From oej@edvina.net Fri Nov 1 00:07:47 2013 Return-Path: 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 0973211E82E4 for ; Fri, 1 Nov 2013 00:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 FjKTelMeDk0E for ; Fri, 1 Nov 2013 00:07:46 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68B11E82B6 for ; Fri, 1 Nov 2013 00:07:43 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id A00C493C2A2; Fri, 1 Nov 2013 07:07:42 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: "Olle E. Johansson" In-Reply-To: <5272C2B7.2080907@gmail.com> Date: Fri, 1 Nov 2013 08:07:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9CEF72C0-E7FB-4063-BC39-D3CE08C81B78@edvina.net> References: <527147FF.5010506@nostrum.com> <5272C2B7.2080907@gmail.com> To: Daniel Constantin Mierla X-Mailer: Apple Mail (2.1816) Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] On the topic of MTI video codecs X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 07:07:47 -0000 On 31 Oct 2013, at 21:51, Daniel-Constantin Mierla = wrote: >=20 > On 10/31/13 10:35 AM, Olle E. Johansson wrote: >> On 30 Oct 2013, at 22:40, Cullen Jennings (fluffy) = wrote: >>=20 >>> On Oct 30, 2013, at 12:20 PM, Leon Geyser wrote: >>>=20 >>>> Unfortunately like Jonathan pointed out H.264 will only be able to = be used royalty free on certain(most popular) platforms. >>>> To be able to avoid negotiation failure we need a MTI codec that = every potential now/future browser would be able to implement freely. >>>> I like what Cisco did, but the solution seems a bit half-baked. >>>>=20 >>> I think that Mozilla put it pretty nicely in their blog. What this = annoucement gives us is not a perfect world. Mozilla is working towards = a better future but in the mean time, this is the best thing we could = possibly figure out on how to make the internet today be the best it can = be for users. >>>=20 >> For the Open Source community in general I beleve this is a big move = forward and I want to thank everyone involved in getting this done. It = can not have been an easy internal struggle through all layers of the = company. Everyone will benefit from it. >>=20 >> For us in the Asterisk community I believe this opens up for use of = video in a whole new way. > To my understanding, the release of the codec is for webrtc only, and = particularly for client side/browsers. For clarification, is this = codec/blob available to use for free in any application, no matter its = relation with webrtc sessions? THe text on OpenH264.org says: "Cisco is announcing today that we will take our H.264 implementation, = and open source it under BSD license terms. Development and maintenance = will be overseen by a board from industry and the open source community. = Furthermore, we will provide a binary form suitable for inclusion in = applications across a number of different operating systems (Windows, = MacOS, Linux x86, Linux ARM and Android ARM), and make this binary = module available for download from the Internet. We will not pass on our = MPEG-LA licensing costs for this module, and based on the current = licensing environment, this will effectively make H.264 free for use on = supported platforms." Doesn't even mention WebRTC - does it? /O= From miconda@gmail.com Fri Nov 1 00:38:01 2013 Return-Path: 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 EEB3E11E82B6 for ; Fri, 1 Nov 2013 00:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] 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 0ATHIrblArpO for ; Fri, 1 Nov 2013 00:38:01 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1C79A21E80A8 for ; Fri, 1 Nov 2013 00:37:48 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id q10so1547871eaj.29 for ; Fri, 01 Nov 2013 00:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=mpJYgqE8xcu4YMjnq91oMZYaKXrCejKmvmCYc4+zZ4w=; b=WRztPuZpc/lh/PdnKlm20N3rmV72b0jdas4e43XsFvji5KXNm/FEmCfHQDZ6uSQxja aM2Yoyg4wFZW+fd08vCoRrRD2399cGzB/homhoY/RgPe42G8kX+j2UBo2j2MXtSzaA0X NWK+kwGn9XUjzQamAVf8hrPPPcXrDqml8X1zJ4BPJoDfdIUukF3XhpX7Vat1hGDke8e1 TclylNP+JSCjNNPHOzFcs0lIaeCld1Uv6zGt8qagha3eCYGstNOSxnEXHsXTGbaovgvG kttHYrUV1DenAigxNxIGWz/RlI0J3DZDDi2pPZ2WI0GxjUsbnbBiSqD4NESgkNxy8LRu WFWg== X-Received: by 10.14.32.65 with SMTP id n41mr123159eea.129.1383291458440; Fri, 01 Nov 2013 00:37:38 -0700 (PDT) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id e13sm4324056eeu.4.2013.11.01.00.37.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 00:37:37 -0700 (PDT) Message-ID: <52735A3F.4020008@gmail.com> Date: Fri, 01 Nov 2013 08:37:35 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <527147FF.5010506@nostrum.com> <5272C2B7.2080907@gmail.com> <9CEF72C0-E7FB-4063-BC39-D3CE08C81B78@edvina.net> In-Reply-To: <9CEF72C0-E7FB-4063-BC39-D3CE08C81B78@edvina.net> Content-Type: multipart/alternative; boundary="------------050407040504070602080704" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On the topic of MTI video codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: miconda@gmail.com 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, 01 Nov 2013 07:38:02 -0000 This is a multi-part message in MIME format. --------------050407040504070602080704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/1/13 8:07 AM, Olle E. Johansson wrote: > On 31 Oct 2013, at 21:51, Daniel-Constantin Mierla wrote: > >> On 10/31/13 10:35 AM, Olle E. Johansson wrote: >>> On 30 Oct 2013, at 22:40, Cullen Jennings (fluffy) wrote: >>> >>>> On Oct 30, 2013, at 12:20 PM, Leon Geyser wrote: >>>> >>>>> Unfortunately like Jonathan pointed out H.264 will only be able to be used royalty free on certain(most popular) platforms. >>>>> To be able to avoid negotiation failure we need a MTI codec that every potential now/future browser would be able to implement freely. >>>>> I like what Cisco did, but the solution seems a bit half-baked. >>>>> >>>> I think that Mozilla put it pretty nicely in their blog. What this annoucement gives us is not a perfect world. Mozilla is working towards a better future but in the mean time, this is the best thing we could possibly figure out on how to make the internet today be the best it can be for users. >>>> >>> For the Open Source community in general I beleve this is a big move forward and I want to thank everyone involved in getting this done. It can not have been an easy internal struggle through all layers of the company. Everyone will benefit from it. >>> >>> For us in the Asterisk community I believe this opens up for use of video in a whole new way. >> To my understanding, the release of the codec is for webrtc only, and particularly for client side/browsers. For clarification, is this codec/blob available to use for free in any application, no matter its relation with webrtc sessions? > THe text on OpenH264.org says: > > "Cisco is announcing today that we will take our H.264 implementation, and open source it under BSD license terms. Development and maintenance will be overseen by a board from industry and the open source community. Furthermore, we will provide a binary form suitable for inclusion in applications across a number of different operating systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and make this binary module available for download from the Internet. We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms." > > Doesn't even mention WebRTC - does it? quick check on that site and I couldn't sport it, maybe there were other blogs/news/... claiming that. On the site, it is still one questionable FAQ, imo: *Q. Can I take advantage of the H.264 codec binary module in my project?* A: Yes. Your users can download this module to utilize the H.264 video codec with your project. "Your users" -- that sound like "not you" as service provider, more like: it can be used by client applications, not servers. Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28 - more details about Kamailio trainings at http://www.asipto.com - --------------050407040504070602080704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/1/13 8:07 AM, Olle E. Johansson wrote:
On 31 Oct 2013, at 21:51, Daniel-Constantin Mierla <miconda@gmail.com> wrote:


On 10/31/13 10:35 AM, Olle E. Johansson wrote:

On 30 Oct 2013, at 22:40, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:


On Oct 30, 2013, at 12:20 PM, Leon Geyser <lgeyser@gmail.com> wrote:


Unfortunately like Jonathan pointed out H.264 will only be able to be used royalty free on certain(most popular) platforms.
To be able to avoid negotiation failure we need a MTI codec that every potential now/future browser would be able to implement freely.
I like what Cisco did, but the solution seems a bit half-baked.


I think that Mozilla put it pretty nicely in their blog. What this annoucement gives us is not a perfect world. Mozilla is working towards a better future but in the mean time, this is the best thing we could possibly figure out on how to make the internet today be the best it can be for users.


For the Open Source community in general I beleve this is a big move forward and I want to thank everyone involved in getting this done. It can not have been an easy internal struggle through all layers of the company. Everyone will benefit from it.

For us in the Asterisk community I believe this opens up for use of video in a whole new way.

To my understanding, the release of the codec is for webrtc only, and particularly for client side/browsers. For clarification, is this codec/blob available to use for free in any application, no matter its relation with webrtc sessions?

THe text on OpenH264.org says:

"Cisco is announcing today that we will take our H.264 implementation, and open source it under BSD license terms. Development and maintenance will be overseen by a board from industry and the open source community. Furthermore, we will provide a binary form suitable for inclusion in applications across a number of different operating systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and make this binary module available for download from the Internet. We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms."

Doesn't even mention WebRTC - does it?
quick check on that site and I couldn't sport it, maybe there were other blogs/news/... claiming that. On the site, it is still one questionable FAQ, imo:

Q. Can I take advantage of the H.264 codec binary module in my project?
A: Yes. Your users can download this module to utilize the H.264 video codec with your project.

"Your users" -- that sound like "not you" as service provider, more like: it can be used by client applications, not servers.

Daniel
-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
  - more details about Kamailio trainings at http://www.asipto.com -
--------------050407040504070602080704-- From oej@edvina.net Fri Nov 1 01:16:57 2013 Return-Path: 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 D615621F9E9A for ; Fri, 1 Nov 2013 01:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6] 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 XI183JovHnhF for ; Fri, 1 Nov 2013 01:16:55 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 55DD321F9994 for ; Fri, 1 Nov 2013 01:16:50 -0700 (PDT) Received: from [192.168.40.22] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 60BED93C2A2; Fri, 1 Nov 2013 08:16:49 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_4706CABD-8E1D-4BD4-B0E8-D7F032ED9B59" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: "Olle E. Johansson" In-Reply-To: <52735A3F.4020008@gmail.com> Date: Fri, 1 Nov 2013 09:16:48 +0100 Message-Id: <6FF7B7FA-39F3-4CDD-B35B-65BBF6E687B5@edvina.net> References: <527147FF.5010506@nostrum.com> <5272C2B7.2080907@gmail.com> <9CEF72C0-E7FB-4063-BC39-D3CE08C81B78@edvina.net> <52735A3F.4020008@gmail.com> To: Daniel Constantin Mierla X-Mailer: Apple Mail (2.1816) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On the topic of MTI video codecs X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 08:16:57 -0000 --Apple-Mail=_4706CABD-8E1D-4BD4-B0E8-D7F032ED9B59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 01 Nov 2013, at 08:37, Daniel-Constantin Mierla = wrote: >=20 > On 11/1/13 8:07 AM, Olle E. Johansson wrote: >> On 31 Oct 2013, at 21:51, Daniel-Constantin Mierla = wrote: >>=20 >>> On 10/31/13 10:35 AM, Olle E. Johansson wrote: >>>> On 30 Oct 2013, at 22:40, Cullen Jennings (fluffy) = wrote: >>>>=20 >>>>> On Oct 30, 2013, at 12:20 PM, Leon Geyser = wrote: >>>>>=20 >>>>>> Unfortunately like Jonathan pointed out H.264 will only be able = to be used royalty free on certain(most popular) platforms. >>>>>> To be able to avoid negotiation failure we need a MTI codec that = every potential now/future browser would be able to implement freely. >>>>>> I like what Cisco did, but the solution seems a bit half-baked. >>>>>>=20 >>>>> I think that Mozilla put it pretty nicely in their blog. What this = annoucement gives us is not a perfect world. Mozilla is working towards = a better future but in the mean time, this is the best thing we could = possibly figure out on how to make the internet today be the best it can = be for users. >>>>>=20 >>>> For the Open Source community in general I beleve this is a big = move forward and I want to thank everyone involved in getting this done. = It can not have been an easy internal struggle through all layers of the = company. Everyone will benefit from it. >>>>=20 >>>> For us in the Asterisk community I believe this opens up for use of = video in a whole new way. >>> To my understanding, the release of the codec is for webrtc only, = and particularly for client side/browsers. For clarification, is this = codec/blob available to use for free in any application, no matter its = relation with webrtc sessions? >> THe text on OpenH264.org says: >>=20 >> "Cisco is announcing today that we will take our H.264 = implementation, and open source it under BSD license terms. Development = and maintenance will be overseen by a board from industry and the open = source community. Furthermore, we will provide a binary form suitable = for inclusion in applications across a number of different operating = systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and make = this binary module available for download from the Internet. We will not = pass on our MPEG-LA licensing costs for this module, and based on the = current licensing environment, this will effectively make H.264 free for = use on supported platforms." >>=20 >> Doesn't even mention WebRTC - does it? > quick check on that site and I couldn't sport it, maybe there were = other blogs/news/... claiming that. Yes, there was a lot of opinions flying around yesterday :-) > On the site, it is still one questionable FAQ, imo: >=20 > Q. Can I take advantage of the H.264 codec binary module in my = project? > A: Yes. Your users can download this module to utilize the H.264 video = codec with your project. >=20 > "Your users" -- that sound like "not you" as service provider, more = like: it can be used by client applications, not servers. I think they mean "the users of your project". In the Asterisk example = we could not distribute the binary as part of our tar.gz but let the = Asterisk admin download the binary manually. We're doing that with some = Digium firmware for cards, sound files and have done it in the past with = some codec source code too. But you are right, the word "users" here is propably just a bad choice = of wording and Cisco could propably clarify a bit better. /O --Apple-Mail=_4706CABD-8E1D-4BD4-B0E8-D7F032ED9B59 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 01 Nov 2013, at 08:37, Daniel-Constantin Mierla <miconda@gmail.com> wrote:


On 11/1/13 8:07 AM, Olle E. Johansson wrote:
On 31 Oct 2013, at 21:51, Daniel-Constantin Mierla <miconda@gmail.com> wrote:


On 10/31/13 10:35 AM, Olle E. Johansson wrote:

On 30 Oct 2013, at 22:40, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:


On Oct 30, 2013, at 12:20 PM, Leon Geyser <lgeyser@gmail.com> wrote:


Unfortunately like Jonathan pointed out H.264 will only be able to be used royalty free on certain(most popular) platforms.
To be able to avoid negotiation failure we need a MTI codec that every potential now/future browser would be able to implement freely.
I like what Cisco did, but the solution seems a bit half-baked.


I think that Mozilla put it pretty nicely in their blog. What this annoucement gives us is not a perfect world. Mozilla is working towards a better future but in the mean time, this is the best thing we could possibly figure out on how to make the internet today be the best it can be for users.


For the Open Source community in general I beleve this is a big move forward and I want to thank everyone involved in getting this done. It can not have been an easy internal struggle through all layers of the company. Everyone will benefit from it.

For us in the Asterisk community I believe this opens up for use of video in a whole new way.

To my understanding, the release of the codec is for webrtc only, and particularly for client side/browsers. For clarification, is this codec/blob available to use for free in any application, no matter its relation with webrtc sessions?

THe text on OpenH264.org says:

"Cisco is announcing today that we will take our H.264 implementation, and open source it under BSD license terms. Development and maintenance will be overseen by a board from industry and the open source community. Furthermore, we will provide a binary form suitable for inclusion in applications across a number of different operating systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and make this binary module available for download from the Internet. We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms."

Doesn't even mention WebRTC - does it?
quick check on that site and I couldn't sport it, maybe there were other blogs/news/... claiming that.
Yes, there was a lot of opinions flying around yesterday :-)

On the site, it is still one questionable FAQ, imo:

Q. Can I take advantage of the H.264 codec binary module in my project?
A: Yes. Your users can download this module to utilize the H.264 video codec with your project.

"Your users" -- that sound like "not you" as service provider, more like: it can be used by client applications, not servers.

I think they mean "the users of your project". In the Asterisk example we could not distribute the binary as part of our tar.gz but let the Asterisk admin download the binary manually. We're doing that with some Digium firmware for cards, sound files and have done it in the past with some codec source code too.

But you are right, the word "users" here is propably just a bad choice of wording and Cisco could propably clarify a bit better.

/O

--Apple-Mail=_4706CABD-8E1D-4BD4-B0E8-D7F032ED9B59-- From simon.perreault@viagenie.ca Fri Nov 1 06:10:53 2013 Return-Path: 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 C38AD21E84EF for ; Fri, 1 Nov 2013 06:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7BCr4huImegL for ; Fri, 1 Nov 2013 06:10:53 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D2FE821E8450 for ; Fri, 1 Nov 2013 06:06:16 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2BBDC403AB for ; Fri, 1 Nov 2013 09:06:15 -0400 (EDT) Message-ID: <5273A746.4060504@viagenie.ca> Date: Fri, 01 Nov 2013 09:06:14 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <527147FF.5010506@nostrum.com> <5272C6C8.3070006@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] On the topic of MTI video codecs X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 13:10:53 -0000 Le 2013-10-31 18:36, Richard Barnes a écrit : > You would need something more than that if you don't trust Cisco not to > tinker with the binaries (no offense). But even that doesn't have to be > complicated. You could just do something like have the software call > back to the vendor whenever it gets a new binary from Cisco to check > that the binary it just got is good (say, by comparing hashes). Is it even necessary that Cisco do the actual compiling of source code? As far as I understand, Cisco only needs to be distributing the binaries. So here's a crazy idea... how about a self-serve binary hosting service? You compile your code, upload it to Cisco, Cisco does the download tracking and accounting, and you and your users just need to download and verify the checksum. Heck, Cisco could even host binaries of x264! That would be much simpler on Cisco's part: much less investment in manpower, much fewer things to maintain and care for. It would just be a glorified FTP server. Unlicensed binary comes in, licensed binary comes out. Platforms could multiply without any effort from Cisco. Win win. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From keith.drage@alcatel-lucent.com Fri Nov 1 07:28:07 2013 Return-Path: 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 8BC4D21E8388 for ; Fri, 1 Nov 2013 07:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 8Hi91L4o71gv for ; Fri, 1 Nov 2013 07:27:47 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D0E3F21E822D for ; Fri, 1 Nov 2013 07:27:46 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rA1ERh8N020110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2013 09:27:45 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rA1ERhmQ012607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Nov 2013 15:27:43 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 1 Nov 2013 15:27:43 +0100 From: "DRAGE, Keith (Keith)" To: Simon Perreault , "rtcweb@ietf.org" Thread-Topic: [rtcweb] On the topic of MTI video codecs Thread-Index: AQHO1wkQNqalYrgjX0CF2LD2UOOxJpoQbMEg Date: Fri, 1 Nov 2013 14:27:42 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0C5BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <527147FF.5010506@nostrum.com> <5272C6C8.3070006@gmail.com> <5273A746.4060504@viagenie.ca> In-Reply-To: <5273A746.4060504@viagenie.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [rtcweb] On the topic of MTI video codecs X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 14:28:09 -0000 I suspect the fallacy in your argument is in the statement "Unlicensed binary comes in, licensed binary comes out." If it was as simple as that, you ISP would them become liable for you H264 = license fees. I suspect that what occurs for Cisco to become liable to the license fees i= s some degree of ownership of the product they are distributing. That ownership means they are also take responsibility for any of the liabi= lities arising from defective code they so distribute. I see no reason why = Cisco would want to do that under anything but a controlled evironment, whi= ch would have its own set of non-trivial costs. Keith > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: 01 November 2013 13:06 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] On the topic of MTI video codecs >=20 > Le 2013-10-31 18:36, Richard Barnes a =E9crit : > > You would need something more than that if you don't trust=20 > Cisco not=20 > > to tinker with the binaries (no offense). But even that=20 > doesn't have=20 > > to be complicated. You could just do something like have=20 > the software=20 > > call back to the vendor whenever it gets a new binary from Cisco to=20 > > check that the binary it just got is good (say, by=20 > comparing hashes). >=20 > Is it even necessary that Cisco do the actual compiling of=20 > source code? >=20 > As far as I understand, Cisco only needs to be distributing=20 > the binaries. So here's a crazy idea... how about a=20 > self-serve binary hosting service? You compile your code,=20 > upload it to Cisco, Cisco does the download tracking and=20 > accounting, and you and your users just need to download and=20 > verify the checksum. Heck, Cisco could even host binaries of x264! >=20 > That would be much simpler on Cisco's part: much less=20 > investment in manpower, much fewer things to maintain and=20 > care for. It would just be a glorified FTP server. Unlicensed=20 > binary comes in, licensed binary comes out. Platforms could=20 > multiply without any effort from Cisco. Win win. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From emcho@sip-communicator.org Fri Nov 1 08:15:09 2013 Return-Path: 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 8D72411E83A1 for ; Fri, 1 Nov 2013 08:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 wRAf1-RRU308 for ; Fri, 1 Nov 2013 08:14:57 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id B127311E8163 for ; Fri, 1 Nov 2013 08:14:57 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rq13so308197pbb.20 for ; Fri, 01 Nov 2013 08:14:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5NmvNHyihtgAGgKpIh8TuaKMHnv55zcruZQu0Y3KR2U=; b=B7pHOdvbXSv/X8NjOKmp1CczqyHeTvsDLk3tvcdoOYe6NBq5NNqe3MR9L/PctWAYsZ 90bdayntIm/N9paZlAmhQ811x5T5OHzp2B061ZahFZfo0/esU8Iq72J9BNoTIlQy5XVk LIF131GSuSQ/JQaWO1rsCa5CQEJpFDFFZZDndQd8q9uaTpEgt/2wJHlh/OPxjyupOH9Y 0ZZEw1pqh9Nyyi7ORxEbgnsT1K0sPs0aDAv7dORHDc3aDz/F/MQ1pc1Y0MOYNjZrMczz jK7EG6NSpIG5wbQ1hGjLh6LlfPcSJ0yh+9Dgq7ANUrHuB7hFrWzZxh3CR5+LXhACJ6O+ RQFA== X-Gm-Message-State: ALoCoQmEqw4zvCjpRFYHwAICc/Kfi2CbszN48nYytTqBKaeMcq4fbFuvUTTbYnDs+3eDpP5EKzxn X-Received: by 10.66.123.5 with SMTP id lw5mr3629717pab.83.1383318895519; Fri, 01 Nov 2013 08:14:55 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [2607:f8b0:400e:c03::231]) by mx.google.com with ESMTPSA id v4sm11375312pbq.31.2013.11.01.08.14.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 08:14:54 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so4155546pab.22 for ; Fri, 01 Nov 2013 08:14:54 -0700 (PDT) X-Received: by 10.68.164.165 with SMTP id yr5mr3720017pbb.146.1383318894868; Fri, 01 Nov 2013 08:14:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Fri, 1 Nov 2013 08:14:34 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0C5BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <527147FF.5010506@nostrum.com> <5272C6C8.3070006@gmail.com> <5273A746.4060504@viagenie.ca> <949EF20990823C4C85C18D59AA11AD8B0C5BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Emil Ivov Date: Fri, 1 Nov 2013 16:14:34 +0100 Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On the topic of MTI video codecs X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 15:15:09 -0000 On Fri, Nov 1, 2013 at 3:27 PM, DRAGE, Keith (Keith) wrote: > > That ownership means they are also take responsibility for any of the liabilities arising > from defective code they so distribute. I see no reason why Cisco would want to do > that under anything but a controlled evironment, which would have its own set of > non-trivial costs. They could have the same by distributing x264 binaries that they have compiled by themselves. One of the things in the Cisco grand, that sound a bit incoherent to me is their declared will on building a healthy open source community around their implementation. Specifically, what baffles me is that there is already a very well oiled implementation that does a lot more than just baseline. That implementation already has a vibrant community, significant popularity and, again, it sounds like it would be considerably superior to what Cisco are planning on rolling out in OpenH264. In addition to wondering at the pure waste of resources (with a casual reference to NIH), potential contributors could legitimately ask "why would we contribute to your project when you made the exact opposite choice when faced with the decision?". Emil -- https://jitsi.org From chris-ietf@chriswendt.net Fri Nov 1 08:20:46 2013 Return-Path: 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 8F35011E8212 for ; Fri, 1 Nov 2013 08:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FM3dOlYe80fG for ; Fri, 1 Nov 2013 08:20:42 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id EB15D11E8163 for ; Fri, 1 Nov 2013 08:20:41 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id k15so680656qaq.20 for ; Fri, 01 Nov 2013 08:20:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9kClB3KdD6dbTVPk7Kdic42sIyRCd0/aGISC0N/0nLE=; b=NimyABHaua9d731hofq1DpoKxdXlBq/9OO/CQ84aNj01AXUiTOUqVXBUhqRbSvCIsE dZdH3pAHoaS9N1OHH53s+BxQAk32UBcQYVPWBDnBDU6UVbF9eUXB1MBMAWVdaKO1dY5f ET0Achi0yBotxMVqvy9MTguF8/+1H/ZYz4Co8ig0yguwkjydErpU98VHB4RV+IhKm96N mK5znOWs62G2qoeQT9PtGkDjhpGu7vL+iWTungmnw5IxuAbPOIO/4MPvU4a/PpB6EejV chxx4fGfQKjYfscww5wJbXe0YorBNCI8O7ClPd9QJ8rYeYZMBeLD8I/HK7wYy4y14NVI xcGw== X-Gm-Message-State: ALoCoQleMU4PK59mpFh2Rgv+4qBbYNnJQUB4F+7NnUuYrHoDtuUgqZRs2N1YgVfKaQBnYTZvJXCa X-Received: by 10.224.161.146 with SMTP id r18mr4661192qax.57.1383319240826; Fri, 01 Nov 2013 08:20:40 -0700 (PDT) Received: from [172.20.10.3] ([166.137.105.26]) by mx.google.com with ESMTPSA id r5sm21937430qaj.13.2013.11.01.08.20.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 08:20:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Chris Wendt In-Reply-To: Date: Fri, 1 Nov 2013 11:20:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <33754450-A153-4540-8A11-842062C887FB@chriswendt.net> References: <527147FF.5010506@nostrum.com> <5272C6C8.3070006@gmail.com> <5273A746.4060504@viagenie.ca> <949EF20990823C4C85C18D59AA11AD8B0C5BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: Emil Ivov X-Mailer: Apple Mail (2.1812) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On the topic of MTI video codecs X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 15:20:46 -0000 x264 is GPL. On Nov 1, 2013, at 11:14 AM, Emil Ivov wrote: > On Fri, Nov 1, 2013 at 3:27 PM, DRAGE, Keith (Keith) > wrote: >>=20 >> That ownership means they are also take responsibility for any of the = liabilities arising >> from defective code they so distribute. I see no reason why Cisco = would want to do >> that under anything but a controlled evironment, which would have its = own set of >> non-trivial costs. >=20 > They could have the same by distributing x264 binaries that they have > compiled by themselves. >=20 > One of the things in the Cisco grand, that sound a bit incoherent to > me is their declared will on building a healthy open source community > around their implementation. Specifically, what baffles me is that > there is already a very well oiled implementation that does a lot more > than just baseline. That implementation already has a vibrant > community, significant popularity and, again, it sounds like it would > be considerably superior to what Cisco are planning on rolling out in > OpenH264. >=20 > In addition to wondering at the pure waste of resources (with a casual > reference to NIH), potential contributors could legitimately ask "why > would we contribute to your project when you made the exact opposite > choice when faced with the decision?". >=20 > Emil >=20 > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From emcho@sip-communicator.org Fri Nov 1 08:26:27 2013 Return-Path: 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 315CE11E83AC for ; Fri, 1 Nov 2013 08:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 TFb17fjvQHLN for ; Fri, 1 Nov 2013 08:26:22 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id A418111E817D for ; Fri, 1 Nov 2013 08:25:52 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id w10so3971748pde.16 for ; Fri, 01 Nov 2013 08:25:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WEnT+MALByFSIDId4IodDF9deAtPrbc4cilzbegdxXk=; b=jTUvh7upOimERUnnondwVFoNSfXxX1QMqDuXTeA2D8UFHKwfzu4StKf4TBurnzGo5H QOxiBZPpc/zzLJMsHXTYqMzWjMK46TO7dDr4yAg+IbyEK/J8Q1YmTC+AID7OoAUkpXHN JZc1ddZWKjANzay28q9UMGWH3C0qai4wPj3een+e2efSW7bvKDUBZNGAx22Oymb6iNXh DTwyVF1ucH3x4NpuKanPi47DPGIvwboqB0sVd+NoQ3G/ytlTTCPXc9zmRFbx81wBCyhD vKM0+X8TmN/UZk5zLxyXqW29bPRcAfhkbsxgqblp3pOjPaeLnSCrZ78bcTK/Qxr4gRnC 2utA== X-Gm-Message-State: ALoCoQnvc/5mttElY9dbhHDc1RnLyF/9jXRokaV+oHZSaKJKKbn6YouIuEL0szytzn0D/m9hJjhJ X-Received: by 10.68.235.72 with SMTP id uk8mr3754027pbc.93.1383319551920; Fri, 01 Nov 2013 08:25:51 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [2607:f8b0:400e:c03::22d]) by mx.google.com with ESMTPSA id fa4sm13656646pab.17.2013.11.01.08.25.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 08:25:51 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id kp14so4174307pab.18 for ; Fri, 01 Nov 2013 08:25:51 -0700 (PDT) X-Received: by 10.68.178.197 with SMTP id da5mr3804420pbc.28.1383319551324; Fri, 01 Nov 2013 08:25:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Fri, 1 Nov 2013 08:25:31 -0700 (PDT) In-Reply-To: <33754450-A153-4540-8A11-842062C887FB@chriswendt.net> References: <527147FF.5010506@nostrum.com> <5272C6C8.3070006@gmail.com> <5273A746.4060504@viagenie.ca> <949EF20990823C4C85C18D59AA11AD8B0C5BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <33754450-A153-4540-8A11-842062C887FB@chriswendt.net> From: Emil Ivov Date: Fri, 1 Nov 2013 16:25:31 +0100 Message-ID: To: Chris Wendt Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On the topic of MTI video codecs X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 15:26:27 -0000 On Fri, Nov 1, 2013 at 4:20 PM, Chris Wendt wrote: > x264 is GPL. I am not sure I see how that is relevant. It's not supposed to be distributed with proprietary software, is it? It would just be a single binary with available source code. Perfectly compatible with GPL. -- https://jitsi.org From fluffy@iii.ca Fri Nov 1 08:56:51 2013 Return-Path: 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 2DE0511E8159 for ; Fri, 1 Nov 2013 08:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599] 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 4D3ZqJ+Rm60q for ; Fri, 1 Nov 2013 08:56:41 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01221F86B9 for ; Fri, 1 Nov 2013 08:56:25 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 64B4122E257; Fri, 1 Nov 2013 11:56:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: Date: Fri, 1 Nov 2013 09:56:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <32DDCDFD-C4AF-4714-BD1A-580D99DD9FCF@iii.ca> References: <527147FF.5010506@nostrum.com> <5272C6C8.3070006@gmail.com> <5273A746.4060504@viagenie.ca> <949EF20990823C4C85C18D59AA11AD8B0C5BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: Emil Ivov X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On the topic of MTI video codecs X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 15:56:52 -0000 On Nov 1, 2013, at 9:14 AM, Emil Ivov wrote: > On Fri, Nov 1, 2013 at 3:27 PM, DRAGE, Keith (Keith) > wrote: >>=20 >> That ownership means they are also take responsibility for any of the = liabilities arising >> from defective code they so distribute. I see no reason why Cisco = would want to do >> that under anything but a controlled evironment, which would have its = own set of >> non-trivial costs. >=20 > They could have the same by distributing x264 binaries that they have > compiled by themselves. >=20 > One of the things in the Cisco grand, that sound a bit incoherent to > me is their declared will on building a healthy open source community > around their implementation. Specifically, what baffles me is that > there is already a very well oiled implementation that does a lot more > than just baseline. That implementation already has a vibrant > community, significant popularity and, again, it sounds like it would > be considerably superior to what Cisco are planning on rolling out in > OpenH264. >=20 > In addition to wondering at the pure waste of resources (with a casual > reference to NIH), potential contributors could legitimately ask "why > would we contribute to your project when you made the exact opposite > choice when faced with the decision?". >=20 > Emil We considered just using x264 (I like x264 myself) that but Mozilla told = us it would not work for them because it is GPL. From emcho@sip-communicator.org Fri Nov 1 09:19:51 2013 Return-Path: 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 7165321E844E for ; Fri, 1 Nov 2013 09:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 ELgkyat0gwD4 for ; Fri, 1 Nov 2013 09:19:47 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1027021E84D8 for ; Fri, 1 Nov 2013 09:19:47 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id jt11so4504529pbb.29 for ; Fri, 01 Nov 2013 09:19:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=7bXNzuRcpKp4fEEUp2cGWOvB/JNvnKv4cfX4/VH0/Og=; b=H8nZD6ptOCdCwXd5nYjWqrlQDuho9dJUwtDrN5rmWBRLdW28YJpLAQJ0FbNObWU45V x8k36Ja7K1lr4C0uFw1K42FVSdZX7v8WVYSQI83x+1heC+ElG8yB6hdSUXQpqI9dAgAQ Xz6Kax8Uf+FjU2dy385X/ZHxxCQlNOCFif3BB+CT/O5Yif2kq4AleO9iJEEtiAjD6zCW ZjN9ldvOMX9FPgb4fpM966+dXrjhRNtQNFNAssHDLicIcCIFir2/zcPhDO6urBhoJxoG tNnws4ZPQqNKoKh7678exJQYcI8eyXuJLDOwh+wjYqnXQOQTZof7XDENdM8ecCBLpRNl eK8Q== X-Gm-Message-State: ALoCoQkhfthOoqYn2VXaAg0sKIWizThVX3jH3H94sOvD7NTNMt6ScOt1JWbhN9KW0nW8pPYBtYPM X-Received: by 10.68.133.198 with SMTP id pe6mr4035264pbb.10.1383322786149; Fri, 01 Nov 2013 09:19:46 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [2607:f8b0:400e:c03::235]) by mx.google.com with ESMTPSA id qf7sm13953920pac.14.2013.11.01.09.19.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 09:19:45 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kx10so4220616pab.40 for ; Fri, 01 Nov 2013 09:19:45 -0700 (PDT) X-Received: by 10.68.59.202 with SMTP id b10mr4041159pbr.78.1383322785584; Fri, 01 Nov 2013 09:19:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Fri, 1 Nov 2013 09:19:25 -0700 (PDT) From: Emil Ivov Date: Fri, 1 Nov 2013 17:19:25 +0100 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 16:19:51 -0000 On Fri, Nov 1, 2013 at 4:56 PM, Cullen Jennings wrote: > > On Nov 1, 2013, at 9:14 AM, Emil Ivov wrote: > >> On Fri, Nov 1, 2013 at 3:27 PM, DRAGE, Keith (Keith) >> wrote: >>> >>> That ownership means they are also take responsibility for any of the liabilities arising >>> from defective code they so distribute. I see no reason why Cisco would want to do >>> that under anything but a controlled evironment, which would have its own set of >>> non-trivial costs. >> >> They could have the same by distributing x264 binaries that they have >> compiled by themselves. >> >> One of the things in the Cisco grand, that sound a bit incoherent to >> me is their declared will on building a healthy open source community >> around their implementation. Specifically, what baffles me is that >> there is already a very well oiled implementation that does a lot more >> than just baseline. That implementation already has a vibrant >> community, significant popularity and, again, it sounds like it would >> be considerably superior to what Cisco are planning on rolling out in >> OpenH264. >> >> In addition to wondering at the pure waste of resources (with a casual >> reference to NIH), potential contributors could legitimately ask "why >> would we contribute to your project when you made the exact opposite >> choice when faced with the decision?". >> >> Emil > > We considered just using x264 (I like x264 myself) that but Mozilla told us it would not work for them because it is GPL. It would be nice for Mozilla to comment then. They wouldn't have been required to statically link against it or even distribute it. It is already possible to use GPL plug-ins with Firefox, so why is x264 an insurmountable problem? Emil -- https://jitsi.org From cowwoc@bbs.darktech.org Fri Nov 1 09:24:58 2013 Return-Path: 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 D050B21E808F for ; Fri, 1 Nov 2013 09:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 9w473AQTJPPN for ; Fri, 1 Nov 2013 09:24:47 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id C266F11E8125 for ; Fri, 1 Nov 2013 09:24:46 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so2729776qeb.17 for ; Fri, 01 Nov 2013 09:24:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+d8jOxqYWm97ptEL+Eo/uK3lM8N9mQCNT9N1of9ul7Q=; b=Hb/vCX4XPviz2ByxHs6h0asM5tFSv67PkCFUOWO1mqwEtMn6eGBbvvWEYgbCeWNd77 fqP3cFkayQREBVGy23D1aecaX7L2DPmWknqUXsL0O8dZNNEf8Rb0RFauy1KRGuKB19Wq 8/CJjXv5eyEodP9qag+sK45AQKBVpKZUcxubxPlEpTukXPbqY3M0KtuqE59GfxtLFxgm oTHtuVR7OeECvDfEaWcb6cSIGQKm4fY4FqSAf7nJQ+13tchQdlUEUPGvNoed53stWsUM AcFmPTZckPRamVmNt1BpqHABSmPK+u6W97oELd8lzzV7ZMMhKp1gdgsToawd1oBsNGN3 MOHw== X-Gm-Message-State: ALoCoQnlhYuLrRUTO6akavNPXDLpi4MDI+w6YatXtTvD82/oOERvOoiYa8amtkMi2sjLk6aeoWJp X-Received: by 10.224.56.5 with SMTP id w5mr5031780qag.60.1383323085899; Fri, 01 Nov 2013 09:24:45 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id h2sm1817181qaf.10.2013.11.01.09.24.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 09:24:45 -0700 (PDT) Message-ID: <5273D5C8.304@bbs.darktech.org> Date: Fri, 01 Nov 2013 12:24:40 -0400 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: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 16:24:58 -0000 On 01/11/2013 12:19 PM, Emil Ivov wrote: > It would be nice for Mozilla to comment then. They wouldn't have been > required to statically link against it or even distribute it. It is > already possible to use GPL plug-ins with Firefox, so why is x264 an > insurmountable problem? Can I dynamically link x264 against my proprietary application without having to GPL it? If not, that's a non-starter. Similarly, what do I under iOS where I am forced to statically link? Whatever solution we end up with has to enable closed-source non-browser applications to act as WebRTC peers. This approach sounds like a non-starter to me. Gili From mail@makk.es Fri Nov 1 09:35:46 2013 Return-Path: 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 B9EAF11E8210 for ; Fri, 1 Nov 2013 09:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] 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 1AR73451GGDm for ; Fri, 1 Nov 2013 09:35:35 -0700 (PDT) Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id 077D011E817D for ; Fri, 1 Nov 2013 09:35:34 -0700 (PDT) Received: (qmail 26391 invoked from network); 1 Nov 2013 16:35:26 -0000 Received: from unknown (HELO ?192.168.0.20?) (31.18.104.182) by lupus.uberspace.de with SMTP; 1 Nov 2013 16:35:26 -0000 Message-ID: <5273D848.2060608@makk.es> Date: Fri, 01 Nov 2013 17:35:20 +0100 From: Max Jonas Werner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: cowwoc , rtcweb@ietf.org References: <5273D5C8.304@bbs.darktech.org> In-Reply-To: <5273D5C8.304@bbs.darktech.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IkmBO19wtNV85HL92NxCfhSMMQrhQhQuQ" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 16:35:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IkmBO19wtNV85HL92NxCfhSMMQrhQhQuQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01.11.2013 17:24, cowwoc wrote: > On 01/11/2013 12:19 PM, Emil Ivov wrote: >> It would be nice for Mozilla to comment then. They wouldn't have been >> required to statically link against it or even distribute it. It is >> already possible to use GPL plug-ins with Firefox, so why is x264 an >> insurmountable problem? >=20 > Can I dynamically link x264 against my proprietary application without = > having to GPL it? Actually no: https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL That's why the LGPL (that poses other risks, though) exists. Max --IkmBO19wtNV85HL92NxCfhSMMQrhQhQuQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFSc9hK1IVn4/X13N8RAsoJAKC2jE/tmjHVntuQpbUW1CV7LWj7WACeIJkg V4yhTk2yuOO8/v04Jml2CBA= =3B46 -----END PGP SIGNATURE----- --IkmBO19wtNV85HL92NxCfhSMMQrhQhQuQ-- From oej@edvina.net Fri Nov 1 09:38:38 2013 Return-Path: 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 D319211E8199 for ; Fri, 1 Nov 2013 09:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] 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 Zn24-QjFTKa1 for ; Fri, 1 Nov 2013 09:38:35 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4172011E817D for ; Fri, 1 Nov 2013 09:38:28 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 49A2993C2A3; Fri, 1 Nov 2013 16:38:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 1 Nov 2013 17:36:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <14789922-BEC6-460B-ABB0-092D63237BBF@edvina.net> References: To: Emil Ivov X-Mailer: Apple Mail (2.1816) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 16:38:39 -0000 On 01 Nov 2013, at 17:19, Emil Ivov wrote: > On Fri, Nov 1, 2013 at 4:56 PM, Cullen Jennings wrote: >>=20 >> On Nov 1, 2013, at 9:14 AM, Emil Ivov wrote: >>=20 >>> On Fri, Nov 1, 2013 at 3:27 PM, DRAGE, Keith (Keith) >>> wrote: >>>>=20 >>>> That ownership means they are also take responsibility for any of = the liabilities arising >>>> from defective code they so distribute. I see no reason why Cisco = would want to do >>>> that under anything but a controlled evironment, which would have = its own set of >>>> non-trivial costs. >>>=20 >>> They could have the same by distributing x264 binaries that they = have >>> compiled by themselves. >>>=20 >>> One of the things in the Cisco grand, that sound a bit incoherent to >>> me is their declared will on building a healthy open source = community >>> around their implementation. Specifically, what baffles me is that >>> there is already a very well oiled implementation that does a lot = more >>> than just baseline. That implementation already has a vibrant >>> community, significant popularity and, again, it sounds like it = would >>> be considerably superior to what Cisco are planning on rolling out = in >>> OpenH264. >>>=20 >>> In addition to wondering at the pure waste of resources (with a = casual >>> reference to NIH), potential contributors could legitimately ask = "why >>> would we contribute to your project when you made the exact opposite >>> choice when faced with the decision?". >>>=20 >>> Emil >>=20 >> We considered just using x264 (I like x264 myself) that but Mozilla = told us it would not work for them because it is GPL. >=20 > It would be nice for Mozilla to comment then. They wouldn't have been > required to statically link against it or even distribute it. It is > already possible to use GPL plug-ins with Firefox, so why is x264 an > insurmountable problem? >=20 Emil. If you take x264 and link into Jitsi you will have to pay license = fees to MPEG-LA. If you let the Jitsi users download the codec binary from Cisco and use = the plugin API which will=20 be defined by the OpenH264 community you don't have to pay any license = fees. Cisco will. It's all about the money. Make sure you join that API discussion so you = can use it in Jitsi. I would like that. :-) The same applies to Mozilla/Firefox. /O From emcho@sip-communicator.org Fri Nov 1 09:52:11 2013 Return-Path: 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 9920F11E821C for ; Fri, 1 Nov 2013 09:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 fKhRB+lPjMys for ; Fri, 1 Nov 2013 09:52:07 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 45E1211E8117 for ; Fri, 1 Nov 2013 09:52:07 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so4488584pbc.36 for ; Fri, 01 Nov 2013 09:52:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xLxrOqrU+vWhsutO2hJKLm2QDGqT/Kar6XAcy8tzqIU=; b=mwwdlXOBMgU5pooybinygXrmXdu4EJockNA/Jwc+soOOasr6eXK4gjwg7AXwimm4ni HRgrRrBi+GKEr076PylD5e53yrsVv43mg7G4RzV/trdFt8QRX9YSQP7366rldtje6ezG egpGEki8tPEMO1UyYfIQegzX4mZRXHXqI4amqYPfhI9KIpMnrg+xxg7TyFFdJFCjfo1n /eh+tTEMXIvEIFhIQp9Hqndfts+pXFIlEXSYB1fSImWcuAikjuLPs1Qo9oSncAL4oUmS la43xSL8sKKkDd1BJG9JYC1a5mdO83hnIM8W5jNsYLrt0nIjvz+7dM005VExAWudUM0j ARkQ== X-Gm-Message-State: ALoCoQleKYzY4rKhyp66a9htWURcj8EDnH2OaHtDOuiDPOca6rKCZLLIVYo1RpjsqvxiOx4Ru3F4 X-Received: by 10.66.169.172 with SMTP id af12mr4217131pac.23.1383324726617; Fri, 01 Nov 2013 09:52:06 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [2607:f8b0:400e:c02::233]) by mx.google.com with ESMTPSA id lm2sm14154274pab.2.2013.11.01.09.52.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 09:52:06 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id y10so4058593pdj.24 for ; Fri, 01 Nov 2013 09:52:06 -0700 (PDT) X-Received: by 10.66.118.204 with SMTP id ko12mr2446284pab.184.1383324726080; Fri, 01 Nov 2013 09:52:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Fri, 1 Nov 2013 09:51:44 -0700 (PDT) In-Reply-To: <14789922-BEC6-460B-ABB0-092D63237BBF@edvina.net> References: <14789922-BEC6-460B-ABB0-092D63237BBF@edvina.net> From: Emil Ivov Date: Fri, 1 Nov 2013 17:51:44 +0100 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 16:52:11 -0000 Hey Olle, On Fri, Nov 1, 2013 at 5:36 PM, Olle E. Johansson wrote: > > On 01 Nov 2013, at 17:19, Emil Ivov wrote: > >> On Fri, Nov 1, 2013 at 4:56 PM, Cullen Jennings wrote: >>> >>> On Nov 1, 2013, at 9:14 AM, Emil Ivov wrote: >>> >>>> On Fri, Nov 1, 2013 at 3:27 PM, DRAGE, Keith (Keith) >>>> wrote: >>>>> >>>>> That ownership means they are also take responsibility for any of the liabilities arising >>>>> from defective code they so distribute. I see no reason why Cisco would want to do >>>>> that under anything but a controlled evironment, which would have its own set of >>>>> non-trivial costs. >>>> >>>> They could have the same by distributing x264 binaries that they have >>>> compiled by themselves. >>>> >>>> One of the things in the Cisco grand, that sound a bit incoherent to >>>> me is their declared will on building a healthy open source community >>>> around their implementation. Specifically, what baffles me is that >>>> there is already a very well oiled implementation that does a lot more >>>> than just baseline. That implementation already has a vibrant >>>> community, significant popularity and, again, it sounds like it would >>>> be considerably superior to what Cisco are planning on rolling out in >>>> OpenH264. >>>> >>>> In addition to wondering at the pure waste of resources (with a casual >>>> reference to NIH), potential contributors could legitimately ask "why >>>> would we contribute to your project when you made the exact opposite >>>> choice when faced with the decision?". >>>> >>>> Emil >>> >>> We considered just using x264 (I like x264 myself) that but Mozilla told us it would not work for them because it is GPL. >> >> It would be nice for Mozilla to comment then. They wouldn't have been >> required to statically link against it or even distribute it. It is >> already possible to use GPL plug-ins with Firefox, so why is x264 an >> insurmountable problem? >> > Emil. If you take x264 and link into Jitsi you will have to pay license fees to MPEG-LA. > > If you let the Jitsi users download the codec binary from Cisco and use the plugin API which will > be defined by the OpenH264 community you don't have to pay any license fees. Cisco will. My question was: why not have users download x264 binaries from Cisco. Basically, nothing changes from the current Cisco suggestion, except for where the source code comes from. Emil -- https://jitsi.org From rlb@ipv.sx Fri Nov 1 10:01:57 2013 Return-Path: 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 2EEE711E8117 for ; Fri, 1 Nov 2013 10:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 FlDhsjx40Xev for ; Fri, 1 Nov 2013 10:01:53 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id 480BC11E8172 for ; Fri, 1 Nov 2013 10:01:52 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id gq1so4834853obb.32 for ; Fri, 01 Nov 2013 10:01:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=98zzBOE7mcm0kU1luh7j9BmICYZe7LDcTgD56LMva2M=; b=mHZBh6ict8aX2k+xKZsFsswSu1hpa0GEb7P0NBPNJ/ohSf/TmNtHQibCs8+M62FxFR U48hmZxXh2v+xYnQkq/EHdp1DAGSP0yjXOohHv3aSHKV7utWiOtNHD8d49bNIdUBtG/a YkIrV+L/3FbT/Ta210+hRSP0XBqtFT0AOUH3Tzq1w/0sBMZSMOMhR6PxORqD+BrcAaZF +mSaINSMpAal4prgmuQfk/SwX3Ctcu3WFdUL/bTkGRnknHLVZtkTT7lnLrrgNCg86Yru 1j7GnN+Z1GzvWAA57pVb594gtf7H0u6ps0VwZmbey9l1K8tnwrPHcvV1yZS5rzcfNAJS Sjcg== X-Gm-Message-State: ALoCoQkUKumxNHy5IvCijmUXboTAwe7+rprMD7OTvuP7GQyDCw+nAJRlAYiSu3X+AIPXKsQwuPWk MIME-Version: 1.0 X-Received: by 10.60.155.240 with SMTP id vz16mr171697oeb.102.1383325311786; Fri, 01 Nov 2013 10:01:51 -0700 (PDT) Received: by 10.76.101.10 with HTTP; Fri, 1 Nov 2013 10:01:51 -0700 (PDT) In-Reply-To: References: <14789922-BEC6-460B-ABB0-092D63237BBF@edvina.net> Date: Fri, 1 Nov 2013 13:01:51 -0400 Message-ID: From: Richard Barnes To: Emil Ivov Content-Type: multipart/alternative; boundary=047d7bfcf3c0d1761604ea208571 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 17:01:57 -0000 --047d7bfcf3c0d1761604ea208571 Content-Type: text/plain; charset=ISO-8859-1 IIUC, by providing a BSD implementation, developers will be able to build the library directly into their apps, if they're willing to accept the MPEG-LA restrictions. This could be helpful for developers who are willing to pay the license fees, or who are too small to be required to pay the license (think I had head 100k users). The BSD licensed implementation means that those developers don't have to either (1) bother with the Cisco song and dance or (2) worry about GPL restrictions. --Richard On Fri, Nov 1, 2013 at 12:51 PM, Emil Ivov wrote: > Hey Olle, > > On Fri, Nov 1, 2013 at 5:36 PM, Olle E. Johansson wrote: > > > > On 01 Nov 2013, at 17:19, Emil Ivov wrote: > > > >> On Fri, Nov 1, 2013 at 4:56 PM, Cullen Jennings wrote: > >>> > >>> On Nov 1, 2013, at 9:14 AM, Emil Ivov wrote: > >>> > >>>> On Fri, Nov 1, 2013 at 3:27 PM, DRAGE, Keith (Keith) > >>>> wrote: > >>>>> > >>>>> That ownership means they are also take responsibility for any of > the liabilities arising > >>>>> from defective code they so distribute. I see no reason why Cisco > would want to do > >>>>> that under anything but a controlled evironment, which would have > its own set of > >>>>> non-trivial costs. > >>>> > >>>> They could have the same by distributing x264 binaries that they have > >>>> compiled by themselves. > >>>> > >>>> One of the things in the Cisco grand, that sound a bit incoherent to > >>>> me is their declared will on building a healthy open source community > >>>> around their implementation. Specifically, what baffles me is that > >>>> there is already a very well oiled implementation that does a lot more > >>>> than just baseline. That implementation already has a vibrant > >>>> community, significant popularity and, again, it sounds like it would > >>>> be considerably superior to what Cisco are planning on rolling out in > >>>> OpenH264. > >>>> > >>>> In addition to wondering at the pure waste of resources (with a casual > >>>> reference to NIH), potential contributors could legitimately ask "why > >>>> would we contribute to your project when you made the exact opposite > >>>> choice when faced with the decision?". > >>>> > >>>> Emil > >>> > >>> We considered just using x264 (I like x264 myself) that but Mozilla > told us it would not work for them because it is GPL. > >> > >> It would be nice for Mozilla to comment then. They wouldn't have been > >> required to statically link against it or even distribute it. It is > >> already possible to use GPL plug-ins with Firefox, so why is x264 an > >> insurmountable problem? > >> > > Emil. If you take x264 and link into Jitsi you will have to pay license > fees to MPEG-LA. > > > > If you let the Jitsi users download the codec binary from Cisco and use > the plugin API which will > > be defined by the OpenH264 community you don't have to pay any license > fees. Cisco will. > > My question was: why not have users download x264 binaries from Cisco. > Basically, nothing changes from the current Cisco suggestion, except > for where the source code comes from. > > Emil > > -- > https://jitsi.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bfcf3c0d1761604ea208571 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
IIUC, by providing a BSD implementation, developers w= ill be able to build the library directly into their apps, if they're w= illing to accept the MPEG-LA restrictions.=A0 This could be helpful for dev= elopers who are willing to pay the license fees, or who are too small to be= required to pay the license (think I had head 100k users).=A0 The BSD lice= nsed implementation means that those developers don't have to either (1= ) bother with the Cisco song and dance or (2) worry about GPL restrictions.=

--Richard


On Fri, Nov 1, 2013 at 12:51 PM, Emil Ivov <emcho@jitsi.org= > wrote:
Hey Olle,

On Fri, Nov 1, 2013 at 5:36 PM, Olle E. Johansson <oej@edvina.net> wrote:
>
> On 01 Nov 2013, at 17:19, Emil Ivov <emcho@jitsi.org> wrote:
>
>> On Fri, Nov 1, 2013 at 4:56 PM, Cullen Jennings <fluffy@iii.ca> wrote:
>>>
>>> On Nov 1, 2013, at 9:14 AM, Emil Ivov <emcho@jitsi.org> wrote:
>>>
>>>> On Fri, Nov 1, 2013 at 3:27 PM, DRAGE, Keith (Keith)
>>>> <keit= h.drage@alcatel-lucent.com> wrote:
>>>>>
>>>>> That ownership means they are also take responsibility= for any of the liabilities arising
>>>>> from defective code they so distribute. I see no reaso= n why Cisco would want to do
>>>>> that under anything but a controlled evironment, which= would have its own set of
>>>>> non-trivial costs.
>>>>
>>>> They could have the same by distributing x264 binaries tha= t they have
>>>> compiled by themselves.
>>>>
>>>> One of the things in the Cisco grand, that sound a bit inc= oherent to
>>>> me is their declared will on building a healthy open sourc= e community
>>>> around their implementation. Specifically, what baffles me= is that
>>>> there is already a very well oiled implementation that doe= s a lot more
>>>> than just baseline. That implementation already has a vibr= ant
>>>> community, significant popularity and, again, it sounds li= ke it would
>>>> be considerably superior to what Cisco are planning on rol= ling out in
>>>> OpenH264.
>>>>
>>>> In addition to wondering at the pure waste of resources (w= ith a casual
>>>> reference to NIH), potential contributors could legitimate= ly ask "why
>>>> would we contribute to your project when you made the exac= t opposite
>>>> choice when faced with the decision?".
>>>>
>>>> Emil
>>>
>>> We considered just using x264 (I like x264 myself) that but Mo= zilla told us it would not work for them because it is GPL.
>>
>> It would be nice for Mozilla to comment then. They wouldn't ha= ve been
>> required to statically link against it or even distribute it. It i= s
>> already possible to use GPL plug-ins with Firefox, so why is x264 = an
>> insurmountable problem?
>>
> Emil. If you take x264 and link into Jitsi you will have to pay licens= e fees to MPEG-LA.
>
> If you let the Jitsi users download the codec binary from Cisco and us= e the plugin API which will
> be defined by the OpenH264 community you don't have to pay any lic= ense fees. Cisco will.

My question was: why not have users download x264 binaries from= Cisco.
Basically, nothing changes from the current Cisco suggestion, except
for where the source code comes from.

Emil

--
https://jitsi.org
_____________________= __________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bfcf3c0d1761604ea208571-- From miconda@gmail.com Fri Nov 1 10:03:47 2013 Return-Path: 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 186B911E80DE for ; Fri, 1 Nov 2013 10:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] 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 FPbtMVi05ZuP for ; Fri, 1 Nov 2013 10:03:46 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id E2A4D11E8117 for ; Fri, 1 Nov 2013 10:03:45 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id f15so2166763eak.22 for ; Fri, 01 Nov 2013 10:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=q+TCVuSNE/L/JgYqxfVOPdWRhViM3UyLKUpT1WK8RbU=; b=fwXtz7153bfYLlzX61CtZPLkKhu0j4qA2flZ1CRU87LlxpnCt06i/hL71zNEC0/YvL 8u/NC0Qbrv3N46a+wrjN6zG8cVLmrU79OueAS4BZZyKI2DNijnOt92Xyi6leyg6AE9gl TRjgtH31u8TTkxGcK5f91C6YGF+6maASXVLojpsjL68wMQ6ZA7ZgqST2R53Nctnr6sAq Q54Ht1/+fjWYilrW8x/HJrrTfa0OIAhQc/Z9TPMc9XqHI3ZBDVNr51ZiF8pHvsC3Xhmf 10WXD5gpg7ZwoiSU0scHV2RPddL29pGWNQw0IOOrwNijkJoWkNcMNmTndnYq50g7rjVk Sr6Q== X-Received: by 10.14.241.74 with SMTP id f50mr4283204eer.29.1383325424871; Fri, 01 Nov 2013 10:03:44 -0700 (PDT) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id a6sm9915271eei.10.2013.11.01.10.03.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 10:03:44 -0700 (PDT) Message-ID: <5273DEEE.4000302@gmail.com> Date: Fri, 01 Nov 2013 18:03:42 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Max Jonas Werner , cowwoc , rtcweb@ietf.org References: <5273D5C8.304@bbs.darktech.org> <5273D848.2060608@makk.es> In-Reply-To: <5273D848.2060608@makk.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: miconda@gmail.com 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, 01 Nov 2013 17:03:47 -0000 On 11/1/13 5:35 PM, Max Jonas Werner wrote: > On 01.11.2013 17:24, cowwoc wrote: >> On 01/11/2013 12:19 PM, Emil Ivov wrote: >>> It would be nice for Mozilla to comment then. They wouldn't have been >>> required to statically link against it or even distribute it. It is >>> already possible to use GPL plug-ins with Firefox, so why is x264 an >>> insurmountable problem? >> Can I dynamically link x264 against my proprietary application without >> having to GPL it? > Actually no: https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL > > That's why the LGPL (that poses other risks, though) exists. GPL constraints about open sourcing are for the case when distributing the application. You can link anything you want with gpl code and you don't have to make the sources available if you don't distribute your application. I think that Emil wanted to say that we, users, don't distribute web browsers, we just use them. Then, if I got it right, no browser will link against the h264 plugin. That will be loaded at user will (eventually), by downloading on demand from cisco site. So I, as user, I take Firefox from Mozilla site, then when I need to do webrtc, my browser will download (first time) and use the h264 plugin. Because I don't distribute further the two, I don't see any restriction from gpl here. That's my understanding. Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28 - more details about Kamailio trainings at http://www.asipto.com - From martin.thomson@gmail.com Fri Nov 1 10:08:25 2013 Return-Path: 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 7064B11E81DB for ; Fri, 1 Nov 2013 10:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, 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 PYJUPFJaXW-o for ; Fri, 1 Nov 2013 10:08:25 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id D0AC411E8210 for ; Fri, 1 Nov 2013 10:08:20 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hn9so1365104wib.17 for ; Fri, 01 Nov 2013 10:08:20 -0700 (PDT) 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=Wat4lx4a9qhL/DO/W7DRgwl+6ZhAqEwMrAMridQDjzE=; b=aG81eK57xeX6BxmydAAgSQAwl71TgMYsJbWENTZUhptx5LAG6iT5SP98kVFtZ7tqpH 5qrgXUP2xJV8QTTTdX9mKhqDrNptJeoixSHZVXTiBLrYVsjd3sfb1MN06np0PVQd2z4J A02U48Ml25+7BzjxDte4D/qib5H/BfsAqWrSqMi53Tik9RxU8W71YZux65tG70gG3y0c MR+iVHpYJbRGsmwnnfqgl+BCYI3fhe04vhm6Tb0Ykc1yoFc24AqRX6RkEEUrlqYDdkPT G+INVuw7cxYfSkrcTXYu0+CdIhYlDC6szncMMapZV5SbhwT0KwcvOED2kJ5shh0xNHA0 LxZg== MIME-Version: 1.0 X-Received: by 10.180.9.139 with SMTP id z11mr3242872wia.22.1383325699979; Fri, 01 Nov 2013 10:08:19 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Fri, 1 Nov 2013 10:08:19 -0700 (PDT) In-Reply-To: <5273DEEE.4000302@gmail.com> References: <5273D5C8.304@bbs.darktech.org> <5273D848.2060608@makk.es> <5273DEEE.4000302@gmail.com> Date: Fri, 1 Nov 2013 10:08:19 -0700 Message-ID: From: Martin Thomson To: miconda@gmail.com Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 17:08:25 -0000 X-List-Received-Date: Fri, 01 Nov 2013 17:08:25 -0000 On 1 November 2013 10:03, Daniel-Constantin Mierla wrote: > So I, as user, I take Firefox from Mozilla site, then when I need to do > webrtc, my browser will download (first time) and use the h264 plugin. > Because I don't distribute further the two, I don't see any restriction from > gpl here. That's my understanding. I think that you should read the GPL again and maybe consult a lawyer. It is my understanding that this would expose the browser to the GPL copyleft terms. p.s., why is my spell checker OK with the non-word "copyleft", but not OK with the acronym "GPL" ... From emcho@sip-communicator.org Fri Nov 1 10:15:55 2013 Return-Path: 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 54BA411E821C for ; Fri, 1 Nov 2013 10:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 h1w8Qw3mC2AL for ; Fri, 1 Nov 2013 10:15:37 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3D50611E8222 for ; Fri, 1 Nov 2013 10:15:36 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so4535205pbc.22 for ; Fri, 01 Nov 2013 10:15:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Lqz29JmHuMOaHc2X5f+XkL43KMZO3klcZToS4JzGYWQ=; b=YO1/LlNQYlk4iCpD6kbuPbS/WF4bX19jwzcGW9PR33ewUOv6GokBSc8E55+C6ARR2J rmaBsZG/pj7dk7Ssim27eYi9fckwQDD5DkNUEvd6Hm+efSB0HxBds7cTc4mtTQX5Y0ey Ms7YAGff1AMJjnJHiQmVCdnDFM/hSwcCI4JkEdU7iGkOW4a338WhVd1mu0DnkP067aeI FpR3iw5Fu699gFuGQuOfBIe9PnuUMCaYsFVtF+w8Kn5pSu1ZNY5z8f2CL7l9uqkkOw7W VD8Yo0sAJGfYQLgHonHt+jccKZtJmWD1hYoYE/KGlirB3OfQlCrH0kQDo1FRgTwYXMhU K0Kw== X-Gm-Message-State: ALoCoQkLQmXVlT3IOatOCgf6F9Mf+rXR7BfVdlZHsQENzATvEQYyDU0zzjtlJ6hk9yIoNg1Do3Rj X-Received: by 10.68.66.33 with SMTP id c1mr4224556pbt.73.1383326136531; Fri, 01 Nov 2013 10:15:36 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [2607:f8b0:400e:c03::22c]) by mx.google.com with ESMTPSA id ho3sm11929006pbb.23.2013.11.01.10.15.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 10:15:36 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb1so4322014pad.31 for ; Fri, 01 Nov 2013 10:15:35 -0700 (PDT) X-Received: by 10.68.59.202 with SMTP id b10mr4283896pbr.78.1383326135846; Fri, 01 Nov 2013 10:15:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Fri, 1 Nov 2013 10:15:15 -0700 (PDT) In-Reply-To: References: <14789922-BEC6-460B-ABB0-092D63237BBF@edvina.net> From: Emil Ivov Date: Fri, 1 Nov 2013 18:15:15 +0100 Message-ID: To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 17:15:55 -0000 On Fri, Nov 1, 2013 at 6:01 PM, Richard Barnes wrote: > IIUC, by providing a BSD implementation, developers will be able to build > the library directly into their apps, if they're willing to accept the > MPEG-LA restrictions. This could be helpful for developers who are willing > to pay the license fees, or who are too small to be required to pay the > license (think I had head 100k users). The BSD licensed implementation > means that those developers don't have to either (1) bother with the Cisco > song and dance or (2) worry about GPL restrictions. True, but both (1) and (2) would be possible with x264. What you gain with the BSD license is the possibility to distribute it yourself with non-GPL compatible code, in which case however you lose the Cisco grant on the patent anyway. Emil -- https://jitsi.org From rlb@ipv.sx Fri Nov 1 10:18:43 2013 Return-Path: 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 2DD8E11E822C for ; Fri, 1 Nov 2013 10:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ND8lvn0scLxA for ; Fri, 1 Nov 2013 10:18:38 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id C2E0211E8210 for ; Fri, 1 Nov 2013 10:18:38 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wn1so4861541obc.27 for ; Fri, 01 Nov 2013 10:18:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=H2KljPauRp+EFdmCc3Ufs+qIRD90PFVtu0fsRkmz6fc=; b=Q2IWUdb823sEW5Zh7B+gGEnMb9u21Po1j/rEViP0O3I3cj+44LaL9hYmR7EGJ6nOiW lbc5ZHT5vHMbUrUs2xfMfAVylibTajYYd2iVB25+okdHFrU+29drPzrXhPcCDsCSzpXt hKuUjrukcoxNMRRfkLMD5faNolVYilB9Bm8l6YUT8cdggqIT9CFcUKAJjheiSE4vm0JM 7JYrfWwuLTS86CfsbedXWezmNSeqC7qLeOjfw45W06WU01CXS2WMCj/MFk/2jiAdmNv0 W7Z45oAn84jKCxCcgGbh18ODWs2Q8o4JmWpLb8Zt1qzY4970PNPJkDWOT2UX6abY2onk 8wbg== X-Gm-Message-State: ALoCoQkkRzW09xOTLC9UzgbrlgDrUUiUJBHZjSTu8KMsSdk5NXih8bclmVlpLI2qXr/4Yc86wvcy MIME-Version: 1.0 X-Received: by 10.60.157.2 with SMTP id wi2mr3402164oeb.35.1383326317965; Fri, 01 Nov 2013 10:18:37 -0700 (PDT) Received: by 10.76.101.10 with HTTP; Fri, 1 Nov 2013 10:18:37 -0700 (PDT) In-Reply-To: References: <14789922-BEC6-460B-ABB0-092D63237BBF@edvina.net> Date: Fri, 1 Nov 2013 13:18:37 -0400 Message-ID: From: Richard Barnes To: Emil Ivov Content-Type: multipart/alternative; boundary=089e011830f4ca8a8904ea20c10e Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 17:18:43 -0000 --089e011830f4ca8a8904ea20c10e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 1, 2013 at 1:15 PM, Emil Ivov wrote: > On Fri, Nov 1, 2013 at 6:01 PM, Richard Barnes wrote: > > IIUC, by providing a BSD implementation, developers will be able to build > > the library directly into their apps, if they're willing to accept the > > MPEG-LA restrictions. This could be helpful for developers who are > willing > > to pay the license fees, or who are too small to be required to pay the > > license (think I had head 100k users). The BSD licensed implementation > > means that those developers don't have to either (1) bother with the > Cisco > > song and dance or (2) worry about GPL restrictions. > > True, but both (1) and (2) would be possible with x264. What you gain > with the BSD license is the possibility to distribute it yourself with > non-GPL compatible code, in which case however you lose the Cisco > grant on the patent anyway. > Yes. There are two, orthogonal benefits of the Cisco proposal: 1. Save on coding: Source code you can use in any way (even GPL-incompatible), but you have to pay 2. Save on licenses: Binary code you can use in download-from-Cisco pattern, and Cisco pays > > Emil > > -- > https://jitsi.org > --089e011830f4ca8a8904ea20c10e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 1, 2013 at 1:15 PM, Emil Ivov <emcho@jitsi.org> wrote:=
On Fri, Nov 1, 2013 at 6:01 PM, Richard Barnes <rlb@ip= v.sx> wrote:
> IIUC, by providing a BSD implementation, developers will be able to bu= ild
> the library directly into their apps, if they're willing to accept= the
> MPEG-LA restrictions. =A0This could be helpful for developers who are = willing
> to pay the license fees, or who are too small to be required to pay th= e
> license (think I had head 100k users). =A0The BSD licensed implementat= ion
> means that those developers don't have to either (1) bother with t= he Cisco
> song and dance or (2) worry about GPL restrictions.

True, but both (1) and (2) would be possible with x264. What you gain=
with the BSD license is the possibility to distribute it yourself with
non-GPL compatible code, in which case however you lose the Cisco
grant on the patent anyway.

Yes.=A0 The= re are two, orthogonal benefits of the Cisco proposal:
1. Sav= e on coding: Source code you can use in any way (even GPL-incompatible), bu= t you have to pay
2. Save on licenses: Binary code you can use in download-from-Ci= sco pattern, and Cisco pays

=A0

Emil

--
https://jitsi.org

--089e011830f4ca8a8904ea20c10e-- From emcho@sip-communicator.org Fri Nov 1 10:19:11 2013 Return-Path: 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 B74F511E8237 for ; Fri, 1 Nov 2013 10:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.755 X-Spam-Level: X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 tSPqI3HAUvrC for ; Fri, 1 Nov 2013 10:19:07 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0421711E8233 for ; Fri, 1 Nov 2013 10:19:05 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id kp14so4332505pab.15 for ; Fri, 01 Nov 2013 10:19:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XjdGxGlSbg64midGsvWAA1l98r1zncxvlVYqNp+h0Yk=; b=OaWeB8yY5vKq8rUM8dy4gBNHOtePV9nODoULGNrj1ZkcpTNBl/HMOB5a8mhTvJ1Aw5 tOXf8FDGid0gAwpAAwPLPicxCTH/bGd1W2Hhg5W4IfwRkOGt7crbwqsWmeWsKqyg/we0 9HAGuQsaPHUYQqJeHoCHGw8lzoU+M39/B60JCh0wrQAaJCKzZogXefS1nWhgMOh72rzs sOVwex6nSDBlLmhMcjzb/Lq1KJe4hQe3xgfgJF+BT7062WX4lRjs2Ppia37TUkBS7wk2 UapL3iEihSJZZ+qB9NDYYCbO3tu3NAgdDOViwMGA2rCPvPt/xzedtMrIy1VGkO2+L/B4 WNkQ== X-Gm-Message-State: ALoCoQlootj4Ey4gVKSXxw7zIASSV7T0M/DLw9AUx6JqAqnV4PSH+IhHmPy5V/6MFRyUl3yajAVd X-Received: by 10.67.4.227 with SMTP id ch3mr4306161pad.74.1383326344786; Fri, 01 Nov 2013 10:19:04 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [2607:f8b0:400e:c01::22e]) by mx.google.com with ESMTPSA id xv2sm11938704pbb.39.2013.11.01.10.19.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 10:19:04 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id un4so4559848pbc.19 for ; Fri, 01 Nov 2013 10:19:04 -0700 (PDT) X-Received: by 10.68.189.229 with SMTP id gl5mr2479825pbc.195.1383326344325; Fri, 01 Nov 2013 10:19:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Fri, 1 Nov 2013 10:18:44 -0700 (PDT) In-Reply-To: References: <5273D5C8.304@bbs.darktech.org> <5273D848.2060608@makk.es> <5273DEEE.4000302@gmail.com> From: Emil Ivov Date: Fri, 1 Nov 2013 18:18:44 +0100 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 17:19:11 -0000 On Fri, Nov 1, 2013 at 6:08 PM, Martin Thomson wrote: > On 1 November 2013 10:03, Daniel-Constantin Mierla wrote: >> So I, as user, I take Firefox from Mozilla site, then when I need to do >> webrtc, my browser will download (first time) and use the h264 plugin. >> Because I don't distribute further the two, I don't see any restriction from >> gpl here. That's my understanding. > > I think that you should read the GPL again and maybe consult a lawyer. We may both need to do this but that doesn't mean we can't have a (supposedly) informed opinion without consulting ;) > It is my understanding that this would expose the browser to the GPL > copyleft terms. It is my understanding that this would have happened if they were to distribute x264 together with the browser, which is not the case here. There are already a number of Firefox plugins out there that are distributed under GPL. Surely you are not saying that FF could somehow get in trouble for being able to run those? Emil -- https://jitsi.org From oej@edvina.net Fri Nov 1 10:21:37 2013 Return-Path: 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 92A6911E8210 for ; Fri, 1 Nov 2013 10:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] 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 sGm2qp0qJS5r for ; Fri, 1 Nov 2013 10:21:36 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 673D511E8174 for ; Fri, 1 Nov 2013 10:21:35 -0700 (PDT) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E571993C2A2; Fri, 1 Nov 2013 17:21:34 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: "Olle E. Johansson" In-Reply-To: <5273DEEE.4000302@gmail.com> Date: Fri, 1 Nov 2013 18:21:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05B9F53B-BEB8-45C8-A9B2-E09E72D1CA0E@edvina.net> References: <5273D5C8.304@bbs.darktech.org> <5273D848.2060608@makk.es> <5273DEEE.4000302@gmail.com> To: Daniel Constantin Mierla X-Mailer: Apple Mail (2.1816) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 17:21:37 -0000 On 01 Nov 2013, at 18:03, Daniel-Constantin Mierla = wrote: >=20 > On 11/1/13 5:35 PM, Max Jonas Werner wrote: >> On 01.11.2013 17:24, cowwoc wrote: >>> On 01/11/2013 12:19 PM, Emil Ivov wrote: >>>> It would be nice for Mozilla to comment then. They wouldn't have = been >>>> required to statically link against it or even distribute it. It is >>>> already possible to use GPL plug-ins with Firefox, so why is x264 = an >>>> insurmountable problem? >>> Can I dynamically link x264 against my proprietary application = without >>> having to GPL it? >> Actually no: https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL >>=20 >> That's why the LGPL (that poses other risks, though) exists. > GPL constraints about open sourcing are for the case when distributing = the application. You can link anything you want with gpl code and you = don't have to make the sources available if you don't distribute your = application. >=20 > I think that Emil wanted to say that we, users, don't distribute web = browsers, we just use them. >=20 > Then, if I got it right, no browser will link against the h264 plugin. = That will be loaded at user will (eventually), by downloading on demand = from cisco site. >=20 > So I, as user, I take Firefox from Mozilla site, then when I need to = do webrtc, my browser will download (first time) and use the h264 = plugin. Because I don't distribute further the two, I don't see any = restriction from gpl here. That's my understanding. I don't think GPL agrees with that. GPL applies at runtime, not only = when building the app. THe FAQ on the link above says "Linking ABC statically or dynamically with other modules is making a = combined work based on ABC. Thus, the terms and conditions of the GNU = General Public License cover the whole combination." "If the program dynamically links plug-ins, and they make function calls = to each other and share data structures, we believe they form a single = program, which must be treated as an extension of both the main program = and the plug-ins. This means the plug-ins must be released under the GPL = or a GPL-compatible free software license, and that the terms of the GPL = must be followed when those plug-ins are distributed. If the program dynamically links plug-ins, but the communication between = them is limited to invoking the =91main=92 function of the plug-in with = some options and waiting for it to return, that is a borderline case." /O= From lorenzo@meetecho.com Fri Nov 1 10:28:42 2013 Return-Path: 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 4523111E8229 for ; Fri, 1 Nov 2013 10:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 BK09WeCLIBCP for ; Fri, 1 Nov 2013 10:28:36 -0700 (PDT) Received: from smtpdb6.aruba.it (smtpdb6.aruba.it [62.149.158.248]) by ietfa.amsl.com (Postfix) with ESMTP id 4289511E8210 for ; Fri, 1 Nov 2013 10:28:34 -0700 (PDT) Received: from lminiero ([82.49.174.20]) by smtpcmd02.ad.aruba.it with bizsmtp id kHUW1m00X0SmHqA01HUWnU; Fri, 01 Nov 2013 18:28:32 +0100 Date: Fri, 1 Nov 2013 18:28:27 +0100 From: Lorenzo Miniero To: Emil Ivov Message-ID: <20131101182827.52f1a0c1@lminiero> In-Reply-To: References: Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 17:28:42 -0000 Il giorno Fri, 1 Nov 2013 17:19:25 +0100 Emil Ivov ha scritto: > On Fri, Nov 1, 2013 at 4:56 PM, Cullen Jennings wrote: > > > > On Nov 1, 2013, at 9:14 AM, Emil Ivov wrote: > > > >> On Fri, Nov 1, 2013 at 3:27 PM, DRAGE, Keith (Keith) > >> wrote: > >>> > >>> That ownership means they are also take responsibility for any of > >>> the liabilities arising from defective code they so distribute. I > >>> see no reason why Cisco would want to do that under anything but > >>> a controlled evironment, which would have its own set of > >>> non-trivial costs. > >> > >> They could have the same by distributing x264 binaries that they > >> have compiled by themselves. > >> > >> One of the things in the Cisco grand, that sound a bit incoherent > >> to me is their declared will on building a healthy open source > >> community around their implementation. Specifically, what baffles > >> me is that there is already a very well oiled implementation that > >> does a lot more than just baseline. That implementation already > >> has a vibrant community, significant popularity and, again, it > >> sounds like it would be considerably superior to what Cisco are > >> planning on rolling out in OpenH264. > >> > >> In addition to wondering at the pure waste of resources (with a > >> casual reference to NIH), potential contributors could > >> legitimately ask "why would we contribute to your project when you > >> made the exact opposite choice when faced with the decision?". > >> > >> Emil > > > > We considered just using x264 (I like x264 myself) that but Mozilla > > told us it would not work for them because it is GPL. > > It would be nice for Mozilla to comment then. They wouldn't have been > required to statically link against it or even distribute it. It is > already possible to use GPL plug-ins with Firefox, so why is x264 an > insurmountable problem? > > Emil > Maybe because it is already available and compared. Announcements and claims work much better when you don't have to actually show anything. Lorenzo From lorenzo@meetecho.com Fri Nov 1 10:29:18 2013 Return-Path: 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 7284621E80FB for ; Fri, 1 Nov 2013 10:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 o5DqvGkXtDvj for ; Fri, 1 Nov 2013 10:29:14 -0700 (PDT) Received: from smtpdg6.aruba.it (smtpdg2.aruba.it [62.149.158.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0346011E8210 for ; Fri, 1 Nov 2013 10:29:11 -0700 (PDT) Received: from rainpc ([82.49.174.20]) by smtpcmd02.ad.aruba.it with bizsmtp id kHV81m00y0SmHqA01HV9DQ; Fri, 01 Nov 2013 18:29:10 +0100 Date: Fri, 1 Nov 2013 18:29:08 +0100 From: Lorenzo Miniero To: Richard Barnes Message-ID: <20131101182908.409c2a62@rainpc> In-Reply-To: References: <14789922-BEC6-460B-ABB0-092D63237BBF@edvina.net> Organization: Meetecho X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 17:29:18 -0000 On Fri, 1 Nov 2013 13:18:37 -0400 Richard Barnes wrote: > On Fri, Nov 1, 2013 at 1:15 PM, Emil Ivov wrote: > > > On Fri, Nov 1, 2013 at 6:01 PM, Richard Barnes wrote: > > > IIUC, by providing a BSD implementation, developers will be able to build > > > the library directly into their apps, if they're willing to accept the > > > MPEG-LA restrictions. This could be helpful for developers who are > > willing > > > to pay the license fees, or who are too small to be required to pay the > > > license (think I had head 100k users). The BSD licensed implementation > > > means that those developers don't have to either (1) bother with the > > Cisco > > > song and dance or (2) worry about GPL restrictions. > > > > True, but both (1) and (2) would be possible with x264. What you gain > > with the BSD license is the possibility to distribute it yourself with > > non-GPL compatible code, in which case however you lose the Cisco > > grant on the patent anyway. > > > > Yes. There are two, orthogonal benefits of the Cisco proposal: > 1. Save on coding: Source code you can use in any way (even > GPL-incompatible), but you have to pay > 2. Save on licenses: Binary code you can use in download-from-Cisco > pattern, and Cisco pays > How is 1. a benefit exactly? I can already do that with other codecs for free. Lorenzo > > > > > > Emil > > > > -- > > https://jitsi.org > > -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From rlb@ipv.sx Fri Nov 1 10:35:52 2013 Return-Path: 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 136BF11E818D for ; Fri, 1 Nov 2013 10:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 FGWiER+Gylml for ; Fri, 1 Nov 2013 10:35:48 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6236711E81A4 for ; Fri, 1 Nov 2013 10:35:44 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wn1so4829687obc.2 for ; Fri, 01 Nov 2013 10:35:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yCQTJRRhKMV73yKhzFpehgFdwcjpb5ZqAwbh1NXFsdU=; b=X+0is2tXQTUK9Nk8dP8K0ThgeWwNO9hI1jBJ4N1IKSzByvPuG01h07vqEbZ/YDfRqV czRXNKnSZJJse/xiBKLMGem8GdStZKLnMaMp3HMp6wPyOpsKzElgMGlQdf6xiTvhGTxx SN9+HI2RLh6T1TX8IXjbGZ5pWh9a/umn1VyEuuDNwu/1sps1beBBe9e4/8C079OsJ9Kp HRe7gVGoNW8e1MfP83hqdQR1zbcf1vnWLgasp0mvyTqvO1lVf09zaiiV8qWDY0ryMf+G mlxEtr82jftXCE2stB70nbP7d3NEfn3Ggk2bYlj8kQ9duE0+/5KuJ0bHlgvorEjPjK/3 J+LA== X-Gm-Message-State: ALoCoQmQgb8j6dZT0IwIzYEudHQI3VKno5GqD2oIUN+ouH72x+6CAPWwBduWGMWfhePzr6ZuK/CJ MIME-Version: 1.0 X-Received: by 10.60.44.36 with SMTP id b4mr3444175oem.53.1383327038532; Fri, 01 Nov 2013 10:30:38 -0700 (PDT) Received: by 10.76.101.10 with HTTP; Fri, 1 Nov 2013 10:30:38 -0700 (PDT) In-Reply-To: <20131101182908.409c2a62@rainpc> References: <14789922-BEC6-460B-ABB0-092D63237BBF@edvina.net> <20131101182908.409c2a62@rainpc> Date: Fri, 1 Nov 2013 13:30:38 -0400 Message-ID: From: Richard Barnes To: Lorenzo Miniero Content-Type: multipart/alternative; boundary=001a11c30186bd82cb04ea20ecec Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 17:35:52 -0000 --001a11c30186bd82cb04ea20ecec Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 1, 2013 at 1:29 PM, Lorenzo Miniero wrote: > On Fri, 1 Nov 2013 13:18:37 -0400 > Richard Barnes wrote: > > > On Fri, Nov 1, 2013 at 1:15 PM, Emil Ivov wrote: > > > > > On Fri, Nov 1, 2013 at 6:01 PM, Richard Barnes wrote: > > > > IIUC, by providing a BSD implementation, developers will be able to > build > > > > the library directly into their apps, if they're willing to accept > the > > > > MPEG-LA restrictions. This could be helpful for developers who are > > > willing > > > > to pay the license fees, or who are too small to be required to pay > the > > > > license (think I had head 100k users). The BSD licensed > implementation > > > > means that those developers don't have to either (1) bother with the > > > Cisco > > > > song and dance or (2) worry about GPL restrictions. > > > > > > True, but both (1) and (2) would be possible with x264. What you gain > > > with the BSD license is the possibility to distribute it yourself with > > > non-GPL compatible code, in which case however you lose the Cisco > > > grant on the patent anyway. > > > > > > > Yes. There are two, orthogonal benefits of the Cisco proposal: > > 1. Save on coding: Source code you can use in any way (even > > GPL-incompatible), but you have to pay > > 2. Save on licenses: Binary code you can use in download-from-Cisco > > pattern, and Cisco pays > > > > > How is 1. a benefit exactly? I can already do that with other codecs for > free. > Meant it was a benefit relative to the prior state for H.264, since x264 is GPL (don't know if there are others). --Richard > Lorenzo > > > > > > > > > > > > Emil > > > > > > -- > > > https://jitsi.org > > > > > > -- > Lorenzo Miniero, COB > > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com > --001a11c30186bd82cb04ea20ecec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 1, 2013 at 1:29 PM, Lorenzo Miniero <lorenzo@meetecho.com= > wrote:
On F= ri, 1 Nov 2013 13:18:37 -0400
Richard Barnes <rlb@ipv.sx> wrote:

> On Fri, Nov 1, 2013 at 1:15 PM, Emil Ivov <emcho@jitsi.org> wrote:
>
> > On Fri, Nov 1, 2013 at 6:01 PM, Richard Barnes <rlb@ipv.sx>= wrote:
> > > IIUC, by providing a BSD implementation, developers will be = able to build
> > > the library directly into their apps, if they're willing= to accept the
> > > MPEG-LA restrictions. =A0This could be helpful for developer= s who are
> > willing
> > > to pay the license fees, or who are too small to be required= to pay the
> > > license (think I had head 100k users). =A0The BSD licensed i= mplementation
> > > means that those developers don't have to either (1) bot= her with the
> > Cisco
> > > song and dance or (2) worry about GPL restrictions.
> >
> > True, but both (1) and (2) would be possible with x264. What you = gain
> > with the BSD license is the possibility to distribute it yourself= with
> > non-GPL compatible code, in which case however you lose the Cisco=
> > grant on the patent anyway.
> >
>
> Yes. =A0There are two, orthogonal benefits of the Cisco proposal:
> 1. Save on coding: Source code you can use in any way (even
> GPL-incompatible), but you have to pay
> 2. Save on licenses: Binary code you can use in download-from-Cisco > pattern, and Cisco pays
>


How is 1. a benefit exactly? I can already do that with other c= odecs for free.

Meant it was a benefit = relative to the prior state for H.264, since x264 is GPL (don't know if= there are others).=A0

--Richard

=A0
Lorenzo


>
>
> >
> > Emil
> >
> > --
> > https://jitsi.org=
> >


--
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.c= om

--001a11c30186bd82cb04ea20ecec-- From miconda@gmail.com Fri Nov 1 10:39:02 2013 Return-Path: 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 02A8F11E80DE for ; Fri, 1 Nov 2013 10:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] 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 WqAtfUNSBau8 for ; Fri, 1 Nov 2013 10:39:01 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 91FA511E8174 for ; Fri, 1 Nov 2013 10:38:59 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b45so2662902eek.29 for ; Fri, 01 Nov 2013 10:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PvvGhy6xTayc7vMArhi2gxceL7OGxM+rlM4/oYkBnsw=; b=ovJ8QXpWF5C7FwZWbGxM0GeNQh3Gqsk2XrklzJFRWtAM5+NMMaKT/MQ1++RiLkWZ64 D88Bj7ybPY6uvhFhKJfRafZbOXyJj1LVjPdCjVCMvN9L659vMQHcN9zopRP0ffNFMUp3 hgAQ29/BUMChovTjB4wvRXSZhcrAJ0mWu1mCl5588bzTc1monrZnV9vQgi+OmZ0atpqT MNtmGf78VuGcQpHUlpXe/yxzJockr+FwJ2goWpje5cudEKOtEWb2a0fReSGoUg+zEOMm O99PqFpZrrXQcdJL3LqaGaH5jsQHbgtZM8UrWm+Bk4viPKIigm2C2xJuFGMrC2le67Hj QrZw== X-Received: by 10.14.180.73 with SMTP id i49mr4383644eem.55.1383327538621; Fri, 01 Nov 2013 10:38:58 -0700 (PDT) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id i1sm10329612eeg.0.2013.11.01.10.38.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 10:38:57 -0700 (PDT) Message-ID: <5273E730.2090802@gmail.com> Date: Fri, 01 Nov 2013 18:38:56 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <5273D5C8.304@bbs.darktech.org> <5273D848.2060608@makk.es> <5273DEEE.4000302@gmail.com> <05B9F53B-BEB8-45C8-A9B2-E09E72D1CA0E@edvina.net> In-Reply-To: <05B9F53B-BEB8-45C8-A9B2-E09E72D1CA0E@edvina.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: miconda@gmail.com 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, 01 Nov 2013 17:39:02 -0000 On 11/1/13 6:21 PM, Olle E. Johansson wrote: > On 01 Nov 2013, at 18:03, Daniel-Constantin Mierla wrote: > >> On 11/1/13 5:35 PM, Max Jonas Werner wrote: >>> On 01.11.2013 17:24, cowwoc wrote: >>>> On 01/11/2013 12:19 PM, Emil Ivov wrote: >>>>> It would be nice for Mozilla to comment then. They wouldn't have been >>>>> required to statically link against it or even distribute it. It is >>>>> already possible to use GPL plug-ins with Firefox, so why is x264 an >>>>> insurmountable problem? >>>> Can I dynamically link x264 against my proprietary application without >>>> having to GPL it? >>> Actually no: https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL >>> >>> That's why the LGPL (that poses other risks, though) exists. >> GPL constraints about open sourcing are for the case when distributing the application. You can link anything you want with gpl code and you don't have to make the sources available if you don't distribute your application. >> >> I think that Emil wanted to say that we, users, don't distribute web browsers, we just use them. >> >> Then, if I got it right, no browser will link against the h264 plugin. That will be loaded at user will (eventually), by downloading on demand from cisco site. >> >> So I, as user, I take Firefox from Mozilla site, then when I need to do webrtc, my browser will download (first time) and use the h264 plugin. Because I don't distribute further the two, I don't see any restriction from gpl here. That's my understanding. > I don't think GPL agrees with that. GPL applies at runtime, not only when building the app. THe FAQ on the link above says > > "Linking ABC statically or dynamically with other modules is making a combined work based on ABC. Thus, the terms and conditions of the GNU General Public License cover the whole combination." > > "If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed. Again, the key term here is distribution. I, as user, I don't distribute them. Mozilla, as developer, doesn't link against h264 plugin nor distributes it. Same with cisco, they don't link h264 plugin against firefox, nor distribute firefox. Now, I, as a user, mix the two, which may result in a combination that has to be gpl (if plugin or browser is gpl), but only in my house. So, as long as I keep it here, don't give the two combined away, no GPL can be enforced. I agree a specialized lawyer can be more accurate and my understanding of GPL might not be the best one. But if it is what you say, I have a dozen a folks I know they have private modules for Kamailio, Asterisk and other GPL project. We will have lots of features in the next releases if we can force them to publish their extensions though GPL :-) Daniel > > If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case." > > /O -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28 - more details about Kamailio trainings at http://www.asipto.com - From martin.thomson@gmail.com Fri Nov 1 10:53:42 2013 Return-Path: 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 50C7011E8230 for ; Fri, 1 Nov 2013 10:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, 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 vSELpohhuQQT for ; Fri, 1 Nov 2013 10:53:42 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AB2BB11E8221 for ; Fri, 1 Nov 2013 10:53:41 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hm4so1435924wib.8 for ; Fri, 01 Nov 2013 10:53:40 -0700 (PDT) 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=49IgcPMU84vLKz8FG+7OaVD4RGqmcViy+SEPjXRCm7o=; b=qjh4AIdXqCS1NNDDanxD5KLJt8w+F2h7elZzK/pj6zYcDxXEXXlHxYGoE96wJZi210 oLCPnrBQB1BHqta6oQsy84DzVEyvSun9XfwOgHZYNh75i7gm/z7DAXnXekOa3ou00LL6 sgGK99m2b5hc6CBdWbfg1kx9yHQVj6MEVS9w99Ze5VkS4mmn6tF5neYKQuM4cdNpmvFV YSlycIyGFXlq2BaK6JdyVHliN1GYFVXE3NA5pxNl+gNhiZsbO5wwis8iv5tklhcNIwtF ldjgU3rzOM4E3e9ZhO0+ArVvhRbA8h4gUBxs8ORRy6fCytlMTTZ9dY0EuVOkhBnW9OJs 7+iQ== MIME-Version: 1.0 X-Received: by 10.180.109.75 with SMTP id hq11mr3162738wib.30.1383328420842; Fri, 01 Nov 2013 10:53:40 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Fri, 1 Nov 2013 10:53:40 -0700 (PDT) In-Reply-To: References: <5273D5C8.304@bbs.darktech.org> <5273D848.2060608@makk.es> <5273DEEE.4000302@gmail.com> Date: Fri, 1 Nov 2013 10:53:40 -0700 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs) X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 17:53:42 -0000 On 1 November 2013 10:18, Emil Ivov wrote: > > There are already a number of Firefox plugins out there that are > distributed under GPL. Surely you are not saying that FF could somehow > get in trouble for being able to run those? I think that the only rational response is this: IANAL More to the point: IANAJ. From tterriberry@mozilla.com Fri Nov 1 12:03:05 2013 Return-Path: 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 272D821E80B2 for ; Fri, 1 Nov 2013 12:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] 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 qFCChA+p5pR6 for ; Fri, 1 Nov 2013 12:02:59 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5D13B21E805D for ; Fri, 1 Nov 2013 12:02:59 -0700 (PDT) Received: from [172.31.234.214] (unknown [216.9.110.12]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 8AA26F20DA for ; Fri, 1 Nov 2013 12:02:58 -0700 (PDT) Message-ID: <5273FAE0.7000707@mozilla.com> Date: Fri, 01 Nov 2013 12:02:56 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 19:03:05 -0000 Harald Alvestrand wrote: > Google still believes that VP8 - a freely available, fully open, > high-quality video codec that you can download, compile for your > platform, include in your binary, distribute and put into production > today - is the best choice of a Mandatory to Implement video codec for > the WebRTC effort. +1 From adam@nostrum.com Fri Nov 1 12:44:06 2013 Return-Path: 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 B2F3A11E817A for ; Fri, 1 Nov 2013 12:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 2ZisfZ4h0SjJ for ; Fri, 1 Nov 2013 12:44:06 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF2711E8146 for ; Fri, 1 Nov 2013 12:44:02 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA1Jhvra081479 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 1 Nov 2013 14:43:58 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <52740478.6030109@nostrum.com> Date: Fri, 01 Nov 2013 14:43:52 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Harald Alvestrand , "rtcweb@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050209070102030801040605" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 19:44:06 -0000 This is a multi-part message in MIME format. --------------050209070102030801040605 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/31/13 13:47, Harald Alvestrand wrote: > > We congratulate Cisco on their intention to make an open source H.264 > codec available and usable by the community. We look forward to seeing > the result of this effort. > > > Google still believes that VP8 - a freely available, fully open, > high-quality video codec that you can download, compile for your > platform, include in your binary, distribute and put into production > today - is the best choice of a Mandatory to Implement video codec for > the WebRTC effort. > I agree with Harald that VP8 is a better codec than H.264 baseline in a number of important ways. But I also want to reiterate that having an MTI codec has never been about choosing the best codec or even a good codec. It's about choosing an emergency backup codec-of-last-resort. It's about having one single mandated codec that everyone has in their back pocket in case nothing else works. The core of RTCWEB is about session *negotiation*. Endpoints will negotiate the best codec they have in common. Once the next generation of codecs come out, this "best codec in common" will only be the MTI if they were about to fail anyway. So it doesn't have to be good. It just has to be better than failure. /a --------------050209070102030801040605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 10/31/13 13:47, Harald Alvestrand wrote:

We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.


Google still believes that VP8 - a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today - is the best choice of a Mandatory to Implement video codec for the WebRTC effort.


I agree with Harald that VP8 is a better codec than H.264 baseline in a number of important ways.

But I also want to reiterate that having an MTI codec has never been about choosing the best codec or even a good codec. It's about choosing an emergency backup codec-of-last-resort. It's about having one single mandated codec that everyone has in their back pocket in case nothing else works.

The core of RTCWEB is about session *negotiation*. Endpoints will negotiate the best codec they have in common. Once the next generation of codecs come out, this "best codec in common" will only be the MTI if they were about to fail anyway.

So it doesn't have to be good.

It just has to be better than failure.

/a
--------------050209070102030801040605-- From fester05@gmail.com Fri Nov 1 12:56:51 2013 Return-Path: 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 2689D11E818B for ; Fri, 1 Nov 2013 12:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 pzsvct83PIFy for ; Fri, 1 Nov 2013 12:56:50 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 725F621E80F1 for ; Fri, 1 Nov 2013 12:56:39 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wn1so4999286obc.2 for ; Fri, 01 Nov 2013 12:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=PPKjjLKtiEsX+he+TORtbR+A1AVpQK2W78GfLanM8ZA=; b=r0VukHpCQzZbFT8M+xXc7VStgp5Mf6GTB3tALjByvaCKfrWP/0MowEWVyy2sunBHLv seuIzr45jCymBZSGCq9ij0NRg9nhdNMau3/DazG7GHDTa4NdKuEbSfcc1iqPBRwNZut5 TzJBYyOpXi7DXAebtneQf9BFnWTzkZs8jIPmGqjd/2SovoyjBXkeyqcDcvRV1C3cQhyI aJQwx5NjeiYPgZOyczC/E0+D+8aQpXKmFll96qu9tkhC82ibVYnt1EYbgzwMBruulNYv JlE6Ju46egNzPVzl8I90GTnDqfRNZKfsLbFPGEqd0dnOROsSyBs/z2lS6ElW5PNHOCZo jfEQ== X-Received: by 10.182.237.75 with SMTP id va11mr3907427obc.5.1383335797990; Fri, 01 Nov 2013 12:56:37 -0700 (PDT) Received: from rcdn-dgeistke-8914.cisco.com (72-163-0-129.cisco.com. [72.163.0.129]) by mx.google.com with ESMTPSA id rl1sm18945220oeb.7.2013.11.01.12.56.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 12:56:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Doug Geistkemper In-Reply-To: <5273FAE0.7000707@mozilla.com> Date: Fri, 1 Nov 2013 14:56:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0F11E3C8-ED0F-4684-A806-09AC86D592D1@gmail.com> References: <5273FAE0.7000707@mozilla.com> To: "Timothy B. Terriberry" , rtcweb@ietf.org X-Mailer: Apple Mail (2.1510) Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 19:56:51 -0000 -1 On Nov 1, 2013, at 2:02 PM, Timothy B. Terriberry = wrote: > Harald Alvestrand wrote: >> Google still believes that VP8 - a freely available, fully open, >> high-quality video codec that you can download, compile for your >> platform, include in your binary, distribute and put into production >> today - is the best choice of a Mandatory to Implement video codec = for >> the WebRTC effort. >=20 > +1 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Fri Nov 1 13:14:21 2013 Return-Path: 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 D243D21E80E1 for ; Fri, 1 Nov 2013 13:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 J7A7QUQNukqd for ; Fri, 1 Nov 2013 13:14:21 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 16E3D21E80B7 for ; Fri, 1 Nov 2013 13:14:21 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id oy12so4756veb.29 for ; Fri, 01 Nov 2013 13:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dJpGZ6ql4aSS2K4eFZfxC5ggKhmeSeV/V2OkDYVrHpE=; b=H7HOIkPxaqCDamH1rvc4jYX7+W0Odn4b1CWnSSMYkLYPTNwUb2HZ/DdWAgEDD9raHD +XSJqapnaqowgDJn6juS9KGwtpqZepLGfi2cgMZcgQeqstorcAyRWUc8Slu6WR5Pq17F DjxCgiivbk5tlueKvx/Q+Xhd7kECgj6Am60iUDrvaIsZkT151h4ImH0GYJqKPfF07vZb nsdWysdJGnUyD0SXE1iETGezCwx+WmfOrJQqRql59gZd0BYUfX6YjsVJ/FFjvuaWLAct 9vj7MrTEhBgQU+f47m71IClm9porTiLwwZEYw1hnB35gkAVvnmHtj7BDTALdeQDmrwnQ cl5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dJpGZ6ql4aSS2K4eFZfxC5ggKhmeSeV/V2OkDYVrHpE=; b=ACJSqd1BfqZDuj4uiYzfiRMSPOxZ5A2P0fa/VdZCTqwysdAwG5nB+8s0fySRvwVCX4 epeoQEtb/xbiiivDqGJOEDQ6rNLaDK1B5JktT7GTIcXCqAeHzjUFwIzlugQ9TCtlYyRK rJTXiKNNvhOB6c7wQbjrEPPfufKaGt3/E0jn9OkHG4i9KEVjZCZwao62VI1XTulenszj rBWzoG3OSEQjs9TrrykBlmYL8rfz5UmlJMTLwb9IcHutQ5b7DL+tUkp+faX4uTJePNFM nxaptvuNn6EKxpi6NV/r78GKMOelFPhC9HrsXuZoj2XUkp5QgfkNIT4AcE4zCiaD1n1d Hwjg== X-Gm-Message-State: ALoCoQlRmo5Mr2QTOOLvpCR0SxtDENO5poLl1C/ocdej/pgPxMaqj/TIACZc/2j6ZXCmCSABi4Gj69Td+BaEr13RQTNJJ8upTuqingEgxfF+J01eNjisCftO21eM9o8wy6pyvI3+MmoSwe2BVg0j2V7KEz0P/5tcks2h/TGt5COQvFJ96P9m57cwDMA57MAD5RAvXIwYZ/yG X-Received: by 10.52.52.137 with SMTP id t9mr2643910vdo.22.1383336860522; Fri, 01 Nov 2013 13:14:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Fri, 1 Nov 2013 13:13:59 -0700 (PDT) In-Reply-To: <52740478.6030109@nostrum.com> References: <52740478.6030109@nostrum.com> From: Justin Uberti Date: Fri, 1 Nov 2013 13:13:59 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=089e0122f65e2d458304ea2336a2 Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 20:14:21 -0000 --089e0122f65e2d458304ea2336a2 Content-Type: text/plain; charset=UTF-8 I also want to reiterate that having a MTI codec means Mandatory To Implement. That means, that should we decide to go down the H.264 path, Firefox and others will be forced to support this Rube Goldberg machine for obtaining H.264 for an indeterminate amount of time, long after WebRTC has moved on to prefer other codecs. On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach wrote: > On 10/31/13 13:47, Harald Alvestrand wrote: > > We congratulate Cisco on their intention to make an open source H.264 > codec available and usable by the community. We look forward to seeing the > result of this effort. > > Google still believes that VP8 - a freely available, fully open, > high-quality video codec that you can download, compile for your platform, > include in your binary, distribute and put into production today - is the > best choice of a Mandatory to Implement video codec for the WebRTC effort. > > > I agree with Harald that VP8 is a better codec than H.264 baseline in a > number of important ways. > > But I also want to reiterate that having an MTI codec has never been about > choosing the best codec or even a good codec. It's about choosing an > emergency backup codec-of-last-resort. It's about having one single > mandated codec that everyone has in their back pocket in case nothing else > works. > > The core of RTCWEB is about session *negotiation*. Endpoints will > negotiate the best codec they have in common. Once the next generation of > codecs come out, this "best codec in common" will only be the MTI if they > were about to fail anyway. > > So it doesn't have to be good. > > It just has to be better than failure. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e0122f65e2d458304ea2336a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also want to reiterate that having a MTI codec means Man= datory To Implement.

That means, that should we decide t= o go down the H.264 path, Firefox and others will be forced to support this= Rube Goldberg machine for obtaining H.264 for an indeterminate amount of t= ime, long after WebRTC has moved on to prefer other codecs.


On Fri,= Nov 1, 2013 at 12:43 PM, Adam Roach <adam@nostrum.com> wrote= :
=20 =20 =20
On 10/31/13 13:47, Harald Alvestrand wrote:

We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.

Google still believes that VP8 - a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today - is the best choice of a Mandatory to Implement video codec for the WebRTC effort.


I agree with Harald that VP8 is a better codec than H.264 baseline in a number of important ways.

But I also want to reiterate that having an MTI codec has never been about choosing the best codec or even a good codec. It's about choosing an emergency backup codec-of-last-resort. It's about havin= g one single mandated codec that everyone has in their back pocket in case nothing else works.

The core of RTCWEB is about session *negotiation*. Endpoints will negotiate the best codec they have in common. Once the next generation of codecs come out, this "best codec in common" wi= ll only be the MTI if they were about to fail anyway.

So it doesn't have to be good.

It just has to be better than failure.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--089e0122f65e2d458304ea2336a2-- From lorenzo@meetecho.com Fri Nov 1 13:19:32 2013 Return-Path: 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 71F8611E811D for ; Fri, 1 Nov 2013 13:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 YAmL8RdIfnpy for ; Fri, 1 Nov 2013 13:19:26 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id 23B9511E8131 for ; Fri, 1 Nov 2013 13:19:25 -0700 (PDT) Received: from rainpc ([82.49.174.20]) by smtpcmd04.ad.aruba.it with bizsmtp id kLKN1m00e0SmHqA01LKNR0; Fri, 01 Nov 2013 21:19:24 +0100 Date: Fri, 1 Nov 2013 21:19:22 +0100 From: Lorenzo Miniero To: Adam Roach Message-ID: <20131101211922.3ed7833d@rainpc> In-Reply-To: <52740478.6030109@nostrum.com> References: <52740478.6030109@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 20:19:32 -0000 On Fri, 01 Nov 2013 14:43:52 -0500 Adam Roach wrote: > On 10/31/13 13:47, Harald Alvestrand wrote: > > > > We congratulate Cisco on their intention to make an open source H.264 > > codec available and usable by the community. We look forward to seeing > > the result of this effort. > > > > > > Google still believes that VP8 - a freely available, fully open, > > high-quality video codec that you can download, compile for your > > platform, include in your binary, distribute and put into production > > today - is the best choice of a Mandatory to Implement video codec for > > the WebRTC effort. > > > > I agree with Harald that VP8 is a better codec than H.264 baseline in a > number of important ways. > > But I also want to reiterate that having an MTI codec has never been > about choosing the best codec or even a good codec. It's about choosing > an emergency backup codec-of-last-resort. It's about having one single > mandated codec that everyone has in their back pocket in case nothing > else works. > > The core of RTCWEB is about session *negotiation*. Endpoints will > negotiate the best codec they have in common. Once the next generation > of codecs come out, this "best codec in common" will only be the MTI if > they were about to fail anyway. > > So it doesn't have to be good. > > It just has to be better than failure. > > /a Those are good points. But were that the case, we could have sticked with an older codec, one that didn't have to carry the burden of royalty fees: a choice that several people have often discarded exactly because it wasn't good enough. That's also why I, as it is probably redundant to restate, actually support Harald's view. My concern is that, with H.264, MTI will not mean *a* codec in a negotiatiated session, which is what we all agree RTCWEB still is, or should be. It will be *the* codec, because several implementations, including two currently missing browsers (whenever they'll start to care), will *only* provide H.264, thus forcing everyone to comply with it. Who's going to do anything else, when you know the only way to reach all browsers is *the* codec? And for a lot of people, including me, there's currently (or actually, will be) only one way to do so, which is a plugin (in RTCWEB, ironic) that may or may not be available two months after we start using it. I'm at the wrong edge of the knife, and I don't like it. Lorenzo From pkyzivat@alum.mit.edu Fri Nov 1 13:53:00 2013 Return-Path: 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 06D4511E8179 for ; Fri, 1 Nov 2013 13:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 H6BTVIBt-CMP for ; Fri, 1 Nov 2013 13:52:54 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 0D43F11E813D for ; Fri, 1 Nov 2013 13:52:53 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta02.westchester.pa.mail.comcast.net with comcast id kHhs1m0050vyq2s51Lstsb; Fri, 01 Nov 2013 20:52:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id kLst1m00D3ZTu2S3RLstSx; Fri, 01 Nov 2013 20:52:53 +0000 Message-ID: <527414A5.9090904@alum.mit.edu> Date: Fri, 01 Nov 2013 13:52:53 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Martin Thomson References: <526FCEC1.7000904@alum.mit.edu> <52700422.4020002@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383339173; bh=cgK/lTOkdKHfGQvulDefWKf8q4/xmEjtBE+ugUMtJtY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QlUDXBE1Wyx6WEyKJSfJLuDDWvuW4i/C1fJnIpJm062M3AJWT3z5yoJivl97Ox1fN ZCT6BU6oDd1/catCFb5OwoFWMUKgGryVVe3KqHMt6MNCQ4VZ8EaXgAbrjqXuK1ljWh 1TfLUAhIJnzowICoDvSEW/56baObuqICjqXS3Yq+6nu03o6UC9G5U+lEWbGN5FqoaL pG5hQfa7tYolUjVSsRjZ6/QF8Xr2lnLt/EBZfvpyQy72fk4MOAJAiFd9VwvDAPaZyB +8z5yJoUGS6tTo11lTtUA3N8PB9EODDu/qVRCL3v7PBtzn5sU8xm8LNvLC36hB5DhJ NH99+8GIqdgIA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05 X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 20:53:00 -0000 On 10/29/13 12:07 PM, Martin Thomson wrote: > On 29 October 2013 11:53, Paul Kyzivat wrote: >> This maps each MediaStreamTracks of a given type to a different m-line. I >> *thought* the use of "specified type" above meant audio/video. Am I missing >> something? > > Yes. sort of, though I'd expand "type" to encompass the concept of > compatibility. Obviously a source with an H.264 encoder can't be > bound to an m= section that only has VP8 negotiated. > > 1. RTCPeerConnection binds tracks to m= sections > 2. For sending tracks, that binding is tentatively made when an offer > or answer is constructed > 3. Sending tracks are bound when setLocalDescription is called > 4. For receiving tracks, that binding is made when the track is made, > which is when setRemoteDescription is called > > When generating offers or answers, the set of bindings (including > tentative ones) - plus the enabled state of the track - determines > what of the send/recv attributes is attached to that m= section. It would be nice for this to be clearer in this draft. The binding of potentially *two* MediaStreamTracks to each m-line isn't apparent to me from the existing text. IIUC you are assuming a sendrecv m-line will map to two unidirectional MediaStreamTracks. Looking at a description of the MediaStreamTrack API I find: "MediaStreamTrack.readonly Read only Is a boolean value with a value of true if the track is readonly (such a video file source or a camera that settings can't be modified), false otherwise." That seems to imply that one that isn't read-only must be read-write. I don't see any mention of write-only. Still confused, Paul From martin.thomson@gmail.com Fri Nov 1 14:10:44 2013 Return-Path: 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 D20D411E813D for ; Fri, 1 Nov 2013 14:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, 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 L9tJg1LMS5b8 for ; Fri, 1 Nov 2013 14:10:44 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 73E8221E80E1 for ; Fri, 1 Nov 2013 14:10:40 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t60so59772wes.2 for ; Fri, 01 Nov 2013 14:10:39 -0700 (PDT) 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=o2/CM4NKTqCe6gPpC2DNTsyPUsBryLIMcXFlRJjH314=; b=ZJCl9ibxkm+PtRqt+hzFeDPVPP+N0oDu9cs5KVotI104iTxb0pjvi591FawZGwRKi0 jkK9EkYCOLp2BLv67zlqViQ/MyPVEzBiPnW7vJxe2d19SD/c745RrJf2PWiJtefgmU7m SNnbZw77HE/un3prxsy+00F9CmdvLD1WpuYees5NuJronVuYxjiLuVMqhyOoVn6ZoSzA 4d09sdTBC2KPN5qIPrqGhZhSmPGVN7jt6mFf7rpH+InKVcKJruVubLtLUyU/NqbAftpA ZLV8jEZew6DkK0+xWUmIBZvR1l8gDhEjKX/tEfmzsLhodUg6kZLKBR5FsFs1wiULK2/3 I1Og== MIME-Version: 1.0 X-Received: by 10.180.9.139 with SMTP id z11mr3887673wia.22.1383340239647; Fri, 01 Nov 2013 14:10:39 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Fri, 1 Nov 2013 14:10:39 -0700 (PDT) In-Reply-To: <527414A5.9090904@alum.mit.edu> References: <526FCEC1.7000904@alum.mit.edu> <52700422.4020002@alum.mit.edu> <527414A5.9090904@alum.mit.edu> Date: Fri, 1 Nov 2013 14:10:39 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05 X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 21:10:44 -0000 On 1 November 2013 13:52, Paul Kyzivat wrote: > > "MediaStreamTrack.readonly Read only > Is a boolean value with a value of true if the track is readonly (such a > video file source or a camera that settings can't be modified), false > otherwise." > > That seems to imply that one that isn't read-only must be read-write. I > don't see any mention of write-only. This attribute only really pertains to the constraints API, which is used to do things like switch cameras between capture modes. This is to do things like change resolutions or capture rates on physical devices. The assumption here is that this interface is not appropriate for tracks that originate from the network and so this is a clear signal to an application that trying to apply constraints is going to fail. I know that this oversimplifies the process and that constraints could be used to provide indications back to RTCPeerConnection about what constraints to apply to its negotiation functions, but I think that the conclusion was that this was overcomplicating things. And we know very well that it is already complicated beyond the comprehension of mere mortals anyway. From pkyzivat@alum.mit.edu Fri Nov 1 14:18:22 2013 Return-Path: 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 D1BDD11E8181 for ; Fri, 1 Nov 2013 14:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 0mCkk+vnjps3 for ; Fri, 1 Nov 2013 14:18:14 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id F0BAD11E817E for ; Fri, 1 Nov 2013 14:18:10 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id kE3g1m0010xGWP854MJ9bX; Fri, 01 Nov 2013 21:18:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id kMJ91m01J3ZTu2S3YMJ9Zg; Fri, 01 Nov 2013 21:18:09 +0000 Message-ID: <52741A91.5060402@alum.mit.edu> Date: Fri, 01 Nov 2013 14:18:09 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383340689; bh=rAgV8wSJwmTdn0h13Tom52ZkPW1ac4xvFdMgmKl1WyY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=c72WeFwvxeSm1UkTQQb4XTpBMJC9YBeS8rhCpxr1NoeyLKd218B+XiFBmmHI1+Xso YTrguus36HLV/R3sjXh6bBOnK1/JrDO9Xgq7ZGtQkZMjNmsMJZVRb/jYE66kFx5fMb JA20RSEZW9wa47Phlq3EbqgmkwnFUxOY3p0GvpsapgidX0mHgbIYCZE374S0Tcw3f/ XBTdtRzT37JAEqWtmR1edrww2+AzNqyJDq9hTu5VRxhd6knSXa/OidKh0VMWWoxk8x Fpm50ZbbK1qqo9Lj98Hd6eGTAC8anlHUPVdaPBS0RZt3ArsIV7/RhZL0J62HABPvYe 7j4PvLxiBBNqA== Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - common attributes X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 21:18:23 -0000 Section 5.2.1 says: Each m= section, provided it is not being bundled into another m= section, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates. Otherwise, it MUST use the same ICE credentials and candidates that were used in the m= section that it is being bundled into. But the use of common ICE candidates for bundled m-lines doesn't work until it is known that bundling will be used. Seems like a few more words about that are called for. Further on: Attributes that are common between all m= sections MAY be moved to session-level, if desired. I presume this is only trying to point out a common feature of SDP. But it overstates the real situation. This may only be done for media level attributes (not source level), and only those that are defined to also be valid at session level as a default for media level. It might be better to just not say this. Or refer to 4566 for details. Thanks, Paul From pkyzivat@alum.mit.edu Fri Nov 1 14:45:43 2013 Return-Path: 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 C2B2821E808A for ; Fri, 1 Nov 2013 14:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 TRkOQyZ13kQh for ; Fri, 1 Nov 2013 14:45:38 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id A99A511E817E for ; Fri, 1 Nov 2013 14:45:34 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id kD7V1m0021wpRvQ55MlYqk; Fri, 01 Nov 2013 21:45:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id kMlY1m00k3ZTu2S3eMlYFd; Fri, 01 Nov 2013 21:45:32 +0000 Message-ID: <527420FC.3070805@alum.mit.edu> Date: Fri, 01 Nov 2013 14:45:32 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383342332; bh=S+x5Ik2328c+QJ8p2fP6RhfOLhiBesT4LErXKk1HfOA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=X+bI0zupTOA8JK//F6mGXGBZr9+uwK/OeuOcF9vCDn/Kr2Txw9v/pm0zFyKiucdJO n4b95Z4o3zttWTWgB7WUFa6l9MD/tkMhr5con5lCwBEwpQ3PNzfNLLICDigiebiMji 8nvF+ElewMTrkQOdKDoehUTpdKKHCJsyAJUSzwvkTcot1YpBvf6KCR8Du/fCXz/dL/ bzuZHctm7y4QdZTWjyWHMp4gwcGXnaLL4EyHUG/HHPTsDuAVUwd5mRX9qmsUGYVQU7 SlazZ6N4fJ+pwfJCgt9J0Qdw6a9PxuUUSbTFpws056I438Igtffco5WdlGKzYAgQOZ gHBQ816KzQL/g== Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 21:45:43 -0000 Section 5.2.2 (Subsequent Offers) says: o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST only include codecs present in the remote description. o The RTP header extensions MUST only include those that are present in the remote description. o The RTCP feedback extensions MUST only include those that are present in the remote description. o The "a=rtcp-mux" line MUST only be added if present in the remote description. o The "a=rtcp-rsize" line MUST only be added if present in the remote description. Including only codecs that were present in the prior answer is a bad idea. It doesn't play well with SIP. There is no harm in continuing to include all the codecs you support. And it keeps options open for changing codecs later. The same is true for most other things that are being restricted based on what was in the last answer. (But I won't say that with certainty without checking the semantics of each one.) For further info, see RFC 6337, especially section 5.1. Thanks, Paul From pkyzivat@alum.mit.edu Fri Nov 1 14:45:43 2013 Return-Path: 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 DED6C11E817E for ; Fri, 1 Nov 2013 14:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 gZfsGQrN6y6J for ; Fri, 1 Nov 2013 14:45:38 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id B648A11E8181 for ; Fri, 1 Nov 2013 14:45:35 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA11.westchester.pa.mail.comcast.net with comcast id kCgC1m0080EZKEL5BMlbFT; Fri, 01 Nov 2013 21:45:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id kMlb1m0063ZTu2S3MMlbw3; Fri, 01 Nov 2013 21:45:35 +0000 Message-ID: <527420FF.2@alum.mit.edu> Date: Fri, 01 Nov 2013 14:45:35 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383342335; bh=TrCGCl9Av0lEA8XOB7Peaie77f3Yzm0aowh9Hpvvqk0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dEpA+Be4MvSY69+PwqlrKDWdppe88Vpn33m/EGMpDlDmU+29xuO27ozBrs2Vw2cTV Q4fLf2OBiGxycxLCYMPRyElU+q+aAKXbDbrymHQokNpNurxtar48hO/tG/iJqPYVyv m76Juw1W2KcyxtHng+v+svOsCRDwqOOj2qyQVx9msGYhRyZziXK2KJusu9lm2CHK5o hHs1jIUh7cwl6iQk/ZP4fjxxsmdmh2IFgJyeyOwHKM4XetNmWnZNSP1utzI5+nqqsw /b8XYFhmWEAKBgbyA4Vb4oRQLgxiN+mZWjx5mWrxkDFt/SE/FGdX7rD62NMu3X/yDK R6n5dyc7IFtNQ== Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Recycling m-lines X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 21:45:44 -0000 Section 5.2.2 (Subsequent Offers) says: o If a m= section was rejected, i.e. has had its port set to zero in either the local or remote description, it MUST remain rejected and have a zero port in the new offer, as indicated in RFC3264, Section 5.1. That 3264 reference is to a section about the initial offer, and so is irrelevant to the case. The relevant section is: 8.1 Adding a Media Stream New media streams are created by new additional media descriptions below the existing ones, or by reusing the "slot" used by an old media stream which had been disabled by setting its port to zero. IOW, previously rejected m-lines may be recycled. Later in 5.2.2: o If a m= section exists in the current local description, but has its state set to inactive or recvonly, and a new MediaStreamTrack is added, the previously existing m= section MUST be recycled instead of creating a new m= section. [OPEN ISSUE: Nail down exactly what this means. Should the codecs remain the same? (No.) Should ICE restart? (No.) Can the "a=mid" attribute be changed? (Yes?)] This seems to assume that there is no existing MediaStreamTrack for these m-lines. If there is, then - the m-line shouldn't be recycled. If there isn't, then - where do its address and port come from? - what is managing the RTCP? Thanks, Paul From pkyzivat@alum.mit.edu Fri Nov 1 15:49:50 2013 Return-Path: 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 3727C21E80B0 for ; Fri, 1 Nov 2013 15:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.255 X-Spam-Level: X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 NFI0YLD4EKUn for ; Fri, 1 Nov 2013 15:49:44 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 10F4111E8136 for ; Fri, 1 Nov 2013 15:49:40 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id kD5R1m00327AodY55NpgRZ; Fri, 01 Nov 2013 22:49:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id kNpg1m00Q3ZTu2S3fNpg76; Fri, 01 Nov 2013 22:49:40 +0000 Message-ID: <52743004.50801@alum.mit.edu> Date: Fri, 01 Nov 2013 15:49:40 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Martin Thomson References: <526FCEC1.7000904@alum.mit.edu> <52700422.4020002@alum.mit.edu> <527414A5.9090904@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383346180; bh=kTHH98WCGlqQNynvotFY4zqStOYADBJtEHiH3Z3h7WI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hMqQppKra6aAjdQSCFs3J267abHEIlReMVjotu8WuBNWMgFEAlDIh6r2CoxfsqMMd fvwnHtepDEAjg2pxmsTQ/uRL0IesEAkFS8VezWkpINjvcvE1nNqJdHeDo9kvCzseL9 YXvaHHi5dnNOi8Wt769qLwnUraz/vHf6HIp8na34V+ov+Yhk1LRvhdSxeaL5m/Ngk9 z5Bgr7KoHMwLMOi5yyUbkDoNeapgrEzOdRgjT9sHD7y28A9KZ/IHz+3oQNRQoXJegP h/I5ab4kOGGaPwukzO7pLCfsVvLf1m1o2sQluBCIm8VyUEd1StR3uBEbX/HRIPj3/n Vbq/DrOl9Ap4w== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05 X-BeenThere: rtcweb@ietf.org 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, 01 Nov 2013 22:49:50 -0000 On 11/1/13 2:10 PM, Martin Thomson wrote: > On 1 November 2013 13:52, Paul Kyzivat wrote: >> >> "MediaStreamTrack.readonly Read only >> Is a boolean value with a value of true if the track is readonly (such a >> video file source or a camera that settings can't be modified), false >> otherwise." >> >> That seems to imply that one that isn't read-only must be read-write. I >> don't see any mention of write-only. > > > This attribute only really pertains to the constraints API, which is > used to do things like switch cameras between capture modes. This is > to do things like change resolutions or capture rates on physical > devices. The assumption here is that this interface is not > appropriate for tracks that originate from the network and so this is > a clear signal to an application that trying to apply constraints is > going to fail. OK, so that doesn't mean what I thought it did. (Sorry, but I haven't been following the WebRTC API side of this.) Looking at: http://dev.w3.org/2011/webrtc/editor/getusermedia.html#mediastreamtrack I don't find any notion of readonly or writeonly tracks. If you are going to use the presence of readoly and writeonly tracks to determine the directionality of the m-line, what property of the track determines that? > I know that this oversimplifies the process and that constraints could > be used to provide indications back to RTCPeerConnection about what > constraints to apply to its negotiation functions, but I think that > the conclusion was that this was overcomplicating things. And we know > very well that it is already complicated beyond the comprehension of > mere mortals anyway. Its currently beyond my comprehension. Take that for what its worth. Thanks, Paul From harald@alvestrand.no Fri Nov 1 23:00:25 2013 Return-Path: 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 8F24A21E80FB for ; Fri, 1 Nov 2013 23:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 SeL6eENnTtjJ for ; Fri, 1 Nov 2013 23:00:20 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 79E5611E81B7 for ; Fri, 1 Nov 2013 23:00:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3067239E4D1 for ; Sat, 2 Nov 2013 06:59:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u--1Gw3w37Ca for ; Sat, 2 Nov 2013 06:59:47 +0100 (CET) Received: from [192.168.1.141] (cust.static.62-202-10-161.swisscomdata.ch [62.202.10.161]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DC32E39E12F for ; Sat, 2 Nov 2013 06:59:46 +0100 (CET) Message-ID: <527494D0.2060107@alvestrand.no> Date: Sat, 02 Nov 2013 06:59:44 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <526FCEC1.7000904@alum.mit.edu> <52700422.4020002@alum.mit.edu> <527414A5.9090904@alum.mit.edu> <52743004.50801@alum.mit.edu> In-Reply-To: <52743004.50801@alum.mit.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 06:00:25 -0000 On 11/01/2013 11:49 PM, Paul Kyzivat wrote: > On 11/1/13 2:10 PM, Martin Thomson wrote: >> On 1 November 2013 13:52, Paul Kyzivat wrote: >>> >>> "MediaStreamTrack.readonly Read only >>> Is a boolean value with a value of true if the track is >>> readonly (such a >>> video file source or a camera that settings can't be modified), false >>> otherwise." >>> >>> That seems to imply that one that isn't read-only must be read-write. I >>> don't see any mention of write-only. >> >> >> This attribute only really pertains to the constraints API, which is >> used to do things like switch cameras between capture modes. This is >> to do things like change resolutions or capture rates on physical >> devices. The assumption here is that this interface is not >> appropriate for tracks that originate from the network and so this is >> a clear signal to an application that trying to apply constraints is >> going to fail. > > OK, so that doesn't mean what I thought it did. (Sorry, but I haven't > been following the WebRTC API side of this.) > > Looking at: > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html#mediastreamtrack > > I don't find any notion of readonly or writeonly tracks. If you are > going to use the presence of readoly and writeonly tracks to determine > the directionality of the m-line, what property of the track > determines that? A MediaStreamTrack is unidirectional. Think of it as an SSRC; it helps (even though simulcast and repair flows make the picture more complex). The basic decision of UnifiedPlan was to map a maximum of 2 MediaStreamTracks (one in each direction) to each m-line. So the directionality of an m-line is dictated by whether there are tracks mapped to it in each direction, and whether they are active (if we decide to map "active"; this isn't clearly decided yet, I think). Table: Tracks that are mapped to this M-line Resulting m-line state at A None a=inactive A->B, disabled a=inactive A->B, enabled a=sendonly A->B enabled, B->A disabled a=sendonly A->B enabled, B->A enabled a=sendrecv I think you can complete the rest of the table in your head. The defense for this somewhat arcane mechanism is that it creates SDP that interoperates with endpoints that expect one outgoing and one incoming video track, both described by the same M-line. > >> I know that this oversimplifies the process and that constraints could >> be used to provide indications back to RTCPeerConnection about what >> constraints to apply to its negotiation functions, but I think that >> the conclusion was that this was overcomplicating things. And we know >> very well that it is already complicated beyond the comprehension of >> mere mortals anyway. > > Its currently beyond my comprehension. Take that for what its worth. > > Thanks, > Paul > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From agouaillard@gmail.com Sat Nov 2 01:53:34 2013 Return-Path: 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 CD37011E80EE for ; Sat, 2 Nov 2013 01:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TRTnb7YYcC4Y for ; Sat, 2 Nov 2013 01:53:34 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id D647F11E80EC for ; Sat, 2 Nov 2013 01:53:32 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id m17so5451081oag.21 for ; Sat, 02 Nov 2013 01:53:32 -0700 (PDT) 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=Uj/woMHbTeCg/sIvwNNXDtO+Z91IEjIf/An18J23uJI=; b=UtYsMo9ze5QaiOtHZ3T0z3J0tybOBkJRGR1u0b1iZKoSan7qwrJByHah/2R8avTWfc jlxO4hUm7q02ZlUa/L1A4qnDZVmZuoc3ydgWhEYDmLRlmW2tdz7R7U1fD1QKipmcvAXV C3Nfgt50n9Mf4sRlyt9OFgr37Jwyl6l62Y/XbqrA+bEYbbHr3zuNZWq9pV1RKlJbh2yK tVzUKDrr0vc05J+FHwSLyjtAOh8vvwLthbUK6O+KzvnmDYmVzw0evcUPut5nvt7pUfQa E7PyHLF0AHpnFzJ5Hr+tSP+wf8AuN53ywg9KED0J/rHPN8Po3WC5GI/WZ3U4G2RomcGk +uRA== MIME-Version: 1.0 X-Received: by 10.182.44.134 with SMTP id e6mr5739867obm.14.1383382412448; Sat, 02 Nov 2013 01:53:32 -0700 (PDT) Received: by 10.182.50.129 with HTTP; Sat, 2 Nov 2013 01:53:32 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Nov 2013 16:53:32 +0800 Message-ID: From: Alexandre GOUAILLARD To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11c3235a48680c04ea2dd117 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 08:53:34 -0000 --001a11c3235a48680c04ea2dd117 Content-Type: text/plain; charset=ISO-8859-1 +1 On Fri, Nov 1, 2013 at 2:47 AM, Harald Alvestrand wrote: > We congratulate Cisco on their intention to make an open source H.264 > codec available and usable by the community. We look forward to seeing the > result of this effort. > > Google still believes that VP8 - a freely available, fully open, > high-quality video codec that you can download, compile for your platform, > include in your binary, distribute and put into production today - is the > best choice of a Mandatory to Implement video codec for the WebRTC effort. > > Harald (sending this from my Google address) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c3235a48680c04ea2dd117 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1


On Fri, Nov 1, 2013 at 2:47 AM, Harald Alvestrand <hta@google.com= > wrote:

W= e congratulate Cisco on their intention to make an open source H.264 codec = available and usable by the community. We look forward to seeing the result= of this effort.


Google still believes that= VP8 - a freely available, fully open, high-quality video codec that you ca= n download, compile for your platform, include in your binary, distribute a= nd put into production today - is the best choice of a Mandatory to Impleme= nt video codec for the WebRTC effort.


Harald (sending this from my Google address)


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--001a11c3235a48680c04ea2dd117-- From lgeyser@gmail.com Sat Nov 2 01:59:49 2013 Return-Path: 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 8791D11E8100 for ; Sat, 2 Nov 2013 01:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yN9gy-O81Gj1 for ; Sat, 2 Nov 2013 01:59:48 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4308011E80EC for ; Sat, 2 Nov 2013 01:59:48 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id n7so979857lam.41 for ; Sat, 02 Nov 2013 01:59:47 -0700 (PDT) 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=peEAtAugddPCDA504OwHpxn48EWbjFsuRSvd7iu2Xow=; b=LOF74DRDYRu/ZIAuKVd+zN7BG+pNfFSjrDnyUDAtjkj1p5ZIYqlCcz4ggX0Hu7UaYs uy45QQoRKx4bahKpxQgs1CwLw3kb2V9TXPfcMcN4p0HeNS/dm0PlZ0FcNWaBRUsAYTCf dK7is5sh3GQV7SduaQClswojCIBgXbZENBszs0/eD1iF/T34QohcE31//t59qwy6CecG YQOOXuQKk5ignw3M/zoBdPuq8l5LgAyzSKG+77gMFIWp0AwMtHBQWZCKb3PShYKy/xu5 xGOtbNolSa7xiF6iLKZOPgFRZCdXsEhzvoxTCZxT4BEpXB1sMJT9LtT9JRpTBtpqP4F2 /rSw== MIME-Version: 1.0 X-Received: by 10.112.143.138 with SMTP id se10mr4138684lbb.26.1383382787196; Sat, 02 Nov 2013 01:59:47 -0700 (PDT) Received: by 10.114.168.70 with HTTP; Sat, 2 Nov 2013 01:59:47 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Nov 2013 10:59:47 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e011828309e8bbf04ea2de74e Cc: Harald Alvestrand Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 08:59:49 -0000 --089e011828309e8bbf04ea2de74e Content-Type: text/plain; charset=ISO-8859-1 +1 On 2 November 2013 10:53, Alexandre GOUAILLARD wrote: > +1 > > > On Fri, Nov 1, 2013 at 2:47 AM, Harald Alvestrand wrote: > >> We congratulate Cisco on their intention to make an open source H.264 >> codec available and usable by the community. We look forward to seeing the >> result of this effort. >> >> Google still believes that VP8 - a freely available, fully open, >> high-quality video codec that you can download, compile for your platform, >> include in your binary, distribute and put into production today - is the >> best choice of a Mandatory to Implement video codec for the WebRTC effort. >> >> Harald (sending this from my Google address) >> >> >> _______________________________________________ >> 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 > > --089e011828309e8bbf04ea2de74e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1


On 2 November 2013 10:53, Alexandre GOUAILLARD <ago= uaillard@gmail.com> wrote:
+1


On Fri, N= ov 1, 2013 at 2:47 AM, Harald Alvestrand <hta@google.com> wrote= :

We congratulate Cisco on their intention to make an open= source H.264 codec available and usable by the community. We look forward = to seeing the result of this effort.


Google still believes that= VP8 - a freely available, fully open, high-quality video codec that you ca= n download, compile for your platform, include in your binary, distribute a= nd put into production today - is the best choice of a Mandatory to Impleme= nt video codec for the WebRTC effort.


Harald (sending this from my Google address)


_________________________________________= ______
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


--089e011828309e8bbf04ea2de74e-- From silviapfeiffer1@gmail.com Sat Nov 2 02:26:53 2013 Return-Path: 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 E815611E80EC for ; Sat, 2 Nov 2013 02:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 8MpPzVlmYkDg for ; Sat, 2 Nov 2013 02:26:51 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 76FCD11E81C6 for ; Sat, 2 Nov 2013 02:26:34 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id j1so5557856oag.11 for ; Sat, 02 Nov 2013 02:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BEYA192r7Y3Nr5FxmBhAUN83RxLRNSCc2X/dHqCZrUc=; b=HhJZVg+ilu/xjdhseMlVgpF0/JxSIldrMjnoXjQrq3V6t8PwPmNdX/3lVnfXE+3B2a xbUpG6/C7UdBqo1Ldcrw6R14KdxPgJKuxW7bpKdqqD83mp5uLv6nxa3AQtlgsPk7gsUk in1pLYxR/7/Za7gMdcupkpEuyOWHN0Vq47U8CcLatDFUWLd0ExaekbiTaStQgjowqiNt UJuB9ol7IZTncOp2XmfBfQoWCpXliaWN+F2yMWXSvzJCSmz1XU9ZiJOThVQ44Id2UlLG 7oeI4m8ft41UWdooUcV2YkwxvUh2GEqZ8byprc8Hi3KYo/iZnn2P2uK10XHr5MNWEubW 7duA== X-Received: by 10.182.213.166 with SMTP id nt6mr2083obc.53.1383384394110; Sat, 02 Nov 2013 02:26:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.94.40 with HTTP; Sat, 2 Nov 2013 02:26:13 -0700 (PDT) In-Reply-To: References: From: Silvia Pfeiffer Date: Sat, 2 Nov 2013 20:26:13 +1100 Message-ID: To: Leon Geyser Content-Type: text/plain; charset=ISO-8859-1 Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 09:26:53 -0000 +1 (is the vote on the MTI codec going to happen via email?) Silvia. On Sat, Nov 2, 2013 at 7:59 PM, Leon Geyser wrote: > +1 > > > On 2 November 2013 10:53, Alexandre GOUAILLARD > wrote: >> >> +1 >> >> >> On Fri, Nov 1, 2013 at 2:47 AM, Harald Alvestrand wrote: >>> >>> We congratulate Cisco on their intention to make an open source H.264 >>> codec available and usable by the community. We look forward to seeing the >>> result of this effort. >>> >>> >>> Google still believes that VP8 - a freely available, fully open, >>> high-quality video codec that you can download, compile for your platform, >>> include in your binary, distribute and put into production today - is the >>> best choice of a Mandatory to Implement video codec for the WebRTC effort. >>> >>> >>> Harald (sending this from my Google address) >>> >>> >>> _______________________________________________ >>> 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 > From spromano@unina.it Sat Nov 2 02:32:35 2013 Return-Path: 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 EF86B11E8119 for ; Sat, 2 Nov 2013 02:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 2QOYLBB5JBj4 for ; Sat, 2 Nov 2013 02:32:30 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 82FF311E8104 for ; Sat, 2 Nov 2013 02:31:59 -0700 (PDT) Received: from u690021.xgsnuf11.imtp.tachikawa.mopera.net ([91.255.83.117]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id rA29Vim7012839 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 2 Nov 2013 10:31:48 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----651FI7V3JF3MY7XREZ3IZFU2I8SKPA" From: Simon Pietro Romano Date: Sat, 02 Nov 2013 10:31:44 +0100 To: Silvia Pfeiffer , Leon Geyser Message-ID: Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 09:32:35 -0000 ------651FI7V3JF3MY7XREZ3IZFU2I8SKPA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit +1 from me (just in case...) Simon Silvia Pfeiffer ha scritto: >+1 (is the vote on the MTI codec going to happen via email?) >Silvia. > > >On Sat, Nov 2, 2013 at 7:59 PM, Leon Geyser wrote: >> +1 >> >> >> On 2 November 2013 10:53, Alexandre GOUAILLARD > >> wrote: >>> >>> +1 >>> >>> >>> On Fri, Nov 1, 2013 at 2:47 AM, Harald Alvestrand >wrote: >>>> >>>> We congratulate Cisco on their intention to make an open source >H.264 >>>> codec available and usable by the community. We look forward to >seeing the >>>> result of this effort. >>>> >>>> >>>> Google still believes that VP8 - a freely available, fully open, >>>> high-quality video codec that you can download, compile for your >platform, >>>> include in your binary, distribute and put into production today - >is the >>>> best choice of a Mandatory to Implement video codec for the WebRTC >effort. >>>> >>>> >>>> Harald (sending this from my Google address) >>>> >>>> >>>> _______________________________________________ >>>> 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 ------651FI7V3JF3MY7XREZ3IZFU2I8SKPA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1 from me (just in case...)

Simon

Silvia Pfeiffer <silviapfeiffer1@gmail.com> ha scritto:
+1  (is the vote on the MTI codec going to happen via email?)
Silvia.


On Sat, Nov 2, 2013 at 7:59 PM, Leon Geyser <lgeyser@gmail.com> wrote:
+1


On 2 November 2013 10:53, Alexandre GOUAILLARD <agouaillard@gmail.com>
wrote:

+1


On Fri, Nov 1, 2013 at 2:47 AM, Harald Alvestrand <hta@google.com> wrote:

We congratulate Cisco on their intention to make an open source H.264
codec available and usable by the community. We look forward to seeing the
result of this effort.


Google still be!
 lieves
that VP8 - a freely available, fully open,
high-quality video codec that you can download, compile for your platform,
include in your binary, distribute and put into production today - is the
best choice of a Mandatory to Implement video codec for the WebRTC effort.


Harald (sending this from my Google address)



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

------651FI7V3JF3MY7XREZ3IZFU2I8SKPA-- From lorenzo@meetecho.com Sat Nov 2 02:48:29 2013 Return-Path: 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 76C3E11E8119 for ; Sat, 2 Nov 2013 02:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=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 TPUH1pfBtc8F for ; Sat, 2 Nov 2013 02:48:18 -0700 (PDT) Received: from smtpdb11.aruba.it (smtpdb11.aruba.it [62.149.158.253]) by ietfa.amsl.com (Postfix) with ESMTP id ABCED11E81E0 for ; Sat, 2 Nov 2013 02:48:09 -0700 (PDT) Received: from [10.53.209.15] ([88.128.80.2]) by smtpcmd04.ad.aruba.it with bizsmtp id kZo11m00e02zm9U01Zo2NJ; Sat, 02 Nov 2013 10:48:04 +0100 Date: Sat, 02 Nov 2013 10:47:59 +0100 Message-ID: <7pc8ua9dp0mk28l38ad67un2.1383385679448@email.android.com> From: Lorenzo Miniero To: Silvia Pfeiffer , Leon Geyser , Simon Pietro Romano MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_45592002273650" Cc: Harald Alvestrand , rtcweb@ietf.org Subject: [rtcweb] R: Re: Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 09:48:29 -0000 ----_com.android.email_45592002273650 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 KzEgKGluIGNhc2UgYW55b25lIHdhcyB3b25kZXJpbmcgOi0pICkKCkxvcmVuem8KCkludmlhdGEg ZGEgc21hcnRwaG9uZSAgWHBlcmlh4oSiIAoKU2ltb24gUGlldHJvIFJvbWFubyA8c3Byb21hbm9A dW5pbmEuaXQ+IGhhIHNjcml0dG86Cgo+KzEgZnJvbSBtZSAoanVzdCBpbiBjYXNlLi4uKQo+Cj5T aW1vbgo+Cj5TaWx2aWEgUGZlaWZmZXIgPHNpbHZpYXBmZWlmZmVyMUBnbWFpbC5jb20+IGhhIHNj cml0dG86Cj4+KzEgIChpcyB0aGUgdm90ZSBvbiB0aGUgTVRJIGNvZGVjIGdvaW5nIHRvIGhhcHBl biB2aWEgZW1haWw/KQo+PlNpbHZpYS4KPj4KPj4KPj5PbiBTYXQsIE5vdiAyLCAyMDEzIGF0IDc6 NTkgUE0sIExlb24gR2V5c2VyIDxsZ2V5c2VyQGdtYWlsLmNvbT4gd3JvdGU6Cj4+PiArMQo+Pj4K Pj4+Cj4+PiBPbiAyIE5vdmVtYmVyIDIwMTMgMTA6NTMsIEFsZXhhbmRyZSBHT1VBSUxMQVJECj4+ PGFnb3VhaWxsYXJkQGdtYWlsLmNvbT4KPj4+IHdyb3RlOgo+Pj4+Cj4+Pj4gKzEKPj4+Pgo+Pj4+ Cj4+Pj4gT24gRnJpLCBOb3YgMSwgMjAxMyBhdCAyOjQ3IEFNLCBIYXJhbGQgQWx2ZXN0cmFuZCA8 aHRhQGdvb2dsZS5jb20+Cj4+d3JvdGU6Cj4+Pj4+Cj4+Pj4+IFdlIGNvbmdyYXR1bGF0ZSBDaXNj byBvbiB0aGVpciBpbnRlbnRpb24gdG8gbWFrZSBhbiBvcGVuIHNvdXJjZQo+PkguMjY0Cj4+Pj4+ IGNvZGVjIGF2YWlsYWJsZSBhbmQgdXNhYmxlIGJ5IHRoZSBjb21tdW5pdHkuIFdlIGxvb2sgZm9y d2FyZCB0bwo+PnNlZWluZyB0aGUKPj4+Pj4gcmVzdWx0IG9mIHRoaXMgZWZmb3J0Lgo+Pj4+Pgo+ Pj4+Pgo+Pj4+PiBHb29nbGUgc3RpbGwgYmVsaWV2ZXMgdGhhdCBWUDggLSBhIGZyZWVseSBhdmFp bGFibGUsIGZ1bGx5IG9wZW4sCj4+Pj4+IGhpZ2gtcXVhbGl0eSB2aWRlbyBjb2RlYyB0aGF0IHlv dSBjYW4gZG93bmxvYWQsIGNvbXBpbGUgZm9yIHlvdXIKPj5wbGF0Zm9ybSwKPj4+Pj4gaW5jbHVk ZSBpbiB5b3VyIGJpbmFyeSwgZGlzdHJpYnV0ZSBhbmQgcHV0IGludG8gcHJvZHVjdGlvbiB0b2Rh eSAtCj4+aXMgdGhlCj4+Pj4+IGJlc3QgY2hvaWNlIG9mIGEgTWFuZGF0b3J5IHRvIEltcGxlbWVu dCB2aWRlbyBjb2RlYyBmb3IgdGhlIFdlYlJUQwo+PmVmZm9ydC4KPj4+Pj4KPj4+Pj4KPj4+Pj4g SGFyYWxkIChzZW5kaW5nIHRoaXMgZnJvbSBteSBHb29nbGUgYWRkcmVzcykKPj4+Pj4KPj4+Pj4K Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+ Pj4gcnRjd2ViIG1haWxpbmcgbGlzdAo+Pj4+PiBydGN3ZWJAaWV0Zi5vcmcKPj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIKPj4+Pj4KPj4+Pgo+Pj4+Cj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+PiBy dGN3ZWIgbWFpbGluZyBsaXN0Cj4+Pj4gcnRjd2ViQGlldGYub3JnCj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIKPj4+Pgo+Pj4KPj4+Cj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4gcnRjd2ViIG1haWxp bmcgbGlzdAo+Pj4gcnRjd2ViQGlldGYub3JnCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYgo+Pj4KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+PnJ0Y3dlYiBtYWlsaW5nIGxpc3QKPj5ydGN3ZWJAaWV0Zi5vcmcK Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYgo+Cj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+cnRjd2ViIG1haWxpbmcg bGlzdAo+cnRjd2ViQGlldGYub3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3J0Y3dlYgo= ----_com.android.email_45592002273650 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 KzEgKGluIGNhc2UgYW55b25lIHdhcyB3b25kZXJpbmcgOi0pICk8YnI+PGJyPkxvcmVuem88YnI+ PGJyPkludmlhdGEgZGEgc21hcnRwaG9uZSAgWHBlcmlh4oSiIDxicj48YnI+U2ltb24gUGlldHJv IFJvbWFubyAmbHQ7c3Byb21hbm9AdW5pbmEuaXQmZ3Q7IGhhIHNjcml0dG86PGJyPjxicj4rMSBm cm9tIG1lIChqdXN0IGluIGNhc2UuLi4pPGJyPg0KPGJyPg0KU2ltb248YnI+PGJyPjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj5TaWx2aWEgUGZlaWZmZXIgJmx0O3NpbHZpYXBmZWlmZmVyMUBnbWFp bC5jb20mZ3Q7IGhhIHNjcml0dG86PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2Io MjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8cHJlIGNsYXNzPSJrOW1haWwi PisxICAoaXMgdGhlIHZvdGUgb24gdGhlIE1USSBjb2RlYyBnb2luZyB0byBoYXBwZW4gdmlhIGVt YWlsPyk8YnIgLz5TaWx2aWEuPGJyIC8+PGJyIC8+PGJyIC8+T24gU2F0LCBOb3YgMiwgMjAxMyBh dCA3OjU5IFBNLCBMZW9uIEdleXNlciAmbHQ7bGdleXNlckBnbWFpbC5jb20mZ3Q7IHdyb3RlOjxi ciAvPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB0IDBw dCAxZXggMC44ZXg7IGJvcmRlci1sZWZ0OiAxcHggc29saWQgIzcyOWZjZjsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij4rMTxiciAvPjxiciAvPjxiciAvPk9uIDIgTm92ZW1iZXIgMjAxMyAxMDo1MywgQWxl eGFuZHJlIEdPVUFJTExBUkQgJmx0O2Fnb3VhaWxsYXJkQGdtYWlsLmNvbSZndDs8YnIgLz53cm90 ZTo8YnIgLz48YnIgLz48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46IDBwdCAwcHQgMWV4IDAuOGV4OyBib3JkZXItbGVmdDogMXB4IHNvbGlkICNhZDdmYTg7IHBh ZGRpbmctbGVmdDogMWV4OyI+KzE8YnIgLz48YnIgLz48YnIgLz5PbiBGcmksIE5vdiAxLCAyMDEz IGF0IDI6NDcgQU0sIEhhcmFsZCBBbHZlc3RyYW5kICZsdDtodGFAZ29vZ2xlLmNvbSZndDsgd3Jv dGU6PGJyIC8+PGJyIC8+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOiAwcHQgMHB0IDFleCAwLjhleDsgYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCAjOGFlMjM0OyBw YWRkaW5nLWxlZnQ6IDFleDsiPldlIGNvbmdyYXR1bGF0ZSBDaXNjbyBvbiB0aGVpciBpbnRlbnRp b24gdG8gbWFrZSBhbiBvcGVuIHNvdXJjZSBILjI2NDxiciAvPmNvZGVjIGF2YWlsYWJsZSBhbmQg dXNhYmxlIGJ5IHRoZSBjb21tdW5pdHkuIFdlIGxvb2sgZm9yd2FyZCB0byBzZWVpbmcgdGhlPGJy IC8+cmVzdWx0IG9mIHRoaXMgZWZmb3J0LjxiciAvPjxiciAvPjxiciAvPkdvb2dsZSBzdGlsbCBi ZSENCiBsaWV2ZXMNCnRoYXQgVlA4IC0gYSBmcmVlbHkgYXZhaWxhYmxlLCBmdWxseSBvcGVuLDxi ciAvPmhpZ2gtcXVhbGl0eSB2aWRlbyBjb2RlYyB0aGF0IHlvdSBjYW4gZG93bmxvYWQsIGNvbXBp bGUgZm9yIHlvdXIgcGxhdGZvcm0sPGJyIC8+aW5jbHVkZSBpbiB5b3VyIGJpbmFyeSwgZGlzdHJp YnV0ZSBhbmQgcHV0IGludG8gcHJvZHVjdGlvbiB0b2RheSAtIGlzIHRoZTxiciAvPmJlc3QgY2hv aWNlIG9mIGEgTWFuZGF0b3J5IHRvIEltcGxlbWVudCB2aWRlbyBjb2RlYyBmb3IgdGhlIFdlYlJU QyBlZmZvcnQuPGJyIC8+PGJyIC8+PGJyIC8+SGFyYWxkIChzZW5kaW5nIHRoaXMgZnJvbSBteSBH b29nbGUgYWRkcmVzcyk8YnIgLz48YnIgLz48YnIgLz48aHIgLz48YnIgLz5ydGN3ZWIgbWFpbGlu ZyBsaXN0PGJyIC8+cnRjd2ViQGlldGYub3JnPGJyIC8+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViPC9hPjwvYmxvY2txdW90ZT48YnIgLz48YnIgLz48YnIgLz48aHIg Lz48YnIgLz5ydGN3ZWIgbWFpbGluZyBsaXN0PGJyIC8+cnRjd2ViQGlldGYub3JnPGJyIC8+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjwvYmxvY2txdW90ZT48 YnIgLz48YnIgLz48YnIgLz48aHIgLz48YnIgLz5ydGN3ZWIgbWFpbGluZyBsaXN0PGJyIC8+cnRj d2ViQGlldGYub3JnPGJyIC8+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViPC9hPjwvYmxvY2txdW90ZT48YnIgLz48aHIgLz48YnIgLz5ydGN3ZWIgbWFpbGluZyBsaXN0 PGJyIC8+cnRjd2ViQGlldGYub3JnPGJyIC8+PGENCmhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYjwvYT48YnIgLz48YnIgLz48L3ByZT48L2Jsb2NrcXVvdGU+PC9kaXY+ ----_com.android.email_45592002273650-- From alessandro.amirante@unina.it Sat Nov 2 03:10:39 2013 Return-Path: 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 0F5AF11E8119 for ; Sat, 2 Nov 2013 03:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 oZX1u+9FAm9W for ; Sat, 2 Nov 2013 03:10:34 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4366611E80EC for ; Sat, 2 Nov 2013 03:10:34 -0700 (PDT) Received: from [192.168.0.4] ([151.77.218.206]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id rA2AATsi015425 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 2 Nov 2013 11:10:31 +0100 Message-ID: <5274CF96.4050203@unina.it> Date: Sat, 02 Nov 2013 11:10:30 +0100 From: Alessandro Amirante User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52740478.6030109@nostrum.com> <20131101211922.3ed7833d@rainpc> In-Reply-To: <20131101211922.3ed7833d@rainpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 10:10:39 -0000 Il 01/11/2013 21:19, Lorenzo Miniero ha scritto: > On Fri, 01 Nov 2013 14:43:52 -0500 > Adam Roach wrote: > >> On 10/31/13 13:47, Harald Alvestrand wrote: >>> >>> We congratulate Cisco on their intention to make an open source H.264 >>> codec available and usable by the community. We look forward to seeing >>> the result of this effort. >>> >>> >>> Google still believes that VP8 - a freely available, fully open, >>> high-quality video codec that you can download, compile for your >>> platform, include in your binary, distribute and put into production >>> today - is the best choice of a Mandatory to Implement video codec for >>> the WebRTC effort. >>> >> >> I agree with Harald that VP8 is a better codec than H.264 baseline in a >> number of important ways. >> >> But I also want to reiterate that having an MTI codec has never been >> about choosing the best codec or even a good codec. It's about choosing >> an emergency backup codec-of-last-resort. It's about having one single >> mandated codec that everyone has in their back pocket in case nothing >> else works. >> >> The core of RTCWEB is about session *negotiation*. Endpoints will >> negotiate the best codec they have in common. Once the next generation >> of codecs come out, this "best codec in common" will only be the MTI if >> they were about to fail anyway. >> >> So it doesn't have to be good. >> >> It just has to be better than failure. >> >> /a > > > Those are good points. But were that the case, we could have sticked with an older codec, one that didn't have to carry the burden of royalty fees: a choice that several people have often discarded exactly because it wasn't good enough. I could not agree more. > > That's also why I, as it is probably redundant to restate, actually support Harald's view. My concern is that, with H.264, MTI will not mean *a* codec in a negotiatiated session, which is what we all agree RTCWEB still is, or should be. It will be *the* codec, because several implementations, including two currently missing browsers (whenever they'll start to care), will *only* provide H.264, thus forcing everyone to comply with it. Who's going to do anything else, when you know the only way to reach all browsers is *the* codec? And for a lot of people, including me, there's currently (or actually, will be) only one way to do so, which is a plugin (in RTCWEB, ironic) that may or may not be available two months after we start using it. +1 for VP8 as MTI. Alessandro > > I'm at the wrong edge of the knife, and I don't like it. > > Lorenzo > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Alessandro Amirante, Ph.D. Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione Universita' degli Studi di Napoli "Federico II" Via Claudio, 21 - 80125 Napoli - Italy Phone: +39 081 7683821 Fax: +39 081 19730464 E-mail: alessandro.amirante@unina.it Skype-ID: alessandro.amirante Web: http://wpage.unina.it/alessandro.amirante From emcho@sip-communicator.org Sat Nov 2 03:15:06 2013 Return-Path: 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 8607511E8186 for ; Sat, 2 Nov 2013 03:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 60QNX40u7PlZ for ; Sat, 2 Nov 2013 03:14:53 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id ED8DB11E815C for ; Sat, 2 Nov 2013 03:14:51 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id g10so4822079pdj.6 for ; Sat, 02 Nov 2013 03:14:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V8WaSi60InjVob/gdvWSf5SDqvXDlB88QnO3K+CZ+kQ=; b=gNbV9HJmMr4gjbCL8SUGQKODaD5Pcow6VHc0wB7rJfA+O1WMJeZ5XdGAOw7JPIz4bC 052KqZN2t+PEKaj/0+ce2xvdKUdJXpoe44i4b8Fl9K26tgn41xDHjSl0IwK90TkcJBDb D2zlOEtEwlipcqZTic91rv4i9YV0/NJ3vSQOUOEMLZtSSOEjKZUNvNhmQltKZJViFCrF MTtDz+VPisBqHAx4BLkbKcNUaiu3yT/Msnge0XfSmV7tBdr4iedhXI92pYhcfRhoFy7/ J/qLKKu0PkXWecPR43iNsC0H52om6MuShQfGCMwPNAvcX5WAL8600qOEU9vgGv/yFTmm mC7A== X-Gm-Message-State: ALoCoQnCtPQqEjdYQ/3+WJaGz0QB1ILhTD3vdvT/3ZerE4GDoUe88YIhRNoh2OqGSKLYTEsmDdF7 X-Received: by 10.68.52.231 with SMTP id w7mr7658561pbo.19.1383387291547; Sat, 02 Nov 2013 03:14:51 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [2607:f8b0:400e:c01::231]) by mx.google.com with ESMTPSA id gg10sm15923182pbc.46.2013.11.02.03.14.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 03:14:50 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so5269822pbc.22 for ; Sat, 02 Nov 2013 03:14:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.225.9 with SMTP id rg9mr7627781pbc.122.1383387290581; Sat, 02 Nov 2013 03:14:50 -0700 (PDT) Received: by 10.66.191.163 with HTTP; Sat, 2 Nov 2013 03:14:50 -0700 (PDT) Received: by 10.66.191.163 with HTTP; Sat, 2 Nov 2013 03:14:50 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Nov 2013 11:14:50 +0100 Message-ID: From: Emil Ivov To: Silvia Pfeiffer Content-Type: multipart/alternative; boundary=047d7b2ee18b0ada6704ea2ef451 Cc: Harald Tveit Alvestrand , rtcweb@ietf.org Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 10:15:06 -0000 --047d7b2ee18b0ada6704ea2ef451 Content-Type: text/plain; charset=ISO-8859-1 On 2 Nov 2013 10:27, "Silvia Pfeiffer" wrote: > > +1 (is the vote on the MTI codec going to happen via email?) There is no voting on the IETF so, no. There would probably be "hum"s called during the meeting. You can take part in these either directly or through the XMPP chatroom: rtcweb@jabber.ietf.org This is not to say that expressing your opinion here is inappropriate. Quite on the contrary. Emil -- https://jitsi.org --047d7b2ee18b0ada6704ea2ef451 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 Nov 2013 10:27, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wro= te:
>
> +1 =A0(is the vote on the MTI codec going to happen via email?)

There is no voting on the IETF so, no. There would probably = be "hum"s called during the meeting. You can take part in these e= ither directly or through the XMPP chatroom: rtcweb@jabber.ietf.org

This is not to say that expressing your opinion here is inap= propriate. Quite on the contrary.

Emil

--
https://jitsi.org

--047d7b2ee18b0ada6704ea2ef451-- From emcho@sip-communicator.org Sat Nov 2 03:35:00 2013 Return-Path: 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 E51D911E80F1 for ; Sat, 2 Nov 2013 03:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 5lIk78xhLteh for ; Sat, 2 Nov 2013 03:34:53 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7ED11E815C for ; Sat, 2 Nov 2013 03:34:52 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id q10so4866999pdj.14 for ; Sat, 02 Nov 2013 03:34:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=We+kSOuhL2uJxaOWigRJorwcXT5+GiCdJySxkkQIGjU=; b=KVCQigI/9yMmsHd2kGB8EXPyXng3eX1BbMI/D7D0CVRDrXXO9l7QRl/TAypDUMUbcl f8B/r7GuNk1viOTxI/U2Mf4eirzjHYc01dVDVvmKKic9T3NL+3MjRc80FwG9bXBWa5Ri 776sQPHwZbMeWCQTgiQyRXcUKmwMABmuo8nM3V0z/wegudugzN0NK50Atzzgn66W264G bL8VYJcjK6p+xetR89yfj7r6wATPqoZ44xEG3wx4tFm2Oi2awiHr9oC4Dz6PyfvAdiXc WSKDbTcjM4tvWPvhZ/B22+0twdOfwEtPA192INC3fv5MLN1m4uZP66keToLQb2XZW6/r ozzw== X-Gm-Message-State: ALoCoQm0DHCyJUhJqDSVH03ke/wHA6FaVSwQ8WLX1pq92if8ZbLH6syjYo0jPqJ6hZUuGyoUID9c X-Received: by 10.67.24.7 with SMTP id ie7mr7529357pad.112.1383388492174; Sat, 02 Nov 2013 03:34:52 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [2607:f8b0:400e:c03::229]) by mx.google.com with ESMTPSA id qw8sm16010225pbb.27.2013.11.02.03.34.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 03:34:51 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so5080275pab.14 for ; Sat, 02 Nov 2013 03:34:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.162.167 with SMTP id yb7mr7796051pab.16.1383388491320; Sat, 02 Nov 2013 03:34:51 -0700 (PDT) Received: by 10.66.191.163 with HTTP; Sat, 2 Nov 2013 03:34:51 -0700 (PDT) Received: by 10.66.191.163 with HTTP; Sat, 2 Nov 2013 03:34:51 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Nov 2013 11:34:51 +0100 Message-ID: From: Emil Ivov To: Harald Tveit Alvestrand Content-Type: multipart/alternative; boundary=047d7bacbe709cb5ca04ea2f3bb5 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 10:35:00 -0000 --047d7bacbe709cb5ca04ea2f3bb5 Content-Type: text/plain; charset=ISO-8859-1 +1 for VP8 as MTI. Compared to VP8, H.264 baseline is only marginally better than H.263. This makes it hard to justify the inconvenience of post-installation additions. The whole point of WebRTC was: NO PLUGINS NEEDED! Let's not through this out the window. Also, while Cisco's grant is quite interesting for certain scenarios it could be very problematic for others. For example: enterprises where installations are handled in a controlled and automated way (e.g. scripted image deployment) and where subsequent Internet access could be limited for various reasons. Emil -- https://jitsi.org On 31 Oct 2013 19:48, "Harald Alvestrand" wrote: > > We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort. > > > Google still believes that VP8 - a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today - is the best choice of a Mandatory to Implement video codec for the WebRTC effort. > > > Harald (sending this from my Google address) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bacbe709cb5ca04ea2f3bb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+1 for VP8 as MTI.

Compared to VP8, H.264 baseline is only marginally better th= an H.263. This makes it hard to justify the inconvenience of post-installat= ion additions.

The whole point of WebRTC was: NO PLUGINS NEEDED!

Let's not through this out the window.

Also, while Cisco's grant is quite interesting for certa= in scenarios it could be very problematic for others. For example: enterpri= ses where installations are handled in a controlled and automated way (e.g.= scripted image deployment) and where subsequent Internet access could be l= imited for various reasons.

Emil

--
https://jitsi.org

On 31 Oct 2013 19:48, "Harald Alvestrand" <hta@google.com> wrote:
>
> We congratulate Cisco on their intention to make an open source H.264 = codec available and usable by the community. We look forward to seeing the = result of this effort.
>
>
> Google still believes that VP8 - a freely available, fully open, high-= quality video codec that you can download, compile for your platform, inclu= de in your binary, distribute and put into production today - is the best c= hoice of a Mandatory to Implement video codec for the WebRTC effort.
>
>
> Harald (sending this from my Google address)
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>

--047d7bacbe709cb5ca04ea2f3bb5-- From bernard_aboba@hotmail.com Sat Nov 2 04:32:19 2013 Return-Path: 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 69F6921E80BF for ; Sat, 2 Nov 2013 04:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.61 X-Spam-Level: X-Spam-Status: No, score=-101.61 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 KKo8slqu8Teq for ; Sat, 2 Nov 2013 04:32:12 -0700 (PDT) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2472521E8056 for ; Sat, 2 Nov 2013 04:31:47 -0700 (PDT) Received: from BLU404-EAS261 ([65.55.111.73]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Nov 2013 04:31:46 -0700 X-TMN: [QN5fSAr7Fxhpj11ehYHCRclgGUBEC/3t] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_31613545-3037-4d17-b5e0-96c949e252e4_" References: <52740478.6030109@nostrum.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Sat, 2 Nov 2013 04:31:45 -0700 To: Justin Uberti X-OriginalArrivalTime: 02 Nov 2013 11:31:46.0579 (UTC) FILETIME=[1D031630:01CED7BF] Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 11:32:19 -0000 --_31613545-3037-4d17-b5e0-96c949e252e4_ Content-Type: multipart/alternative; boundary="Apple-Mail-630E53EC-A98D-430D-B40B-3E244563577B" Content-Transfer-Encoding: 7bit --Apple-Mail-630E53EC-A98D-430D-B40B-3E244563577B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not sure I understand this completely. Isn't support for "the Rube Goldberg M= achine" needed only on platforms that do not natively support H.264?=20 > On Nov 1, 2013, at 1:14 PM, "Justin Uberti" wrote: >=20 > I also want to reiterate that having a MTI codec means Mandatory To Implem= ent. >=20 > That means, that should we decide to go down the H.264 path, Firefox and o= thers will be forced to support this Rube Goldberg machine for obtaining H.2= 64 for an indeterminate amount of time, long after WebRTC has moved on to pr= efer other codecs. >=20 >=20 >> On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach wrote: >>> On 10/31/13 13:47, Harald Alvestrand wrote: >>> We >>> congratulate Cisco on their intention to make an open >>> source H.264 codec available and usable by the community. >>> We look forward to seeing the result of this effort. >>>=20 >>> Google >>> still believes that VP8 - a freely available, fully open, >>> high-quality video codec that you can download, compile >>> for your platform, include in your binary, distribute and >>> put into production today - is the best choice of a >>> Mandatory to Implement video codec for the WebRTC effort. >>=20 >> I agree with Harald that VP8 is a better codec than H.264 baseline in a n= umber of important ways. >>=20 >> But I also want to reiterate that having an MTI codec has never been abou= t choosing the best codec or even a good codec. It's about choosing an emerg= ency backup codec-of-last-resort. It's about having one single mandated code= c that everyone has in their back pocket in case nothing else works. >>=20 >> The core of RTCWEB is about session *negotiation*. Endpoints will negotia= te the best codec they have in common. Once the next generation of codecs co= me out, this "best codec in common" will only be the MTI if they were about t= o fail anyway. >>=20 >> So it doesn't have to be good. >>=20 >> It just has to be better than failure. >>=20 >> /a >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-630E53EC-A98D-430D-B40B-3E244563577B Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
Not sure I understand this completely. Isn't support for "the Rube Goldberg Machine" needed only on platforms that do not natively support H.264? 

On Nov 1, 2013, at 1:14 PM, "Justin Uberti" <juberti@google.com> wrote:

I also want to reiterate that having a MTI codec means Mandatory To Implement.

That means, that should we decide to go down the H.264 path, Firefox and others will be forced to support this Rube Goldberg machine for obtaining H.264 for an indeterminate amount of time, long after WebRTC has moved on to prefer other codecs.


On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach <adam@nostrum.com> wrote:
On 10/31/13 13:47, Harald Alvestrand wrote:

We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.


Google still believes that VP8 - a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today - is the best choice of a Mandatory to Implement video codec for the WebRTC effort.


I agree with Harald that VP8 is a better codec than H.264 baseline in a number of important ways.

But I also want to reiterate that having an MTI codec has never been about choosing the best codec or even a good codec. It's about choosing an emergency backup codec-of-last-resort. It's about having one single mandated codec that everyone has in their back pocket in case nothing else works.

The core of RTCWEB is about session *negotiation*. Endpoints will negotiate the best codec they have in common. Once the next generation of codecs come out, this "best codec in common" will only be the MTI if they were about to fail anyway.

So it doesn't have to be good.

It just has to be better than failure.

/a

_______________________________________________
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
--Apple-Mail-630E53EC-A98D-430D-B40B-3E244563577B-- --_31613545-3037-4d17-b5e0-96c949e252e4_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_31613545-3037-4d17-b5e0-96c949e252e4_-- From petithug@acm.org Sat Nov 2 04:45:17 2013 Return-Path: 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 C7B9811E81E9 for ; Sat, 2 Nov 2013 04:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 wH+xBHZwbtg9 for ; Sat, 2 Nov 2013 04:45:17 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id CD7B821E80C0 for ; Sat, 2 Nov 2013 04:45:10 -0700 (PDT) Received: from [IPv6:2001:5c0:1101:2d00:acfb:2240:b8ac:e08e] (unknown [IPv6:2001:5c0:1101:2d00:acfb:2240:b8ac:e08e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 7A3DF2025A; Sat, 2 Nov 2013 12:45:06 +0100 (CET) Message-ID: <5274E5C0.3090803@acm.org> Date: Sat, 02 Nov 2013 05:45:04 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: Harald Alvestrand References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 11:45:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 +1. +1 also on everything Lorenzo said. On 10/31/2013 12:47 PM, Harald Alvestrand wrote: > We congratulate Cisco on their intention to make an open source H.264 > codec available and usable by the community. We look forward to seeing the > result of this effort. > > > Google still believes that VP8 - a freely available, fully open, > high-quality video codec that you can download, compile for your platform, > include in your binary, distribute and put into production today - is the > best choice of a Mandatory to Implement video codec for the WebRTC effort. > > > Harald (sending this from my Google address) > > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSdOW5AAoJECnERZXWan7E5wsP/iwQtvHwEHjJWTDA4GwjrLU1 LmdGaFmxKdSifOuvTId7fBa69zl2DNtB2W+QOyiwLknIApjBTSTEPd48RGZmOwnq fN/5l4aL4tCL+oXOBrSb1mg05H+6TLqhFurF3oUR7SGXCAdjJuL122yhuLSH3n+/ kgzQOo12xOu5cDVYrIk0dhevf/sgclpwH+64ALnZDvS3QmvOuSWDMi5F27NFnrTa 4FTnTrfOv4cpNVcYqyziLvdIsWWBbdXUfalCoiiBfQ4vMX56EshSRavdvXE7F/Zt T/U1flhgtae981wV86NMNm1gXVWBwXqBKN5VyU/YHijff2qyyYRoKG94j2Hh9CDN y2yu0611t+41SdKAcQOFVCPT4Qg7lvoPSYYJM0/avfu+NKbAz/t9ZpFj1PrO8o+h TtRZ+G6xcKQmrqfD0euUYNn0LJrTBhmpHq5gmGp6LaoLw+ZfuwDoNgbn3eDJofMB rjTzr/MbOayxX/Oruar7fu/H/BoyfLzXLo2aZ1wu49p9FbZ1tWBp2uNGN87rROe1 1bQWBiVaOMaf7wQC7oqftQWiRHM54XGtGQ9j1vsbJCzy9dvfwebR9vrb9HUv192T qnEUWpruJWYct6XVybsbtUFnO1U+HwUZY4K661XrylYxpibu6xzebRRnPjl3wsUY 6FjgvIofnvs/YU30pBqd =zqbx -----END PGP SIGNATURE----- From lgeyser@gmail.com Sat Nov 2 04:56:42 2013 Return-Path: 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 A8EAC11E81F7 for ; Sat, 2 Nov 2013 04:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5Z-IhDt1-EOI for ; Sat, 2 Nov 2013 04:56:41 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1A20A21E8095 for ; Sat, 2 Nov 2013 04:56:37 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so4271377lbj.3 for ; Sat, 02 Nov 2013 04:56:31 -0700 (PDT) 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=S9p2QRqOhtWOjF4jR6wEj2ncRj1DVRT6vMtcb5t/UPU=; b=ZYJcvSHJ22XBK6PDpf3Khj29RXIJjnhQIKSkYcVKnZl1eeB/h/2rkxtTfYDbvNyRKc bkOOHWlxJhKfdOMToS+YnqjRmpyGB4qLIquD278LHQ52AHPnTxvwVUqvxEXdzK3I8t/c o+8EkTccw4plN4ascX/3sx4tHrV1EKW3WIKtIpg/l3B9c54x+n4ohhHwayRxvf9xNOij 03M7NwZzRIet5yHskhrdqQW5Mz3TFCg7FSVhRwcsAloZqbpMRRoCU96owOAzzRsNzXvE yakimd646ASpeIFaLknqG42fPy48/z6+CaaD3nsUa6lNs/3l1flWVnMi5a6slJLiSi4M 4eyw== MIME-Version: 1.0 X-Received: by 10.112.157.67 with SMTP id wk3mr92854lbb.62.1383393391481; Sat, 02 Nov 2013 04:56:31 -0700 (PDT) Received: by 10.114.168.70 with HTTP; Sat, 2 Nov 2013 04:56:31 -0700 (PDT) In-Reply-To: References: <52740478.6030109@nostrum.com> Date: Sat, 2 Nov 2013 13:56:31 +0200 Message-ID: From: Leon Geyser To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a11c3409caf18f404ea305fd5 Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 11:56:42 -0000 --001a11c3409caf18f404ea305fd5 Content-Type: text/plain; charset=ISO-8859-1 Like Firefox and Opera...and the browser I might create in the future? :) Firefox only has decoding support on some platforms, because it uses the operating system's H.264 decoder if it has one so far as I know. On 2 November 2013 13:31, Bernard Aboba wrote: > Not sure I understand this completely. Isn't support for "the Rube > Goldberg Machine" needed only on platforms that do not natively support > H.264? > > On Nov 1, 2013, at 1:14 PM, "Justin Uberti" wrote: > > I also want to reiterate that having a MTI codec means Mandatory To > Implement. > > That means, that should we decide to go down the H.264 path, Firefox and > others will be forced to support this Rube Goldberg machine for obtaining > H.264 for an indeterminate amount of time, long after WebRTC has moved on > to prefer other codecs. > > > On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach wrote: > >> On 10/31/13 13:47, Harald Alvestrand wrote: >> >> We congratulate Cisco on their intention to make an open source H.264 >> codec available and usable by the community. We look forward to seeing the >> result of this effort. >> >> Google still believes that VP8 - a freely available, fully open, >> high-quality video codec that you can download, compile for your platform, >> include in your binary, distribute and put into production today - is the >> best choice of a Mandatory to Implement video codec for the WebRTC effort. >> >> >> I agree with Harald that VP8 is a better codec than H.264 baseline in a >> number of important ways. >> >> But I also want to reiterate that having an MTI codec has never been >> about choosing the best codec or even a good codec. It's about choosing an >> emergency backup codec-of-last-resort. It's about having one single >> mandated codec that everyone has in their back pocket in case nothing else >> works. >> >> The core of RTCWEB is about session *negotiation*. Endpoints will >> negotiate the best codec they have in common. Once the next generation of >> codecs come out, this "best codec in common" will only be the MTI if they >> were about to fail anyway. >> >> So it doesn't have to be good. >> >> It just has to be better than failure. >> >> /a >> >> _______________________________________________ >> 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 > > --001a11c3409caf18f404ea305fd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Like Firefox and Opera...and the browser I might create in= the future? :)
Firefox only has de= coding support on some platforms, because it uses the operating system'= s H.264 decoder if it has one so far as I know.

On 2 Novemb= er 2013 13:31, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
Not sure I understand= this completely. Isn't support for "the Rube Goldberg Machine&quo= t; needed only on platforms that do not natively support H.264?=A0

On Nov 1, 2013, at 1:14 PM, "Justin Ub= erti" <jube= rti@google.com> wrote:

<= div dir=3D"ltr"> I also want to reiterate that having a MTI codec means Mandatory To Impleme= nt.

That means, that should we decide to go down the H.2= 64 path, Firefox and others will be forced to support this Rube Goldberg ma= chine for obtaining H.264 for an indeterminate amount of time, long after W= ebRTC has moved on to prefer other codecs.


On Fri,= Nov 1, 2013 at 12:43 PM, Adam Roach <adam@nostrum.com> wrote= :
=20 =20 =20
On 10/31/13 13:47, Harald Alvestrand wrote:

We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.

Google still believes that VP8 - a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today - is the best choice of a Mandatory to Implement video codec for the WebRTC effort.


I agree with Harald that VP8 is a better codec than H.264 baseline in a number of important ways.

But I also want to reiterate that having an MTI codec has never been about choosing the best codec or even a good codec. It's about choosing an emergency backup codec-of-last-resort. It's about havin= g one single mandated codec that everyone has in their back pocket in case nothing else works.

The core of RTCWEB is about session *negotiation*. Endpoints will negotiate the best codec they have in common. Once the next generation of codecs come out, this "best codec in common" wi= ll only be the MTI if they were about to fail anyway.

So it doesn't have to be good.

It just has to be better than failure.
/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


___________________= ____________________________
rtcweb mailing list
= rtcweb@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/rtcweb

____________________________________________= ___
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--001a11c3409caf18f404ea305fd5-- From karl.stahl@intertex.se Sat Nov 2 05:04:44 2013 Return-Path: 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 1E6A121E80E1 for ; Sat, 2 Nov 2013 05:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1] 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 2zCxPsYFemgy for ; Sat, 2 Nov 2013 05:04:39 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 28AD321E80BE for ; Sat, 2 Nov 2013 05:04:38 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201311021304351188 for ; Sat, 02 Nov 2013 13:04:35 +0100 From: "Karl Stahl" To: References: <52740478.6030109@nostrum.com> <20131101211922.3ed7833d@rainpc> <5274CF96.4050203@unina.it> In-Reply-To: <5274CF96.4050203@unina.it> Date: Sat, 2 Nov 2013 13:04:33 +0100 Message-ID: <0b2901ced7c3$b1985c70$14c91550$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7Xs85DbF2lu5AzQNmHLqSUx77grQACfZEw Content-Language: sv Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 12:04:44 -0000 >From below:> "will *only* provide H.264, thus forcing everyone to comply with it. Who's going to do anything else, when you know the only way to reach all browsers is *the* codec?" --- That fear should not be underestimated: Compare telephony, where = 3.5kHz G.711 still is 99% of the traffic, and use of wide band audio codecs to reach 7kHz AM-radio quality between two different carriers is yet to be = seen (in spite of IP/IMS/VoLTE)...=20 I thanked Cisco for their free H.264 offering - WebRTC needs video compatibility when connecting with existing services - but many thanks = to Google also: That free baseline H.264 would hardly have happened without their free VP8 offering... Note that neither free H.264 nor free VP8 are conditioned any one of = them being selected MTI! For compatibility using Cisco's free H.264 offering, the codec plug-in = slot and download of a H.264 codec are required, so that must be made = mandatory, must it not? Then, when minimum video compatibility thus is assured, maybe IETF could reach consensus about a free and good video codec that could be included = in a WebRTC browser from the beginning? BTW: In an IETF recommendation, mustn't such codec plug-in slot be open = for more than download from Cisco and for more than H.264 baseline? And, with compatibility assured, wouldn't VP9 be an even better video = codec MTI? /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Alessandro Amirante Skickat: den 2 november 2013 11:10 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Congratuiations on the Cisco announcement - but we = still prefer VP8 Il 01/11/2013 21:19, Lorenzo Miniero ha scritto: > On Fri, 01 Nov 2013 14:43:52 -0500 > Adam Roach wrote: > >> On 10/31/13 13:47, Harald Alvestrand wrote: >>> >>> We congratulate Cisco on their intention to make an open source=20 >>> H.264 codec available and usable by the community. We look forward=20 >>> to seeing the result of this effort. >>> >>> >>> Google still believes that VP8 - a freely available, fully open,=20 >>> high-quality video codec that you can download, compile for your=20 >>> platform, include in your binary, distribute and put into production = >>> today - is the best choice of a Mandatory to Implement video codec=20 >>> for the WebRTC effort. >>> >> >> I agree with Harald that VP8 is a better codec than H.264 baseline in = >> a number of important ways. >> >> But I also want to reiterate that having an MTI codec has never been=20 >> about choosing the best codec or even a good codec. It's about=20 >> choosing an emergency backup codec-of-last-resort. It's about having=20 >> one single mandated codec that everyone has in their back pocket in=20 >> case nothing else works. >> >> The core of RTCWEB is about session *negotiation*. Endpoints will=20 >> negotiate the best codec they have in common. Once the next=20 >> generation of codecs come out, this "best codec in common" will only=20 >> be the MTI if they were about to fail anyway. >> >> So it doesn't have to be good. >> >> It just has to be better than failure. >> >> /a > > > Those are good points. But were that the case, we could have sticked = with an older codec, one that didn't have to carry the burden of royalty = fees: a choice that several people have often discarded exactly because it = wasn't good enough. I could not agree more. > > That's also why I, as it is probably redundant to restate, actually support Harald's view. My concern is that, with H.264, MTI will not mean = *a* codec in a negotiatiated session, which is what we all agree RTCWEB = still is, or should be. It will be *the* codec, because several = implementations, including two currently missing browsers (whenever they'll start to = care), will *only* provide H.264, thus forcing everyone to comply with it. = Who's going to do anything else, when you know the only way to reach all = browsers is *the* codec? And for a lot of people, including me, there's currently = (or actually, will be) only one way to do so, which is a plugin (in RTCWEB, ironic) that may or may not be available two months after we start using = it. +1 for VP8 as MTI. Alessandro > > I'm at the wrong edge of the knife, and I don't like it. > > Lorenzo > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Alessandro Amirante, Ph.D. Dipartimento di Ingegneria Elettrica e delle Tecnologie = dell'Informazione Universita' degli Studi di Napoli "Federico II" Via Claudio, 21 - 80125 Napoli - Italy Phone: +39 081 7683821 Fax: +39 081 19730464 E-mail: alessandro.amirante@unina.it Skype-ID: alessandro.amirante Web: http://wpage.unina.it/alessandro.amirante _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ron@debian.org Sat Nov 2 05:48:23 2013 Return-Path: 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 CEB9211E81F0 for ; Sat, 2 Nov 2013 05:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] 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 lf+1-HKjv0-6 for ; Sat, 2 Nov 2013 05:48:12 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 201F611E8118 for ; Sat, 2 Nov 2013 05:48:11 -0700 (PDT) Received: from ppp118-210-230-117.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.230.117]) by ipmail05.adl6.internode.on.net with ESMTP; 02 Nov 2013 23:18:09 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 5DDB24F8F3 for ; Sat, 2 Nov 2013 23:18:02 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gopQNJssJm-Q for ; Sat, 2 Nov 2013 23:18:01 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id C3C444F902; Sat, 2 Nov 2013 23:18:01 +1030 (CST) Date: Sat, 2 Nov 2013 23:18:01 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131102124801.GY3245@audi.shelbyville.oz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 12:48:24 -0000 On Thu, Oct 31, 2013 at 07:47:31PM +0100, Harald Alvestrand wrote: > We congratulate Cisco on their intention to make an open source H.264 codec > available and usable by the community. We look forward to seeing the result > of this effort. > > Google still believes that VP8 - a freely available, fully open, > high-quality video codec that you can download, compile for your platform, > include in your binary, distribute and put into production today - is the > best choice of a Mandatory to Implement video codec for the WebRTC effort. This is my belief also. While the Cisco announcement is certainly an interesting approach to trying to extricate their existing technology investment from the deep quagmire of encumbrances that currently bind it, the result still falls well short of not only the ideal, but also the already existing alternative choices that we have available to us. Given the choice between a genuinely Free option, that anyone is free to improve and distribute however they wish - and a no-cost binary-only option that is available from only a single supplier, while Happy Hour lasts - the decision still seems to be something of a no-brainer. Even before you also consider that the Free Option is not constrained to only its lowest possible performance mode in the implementation that is available to people today. VP8 still seems like the only obvious and enduring choice for an MTI codec for WebRTC at present. Ron From bernard_aboba@hotmail.com Sat Nov 2 07:00:55 2013 Return-Path: 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 57E9111E8115 for ; Sat, 2 Nov 2013 07:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.579 X-Spam-Level: X-Spam-Status: No, score=-101.579 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 SfiDECcmkehV for ; Sat, 2 Nov 2013 07:00:51 -0700 (PDT) Received: from blu0-omc1-s7.blu0.hotmail.com (blu0-omc1-s7.blu0.hotmail.com [65.55.116.18]) by ietfa.amsl.com (Postfix) with ESMTP id B967721F9EF6 for ; Sat, 2 Nov 2013 07:00:50 -0700 (PDT) Received: from BLU406-EAS30 ([65.55.116.8]) by blu0-omc1-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Nov 2013 07:00:49 -0700 X-TMN: [UcuA4n1gDexX58XZwP61W8F7LaPdx5NN] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_56033a74-d7ba-493e-9a5a-3e452f8b1fc3_" References: From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Sat, 2 Nov 2013 07:00:48 -0700 To: Emil Ivov X-OriginalArrivalTime: 02 Nov 2013 14:00:49.0891 (UTC) FILETIME=[EFA43330:01CED7D3] Cc: Harald Tveit Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 14:00:55 -0000 --_56033a74-d7ba-493e-9a5a-3e452f8b1fc3_ Content-Type: multipart/alternative; boundary="Apple-Mail-EF0C96BB-D4FF-454C-90A8-A33FFA71769A" Content-Transfer-Encoding: 7bit --Apple-Mail-EF0C96BB-D4FF-454C-90A8-A33FFA71769A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Those enterprise scenarios often either involve a defined software image tha= t could include the Cisco plugin (does it always have to be downloaded?) OR i= nvolve a relatively recent OS, with native H.264 support. So I am not sure t= his need come up that often. > On Nov 2, 2013, at 3:35 AM, "Emil Ivov" wrote: > Also, while Cisco's grant is quite interesting for certain scenarios it co= uld be very problematic for others. For example: enterprises where installat= ions are handled in a controlled and automated way (e.g. scripted image depl= oyment) and where subsequent Internet access could be limited for various re= asons.=20 >=20 > Emil >=20 > -- > https://jitsi.org >=20 > On 31 Oct 2013 19:48, "Harald Alvestrand" wrote: > > > > We congratulate Cisco on their intention to make an open source H.264 co= dec available and usable by the community. We look forward to seeing the res= ult of this effort. > > > > > > Google still believes that VP8 - a freely available, fully open, high-qu= ality video codec that you can download, compile for your platform, include i= n your binary, distribute and put into production today - is the best choice= of a Mandatory to Implement video codec for the WebRTC effort. > > > > > > Harald (sending this from my Google address) > > > > > > _______________________________________________ > > 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 --Apple-Mail-EF0C96BB-D4FF-454C-90A8-A33FFA71769A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
Those enterprise scenarios often either involve a defined software image that could include the Cisco plugin (does it always have to be downloaded?) OR involve a relatively recent OS, with native H.264 support. So I am not sure this need come up that often.

On Nov 2, 2013, at 3:35 AM, "Emil Ivov" <emcho@jitsi.org> wrote:

Also, while Cisco's grant is quite interesting for certain scenarios it could be very problematic for others. For example: enterprises where installations are handled in a controlled and automated way (e.g. scripted image deployment) and where subsequent Internet access could be limited for various reasons. 

Emil

--
https://jitsi.org

On 31 Oct 2013 19:48, "Harald Alvestrand" <hta@google.com> wrote:
>
> We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.
>
>
> Google still believes that VP8 - a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today - is the best choice of a Mandatory to Implement video codec for the WebRTC effort.
>
>
> Harald (sending this from my Google address)
>
>
> _______________________________________________
> 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
--Apple-Mail-EF0C96BB-D4FF-454C-90A8-A33FFA71769A-- --_56033a74-d7ba-493e-9a5a-3e452f8b1fc3_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_56033a74-d7ba-493e-9a5a-3e452f8b1fc3_-- From ekr@rtfm.com Sat Nov 2 07:10:03 2013 Return-Path: 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 06BB011E80E3 for ; Sat, 2 Nov 2013 07:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.772 X-Spam-Level: X-Spam-Status: No, score=-102.772 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 s7FElrmI78rX for ; Sat, 2 Nov 2013 07:09:58 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id BB78D11E8115 for ; Sat, 2 Nov 2013 07:09:57 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id f4so2157812wiw.10 for ; Sat, 02 Nov 2013 07:09:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8lySq0j0aK4PeEoZ8jnIoUkBysylyhgbiChJUaPpbPk=; b=g4/bnxqfnkYIoU7Jy6I8CepfxLDStpqA4EtloALYRrBs4wiRIcPBqtQvHk6DlMVbii PqYnSO5CMaq1n3L74wZGQoIk+KBx5hroifikZzmt+OpMiFmHAOVPGt6k/CtPRnUab/Hq UcsbiXKDjQ7KJ1uJS4r7Cs+LGqtI7ltx93DSdtRM43VOqjnXj7/jspajXvUlGhKpv5Qz z7UC0mgsqeMzAejsD9Di1ZT5sLd+FhdObjpP/ANH+7m5O7My9DKXt4u9CFnSauHZEgBn rB3rv3IyNc+15vJ/5sBdbb5Yp5e1DVdvKPJeMFXvqhW3oS53k7UP6hWlkZldaSyxPGUr A7ig== X-Gm-Message-State: ALoCoQnNKgDG0JJ7Y3hkmNNQCF9CL5ddopuPlwKzytr6stHs5ysaEhaVT99BLs1KG5egCARXdG2f X-Received: by 10.180.24.137 with SMTP id u9mr5853059wif.5.1383401396173; Sat, 02 Nov 2013 07:09:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Sat, 2 Nov 2013 07:09:16 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <52740478.6030109@nostrum.com> From: Eric Rescorla Date: Sat, 2 Nov 2013 07:09:16 -0700 Message-ID: To: Leon Geyser Content-Type: multipart/alternative; boundary=f46d04447f67cd027604ea323cff Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 14:10:03 -0000 --f46d04447f67cd027604ea323cff Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 2, 2013 at 4:56 AM, Leon Geyser wrote: > Like Firefox and Opera...and the browser I might create in the future? :) > Firefox only has decoding support on some platforms, because it uses the > operating system's H.264 decoder if it has one so far as I know. > I anticipate that Firefox will use HW codecs on phones. We haven't determined what we will do on operating systems with good H.264 codecs built in to the platform. -Ekr On 2 November 2013 13:31, Bernard Aboba wrote: > >> Not sure I understand this completely. Isn't support for "the Rube >> Goldberg Machine" needed only on platforms that do not natively support >> H.264? >> >> On Nov 1, 2013, at 1:14 PM, "Justin Uberti" wrote: >> >> I also want to reiterate that having a MTI codec means Mandatory To >> Implement. >> >> That means, that should we decide to go down the H.264 path, Firefox and >> others will be forced to support this Rube Goldberg machine for obtaining >> H.264 for an indeterminate amount of time, long after WebRTC has moved on >> to prefer other codecs. >> >> >> On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach wrote: >> >>> On 10/31/13 13:47, Harald Alvestrand wrote: >>> >>> We congratulate Cisco on their intention to make an open source H.264 >>> codec available and usable by the community. We look forward to seeing the >>> result of this effort. >>> >>> Google still believes that VP8 - a freely available, fully open, >>> high-quality video codec that you can download, compile for your platform, >>> include in your binary, distribute and put into production today - is the >>> best choice of a Mandatory to Implement video codec for the WebRTC effort. >>> >>> >>> I agree with Harald that VP8 is a better codec than H.264 baseline in a >>> number of important ways. >>> >>> But I also want to reiterate that having an MTI codec has never been >>> about choosing the best codec or even a good codec. It's about choosing an >>> emergency backup codec-of-last-resort. It's about having one single >>> mandated codec that everyone has in their back pocket in case nothing else >>> works. >>> >>> The core of RTCWEB is about session *negotiation*. Endpoints will >>> negotiate the best codec they have in common. Once the next generation of >>> codecs come out, this "best codec in common" will only be the MTI if they >>> were about to fail anyway. >>> >>> So it doesn't have to be good. >>> >>> It just has to be better than failure. >>> >>> /a >>> >>> _______________________________________________ >>> 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 > > --f46d04447f67cd027604ea323cff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 2, 2013 at 4:56 AM,= Leon Geyser <lgeyser@gmail.com> wrote:
Like Firefox and Opera...an= d the browser I might create in the future? :)
Firefox only has decoding support on some platforms, because it uses the op= erating system's H.264 decoder if it has one so far as I know.

I anticipate that Firefox w= ill use HW codecs on phones. We haven't
determined what we will do on operating systems with good H.264
<= div>codecs built in to the platform.

-Ekr

On 2 November 2013 13:31, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
Not sure I understand= this completely. Isn't support for "the Rube Goldberg Machine&quo= t; needed only on platforms that do not natively support H.264?=A0

On Nov 1, 2013, at 1:14 PM, "Justin Uberti" &l= t;juberti@google.co= m> wrote:

I also want to reiterate that having a MTI codec means Mandatory To Impleme= nt.

That means, that should we decide to go down the H.2= 64 path, Firefox and others will be forced to support this Rube Goldberg ma= chine for obtaining H.264 for an indeterminate amount of time, long after W= ebRTC has moved on to prefer other codecs.


On Fri,= Nov 1, 2013 at 12:43 PM, Adam Roach <adam@nostrum.com> wrote= :
=20 =20 =20
On 10/31/13 13:47, Harald Alvestrand wrote:

We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.

Google still believes that VP8 - a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today - is the best choice of a Mandatory to Implement video codec for the WebRTC effort.


I agree with Harald that VP8 is a better codec than H.264 baseline in a number of important ways.

But I also want to reiterate that having an MTI codec has never been about choosing the best codec or even a good codec. It's about choosing an emergency backup codec-of-last-resort. It's about havin= g one single mandated codec that everyone has in their back pocket in case nothing else works.

The core of RTCWEB is about session *negotiation*. Endpoints will negotiate the best codec they have in common. Once the next generation of codecs come out, this "best codec in common" wi= ll only be the MTI if they were about to fail anyway.

So it doesn't have to be good.

It just has to be better than failure.
/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


___________________= ____________________________
rtcweb mailing list
= rtcweb@ietf.org<= /a>
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


--f46d04447f67cd027604ea323cff-- From cowwoc@bbs.darktech.org Sat Nov 2 07:38:06 2013 Return-Path: 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 EF1D521F9DAF for ; Sat, 2 Nov 2013 07:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.944 X-Spam-Level: X-Spam-Status: No, score=-4.944 tagged_above=-999 required=5 tests=[AWL=-1.346, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 rZxx5-Ai7ISI for ; Sat, 2 Nov 2013 07:38:01 -0700 (PDT) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 85E7D21F9F5B for ; Sat, 2 Nov 2013 07:37:57 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id u16so9454387iet.18 for ; Sat, 02 Nov 2013 07:37:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=q+Ni8iFZQW5sT+BytRvFFqGeinGoHI48n2MPvDi9AA8=; b=jZu5wZKkusTWUMNUOXJg4HuRdmEzANVLUJ+jT7Lt8IaMMjXwhG4/3cnX6vjyTmN2v2 smk0yR2XJK80RnSDZxX9J+69/S8ntpiOtALcOLMr4mq+iiyYb2aDZ+C1eXaONWD716g/ kjUSppQOd6Sdl2RmQ18GNUnvRi3CSoGtXWoCYFbS6PbsbavEWi6APXliuLZzW+Q4hw2p 9r4b7YMD+zys/HUqriABI1ryNg83PyT8d2j6xyhQBF3g4HjcaoLFtntYhMNVdjOLQ9XD bnRESjG1o5ubkquoawqASuhubEzgx7wY4p8mui9Yu4fspaB0hBjTVt1/cWl5kwDIwBzW yu2A== X-Gm-Message-State: ALoCoQnQNCOisvHEclDryevWv3sQrYZyPQV1zaJi/OCvrsHb818ZoUFT+0Q7Kw2EPfOvGhsNNAdU X-Received: by 10.42.215.11 with SMTP id hc11mr571523icb.47.1383403074290; Sat, 02 Nov 2013 07:37:54 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id k6sm10289446igx.8.2013.11.02.07.37.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 07:37:53 -0700 (PDT) Message-ID: <52750E3C.9060206@bbs.darktech.org> Date: Sat, 02 Nov 2013 10:37:48 -0400 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: rtcweb@ietf.org References: <52740478.6030109@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040100090500070609070704" Subject: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 14:38:06 -0000 This is a multi-part message in MIME format. --------------040100090500070609070704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit How many platforms *really* support H.264 natively today? iOS is a great example. On paper, it supports H.264 but in reality the public API only supports H.264 decoding (not encoding). Then, when you try using that API for decoding you discover that it does not support real-time decoding (only decoding from file). So really, iOS doesn't actually support H.264 as required by WebRTC. Android is only marginally better in that respect. I can't think of a single platform that supports real-time H.264 encoding/decoding natively today. Gili On 02/11/2013 7:31 AM, Bernard Aboba wrote: > Not sure I understand this completely. Isn't support for "the Rube > Goldberg Machine" needed only on platforms that do not natively > support H.264? > > On Nov 1, 2013, at 1:14 PM, "Justin Uberti" > wrote: > >> I also want to reiterate that having a MTI codec means Mandatory To >> Implement. >> >> That means, that should we decide to go down the H.264 path, Firefox >> and others will be forced to support this Rube Goldberg machine for >> obtaining H.264 for an indeterminate amount of time, long after >> WebRTC has moved on to prefer other codecs. >> >> >> On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach > > wrote: >> >> On 10/31/13 13:47, Harald Alvestrand wrote: >>> >>> We congratulate Cisco on their intention to make an open source >>> H.264 codec available and usable by the community. We look >>> forward to seeing the result of this effort. >>> >>> >>> Google still believes that VP8 - a freely available, fully open, >>> high-quality video codec that you can download, compile for your >>> platform, include in your binary, distribute and put into >>> production today - is the best choice of a Mandatory to >>> Implement video codec for the WebRTC effort. >>> >> >> I agree with Harald that VP8 is a better codec than H.264 >> baseline in a number of important ways. >> >> But I also want to reiterate that having an MTI codec has never >> been about choosing the best codec or even a good codec. It's >> about choosing an emergency backup codec-of-last-resort. It's >> about having one single mandated codec that everyone has in their >> back pocket in case nothing else works. >> >> The core of RTCWEB is about session *negotiation*. Endpoints will >> negotiate the best codec they have in common. Once the next >> generation of codecs come out, this "best codec in common" will >> only be the MTI if they were about to fail anyway. >> >> So it doesn't have to be good. >> >> It just has to be better than failure. >> >> /a >> >> _______________________________________________ >> 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 --------------040100090500070609070704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    How many platforms *really* support H.264 natively today?

    iOS is a great example. On paper, it supports H.264 but in reality the public API only supports H.264 decoding (not encoding). Then, when you try using that API for decoding you discover that it does not support real-time decoding (only decoding from file). So really, iOS doesn't actually support H.264 as required by WebRTC. Android is only marginally better in that respect.

    I can't think of a single platform that supports real-time H.264 encoding/decoding natively today.

Gili

On 02/11/2013 7:31 AM, Bernard Aboba wrote:
Not sure I understand this completely. Isn't support for "the Rube Goldberg Machine" needed only on platforms that do not natively support H.264? 

On Nov 1, 2013, at 1:14 PM, "Justin Uberti" <juberti@google.com> wrote:

I also want to reiterate that having a MTI codec means Mandatory To Implement.

That means, that should we decide to go down the H.264 path, Firefox and others will be forced to support this Rube Goldberg machine for obtaining H.264 for an indeterminate amount of time, long after WebRTC has moved on to prefer other codecs.


On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach <adam@nostrum.com> wrote:
On 10/31/13 13:47, Harald Alvestrand wrote:

We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.


Google still believes that VP8 - a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today - is the best choice of a Mandatory to Implement video codec for the WebRTC effort.


I agree with Harald that VP8 is a better codec than H.264 baseline in a number of important ways.

But I also want to reiterate that having an MTI codec has never been about choosing the best codec or even a good codec. It's about choosing an emergency backup codec-of-last-resort. It's about having one single mandated codec that everyone has in their back pocket in case nothing else works.

The core of RTCWEB is about session *negotiation*. Endpoints will negotiate the best codec they have in common. Once the next generation of codecs come out, this "best codec in common" will only be the MTI if they were about to fail anyway.

So it doesn't have to be good.

It just has to be better than failure.

/a

_______________________________________________
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

--------------040100090500070609070704-- From martin.thomson@gmail.com Sat Nov 2 07:39:26 2013 Return-Path: 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 12C9321F9F5B for ; Sat, 2 Nov 2013 07:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, 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 IZ+C6WCwYaUx for ; Sat, 2 Nov 2013 07:39:25 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA0211E80E3 for ; Sat, 2 Nov 2013 07:38:57 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id x55so561379wes.36 for ; Sat, 02 Nov 2013 07:38:52 -0700 (PDT) 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=VfVn+lxGSViqHSuSicENlfoJNjxMBWgSekV9lHYVEpg=; b=GxYaFxo/8z+XHNMalnOtj07irr1QMT9SjzPJSRLPxJYJxCUnzqZHLRHZzCU4leAQ// McjhO8y1KlTkx71qoOz3TiuiGLK0KoCdHOPsBy5tVWmV3aaFn1HYPDzr8IfCpzU5hPja VrJrGVYgW69SRtsmsXgqDWlAMhTjZ+wyjmT2wQwDlcHReCMbYwWlqurRMb0JBVVyjSXz lzrNdjygLhe+lfZm3Sjs4BmMVNTMNjwHiK0RDRsFJI44r9UnnddtqAhvzSgT0D+m8IPK JnFz31RABorwAouYlsv4a0SDXlodvhmx/PxDjXFros2SphBXegLNlYAVkyhub1EWKSYh yS/w== MIME-Version: 1.0 X-Received: by 10.180.109.75 with SMTP id hq11mr5886999wib.30.1383403132628; Sat, 02 Nov 2013 07:38:52 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Sat, 2 Nov 2013 07:38:52 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Nov 2013 07:38:52 -0700 Message-ID: From: Martin Thomson To: Silvia Pfeiffer Content-Type: text/plain; charset=UTF-8 Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 14:39:26 -0000 On 2 November 2013 02:26, Silvia Pfeiffer wrote: > (is the vote on the MTI codec going to happen via email?) I still hold out hope that a vote will not be necessary. From martin.thomson@gmail.com Sat Nov 2 08:03:01 2013 Return-Path: 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 F04D021F9344 for ; Sat, 2 Nov 2013 08:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, 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 Hei14zmQ4F6m for ; Sat, 2 Nov 2013 08:03:01 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE1721F933B for ; Sat, 2 Nov 2013 08:03:01 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id ez12so2171525wid.15 for ; Sat, 02 Nov 2013 08:02:56 -0700 (PDT) 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=9uIIevs8GSiwL73GIJtEVi1a8kJjPIH0xjTjZnoMMWM=; b=vZAGSWpSBoUbVv1R08jou8x/7DnqVrc7CBrbSIyGTVpx07riFrIN+LyVBApsMTgLlO EPj1F5oAowbL99zZ1Y3579So34bbeic111/J3nlufTAA33yvY475n0W0u0gnzMSL924X nZO4gw9Oomf2tSZmptyIbwXU/B7hExZm3ifkTkrrhK3UZfmaeCYkGqh35osojh3v/nIj nNbNZ3OCqhCt1fW9YtOxfBaTVR6TvmfuZIL9nqwbrkSnUw179TmBl2+9LYP5qBWEh4BM xmofasTFbz7xAwVjsqzfGV7L6Elt8Q6v6x+jzU51BXNV7a0MZRmRFyY+3XS3DQXF1D5Z ri1Q== MIME-Version: 1.0 X-Received: by 10.194.239.40 with SMTP id vp8mr143321wjc.45.1383404576049; Sat, 02 Nov 2013 08:02:56 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Sat, 2 Nov 2013 08:02:56 -0700 (PDT) In-Reply-To: <52750E3C.9060206@bbs.darktech.org> References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> Date: Sat, 2 Nov 2013 08:02:56 -0700 Message-ID: From: Martin Thomson To: cowwoc Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 15:03:02 -0000 On 2 November 2013 07:37, cowwoc wrote: > I can't think of a single platform that supports real-time H.264 > encoding/decoding natively today. That's a very strange way to put the question. Let me put another spin on it, and please excuse the example... Skype runs on more platforms than you might think. Those platforms can all support H.264 to the extent that Skype requires. Cisco's generous offer opens almost the same capability to anyone, with the caveat that some platforms currently remain closed. Of course, you could let your ideals get in the way of progress. Me, I'm a pragmatist. This gift represents a great opportunity for people who actually care about the practical outcomes. There's been a lot of mouth-gazing of gift horses on this list of late. I sure hope that this isn't representative of the real sentiment of the community. I'd like to think that people are better than that. (BTW, I understand and respect Harald's position. From where he sits, I'm sure that his conclusion makes perfect sense.) From jlaurens@cisco.com Sat Nov 2 08:16:47 2013 Return-Path: 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 B1B1A21F8445 for ; Sat, 2 Nov 2013 08:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.371 X-Spam-Level: X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 tLLwyATrpUnA for ; Sat, 2 Nov 2013 08:16:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E427D21E80CF for ; Sat, 2 Nov 2013 08:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12010; q=dns/txt; s=iport; t=1383405386; x=1384614986; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4VhAopAdpIrQ5G3njxl8x/KMwqPb9tiuospb/TmhxKI=; b=G/kpt9TqhqXdwaFQ239mD9gNK5NMhGu7pfdMgL6V1+2sO3b/NR+QOIGM Gf+RZODXzLB8zigMvnDdbDoSvn7woNhLoCHGGMyup+N3K57Xw2OUk6ruq ujcI3QDstkHHES2Wo3ilmh5sOrExZZCRwQQFOIL7Y52ak2x8dJSY05ggA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8GABgWdVKtJV2b/2dsb2JhbABZgkNEOKxFk0BLgRwWdIImAQEEAQEBawsQAgEIOwQHJwsUEQIEDgUUh20NvTMEjgaBTgQHgyCBDgOYCpIJgWiBPg X-IronPort-AV: E=Sophos;i="4.93,622,1378857600"; d="scan'208,217";a="279793268" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 02 Nov 2013 15:16:25 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA2FGPoF010405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Nov 2013 15:16:25 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Sat, 2 Nov 2013 10:16:24 -0500 From: "Jeremy Laurenson (jlaurens)" To: cowwoc Thread-Topic: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) Thread-Index: AQHO19kpBk13xO4pgUCS+AgMzHheL5oSDUlc Date: Sat, 2 Nov 2013 15:16:23 +0000 Message-ID: <7943D53D-4ADC-4979-816C-C8F18F457B1A@cisco.com> References: <52740478.6030109@nostrum.com> , <52750E3C.9060206@bbs.darktech.org> In-Reply-To: <52750E3C.9060206@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7943D53D4ADC4979816CC8F18F457B1Aciscocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 15:16:47 -0000 --_000_7943D53D4ADC4979816CC8F18F457B1Aciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suspect iOS will be the worst example. Apple likes h.264 and I think is a= ctually most likely to release a Safari native h.264 WebRTC implementation = vs any other option.... And I highly doubt they'll be using Cisco's module To the degree this is about "enabling web browsers with Real-Time Communica= tions (RTC) capabilities via simple Javascript APIs." they actually could c= heck the box easily... And give you a UiWebView... Which may well make WebR= TC wind up being the best way to get hardware 264 support in 3rd party apps= ... And hence push WebRTC even further. And as always say "Apple iOS is supporting openness"... Can't wait for those discussions :-) Sent from my iPhone On Nov 2, 2013, at 10:38 AM, "cowwoc" > wrote: How many platforms *really* support H.264 natively today? iOS is a great example. On paper, it supports H.264 but in reality the = public API only supports H.264 decoding (not encoding). Then, when you try = using that API for decoding you discover that it does not support real-time= decoding (only decoding from file). So really, iOS doesn't actually suppor= t H.264 as required by WebRTC. Android is only marginally better in that re= spect. I can't think of a single platform that supports real-time H.264 encodi= ng/decoding natively today. Gili On 02/11/2013 7:31 AM, Bernard Aboba wrote: Not sure I understand this completely. Isn't support for "the Rube Goldberg= Machine" needed only on platforms that do not natively support H.264? On Nov 1, 2013, at 1:14 PM, "Justin Uberti" > wrote: I also want to reiterate that having a MTI codec means Mandatory To Impleme= nt. That means, that should we decide to go down the H.264 path, Firefox and ot= hers will be forced to support this Rube Goldberg machine for obtaining H.2= 64 for an indeterminate amount of time, long after WebRTC has moved on to p= refer other codecs. On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach > wrote: On 10/31/13 13:47, Harald Alvestrand wrote: We congratulate Cisco on their intention to make an open source H.264 codec= available and usable by the community. We look forward to seeing the resul= t of this effort. Google still believes that VP8 - a freely available, fully open, high-quali= ty video codec that you can download, compile for your platform, include in= your binary, distribute and put into production today - is the best choice= of a Mandatory to Implement video codec for the WebRTC effort. I agree with Harald that VP8 is a better codec than H.264 baseline in a num= ber of important ways. But I also want to reiterate that having an MTI codec has never been about = choosing the best codec or even a good codec. It's about choosing an emerge= ncy backup codec-of-last-resort. It's about having one single mandated code= c that everyone has in their back pocket in case nothing else works. The core of RTCWEB is about session *negotiation*. Endpoints will negotiate= the best codec they have in common. Once the next generation of codecs com= e out, this "best codec in common" will only be the MTI if they were about = to fail anyway. So it doesn't have to be good. It just has to be better than failure. /a _______________________________________________ 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 --_000_7943D53D4ADC4979816CC8F18F457B1Aciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I suspect iOS will be the wo= rst example. Apple likes h.264 and I think is actually most likely to relea= se a Safari native h.264 WebRTC implementation vs any other option.... And = I highly doubt they'll be using Cisco's module 

To the degree this is = about "enabling web browsers with Real-Time Comm= unications (RTC) capabilities via simple Javascript APIs.&qu= ot; they actually could check the box easily... And give you a UiWebView...= Which may well make WebRTC wind up being the best way to get hardware 264 = support in 3rd party apps... And hence push WebRTC even further.

And as always say "Appl= e iOS is supporting openness"... 

Can't wait for those discuss= ions  :-)

Sent from my iPhone

On Nov 2, 2013, at 10:38 AM, "cowwoc" <cowwoc@bbs.darktech.org> wrote:


    How many platforms *really* support H.264 natively today= ?

    iOS is a great example. On paper, it supports H.264 but = in reality the public API only supports H.264 decoding (not encoding). Then= , when you try using that API for decoding you discover that it does not su= pport real-time decoding (only decoding from file). So really, iOS doesn't actually support H.264 as required by WebRTC. Andro= id is only marginally better in that respect.

    I can't think of a single platform that supports real-ti= me H.264 encoding/decoding natively today.

Gili

On 02/11/2013 7:31 AM, Bernard Aboba wrote:
Not sure I understand this completely. Isn't support for "the Rub= e Goldberg Machine" needed only on platforms that do not natively supp= ort H.264? 

On Nov 1, 2013, at 1:14 PM, "Justin Uberti" <juberti@google.com> wr= ote:

I also want to reiterate that having a MTI codec means Man= datory To Implement.

That means, that should we decide to go down the H.264 path, Firefox a= nd others will be forced to support this Rube Goldberg machine for obtainin= g H.264 for an indeterminate amount of time, long after WebRTC has moved on= to prefer other codecs.


On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach <adam@nostrum.com> wrote:
On 10/31/13 13:47, Harald Alvestrand wrote:

= We congratulate Cisco on their intention to make an open= source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.


= Google still believes that VP8 - a freely available, ful= ly open, high-quality video codec that you can download, compile for your platform, include in your binary, distr= ibute and put into production today - is the best choice of a Mandatory to = Implement video codec for the WebRTC effort.


I agree with Harald that VP8 is a better codec than H.264 baseline in a num= ber of important ways.

But I also want to reiterate that having an MTI codec has never been about = choosing the best codec or even a good codec. It's about choosing an emerge= ncy backup codec-of-last-resort. It's about having one single mandated code= c that everyone has in their back pocket in case nothing else works.

The core of RTCWEB is about session *negotiation*. Endpoints will negotiate= the best codec they have in common. Once the next generation of codecs com= e out, this "best codec in common" will only be the MTI if they w= ere about to fail anyway.

So it doesn't have to be good.

It just has to be better than failure.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org=
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ie= tf.org
https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
rtcweb mailing list
rtcwe=
b@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_7943D53D4ADC4979816CC8F18F457B1Aciscocom_-- From stpeter@stpeter.im Sat Nov 2 08:53:54 2013 Return-Path: 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 81DA711E817C for ; Sat, 2 Nov 2013 08:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 v54UUJw2Xf5m for ; Sat, 2 Nov 2013 08:53:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E062F11E8162 for ; Sat, 2 Nov 2013 08:53:49 -0700 (PDT) Received: from sjc-vpn2-659.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 875644032B; Sat, 2 Nov 2013 09:53:48 -0600 (MDT) Message-ID: <5275200B.9050602@stpeter.im> Date: Sat, 02 Nov 2013 08:53:47 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Martin Thomson , Silvia Pfeiffer References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 15:53:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/2/13 7:38 AM, Martin Thomson wrote: > On 2 November 2013 02:26, Silvia Pfeiffer > wrote: >> (is the vote on the MTI codec going to happen via email?) > > I still hold out hope that a vote will not be necessary. Me, too. Especially since we don't vote. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSdSALAAoJEOoGpJErxa2ptuYP/R0EI4fXFU19kyOZ8Kggt515 b4Kpm96VHbcloadHndDvjz4LCjp8CbDB/rgOC+yFW1GMWyWb0K/6xGY4bTw0c6Pa Vp9iuc91GSST7qL2ukb4eEQF++dHQHPNwpPN5FPGh5cwL3xJMyd6Kwjd9vOjCQXl MrKGeGsB+tq6BiAHn6sNFtaMSKZSCfs7Vsa6BSrIWy1pYnnlM5oro06GTl00Oal1 Cq90fZ+PJy/aQKLqZiob88lBzEOpjxALwkrbm+sWATofaQzkvAth0jBrKVI3zSrZ RIWQzTms0sZPjmG2AxDOPiPIK9T46ryld16T/gv5/wCvTmBcemXTlrovPrw9iGbs OIgSsskzVcwqi9bcTm083c3+qbbENkK/Hjpl8f9IBJ2BaCdf0+/oKAeNAfgmI5xT ZHBlTUYTafetCYWt0VxrwN3AhjxL05F+GQqI+dsMvZK0J32g0SAeaUg5c55V4vIP 4F8R5GG4iDpz0DeT64yUKYOOxjkTqJXeecX344QT1ygGe9ugOR3nTI9lvjEnxLjm R99fy8Fhn4T7XuVp+vE0uQZJC1sKLoGgVLNr/4U0Q1O4E+qQT4J/M0SaFmO0Atn0 MXzDfckILh2OdVjVI5RmuYeFZ/ZovJ11wmfu1y3M80msnl/WSw0PTk2Q0pMu7mFO eNJk88Ppp1E5cb3yrg4b =/OmO -----END PGP SIGNATURE----- From tim@phonefromhere.com Sat Nov 2 09:56:59 2013 Return-Path: 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 6E52721F9B21 for ; Sat, 2 Nov 2013 09:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 bSsONBkxMWdP for ; Sat, 2 Nov 2013 09:56:53 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id 80BFD11E810E for ; Sat, 2 Nov 2013 09:56:45 -0700 (PDT) Received: (qmail 72050 invoked from network); 2 Nov 2013 16:56:43 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 1164 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 2 Nov 2013 16:56:43 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 6F02418A0198; Sat, 2 Nov 2013 16:56:43 +0000 (GMT) Received: from [192.168.157.113] (unknown [192.67.4.37]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 22F1318A0152; Sat, 2 Nov 2013 16:56:43 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: tim panton In-Reply-To: Date: Sat, 2 Nov 2013 16:56:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> To: Martin Thomson X-Mailer: Apple Mail (2.1816) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 16:56:59 -0000 On 2 Nov 2013, at 15:02, Martin Thomson = wrote: > On 2 November 2013 07:37, cowwoc wrote: >> I can't think of a single platform that supports real-time H.264 >> encoding/decoding natively today. >=20 > That's a very strange way to put the question. >=20 > Let me put another spin on it, and please excuse the example... >=20 > Skype runs on more platforms than you might think. Those platforms > can all support H.264 to the extent that Skype requires. Martin, can I ask you to talk with your Skype engineering team and check = up on=20 the exact way that works on iOS. Last time I looked, it seemed you = couldn=92t use the=20 Apple supplied (hardware accelerated) h264 library for realtime = encode/decode and it wasn=92t at all clear to me that the hardware encoder licence covered = any soft implementation of h264 we added. I=92d like to caveat that: 1) it was a while ago. 2) I=92m not a lawyer. 3) it was a thought = experiment. So it would be interesting to get a current view from the trenches. T. From jlaurens@cisco.com Sat Nov 2 10:03:51 2013 Return-Path: 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 BAE8C11E8125 for ; Sat, 2 Nov 2013 10:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.843 X-Spam-Level: X-Spam-Status: No, score=-9.843 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 8peDFp0UqS2t for ; Sat, 2 Nov 2013 10:03:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id ADC0911E8205 for ; Sat, 2 Nov 2013 10:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1469; q=dns/txt; s=iport; t=1383411823; x=1384621423; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=i2t5EKsxGolF4R5hrCCCaR6FeS1CM4RW6vbUCqRh8PY=; b=dCnhWWJ7ZTyJgob/71ybJp/iEg5tFDYHY9ZMyIMNuLCsoc1rj/HMbtgH 8cBhjz3kp4/2GoX3j+0v7mGcKsligq8KQV0HeADKPZ6FVnS8KtLP+IL+m RHngKJd2ib5pFGxU5AzlKh8zPKOzWUgX56NZ95ZgYG3B8h9Q2PNpKCsR4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAGcvdVKtJXG9/2dsb2JhbABZgwc4wAVLgRwWdIIlAQEBAwEBAQFrCwULAgEIGCMLIQYLJQIEDgWHbwMJBg2zNA2JZwSMaII9MweDIIEOA5YfgWuMUoU3gWiBPg X-IronPort-AV: E=Sophos;i="4.93,622,1378857600"; d="scan'208";a="279933921" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 02 Nov 2013 17:03:43 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA2H3gce011501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Nov 2013 17:03:43 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.253]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sat, 2 Nov 2013 12:03:54 -0500 From: "Jeremy Laurenson (jlaurens)" To: tim panton Thread-Topic: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) Thread-Index: AQHO1+yWkUHsyb/SP0uf0OqKiNRd65oSKx1j Date: Sat, 2 Nov 2013 17:03:41 +0000 Message-ID: References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 17:03:51 -0000 You are right, it's not possible to get hardware accelerated Sent from my iPhone > On Nov 2, 2013, at 12:57 PM, "tim panton" wrote: >=20 >=20 >> On 2 Nov 2013, at 15:02, Martin Thomson wrote= : >>=20 >>> On 2 November 2013 07:37, cowwoc wrote: >>> I can't think of a single platform that supports real-time H.264 >>> encoding/decoding natively today. >>=20 >> That's a very strange way to put the question. >>=20 >> Let me put another spin on it, and please excuse the example... >>=20 >> Skype runs on more platforms than you might think. Those platforms >> can all support H.264 to the extent that Skype requires. >=20 > Martin, can I ask you to talk with your Skype engineering team and check = up on=20 > the exact way that works on iOS. Last time I looked, it seemed you couldn= =92t use the=20 > Apple supplied (hardware accelerated) h264 library for realtime encode/de= code and > it wasn=92t at all clear to me that the hardware encoder licence covered = any soft implementation of h264 we > added. >=20 > I=92d like to caveat that: > 1) it was a while ago. 2) I=92m not a lawyer. 3) it was a thought experim= ent. > So it would be interesting to get a current view from the trenches. >=20 > T. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From emcho@sip-communicator.org Sat Nov 2 10:14:22 2013 Return-Path: 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 F250711E8218 for ; Sat, 2 Nov 2013 10:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 fedqvz18qjto for ; Sat, 2 Nov 2013 10:14:17 -0700 (PDT) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id CD0B521F9D65 for ; Sat, 2 Nov 2013 10:14:17 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id xa12so2438570pbc.38 for ; Sat, 02 Nov 2013 10:14:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eWl3YwbwZtR0+IwuLs6nYmf3v6Krkp1XcHzUamyu/Ac=; b=L02zr8VrByafNZk+NFtnKsq9C1xD3hDnMni3eje6gysWtaYmWm8DvmOuNHftM01mTi JKeYxYvQAxmjhrPgD6TDIydlD2biL8uRUPFAs1rlHwdSXspJwj/vusBnhfHHkr0oTYCx n2dZm5fWLASgcWttQhJyDsTSTrry8hB8AJh2Jqtp/ZrafLMFBsZ3grGVg8Q9IqZuEoLG Qq3UOFX4RmGhf2vrFZeP5Yv4VgonyMj4pobqz9d3K5zcpAy9i4ZmoCbFcR25qteBAydB jN8YmArJPuRwuE6RN7xqq1NJQW3uP48cBCEo0XNPukY7vy0otYLZnAe0sHpZhgq97Pdd Vy8g== X-Gm-Message-State: ALoCoQkKPURQ63ORFsvqRruznXnzYZaVsqupjm2kVQO7si1KOM4cF9wZp5inwxo1+Hfu83fVPxDH X-Received: by 10.68.169.161 with SMTP id af1mr9059330pbc.22.1383412457370; Sat, 02 Nov 2013 10:14:17 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [2607:f8b0:400e:c03::234]) by mx.google.com with ESMTPSA id oj6sm20921146pab.9.2013.11.02.10.14.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 10:14:16 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id bj1so5261706pad.25 for ; Sat, 02 Nov 2013 10:14:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.142.107 with SMTP id rv11mr9137199pab.17.1383412456235; Sat, 02 Nov 2013 10:14:16 -0700 (PDT) Received: by 10.66.191.163 with HTTP; Sat, 2 Nov 2013 10:14:15 -0700 (PDT) Received: by 10.66.191.163 with HTTP; Sat, 2 Nov 2013 10:14:15 -0700 (PDT) In-Reply-To: References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> Date: Sat, 2 Nov 2013 18:14:15 +0100 Message-ID: From: Emil Ivov To: tim panton Content-Type: multipart/alternative; boundary=001a11331e46083d6504ea34d0b6 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 17:14:22 -0000 --001a11331e46083d6504ea34d0b6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Same questions for OS X and Windows actually. Last time we checked (which was also some time ago) there was no way to get the OS to *encode* H.264 for you. --sent from my mobile On 2 Nov 2013 17:57, "tim panton" wrote: > > On 2 Nov 2013, at 15:02, Martin Thomson wrote: > > > On 2 November 2013 07:37, cowwoc wrote: > >> I can't think of a single platform that supports real-time H.264 > >> encoding/decoding natively today. > > > > That's a very strange way to put the question. > > > > Let me put another spin on it, and please excuse the example... > > > > Skype runs on more platforms than you might think. Those platforms > > can all support H.264 to the extent that Skype requires. > > Martin, can I ask you to talk with your Skype engineering team and check > up on > the exact way that works on iOS. Last time I looked, it seemed you > couldn=92t use the > Apple supplied (hardware accelerated) h264 library for realtime > encode/decode and > it wasn=92t at all clear to me that the hardware encoder licence covered = any > soft implementation of h264 we > added. > > I=92d like to caveat that: > 1) it was a while ago. 2) I=92m not a lawyer. 3) it was a thought > experiment. > So it would be interesting to get a current view from the trenches. > > T. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11331e46083d6504ea34d0b6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Same questions for OS X and Windows actually. Last time we c= hecked (which was also some time ago) there was no way to get the OS to *en= code* H.264 for you.

--sent from my mobile

On 2 Nov 2013 17:57, "tim panton" <= tim@phonefromhere.com> wrot= e:

On 2 Nov 2013, at 15:02, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
>> =A0 =A0I can't think of a single platform that supports real-t= ime H.264
>> encoding/decoding natively today.
>
> That's a very strange way to put the question.
>
> Let me put another spin on it, and please excuse the example...
>
> Skype runs on more platforms than you might think. =A0Those platforms<= br> > can all support H.264 to the extent that Skype requires.

Martin, can I ask you to talk with your Skype engineering team and check up= on
the exact way that works on iOS. Last time I looked, it seemed you couldn= =92t use the
Apple supplied (hardware accelerated) h264 library for realtime encode/deco= de and
it wasn=92t at all clear to me that the hardware encoder licence covered an= y soft implementation of h264 we
added.

I=92d like to caveat that:
=A01) it was a while ago. 2) I=92m not a lawyer. 3) it was a thought experi= ment.
So it would be interesting to get a current view from the trenches.

T.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--001a11331e46083d6504ea34d0b6-- From bossiel@yahoo.fr Sat Nov 2 10:28:07 2013 Return-Path: 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 226BC21E8099 for ; Sat, 2 Nov 2013 10:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 r7oZoVnHoGVL for ; Sat, 2 Nov 2013 10:28:02 -0700 (PDT) Received: from nm7-vm1.bullet.mail.ird.yahoo.com (nm7-vm1.bullet.mail.ird.yahoo.com [77.238.189.223]) by ietfa.amsl.com (Postfix) with SMTP id C2F2E11E8117 for ; Sat, 2 Nov 2013 10:27:51 -0700 (PDT) Received: from [77.238.189.56] by nm7.bullet.mail.ird.yahoo.com with NNFMP; 02 Nov 2013 17:27:50 -0000 Received: from [212.82.98.120] by tm9.bullet.mail.ird.yahoo.com with NNFMP; 02 Nov 2013 17:27:50 -0000 Received: from [127.0.0.1] by omp1057.mail.ir2.yahoo.com with NNFMP; 02 Nov 2013 17:27:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 589906.52503.bm@omp1057.mail.ir2.yahoo.com Received: (qmail 41603 invoked by uid 60001); 2 Nov 2013 17:27:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1383413267; bh=dc84qBlLmoU091R8hmyC3FYmWOndGa+W+46dh6hMC4c=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=liA0M5kkkXiGdhufLn7wOaQdYAmhmRxlMoLI3fLP+lpiXYzltZiSV8pLkG4YncfToDgw7jE1QhmJ1fjMggi6IIsHIS174MV3oKXHpBPBjDjQVzeiz5p/KKyfp3i27d3176AnBIrt8LLSw1udDzTYL62USMy6sB1yq887PjZM3mU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0NlDAlAVHvfzPL1IsjpxzAef5ZA++RFAwL2/VM/9mFiK+TxCZwgpiAJve7dPShXi8Wq18PUO7xE6ydBmzf/RYkGcf87BKGoeYPldBm1hQxOaRjoKbdOblEiYB3am7O94a9WRwmLMUkRdFDcVp84TTQOl5P8+MyXliQ5gfN06a/k=; X-YMail-OSG: 48IPwegVM1lu8i8bG6AmMkcS79NSa8Qgt6FphI0ux9rwgmA v3BOZOwwaYOdsAMkTFAEbDkWSnKViPAgtPSZQCoRgzGuMhoMil9c8YiCcz2o XWrMB8mOHq5HXFSkBf1LGSbHDF1NpIRQnk0YDUytCB2C12U_qJMnGjjqILPp dR58nV836HEnct.pjrz3rLjOHdGCD9aYQ4.rxuX2NIEg_py0S_IvkHVu07nb nh5MVMLBNQwuEDmtr1_bSxSFVmO24SAoVt1HuGk1Xr2GWe5l0i1xERLjUMR6 68ygx6sHnM587MkkcgbpshFzuWBSRdvr8qGwp3K9ZHSTd0XIYd8Ct_QFcfbB JcwGs_0xYvVHpYTBPLsBWCTsq6oL7ncqsAfTIhxP7bbxeRAz.AeT9gtf2oDd Dj3C6AVuwbe1vMT63WgjsfU8zlT0HpkiNBU9_evhbKghTgfjsXE6pfuWmgo5 jzDLPI4J2g1Ee.V5kYBBpij7j0YfSaLPpkVB7s0Kn.lma87Dxjx9A.VNrCxm b.efjdXOjseWUnZSGKF9CsQ9s.C.t42Ow879Jr_QTBJMX6OGhaqxF56dcLGp pmhNGQEJOzdE0KciDH9.lczbGTUD6lCtjyU0EoHB2UeUKjIrwLWY_XTPL_ob 2IBDE9_DS5g3Hj7l8lCYK7C6NXhy0Ylh2pA-- Received: from [88.179.39.5] by web171304.mail.ir2.yahoo.com via HTTP; Sat, 02 Nov 2013 17:27:46 GMT X-Rocket-MIMEInfo: 002.001, QEVtaWwKQm90aCBXaW5kb3dzIDggYW5kIDcgbmF0aXZlbHkgY29udGFpbiBILjI2NCAqZW5jb2RlciogKFRoYW5rcyBmb3IgTWVkaWEgZm91bmRhdGlvbikuIFRoZSBvbmx5IGlzc3VlIHdpdGggV2luZG93cyA3IGlzIHRoZSB0aGUgZW5jb2RlciBkb2Vzbid0IHN1cHBvcnQgcmVhbHRpbWUgZW5jb2RpbmcgKHVwIHRvIDNzIGRlbGF5KS4KWW91IGNhbiBhbHNvIHJlbHkgb24gdGhlIEdQVSAoQ3VkYSBmb3IgTnZpZGlhIGFuZCBJbnRlbCBRdWljayBTeW5jIGZvciBJbnRlbCkuIE5vdGhpbmcgdG8gaW5zdGFsbCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.161.596 References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> Message-ID: <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> Date: Sat, 2 Nov 2013 17:27:46 +0000 (GMT) From: Bossiel thioriguel To: Emil Ivov , tim panton In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1470824145-1850331765-1383413266=:41025" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bossiel thioriguel 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: Sat, 02 Nov 2013 17:28:07 -0000 ---1470824145-1850331765-1383413266=:41025 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable @Emil=0ABoth Windows 8 and 7 natively contain H.264 *encoder* (Thanks for M= edia foundation). The only issue with Windows 7 is the the encoder doesn't = support realtime encoding (up to 3s delay).=0AYou can also rely on the GPU = (Cuda for Nvidia and Intel Quick Sync for Intel). Nothing to install for th= e end-user.=0AIf you want reference code:=0AMedia Foundation (Windows OS an= d Intel Quick Sync):=C2=A0https://code.google.com/p/doubango/source/browse/= #svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginWinMF=0ANvidia Cuda:=C2= =A0https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2= Fdoubango%2Fplugins%2FpluginCUDA=0A=0A=0A=0A=0ALe Samedi 2 novembre 2013 18= h14, Emil Ivov a =C3=A9crit :=0A =0ASame questions for OS= X and Windows actually. Last time we checked (which was also some time ago= ) there was no way to get the OS to *encode* H.264 for you.=0A--sent from m= y mobile=0AOn 2 Nov 2013 17:57, "tim panton" wrote:= =0A=0A=0A>On 2 Nov 2013, at 15:02, Martin Thomson wrote:=0A>=0A>> On 2 November 2013 07:37, cowwoc wrote:=0A>>> =C2=A0 =C2=A0I can't think of a single platform that support= s real-time H.264=0A>>> encoding/decoding natively today.=0A>>=0A>> That's = a very strange way to put the question.=0A>>=0A>> Let me put another spin o= n it, and please excuse the example...=0A>>=0A>> Skype runs on more platfor= ms than you might think. =C2=A0Those platforms=0A>> can all support H.264 t= o the extent that Skype requires.=0A>=0A>Martin, can I ask you to talk with= your Skype engineering team and check up on=0A>the exact way that works on= iOS. Last time I looked, it seemed you couldn=E2=80=99t use the=0A>Apple s= upplied (hardware accelerated) h264 library for realtime encode/decode and= =0A>it wasn=E2=80=99t at all clear to me that the hardware encoder licence = covered any soft implementation of h264 we=0A>added.=0A>=0A>I=E2=80=99d lik= e to caveat that:=0A>=C2=A01) it was a while ago. 2) I=E2=80=99m not a lawy= er. 3) it was a thought experiment.=0A>So it would be interesting to get a = current view from the trenches.=0A>=0A>T.=0A>=0A>__________________________= _____________________=0A>rtcweb mailing list=0A>rtcweb@ietf.org=0A>https://= www.ietf.org/mailman/listinfo/rtcweb=0A>=0A________________________________= _______________=0Artcweb mailing list=0Artcweb@ietf.org=0Ahttps://www.ietf.= org/mailman/listinfo/rtcweb ---1470824145-1850331765-1383413266=:41025 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
@Emil
Both Windows 8 and 7 natively contain H.264 *encoder* = (Thanks for Media foundation). The only issue with Windows 7 is the the enc= oder doesn't support realtime encoding (up to 3s delay).
You can also rely on the GPU (Cuda = for Nvidia and Intel Quick Sync for Intel). Nothing to install for the end-= user.
If you want refere= nce code:
Media Foundati= on (Windows OS and Intel Quick Sync): https://code.google.com/p/doubango/source/browse/#svn%2Fbranch= es%2F2.0%2Fdoubango%2Fplugins%2FpluginWinMF
Nvidia Cuda: https://code.google.com/p/doubango/so= urce/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginCUDA



Le Samedi 2 novembre 2013 1= 8h14, Emil Ivov <emcho@jitsi.org> a =C3=A9crit :
=
Same = questions for OS X and Windows actually. Last time we checked (which was al= so some time ago) there was no way to get the OS to *encode* H.264 for you.=
=0A
--sent from my mobile
=0A
On 2 Nov 2013 17:57, "tim panton" <tim@phonefromhere.com> wrote:
=0A
=0AOn 2 Nov 2013, at 15:02, Mart= in Thomson <martin.thoms= on@gmail.com> wrote:
=0A
=0A> On 2 November 2013 07:37, cow= woc <cowwoc@bbs.darktech.o= rg> wrote:
=0A>>    I can't think of a single pla= tform that supports real-time H.264
=0A>> encoding/decoding native= ly today.
=0A>
=0A> That's a very strange way to put the questi= on.
=0A>
=0A> Let me put another spin on it, and please excuse = the example...
=0A>
=0A> Skype runs on more platforms than you = might think.  Those platforms
=0A> can all support H.264 to the = extent that Skype requires.
=0A
=0AMartin, can I ask you to talk with= your Skype engineering team and check up on
=0Athe exact way that works= on iOS. Last time I looked, it seemed you couldn=E2=80=99t use the
=0AA= pple supplied (hardware accelerated) h264 library for realtime encode/decod= e and
=0Ait wasn=E2=80=99t at all clear to me that the hardware encoder = licence covered any soft implementation of h264 we
=0Aadded.
=0A
= =0AI=E2=80=99d like to caveat that:
=0A 1) it was a while ago. 2) I= =E2=80=99m not a lawyer. 3) it was a thought experiment.
=0ASo it would = be interesting to get a current view from the trenches.
=0A
=0AT.
= =0A
=0A_______________________________________________
=0Artcweb mail= ing list
=0Artcweb@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/rtcweb
=0A

_______________________________________________
rt= cweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinf= o/rtcweb


---1470824145-1850331765-1383413266=:41025-- From cowwoc@bbs.darktech.org Sat Nov 2 10:42:09 2013 Return-Path: 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 D6E4D11E8172 for ; Sat, 2 Nov 2013 10:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Ibrlr1+3m6Ac for ; Sat, 2 Nov 2013 10:42:05 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 97FA821F9F77 for ; Sat, 2 Nov 2013 10:42:03 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id x13so9920614ief.9 for ; Sat, 02 Nov 2013 10:42:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=Ii4cTEulgcQ9SdbKo16YVrPQ6ZXPdRm1DTC+jV10f3I=; b=ZUejwWxof/URpxIYZyw/h+jNXcVKNyag6uIQctL2ZlIxNSJgn0ykwcD2TqSxVmfB2n +fiiIokdO+gSlFbr3/H7IA9/w5FgE/WQbcsDrndtMU7+l5lIsy0Is1XrcuPwIAKJnrCO 50fJ3oQrVM7iUPFRGI/KtIF6Zc4jXA0OpiBpgGvT8hHvdXOaER7DOrJGV8d8sxpIVptH xR+NLFm82qnscSqcT7pjqOy+UoBWDe0w4oIS9Ne3YnYHzvcieeupT5n4TwpGuh3RR8JY E4qy4Bc57RbeLmIx+PbE5mcTuPX3uYFp6z6yJPQaW6Gt3PA+gOB/cqr6IQ3um9PXXSQQ gHzA== X-Gm-Message-State: ALoCoQnLkdLpdRzGGqKOEZu7TfrYNHZ32KgkNQENVataBAPES6KpLu/qFTyzbXewIWzqHMMOcSKW X-Received: by 10.42.48.202 with SMTP id t10mr5564027icf.9.1383414122960; Sat, 02 Nov 2013 10:42:02 -0700 (PDT) Received: from [192.168.123.174] ([70.28.107.51]) by mx.google.com with ESMTPSA id cl4sm4070723igc.1.2013.11.02.10.42.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 10:42:02 -0700 (PDT) Message-ID: <5275395B.5060709@bbs.darktech.org> Date: Sat, 02 Nov 2013 13:41:47 -0400 From: Gili User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> In-Reply-To: <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> Content-Type: multipart/alternative; boundary="------------050707090108090701050404" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 17:42:10 -0000 This is a multi-part message in MIME format. --------------050707090108090701050404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit So... the only platform that supports H.264 natively (real-time encoding/decoding) is Windows 8? Any others? Gili On 11/2/2013 1:27 PM, Bossiel thioriguel wrote: > @Emil > Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for > Media foundation). The only issue with Windows 7 is the the encoder > doesn't support realtime encoding (up to 3s delay). > You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for > Intel). Nothing to install for the end-user. > If you want reference code: > Media Foundation (Windows OS and Intel Quick > Sync): https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginWinMF > Nvidia > Cuda: https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginCUDA > > > > Le Samedi 2 novembre 2013 18h14, Emil Ivov a écrit : > Same questions for OS X and Windows actually. Last time we checked > (which was also some time ago) there was no way to get the OS to > *encode* H.264 for you. > --sent from my mobile > On 2 Nov 2013 17:57, "tim panton" > wrote: > > > On 2 Nov 2013, at 15:02, Martin Thomson > wrote: > > > On 2 November 2013 07:37, cowwoc > wrote: > >> I can't think of a single platform that supports real-time H.264 > >> encoding/decoding natively today. > > > > That's a very strange way to put the question. > > > > Let me put another spin on it, and please excuse the example... > > > > Skype runs on more platforms than you might think. Those platforms > > can all support H.264 to the extent that Skype requires. > > Martin, can I ask you to talk with your Skype engineering team and > check up on > the exact way that works on iOS. Last time I looked, it seemed you > couldn't use the > Apple supplied (hardware accelerated) h264 library for realtime > encode/decode and > it wasn't at all clear to me that the hardware encoder licence > covered any soft implementation of h264 we > added. > > I'd like to caveat that: > 1) it was a while ago. 2) I'm not a lawyer. 3) it was a thought > experiment. > So it would be interesting to get a current view from the trenches. > > T. > > _______________________________________________ > 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 --------------050707090108090701050404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    So... the only platform that supports H.264 natively (real-time encoding/decoding) is Windows 8? Any others?

Gili

On 11/2/2013 1:27 PM, Bossiel thioriguel wrote:
@Emil
Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for Media foundation). The only issue with Windows 7 is the the encoder doesn't support realtime encoding (up to 3s delay).
You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for Intel). Nothing to install for the end-user.
If you want reference code:



Le Samedi 2 novembre 2013 18h14, Emil Ivov <emcho@jitsi.org> a écrit :
Same questions for OS X and Windows actually. Last time we checked (which was also some time ago) there was no way to get the OS to *encode* H.264 for you.
--sent from my mobile
On 2 Nov 2013 17:57, "tim panton" <tim@phonefromhere.com> wrote:

On 2 Nov 2013, at 15:02, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>    I can't think of a single platform that supports real-time H.264
>> encoding/decoding natively today.
>
> That's a very strange way to put the question.
>
> Let me put another spin on it, and please excuse the example...
>
> Skype runs on more platforms than you might think.  Those platforms
> can all support H.264 to the extent that Skype requires.

Martin, can I ask you to talk with your Skype engineering team and check up on
the exact way that works on iOS. Last time I looked, it seemed you couldn’t use the
Apple supplied (hardware accelerated) h264 library for realtime encode/decode and
it wasn’t at all clear to me that the hardware encoder licence covered any soft implementation of h264 we
added.

I’d like to caveat that:
 1) it was a while ago. 2) I’m not a lawyer. 3) it was a thought experiment.
So it would be interesting to get a current view from the trenches.

T.

_______________________________________________
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

--------------050707090108090701050404-- From bossiel@yahoo.fr Sat Nov 2 11:00:58 2013 Return-Path: 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 D8E7911E8225 for ; Sat, 2 Nov 2013 11:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 tgMfQQ14iQmn for ; Sat, 2 Nov 2013 11:00:54 -0700 (PDT) Received: from nm3-vm0.bullet.mail.ird.yahoo.com (nm3-vm0.bullet.mail.ird.yahoo.com [77.238.189.213]) by ietfa.amsl.com (Postfix) with SMTP id 28A5311E821B for ; Sat, 2 Nov 2013 11:00:52 -0700 (PDT) Received: from [77.238.189.231] by nm3.bullet.mail.ird.yahoo.com with NNFMP; 02 Nov 2013 18:00:52 -0000 Received: from [46.228.39.106] by tm12.bullet.mail.ird.yahoo.com with NNFMP; 02 Nov 2013 18:00:52 -0000 Received: from [127.0.0.1] by smtp143.mail.ir2.yahoo.com with NNFMP; 02 Nov 2013 18:00:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1383415252; bh=Vq18+vFOXW1spWBLsxm35rCZxBZZVVhdiklfNNWXJNs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=wGs1DQHnAatgdwcCKOPbbJDO9dWuKJkNwiz0k8aSdcirwXJka9PBh6sbk7Pb+ht3Su+t4UVzzlmQoOUyFMy979e4O3h3Q9m82b3gZBwkSx0rKPK3dlaiQ5zvCV6XKWPXApYumW5QJoH+BbHGCacWgqFcLV29KJdJ3p4zodfFrt0= X-Yahoo-Newman-Id: 193525.8129.bm@smtp143.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Vv8qVmUVM1mVyhlqCVRPpjwZlawhNFh9whXivnPVrJhLV5E DeAvSu5Z9AzmWTKHhVq7VbWK.12DzS90HLZcpWupFgN.KzdXI0VRiz5MHE6J iG_UScyypZxNdowdVSIKcFtfnT_LDPhdDZobqEuxjMgEkiRHh.dOogm2RqUc MS_do5N0o4rm_8CwFg55kOQ7HaXJzzejF9XlKjYgi2MuR3q4TyOhM584yU83 uAVaSHJB2TAYIouOcWaGl2uYK6G7P905vEkTWqMP1.jmq_2RipRLjj.9feSQ CpD.roQfd8WaHaKd4TY3UK.RehUjp390MVzwVPMEc9Mbb5AScOtwDksPZyVp ASJcN7IBkVLJiX8gCsYlx8cSq5ziaXBQ5sEKwGgACZ3aC5b2bg5tpO6ORmQI ooEqwu.fJwGLacvNINHRcwOdOKffgMB1N2GQx9hyy6s83CQiDc8oLt0Sbw.L Dpq3invELtrJ_1syknqJzKfCvLq0rXF5blM0MBWmXQMb74fcoGWLVh3Vku1A viPn4Ehx0VJRlwEteZr4SzlPpwUSw01WF72TT3kdwEPWFa2SVfIY5vZli9RP YdAkGfuAoDwxUJR6FUq89FJJZs9sYqH0o5sA06tLxqquJxVywfZGFo8qKmgL KiXkoduIsSrU- X-Yahoo-SMTP: Dix.ZgGswBADJg.if3NVG_xX0Xc- X-Rocket-Received: from [192.168.0.26] (bossiel@88.179.39.5 with ) by smtp143.mail.ir2.yahoo.com with SMTP; 02 Nov 2013 18:00:52 +0000 UTC References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> Mime-Version: 1.0 (1.0) In-Reply-To: <5275395B.5060709@bbs.darktech.org> Content-Type: multipart/alternative; boundary=Apple-Mail-E260F57D-E5D8-423C-A1B6-5DC930D8A2CC Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B350) From: Bossiel Date: Sat, 2 Nov 2013 19:00:51 +0100 To: Gili Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 18:00:59 -0000 --Apple-Mail-E260F57D-E5D8-423C-A1B6-5DC930D8A2CC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On windows 7 you have CUDA and Intel Quick Sync Sent from my iPhone On Nov 2, 2013, at 18:41, Gili wrote: >=20 > So... the only platform that supports H.264 natively (real-time encodi= ng/decoding) is Windows 8? Any others? >=20 > Gili >=20 > On 11/2/2013 1:27 PM, Bossiel thioriguel wrote: >> @Emil >> Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for Media f= oundation). The only issue with Windows 7 is the the encoder doesn't support= realtime encoding (up to 3s delay). >> You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for In= tel). Nothing to install for the end-user. >> If you want reference code: >> Media Foundation (Windows OS and Intel Quick Sync): https://code.google.c= om/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2Fplu= ginWinMF >> Nvidia Cuda: https://code.google.com/p/doubango/source/browse/#svn%2Fbran= ches%2F2.0%2Fdoubango%2Fplugins%2FpluginCUDA >>=20 >>=20 >>=20 >> Le Samedi 2 novembre 2013 18h14, Emil Ivov a =C3=A9crit= : >> Same questions for OS X and Windows actually. Last time we checked (which= was also some time ago) there was no way to get the OS to *encode* H.264 fo= r you. >> --sent from my mobile >> On 2 Nov 2013 17:57, "tim panton" wrote: >>=20 >> On 2 Nov 2013, at 15:02, Martin Thomson wrote:= >>=20 >> > On 2 November 2013 07:37, cowwoc wrote: >> >> I can't think of a single platform that suppo= rts real-time H.264 >> >> encoding/decoding natively today. >> > >> > That's a very strange way to put the question. >> > >> > Let me put another spin on it, and please excuse the example... >> > >> > Skype runs on more platforms than you might think. Those platforms >> > can all support H.264 to the extent that Skype requires. >>=20 >> Martin, can I ask you to talk with your Skype engineering team and check u= p on >> the exact way that works on iOS. Last time I looked, it seemed you couldn= =E2=80=99t use the >> Apple supplied (hardware accelerated) h264 library for realtime encode/de= code and >> it wasn=E2=80=99t at all clear to me that the hardware encoder licence co= vered any soft implementation of h264 we >> added. >>=20 >> I=E2=80=99d like to caveat that: >> 1) it was a while ago. 2) I=E2=80=99m not a lawyer. 3) it was a thought e= xperiment. >> So it would be interesting to get a current view from the trenches. >>=20 >> T. >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-E260F57D-E5D8-423C-A1B6-5DC930D8A2CC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On windows 7 you have CUDA and Intel Q= uick Sync

Sent from my iPhone

On Nov 2, 2013, at 18:41,= Gili <cowwoc@bbs.darktech.org= > wrote:

=20 =20 =20

    So... the only platform that supports H.264 nativel= y (real-time encoding/decoding) is Windows 8? Any others?

Gili

On 11/2/2013 1:27 PM, Bossiel thioriguel wrote:
@Emil
Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for Media foundation). The only issue with Windows 7 is the the encoder doesn't support realtime encoding (up to 3s delay).
You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for Intel). Nothing to install for the end-user.
If you want reference code:



Le Samedi 2= novembre 2013 18h14, Emil Ivov <emcho@jitsi.org> a =C3=A9crit :
Same questions for OS X and Windows actually. Last time we checked (which was also some time ago) there was no way to get the OS to *encode* H.264 for you.
--sent from my mobile
On 2 Nov 2013 17:57, "tim panton" <tim@phonefromhere.com> wrote:

On 2 Nov 2013, at 15:02, Martin Thomson <martin.thomson= @gmail.com> wrote:

> On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech= .org> wrote:
>>    I can't think of a single platfo= rm that supports real-time H.264
>> encoding/decoding natively today.
>
> That's a very strange way to put the question.
>
> Let me put another spin on it, and please excuse the example...
>
> Skype runs on more platforms than you might think.  Those platforms
> can all support H.264 to the extent that Skype requires.

Martin, can I ask you to talk with your Skype engineering team and check up on
the exact way that works on iOS. Last time I looked, it seemed you couldn=E2=80=99t use the
Apple supplied (hardware accelerated) h264 library for realtime encode/decode and
it wasn=E2=80=99t at all clear to me that the hardware= encoder licence covered any soft implementation of h264 we
added.

I=E2=80=99d like to caveat that:
 1) it was a while ago. 2) I=E2=80=99m not a lawy= er. 3) it was a thought experiment.
So it would be interesting to get a current view from the trenches.

T.

_______________________________________________
rtcweb mailing list
r= tcweb@ietf.org
https://www.i= etf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinf= o/rtcweb




_______________________________________________
rtcweb mailing list
rtcweb=
@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

=20
____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-E260F57D-E5D8-423C-A1B6-5DC930D8A2CC-- From bossiel@yahoo.fr Sat Nov 2 11:08:59 2013 Return-Path: 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 90D1C11E8225 for ; Sat, 2 Nov 2013 11:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 Zbx1BatWfKNU for ; Sat, 2 Nov 2013 11:08:54 -0700 (PDT) Received: from nm16-vm1.bullet.mail.ir2.yahoo.com (nm16-vm1.bullet.mail.ir2.yahoo.com [212.82.96.207]) by ietfa.amsl.com (Postfix) with ESMTP id 5E30811E8222 for ; Sat, 2 Nov 2013 11:08:35 -0700 (PDT) Received: from [212.82.98.124] by nm16.bullet.mail.ir2.yahoo.com with NNFMP; 02 Nov 2013 18:08:25 -0000 Received: from [46.228.39.106] by tm17.bullet.mail.ir2.yahoo.com with NNFMP; 02 Nov 2013 18:08:25 -0000 Received: from [127.0.0.1] by smtp143.mail.ir2.yahoo.com with NNFMP; 02 Nov 2013 18:08:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1383415705; bh=1SLKwY5yzCzbSWtwUpx83L8y61ejWJbTsOdShffvl78=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=Yu1Zjp6HyEdR0Zg2ThKZgdshgVqrJDzwpuQ9lPDPRMw12wgnxCtw2Vhoz2IOSg0ly0hDdcI71M6hI9BkcWkatrWA6xeAAoMu6V1QcxhHyx+v9fLAtxztl6nwv5Sd/p/BVWrcir04vkGla522/TBVxZLo/JJfvrsJCUvZgH929wY= X-Yahoo-Newman-Id: 542769.4464.bm@smtp143.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Zq8NDiQVM1l7n6UZ1tH8P0khUn47octcj5ueKNT4oXx94m8 j5RzAQCsol4tR1hazCuxVCfzuUXlMLV2FP3jUC4k6aT_T4ugPmeJSOZHTDsY sr3W5i2KSQqiOu7hkP0D0lTY1qqYwcrkzQGHca5TOlepwh4sCOc4FZo8uqtW h6Kxr.GAo5mPNLssTVUexe87bMntmLR6ytRHc4uZabWS2TLlTXm6CUmCsqed rXG495D6geYZTde2KuTNkc9cNr7lu1aVWrkMl7XA7a7XDNh1VhHSDth2qhAY zexd4sg9xUmtBJWwqzP0Ax2TbWMBJ9DXJqBu1M7Px4qasxBZvMiyiXQZX3Nz HNb71X.zdTX9lsFpvd68skZWqDJUvwYUHBv9BOXrWeTlkeKZJsjYtCmBh.4C 3Uzgilk4RrQsokMHJNDMq.dyCJvi9oBxnGo2eSWbXNKbMYtPWpgxg..37P0I .4xn0L2x_EJuIv7NSv8z_mbiIngA_QqUGMIyDN14xHfq.YOdQSl.62NQRtoo Bi9M62NOboQdnCBn79iOWsyMAV7Jy77klcsCDylNp.SQp.swzYOZtOD.c38z DM1aZZQlrQtJ44scCiA.IGGhsfDYy.RoyPjUv1wMhB478h7nq5aIBoyzXL0j Fnq5dXhXFd6U- X-Yahoo-SMTP: Dix.ZgGswBADJg.if3NVG_xX0Xc- X-Rocket-Received: from [192.168.0.26] (bossiel@88.179.39.5 with ) by smtp143.mail.ir2.yahoo.com with SMTP; 02 Nov 2013 18:08:25 +0000 UTC References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> Mime-Version: 1.0 (1.0) In-Reply-To: <5275395B.5060709@bbs.darktech.org> Content-Type: multipart/alternative; boundary=Apple-Mail-97B9FED3-8D37-445E-BBB4-C1FC38F562A6 Content-Transfer-Encoding: 7bit Message-Id: <3254138D-5725-4026-AD79-7B863B7FCB57@yahoo.fr> X-Mailer: iPhone Mail (10B350) From: Bossiel Date: Sat, 2 Nov 2013 19:08:25 +0100 To: Gili Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 18:09:00 -0000 --Apple-Mail-97B9FED3-8D37-445E-BBB4-C1FC38F562A6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In addition to CUDA and Intel Quick Sync there are also many webcams support= ing H264 encoding (eg. Logitech) Sent from my iPhone On Nov 2, 2013, at 18:41, Gili wrote: >=20 > So... the only platform that supports H.264 natively (real-time encodi= ng/decoding) is Windows 8? Any others? >=20 > Gili >=20 > On 11/2/2013 1:27 PM, Bossiel thioriguel wrote: >> @Emil >> Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for Media f= oundation). The only issue with Windows 7 is the the encoder doesn't support= realtime encoding (up to 3s delay). >> You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for In= tel). Nothing to install for the end-user. >> If you want reference code: >> Media Foundation (Windows OS and Intel Quick Sync): https://code.google.c= om/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2Fplu= ginWinMF >> Nvidia Cuda: https://code.google.com/p/doubango/source/browse/#svn%2Fbran= ches%2F2.0%2Fdoubango%2Fplugins%2FpluginCUDA >>=20 >>=20 >>=20 >> Le Samedi 2 novembre 2013 18h14, Emil Ivov a =C3=A9crit= : >> Same questions for OS X and Windows actually. Last time we checked (which= was also some time ago) there was no way to get the OS to *encode* H.264 fo= r you. >> --sent from my mobile >> On 2 Nov 2013 17:57, "tim panton" wrote: >>=20 >> On 2 Nov 2013, at 15:02, Martin Thomson wrote:= >>=20 >> > On 2 November 2013 07:37, cowwoc wrote: >> >> I can't think of a single platform that suppo= rts real-time H.264 >> >> encoding/decoding natively today. >> > >> > That's a very strange way to put the question. >> > >> > Let me put another spin on it, and please excuse the example... >> > >> > Skype runs on more platforms than you might think. Those platforms >> > can all support H.264 to the extent that Skype requires. >>=20 >> Martin, can I ask you to talk with your Skype engineering team and check u= p on >> the exact way that works on iOS. Last time I looked, it seemed you couldn= =E2=80=99t use the >> Apple supplied (hardware accelerated) h264 library for realtime encode/de= code and >> it wasn=E2=80=99t at all clear to me that the hardware encoder licence co= vered any soft implementation of h264 we >> added. >>=20 >> I=E2=80=99d like to caveat that: >> 1) it was a while ago. 2) I=E2=80=99m not a lawyer. 3) it was a thought e= xperiment. >> So it would be interesting to get a current view from the trenches. >>=20 >> T. >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-97B9FED3-8D37-445E-BBB4-C1FC38F562A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In addition to CUDA and Intel Quick Sy= nc there are also many webcams supporting H264 encoding (eg. Logitech)
Sent from my iPhone

On Nov 2, 2013, at 18:41, Gili <cowwoc@bbs.darktech.org> wrote:=

=20 =20 =20

    So... the only platform that supports H.264 nativel= y (real-time encoding/decoding) is Windows 8? Any others?

Gili

On 11/2/2013 1:27 PM, Bossiel thioriguel wrote:
@Emil
Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for Media foundation). The only issue with Windows 7 is the the encoder doesn't support realtime encoding (up to 3s delay).
You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for Intel). Nothing to install for the end-user.
If you want reference code:



Le Samedi 2= novembre 2013 18h14, Emil Ivov <emcho@jitsi.org> a =C3=A9crit :
Same questions for OS X and Windows actually. Last time we checked (which was also some time ago) there was no way to get the OS to *encode* H.264 for you.
--sent from my mobile
On 2 Nov 2013 17:57, "tim panton" <tim@phonefromhere.com> wrote:

On 2 Nov 2013, at 15:02, Martin Thomson <martin.thomson= @gmail.com> wrote:

> On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech= .org> wrote:
>>    I can't think of a single platfo= rm that supports real-time H.264
>> encoding/decoding natively today.
>
> That's a very strange way to put the question.
>
> Let me put another spin on it, and please excuse the example...
>
> Skype runs on more platforms than you might think.  Those platforms
> can all support H.264 to the extent that Skype requires.

Martin, can I ask you to talk with your Skype engineering team and check up on
the exact way that works on iOS. Last time I looked, it seemed you couldn=E2=80=99t use the
Apple supplied (hardware accelerated) h264 library for realtime encode/decode and
it wasn=E2=80=99t at all clear to me that the hardware= encoder licence covered any soft implementation of h264 we
added.

I=E2=80=99d like to caveat that:
 1) it was a while ago. 2) I=E2=80=99m not a lawy= er. 3) it was a thought experiment.
So it would be interesting to get a current view from the trenches.

T.

_______________________________________________
rtcweb mailing list
r= tcweb@ietf.org
https://www.i= etf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinf= o/rtcweb




_______________________________________________
rtcweb mailing list
rtcweb=
@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

=20
____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-97B9FED3-8D37-445E-BBB4-C1FC38F562A6-- From martin.thomson@gmail.com Sat Nov 2 11:27:03 2013 Return-Path: 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 43F8611E8173 for ; Sat, 2 Nov 2013 11:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, 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 Jtw6xVMiFk0d for ; Sat, 2 Nov 2013 11:27:02 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id B6CFD21F9F0E for ; Sat, 2 Nov 2013 11:26:58 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ex4so2297762wid.9 for ; Sat, 02 Nov 2013 11:26:57 -0700 (PDT) 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:content-transfer-encoding; bh=WOlbPJpAApTz/wAmSRRxt7KGhw7Cn7sn2Qi1/xWiJHU=; b=lGw5/43qKRipn40do6XMjGglGw4B/Q8a+FLEP12IHKBWuMsjPqcEL0y40rqCWLUX+p aIexnjGEoIJZoGu0KicpVANNAjdoP8hXl8CehqHytLzhoeQEdXcfsAMg4o42t+oSWBQc YPeug+cls/2SVH49TtE8pcmiMaJ4wDEtMqYO9YGKPw+JB9CsMHk/OqqpplqX1MNGmhOE LUHeeuHsXQ/Ws+pc2pMTywpTYIVBoiM/R2acYON6brFXMMB7MYv9a1oxd+QcLEwEfTT3 0ED7fnbuGfHniogV3JR5tcnZ4iNhAV8/rOUWLLyuIm9GOi4GQ42L8essoIs3jfRNlT/o JbZg== MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr6524216wic.64.1383416817749; Sat, 02 Nov 2013 11:26:57 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Sat, 2 Nov 2013 11:26:57 -0700 (PDT) In-Reply-To: References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> Date: Sat, 2 Nov 2013 11:26:57 -0700 Message-ID: From: Martin Thomson To: tim panton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 18:27:03 -0000 On 2 November 2013 09:56, tim panton wrote: > Last time I looked, it seemed you couldn=E2=80=99t use the > Apple supplied (hardware accelerated) h264 library for realtime encode/de= code and > it wasn=E2=80=99t at all clear to me that the hardware encoder licence co= vered any soft implementation of h264 we > added. That is my understanding also. It's the weekend, so I won't be able to get a fixed answer, but I believe that Skype uses a largely software-based implementation of H.264 on iOS devices. It's not that there isn't hardware acceleration on the device, it's that the APIs that are made available to applications do not include a way to access those functions. From cowwoc@bbs.darktech.org Sat Nov 2 13:01:39 2013 Return-Path: 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 D723021E80DF for ; Sat, 2 Nov 2013 13:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 p-fIkai8GULW for ; Sat, 2 Nov 2013 13:01:33 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id E9BC821E80D8 for ; Sat, 2 Nov 2013 13:01:32 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id aq17so9596416iec.20 for ; Sat, 02 Nov 2013 13:01:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mB03mswxMl/GeSbzO4pEgCiITde6HOm3oWSDRfNKgNE=; b=aCh1H3Hfkc99yA/BGe+nyHxwNr5Dd7CqXAaYu0EvUM/0Yw8hkUdyxkNMWRuiQ8hNUU InIUtmYz8shIN34A4pPOxOabYbQa5EhNBRmwKcFwolvrdFOQLAv4y3ZyqK6cXXbWamc4 qXn1hll8opM+a7K4kf/SeyouSC2fUJrDnC8SE7w3msbiSaiZmnSDlGawzhNTkHSzMgI2 phYteMvmWLvC1E6+nsz5kkwfSMeg75XfrTv0sbk2YOUas34q3jdpl6FXmCNL/H8aIx2A VmfHlcvgQz1pRmuRxBRWXdYVsPCvRtemCJfSWUN/A9lGmCrSCLESauRuu3cITbk8obpl wMjg== X-Gm-Message-State: ALoCoQlOFgi8lS7X8Plew6ENeTBkcWG0raF36Wxu1qlpH6e3uhR73jduRMj8P5NMhhSAZcmqJ0O0 X-Received: by 10.51.16.3 with SMTP id fs3mr6763647igd.53.1383422492293; Sat, 02 Nov 2013 13:01:32 -0700 (PDT) Received: from [192.168.123.174] ([70.28.107.51]) by mx.google.com with ESMTPSA id f19sm4289736igz.1.2013.11.02.13.01.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 13:01:31 -0700 (PDT) Message-ID: <52755A0E.4020007@bbs.darktech.org> Date: Sat, 02 Nov 2013 16:01:18 -0400 From: Gili User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Martin Thomson References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 20:01:39 -0000 Martin, I fully understand why Firefox would be happy but as someone who plan to integrate WebRTC into a non-browser application, especially on iOS, Cisco's solution simply does not work. I appreciate their contribution, but again, it simply doesn't help my use-case. Gili On 11/2/2013 11:02 AM, Martin Thomson wrote: > On 2 November 2013 07:37, cowwoc wrote: >> I can't think of a single platform that supports real-time H.264 >> encoding/decoding natively today. > That's a very strange way to put the question. > > Let me put another spin on it, and please excuse the example... > > Skype runs on more platforms than you might think. Those platforms > can all support H.264 to the extent that Skype requires. > > Cisco's generous offer opens almost the same capability to anyone, > with the caveat that some platforms currently remain closed. Of > course, you could let your ideals get in the way of progress. Me, I'm > a pragmatist. This gift represents a great opportunity for people who > actually care about the practical outcomes. > > There's been a lot of mouth-gazing of gift horses on this list of > late. I sure hope that this isn't representative of the real > sentiment of the community. I'd like to think that people are better > than that. > > (BTW, I understand and respect Harald's position. From where he sits, > I'm sure that his conclusion makes perfect sense.) From cowwoc@bbs.darktech.org Sat Nov 2 13:02:13 2013 Return-Path: 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 2A7D021F9F86 for ; Sat, 2 Nov 2013 13:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 sg8G10oh4TN3 for ; Sat, 2 Nov 2013 13:02:08 -0700 (PDT) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id C6CBF11E8238 for ; Sat, 2 Nov 2013 13:02:07 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id u16so9788668iet.18 for ; Sat, 02 Nov 2013 13:02:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=8aLwK+3aThZX06NPtGN90eW67jIqHeqtZ7f2lthf3rM=; b=kECzVdIpDlGg8miWm34FDWp8MsYiczJGGrJYB79g69H77yFke4riHD7OiSkgiGSj3s jT0G4L97wmAO1zH52VQynjoyw+GO/QJ7eL4PY5T5u+VOwe0K4YrSNEnMyZXIHISnLmB3 vwFhJnVCEKiMDScel1mf5mwCr6xLkhP+n6y/M5kFE5faq5ECqsoarRIfRui2wmFnsR6K DmbztE2n6xS+DcbVovOYn8PRdRMHopomXHqT4VsU7j/gHysaVQJ9W/4LypOP6MvUG88k MlD2Fdlvz9xV4hU1uQO/nrBLmGQ8hxHIAvV2PHN9ldwbvK3IpqbGHK22Vl0MzVCDKgJ1 ED2A== X-Gm-Message-State: ALoCoQlDIFBPT4GVUkxDF9C677qDTXMlLl2SKHASvmiZ5UHtq7ug2tgPFjEwJ+H9g+jIWN1z+oHI X-Received: by 10.50.26.70 with SMTP id j6mr6792789igg.24.1383422527492; Sat, 02 Nov 2013 13:02:07 -0700 (PDT) Received: from [192.168.123.174] ([70.28.107.51]) by mx.google.com with ESMTPSA id w4sm10980737igb.5.2013.11.02.13.02.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 13:02:06 -0700 (PDT) Message-ID: <52755A30.6050206@bbs.darktech.org> Date: Sat, 02 Nov 2013 16:01:52 -0400 From: Gili User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Jeremy Laurenson (jlaurens)" References: <52740478.6030109@nostrum.com> , <52750E3C.9060206@bbs.darktech.org> <7943D53D-4ADC-4979-816C-C8F18F457B1A@cisco.com> In-Reply-To: <7943D53D-4ADC-4979-816C-C8F18F457B1A@cisco.com> Content-Type: multipart/alternative; boundary="------------090806000909000102080600" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 20:02:13 -0000 This is a multi-part message in MIME format. --------------090806000909000102080600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit With respect, no. As I keep on repeating, there is a strong need for WebRTC outside of the browser. I don't see how I am supposed to integrate WebRTC into a closed-source iOS application if H.264 is MTI. I would be more than happy to revisit my position once someone provides a credible solution. Gili On 11/2/2013 11:16 AM, Jeremy Laurenson (jlaurens) wrote: > I suspect iOS will be the worst example. Apple likes h.264 and I think > is actually most likely to release a Safari native h.264 WebRTC > implementation vs any other option.... And I highly doubt they'll be > using Cisco's module > > To the degree this is about "enabling web browsers with Real-Time > Communications (RTC) capabilities via simple Javascript APIs." they > actually could check the box easily... And give you a UiWebView... > Which may well make WebRTC wind up being the best way to get hardware > 264 support in 3rd party apps... And hence push WebRTC even further. > > And as always say "Apple iOS is supporting openness"... > > Can't wait for those discussions :-) > > Sent from my iPhone > > On Nov 2, 2013, at 10:38 AM, "cowwoc" > wrote: > >> >> How many platforms *really* support H.264 natively today? >> >> iOS is a great example. On paper, it supports H.264 but in >> reality the public API only supports H.264 decoding (not encoding). >> Then, when you try using that API for decoding you discover that it >> does not support real-time decoding (only decoding from file). So >> really, iOS doesn't actually support H.264 as required by WebRTC. >> Android is only marginally better in that respect. >> >> I can't think of a single platform that supports real-time H.264 >> encoding/decoding natively today. >> >> Gili >> >> On 02/11/2013 7:31 AM, Bernard Aboba wrote: >>> Not sure I understand this completely. Isn't support for "the Rube >>> Goldberg Machine" needed only on platforms that do not natively >>> support H.264? >>> >>> On Nov 1, 2013, at 1:14 PM, "Justin Uberti" >> > wrote: >>> >>>> I also want to reiterate that having a MTI codec means Mandatory To >>>> Implement. >>>> >>>> That means, that should we decide to go down the H.264 path, >>>> Firefox and others will be forced to support this Rube Goldberg >>>> machine for obtaining H.264 for an indeterminate amount of time, >>>> long after WebRTC has moved on to prefer other codecs. >>>> >>>> >>>> On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach >>> > wrote: >>>> >>>> On 10/31/13 13:47, Harald Alvestrand wrote: >>>>> >>>>> We congratulate Cisco on their intention to make an open >>>>> source H.264 codec available and usable by the community. We >>>>> look forward to seeing the result of this effort. >>>>> >>>>> >>>>> Google still believes that VP8 - a freely available, fully >>>>> open, high-quality video codec that you can download, compile >>>>> for your platform, include in your binary, distribute and put >>>>> into production today - is the best choice of a Mandatory to >>>>> Implement video codec for the WebRTC effort. >>>>> >>>> >>>> I agree with Harald that VP8 is a better codec than H.264 >>>> baseline in a number of important ways. >>>> >>>> But I also want to reiterate that having an MTI codec has never >>>> been about choosing the best codec or even a good codec. It's >>>> about choosing an emergency backup codec-of-last-resort. It's >>>> about having one single mandated codec that everyone has in >>>> their back pocket in case nothing else works. >>>> >>>> The core of RTCWEB is about session *negotiation*. Endpoints >>>> will negotiate the best codec they have in common. Once the >>>> next generation of codecs come out, this "best codec in common" >>>> will only be the MTI if they were about to fail anyway. >>>> >>>> So it doesn't have to be good. >>>> >>>> It just has to be better than failure. >>>> >>>> /a >>>> >>>> _______________________________________________ >>>> 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 --------------090806000909000102080600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    With respect, no. As I keep on repeating, there is a strong need for WebRTC outside of the browser. I don't see how I am supposed to integrate WebRTC into a closed-source iOS application if H.264 is MTI. I would be more than happy to revisit my position once someone provides a credible solution.

Gili

On 11/2/2013 11:16 AM, Jeremy Laurenson (jlaurens) wrote:
I suspect iOS will be the worst example. Apple likes h.264 and I think is actually most likely to release a Safari native h.264 WebRTC implementation vs any other option.... And I highly doubt they'll be using Cisco's module 

To the degree this is about "enabling web browsers with Real-Time Communications (RTC) capabilities via simple Javascript APIs." they actually could check the box easily... And give you a UiWebView... Which may well make WebRTC wind up being the best way to get hardware 264 support in 3rd party apps... And hence push WebRTC even further.

And as always say "Apple iOS is supporting openness"... 

Can't wait for those discussions  :-)

Sent from my iPhone

On Nov 2, 2013, at 10:38 AM, "cowwoc" <cowwoc@bbs.darktech.org> wrote:


    How many platforms *really* support H.264 natively today?

    iOS is a great example. On paper, it supports H.264 but in reality the public API only supports H.264 decoding (not encoding). Then, when you try using that API for decoding you discover that it does not support real-time decoding (only decoding from file). So really, iOS doesn't actually support H.264 as required by WebRTC. Android is only marginally better in that respect.

    I can't think of a single platform that supports real-time H.264 encoding/decoding natively today.

Gili

On 02/11/2013 7:31 AM, Bernard Aboba wrote:
Not sure I understand this completely. Isn't support for "the Rube Goldberg Machine" needed only on platforms that do not natively support H.264? 

On Nov 1, 2013, at 1:14 PM, "Justin Uberti" <juberti@google.com> wrote:

I also want to reiterate that having a MTI codec means Mandatory To Implement.

That means, that should we decide to go down the H.264 path, Firefox and others will be forced to support this Rube Goldberg machine for obtaining H.264 for an indeterminate amount of time, long after WebRTC has moved on to prefer other codecs.


On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach <adam@nostrum.com> wrote:
On 10/31/13 13:47, Harald Alvestrand wrote:

We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.


Google still believes that VP8 - a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today - is the best choice of a Mandatory to Implement video codec for the WebRTC effort.


I agree with Harald that VP8 is a better codec than H.264 baseline in a number of important ways.

But I also want to reiterate that having an MTI codec has never been about choosing the best codec or even a good codec. It's about choosing an emergency backup codec-of-last-resort. It's about having one single mandated codec that everyone has in their back pocket in case nothing else works.

The core of RTCWEB is about session *negotiation*. Endpoints will negotiate the best codec they have in common. Once the next generation of codecs come out, this "best codec in common" will only be the MTI if they were about to fail anyway.

So it doesn't have to be good.

It just has to be better than failure.

/a

_______________________________________________
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

--------------090806000909000102080600-- From cowwoc@bbs.darktech.org Sat Nov 2 13:07:05 2013 Return-Path: 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 E439911E8241 for ; Sat, 2 Nov 2013 13:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 IkEESbPKXR7l for ; Sat, 2 Nov 2013 13:06:37 -0700 (PDT) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0E64B11E8239 for ; Sat, 2 Nov 2013 13:06:22 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id u16so9474751iet.7 for ; Sat, 02 Nov 2013 13:06:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=yJjCShMEHE/uIyPtSFk0YBKA5lw/xME6u7ipjSCET4Y=; b=gGyd79XGG/J8fv/Z2DLkzovGgogYablMZs9jWVvyVYQH0j+UQ5XW5j12/As2eofPJ7 kSwv1uij61bIXUSpAgC7MjTArrvOV45ubwpHlyNXIgO3hSu3U/wpSWyOiBoQ8euiMh2/ rAsOdzwUibQ/3RgOtfOHb7SLaf77FqfO83mo/JhtsbzjKEIZwCjYG8euJGpp0GY4zr6F bkNKWTJzqVAUk9ImSuRXdIzgqCANKIHlnZRHuoh1vn2q550sPvC1SMpeMk8M6ITPSgvz sXesONu+b6pM935mf4ANjMSCYjQM1xJMvHgC0qTELRsJ02mempt6lMlPFtUE7vaKv5qs gu8Q== X-Gm-Message-State: ALoCoQnw5EebvQNWszWbjwFxWwZXLhBG11PiuGRGbkssuu0gpeIF2Yhqgzd9hG2U4eAL3a8wci9t X-Received: by 10.50.26.70 with SMTP id j6mr6801825igg.24.1383422782398; Sat, 02 Nov 2013 13:06:22 -0700 (PDT) Received: from [192.168.123.174] ([70.28.107.51]) by mx.google.com with ESMTPSA id m1sm10995917igj.10.2013.11.02.13.06.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 13:06:21 -0700 (PDT) Message-ID: <52755B30.8070506@bbs.darktech.org> Date: Sat, 02 Nov 2013 16:06:08 -0400 From: Gili User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Bossiel References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090809030101090504050601" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 20:07:05 -0000 This is a multi-part message in MIME format. --------------090809030101090504050601 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Bossiel, Thanks for the clarification. Are there existing libraries on top of CUDA and Intel Quick Sync that provide real-time H.264 encoding/decoding (with a reasonable license), or is this something we'd need to build ourselves? Also, please note that not all video cards support CUDA (only NVidia by last count), or run Intel CPUs (in spite of the fact that many do), so we still have a portability problem. Thanks, Gili On 11/2/2013 2:00 PM, Bossiel wrote: > On windows 7 you have CUDA and Intel Quick Sync > > Sent from my iPhone > > On Nov 2, 2013, at 18:41, Gili > wrote: > >> >> So... the only platform that supports H.264 natively (real-time >> encoding/decoding) is Windows 8? Any others? >> >> Gili >> >> On 11/2/2013 1:27 PM, Bossiel thioriguel wrote: >>> @Emil >>> Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for >>> Media foundation). The only issue with Windows 7 is the the encoder >>> doesn't support realtime encoding (up to 3s delay). >>> You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync >>> for Intel). Nothing to install for the end-user. >>> If you want reference code: >>> Media Foundation (Windows OS and Intel Quick Sync): >>> https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginWinMF >>> Nvidia Cuda: >>> https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginCUDA >>> >>> >>> >>> Le Samedi 2 novembre 2013 18h14, Emil Ivov a écrit : >>> Same questions for OS X and Windows actually. Last time we checked >>> (which was also some time ago) there was no way to get the OS to >>> *encode* H.264 for you. >>> --sent from my mobile >>> On 2 Nov 2013 17:57, "tim panton" >> > wrote: >>> >>> >>> On 2 Nov 2013, at 15:02, Martin Thomson >>> > wrote: >>> >>> > On 2 November 2013 07:37, cowwoc >> > wrote: >>> >> I can't think of a single platform that supports real-time >>> H.264 >>> >> encoding/decoding natively today. >>> > >>> > That's a very strange way to put the question. >>> > >>> > Let me put another spin on it, and please excuse the example... >>> > >>> > Skype runs on more platforms than you might think. Those >>> platforms >>> > can all support H.264 to the extent that Skype requires. >>> >>> Martin, can I ask you to talk with your Skype engineering team >>> and check up on >>> the exact way that works on iOS. Last time I looked, it seemed >>> you couldn’t use the >>> Apple supplied (hardware accelerated) h264 library for realtime >>> encode/decode and >>> it wasn’t at all clear to me that the hardware encoder licence >>> covered any soft implementation of h264 we >>> added. >>> >>> I’d like to caveat that: >>> 1) it was a while ago. 2) I’m not a lawyer. 3) it was a thought >>> experiment. >>> So it would be interesting to get a current view from the trenches. >>> >>> T. >>> >>> _______________________________________________ >>> 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 --------------090809030101090504050601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Bossiel,

    Thanks for the clarification. Are there existing libraries on top of CUDA and Intel Quick Sync that provide real-time H.264 encoding/decoding (with a reasonable license), or is this something we'd need to build ourselves?

    Also, please note that not all video cards support CUDA (only NVidia by last count), or run Intel CPUs (in spite of the fact that many do), so we still have a portability problem.

Thanks,
Gili

On 11/2/2013 2:00 PM, Bossiel wrote:
On windows 7 you have CUDA and Intel Quick Sync

Sent from my iPhone

On Nov 2, 2013, at 18:41, Gili <cowwoc@bbs.darktech.org> wrote:


    So... the only platform that supports H.264 natively (real-time encoding/decoding) is Windows 8? Any others?

Gili

On 11/2/2013 1:27 PM, Bossiel thioriguel wrote:
@Emil
Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for Media foundation). The only issue with Windows 7 is the the encoder doesn't support realtime encoding (up to 3s delay).
You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for Intel). Nothing to install for the end-user.
If you want reference code:



Le Samedi 2 novembre 2013 18h14, Emil Ivov <emcho@jitsi.org> a écrit :
Same questions for OS X and Windows actually. Last time we checked (which was also some time ago) there was no way to get the OS to *encode* H.264 for you.
--sent from my mobile
On 2 Nov 2013 17:57, "tim panton" <tim@phonefromhere.com> wrote:

On 2 Nov 2013, at 15:02, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>    I can't think of a single platform that supports real-time H.264
>> encoding/decoding natively today.
>
> That's a very strange way to put the question.
>
> Let me put another spin on it, and please excuse the example...
>
> Skype runs on more platforms than you might think.  Those platforms
> can all support H.264 to the extent that Skype requires.

Martin, can I ask you to talk with your Skype engineering team and check up on
the exact way that works on iOS. Last time I looked, it seemed you couldn’t use the
Apple supplied (hardware accelerated) h264 library for realtime encode/decode and
it wasn’t at all clear to me that the hardware encoder licence covered any soft implementation of h264 we
added.

I’d like to caveat that:
 1) it was a while ago. 2) I’m not a lawyer. 3) it was a thought experiment.
So it would be interesting to get a current view from the trenches.

T.

_______________________________________________
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

--------------090809030101090504050601-- From bossiel@yahoo.fr Sat Nov 2 13:27:30 2013 Return-Path: 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 08BB911E823F for ; Sat, 2 Nov 2013 13:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 lKB4O3-1Jnvg for ; Sat, 2 Nov 2013 13:27:13 -0700 (PDT) Received: from nm3-vm0.bullet.mail.ird.yahoo.com (nm3-vm0.bullet.mail.ird.yahoo.com [77.238.189.213]) by ietfa.amsl.com (Postfix) with SMTP id 3F66121F9F34 for ; Sat, 2 Nov 2013 13:27:09 -0700 (PDT) Received: from [77.238.189.237] by nm3.bullet.mail.ird.yahoo.com with NNFMP; 02 Nov 2013 20:27:03 -0000 Received: from [46.228.39.73] by tm18.bullet.mail.ird.yahoo.com with NNFMP; 02 Nov 2013 20:27:03 -0000 Received: from [127.0.0.1] by smtp110.mail.ir2.yahoo.com with NNFMP; 02 Nov 2013 20:27:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1383424023; bh=iIC8gw+l7B84L4hpFO1Y5/Z6VZAMzI86quvpNxfKB1Y=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=tHTGTxqVOBGXMBLa7fVBJS/N3mvkjVtPcMeNGdho1PiBfpW5thC4xnqRRp5UGrsoBrcWIfZroBGNOb14vSsszSaDjstawW2wRg1axy5XodD6GO+YFuoLkmXZASjRFMrvsgaSLTw7dtVQRUpxtfOKQmUpgGCa87zTlY72dWam+GA= X-Yahoo-Newman-Id: 492087.41083.bm@smtp110.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: s6UAABMVM1lfiiH2pMnbIEm594YDEPzhKK0YuCd1Ru_UoHj GybRSkhiAQ7HucHXLgmMt9o0.vYXL3a2aiQ60k83gK9dKhJFar4bW.bZN1o5 3cmSlpvhVCl1ZYi9HyW3zEgd1wIgtqAB6aR80K2NF_9mpUlQAFWylQIK7uTF sohXzKOB12OM4Ksgi4BRSk1VVIngPqiOd2NsLa6cjLPolDG9fAujTWxfKyhI cE7Idu7r7y6i2E2t3gXFaLhzchzMOyBu0n3_JPaIMRIih6f0HyqGsD8rh5Es 5ZP6pKHDhrJ3hpQJKdPhua8izH3jg.lwMRxkAW.J7fXMvpyx0.wTN4J83WHF 9wRNO0LRlbfqLoz868IWUiektfoneQuHG6PnBPBjGNckOM9cpo7k6GmJa2QK gy5G4XrcNGUxlFmmrvbjwuydzvGHXlPuj595Sd2rlK9nu1qOmqCZDlHJO0QF 4cF9p6wk6z3455rykkBGMmopFt6HgL_TmwwJ55Xk6gdH9UhpdybNFvgylC83 lLcZuzdpqYQjehYTHfz3HUPOEoDQDWHvSu1SmN5T0X5cJjHYpK0g7or6QRtQ A3UAXx6lEoXAjC2rMp0Ma.W4s.Cp4HYX6qgppG01BTcevK_98TRlTwGaGWIQ RLOcg3S8CKxQ- X-Yahoo-SMTP: Dix.ZgGswBADJg.if3NVG_xX0Xc- X-Rocket-Received: from [192.168.0.26] (bossiel@88.179.39.5 with ) by smtp110.mail.ir2.yahoo.com with SMTP; 02 Nov 2013 20:27:03 +0000 UTC References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> <52755B30.8070506@bbs.darktech.org> Mime-Version: 1.0 (1.0) In-Reply-To: <52755B30.8070506@bbs.darktech.org> Content-Type: multipart/alternative; boundary=Apple-Mail-A32D5C9A-7ED3-43EE-AC45-3ECDFE3BECFB Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B350) From: Bossiel Date: Sat, 2 Nov 2013 21:27:02 +0100 To: Gili Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 20:27:30 -0000 --Apple-Mail-A32D5C9A-7ED3-43EE-AC45-3ECDFE3BECFB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable CUDA works on windows XP and later. The developer needs the SDK and the end-= user up-to-date drivers. For Intel QuickSync there is an SDK but not needed if you're using Microsoft= Media Foundation (Windows Platform SDK). With CUDA, Intel Quick Sync, Win8-builtin- encoder, Webcams with UVC 1.5... y= ou can have native H264 in 99% cases. We have a x264 fallback plugin in our o= pen source products but rarely used. Also note that Windows *Phone* 8 natively support H264 encoding/decoding. Fo= r reference implementation (open source SIP video client) you can follow the= links I sent. Sent from my iPhone On Nov 2, 2013, at 21:06, Gili wrote: > Hi Bossiel, >=20 > Thanks for the clarification. Are there existing libraries on top of C= UDA and Intel Quick Sync that provide real-time H.264 encoding/decoding (wit= h a reasonable license), or is this something we'd need to build ourselves? >=20 > Also, please note that not all video cards support CUDA (only NVidia b= y last count), or run Intel CPUs (in spite of the fact that many do), so we s= till have a portability problem. >=20 > Thanks, > Gili >=20 > On 11/2/2013 2:00 PM, Bossiel wrote: >> On windows 7 you have CUDA and Intel Quick Sync >>=20 >> Sent from my iPhone >>=20 >> On Nov 2, 2013, at 18:41, Gili wrote: >>=20 >>>=20 >>> So... the only platform that supports H.264 natively (real-time enco= ding/decoding) is Windows 8? Any others? >>>=20 >>> Gili >>>=20 >>> On 11/2/2013 1:27 PM, Bossiel thioriguel wrote: >>>> @Emil >>>> Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for = Media foundation). The only issue with Windows 7 is the the enc= oder doesn't support realtime encoding (up to 3s delay). >>>> You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for I= ntel). Nothing to install for the end-user. >>>> If you want reference code: >>>> Media Foundation (Windows OS and Intel Quick Sync): https://code.google= .com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2Fp= luginWinMF >>>> Nvidia Cuda: https://code.google.com/p/doubango/source/browse/#svn%2Fbr= anches%2F2.0%2Fdoubango%2Fplugins%2FpluginCUDA >>>>=20 >>>>=20 >>>>=20 >>>> Le Samedi 2 novembre 2013 18h14, Emil Ivov a =C3=A9cr= it : >>>> Same questions for OS X and Windows actually. Last time we checked (whi= ch was also some time ago) there was no way to get the OS to *encode* H.264 f= or you. >>>> --sent from my mobile >>>> On 2 Nov 2013 17:57, "tim panton" wrote: >>>>=20 >>>> On 2 Nov 2013, at 15:02, Martin Thomson wrot= e: >>>>=20 >>>> > On 2 November 2013 07:37, cowwoc wrote: >>>> >> I can't think of a single platform that supports real-time H.264 >>>> >> encoding/decoding natively today. >>>> > >>>> > That's a very strange way to put the question. >>>> > >>>> > Let me put another spin on it, and please excuse the example... >>>> > >>>> > Skype runs on more platforms than you might think. Those platforms >>>> > can all support H.264 to the extent that Skype requires. >>>>=20 >>>> Martin, can I ask you to talk with your Skype engineering team and chec= k up on >>>> the exact way that works on iOS. Last time I looked, it seemed you coul= dn=E2=80=99t use the >>>> Apple supplied (hardware accelerated) h264 library for realtime encode/= decode and >>>> it wasn=E2=80=99t at all clear to me that the = hardware encoder licence covered any soft implementation of h264 we >>>> added. >>>>=20 >>>> I=E2=80=99d like to caveat that: >>>> 1) it was a while ago. 2) I=E2=80=99m not a lawyer. 3) it was a though= t experiment. >>>> So it would be interesting to get a current view from the trenches. >>>>=20 >>>> T. >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >=20 --Apple-Mail-A32D5C9A-7ED3-43EE-AC45-3ECDFE3BECFB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
CUDA works on windows XP and later. Th= e developer needs the SDK and the end-user up-to-date drivers.
For Intel QuickSync there is an SDK but not needed if you're usi= ng Microsoft Media Foundation (Windows Platform SDK).

With CUDA, Intel Quick Sync, Win8-builtin- encoder, Webcams with UVC 1.5.= .. you can have native H264 in 99% cases. We have a x264 fallback plugin in o= ur open source products but rarely used.

Also note t= hat Windows *Phone* 8 natively support H264 encoding/decoding. For reference= implementation (open source SIP video client) you can follow the links I se= nt.

Sent from my iPhone

On Nov 2, 2013, at 21:06, Gili &= lt;cowwoc@bbs.darktech.org>= ; wrote:

=20 =20 =20
Hi Bossiel,

    Thanks for the clarification. Are there existing li= braries on top of CUDA and Intel Quick Sync that provide real-time H.264 encoding/decoding (with a reasonable license), or is this something we'd need to build ourselves?

    Also, please note that not all video cards support C= UDA (only NVidia by last count), or run Intel CPUs (in spite of the fact that many do), so we still have a portability problem.

Thanks,
Gili

On 11/2/2013 2:00 PM, Bossiel wrote:
On windows 7 you have CUDA and Intel Quick Sync

Sent from my iPhone

On Nov 2, 2013, at 18:41, Gili <cowwoc@bbs.darktech.org> wrote:


    So... the only platform that supports H.264 n= atively (real-time encoding/decoding) is Windows 8? Any others?

Gili

On 11/2/2013 1:27 PM, Bossiel thioriguel wrote:
@Emil
Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for Media foundation). The only issue with Windows 7 is the the encoder doesn't support realtime encoding (up to 3s delay).
You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for Intel). Nothing to install for the end-user.
If you want reference code:



Le Samedi 2 novembre 2013 18h14, Emil Ivov <emcho@jitsi.org> a =C3=A9crit :
Same questions for OS X and Windows actually. Last time we checked (which was also some time ago) there was no way to get the OS to *encode* H.264 for you.
--sent from my mobile
On 2 Nov 2013 17:57, "tim panton" <tim@phonefromhere.com> wrote:

On 2 Nov 2013, at 15:02, Martin Thomson <martin.t= homson@gmail.com> wrote:

> On 2 November 2013 07:37, cowwoc <cowwoc@bbs.d= arktech.org> wrote:
>>    I can't think of a single platform that supports real-time H.264
>> encoding/decoding natively today.
>
> That's a very strange way to put the question.
>
> Let me put another spin on it, and please excuse the example...
>
> Skype runs on more platforms than you might think.  Those platforms
> can all support H.264 to the extent that Skype requires.

Martin, can I ask you to talk with your Skype engineering team and check up on
the exact way that works on iOS. Last time I looked, it seemed you couldn=E2=80=99t use the Apple supplied (hardware accelerated) h264 library for realtime encode/decode and
it wasn=E2=80=99t at all clear to me that the hardware encoder licence covered any soft implementation of h264 we
added.

I=E2=80=99d like to caveat that:
 1) it was a while ago. 2) I=E2=80=99m not a= lawyer. 3) it was a thought experiment.
So it would be interesting to get a current view from the trenches.

T.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https:/= /www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/l= istinfo/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

=20
= --Apple-Mail-A32D5C9A-7ED3-43EE-AC45-3ECDFE3BECFB-- From cowwoc@bbs.darktech.org Sat Nov 2 15:15:58 2013 Return-Path: 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 C6B9211E824F for ; Sat, 2 Nov 2013 15:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 RTY34y3zQOht for ; Sat, 2 Nov 2013 15:15:53 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id E043311E824E for ; Sat, 2 Nov 2013 15:15:52 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id tp5so9702297ieb.2 for ; Sat, 02 Nov 2013 15:15:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=FyQCJZE4jrbiEBj47PhoKzsuuUykUbxkeLpG1vC7f1o=; b=NiDWz87BWNKB3gGf9b8XYUaohqOgcwcTBcaEsvPOchrlnHTl0MrJktYlDw48Rii5lq JIDr3ittmviCAsKfeX25/abnyBnrDw5UUY9bwSZk1HR8BPoUfRanf/BddMFOnzbiz7Tk THU5s++zX+5Wbh/iJvI6IE0OafvrOzjOu+BKBKnSNYHWmqYgDYhnibC32MDwvhCwjyEE ngLSyBPK33PcFtRJ/Q98mWBG0/Ey7s4z0F5Q0T9gPFNq6EFbdVcEaUGBap0zAPYaqxl1 oFelIoSeEFzuZ8cpOMoubX0m0MduyWKVK9D72kWmgAvDSmlYHtgStviVh4/8TNZscCfP QgAg== X-Gm-Message-State: ALoCoQkXcd+35fGGblhH9Pw1cc9YLLhZFnHelQlllG1JIU4rim9/Z1okmLo1Er3pOIO/9PDt+X7E X-Received: by 10.42.67.74 with SMTP id s10mr5892950ici.1.1383430552048; Sat, 02 Nov 2013 15:15:52 -0700 (PDT) Received: from [192.168.123.174] ([70.28.107.51]) by mx.google.com with ESMTPSA id ka1sm12429176igb.7.2013.11.02.15.15.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 15:15:51 -0700 (PDT) Message-ID: <52757985.3080306@bbs.darktech.org> Date: Sat, 02 Nov 2013 18:15:33 -0400 From: Gili User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Bossiel References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> <52755B30.8070506@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030101070008020307070203" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 22:15:58 -0000 X-List-Received-Date: Sat, 02 Nov 2013 22:15:58 -0000 This is a multi-part message in MIME format. --------------030101070008020307070203 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit According to http://www.tekrevue.com/2013/08/19/nvidia-takes-62-of-discrete-gpu-market-share-in-q2-2013/ NVidia owns 62% of the market, while according to http://www.cpubenchmark.net/market_share.html Intel owns 75.6% of the market. Whether the union of these two translates to 99% market share remains to be seen, but one thing is sure: it sounds like a deployment nightmare. I'd have build an abstraction layer on top of CUDA + Intel Quick Sync and update device drivers on each user machine. This is hardly trivial stuff. Don't get me wrong, VP8 is even worse when it comes to hardware-acceleration. For this reason, I'd probably forgo hardware acceleration on Windows 7 and use software codecs for the sake of simplicity. Desktop PCs are fast enough anyway. When it comes to software-based codecs, VP8 is in a much better position than H.264. It has a better royalty, licensing and deployment story. I think both VP8 and H.264 need a better story when it comes to a portable hardware accelerated APi. So when it comes to hardware-accelerated real-time H.264 encoding/decoding support, here is what we've got: Windows 7: Yes, if you jump through many hoops Windows 8: Yes OSX: No iOS: No Android: No By last check, Windows 8 had approximately 10% market share. When it comes to software-based H.264 codecs, I'm not aware of a single portable implementation with a commercially-friendly license. On the flip side, the software-based VP8 codec is available on all these platforms (today, not in some distant future) with very reasonable performance and ease of deployment. My point is, when considering using H.264 vs VP8 for MTI it's not clear that H.264 has any real advantage over VP8. H.264 has industry-wide support when it comes to playing pre-recorded YouTube videos, but that's hardly relevant to our discussion. WebRTC requires real-time encoding/decoding support and in that context, the two codecs are on equal footing. Gili On 11/2/2013 4:27 PM, Bossiel wrote: > CUDA works on windows XP and later. The developer needs the SDK and > the end-user up-to-date drivers. > > For Intel QuickSync there is an SDK but not needed if you're using > Microsoft Media Foundation (Windows Platform SDK). > > With CUDA, Intel Quick Sync, Win8-builtin- encoder, Webcams with UVC > 1.5... you can have native H264 in 99% cases. We have a x264 fallback > plugin in our open source products but rarely used. > > Also note that Windows *Phone* 8 natively support H264 > encoding/decoding. For reference implementation (open source SIP video > client) you can follow the links I sent. > > Sent from my iPhone > > On Nov 2, 2013, at 21:06, Gili > wrote: > >> Hi Bossiel, >> >> Thanks for the clarification. Are there existing libraries on top >> of CUDA and Intel Quick Sync that provide real-time H.264 >> encoding/decoding (with a reasonable license), or is this something >> we'd need to build ourselves? >> >> Also, please note that not all video cards support CUDA (only >> NVidia by last count), or run Intel CPUs (in spite of the fact that >> many do), so we still have a portability problem. >> >> Thanks, >> Gili >> >> On 11/2/2013 2:00 PM, Bossiel wrote: >>> On windows 7 you have CUDA and Intel Quick Sync >>> >>> Sent from my iPhone >>> >>> On Nov 2, 2013, at 18:41, Gili >> > wrote: >>> >>>> >>>> So... the only platform that supports H.264 natively (real-time >>>> encoding/decoding) is Windows 8? Any others? >>>> >>>> Gili >>>> >>>> On 11/2/2013 1:27 PM, Bossiel thioriguel wrote: >>>>> @Emil >>>>> Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for >>>>> Media foundation). The only issue with Windows 7 is the the >>>>> encoder doesn't support realtime encoding (up to 3s delay). >>>>> You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync >>>>> for Intel). Nothing to install for the end-user. >>>>> If you want reference code: >>>>> Media Foundation (Windows OS and Intel Quick Sync): >>>>> https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginWinMF >>>>> Nvidia Cuda: >>>>> https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginCUDA >>>>> >>>>> >>>>> >>>>> Le Samedi 2 novembre 2013 18h14, Emil Ivov a écrit : >>>>> Same questions for OS X and Windows actually. Last time we checked >>>>> (which was also some time ago) there was no way to get the OS to >>>>> *encode* H.264 for you. >>>>> --sent from my mobile >>>>> On 2 Nov 2013 17:57, "tim panton" >>>> > wrote: >>>>> >>>>> >>>>> On 2 Nov 2013, at 15:02, Martin Thomson >>>>> > >>>>> wrote: >>>>> >>>>> > On 2 November 2013 07:37, cowwoc >>>> > wrote: >>>>> >> I can't think of a single platform that supports >>>>> real-time H.264 >>>>> >> encoding/decoding natively today. >>>>> > >>>>> > That's a very strange way to put the question. >>>>> > >>>>> > Let me put another spin on it, and please excuse the example... >>>>> > >>>>> > Skype runs on more platforms than you might think. Those >>>>> platforms >>>>> > can all support H.264 to the extent that Skype requires. >>>>> >>>>> Martin, can I ask you to talk with your Skype engineering team >>>>> and check up on >>>>> the exact way that works on iOS. Last time I looked, it seemed >>>>> you couldn’t use the >>>>> Apple supplied (hardware accelerated) h264 library for >>>>> realtime encode/decode and >>>>> it wasn’t at all clear to me that the hardware encoder licence >>>>> covered any soft implementation of h264 we >>>>> added. >>>>> >>>>> I’d like to caveat that: >>>>> 1) it was a while ago. 2) I’m not a lawyer. 3) it was a >>>>> thought experiment. >>>>> So it would be interesting to get a current view from the >>>>> trenches. >>>>> >>>>> T. >>>>> >>>>> _______________________________________________ >>>>> 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 >> --------------030101070008020307070203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

    According to http://www.tekrevue.com/2013/08/19/nvidia-takes-62-of-discrete-gpu-market-share-in-q2-2013/ NVidia owns 62% of the market, while according to http://www.cpubenchmark.net/market_share.html Intel owns 75.6% of the market.

    Whether the union of these two translates to 99% market share remains to be seen, but one thing is sure:  it sounds like a deployment nightmare. I'd have build an abstraction layer on top of CUDA + Intel Quick Sync and update device drivers on each user machine. This is hardly trivial stuff. Don't get me wrong, VP8 is even worse when it comes to hardware-acceleration. For this reason, I'd probably forgo hardware acceleration on Windows 7 and use software codecs for the sake of simplicity. Desktop PCs are fast enough anyway.

    When it comes to software-based codecs, VP8 is in a much better position than H.264. It has a better royalty, licensing and deployment story. I think both VP8 and H.264 need a better story when it comes to a portable hardware accelerated APi.

    So when it comes to hardware-accelerated real-time H.264 encoding/decoding support, here is what we've got:

Windows 7: Yes, if you jump through many hoops
Windows 8: Yes
OSX: No
iOS: No
Android: No

    By last check, Windows 8 had approximately 10% market share.

    When it comes to software-based H.264 codecs, I'm not aware of a single portable implementation with a commercially-friendly license. On the flip side, the software-based VP8 codec is available on all these platforms (today, not in some distant future) with very reasonable performance and ease of deployment.

    My point is, when considering using H.264 vs VP8 for MTI it's not clear that H.264 has any real advantage over VP8. H.264 has industry-wide support when it comes to playing pre-recorded YouTube videos, but that's hardly relevant to our discussion. WebRTC requires real-time encoding/decoding support and in that context, the two codecs are on equal footing.

Gili

On 11/2/2013 4:27 PM, Bossiel wrote:
CUDA works on windows XP and later. The developer needs the SDK and the end-user up-to-date drivers.

For Intel QuickSync there is an SDK but not needed if you're using Microsoft Media Foundation (Windows Platform SDK).

With CUDA, Intel Quick Sync, Win8-builtin- encoder, Webcams with UVC 1.5... you can have native H264 in 99% cases. We have a x264 fallback plugin in our open source products but rarely used.

Also note that Windows *Phone* 8 natively support H264 encoding/decoding. For reference implementation (open source SIP video client) you can follow the links I sent.

Sent from my iPhone

On Nov 2, 2013, at 21:06, Gili <cowwoc@bbs.darktech.org> wrote:

Hi Bossiel,

    Thanks for the clarification. Are there existing libraries on top of CUDA and Intel Quick Sync that provide real-time H.264 encoding/decoding (with a reasonable license), or is this something we'd need to build ourselves?

    Also, please note that not all video cards support CUDA (only NVidia by last count), or run Intel CPUs (in spite of the fact that many do), so we still have a portability problem.

Thanks,
Gili

On 11/2/2013 2:00 PM, Bossiel wrote:
On windows 7 you have CUDA and Intel Quick Sync

Sent from my iPhone

On Nov 2, 2013, at 18:41, Gili <cowwoc@bbs.darktech.org> wrote:


    So... the only platform that supports H.264 natively (real-time encoding/decoding) is Windows 8? Any others?

Gili

On 11/2/2013 1:27 PM, Bossiel thioriguel wrote:
@Emil
Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for Media foundation). The only issue with Windows 7 is the the encoder doesn't support realtime encoding (up to 3s delay).
You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync for Intel). Nothing to install for the end-user.
If you want reference code:



Le Samedi 2 novembre 2013 18h14, Emil Ivov <emcho@jitsi.org> a écrit :
Same questions for OS X and Windows actually. Last time we checked (which was also some time ago) there was no way to get the OS to *encode* H.264 for you.
--sent from my mobile
On 2 Nov 2013 17:57, "tim panton" <tim@phonefromhere.com> wrote:

On 2 Nov 2013, at 15:02, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>    I can't think of a single platform that supports real-time H.264
>> encoding/decoding natively today.
>
> That's a very strange way to put the question.
>
> Let me put another spin on it, and please excuse the example...
>
> Skype runs on more platforms than you might think.  Those platforms
> can all support H.264 to the extent that Skype requires.

Martin, can I ask you to talk with your Skype engineering team and check up on
the exact way that works on iOS. Last time I looked, it seemed you couldn’t use the
Apple supplied (hardware accelerated) h264 library for realtime encode/decode and
it wasn’t at all clear to me that the hardware encoder licence covered any soft implementation of h264 we
added.

I’d like to caveat that:
 1) it was a while ago. 2) I’m not a lawyer. 3) it was a thought experiment.
So it would be interesting to get a current view from the trenches.

T.

_______________________________________________
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


--------------030101070008020307070203-- From ekr@rtfm.com Sat Nov 2 15:17:08 2013 Return-Path: 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 53B6611E8253 for ; Sat, 2 Nov 2013 15:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 GEaHOtgXtBSu for ; Sat, 2 Nov 2013 15:17:04 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id C1BBF11E824E for ; Sat, 2 Nov 2013 15:17:03 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id f4so2402638wiw.10 for ; Sat, 02 Nov 2013 15:17:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qIkqOJhSt4KlIg6vbbm3eBJycQiJIQmRe4oPOBhJ3bY=; b=Ik6varFVfklCe/j0Oy+2qmM5CJYE0fSRxnVFl4ojQrWYa4eWXnLulkNRwBNkJDRRfj T8SruaQqYAN9ZHukxEESxgl8bohSJKhCjwHKAb8WJPX1sXYTN+Gqw4+BPfdGFx1hymH7 9muCFiEnIhgh3CY7CslXt1bITLaByv4Vv+Vk0GcELB2r7TEOoQgSfGt2GSp7uHG/NCDO vbgxThXbWK2/hE4KdSvfXikx/O21DNuHPjHqUCT+eEe0HP7oKTbC7BxnHp0aquSToKeZ YfvGzFFrAQ9UlxSFyJ5y81h9KvXNuakPE5H3Ez4KjLLrCinGWO52x5v9MBxDHtiWH3+s QjjQ== X-Gm-Message-State: ALoCoQkHLcRcLDWs+j0oaJZi+BtgfvRejiC5zhdGSUz3MEsimseUVcSTd/pqHMwTzkyq049Y4qJ2 X-Received: by 10.180.24.137 with SMTP id u9mr6807575wif.5.1383430622809; Sat, 02 Nov 2013 15:17:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Sat, 2 Nov 2013 15:16:22 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:a427:d50c:2c74:28c4] In-Reply-To: References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> From: Eric Rescorla Date: Sat, 2 Nov 2013 15:16:22 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=f46d04447f67d828f004ea390ac1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 22:17:08 -0000 --f46d04447f67d828f004ea390ac1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If only there was some piece of software that you could download that provided H.264 encoders for those platforms. -Ekr On Sat, Nov 2, 2013 at 10:14 AM, Emil Ivov wrote: > Same questions for OS X and Windows actually. Last time we checked (which > was also some time ago) there was no way to get the OS to *encode* H.264 > for you. > > --sent from my mobile > On 2 Nov 2013 17:57, "tim panton" wrote: > >> >> On 2 Nov 2013, at 15:02, Martin Thomson wrote= : >> >> > On 2 November 2013 07:37, cowwoc wrote: >> >> I can't think of a single platform that supports real-time H.264 >> >> encoding/decoding natively today. >> > >> > That's a very strange way to put the question. >> > >> > Let me put another spin on it, and please excuse the example... >> > >> > Skype runs on more platforms than you might think. Those platforms >> > can all support H.264 to the extent that Skype requires. >> >> Martin, can I ask you to talk with your Skype engineering team and check >> up on >> the exact way that works on iOS. Last time I looked, it seemed you >> couldn=92t use the >> Apple supplied (hardware accelerated) h264 library for realtime >> encode/decode and >> it wasn=92t at all clear to me that the hardware encoder licence covered >> any soft implementation of h264 we >> added. >> >> I=92d like to caveat that: >> 1) it was a while ago. 2) I=92m not a lawyer. 3) it was a thought >> experiment. >> So it would be interesting to get a current view from the trenches. >> >> T. >> >> _______________________________________________ >> 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 > > --f46d04447f67d828f004ea390ac1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
If only there was some piece of software that you could do= wnload
that provided H.264 encoders for those platforms.

=
-Ekr



On Sat, Nov 2, 2013 at 10:14 AM, Emil Ivov <emcho@jitsi.org> w= rote:

Same questions for OS X and Windows actually. Last time we c= hecked (which was also some time ago) there was no way to get the OS to *en= code* H.264 for you.

--sent from my mobile

On 2 Nov 2013 17:57, "tim panton" <= tim@phonefromher= e.com> wrote:

On 2 Nov 2013, at 15:02, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
>> =A0 =A0I can't think of a single platform that supports real-t= ime H.264
>> encoding/decoding natively today.
>
> That's a very strange way to put the question.
>
> Let me put another spin on it, and please excuse the example...
>
> Skype runs on more platforms than you might think. =A0Those platforms<= br> > can all support H.264 to the extent that Skype requires.

Martin, can I ask you to talk with your Skype engineering team and check up= on
the exact way that works on iOS. Last time I looked, it seemed you couldn= =92t use the
Apple supplied (hardware accelerated) h264 library for realtime encode/deco= de and
it wasn=92t at all clear to me that the hardware encoder licence covered an= y soft implementation of h264 we
added.

I=92d like to caveat that:
=A01) it was a while ago. 2) I=92m not a lawyer. 3) it was a thought experi= ment.
So it would be interesting to get a current view from the trenches.

T.

_______________________________________________
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


--f46d04447f67d828f004ea390ac1-- From ekr@rtfm.com Sat Nov 2 15:19:11 2013 Return-Path: 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 916BD11E8258 for ; Sat, 2 Nov 2013 15:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.31 X-Spam-Level: X-Spam-Status: No, score=-101.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] 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 DCFbFRMH3Oey for ; Sat, 2 Nov 2013 15:19:07 -0700 (PDT) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1857A11E824B for ; Sat, 2 Nov 2013 15:18:47 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u56so781721wes.19 for ; Sat, 02 Nov 2013 15:18:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aQBwz9QLTknbL6FgrS2VtQs7GhR7oFtcP3PkAJ49WFM=; b=m8/xjSxCQCuOasRLLH33ItjhY8yb2rApgTzNF50zBtqql462ep88eGSsyhuJwyXMkW Y9bDdBTIpykjKoNVrpsTtw4BIxploXDJNfsy8DjKbavNmfHrMM468Cbw8I3bLFiX0iQW eNjPW2sXzVqkHdFLpf6Sbf4b3k8oN62ec6ae23WZqnFM3eziWKyl6iNLN51ITQxjaIni GxBp82IV1ydHaLytbSHIbMS3dQGm2x9dkEXBm+0wittY239T2hPrR7EAOhJuPoSsKHOM EhNaEr7mKvJ9iCtAVh9I+RWDzHJwCTMeNFS6y9JTYLh9EJDhp+HO/sLudPbouPJa+iYe BpZA== X-Gm-Message-State: ALoCoQmp0WuiQgEuGjfGXrJklg4owTta9s3fbdaWmTwpLyVBeVWu90cy36OKtauR5MVKMP1vWj4P X-Received: by 10.180.24.197 with SMTP id w5mr6865420wif.8.1383430725904; Sat, 02 Nov 2013 15:18:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Sat, 2 Nov 2013 15:18:04 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:a427:d50c:2c74:28c4] In-Reply-To: <52755A0E.4020007@bbs.darktech.org> References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <52755A0E.4020007@bbs.darktech.org> From: Eric Rescorla Date: Sat, 2 Nov 2013 15:18:04 -0700 Message-ID: To: Gili Content-Type: multipart/alternative; boundary=f46d044286e2fd419104ea39108b Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 22:19:11 -0000 --f46d044286e2fd419104ea39108b Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 2, 2013 at 1:01 PM, Gili wrote: > Martin, > > I fully understand why Firefox would be happy but as someone who plan > to integrate WebRTC into a non-browser application, especially on iOS, > Cisco's solution simply does not work. I appreciate their contribution, but > again, it simply doesn't help my use-case. > I haven't seen you explain how your use case is different from that of a browser. Could you please do so? -Ekr > Gili > > > On 11/2/2013 11:02 AM, Martin Thomson wrote: > >> On 2 November 2013 07:37, cowwoc wrote: >> >>> I can't think of a single platform that supports real-time H.264 >>> encoding/decoding natively today. >>> >> That's a very strange way to put the question. >> >> Let me put another spin on it, and please excuse the example... >> >> Skype runs on more platforms than you might think. Those platforms >> can all support H.264 to the extent that Skype requires. >> >> Cisco's generous offer opens almost the same capability to anyone, >> with the caveat that some platforms currently remain closed. Of >> course, you could let your ideals get in the way of progress. Me, I'm >> a pragmatist. This gift represents a great opportunity for people who >> actually care about the practical outcomes. >> >> There's been a lot of mouth-gazing of gift horses on this list of >> late. I sure hope that this isn't representative of the real >> sentiment of the community. I'd like to think that people are better >> than that. >> >> (BTW, I understand and respect Harald's position. From where he sits, >> I'm sure that his conclusion makes perfect sense.) >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d044286e2fd419104ea39108b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Nov 2, 2013 at 1:01 PM, Gili <cowwoc@bbs.darktech.o= rg> wrote:
Martin,

=A0 =A0 I fully understand why Firefox would be happy but as someone who pl= an to integrate WebRTC into a non-browser application, especially on iOS, C= isco's solution simply does not work. I appreciate their contribution, = but again, it simply doesn't help my use-case.

I haven't seen =A0you explain how your= use case is different from that of
a browser. Could you please d= o so?

-Ekr
=A0
Gili


On 11/2/2013 11:02 AM, Martin Thomson wrote:
On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
=A0 =A0 =A0I can't think of a single platform that supports real-time H= .264
encoding/decoding natively today.
That's a very strange way to put the question.

Let me put another spin on it, and please excuse the example...

Skype runs on more platforms than you might think. =A0Those platforms
can all support H.264 to the extent that Skype requires.

Cisco's generous offer opens almost the same capability to anyone,
with the caveat that some platforms currently remain closed. =A0Of
course, you could let your ideals get in the way of progress. =A0Me, I'= m
a pragmatist. =A0This gift represents a great opportunity for people who actually care about the practical outcomes.

There's been a lot of mouth-gazing of gift horses on this list of
late. =A0I sure hope that this isn't representative of the real
sentiment of the community. =A0I'd like to think that people are better=
than that.

(BTW, I understand and respect Harald's position. =A0From where he sits= ,
I'm sure that his conclusion makes perfect sense.)

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--f46d044286e2fd419104ea39108b-- From emcho@sip-communicator.org Sat Nov 2 15:28:15 2013 Return-Path: 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 E00C411E824B for ; Sat, 2 Nov 2013 15:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 HstthThLtFpQ for ; Sat, 2 Nov 2013 15:28:07 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id BDE1B11E8252 for ; Sat, 2 Nov 2013 15:28:03 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id mc17so5647873pbc.35 for ; Sat, 02 Nov 2013 15:28:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=p/1QUsQWG3fTx9Jp4rQQXG4oWD1+UcOrSJXVUdzElUo=; b=iYoZWZN5NUKhgBp6wM7cgz1dgt1E6hsMiPRzFVQY3gORGAomvzfGCnJGt/d9bO3qHq WJIApznIJDnguQ3fO2fOptpw8nZP3nI8aT/wijBBV81C5kDDcO+Pz+dVWPVBYP7ikjx7 H51ktk0PTMM6jar/QJPPo7W0NemayQ61ec2tO9fMI9TUIRBTQWsF5ZQPxBuIfSuXmFM7 KBYJ1r2YTAA6QQDZOWQOJXplil6UfYV/IgJlIXukFuaDzyYqIeIb+t7l0YF/4h6ORZC6 ojQk3LgrljBr5OopWIkwOspUw5xOttB/OgINtpaNEeShopx/enirkWQb2FAiZwyCzEbu eIIA== X-Gm-Message-State: ALoCoQnfVznldteE3oKwB1RDalF7uNcP3uQhGm3a/xseswXaz6EpjucZkpaZsdRh1xq/OP1pFVKg X-Received: by 10.66.149.231 with SMTP id ud7mr10144189pab.8.1383431282938; Sat, 02 Nov 2013 15:28:02 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [2607:f8b0:400e:c03::234]) by mx.google.com with ESMTPSA id go4sm18704143pbb.15.2013.11.02.15.28.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 15:28:01 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id bj1so5423234pad.25 for ; Sat, 02 Nov 2013 15:28:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.144.102 with SMTP id sl6mr9807816pab.96.1383431281698; Sat, 02 Nov 2013 15:28:01 -0700 (PDT) Received: by 10.66.191.163 with HTTP; Sat, 2 Nov 2013 15:28:01 -0700 (PDT) Received: by 10.66.191.163 with HTTP; Sat, 2 Nov 2013 15:28:01 -0700 (PDT) In-Reply-To: References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> Date: Sat, 2 Nov 2013 23:28:01 +0100 Message-ID: From: Emil Ivov To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b6da6e41e04d404ea3932f1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 22:28:15 -0000 --047d7b6da6e41e04d404ea3932f1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'd encourage you to read back. This part of the thread started with the claim that most of the time it won't come to downloading Cisco's binary because there is already widespread OS support for H.264 encoding on all OSes. --sent from my mobile On 2 Nov 2013 23:17, "Eric Rescorla" wrote: > If only there was some piece of software that you could download > that provided H.264 encoders for those platforms. > > -Ekr > > > > On Sat, Nov 2, 2013 at 10:14 AM, Emil Ivov wrote: > >> Same questions for OS X and Windows actually. Last time we checked (whic= h >> was also some time ago) there was no way to get the OS to *encode* H.264 >> for you. >> >> --sent from my mobile >> On 2 Nov 2013 17:57, "tim panton" wrote: >> >>> >>> On 2 Nov 2013, at 15:02, Martin Thomson >>> wrote: >>> >>> > On 2 November 2013 07:37, cowwoc wrote: >>> >> I can't think of a single platform that supports real-time H.264 >>> >> encoding/decoding natively today. >>> > >>> > That's a very strange way to put the question. >>> > >>> > Let me put another spin on it, and please excuse the example... >>> > >>> > Skype runs on more platforms than you might think. Those platforms >>> > can all support H.264 to the extent that Skype requires. >>> >>> Martin, can I ask you to talk with your Skype engineering team and chec= k >>> up on >>> the exact way that works on iOS. Last time I looked, it seemed you >>> couldn=92t use the >>> Apple supplied (hardware accelerated) h264 library for realtime >>> encode/decode and >>> it wasn=92t at all clear to me that the hardware encoder licence covere= d >>> any soft implementation of h264 we >>> added. >>> >>> I=92d like to caveat that: >>> 1) it was a while ago. 2) I=92m not a lawyer. 3) it was a thought >>> experiment. >>> So it would be interesting to get a current view from the trenches. >>> >>> T. >>> >>> _______________________________________________ >>> 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 >> >> > --047d7b6da6e41e04d404ea3932f1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I'd encourage you to read back.

This part of the thread started with the claim that most of = the time it won't come to downloading Cisco's binary because there = is already widespread OS support for H.264 encoding on all OSes.

--sent from my mobile

On 2 Nov 2013 23:17, "Eric Rescorla" &= lt;ekr@rtfm.com> wrote:
If only there was some piece of software that you could do= wnload
that provided H.264 encoders for those platforms.

=
-Ekr



On Sat, Nov 2, 2013 at 10:14 AM, Emil Ivov <emcho@jitsi.org> w= rote:

Same questions for OS X and Windows actually. Last time we c= hecked (which was also some time ago) there was no way to get the OS to *en= code* H.264 for you.

--sent from my mobile

On 2 Nov 2013 17:57, "tim panton" <= tim@phonefromher= e.com> wrote:

On 2 Nov 2013, at 15:02, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
>> =A0 =A0I can't think of a single platform that supports real-t= ime H.264
>> encoding/decoding natively today.
>
> That's a very strange way to put the question.
>
> Let me put another spin on it, and please excuse the example...
>
> Skype runs on more platforms than you might think. =A0Those platforms<= br> > can all support H.264 to the extent that Skype requires.

Martin, can I ask you to talk with your Skype engineering team and check up= on
the exact way that works on iOS. Last time I looked, it seemed you couldn= =92t use the
Apple supplied (hardware accelerated) h264 library for realtime encode/deco= de and
it wasn=92t at all clear to me that the hardware encoder licence covered an= y soft implementation of h264 we
added.

I=92d like to caveat that:
=A01) it was a while ago. 2) I=92m not a lawyer. 3) it was a thought experi= ment.
So it would be interesting to get a current view from the trenches.

T.

_______________________________________________
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


--047d7b6da6e41e04d404ea3932f1-- From ekr@rtfm.com Sat Nov 2 15:43:57 2013 Return-Path: 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 566D621E8114 for ; Sat, 2 Nov 2013 15:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 tq9CJ+-9YXJt for ; Sat, 2 Nov 2013 15:43:52 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id E5AEC21E80B8 for ; Sat, 2 Nov 2013 15:43:51 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm4so2402840wib.0 for ; Sat, 02 Nov 2013 15:43:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HyLFfL/pDZhms3Y64tjinF0WdfpyHduVYRWbFyXEXnA=; b=R/kCNsXPAHYXbNpmpXmMabR1L7YW6fdho78V5g8nKMrrMYaqDxU5UVyGjoOlYO5FmC SvwkT2v7OXyCLfLP2GaHSb3wV0YuZSRT99LLjnMRixDKRr8rtRTvj9t1mmf6lmZSfyWM WBEoJu2TK76EnKqZBojvU4suFpN1IzqwI7OZAjBABMEJO9z1PAC+sXabnYK9xGXmst6f 3R0kKTdcxtHz61MNzTFxvtVK2lm7d921spkyZcCRFhuc9cEIfGXTmAKs307WFMS1TErL J+UkVgRHBVMMaPDYzAYzBz0oE42a0aYwbyIk5GDTMFzfmN3kNDDpVTIeYDZrfp5r8c6P njdA== X-Gm-Message-State: ALoCoQm8Fz6056oOLjYFuHUPgiwmhn7dg/WvHW3FO7y7Uqr1ijgMyqM2rt6aCGWAVyZSfQi0bvmE X-Received: by 10.194.58.104 with SMTP id p8mr7199129wjq.1.1383432231051; Sat, 02 Nov 2013 15:43:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Sat, 2 Nov 2013 15:43:09 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:a427:d50c:2c74:28c4] In-Reply-To: References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> From: Eric Rescorla Date: Sat, 2 Nov 2013 15:43:09 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=047d7ba97804b4004e04ea396a26 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 22:43:57 -0000 --047d7ba97804b4004e04ea396a26 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 2, 2013 at 3:28 PM, Emil Ivov wrote: > I'd encourage you to read back. > > This part of the thread started with the claim that most of the time it > won't come to downloading Cisco's binary because there is already > widespread OS support for H.264 encoding on all OSes > I assume you're referring to Bernard's comment? If so, I don't think that's actually what he said. In any case, speaking as someone who actually has to deal with this, it's more work to maintain more code paths. Thus, I anticipate using Cisco's binary on all desktop platforms and only using platform codecs where it offers a significant performance advantage, e.g., on mobile. On a related note: it's a mistake to assume that just because there aren't currently good interfaces to the existing H.264 encoding hardware that those interfaces will never exist. For instance, the iPhone clearly has real-time capable encoding hardware, and Apple certainly could make it available if they wanted. That's a much simpler proposition than adding hardware where none exists. -Ekr --047d7ba97804b4004e04ea396a26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Nov 2, 2013 at 3:28 PM, Emil Ivov <emcho@jitsi.org> wrote:

I'd encourage you to read= back.

This part of the thread started with the claim that most of = the time it won't come to downloading Cisco's binary because there = is already widespread OS support for H.264 encoding on all OSes


I assume you're referring to Bernard's comment?= If so, I don't think that's actually
what he said.
=

In any case, speaking as someone who actually has to de= al with this, it's more
work to maintain more code paths. Thus, I anticipate using Cisco's= binary on
all desktop platforms and only using platform codecs w= here it offers a significant
performance advantage, e.g., on mobi= le.

On a related note: it's a mistake to assume that ju= st because there aren't
currently good interfaces to the exis= ting H.264 encoding hardware that those
interfaces will never exi= st. For instance, the iPhone clearly has real-time
capable encoding hardware, and Apple certainly could make it available=
if they wanted. That's a much simpler proposition than addin= g hardware
where none exists.

-Ekr

--047d7ba97804b4004e04ea396a26-- From jlaurens@cisco.com Sat Nov 2 15:49:24 2013 Return-Path: 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 E888311E8255 for ; Sat, 2 Nov 2013 15:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.409 X-Spam-Level: X-Spam-Status: No, score=-10.409 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 qyK1tjuU7lbM for ; Sat, 2 Nov 2013 15:49:20 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E838611E8105 for ; Sat, 2 Nov 2013 15:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8501; q=dns/txt; s=iport; t=1383432560; x=1384642160; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=URqrZMdNa4ZFhwtDSbZhOfgue/jaclPsmgvPUnZ/HZw=; b=WuQVDdqgV20rwYP1DgOpOZ0Ba6crKgB5RqrszEUpeEXOdIGmUTuFUX7g BsZZK9vVBSCp0Kbb+SxDQSgECsKnSay4EO5e/ikZ7zX+BrzdPKUnNpEGh hXKIpnFppdvhv+8mtsTsaH3Te/l0BnLBvAAvyLLr+MBdNUMAlaJ5HPuud A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFADiAdVKtJV2c/2dsb2JhbABZgwc4wAVLgRsWdIIlAQEBAwEBAQFrCwULAgEIDgojBAchBgsUAwENAgQOBYdvAwkGDbMbDYlnBIxogmwEB4MggQ4Dlh+Ba4xShTeBaIE+ X-IronPort-AV: E=Sophos;i="4.93,624,1378857600"; d="scan'208,217";a="276920437" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 02 Nov 2013 22:49:19 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA2MnJM5023865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Nov 2013 22:49:19 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.33]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Sat, 2 Nov 2013 17:49:18 -0500 From: "Jeremy Laurenson (jlaurens)" To: Emil Ivov Thread-Topic: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) Thread-Index: AQHO2BkpBk13xO4pgUCS+AgMzHheL5oS2TOA//+yB14= Date: Sat, 2 Nov 2013 22:48:56 +0000 Message-ID: References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_AB1229535A834F999A02D257F4E11C19ciscocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 22:49:25 -0000 --_000_AB1229535A834F999A02D257F4E11C19ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don't think this is the case. The rationale is that H.264 can be accelerated by hardware. Some rightly question how much this is actually the case natively today. To Ekr's point, if Cisco works with the top providers to enable true accele= ration.... Or in the case of Apple, if ultimate delivery of true h/w acceleration of 2= 64 is ultimately delivered through WebRTC... Then at least we' have *more* h/w acceleration than we do today Sent from my iPhone On Nov 2, 2013, at 6:28 PM, "Emil Ivov" > wrote: I'd encourage you to read back. This part of the thread started with the claim that most of the time it won= 't come to downloading Cisco's binary because there is already widespread O= S support for H.264 encoding on all OSes. --sent from my mobile On 2 Nov 2013 23:17, "Eric Rescorla" > wr= ote: If only there was some piece of software that you could download that provided H.264 encoders for those platforms. -Ekr On Sat, Nov 2, 2013 at 10:14 AM, Emil Ivov > wrote: Same questions for OS X and Windows actually. Last time we checked (which w= as also some time ago) there was no way to get the OS to *encode* H.264 for= you. --sent from my mobile On 2 Nov 2013 17:57, "tim panton" > wrote: On 2 Nov 2013, at 15:02, Martin Thomson > wrote: > On 2 November 2013 07:37, cowwoc > wrote: >> I can't think of a single platform that supports real-time H.264 >> encoding/decoding natively today. > > That's a very strange way to put the question. > > Let me put another spin on it, and please excuse the example... > > Skype runs on more platforms than you might think. Those platforms > can all support H.264 to the extent that Skype requires. Martin, can I ask you to talk with your Skype engineering team and check up= on the exact way that works on iOS. Last time I looked, it seemed you couldn= =92t use the Apple supplied (hardware accelerated) h264 library for realtime encode/deco= de and it wasn=92t at all clear to me that the hardware encoder licence covered an= y soft implementation of h264 we added. I=92d like to caveat that: 1) it was a while ago. 2) I=92m not a lawyer. 3) it was a thought experime= nt. So it would be interesting to get a current view from the trenches. T. _______________________________________________ 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 --_000_AB1229535A834F999A02D257F4E11C19ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I don't think this is the case.

The rationale is that H.264 can be accelerated by hardware.
Some rightly question how much this is actually the case natively toda= y.
To Ekr's point, if Cisco works with the top providers to enable true a= cceleration....
Or in the case of Apple, if ultimate delivery of true h/w acceleration= of 264 is ultimately delivered through WebRTC...
Then at least we' have *more* h/w acceleration than we do today

Sent from my iPhone

On Nov 2, 2013, at 6:28 PM, "Emil Ivov" <emcho@jitsi.org> wrote:

I'd encourage you to read back.

This part of the thread started with the claim that most of = the time it won't come to downloading Cisco's binary because there is alrea= dy widespread OS support for H.264 encoding on all OSes.

--sent from my mobile

On 2 Nov 2013 23:17, "Eric Rescorla" &= lt;ekr@rtfm.com> wrote:
If only there was some piece of software that you could do= wnload
that provided H.264 encoders for those platforms.

-Ekr



On Sat, Nov 2, 2013 at 10:14 AM, Emil Ivov <emcho@jitsi.org> wrote:

Same questions for OS X and Windows actually. Last time we c= hecked (which was also some time ago) there was no way to get the OS to *en= code* H.264 for you.

--sent from my mobile

On 2 Nov 2013 17:57, "tim panton" <= tim@phonefromher= e.com> wrote:

On 2 Nov 2013, at 15:02, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>    I can't think of a single platform that supports real= -time H.264
>> encoding/decoding natively today.
>
> That's a very strange way to put the question.
>
> Let me put another spin on it, and please excuse the example...
>
> Skype runs on more platforms than you might think.  Those platfor= ms
> can all support H.264 to the extent that Skype requires.

Martin, can I ask you to talk with your Skype engineering team and check up= on
the exact way that works on iOS. Last time I looked, it seemed you couldn= =92t use the
Apple supplied (hardware accelerated) h264 library for realtime encode/deco= de and
it wasn=92t at all clear to me that the hardware encoder licence covered an= y soft implementation of h264 we
added.

I=92d like to caveat that:
 1) it was a while ago. 2) I=92m not a lawyer. 3) it was a thought exp= eriment.
So it would be interesting to get a current view from the trenches.

T.

_______________________________________________
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
--_000_AB1229535A834F999A02D257F4E11C19ciscocom_-- From kaiduanx@gmail.com Sat Nov 2 16:41:40 2013 Return-Path: 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 140F311E8143 for ; Sat, 2 Nov 2013 16:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 2pNSk9mnoe-5 for ; Sat, 2 Nov 2013 16:41:39 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B625711E8260 for ; Sat, 2 Nov 2013 16:41:36 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w61so807525wes.38 for ; Sat, 02 Nov 2013 16:41:35 -0700 (PDT) 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=ztcDaReOdKMibvM9O2Iz390NgUUfPvksXL8bGKvCXoM=; b=0mywfWdg07ZS2IkuyNKmGNOVAwH2U6DBpR4BEQLRav8F2ih2CJ7/4/tOq8CU5fWgPH vAoqzt9clkuFVOCf5S3y/vMAYqWnL9jVlkDcbnXclaf9Y7CN50Sxxat2VYgv82C8pkhe FzLcE6qjzZs65VmEcjhteuduavkLm1vHRuIe2jVkZ/dAItJXWXfK420uV/aN0bIqSQ8G hg1uDfGBatzDN8kobLUwLHxRxQT4wh6j07jlYGoRe1sHBPzlQ9FsHGGLwjxQjMoRxD0V oGyz08gtZo+H0GnBr/XvnlrzO60fat01Ab2knBpk6SjORjC6rRxhzZrCH5E/77Ij+n8d zI/w== MIME-Version: 1.0 X-Received: by 10.180.90.116 with SMTP id bv20mr6895502wib.50.1383435695834; Sat, 02 Nov 2013 16:41:35 -0700 (PDT) Received: by 10.216.183.202 with HTTP; Sat, 2 Nov 2013 16:41:35 -0700 (PDT) In-Reply-To: References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <52755A0E.4020007@bbs.darktech.org> Date: Sat, 2 Nov 2013 19:41:35 -0400 Message-ID: From: Kaiduan Xie To: Eric Rescorla Content-Type: multipart/alternative; boundary=f46d043c7f4e384d5504ea3a3963 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sat, 02 Nov 2013 23:41:40 -0000 --f46d043c7f4e384d5504ea3a3963 Content-Type: text/plain; charset=ISO-8859-1 Every BlackBerry 10 phone has H.264 hardware encoder/decoder. /Kaiduan On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla wrote: > > > > On Sat, Nov 2, 2013 at 1:01 PM, Gili wrote: > >> Martin, >> >> I fully understand why Firefox would be happy but as someone who plan >> to integrate WebRTC into a non-browser application, especially on iOS, >> Cisco's solution simply does not work. I appreciate their contribution, but >> again, it simply doesn't help my use-case. >> > > I haven't seen you explain how your use case is different from that of > a browser. Could you please do so? > > -Ekr > > >> Gili >> >> >> On 11/2/2013 11:02 AM, Martin Thomson wrote: >> >>> On 2 November 2013 07:37, cowwoc wrote: >>> >>>> I can't think of a single platform that supports real-time H.264 >>>> encoding/decoding natively today. >>>> >>> That's a very strange way to put the question. >>> >>> Let me put another spin on it, and please excuse the example... >>> >>> Skype runs on more platforms than you might think. Those platforms >>> can all support H.264 to the extent that Skype requires. >>> >>> Cisco's generous offer opens almost the same capability to anyone, >>> with the caveat that some platforms currently remain closed. Of >>> course, you could let your ideals get in the way of progress. Me, I'm >>> a pragmatist. This gift represents a great opportunity for people who >>> actually care about the practical outcomes. >>> >>> There's been a lot of mouth-gazing of gift horses on this list of >>> late. I sure hope that this isn't representative of the real >>> sentiment of the community. I'd like to think that people are better >>> than that. >>> >>> (BTW, I understand and respect Harald's position. From where he sits, >>> I'm sure that his conclusion makes perfect sense.) >>> >> >> _______________________________________________ >> 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 > > --f46d043c7f4e384d5504ea3a3963 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Every BlackBerry 10 phone has H.264 hardware encoder/decod= er.

/Kaiduan

<= br>
On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla= <ek= r@rtfm.com> wrote:



On Sat, Nov 2, 201= 3 at 1:01 PM, Gili <cowwoc@bbs.darktech.org> wrote:
Martin,

=A0 =A0 I fully understand why Firefox would be happy but as someone who pl= an to integrate WebRTC into a non-browser application, especially on iOS, C= isco's solution simply does not work. I appreciate their contribution, = but again, it simply doesn't help my use-case.

I haven't seen =A0you explain ho= w your use case is different from that of
a browser. Could you pl= ease do so?

-Ekr
=A0
Gili


On 11/2/2013 11:02 AM, Martin Thomson wrote:
On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
=A0 =A0 =A0I can't think of a single platform that supports real-time H= .264
encoding/decoding natively today.
That's a very strange way to put the question.

Let me put another spin on it, and please excuse the example...

Skype runs on more platforms than you might think. =A0Those platforms
can all support H.264 to the extent that Skype requires.

Cisco's generous offer opens almost the same capability to anyone,
with the caveat that some platforms currently remain closed. =A0Of
course, you could let your ideals get in the way of progress. =A0Me, I'= m
a pragmatist. =A0This gift represents a great opportunity for people who actually care about the practical outcomes.

There's been a lot of mouth-gazing of gift horses on this list of
late. =A0I sure hope that this isn't representative of the real
sentiment of the community. =A0I'd like to think that people are better=
than that.

(BTW, I understand and respect Harald's position. =A0From where he sits= ,
I'm sure that his conclusion makes perfect sense.)

_______________________________________________
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


--f46d043c7f4e384d5504ea3a3963-- From tim@phonefromhere.com Sun Nov 3 02:49:51 2013 Return-Path: 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 98C0111E8127 for ; Sun, 3 Nov 2013 02:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 dXGkfHfpUo+0 for ; Sun, 3 Nov 2013 02:49:45 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id D844A11E80EC for ; Sun, 3 Nov 2013 02:49:44 -0800 (PST) Received: (qmail 70285 invoked from network); 3 Nov 2013 10:49:39 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 690 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 3 Nov 2013 10:49:39 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1792618A0580; Sun, 3 Nov 2013 10:49:39 +0000 (GMT) Received: from [192.168.157.113] (unknown [192.67.4.37]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B741E18A056B; Sun, 3 Nov 2013 10:49:38 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BCE37CB1-5916-4555-9D0F-3344C29E2A0B" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: tim panton In-Reply-To: Date: Sun, 3 Nov 2013 10:49:39 +0000 Message-Id: References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1816) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sun, 03 Nov 2013 10:49:51 -0000 --Apple-Mail=_BCE37CB1-5916-4555-9D0F-3344C29E2A0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2 Nov 2013, at 22:43, Eric Rescorla wrote: >=20 >=20 >=20 > On Sat, Nov 2, 2013 at 3:28 PM, Emil Ivov wrote: > I'd encourage you to read back. >=20 > This part of the thread started with the claim that most of the time = it won't come to downloading Cisco's binary because there is already = widespread OS support for H.264 encoding on all OSes >=20 >=20 > I assume you're referring to Bernard's comment? If so, I don't think = that's actually > what he said. >=20 > In any case, speaking as someone who actually has to deal with this, = it's more > work to maintain more code paths. Thus, I anticipate using Cisco's = binary on > all desktop platforms and only using platform codecs where it offers a = significant > performance advantage, e.g., on mobile. Unfortunately it is on mobile that these codecs are not available. >=20 > On a related note: it's a mistake to assume that just because there = aren't > currently good interfaces to the existing H.264 encoding hardware that = those > interfaces will never exist. For instance, the iPhone clearly has = real-time > capable encoding hardware, and Apple certainly could make it available > if they wanted. That's a much simpler proposition than adding hardware > where none exists. I=92m not sure that the situation is quite that simple, I think that = many of the currently deployed GPUs would be capable of accelerating VP8 with a firmware = update. One can speculate endlessly about the future, but one of the benefits of = h264 is that the hardware is deployed. However when you examine this claim, we = find that it is only=20 available to the platform owner, so we risk having a vendor lock-in = where the platform browser has access to performance that 3rd party browsers don=92t= . Tim. >=20 > -Ekr >=20 --Apple-Mail=_BCE37CB1-5916-4555-9D0F-3344C29E2A0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 2 Nov 2013, at 22:43, Eric Rescorla = <ekr@rtfm.com> wrote:




On Sat, Nov 2, 2013 at 3:28 PM, Emil Ivov <emcho@jitsi.org> wrote:

I'd = encourage you to read back.

This part of the thread = started with the claim that most of the time it won't come to = downloading Cisco's binary because there is already widespread OS = support for H.264 encoding on all OSes


I assume you're referring to Bernard's comment? If = so, I don't think that's actually
what he = said.

In any case, speaking as someone who = actually has to deal with this, it's more
work to maintain more code paths. Thus, I anticipate using Cisco's = binary on
all desktop platforms and only using platform codecs = where it offers a significant
performance advantage, e.g., on = mobile.

Unfortunat= ely it is on mobile that these codecs are not = available.


On a related note: it's a mistake to assume that = just because there aren't
currently good interfaces to the = existing H.264 encoding hardware that those
interfaces will = never exist. For instance, the iPhone clearly has real-time
capable encoding hardware, and Apple certainly could make it = available
if they wanted. That's a much simpler proposition = than adding hardware
where none = exists.

I=92m = not sure that the situation is quite that simple, I think that many of = the currently
deployed GPUs would be capable of accelerating = VP8 with a firmware update.

One can speculate = endlessly about the future, but one of the benefits of h264 = is
that the hardware is deployed. However when you examine = this claim, we find that it is only 
available to the = platform owner, so we risk having a vendor lock-in where = the
platform browser has access to performance that 3rd party = browsers don=92t .

Tim.


-Ekr


= --Apple-Mail=_BCE37CB1-5916-4555-9D0F-3344C29E2A0B-- From keith.drage@alcatel-lucent.com Sun Nov 3 09:52:13 2013 Return-Path: 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 3F98421E80CF for ; Sun, 3 Nov 2013 09:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.501 X-Spam-Level: X-Spam-Status: No, score=-110.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 7ymGjZ2rHpmo for ; Sun, 3 Nov 2013 09:52:06 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE3621E809F for ; Sun, 3 Nov 2013 09:52:06 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rA3Hq3M3020095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 3 Nov 2013 11:52:04 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rA3Hq1k4024721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Nov 2013 18:52:02 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sun, 3 Nov 2013 18:52:01 +0100 From: "DRAGE, Keith (Keith)" To: tim panton , Eric Rescorla Thread-Topic: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) Thread-Index: AQHO2IJyVW7oO7lpnEG64e25l15uCZoTyTJA Date: Sun, 3 Nov 2013 17:52:00 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0C6D75@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0C6D75FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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: Sun, 03 Nov 2013 17:52:13 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B0C6D75FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And this is where it would be useful to see some work done, although probab= ly not by IETF. There a a few bits of API work out there, but nowhere do we see much push f= or adoption. As fae as I see there is no political reason why they should n= ot be adopted, or even a fresh effort adopted to create some new ones. The = only thing seems to be lack of impetus. regards Keith ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= tim panton Sent: 03 November 2013 10:50 To: Eric Rescorla Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiations on = the Cisco announcement - but we still prefer VP8) On 2 Nov 2013, at 22:43, Eric Rescorla > = wrote: On Sat, Nov 2, 2013 at 3:28 PM, Emil Ivov > wrote: I'd encourage you to read back. This part of the thread started with the claim that most of the time it won= 't come to downloading Cisco's binary because there is already widespread O= S support for H.264 encoding on all OSes I assume you're referring to Bernard's comment? If so, I don't think that's= actually what he said. In any case, speaking as someone who actually has to deal with this, it's m= ore work to maintain more code paths. Thus, I anticipate using Cisco's binary o= n all desktop platforms and only using platform codecs where it offers a sign= ificant performance advantage, e.g., on mobile. Unfortunately it is on mobile that these codecs are not available. On a related note: it's a mistake to assume that just because there aren't currently good interfaces to the existing H.264 encoding hardware that thos= e interfaces will never exist. For instance, the iPhone clearly has real-time capable encoding hardware, and Apple certainly could make it available if they wanted. That's a much simpler proposition than adding hardware where none exists. I'm not sure that the situation is quite that simple, I think that many of = the currently deployed GPUs would be capable of accelerating VP8 with a firmware update. One can speculate endlessly about the future, but one of the benefits of h2= 64 is that the hardware is deployed. However when you examine this claim, we find= that it is only available to the platform owner, so we risk having a vendor lock-in where t= he platform browser has access to performance that 3rd party browsers don't . Tim. -Ekr --_000_949EF20990823C4C85C18D59AA11AD8B0C6D75FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
And this is where it would be use= ful to see some work done, although probably not by IETF.
 
There a a few bits of API work ou= t there, but nowhere do we see much push for adoption. As fae as I see= there is no political reason why they should not be adopted, or even a fresh effort adopted to create some new ones. The on= ly thing seems to be lack of impetus.
 
regards
 
Keith

From: rtcweb-bounces@ietf.org [mail= to:rtcweb-bounces@ietf.org] On Behalf Of tim panton
Sent: 03 November 2013 10:50
To: Eric Rescorla
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Platforms that support H264 (was: Congratuiati= ons on the Cisco announcement - but we still prefer VP8)


On 2 Nov 2013, at 22:43, Eric Rescorla <ekr@rtfm.com> wrote:


Unfortunately it is on mobile that these codecs are not available.

On a related note: it's a mistake to assume that just because there ar= en't
currently good interfaces to the existing H.264 encoding hardware that= those
interfaces will never exist. For instance, the iPhone clearly has real= -time
capable encoding hardware, and Apple certainly could make it available=
if they wanted. That's a much simpler proposition than adding hardware=
where none exists.

I’m not sure that the situation is quite that simple, I think th= at many of the currently
deployed GPUs would be capable of accelerating VP8 with a firmware upd= ate.

One can speculate endlessly about the future, but one of the benefits = of h264 is
that the hardware is deployed. However when you examine this claim, we= find that it is only 
available to the platform owner, so we risk having a vendor lock-in wh= ere the
platform browser has access to performance that 3rd party browsers don= ’t .

Tim.


-Ekr


--_000_949EF20990823C4C85C18D59AA11AD8B0C6D75FR712WXCHMBA11zeu_-- From harald@alvestrand.no Sun Nov 3 10:10:30 2013 Return-Path: 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 99E2A21E80FF for ; Sun, 3 Nov 2013 10:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 xTGXmHPxaL+I for ; Sun, 3 Nov 2013 10:10:24 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA7021E80F5 for ; Sun, 3 Nov 2013 10:10:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7214939E176 for ; Sun, 3 Nov 2013 19:10:23 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk3+RMDKQnGi for ; Sun, 3 Nov 2013 19:10:22 +0100 (CET) Received: from [172.19.244.5] (unknown [216.239.45.130]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 68D4239E091 for ; Sun, 3 Nov 2013 19:10:22 +0100 (CET) Message-ID: <5276918B.4040207@alvestrand.no> Date: Sun, 03 Nov 2013 19:10:19 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <949EF20990823C4C85C18D59AA11AD8B0C6D75@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0C6D75@FR712WXCHMBA11.zeu.alcatel-lucent.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------020800050505030801020808" Subject: [rtcweb] API standardization on phones? (Re: Platforms that support H264) X-BeenThere: rtcweb@ietf.org 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: Sun, 03 Nov 2013 18:10:30 -0000 This is a multi-part message in MIME format. --------------020800050505030801020808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/03/2013 06:52 PM, DRAGE, Keith (Keith) wrote: > And this is where it would be useful to see some work done, although > probably not by IETF. > > There a a few bits of API work out there, but nowhere do we see much > push for adoption. As fae as I see there is no political reason why > they should not be adopted, or even a fresh effort adopted to create > some new ones. The only thing seems to be lack of impetus. What's the industry state on standardization of APIs for phones? Most of what I see seems to be platform specific, with some exceptions (OpenGL / WebGL for graphics, OpenES for audio). But it's not where I spend the most time looking; it would be good to have someone who knows this space summarize. --------------020800050505030801020808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/03/2013 06:52 PM, DRAGE, Keith (Keith) wrote:
And this is where it would be useful to see some work done, although probably not by IETF.
 
There a a few bits of API work out there, but nowhere do we see much push for adoption. As fae as I see there is no political reason why they should not be adopted, or even a fresh effort adopted to create some new ones. The only thing seems to be lack of impetus.

What's the industry state on standardization of APIs for phones?

Most of what I see seems to be platform specific, with some exceptions (OpenGL / WebGL for graphics, OpenES for audio).

But it's not where I spend the most time looking; it would be good to have someone who knows this space summarize.


--------------020800050505030801020808-- From keith.drage@alcatel-lucent.com Sun Nov 3 12:35:10 2013 Return-Path: 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 4ACD011E8143 for ; Sun, 3 Nov 2013 12:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.505 X-Spam-Level: X-Spam-Status: No, score=-110.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 JZI-RP1l-upi for ; Sun, 3 Nov 2013 12:35:04 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 31B3C11E8123 for ; Sun, 3 Nov 2013 12:35:04 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rA3KYwDC003904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 3 Nov 2013 14:34:59 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rA3KYvwR025431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Nov 2013 21:34:57 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sun, 3 Nov 2013 21:34:57 +0100 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] API standardization on phones? (Re: Platforms that support H264) Thread-Index: AQHO2MAAeqJEr6VKRUS16n0ERsAx65oT9j1Q Date: Sun, 3 Nov 2013 20:34:56 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0C6F9D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <949EF20990823C4C85C18D59AA11AD8B0C6D75@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5276918B.4040207@alvestrand.no> In-Reply-To: <5276918B.4040207@alvestrand.no> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0C6F9DFR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [rtcweb] API standardization on phones? (Re: Platforms that support H264) X-BeenThere: rtcweb@ietf.org 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: Sun, 03 Nov 2013 20:35:10 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B0C6F9DFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The only stuff I am aware of is done by http://www.khronos.org/ But that is as far as my knowledge goes. It would certainly be desireable that there is an standardised API that eve= ryone uses to get access to embedded hardware codec support. Keith ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: 03 November 2013 18:10 To: rtcweb@ietf.org Subject: [rtcweb] API standardization on phones? (Re: Platforms that suppor= t H264) On 11/03/2013 06:52 PM, DRAGE, Keith (Keith) wrote: And this is where it would be useful to see some work done, although probab= ly not by IETF. There a a few bits of API work out there, but nowhere do we see much push f= or adoption. As fae as I see there is no political reason why they should n= ot be adopted, or even a fresh effort adopted to create some new ones. The = only thing seems to be lack of impetus. What's the industry state on standardization of APIs for phones? Most of what I see seems to be platform specific, with some exceptions (Ope= nGL / WebGL for graphics, OpenES for audio). But it's not where I spend the most time looking; it would be good to have = someone who knows this space summarize. --_000_949EF20990823C4C85C18D59AA11AD8B0C6F9DFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The only stuff I am aware of is d= one by
 
 
But that is as far as my knowledg= e goes.
 
It would certainly be desireable = that there is an standardised API that everyone uses to get access to embed= ded hardware codec support.
 
Keith

From: rtcweb-bounces@ietf.org [mail= to:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 03 November 2013 18:10
To: rtcweb@ietf.org
Subject: [rtcweb] API standardization on phones? (Re: Platforms that= support H264)

On 11/03/2013 06:52 PM, DRAGE, Keith (Keith)= wrote:
And this is where it would be use= ful to see some work done, although probably not by IETF.
&= nbsp;
There a a few bits of API work ou= t there, but nowhere do we see much push for adoption. As fae as I see= there is no political reason why they should not be adopted, or even a fresh effort adopted to create some new ones. The on= ly thing seems to be lack of impetus.

What's the in= dustry state on standardization of APIs for phones?

Most of what I see seems to be platform specific, with some exceptions (Ope= nGL / WebGL for graphics, OpenES for audio).

But it's not where I spend the most time looking; it would be good to have = someone who knows this space summarize.


--_000_949EF20990823C4C85C18D59AA11AD8B0C6F9DFR712WXCHMBA11zeu_-- From uwe.rauschenbach@nsn.com Sun Nov 3 15:11:51 2013 Return-Path: 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 E6C8821E8127 for ; Sun, 3 Nov 2013 15:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pkRxi-pt9MQl for ; Sun, 3 Nov 2013 15:11:46 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3461921E8126 for ; Sun, 3 Nov 2013 15:11:32 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rA3NBRMJ008194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Nov 2013 00:11:27 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rA3NBQfF030040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 00:11:26 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Nov 2013 00:11:26 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.220]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 00:11:26 +0100 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "fluffy@iii.ca" , ext Justin Uberti , "rtcweb@ietf.org" Thread-Topic: Provisional answers in JSEP draft Thread-Index: Ac7YvPftdbBA+IsbQWCmW52pP7Z6Ww== Date: Sun, 3 Nov 2013 23:11:25 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF813E01D@DEMUMBX005.nsn-intra.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.124] Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF813E01DDEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10196 X-purgate-ID: 151667::1383520287-00005753-D7EC8993/0-0/0-0 Subject: [rtcweb] Provisional answers in JSEP draft X-BeenThere: rtcweb@ietf.org 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: Sun, 03 Nov 2013 23:11:52 -0000 --_000_56C2F665D49E0341B9DF5938005ACDF813E01DDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have some questions regarding section 4.1.3.1 (Use of Provisional Answers= ) in the JSEP-05 draft. The text reads as follows: 4.1.3.1 Use of Provisional Answers Most web applications will not need to create answers using the "pranswer" type. The preferred handling for a web application would be to create and send an "inactive" answer more or less immediately after receiving the offer, instead of waiting for a human user to physically answer the call. Later, when the human input is received, the application can create a new "sendrecv" offer to update the previous offer/answer pair and start the media flow. This approach is preferred because it minimizes the amount of time that the offer/answer exchange is left open, in addition to avoiding media clipping by ensuring the transport is ready to go by the time the call is physically answered. However, some applications may not be able to do this, particularly ones that are attempting to gateway to other signaling protocols. In these cases, "pranswer" can still allow the application to warm up the transport. Consider a typical web application that will set up a data channel, an audio channel, and a video channel. When an endpoint receives an offer with these channels, it could send an answer accepting the data channel for two-way data, and accepting the audio and video tracks as inactive or receive-only. It could then ask the user to accept the call, acquire the local media streams, and send a new offer to the remote side moving the audio and video to be two-way media. By the time the human has accepted the call and sent the new offer, it is likely that the ICE and DTLS handshaking for all the channels will already be set up. I have two questions: 1) What is meant here by "the offer-answer exchange is left open"? In anoth= er place in the document, it is stated that in fact pranswer is like any an= swer except that resources (I assume from previous pranswers) are not freed= until the final answer arrives. So, what's the actual drawback here? Is th= ere a performance penalty? This should be stated more clearly. 2) I do not understand why "pranswer" supposedly leads to media clipping bu= t "answer" does not. AFAIU, if the pranswer from the callee contains sendre= cv media sections, ICE runs immediately after the pranswer has been install= ed in the caller's browser, and media pathes are set up both ways without d= elay. If, as recommended above, the callee sends a recvonly answer first, I= CE will initially only create a media path for the direction from the calle= r to the callee, and then create a media path in the other direction after = the new offer from the callee has been received by the caller's application= . So there may be clipping in the path from the callee to the caller. This = conflicts with what is stated in the text. Do I overlook something? Does th= e text need an update? Kind regards, Uwe --_000_56C2F665D49E0341B9DF5938005ACDF813E01DDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have some questions regarding section 4.1.3.1 (Use of Provisional Answers) in the JSEP-05 draft.
 
The text reads as follows:
 
 4.1.3.1 Use of Provisional Answers
 
Most = web applications will not need to create answers using the
"= ;pranswer" type. The preferred handling for a web application would
be to= create and send an "inactive" answer more or less immediately
after= receiving the offer, instead of waiting for a human user to<= /div>
physi= cally answer the call. Later, when the human input is received,
the a= pplication can create a new "sendrecv" offer to update the=
previ= ous offer/answer pair and start the media flow. This approach=
is pr= eferred because it minimizes the amount of time that the offer/answer
excha= nge is left open, in addition to avoiding media clipping
by en= suring the transport is ready to go by the time the call is
physi= cally answered. However, some applications may not be able to=
do th= is, particularly ones that are attempting to gateway to other=
signa= ling protocols. In these cases, "pranswer" can still allow the
appli= cation to warm up the transport.
 
Consi= der a typical web application that will set up a data channel,
an au= dio channel, and a video channel. When an endpoint receives an
offer= with these channels, it could send an answer accepting the data
chann= el for two-way data, and accepting the audio and video tracks as
inact= ive or receive-only. It could then ask the user to accept the=
call,= acquire the local media streams, and send a new offer to the=
remot= e side moving the audio and video to be two-way media. By the=
time = the human has accepted the call and sent the new offer, it is=
likel= y that the ICE and DTLS handshaking for all the channels will=
alrea= dy be set up.
 
 
I have= two questions:
 
1) Wha= t is meant here by „the offer-answer exchange is left open”? In= another place in the document, it is stated that in fact pranswer is like = any answer except that resources (I assume from previous pranswers) are not freed until the final answer arrives. So, what’s t= he actual drawback here? Is there a performance penalty? This should be sta= ted more clearly.
 
2) I d= o not understand why “pranswer” supposedly leads to media clipp= ing but “answer” does not. AFAIU, if the pranswer from the call= ee contains sendrecv media sections, ICE runs immediately after the pranswer has been installed in the caller’s browser, and media pa= thes are set up both ways without delay. If, as recommended above, the call= ee sends a recvonly answer first, ICE will initially only create a media pa= th for the direction from the caller to the callee, and then create a media path in the other direction after the n= ew offer from the callee has been received by the caller’s applicatio= n. So there may be clipping in the path from the callee to the caller. This= conflicts with what is stated in the text. Do I overlook something? Does the text need an update?<= /div>
 
 
Kind r= egards,
Uwe
 =
 
 
 
 --_000_56C2F665D49E0341B9DF5938005ACDF813E01DDEMUMBX005nsnintr_-- From cowwoc@bbs.darktech.org Sun Nov 3 15:40:15 2013 Return-Path: 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 62D1711E8252 for ; Sun, 3 Nov 2013 15:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[AWL=-1.297, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 kZiH0PaOmeWg for ; Sun, 3 Nov 2013 15:40:09 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id C659711E8257 for ; Sun, 3 Nov 2013 15:39:58 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so11181682iet.18 for ; Sun, 03 Nov 2013 15:39:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=0YdhLY/nyHyFesPcVITS7BCFInk1cJSLIhFJaE/r8pA=; b=BxsL0JT6NSp2xfRqmDYJ2RElqhdEHJqgGbv80Lagbj83C1WeEF1VIgqFvGMP74sBJB OzeZgFJOvUpg1b44RpGfup2vI/qEAR+iZuzmZwbGYj9/h+I+I8KtRrbEKSo7noUzLtnd jsAT9CshNAyMATIA1aB5SPNCgNYiX7PSVbYdFFsPbGSG8XLWT0gssG33LvVPp7DN6YW4 laxum9OzFSFPESejqx0zwImLI3Tg+UbuGitlwZd5ngwdv9Re/0F5m+nZDj5c/tYK8gmh 2081TUDk1IhuobHa20PrsIFbykGNj+oIVnR+3gNa5ptr0J70fotM6o+FWOxJLAIfeBlj WsWA== X-Gm-Message-State: ALoCoQkFx9R2tu7q/Xwxyg5p6b1qYs2xLwjIee5S/lcy90SEidX4h89rs0cAHGZ05qAKU+zhgoy9 X-Received: by 10.50.20.99 with SMTP id m3mr9918460ige.54.1383521997352; Sun, 03 Nov 2013 15:39:57 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id yt10sm18057951igb.9.2013.11.03.15.39.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 15:39:56 -0800 (PST) Message-ID: <5276DECA.7080604@bbs.darktech.org> Date: Sun, 03 Nov 2013 18:39:54 -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: Eric Rescorla References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <52755A0E.4020007@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020301010802070703060107" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sun, 03 Nov 2013 23:40:15 -0000 X-List-Received-Date: Sun, 03 Nov 2013 23:40:15 -0000 This is a multi-part message in MIME format. --------------020301010802070703060107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Eric, In general, * Browsers are more likely to be open-source than applications, and therefore are more flexible regarding the plugin licenses that are acceptable. * Most browsers have a plug-in architecture, allowing them to download codecs on demand. The same is not true of most applications. I suspect that if we find a solution that works for non-browser applications, it'll likely work for browsers but not necessarily the other way around. These are generalizations, so I expect you will find exceptions to the rule. Gili On 02/11/2013 6:18 PM, Eric Rescorla wrote: > > > > On Sat, Nov 2, 2013 at 1:01 PM, Gili > wrote: > > Martin, > > I fully understand why Firefox would be happy but as someone > who plan to integrate WebRTC into a non-browser application, > especially on iOS, Cisco's solution simply does not work. I > appreciate their contribution, but again, it simply doesn't help > my use-case. > > > I haven't seen you explain how your use case is different from that of > a browser. Could you please do so? > > -Ekr > > Gili > > > On 11/2/2013 11:02 AM, Martin Thomson wrote: > > On 2 November 2013 07:37, cowwoc > wrote: > > I can't think of a single platform that supports > real-time H.264 > encoding/decoding natively today. > > That's a very strange way to put the question. > > Let me put another spin on it, and please excuse the example... > > Skype runs on more platforms than you might think. Those > platforms > can all support H.264 to the extent that Skype requires. > > Cisco's generous offer opens almost the same capability to anyone, > with the caveat that some platforms currently remain closed. Of > course, you could let your ideals get in the way of progress. > Me, I'm > a pragmatist. This gift represents a great opportunity for > people who > actually care about the practical outcomes. > > There's been a lot of mouth-gazing of gift horses on this list of > late. I sure hope that this isn't representative of the real > sentiment of the community. I'd like to think that people are > better > than that. > > (BTW, I understand and respect Harald's position. From where > he sits, > I'm sure that his conclusion makes perfect sense.) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------020301010802070703060107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Eric,

In general,
  • Browsers are more likely to be open-source than applications, and therefore are more flexible regarding the plugin licenses that are acceptable.
  • Most browsers have a plug-in architecture, allowing them to download codecs on demand. The same is not true of most applications.
I suspect that if we find a solution that works for non-browser applications, it'll likely work for browsers but not necessarily the other way around. These are generalizations, so I expect you will find exceptions to the rule.

Gili

On 02/11/2013 6:18 PM, Eric Rescorla wrote:



On Sat, Nov 2, 2013 at 1:01 PM, Gili <cowwoc@bbs.darktech.org> wrote:
Martin,

    I fully understand why Firefox would be happy but as someone who plan to integrate WebRTC into a non-browser application, especially on iOS, Cisco's solution simply does not work. I appreciate their contribution, but again, it simply doesn't help my use-case.

I haven't seen  you explain how your use case is different from that of
a browser. Could you please do so?

-Ekr
 
Gili


On 11/2/2013 11:02 AM, Martin Thomson wrote:
On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
     I can't think of a single platform that supports real-time H.264
encoding/decoding natively today.
That's a very strange way to put the question.

Let me put another spin on it, and please excuse the example...

Skype runs on more platforms than you might think.  Those platforms
can all support H.264 to the extent that Skype requires.

Cisco's generous offer opens almost the same capability to anyone,
with the caveat that some platforms currently remain closed.  Of
course, you could let your ideals get in the way of progress.  Me, I'm
a pragmatist.  This gift represents a great opportunity for people who
actually care about the practical outcomes.

There's been a lot of mouth-gazing of gift horses on this list of
late.  I sure hope that this isn't representative of the real
sentiment of the community.  I'd like to think that people are better
than that.

(BTW, I understand and respect Harald's position.  From where he sits,
I'm sure that his conclusion makes perfect sense.)

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--------------020301010802070703060107-- From cowwoc@bbs.darktech.org Sun Nov 3 15:41:25 2013 Return-Path: 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 96A0121E8131 for ; Sun, 3 Nov 2013 15:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 3-FUc-PZFVu3 for ; Sun, 3 Nov 2013 15:41:17 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id ECA1E21E8118 for ; Sun, 3 Nov 2013 15:41:16 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id qd12so11209683ieb.33 for ; Sun, 03 Nov 2013 15:41:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=a5ZrlQt3Bv09QrI9nVx9ZhZ5Z+fgE00T2VYoR87GFEo=; b=bgauY/E5EBh1rJ+1LYFE4Wk9cSp2kGHEjNmLxEJ+q7FCOQKtD4BwhEKHkLzQFUgVPX c0E2dVFJL7muTv0VZ68qXTdoeTXNL/SmnRhGpsy3WosenK8h3zj2AVop9ztsSC6helVV zlo+WAgB/3iiJW/WD7tlQo13dDu8+cdz3nTgFgfeocIwYXDdZvZPLbhrySixFl2cgELj /4+jYlNVOfOO/KrOOvAItCOKi5SEchOdqdf727+j45qHKJFU+WXUsMeOKvDB5PbsA5Id B+MeQQJkyZfuG/j9JSP6a3cT61XkSlSo3fXsoSr1c/oufz4guCrtJ5thUS3qwwYknp3R /NHg== X-Gm-Message-State: ALoCoQlYVpSAWrY5joOgXPhgBVkh951KacOo9Xl7gql2aLVdG5RKHATF17Set1G84zzDYoZUr2AP X-Received: by 10.50.20.226 with SMTP id q2mr9933161ige.11.1383522072426; Sun, 03 Nov 2013 15:41:12 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id w7sm18088500igp.1.2013.11.03.15.41.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 15:41:11 -0800 (PST) Message-ID: <5276DF16.8090204@bbs.darktech.org> Date: Sun, 03 Nov 2013 18:41:10 -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: rtcweb@ietf.org References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060803000004090503010808" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Sun, 03 Nov 2013 23:41:25 -0000 This is a multi-part message in MIME format. --------------060803000004090503010808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have no idea what the future will hold, but I know that as of today H.264 does not seem to enjoy much stronger platform support than VP8 (with respect to real-time encoding/decoding support). Gili On 02/11/2013 6:43 PM, Eric Rescorla wrote: > > > > On Sat, Nov 2, 2013 at 3:28 PM, Emil Ivov > wrote: > > I'd encourage you to read back. > > This part of the thread started with the claim that most of the > time it won't come to downloading Cisco's binary because there is > already widespread OS support for H.264 encoding on all OSes > > > I assume you're referring to Bernard's comment? If so, I don't think > that's actually > what he said. > > In any case, speaking as someone who actually has to deal with this, > it's more > work to maintain more code paths. Thus, I anticipate using Cisco's > binary on > all desktop platforms and only using platform codecs where it offers a > significant > performance advantage, e.g., on mobile. > > On a related note: it's a mistake to assume that just because there aren't > currently good interfaces to the existing H.264 encoding hardware that > those > interfaces will never exist. For instance, the iPhone clearly has > real-time > capable encoding hardware, and Apple certainly could make it available > if they wanted. That's a much simpler proposition than adding hardware > where none exists. > > -Ekr > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060803000004090503010808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    I have no idea what the future will hold, but I know that as of today H.264 does not seem to enjoy much stronger platform support than VP8 (with respect to real-time encoding/decoding support).

Gili

On 02/11/2013 6:43 PM, Eric Rescorla wrote:



On Sat, Nov 2, 2013 at 3:28 PM, Emil Ivov <emcho@jitsi.org> wrote:

I'd encourage you to read back.

This part of the thread started with the claim that most of the time it won't come to downloading Cisco's binary because there is already widespread OS support for H.264 encoding on all OSes


I assume you're referring to Bernard's comment? If so, I don't think that's actually
what he said.

In any case, speaking as someone who actually has to deal with this, it's more
work to maintain more code paths. Thus, I anticipate using Cisco's binary on
all desktop platforms and only using platform codecs where it offers a significant
performance advantage, e.g., on mobile.

On a related note: it's a mistake to assume that just because there aren't
currently good interfaces to the existing H.264 encoding hardware that those
interfaces will never exist. For instance, the iPhone clearly has real-time
capable encoding hardware, and Apple certainly could make it available
if they wanted. That's a much simpler proposition than adding hardware
where none exists.

-Ekr



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------060803000004090503010808-- From randell-ietf@jesup.org Sun Nov 3 20:20:15 2013 Return-Path: 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 42E7021E80F8 for ; Sun, 3 Nov 2013 20:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 XVPPDu26OhJJ for ; Sun, 3 Nov 2013 20:20:09 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 512B621E80F3 for ; Sun, 3 Nov 2013 20:20:09 -0800 (PST) Received: from [64.114.24.114] (port=50308 helo=[142.131.18.239]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VdBe3-000AUj-8n for rtcweb@ietf.org; Sun, 03 Nov 2013 22:20:07 -0600 Message-ID: <52772073.6090000@jesup.org> Date: Sun, 03 Nov 2013 20:20:03 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070106090907040607050703" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 04:20:15 -0000 This is a multi-part message in MIME format. --------------070106090907040607050703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/2/2013 7:00 AM, Bernard Aboba wrote: > Those enterprise scenarios often either involve a defined software > image that could include the Cisco plugin (does it always have to be > downloaded?) OR involve a relatively recent OS, with native H.264 > support. So I am not sure this need come up that often. IANAPL (I Am Not A Patent Lawyer) - but if you make an image that includes Cisco's plugin for imaging machines, that would be a violation of the rules - you would be the one distributing it to end-use systems. While you're unlikely to get pinged on it, the company lawyers may not see it that way, and it might show up flagged in an audit, and IT guys don't like that. There are also some systems that don't generally allow plugins of any sort (such as Metro IIRC); though those might have native H.264 encode/decode support. Note that platform encode/decode support for WebRTC is more problematic than software support, since the H.264 encoders (hell, even decoders) may be of questionable stability. (You'll note the blacklists/whitelists Mozilla uses for platform decoder support on Android, for example, because some of them have problems.) How serious that problem is (and how serious it is for encoders) is not clear. There's also the issue of what knobs are available to tune the encoder, especially for resiliency options. > > On Nov 2, 2013, at 3:35 AM, "Emil Ivov" > wrote: >> >> Also, while Cisco's grant is quite interesting for certain scenarios >> it could be very problematic for others. For example: enterprises >> where installations are handled in a controlled and automated way >> (e.g. scripted image deployment) and where subsequent Internet access >> could be limited for various reasons. >> >> Emil >> >> -- >> -- Randell Jesup randell-ietf@jesup.org --------------070106090907040607050703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/2/2013 7:00 AM, Bernard Aboba wrote:
Those enterprise scenarios often either involve a defined software image that could include the Cisco plugin (does it always have to be downloaded?) OR involve a relatively recent OS, with native H.264 support. So I am not sure this need come up that often.

IANAPL (I Am Not A Patent Lawyer) - but if you make an image that includes Cisco's plugin for imaging machines, that would be a violation of the rules - you would be the one distributing it to end-use systems.  While you're unlikely to get pinged on it, the company lawyers may not see it that way, and it might show up flagged in an audit, and IT guys don't like that.

There are also some systems that don't generally allow plugins of any sort (such as Metro IIRC); though those might have native H.264 encode/decode support.  Note that platform encode/decode support for WebRTC is more problematic than software support, since the H.264 encoders (hell, even decoders) may be of questionable stability.  (You'll note the blacklists/whitelists Mozilla uses for platform decoder support on Android, for example, because some of them have problems.)  How serious that problem is (and how serious it is for encoders) is not clear.   There's also the issue of what knobs are available to tune the encoder, especially for resiliency options.


On Nov 2, 2013, at 3:35 AM, "Emil Ivov" <emcho@jitsi.org> wrote:

Also, while Cisco's grant is quite interesting for certain scenarios it could be very problematic for others. For example: enterprises where installations are handled in a controlled and automated way (e.g. scripted image deployment) and where subsequent Internet access could be limited for various reasons. 

Emil

--



-- 
Randell Jesup
randell-ietf@jesup.org
--------------070106090907040607050703-- From randell-ietf@jesup.org Sun Nov 3 20:44:39 2013 Return-Path: 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 CC2F321F9BC1 for ; Sun, 3 Nov 2013 20:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 jYnJb1U5nL5P for ; Sun, 3 Nov 2013 20:44:34 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7198711E818A for ; Sun, 3 Nov 2013 20:44:31 -0800 (PST) Received: from [64.114.24.114] (port=51008 helo=[142.131.18.239]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VdC1e-000Gxu-Vg for rtcweb@ietf.org; Sun, 03 Nov 2013 22:44:31 -0600 Message-ID: <5277262E.3050600@jesup.org> Date: Sun, 03 Nov 2013 20:44:30 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------080009010509060703020004" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Subject: Re: [rtcweb] API standardization on phones? (Re: Platforms that support H264) X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 04:44:39 -0000 This is a multi-part message in MIME format. --------------080009010509060703020004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/3/2013 12:34 PM, DRAGE, Keith (Keith) wrote: > The only stuff I am aware of is done by > http://www.khronos.org/ > But that is as far as my knowledge goes. My understanding from someone at Skype who worked with OMX stuff was that it was horribly poorly compatible because most people never ran any of the test suites that Kronos charges for. Take with a huge grain of salt as this is second-hand and wasn't the primary topic. > It would certainly be desireable that there is an standardised API > that everyone uses to get access to embedded hardware codec support. Always a good thing, if it's done well. > Keith > > ------------------------------------------------------------------------ > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] > *On Behalf Of *Harald Alvestrand > *Sent:* 03 November 2013 18:10 > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] API standardization on phones? (Re: Platforms > that support H264) > > On 11/03/2013 06:52 PM, DRAGE, Keith (Keith) wrote: >> And this is where it would be useful to see some work done, >> although probably not by IETF. >> There a a few bits of API work out there, but nowhere do we see >> much push for adoption. As fae as I see there is no political >> reason why they should not be adopted, or even a fresh effort >> adopted to create some new ones. The only thing seems to be lack >> of impetus. > > What's the industry state on standardization of APIs for phones? > > Most of what I see seems to be platform specific, with some > exceptions (OpenGL / WebGL for graphics, OpenES for audio). > > But it's not where I spend the most time looking; it would be good > to have someone who knows this space summarize > -- Randell Jesup randell-ietf@jesup.org --------------080009010509060703020004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/3/2013 12:34 PM, DRAGE, Keith (Keith) wrote:
The only stuff I am aware of is done by
 
 
But that is as far as my knowledge goes.

My understanding from someone at Skype who worked with OMX stuff was that it was horribly poorly compatible because most people never ran any of the test suites that Kronos charges for.  Take with a huge grain of salt as this is second-hand and wasn't the primary topic.

 
It would certainly be desireable that there is an standardised API that everyone uses to get access to embedded hardware codec support.

Always a good thing, if it's done well.

 
Keith

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 03 November 2013 18:10
To: rtcweb@ietf.org
Subject: [rtcweb] API standardization on phones? (Re: Platforms that support H264)

On 11/03/2013 06:52 PM, DRAGE, Keith (Keith) wrote:
And this is where it would be useful to see some work done, although probably not by IETF.
 
There a a few bits of API work out there, but nowhere do we see much push for adoption. As fae as I see there is no political reason why they should not be adopted, or even a fresh effort adopted to create some new ones. The only thing seems to be lack of impetus.

What's the industry state on standardization of APIs for phones?

Most of what I see seems to be platform specific, with some exceptions (OpenGL / WebGL for graphics, OpenES for audio).

But it's not where I spend the most time looking; it would be good to have someone who knows this space summarize 

-- 
Randell Jesup
randell-ietf@jesup.org
--------------080009010509060703020004-- From juberti@google.com Sun Nov 3 22:31:22 2013 Return-Path: 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 1EBD911E82C1 for ; Sun, 3 Nov 2013 22:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 f+nE-hzkfZpy for ; Sun, 3 Nov 2013 22:31:21 -0800 (PST) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADB211E81A0 for ; Sun, 3 Nov 2013 22:31:20 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id hz11so4334851vcb.38 for ; Sun, 03 Nov 2013 22:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=neCrBt1nQXB18ZsAwweMBVrY+UVvsL5/57etkvsfSrY=; b=JAKQ13juqj9clsviWzzMNj+eLppO1GsbQ2U3ezhEDBgSWGbKnX+aWl03nI76W4tBou oImRGYSUGGMI9Jn6/8Ccnguqr5eFolVzCyZKa9rrjOO1xIlRlJf8562RkBoGxse8MduK 0C1NXLzMlPv+6Udq6PuTvVAZq2i1LDSNrAreDELN7Enof2okJqgghvz7ZLmyL7KstIDo CJowTdtHpgQ4WhFqNIH1fAUs7P4kpjZXuQO+BsYXMyEPOzi+hxSbR5H2me7KFSB4WlH1 j5PUnUq5Ycsxvqr5ABqpS33WZCzmIxf4ym98q2gG9QZbi2aZ1bUouag3IPFpLlBb2RlZ pptw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=neCrBt1nQXB18ZsAwweMBVrY+UVvsL5/57etkvsfSrY=; b=PuKvWbBJYUu4xTA5s0Md7VShHwI4aXW3rHlgxQlWCTN1nwUDBjz7tmFcE5KEtGIYXr FY4ty0Q6SVXTC3sdxc1657rO3IvgBuwJYEdS23ysHYjAjBSRjW6Wvzot89woIMO5amC0 Lm9zxz3vp5ZXwINQVpwLKoN+SF1Em/OkKR+JpPJuNutERbgu+TOZhx/RL2jW22EVrRFE WGU5RcszKEp9PnhyV2vXNucS6Ugun4NJOcnN2l+uDGgTvoIqXNBUo4YZwsn+vc+1shBt 5PbBldtZmGp3pUkwc9IeIxhiq5MIwgzYxhMSG/JrP4bTKR5r4RsdI+p7s1Wwy5xWHub6 BGPg== X-Gm-Message-State: ALoCoQkFxVbpwh77UIduUgHTdqxax7VCfdzbOwYBE5S84cpVEnuchfyRBS2kANFXgKrm8vOIfTayMgqD9ykSBwccudi8sazRO8EYfbIJqTp+kAy5sxGahyRdIhEXnsU+Ua8hK+MY3QBgUnCM6AU/tyTcypvTypgGPD1o0TiBGqh02UZI62+hm9wTYQIYH40n6/ncY94YQnBp X-Received: by 10.58.161.231 with SMTP id xv7mr10398059veb.2.1383546679762; Sun, 03 Nov 2013 22:31:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Sun, 3 Nov 2013 22:30:59 -0800 (PST) In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF813E01D@DEMUMBX005.nsn-intra.net> References: <56C2F665D49E0341B9DF5938005ACDF813E01D@DEMUMBX005.nsn-intra.net> From: Justin Uberti Date: Sun, 3 Nov 2013 22:30:59 -0800 Message-ID: To: "Rauschenbach, Uwe (NSN - DE/Munich)" Content-Type: multipart/alternative; boundary=047d7b67747260c30804ea541086 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Provisional answers in JSEP draft X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 06:31:22 -0000 --047d7b67747260c30804ea541086 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 3, 2013 at 3:11 PM, Rauschenbach, Uwe (NSN - DE/Munich) < uwe.rauschenbach@nsn.com> wrote: > Hi, > > I have some questions regarding section 4.1.3.1 (Use of Provisional > Answers) in the JSEP-05 draft. > > The text reads as follows: > > 4.1.3.1 Use of Provisional Answers > > Most web applications will not need to create answers using the > "pranswer" type. The preferred handling for a web application would > be to create and send an "inactive" answer more or less immediately > after receiving the offer, instead of waiting for a human user to > physically answer the call. Later, when the human input is received, > the application can create a new "sendrecv" offer to update the > previous offer/answer pair and start the media flow. This approach > is preferred because it minimizes the amount of time that the offer/answe= r > exchange is left open, in addition to avoiding media clipping > by ensuring the transport is ready to go by the time the call is > physically answered. However, some applications may not be able to > do this, particularly ones that are attempting to gateway to other > signaling protocols. In these cases, "pranswer" can still allow the > application to warm up the transport. > > Consider a typical web application that will set up a data channel, > an audio channel, and a video channel. When an endpoint receives an > offer with these channels, it could send an answer accepting the data > channel for two-way data, and accepting the audio and video tracks as > inactive or receive-only. It could then ask the user to accept the > call, acquire the local media streams, and send a new offer to the > remote side moving the audio and video to be two-way media. By the > time the human has accepted the call and sent the new offer, it is > likely that the ICE and DTLS handshaking for all the channels will > already be set up. > > > I have two questions: > > 1) What is meant here by =E2=80=9Ethe offer-answer exchange is left open= =E2=80=9D? In > another place in the document, it is stated that in fact pranswer is like > any answer except that resources (I assume from previous pranswers) are n= ot > freed until the final answer arrives. So, what=E2=80=99s the actual drawb= ack here? > Is there a performance penalty? This should be stated more clearly. > The main issue is that further offers are not permitted while in this state. I can add this to the next version. > > 2) I do not understand why =E2=80=9Cpranswer=E2=80=9D supposedly leads to= media clipping > but =E2=80=9Canswer=E2=80=9D does not. AFAIU, if the pranswer from the ca= llee contains > sendrecv media sections, ICE runs immediately after the pranswer has been > installed in the caller=E2=80=99s browser, and media pathes are set up bo= th ways > without delay. If, as recommended above, the callee sends a recvonly answ= er > first, ICE will initially only create a media path for the direction from > the caller to the callee, and then create a media path in the other > direction after the new offer from the callee has been received by the > caller=E2=80=99s application. So there may be clipping in the path from t= he callee > to the caller. This conflicts with what is stated in the text. Do I > overlook something? Does the text need an update? > Yes, the text is unclear here. The intent was to indicate that both approaches avoid media clipping, but the pranswer one leaves the O/A exchange open. Regarding your comment about ICE, ICE will be established even when the callee replies with an inactive answer, so there should be no clipping. > > Kind regards, > Uwe > > > > > --047d7b67747260c30804ea541086 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Nov 3, 2013 at 3:11 PM, Rauschenbach, Uwe (NSN - DE/Munich)= <uwe.rauschenbach@nsn.com> wrote:
Hi,
=C2=A0
I have some questions regarding section 4.1.3.1 (Use of Provisional Answers) i= n the JSEP-05 draft.
=C2=A0
The text reads as follows:
=C2=A0
=C2=A04.1.3.= 1 Use of Provis= ional Answers
=C2=A0
Most web applicat= ions will not need to create answers using the
"pranswer&qu= ot; type. The preferred handling for a web application would<= /div>
be to create and = send an "inactive" answer more or less immediately<= /div>
after receiving t= he offer, instead of waiting for a human user to
physically answer= the call. Later, when the human input is received,
the application c= an create a new "sendrecv" offer to update the
previous offer/an= swer pair and start the media flow. This approach
is preferred beca= use it minimizes the amount of time that the offer/answer
exchange is left = open, in addition to avoiding media clipping
by ensuring the t= ransport is ready to go by the time the call is
physically answer= ed. However, some applications may not be able to
do this, particul= arly ones that are attempting to gateway to other
signaling protoco= ls. In these cases, "pranswer" can still allow the<= /div>
application to wa= rm up the transport.
=C2=A0
Consider a typica= l web application that will set up a data channel,
an audio channel,= and a video channel. When an endpoint receives an
offer with these = channels, it could send an answer accepting the data
channel for two-w= ay data, and accepting the audio and video tracks as
inactive or recei= ve-only. It could then ask the user to accept the
call, acquire the= local media streams, and send a new offer to the
remote side movin= g the audio and video to be two-way media. By the
time the human ha= s accepted the call and sent the new offer, it is
likely that the I= CE and DTLS handshaking for all the channels will
already be set up= .
=C2=A0
=C2=A0
I have two questio= ns:
=C2=A0
1) What is meant h= ere by =E2=80=9Ethe offer-answer exchange is left open=E2=80=9D? In another= place in the document, it is stated that in fact pranswer is like any answ= er except that resources (I assume from previous pranswers) are not freed until the final answer arrives. So, what=E2=80=99s= the actual drawback here? Is there a performance penalty? This should be s= tated more clearly.

The main issue is that further offers are not permitted while in= this state. I can add this to the next version.=C2=A0
=C2=A0
2) I do not unders= tand why =E2=80=9Cpranswer=E2=80=9D supposedly leads to media clipping but = =E2=80=9Canswer=E2=80=9D does not. AFAIU, if the pranswer from the callee c= ontains sendrecv media sections, ICE runs immediately after the pranswer has been installed in the caller=E2=80=99s browser, and media = pathes are set up both ways without delay. If, as recommended above, the ca= llee sends a recvonly answer first, ICE will initially only create a media = path for the direction from the caller to the callee, and then create a media path in the other direction after the n= ew offer from the callee has been received by the caller=E2=80=99s applicat= ion. So there may be clipping in the path from the callee to the caller. Th= is conflicts with what is stated in the text. Do I overlook something? Does the text need an update?<= /div>

Yes, the text is = unclear here. The intent was to indicate that both approaches avoid media c= lipping, but the pranswer one leaves the O/A exchange open.

Regarding your comment about ICE, ICE will be establish= ed even when the callee replies with an inactive answer, so there should be= no clipping.

=C2=A0
=C2=A0
Kind regards,
Uwe
=C2=A0
=C2=A0
=C2=A0
=C2=A0

--047d7b67747260c30804ea541086-- From juberti@google.com Sun Nov 3 22:43:58 2013 Return-Path: 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 E8EE221F9B07 for ; Sun, 3 Nov 2013 22:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 17xJ-fIRngcO for ; Sun, 3 Nov 2013 22:43:58 -0800 (PST) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9287811E810A for ; Sun, 3 Nov 2013 22:43:46 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p6so1147083vbe.32 for ; Sun, 03 Nov 2013 22:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IVlG2VRvWfXzq0WW+tbFmLSDDpUFmMO8hmKKVm9Ek+8=; b=S4iM2MshhCLiQeT8aeA19+YBu75cbe1wimq3t1Ygl5Sb5CvOMkinU38OXS69fjW1/F RWYkMtLn8zeZNsiv/vJZSoV1Et9C3H0HYcgxWwPgT9btmxMGOokHt8+dSgGhPUTB44nT K0xrHyae+k7WZHQP5ZjcBKvuwkRtYA57YSZMfKc0mrNTDUUN00JGgNxW8ePj+/rXrwIy SfQCgmJS0R3WudwxphJfR9U15Hp9KlQI2lcPx/bNrjTooW9eCLdBSMBJm8OC8nvmLWoa J+/2oBM2/9db3BTgNTL1Uh0ueVeB5nRJ7SJWjjwfkly4NBsNUReTSyX9I6hzhLFVMkhu mvRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IVlG2VRvWfXzq0WW+tbFmLSDDpUFmMO8hmKKVm9Ek+8=; b=H/dvLiq1lfy9ndodtRHsWL+QG1LlLprSwk8/rJDqW5gOp309hRchi9RhnaoqLmWi0c su0alD2A+P75kc1wZHkZ78KuGUvUsTv42q/YtO3QyEf9LxEc/jdfslGK0Yoit+wRUvjq d2Bdg95z7HO5fjxudVcSlBoQQF8t9QsNrkwTBTWMus84q2Vin1T7YwrAy8KWPtRQgCNl OsQCzJU3Rp3iZduM86FT741wPqNncuTeEhbm2twBCtF/AuELDsYyOaF7JmnHdq1zpGSA G/FxC3FjiTQ8BHWg69qMwESWc8b50b9JtTAjVHfaWLm2FJzNOcYpRmU3/cDecVw2yGsb IWtQ== X-Gm-Message-State: ALoCoQkooOzn2ds5OnUqqbJcGEUS/rRKjYK+Lv9Ybqf1BAl6xmAc/OG89Fc/5csdRVbssmwb/EXOpRgTxSN07frCsT297xl+ukIza6MhvgBAAfHfY9D9e4XeQioXwrQnO2XoxUIhQHeEeZRI+1BooN0BPs6gSlduAmXBX0y8P4/Hc732hA4T32sViJ9f2aY1iMxpi1torucz X-Received: by 10.52.97.138 with SMTP id ea10mr470344vdb.31.1383547425332; Sun, 03 Nov 2013 22:43:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Sun, 3 Nov 2013 22:43:25 -0800 (PST) In-Reply-To: <52741A91.5060402@alum.mit.edu> References: <52741A91.5060402@alum.mit.edu> From: Justin Uberti Date: Sun, 3 Nov 2013 22:43:25 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=20cf307f38f8d1355304ea543c23 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - common attributes X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 06:43:59 -0000 --20cf307f38f8d1355304ea543c23 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 1, 2013 at 2:18 PM, Paul Kyzivat wrote: > Section 5.2.1 says: > > Each m= section, provided it is not being bundled into another m= > section, MUST generate a unique set of ICE credentials and gather its > own unique set of ICE candidates. Otherwise, it MUST use the same > ICE credentials and candidates that were used in the m= section that > it is being bundled into. > > But the use of common ICE candidates for bundled m-lines doesn't work > until it is known that bundling will be used. Seems like a few more words > about that are called for. > Sure. When I say "bundled" here, I mean that the actual bundling has occurred, i.e. the streams will be sent over the same transport (in which case they have to use the same ICE info). > > Further on: > > Attributes that are common between all m= sections MAY be moved to > session-level, if desired. > > I presume this is only trying to point out a common feature of SDP. But it > overstates the real situation. This may only be done for media level > attributes (not source level), and only those that are defined to also be > valid at session level as a default for media level. > > It might be better to just not say this. Or refer to 4566 for details. > Since this section mentions which specific attributes must be added to each m= section, this is just pointing out that it is also OK if these are added at session level. But I see that not all attributes are defined as being valid at session level, regardless of whether the values are common. I think it is worth mentioning what JSEP endpoints should do here. Assuming we want to permit this behavior, it sounds like we should simply mention that this can be done only for media-level attributes that are also defined to be valid at session-level. > > Thanks, > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf307f38f8d1355304ea543c23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Nov 1, 2013 at 2:18 PM, Paul Kyzivat <= pkyzivat@alum.mi= t.edu> wrote:
Section 5.2.1 says:

=C2=A0 =C2=A0Each m=3D section, provided it is not being bundled into anoth= er m=3D
=C2=A0 =C2=A0section, MUST generate a unique set of ICE credentials and gat= her its
=C2=A0 =C2=A0own unique set of ICE candidates. =C2=A0Otherwise, it MUST use= the same
=C2=A0 =C2=A0ICE credentials and candidates that were used in the m=3D sect= ion that
=C2=A0 =C2=A0it is being bundled into.

But the use of common ICE candidates for bundled m-lines doesn't work u= ntil it is known that bundling will be used. Seems like a few more words ab= out that are called for.

Sure. When I s= ay "bundled" here, I mean that the actual bundling has occurred, = i.e. the streams will be sent over the same transport (in which case they h= ave to use the same ICE info).=C2=A0

Further on:

=C2=A0 =C2=A0Attributes that are common between all m=3D sections MAY be mo= ved to
=C2=A0 =C2=A0session-level, if desired.

I presume this is only trying to point out a common feature of SDP. But it = overstates the real situation. This may only be done for media level attrib= utes (not source level), and only those that are defined to also be valid a= t session level as a default for media level.

It might be better to just not say this. Or refer to 4566 for details.
<= /blockquote>

Since this section mentions which specific = attributes must be added to each m=3D section, this is just pointing out th= at it is also OK if these are added at session level. But I see that not al= l attributes are defined as being valid at session level, regardless of whe= ther the values are common.

I think it is worth mentioning what JSEP endpoints shou= ld do here. Assuming we want to permit this behavior, it sounds like we sho= uld simply mention that this can be done only for media-level attributes th= at are also defined to be valid at session-level.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--20cf307f38f8d1355304ea543c23-- From juberti@google.com Sun Nov 3 22:55:59 2013 Return-Path: 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 0652B11E8114 for ; Sun, 3 Nov 2013 22:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 YECKdZMW12Mj for ; Sun, 3 Nov 2013 22:55:58 -0800 (PST) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id A8A9521E80B3 for ; Sun, 3 Nov 2013 22:55:56 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id c14so1144266vea.41 for ; Sun, 03 Nov 2013 22:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qjgz5bcCsIA+ry5joUHrXQYBj6ohuLUdxVPs7WP55Mg=; b=eUtAXoLykKknogplPvwQUKhcKZvSPaTyVLbm29Nc0+/iPVUpTqJMGhQPDwLABMi0Vd 8qLsGH9xUo3f5fLoxe22kXJpC5roX5+YO9SStkRkL9gEPcdkrPfFXFFE9BZvuRCTyIWU /GOLDa5pO5BIO+6XQh3TwCxKXuhtCgbNFjcCbWCXTD7ZqH5Tf7IjV+CULJ2OWq8X2ZlR aURDBjsCLuomTGORVxp36xdwkHgZ3A3b9W4YutQyjEbSbJDaQrA4DChU0Mq2L0T60prP lU5kydpZiGYyDvrj9K2p4Wif65kVVy1ZwrLPup6vjf/+d7VXSimAUYIxkrZIogkNYet0 0oqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qjgz5bcCsIA+ry5joUHrXQYBj6ohuLUdxVPs7WP55Mg=; b=VkxJjn4UEWlRlrQLWfqqThu6zwLJWANwg29ExlaBF9LtzdK4f5vchg88NEltao8zB+ fkhX1wyUP0jWbuZ55N+zyKJJaqrZsyaSUQBKk2Vh0o60btWtYoriKEsMzMgCDpyLxP3r yMj/+ZGEXSa9m3jESgIlVuLFMVq3P6Viq2k+LseCboMb0XxT4nf8Adag+rrPnGsOKJDZ CBTNvtBd2+rcHcHTGh8F+deca7tVKtdRh2zBaqWWWNmtjOknDx248quaiK02RZCu1CuH gsA3uSCIGhbK/5tQ9N9SAmm6xN87ZCqvGwJIKhq5M+WWGlJvgjH8D67qFlcI9oJmJvab JLEA== X-Gm-Message-State: ALoCoQlRZQ4zD7oi2QFM1ABktn+rMzIlWkgUz+/REJLe0cyOJ5PN8gVUT0QtR24zKtKvu4S9vUbFlDaGhnUCytn/W0mexMJrck5Weph+1ZeisTtstEbX09m+tXPjM9Xt7AdL4Vo3Tg1tNFUR2LYPVOBpOiV0Sbp+RrnePMAgEVt4HOYAJOQecUJWD8BR8cz6rxAAZeuBiqJi X-Received: by 10.58.29.37 with SMTP id g5mr35990veh.38.1383548155845; Sun, 03 Nov 2013 22:55:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Sun, 3 Nov 2013 22:55:35 -0800 (PST) In-Reply-To: <527420FC.3070805@alum.mit.edu> References: <527420FC.3070805@alum.mit.edu> From: Justin Uberti Date: Sun, 3 Nov 2013 22:55:35 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b6786fe5c0b3204ea546837 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 06:55:59 -0000 --047d7b6786fe5c0b3204ea546837 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat wrote: > Section 5.2.2 (Subsequent Offers) says: > > o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST > only include codecs present in the remote description. > > o The RTP header extensions MUST only include those that are present > in the remote description. > > o The RTCP feedback extensions MUST only include those that are > present in the remote description. > > o The "a=rtcp-mux" line MUST only be added if present in the remote > description. > > o The "a=rtcp-rsize" line MUST only be added if present in the > remote description. > > Including only codecs that were present in the prior answer is a bad idea. > It doesn't play well with SIP. There is no harm in continuing to include > all the codecs you support. And it keeps options open for changing codecs > later. > > The same is true for most other things that are being restricted based on > what was in the last answer. (But I won't say that with certainty without > checking the semantics of each one.) > > For further info, see RFC 6337, especially section 5.1. > According to section 5.2.5, it seems that this is only the cases for offers triggered by offerless reINVITEs. I don't think we want to be re-allocating and negotiating codecs every time we want to make a change to the session descriptions in use. Generally I think we should consider that the capabilities of the remote side will not change unexpectedly during the call, and so full renegotiation is not needed with each reINVITE. If full renegotiation is needed, use an INVITE-with-replaces, as Cullen has suggested. This avoids complicated cases like having to unBUNDLE in mid-call, or re-reserve codecs that are unlikely to be used. > > Thanks, > Paul > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b6786fe5c0b3204ea546837 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat <= pkyzivat@alum.mi= t.edu> wrote:
Section 5.2.2 (Subsequent Offers) says:

=C2=A0 =C2=A0o =C2=A0The m=3D line and corresponding "a=3Drtpmap"= and "a=3Dfmtp" lines MUST
=C2=A0 =C2=A0 =C2=A0 only include codecs present in the remote description.=

=C2=A0 =C2=A0o =C2=A0The RTP header extensions MUST only include those that= are present
=C2=A0 =C2=A0 =C2=A0 in the remote description.

=C2=A0 =C2=A0o =C2=A0The RTCP feedback extensions MUST only include those t= hat are
=C2=A0 =C2=A0 =C2=A0 present in the remote description.

=C2=A0 =C2=A0o =C2=A0The "a=3Drtcp-mux" line MUST only be added i= f present in the remote
=C2=A0 =C2=A0 =C2=A0 description.

=C2=A0 =C2=A0o =C2=A0The "a=3Drtcp-rsize" line MUST only be added= if present in the
=C2=A0 =C2=A0 =C2=A0 remote description.

Including only codecs that were present in the prior answer is a bad idea. = It doesn't play well with SIP. There is no harm in continuing to includ= e all the codecs you support. And it keeps options open for changing codecs= later.

The same is true for most other things that are being restricted based on w= hat was in the last answer. (But I won't say that with certainty withou= t checking the semantics of each one.)

For further info, see RFC 6337, especially section 5.1.

According to section 5.2.5, it seems that this is only the= cases for offers triggered by offerless reINVITEs. I don't think we wa= nt to be re-allocating and negotiating codecs every time we want to make a = change to the session descriptions in use.=C2=A0

Generally I think we should consider that the capabilit= ies of the remote side will not change unexpectedly during the call, and so= full renegotiation is not needed with each reINVITE. If full renegotiation= is needed, use an INVITE-with-replaces, as Cullen has suggested. This avoi= ds complicated cases like having to unBUNDLE in mid-call, or re-reserve cod= ecs that are unlikely to be used.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b6786fe5c0b3204ea546837-- From juberti@google.com Sun Nov 3 23:09:33 2013 Return-Path: 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 D00FA21E80A7 for ; Sun, 3 Nov 2013 23:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 Euzc9PZjbKXV for ; Sun, 3 Nov 2013 23:09:32 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2306E21E8141 for ; Sun, 3 Nov 2013 23:09:31 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id jz11so1198733veb.12 for ; Sun, 03 Nov 2013 23:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Taj12usrNAbwAb2aaWdQgBfmodOsINJNMjO7Q/rcx0E=; b=UkXjp3o+9NLFeTGinoEu39Q2TLoLnhUIf538DhWVqdg7iESAZAkCg7e0N3c5I01g5r 1+HZ9/nJDpksT+SEcpF9KsOxPwlhnjxESLUZjmAsHcvibXVbNKe3Hc3v4Z3BUIua92JI qKHM8wL9veNExC5CJVn6OyW1wLX/E6HneUmuC1FN9pjtPFBPCc4DjVBzIPbMgQxBjCPv UilohsDR9WQPGQ8ZpqIlJ5w/ZdV9u7QkY9Z5B0aRJAY9zhnxW0904kwUQ6RR9tKbmZ6A uRxLSD2nHEM4wufxQnvaWGeCLlSpwQE3wTdkpu2ZVVQododpSk0hBWVkpRS7CaEgB185 0yXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Taj12usrNAbwAb2aaWdQgBfmodOsINJNMjO7Q/rcx0E=; b=My6Ufl9v+Nk10lzLnc1zpwVd35PlcQ6dvLTa+7OTJwx+q8mU4WDu6ZOSS3YOjzcdUL +YSZZdQCIH0k0m3EBYTUmQK56fO5NjZbHEyyfG99vqQ0QF1kzEAWL4r0QGbdXlPMAkp2 Ycr7GlA9JuRt8vXu5704qQJAPCYgnAeb+4V6smwTNs/xzIYCk/IBVs/6+Zf0MrO7Ln3C 3MS9VTca5HyvHJDKGOixInj5oWUj8Li9lJIItKMYiTjI6Q19PqqkdG/p3KSOiSU4z3Co VCKbRo1lqlvx95fTWCbEpmjTYD6XEROzqs90MccYpBkSZ4TzcTB2j7bBJWAuVVIhJGHY Luzg== X-Gm-Message-State: ALoCoQkVcTsQ5PdhOUE973J/I+Ad6UF6PMdADV0Gak0+vzQKoOLsGaBLLXmlH310gB77REAMjpESR9HPPQWsaPAmytaMUZyJ9X0Rd9TLD2MxZgcZ6Z+1Ji4bEn5kLo7m0Scdn0vbgxWe4F1o+TCKwF8NMrrZA8aBFX0XZhyE7YiHJrtHSbQHgA4/ENtFbxPcNvG2ZNh2Ktzo X-Received: by 10.221.39.195 with SMTP id tn3mr10235519vcb.2.1383548970376; Sun, 03 Nov 2013 23:09:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Sun, 3 Nov 2013 23:09:10 -0800 (PST) In-Reply-To: <527420FF.2@alum.mit.edu> References: <527420FF.2@alum.mit.edu> From: Justin Uberti Date: Sun, 3 Nov 2013 23:09:10 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a113375c2e8b9cb04ea5498ff Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Recycling m-lines X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 07:09:33 -0000 --001a113375c2e8b9cb04ea5498ff Content-Type: text/plain; charset=UTF-8 On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat wrote: > Section 5.2.2 (Subsequent Offers) says: > > o If a m= section was rejected, i.e. has had its port set to zero in > either the local or remote description, it MUST remain rejected > and have a zero port in the new offer, as indicated in RFC3264, > Section 5.1. > > That 3264 reference is to a section about the initial offer, and so is > irrelevant to the case. The relevant section is: > > 8.1 Adding a Media Stream > > New media streams are created by new additional media descriptions > below the existing ones, or by reusing the "slot" used by an old > media stream which had been disabled by setting its port to zero. > > IOW, previously rejected m-lines may be recycled. > Right you are. > > Later in 5.2.2: > > o If a m= section exists in the current local description, but has > its state set to inactive or recvonly, and a new MediaStreamTrack > is added, the previously existing m= section MUST be recycled > instead of creating a new m= section. [OPEN ISSUE: Nail down > exactly what this means. Should the codecs remain the same? > (No.) Should ICE restart? (No.) Can the "a=mid" attribute be > changed? (Yes?)] > > This seems to assume that there is no existing MediaStreamTrack for these > m-lines. > > Yes. The text should state that more clearly. > If there is, then > - the m-line shouldn't be recycled. > If there isn't, then > - where do its address and port come from? > - what is managing the RTCP? > The m= section will still have completed ICE negotiation, despite being marked as inactive. So the address/port information should already be present. I don't follow your question about who is managing RTCP. > > Thanks, > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113375c2e8b9cb04ea5498ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat <= pkyzivat@alum.mi= t.edu> wrote:
Section 5.2.2 (Subsequent Offers) says:

=C2=A0 =C2=A0o =C2=A0If a m=3D section was rejected, i.e. has had its port = set to zero in
=C2=A0 =C2=A0 =C2=A0 either the local or remote description, it MUST remain= rejected
=C2=A0 =C2=A0 =C2=A0 and have a zero port in the new offer, as indicated in= RFC3264,
=C2=A0 =C2=A0 =C2=A0 Section 5.1.

That 3264 reference is to a section about the initial offer, and so is irre= levant to the case. The relevant section is:

=C2=A0 =C2=A08.1 Adding a Media Stream

=C2=A0 =C2=A0New media streams are created by new additional media descript= ions
=C2=A0 =C2=A0below the existing ones, or by reusing the "slot" us= ed by an old
=C2=A0 =C2=A0media stream which had been disabled by setting its port to ze= ro.

IOW, previously rejected m-lines may be recycled.

=
Right you are.=C2=A0

Later in 5.2.2:

=C2=A0 =C2=A0o =C2=A0If a m=3D section exists in the current local descript= ion, but has
=C2=A0 =C2=A0 =C2=A0 its state set to inactive or recvonly, and a new Media= StreamTrack
=C2=A0 =C2=A0 =C2=A0 is added, the previously existing m=3D section MUST be= recycled
=C2=A0 =C2=A0 =C2=A0 instead of creating a new m=3D section. =C2=A0[OPEN IS= SUE: Nail down
=C2=A0 =C2=A0 =C2=A0 exactly what this means. =C2=A0Should the codecs remai= n the same?
=C2=A0 =C2=A0 =C2=A0 (No.) =C2=A0Should ICE restart? =C2=A0(No.) =C2=A0Can = the "a=3Dmid" attribute be
=C2=A0 =C2=A0 =C2=A0 changed? =C2=A0(Yes?)]

This seems to assume that there is no existing MediaStreamTrack for these m= -lines.

Yes. The text should state that more clearly.
=C2=A0
If there is, then
- the m-line shouldn't be recycled.
If there isn't, then
- where do its address and port come from?
- what is managing the RTCP?

The m=3D s= ection will still have completed ICE negotiation, despite being marked as i= nactive. So the address/port information should already be present.

I don't follow your question about who is managing = RTCP.=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--001a113375c2e8b9cb04ea5498ff-- From juberti@google.com Sun Nov 3 23:36:23 2013 Return-Path: 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 8525921E812A for ; Sun, 3 Nov 2013 23:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.507 X-Spam-Level: X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=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 a20Ds4iMh4dm for ; Sun, 3 Nov 2013 23:36:22 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6D59921E815C for ; Sun, 3 Nov 2013 23:36:18 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id ib11so4301467vcb.22 for ; Sun, 03 Nov 2013 23:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xYMKi1EJ1HLNNdMH/xlc+WvC5TbYQ2V7Fu30lxWAMq8=; b=N7Dw3CosbR5xScQjepTvbggJ2YZCx1kAbopEHsnO3S7XBbYuBrC5N8Padz+adQ0wPD kdHdeZyCeIwrb4AUBlwoh57o4qmHicwTOKUXDS5w8uMPYOyzXDEG0r+Xx0ncmhh/Rbt4 DpOMiPEAoxgR+TScfWvZgcSjiedPJ57WzSDzz8ze0y1dYq0IWok2d4sSHXXjKqILynJK VSpn4rSjoY7NtsLchVft4w7uZcmrVb88VcxyiYwqiRK4OJPgL6mZ32plIgaj6NqHLj0i rygGUrI6L/8Z30Rv2qOoQ6CUaEaXd0AdmKYztNqhyOTZW1h+SGjNMgx7YOz+OGHIChrD Hafg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xYMKi1EJ1HLNNdMH/xlc+WvC5TbYQ2V7Fu30lxWAMq8=; b=c1G4n0LP7fYXr1xgAcTauPSBS2pVkmP1OWpvgjUzl/jp5sd/5JuoXek8BO/Yphjgpj n+c1zt6+HSnOAGroUMAqEYJhzmybWPcBL64Nw2TNCY+TTiSBHfDcicvKrruCV/+U6ZIN iPO3qzdPwl7JRPTFEkKMn6KjnA5MSBAFjxXuRUUzVbiYGStbuR0Y4n/XaTGPoQ+LyQWH iVqBqL/I70s44uNyElp+uYjNyyTHrebyqnPagYZDof9HxhNXxMn6v/nkEhkzQgQ5wCUE /M+FKtxwIzbxWB1hE3aZsP4MLpyYidHojEjruR9daCpbvPADBUru8muGyP3/ibMoOdF8 7j1A== X-Gm-Message-State: ALoCoQnwnXABAsG6Icgc5xxTqdei0bsq5Mg+8i5nYyJW9IyKEjatqt1WbUeHKplqM2OFtSUa6f2RNnAWpH9wlbQsTLl0J/N9CQXOgbmiG4qEyvuMXgmFt96F2qbmSumIHyJWmkDBrMDBdpRrrUNT+wkVWPFi708/Ef5gDXDUZRFSUFXVOg/x0QU4hqGNS31ocPzHALfT4SNt X-Received: by 10.58.46.18 with SMTP id r18mr10663711vem.4.1383550576364; Sun, 03 Nov 2013 23:36:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Sun, 3 Nov 2013 23:35:56 -0800 (PST) In-Reply-To: <527494D0.2060107@alvestrand.no> References: <526FCEC1.7000904@alum.mit.edu> <52700422.4020002@alum.mit.edu> <527414A5.9090904@alum.mit.edu> <52743004.50801@alum.mit.edu> <527494D0.2060107@alvestrand.no> From: Justin Uberti Date: Sun, 3 Nov 2013 23:35:56 -0800 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e01294482a222fc04ea54f817 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 07:36:24 -0000 --089e01294482a222fc04ea54f817 Content-Type: text/plain; charset=UTF-8 Harald's understanding is correct. Concerning the original question about Section 5.3.1, the text tried to indicate that the processing described should be performed for each "send" MediaStreamTrack. The local endpoint has no control over how the remote endpoint associates MSTs with m= lines. However, the mapping of "enabled" to the directional attribute is something we need to discuss, and if sensible, write into the draft. On Fri, Nov 1, 2013 at 10:59 PM, Harald Alvestrand wrote: > On 11/01/2013 11:49 PM, Paul Kyzivat wrote: > > On 11/1/13 2:10 PM, Martin Thomson wrote: > >> On 1 November 2013 13:52, Paul Kyzivat wrote: > >>> > >>> "MediaStreamTrack.readonly Read only > >>> Is a boolean value with a value of true if the track is > >>> readonly (such a > >>> video file source or a camera that settings can't be modified), false > >>> otherwise." > >>> > >>> That seems to imply that one that isn't read-only must be read-write. I > >>> don't see any mention of write-only. > >> > >> > >> This attribute only really pertains to the constraints API, which is > >> used to do things like switch cameras between capture modes. This is > >> to do things like change resolutions or capture rates on physical > >> devices. The assumption here is that this interface is not > >> appropriate for tracks that originate from the network and so this is > >> a clear signal to an application that trying to apply constraints is > >> going to fail. > > > > OK, so that doesn't mean what I thought it did. (Sorry, but I haven't > > been following the WebRTC API side of this.) > > > > Looking at: > > > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html#mediastreamtrack > > > > I don't find any notion of readonly or writeonly tracks. If you are > > going to use the presence of readoly and writeonly tracks to determine > > the directionality of the m-line, what property of the track > > determines that? > > A MediaStreamTrack is unidirectional. Think of it as an SSRC; it helps > (even though simulcast and repair flows make the picture more complex). > > The basic decision of UnifiedPlan was to map a maximum of 2 > MediaStreamTracks (one in each direction) to each m-line. > > So the directionality of an m-line is dictated by whether there are > tracks mapped to it in each direction, and whether they are active (if > we decide to map "active"; this isn't clearly decided yet, I think). > > Table: > > Tracks that are mapped > to this M-line Resulting m-line state at A > > None a=inactive > A->B, disabled a=inactive > A->B, enabled a=sendonly > A->B enabled, B->A disabled a=sendonly > A->B enabled, B->A enabled a=sendrecv > > I think you can complete the rest of the table in your head. > > The defense for this somewhat arcane mechanism is that it creates SDP > that interoperates with endpoints that expect one outgoing and one > incoming video track, both described by the same M-line. > > > > > > >> I know that this oversimplifies the process and that constraints could > >> be used to provide indications back to RTCPeerConnection about what > >> constraints to apply to its negotiation functions, but I think that > >> the conclusion was that this was overcomplicating things. And we know > >> very well that it is already complicated beyond the comprehension of > >> mere mortals anyway. > > > > Its currently beyond my comprehension. Take that for what its worth. > > > > Thanks, > > Paul > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e01294482a222fc04ea54f817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Harald's understanding is correct.

= Concerning the original question about Section 5.3.1, the text tried to ind= icate that the processing described should be performed for each "send= " MediaStreamTrack. The local endpoint has no control over how the rem= ote endpoint associates MSTs with m=3D lines. However, the mapping of "= ;enabled" to the directional attribute is something we need to discuss= , and if sensible, write into the draft.


On Fri,= Nov 1, 2013 at 10:59 PM, Harald Alvestrand <harald@alvestrand.no= > wrote:
On 1= 1/01/2013 11:49 PM, Paul Kyzivat wrote:
> On 11/1/13 2:10 PM, Martin Thomson wrote:
>> On 1 November 2013 13:52, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>>
>>> "MediaStreamTrack.readonly Read only
>>> =C2=A0 =C2=A0 =C2=A0Is a boolean value with a value of true if= the track is
>>> readonly (such a
>>> video file source or a camera that settings can't be modif= ied), false
>>> otherwise."
>>>
>>> That seems to imply that one that isn't read-only must be = read-write. I
>>> don't see any mention of write-only.
>>
>>
>> This attribute only really pertains to the constraints API, which = is
>> used to do things like switch cameras between capture modes. =C2= =A0This is
>> to do things like change resolutions or capture rates on physical<= br> >> devices. =C2=A0The assumption here is that this interface is not >> appropriate for tracks that originate from the network and so this= is
>> a clear signal to an application that trying to apply constraints = is
>> going to fail.
>
> OK, so that doesn't mean what I thought it did. (Sorry, but I have= n't
> been following the WebRTC API side of this.)
>
> Looking at:
>
> http://dev.w3.org/2011/webrtc/editor/getuse= rmedia.html#mediastreamtrack
>
> I don't find any notion of readonly or writeonly tracks. If you ar= e
> going to use the presence of readoly and writeonly tracks to determine=
> the directionality of the m-line, what property of the track
> determines that?

A MediaStreamTrack is unidirectional. Think of it as an SSRC; i= t helps
(even though simulcast and repair flows make the picture more complex).

The basic decision of UnifiedPlan was to map a maximum of 2
MediaStreamTracks (one in each direction) to each m-line.

So the directionality of an m-line is dictated by whether there are
tracks mapped to it in each direction, and whether they are active (if
we decide to map "active"; this isn't clearly decided yet, I = think).

Table:

Tracks that are mapped
to this M-line =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Resulting m-line state at A

None =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Din= active
A->B, disabled =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 a=3Dinactive
A->B, enabled =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 a=3Dsendonly
A->B enabled, B->A disabled =C2=A0a=3Dsendonly
A->B enabled, B->A enabled =C2=A0a=3Dsendrecv

I think you can complete the rest of the table in your head.

The defense for this somewhat arcane mechanism is that it creates SDP
that interoperates with endpoints that expect one outgoing and one
incoming video track, both described by the same M-line.



>
>> I know that this oversimplifies the process and that constraints c= ould
>> be used to provide indications back to RTCPeerConnection about wha= t
>> constraints to apply to its negotiation functions, but I think tha= t
>> the conclusion was that this was overcomplicating things. =C2=A0An= d we know
>> very well that it is already complicated beyond the comprehension = of
>> mere mortals anyway.
>
> Its currently beyond my comprehension. Take that for what its worth. >
> =C2=A0 =C2=A0 Thanks,
> =C2=A0 =C2=A0 Paul
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--
Surveillance is pervasive. Go Dark.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e01294482a222fc04ea54f817-- From singer@apple.com Mon Nov 4 05:51:45 2013 Return-Path: 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 0019611E81A7 for ; Mon, 4 Nov 2013 05:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 59ZFVLAbywh3 for ; Mon, 4 Nov 2013 05:51:38 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) by ietfa.amsl.com (Postfix) with ESMTP id F090511E8108 for ; Mon, 4 Nov 2013 05:51:37 -0800 (PST) Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 25.86.03695.466A7725; Mon, 4 Nov 2013 21:51:32 +0800 (MYT) X-AuditID: 1152fe06-b7f5a6d000000e6f-15-5277a66437ba Received: from galingale.asia.apple.com ( [17.82.200.117]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id ED.26.14371.466A7725; Mon, 4 Nov 2013 21:51:32 +0800 (MYT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.83.34.50] (unknown [17.83.34.50]) by mail.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVQ00LWHRTPNH00@mail.asia.apple.com> for rtcweb@ietf.org; Mon, 04 Nov 2013 21:51:32 +0800 (SGT) From: David Singer In-reply-to: <5275395B.5060709@bbs.darktech.org> Date: Mon, 04 Nov 2013 22:51:26 +0900 Message-id: <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> To: Gili X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUiGHRCSDdlWXmQQdstJYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8WbHcvaCdcwVL1a+ZWlgvMHUxcjJISFgIvF0RhcjhC0mceHe erYuRi4OIYHdjBIvL36CK/q17ytUYgKTxK+fe8ESvAKCEj8m32PpYuTgYBaQlzh4XhYkzCyg JfH9USsLRP18JomZ81+xg9QICxhK/NsUClLDJqAq8WDOMbDFnAIGEjdurwUbyQIUv/J9NwvE HGGJ74/vsUCsspE4sq0T6oaDLBL/JsxhBUmICChJPLm+jhniUFmJ0+eegy2WEPjKKjHxxlOm CYzCs5DcOgvh1llIbl3AyLyKUTw3MTNHNzPPSC+xODNRL7GgICdVLzk/dxMjOKD/se1gXPDa 8BCjAAejEg/v7LdFQUKsiWXFlbmHGCU4mJVEeFcUlQcJ8aYkVlalFuXHF5XmpBYfYpTmYFES 5412jAkSEkhPLEnNTk0tSC2CyTJxcEo1MGaxG8YXX/hhvHTC95v93DV7hTy2HY02fsOxRHpO j15F2QpGRoEFl1jeSS/aUPZ0+41vdssXdDOmTb72Mnm/DIvW1YSOmKfpts3tCWL3OsVcg49J /2SutKswbT6y4v474043I7ltEqZThd+rs52WcZbunpfA8bNtfmXzSl6FqbukrjcddP2rrcRS nJFoqMVcVJwIAOXQAKBkAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUiGHSiVDdlWXmQwcU9PBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr482O5ewF65grXqx8y9LAeIOpi5GTQ0LAROLXvq9sELaYxIV7 64FsLg4hgQlMEr9+7gUr4hUQlPgx+R5LFyMHB7OAvMTB87IgYWYBLYnvj1pZIOrnM0nMnP+K HaRGWMBQ4t+mUJAaNgFViQdzjjGC2JwCBhI3bq8FG8kCFL/yfTcLxBxhie+P77FArLKROLKt E+qGgywS/ybMYQVJiAgoSTy5vo4Z4lBZidPnnrNMYBSYheS8WQjnzUJy3gJG5lWMokWpOYmV hnqJxZmJeokFBTmpesn5uZsYIQEotIPx436DQ4wCHIxKPLzXHxQFCbEmlhVX5h5ilOBgVhLh XVFUHiTEm5JYWZValB9fVJqTWnyIUZqDRUmcV/mEQ5CQQHpiSWp2ampBahFMlomDU6qBcbVJ cO0+x9Ml4r8vLeMzEP5cd73qZOBd95zft+ab825N2XPvxST/tdti9/F+e3Wo2OFOQMaM9nX/ HeLXPn6YrOwbvEmAP+ynmjfb4cSu+S4uyyzqG+cc6BJ8yTR/gYLznYCZS2w6tQTXJbzNkRRW iBLrWXKdUdR//w35exo1lw883/bgjX/XaiWW4oxEQy3mouJEAPlyyDA8AgAA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 13:51:45 -0000 On Nov 3, 2013, at 2:41 , Gili wrote: > > So... the only platform that supports H.264 natively (real-time encoding/decoding) is Windows 8? Any others? The fact that there currently isn't an API is different from whether the platform can do it (in the iOS case). reverse engineering suggests that FaceTime uses AVC (H.264). David Singer Multimedia and Software Standards, Apple Inc. From stewe@stewe.org Mon Nov 4 05:52:20 2013 Return-Path: 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 D512711E81C5 for ; Mon, 4 Nov 2013 05:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DEAR_SOMETHING=1.605, RCVD_IN_DNSWL_LOW=-1] 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 8Is438uu+4-N for ; Mon, 4 Nov 2013 05:52:16 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id CAEAC11E8108 for ; Mon, 4 Nov 2013 05:52:14 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB362.namprd07.prod.outlook.com (10.141.75.21) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 4 Nov 2013 13:52:11 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.55]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.167]) with mapi id 15.00.0785.001; Mon, 4 Nov 2013 13:52:11 +0000 From: Stephan Wenger To: "rtcweb@ietf.org" Thread-Topic: Liaison Statement to IETF (SC 29 N 13820) Thread-Index: AQHO2TqiDUqWpOHNy0aSyi+svLQLvJoUkX8A Date: Mon, 4 Nov 2013 13:52:09 +0000 Message-ID: In-Reply-To: <20131104174700.EE08.544A59DA@itscj.ipsj.or.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [24.5.171.95] x-forefront-prvs: 0020414413 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(377424004)(243025003)(51704005)(24454002)(81686001)(56776001)(54316002)(87266001)(79102001)(81816001)(83072001)(15975445006)(76482001)(15202345003)(59766001)(77982001)(80976001)(50986001)(49866001)(47736001)(19580395003)(66066001)(47976001)(83322001)(19580405001)(36756003)(76786001)(76176001)(56816003)(77096001)(76796001)(31966008)(46102001)(80022001)(81542001)(74662001)(65816001)(74502001)(47446002)(69226001)(63696002)(81342001)(54356001)(4396001)(85306002)(53806001)(51856001)(74876001)(74706001)(74366001)(2656002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB362; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:24.5.171.95; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: multipart/mixed; boundary="_002_CE9CD627A93D0stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: Jari Arkko Subject: [rtcweb] FW: Liaison Statement to IETF (SC 29 N 13820) X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 13:52:20 -0000 --_002_CE9CD627A93D0stewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-ID: <41FF9DEB28B7B148905D8673B6F1F5E7@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi rtcweb and Jari, Jari, please distribute further as you deem necessary, with or without my notes below. The attached liaison statement, received from MPEG tonight, is addressed to the =B3IETF=B2 (which is why Jari is copied specifically), but I believe it=B9s mostly if not exclusively rtcweb that is interested. Note that MPEG=B9s closing plenary was past Friday; this almost sets a record for turn-around time. The liaison statement is short and concise, so I do not attempt to summarize it.=20 To put things into perspective (with the caveat that I do not attend most technical meetings in MPEG, as I=B9m busy with JCT-VC), allow me to fill in some context IVC is a cleaned-up version of the MPEG-1 video compression technology, riding the expiration of many of the second generation video coding patents (MPEG-1 part 2 was ratified in 1993). WebVC has many similarities with the Chinese AVS, and both are essentially stripped down versions of H.264 (baseline) with bug fixes and minor enhancements of known H.264 shortcomings. VCB is VP8 with an MPEG-style specification and, AFAIK and so far, compatible with what=B9s out as VP8 in the wild. WebVC is fairly well along the approval process. Despite the =B3good results=B2 reported, few folks I talk to expect IVC to go anywhere anytime soon. Some were expecting that VCB would enter ISO=B9s approval process at this meeting (issue of a Committee Draft, CD), but that also didn=B9t happe= n. Many on this list are probably more familiar with the IETF=B9s and W3C=B9s patent policies than with MPEG=B9s, and the additional constraints used in video coding in MPEG. So here is a quick primer. The common ITU/ISO/IEC patent policy and its associated guidelines require formal, binding IPR declarations with authorized signature once the spec is stable and its clear that the patented technology is included, which implies to most that declarations are expected only towards the end of the approval process. However, contributors in all three aforementioned projects (though not in most other MPEG subgroups) are expected make non-binding written statements in their contributions, similar to what happened in JVT. There is also an oral call for IPR at the begin of any MPEG meeting, but that is boilerplate and the reply is almost always silence. All three technologies are developed in a relatively small sub-group (a few dozen people at most) while the majority of video coding experts (the record was around 350, IIRC) sit in the group known as JCT-VC and work on H.265. It is entirely possibly that =B3RAND" or even =B3unavailable=B2 IPR declarations will be received for all three standards under development towards the end of the process, without an early warning by non-binding written or oral statements in the subgroup. Those declarations would AFAIK still be timely, because a) the patent policy guidelines discourage written IPR declarations to the ISO secretariat before the spec is stable (something many people associate with the DIS state), b) many companies interested in video coding do not follow those three projects in detail, perhaps because they focus on H.265, and c) once the projects are in the final stages of the approval process, companies may wake up because, arguably, only then the declaration requirements come into play. Note also that, unlike W3C, ISO does not have a formal process to deal with situations where an unfavorable IPR declaration has been received. The policy only sets the requirement that the approved standard does not include provisions dependent on the unavailable patent. The common ITU/ISO/IEC patent policy can be found here: http://www.itu.int/en/ITU-T/ipr/Pages/policy.aspx The guidelines are here: http://www.itu.int/dms_pub/itu-t/oth/04/04/T04040000010003PDFE.pdf (I=B9m using the ITU web site as I know where to find things; I=B9m sure yo= u can find identical docs on the ISO site somewhere.) Regards, Stephan =20 On 11.4.2013, 00:48 , "WATANABE Shinji" wrote: >Dear Sir or Madam, > >In accordance with Resolutions taken >at the 106th SC 29/WG 11 meeting, >2013-10-28/11-01, Geneva, Switzerland, >I am pleased to send attached Liaison statement. > >If you have any questions, please do not hesitate to contact me. >Thank you for your cooperation. > > >Best Regards, >Shinji Watanabe > >----- >WATANABE Shinji (Mr.) >Secretary, ISO/IEC JTC 1/SC 29 >IPSJ/ITSCJ >308-3 Kikai-Shinko-Kaikan Bldg. >3-5-8 Shiba-koen, Minato-ku, Tokyo 105-0011 Japan >Tel: +81-3-3431-2808 Fax: +81-3-3431-6493 >Mail: watanabe@itscj.ipsj.or.jp --_002_CE9CD627A93D0stewesteweorg_ Content-Type: application/x-zip-compressed; name="29n13820.zip" Content-Description: 29n13820.zip Content-Disposition: attachment; filename="29n13820.zip"; size=15147; creation-date="Mon, 04 Nov 2013 13:52:08 GMT"; modification-date="Mon, 04 Nov 2013 13:52:08 GMT" Content-ID: <7659AB7222575641A97976CB35AC5AA6@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 UEsDBBQAAgAIAE2hYUNI4h/MeTUAAADKAAANAAAAMjluMTM4MjAxLmRvY+xbCVwUR9avGUYYhAmH SPAuIyoq1wgKQVRg5IwCAhKNZ89Mw7QO02N3D0eiiwbNeiSKml1N1p/RRKJxo6IJxnhsNGyixNto 0Hhfia4kXokEE+F71XPQIETz/bL7Zb8fhf+pruqq9169969XM/bM0SNeF9ds6XwJNSvDkBOqb3BF zpI+GWCKveGJkNbWV9/Q0EC6JgMa2sp/Vakp24vGX3RVIHTb+xNHZKEoEbrnjdBTSDtVO1U9Xj0e PVJcFb5oYFeEMtVdJxBca2/tV6GWS0ODx2Ov7eUj8XWrTSKp+/tZr3+t9mmizcrKYbb70joS6nzb +AW22n5/ezRCNXKEVtnaj6vvdmq5jgA5IAY9G21tP0ntD/Xa4Qhtg4kvxCF0ENoTob9jC97s30x/ 89KaXfZ6YnTL8vo3W5+9kHYWbHcO5vlC27uLtb95TeR/0YKc5u2IZvrt839rkfq7JXmkzgC7w55F 6Af0+5VbQ5qux8630O7rFIOrD8ua83BXZ4Rgs6C+UQh1l8jpFW3l3zyoQ238IyUexm0AKX001vYp mA9dYjtaov/3KnY9zflA9IS3wB9pvH+Nh0/KSzsfm/OytfKkfGlNn93Pj9snzePYvH7c/X9XbY/X 4+z/rfH5rX4kuXmYO5wfkBSigK/tkLeMnA1eCtRW/vAlOTUrPiM1Nis5LTV2JE7LSIxNTc4Umzgh LQNnZsWmjojNGGHrUzUZ0GRuPB4Rj1PTMkbFjrQPTs5MC0mO1+CULI06JFMz8NmQ5xPVapUmbURy aiJOS8Cj0rLJVXqyJmtMRnwmBl04dsyI5DRVK3NxqjpcHTpYlcrm03lamsMDQ9VhgTiRNtH5VCDO LGCEF2nOSJn0qkzWwunoKKxhTfm0ieVUWYxghPZIhmJ41oThXzajp1kYoGdMuTiH5XAcxxbwNMer stgonByflYAzsjTP01rcqj0Bo9LjE/vhAtZi1GMjM43GAosZEwjLswqgtKxFwGAL5mgdbRKwmWNz OZrniQHJJoHmTLTQ1JIsWmcwsUY2l6H5QAxrAYHYTHECo7MYKQ7ThWYjy1ECyxWBYm7ary4Fayme 1otD0iOxtggnsmyukQ5WEcMxw/MWuEthDWU0ivPSOdbM8pSRxwGanPR+T2YlMTDFYiwi4VAHYoiC AQsGGrPaqbROYPLhKgfr6XzayJrJXArzAqyL4vS4wEBzNKxOIL5hC0zEZIr0cDQsGWwDf+ZyFNyk cA5H00FsTpDOQHG5NLgbHMrTOCCryExjtaMNxkC0iMeACDq6HxFBmbDFBG4XOEYngFSTRaQPmEWZ zTARFIgRoYhHjfoCWGkgNrGmID3D6zgmjzFZ/Q3eZPhgjLMMDI/BQRBV3mIkEkGrUMA6gsMQYWTt jCCGsWUnBiRna/qJISYsa3oLeuAm6BIjxVu0PD3dAl4CN2tpHZVHY6qAeIqsQa9niEbKiAVpWAQD JWCdyE0IKs9oYS6lMzAQCTE+uSwJNAggDViNlW0c7aBFHtiSw8BlPsSFLKlxLFlwrJljjOIeDFZl kXibQAFYmgcCyGgYAv4xsyQqEAQy0yG8BcYVUDxhKSx5hEWcQEniJAYCOGHSkZVpaaGApk2iSIlC Yr5Vy3QLw9F5tBhWyfpEXxI9JhYYpTWKavIo2LdAL4uRmA+x43MgdCTcOjYPaCTmC7tGRnBoic3W wLXOwHLB4ApCVxKdQPAaR/wLnDNQxhy7ftFMgVBFCzKAiTSVxwNfdDStp60CeYExwxa3jwEaEeow JFnRWAcbmWzgwaG9g/EoUAE5kBNpBzOTmFwD8WQOY5TaxWMLb+MmDAJp4A4iFRZmEjjWKLpCsAAx IUXk5MDWNRABAmG33UtkpqibBKvpQsSU0rgYCFyyCfNmRhBZSZIe7BstY2SEIuJnPUcVYJ2Rpjid hfDSpDNaSNh4W1wgKXCCyDswAHJDC3sJQgK8IapbTXgB2Zq4fk3TniQ9AVNjgXiCAXKJZIOKOYc1 5bJieoL4kjYslOQvO3XtRwBkcB0kcNFZOgMIh2XoQUQeJALGDO6DlMKx+bAZYUG5tCQFa8F2VgA3 iXsb2MFDluJ5W/ThkLWNsE60K7CRmRdZIHLLNgp2HwkJi3MYsvUdakEsZU/blC0vZNoSrhijX09F j3MtcY30DJJ4UUw4BgrSC2FOEeigiTLbAnMYjhcanZAlblQdzZgFQpfk9Aw4I3Rwwok2gz8pkG3k 4TyFTaizERF4y5hI/mg8R3MwDUnNwRDb0WYfyYs7nDUxgo2++eLyyM4m0wm3zDRHDmxyWDwqTeR0 4+nbWiYnsbSe8MAzyFOsyORcltXbjgjeepKLZyVlPRRhXRx5IwOTglXPE77lAl0EBw+NtrcqsAA4 2CzWpCJY7dOy+iLwEGMSACDbuq+wGY43i/VQEA9geOGW8tIQ2XIBBJEio+zecARbZLp9iXqWqAjG qgS4U2Td0KKrSIQCxR1uMYMryeQ8mgaH54pbKUo8DtShEfBGQIyG7WYgVocFqSNwCmWyUJy4IcOJ RZnA1xSWB8rDscCABhMDb+fGZMba5EQ+IidMjUdBHjHgIBzeeA6JwrIpIw2nBHk/aAbr4c2bk0ql sL+qVG1v+qVFiVAIYALgr4AVgE2AzYByQAVgG+AU4DTgX4COrgj5AnoA+gD6AnrBp8BKwL0rZ6sP 7l7/eklhtcAI1LgEoeWP896+hq6WISgvCSlMAD7JVYl6dzT8PNQdWe8MUs42KB332QAZGSIkeSk8 7KPIK4zyaDaro+NKKtzZ2osevUtkYkdveopTU6WeMMBbgfo49MX1d5YOMhvIp3HHuH4OSc3GgbCm Q7s+YolDH3x0bmkVngpXR6/KcaVJ6Yp6dDTETpmHmvQ1znNX+EnvS290kMafByy3cWCbJN6+thgH AOoAyfBp/95TCJ3wRGi+F9zzRmgsYDXgKuCBNNA/PlnjhrRxVdr4Wtr4QtrYL23slDYq/kON91tt gJva90FuCe6ow9r9yGftavIfI43X4EEnfyePOavbec2Z8mAS1FOgpvydkMwPIQ8npPq8HZKtbjfL PqQDzLIPa08my1WfK5G8j++enmgP5S9HCrGTXLmRK5kowK0j8tZ7Ausof5l1hEy8crJf+ZA9exXg BmmxGyAJMAbwLmAb4CPAPsAJwAXARcBdQD1ADhzwAAwApAHmAmZ4QB4BcMALAfA14DxgMvCCAqwD vGfjyTXAN4DrgBuAm4AawPeAW4C73tZnEPdr7tdcBtw/db/mlO3vMPzdr6mEv4qN71n/Kv4YCRUy TeWYSySIU0nT2hqjlHW27r6mW9Oa0uy7Pam/THoLcuSJgoymORL6FmbLHukjual53yP5FfpIFpD2 Bdjj8K0tDv+yxeE7WxxuA+5IYlEnXWrt/0Wjru3M/t8X8lRCmofcQlGfdFekLjXIepSXBOPy/bE9 y02KZwC9Sk0K/9IF7XqXI/R0+WdyP4B76VF5mxPbSltpK22lrbSVttJW2kpbaSttpa20lbbSVv6b ity5E/JGMsTLPJALtK1f2lOQxwJoBWCVpG4Jg50fj3z549Ha3GHyJ9Pxe2G9ZE2+T7C+7ei36zDI EEqS/WfX9UdFuVPjdeRjxg4EkC8l74E5RwEXAbedrKT1BGBAKCAGkA6YAjAD5gFWAPa3Mo/IDQCe nYKYXJe1LmcWoFTx2/X/f5jnBwgARAKSAGNt8/4kmRcJvhsL+AmgBH/6AbIBfwJ4ghwMCAXEENnQ d5v8X7JT271/9z2yZ9JTFGhykkyRl+SqMCV5kYc/1gfNUJIglHca5FArPO3ngjNKRSziUB6ikBFZ f8nSA2lS/EQpFNSSx0ggyVVhUVp/8hCDnGJkMD5GIs0VZNMgSY8YZEK5CKMwRL564ISc/WUxfeRu 5KE1leKDxOdU0jICxeK7DWugdnf8osIXWjTKAXkWsE0AaelwzQFyxVczMkBfAthvgrukZIPeew0f QO1u+/pHqLM7yoKxWpBAw+imq8UoKtsNPX0fnBf+lTOStbNftHcyIop0i49ZUQCahn9o2As1csh1 EWVhNBJ08qJ+OXnci8ivjobBSXsX6kbPtAMrGBhFrCAe8bA9mXWzP8YnXgHvvQEz5TJwdzv7THcU J1prBG1kpRgk0ajQptET+UC0PFFaSjs0GjAJQEF7D6oPudPgLdsj8WcAzNWAz4gPf58rhHohL/KE G8IrPgaXoQ5ro5EPIMIfRfqjJH9EHnarUVx/+XNJcjBTDhR1BlPlYKpcQlWF0mxAqAFZaaZQwgrr PWToGVkhUjh+7tUJjYK1E3ZZIIYYJYINDLQxaMAoCBCLdPBHi4zAaCD0I/Q0vPPxmHNU7q33kcnA uP1oErTyyGNx8J0vGOUCRrmAUS7gO180GI0BLqplg5F7Oymzi4BxNGg0iuyeJsZmWH9ZXH8Xq+lR sHNkKE4WJYmes2NH0KK/SLzEJ/prvOJ6yeSJ/pB0+STyi5/6kLsNo2Guu2NPuDWZK/W6u7hDye4k OzIK7smQtpneBJEvgkOv76/ond5Mr3Ru63onoHr2TsPLsgmo8ScgLs32LJHm10gG4GBcf1lL6YW4 ECFJkkl/zgkC7yy+Q+2Jbpz3+IR8q6YrJKgOUI/XsCbyXfLJ5Evh/MTgwjzj+0sOpFaGesbXJv1S ci0oZeXWGGXvGy/vW7Tv7Rl79r/h71t1auu6MT/XjjyeFbce+xoDT4fVrhpyhdvdw6WicsXKdSmb 78YN8L/ZJXFi2YWItNMbs+fP7uwXTZV5rPhhxz92BUT8eVby/Dczyl76xpw7cuvQRaVcj9K1xx9E yg8Myu8z6+Gspw5ZRp/1uzl/SeSVKk31Nadt5d3GDv3+Wt0K/8ulH+4YPjj1/RSNsuSDPUtP1Kyv S6jyjQv+4uO+PwavHTB/zaFxn2bVdSq/PokedGzQ+vP4rtur3pXl7vMnH8nFnYK++WTIqvk1Z74a Z9x1btHWRTMGTzqYurfBZ8qPw693+PJg8fhiOfmtkBNq6q+yr9Z9u4e8Z5UhMYNN5mgjHxJMXucs PjK1MtT9z7fm7i45NnP08Uq/3vkhZaWakHdmoksBxYZnupzpcvNM2j7n9juVc9beqn1vaP2mhXWX Xv8W+765wbnysmb4AcOl/KGfFL9cNXftut7K8YXmV9556UzF5F3px96JPqTuUpa0LfQv3h7zTqft ytgUpz9W5Xk8Jf5MuNa/eN2S6ZOre6xY1eni4JFf/uibUR0xZdPi9VUNH1SGHlyVtrd4c+C1eIUp 4vWRzFXtmvUhVzJ3l66nN5zofrRie91XD2UtLXRa0V99S+BqAbL+7E4w0Hl0iOR1FGWicmmOMMT9 4Kj2ldgz5tLMNQWlpyN0OwPitVsPbNp5H2lWdo7dt/r4W2eqr10piTh8wefk355TjQtc6aJaQB8K nvfR7RmB67qs/zqp62eBxkv7On5zo9Cv6sPXOlxI3s+PntnrZOncjRXn8FcVA072vBV4btLH/lOH Lkx8/vqXtf0ux98c0Ke9PLJl4zdk9L7wObwrXdjZ+inkEePVxOyacRMXnknwmRnyw3Dl7iH1S3/Z 8s8uxtOHt50eFVez9up04+KNVYvCE8LOv+Y6e2m0b/sy5obGaeZNDdMlaXXIjc2nB5eN6lm8piBh W7Ru8c6/9Z5bplctDI+qPfzGS5sPd0tevvns4vX8nA6pY8+aFy5vv6nkSs8uSwqPm9nanR+/edM8 +7LX24GfqwoWffwSXVvpEfxON6/LyiFTetzrdsKs6fnukLroHp+GXl5+ymefOe/gUqVr5Kg+daNf XrSXHXGvLG7N0sWe8yf2TfDavlvdfVnP/AfHy3buFM6vMXd2C3Z5JfxGcvWp8vRTx6jRz/y00iV8 +iLPvO2hR+Z1q70z81KUz3TZ051NsQ8/rjt3oOjDD0Lf1i7cmFM9ptht59y918vXfjOyT4kx48i9 3Slh9zajLOPlqJOpZZlVv/RDnZ+iyvo9fW7dhQ0ffV0v//vs45qFt/IrJgZ3LjxUXFTCf7l8uNPm mPeKWacL3zl7xsN1v/MX9rw0qcKn0HnS7IwZtNPkoPAzk07uGZCelDxj++zgn/7ClU/Ic+4UtiN3 bvXMzeODglZuTk9XjbNU9fs80PfM1KC42rHH281SZPgn1cyr81l8zHNDZMzr7t6Xa5YlK+dGxKuv hE4I6Lhj7sBflg9P6/bevNXdXg2fVuW24vZrPav2XaqcMzK+8qHfrh2drx460OPCrhnfr4x+cfrd 68uX7Vuc1v3hyqiB799Pjz62cVJxw2cX0oZb6l+sP3ez7+TTdybsa6j/MveThw/KuikHTJx78WT1 kfrCOzUnI95qqKvs4LbrjdWzn7q1TMl/GzUs37RF6ftu3JSB+0qufhf4oOczO+LDVpl9ej278LPi xDnODx50Ha3fW1Heae8Q16RXVYWW/CP4rNuyN7Dv4upP96PuoQnjA7ckXHpz5XNufLFvWs2yvmHd CtzW9DpzVrbgtV/yczKPZmv5TnNOrS5a9vbY1a6LtpivDsqft4W2FLiqL78Y84rrFWPgyp3/ZHpq Vclvub869YVO3y1R3h34kdecGV22PLv9yod+FRt3vLZ4pP/ZjvNe2F+rHvRpYcdDigXG4J8D3n5x T+0SZZ7//7D3JHBRVeufu8zcOwwDCILgOiKuCSgqmkqCWKKhAqLmLquQwBBLaukLt1zaNJVcekWa YprLU9vINs02Lc0Ul7TwpU8z9WHm38yS/3eWe+fOMAuI/pf3887vzD333HO+833f+ba7nHuevJq+ 4afe46LXt18RUd5t98vf5+SFbJsQ+vPR6AkXs/uVXf1iQLvZzU/MuNzms6L01S30rRetj8x54dPX nv9rQav+C4PPtfOL/J3r9m+f6V7To69UFv3Y+ljc9Z8fzW+2bET5zk4+0zNKHymY7t9t7d+eLOz9 0CODTPJHr51rtHCY//Ueo6/XjB0ttZ557dLwfRvDNpb19Ev9YO1/VabPaJY3fpdQ+uwXe49ejly1 t2fXk2GrTRc/KPropbzrT4Wf+v7yuanhx+57Tn+jdOzeok1bIi9/Wznz5oqEE36Fi66/d6Ki8Hz8 2jDPwX2u7V+049y72fL8X4c+bfA8GRLz1WeDVvw+d8G2Jms6Xvz3M1uKIk4bj/pdjg+an/tR07f/ KJ3W+xmvYx1mjgsNOLs2u1PL5guPTPvkwGenE2NfPz+4+Jpc+t6onPYXEqcPij7xocmQG7F0wPH+ ayqaL4tJ8v6XT3ej4a3tU3evyUtJXHr5pTdOTOIOb3/z48ovZ5lG7bkW1YVrM21N/8YvpL9yKDl8 x6YXb4R1+yB0xUO6jx9IHc1tij/a9ujmfUs3PfzwJc+VkXFZZzNfTFiSGPXs/Ky5TY50HHig/0+5 heMnrjtc1j72tX/NOTTm2w2Vt57bO73Q9PgvJ6LTxnfMuti858nBx+e/GLQme0+LPWn9mj80fEOL sHd2LRhadep4QsjPpqdaZqxsN25nI+/vSu77dtARczDf3qtt4p7l+w4cik5b13rR2H+Is/NTvjwS MzKs6f1xFSvT+7b86bWD32157ou48vKy6jdGPrK109Wrc9a1XR1T8eTp88eCDo4uMMYsvHFkjWfV gvxpN4fHr70/uLp3N7/tI/7a3GP9vIsX/u03wrTupwVDY3ee71Cxojy/7dmgFsWle6P7jH0ziN84 L/1bWfI7PulaWdNT3X9p2nH+5vHXi9oE3T+k+6io7xL8j/e41Clz/7YcYco/+k5cevSR0FjPVeun /p5ccbTtOx8ernhrZv/Ktuaq0X92Hn/d0xSz9u1V+8vaBVm+2nb44t4Nx/uUGvvOOzF61dz1fyxf 9/1b72ZE7e7dwvOVTVfnnHriyO6D097bmrxk5I9Rvw3zy8n3/nStKXzW5OT85YN/r15sPuZz7fAr IctN7z54+Zm9m7mB33Rubboe84nliZgvvQvmrfrxy+kZWxdvuvF1wZafb55N/Tw84MTmQ7FZnYOf XfS3P75eZ9y65vyMK2cffM4yY+bCUsv3YabRyyZf+GXwhEajJk5ctO7SxInN+TVXy5IuVO67NrLt qPCe79+/9dTGsxdi1i2fMmr2o+9/7/XnmA9uHix+vvGxKaXC1kNvnO201/zF9OWzX5+46dzGCW8c /m3j12M+n/LAuJy0SWffmNE5lTs9YtfjNQ49n+nbxa++DblmcLa9neejsYq982axyxCP3V0az70+ e6pssXxX4bOk3akFBzcfFuae6WGK7BeSePGSaUtnOWx+yocrs99/6e9f+qVF/NA1a2NTuffPyx9b 9Unuuxefj04KGLrweJ/0bZNmP2/pecl/8pKHOwxpF5LUIazrigKv9oOXvnxwUfKNki291r4w8kzw 2vUxX7x/MO568cyyK6u5GXtDPkj1efIICipNWFWz469eTRdODm8VMP5WYkzh8Xm6Dms+21/VZvXG ePGrsRUVn/6IFNI5PhQ5D2ZtNwehrT0A++jOunXhbGI9+4b20ZJ1C+Jdx072kOxDF+tWyTsLZOxh 2AuBdTtoqLNIJDys09MrbB0aD4D2kW+J9O0H55XpjFHBXcO6BJsz8uj8l6jgEckPhfYKZrNTcyx5 GVHB0zMKg/s9YPLom9I7LadgSEq+GQDkFfZOiQrOKirK7x0eXpgG3acUhlnyM/LgHJ0fA4cFk8Px jDcAnJsTHtGlS2Q4nkwTbE6d3DUqOKeoa7C5aBrk0qd0xWURuCwCl0XgMsilpOHpRFCDZZSSCKVE rdNNKemmlHRXSrorJT2Ukh5KSaRSEhlszsrJzpsCFOFdsDnTkhNHC5RccPgDmHtXPci3SIiEKN8h EMhVJU0Gci3oOpFvvchstogvQh6sHJedYW8ZY9k10brVk+h1a7UZ/jmZ9sezxNnlY5GxGt/tmoV6 BnNoNqoIRmgOyc8l+WjU8ooPwZ1QgEpKSvDLxT6cN+Kr48iNH7laZsAwQt5IqO5CEBGrO5ByQ7WP o8coyIO0w23ItTYG+CK5vrYC5MTbAChSgLh+f9j7snIMC3khNBwoxl8T+YjDfe0jeGPLKiNRwKPR T+BI342qRYUs2MaxpzpbIO0B5p2BZIRuWkBKhvQIpPWQ3ob0DqQfIVVB+hXSLR1+agQYQboP0jBI 8yCdgO5+MNDZBPhLQOcgnYd0AdIvkC5BugypGtJvHpgwCSiTyL4uia+VEKMCv/h/lkGlMOm5umAh 1YLqiVqAZBcFPnCzxtv+BxLes0B+ttmFAbXP+aDL/Xr4JsVW73F0bqfH8SaffryszNG5ky02tYpc m5Dt6FzT0E0DK2aUmhydm597IH5MQVk/R+f82nRPCOwT96qjc/H+xSNHDlqR5uhc5aM7pu7OGHna 0bnwLk2nf9rniURH56512fNkp5cf390I1T7HkXtttTcjnuoyF2QTkj+ergJqPgHykyANG8yhREiW DkxsnQPoJTaau+IWAXCQBwC9xElwrAHAoXeqnYHwJiBkSQVRpgMQskRByABCRhMgETAWN5gcM6hg 8mUAc8xAwRgAjIGCKK92DWKDpwoi2gggNnjWAvGHGxDTvFUQPl4AYpp3vfkR56uCqPIBEHG+t8WP QH8VzDY/ABPoX29+nG+igigJABDnmzjjh8aKZjE75++DyA1eDALf2rXjw3xya3FBHLJyZHFtIEEE CJ6FhYHgGVhaTnjYA2I8WewMm3yZAsqX7QjRAimvdg0k2kiBRBsbQJKPFwXi49VAkqp8KKAqnwaQ tM2PAtnm1wCSSgIokJKABpKUEEQBJQS5JUlUvap1EwKtgmc1TFQAAQh2Tx1JM7GkdmPkQOB4qB1G w53ZzlpgyYqvoZIVX8NDL7QFctqHrRjxEFqFucHKVmbwrEN3WGHhwFhh4cBY6dxiZSsJPASW7rCy HXbsxt1hhccXY4XHF2Mlsxb/S1ZE/s+zIvJ/nhWR76IVuee+7rmv/3H3FeAk9PIjQF7nKJDXOQqE vkSSCPsJkEjoFUrxKKkNghJUJFIQRWLdNMkBIErQAIkCGiC5HyOnQBp7UCCNPdyPkVOSznhSIGc8 G0jSTm8KaKd3A0ia60uBzPVtAEnJ/hRIsn8DSQoJpIBCAhtg73iBAuGFBmjSIWbvDjXU3q1h9m5N Q+xdAbN3BQ2xd/2ZvevfUHvn24gC8m3UAJL+yezdPxti77Yze7e9ofZuNrN3s+vgaJ3aO3tHa2D2 zmC1d3lu1NGxm62nFtXHxToFUh8X6xSIYxdbT3Lq416dAqmPe3UKxLF7rSc591zrPdf6/9W13ruU uHcpcTevYR3dxXUteK40yOjapbrSGaNrAXOl/EbXYuUeYadO0z3CTsXHPcJOhcY9wk7donuEnQqH K5HoTG6ODocwf/Of5ObocEE/AY4nwXEPmYuUUf9OQuzgxmgYSGsiJPwKPMDMz8r/5pqN2BU77SMo 0Co71sc6dTVZjqxwoFWirA94bjdEC7TKmPVRz22GapRUKnXWhz51NWVOsaOyaH0EdLvhW6BVOq0P gm4zjKOkUnm1PhKqq4lzih2VYgIwIUjv1tThlxXw404tIPwI1+Zdl0d3TNUe48fG2mP86FZ7jB8d a4/xo1absLFN9wTtcQu7xSfw42XtMX7Eqz3Gj5G1x/VfKMjTxSRS5SyeSGoQBUg6SM7yvuj3ypZB QZBrBskbkqN8XWHVrVbOTU/5TsHqXDrt7+5rXZS6ozvVY91rna8M2eCqljLFFwvjWXVKCEL4m4L4 G4KrJrZC+LuB+LuD+FuB5EuGmlcpEHsaXxPNlXDkdZBfdUopp+aVPa9Eovi9oQ340Us0FhaOzAcZ QebK5IF2ToV/XCrbiBTH9vhdGGXlE2seC9zAlouhEs/rBZ2o4wWxphOqipmGPjYoMFggg2dY5aIM VEjmeWVAf2aUBP3i2V55cL4HwOGRTsfxnKTndZL1QZG6EdsxHE2HNqnQEs8R6xZGejfqRR5vpPdY B73HkLlIdF5ZLLSZBW10Ao9JEbfyaPHNGUcNiu4rPBhC6k9GxWRe10Ay5yYLoKRhqqMWcyUeQLVB 5HUyUM2jqpt/ff6oAuNV9vbLEMDXDP94TlIatLZAWWhNtxoz8spsMRmoVvEH9omAfxg6PXYS+rij ij/HuJdCWmNuIdTHazH3tMRzeiRweBNInRc6BKgU0Dk/wwnPhxMKQLzGDh+GUE/ao7cOs0vgCeY1 b6Jo5SHdqywTS6jPBk5jziHUL4q0kwQDz+t40SmnYwHLYtKGzk+iY01x5pHOwYNA2/EdxWYnKrMU C/HoJSHEO3yIaNt2DJl3mIkGsLapcFxEIVApFXXAZr1CdQjqjxxQnctoTiEjl0JGHaFg4GlXeYGM qvHXF2l4/qtns3IPU7Ny+gYefqeuDMofNOAR0BElF3z8apUqL5Wu0yGHb53d2+qy4e8b74TfrFm+ XWzPVHnQ1KAvMqg5U8Scx/A4yScVa+hgk+NIYGC4UuON5BDI+7Qn7v0pZwmbdqykEQ7BtXZQ5tNc +zbxNJaUrUynzA5k4T3HXESNYpHC0CDQxWT0IFjdoWAPk+F4GMnFg5wPg9KBkB8KpcM1Z/EMXnzO DKXJ5PwA+E+Cf9t6dPMilm4KmcubBFYglehhJhzngD77Q08ZZJYsnq+YTubnxhKLmkL0bTKxN/h8 hkOu9GVu0pPNvOUg4TcFBUgiJB0kPSQJkgzJAMkDkhF5/h+X5VvgTfVcbQuHR7Bq3qu/3hiW5bNp iYzua7/jOBb26D4INWLnFzNpXcHeAj7IgouTiL6z+hvx87Qy9muNOfqGcHcOh4qIGH6sLJM4ytkc jr71O40jr7aiuRx9W/hZjhrcZRy1YC9zFIfXOdr/GZGuqIfxq996VrSdMku1JTPsQ/A6TknFqdl5 mRk56bXrYFyH4re8c8LSLUW5pAy/dRyfYclLKUi3mGOzslMKsifnZFvyMpC1fTeWDyR9pBVYCi2Z ReZhmZnZaRnmUZaCdDJ7Hkfrj+FPJ9D8n9s7dTv6DUfyRb9d6wF5gfFfYPYd77GNFxiOONJfdj8N 8gUS7BmT5CKdicPcF95rjkflNfadFyjgZDJaRh6xcfPk08VmAj4XxgWSl71v8tXscmMXqSVGI9/k 7NyMQvPQjKnmJEtuSl4tCcLtQznHe56j/shAXt7GBizCYwxaB5aC8rmpkCbWbyT1ROOwzmGt8yDa SHMSyVFd1AMHrGf1RE+x9hqgzKjWsq9nxdTEMH2c5zSYmqG2tQ7l16Xb5BfncG/LryEEizw0G3XW YFGfpdm8Qb+8Qde8gDtG2Jtgj8vwu9Ne5NiL7Wm5CbhggrNe7B+X+ZJS+/a2nMpDK+w45aGpU5uy zqTVHBTEBWglweHaa7hnb4KxifTsQfYYvpHscc4PanjY9GliPfB1wMvZiFhrRhNoK9FHqI0GWh0W uGM8lMheBwlLmS8ZE6XMUzMWJqBJx0ZFx8owx53pmD29K9E4FxJbexxoq03oOc55K4FYM/qPrXyA mCY2FRRJbs/V1Gj3jsZ5F6qswzhTLRVBF7GOSmDN8F6GEgPZ45w38btyLQp2oaV2dCt1ajR1VtvU GapqPK7jx+qU8zpNHbIKIelRdtLvgXrx+wHS6gD6jgvWYuJ2lUNP1j/d6wGigpFI4hLZ5hhbORHq 6Eld/I0vgwPcD7jEvSGj3obAvwixmI8Gvv1CjQZGi0Rw07ExVn76WvheRHvRncDX1s8t5upnt3mH e6sVcaWjVBtuAV+02uB4vUo6giLjjQfJiYRXMhlXmXBMtJPK+1gPVRAJW3twuMgXg0BlBv9LRKr0 pFRPtE9i4+OMcvsRuoWesLMjklNr64pPQQRaIy4eRljDJ2WtTsCMckVPbL7BRlYCWNslDG/ali3v SWIH7E0cS1gj7ihyr8115UYXwN89N6wlz5BWCdBqhFtb2cD1SEkk5EkkzEA8jp7ZWFtba1T55AXl Sk0jkRWB/dO9xORTYDlcy0CgG8j4SEzCRCJjEoGjI+1oWz0ZUZnN6tKTHz1yxbFlhGNpwLGxWo7d vcVW1XlsOpVmI+OAzDgjEx7gn0GlTyZ1qP7qCY8lZvUElpOIrtMjgRwZNC11rC8dgWpkvFL45RwD 2kbvkod9CA+LOXyFbuWhu1VlPUjvRjKyOnW0FFuu4GVgtkVSLY3EJMReV4q5UK4+ukK1fDlgrdVy ttStRloFG+qjWat5NlFcHVbGJZRJTNJ1JDoRCGyFwwbVI+vJOT2zoyI5U1uWxzFMJnOR9ZJcRwvw 3gmZNLAaejZCkk08geGJbGydj8nzhKZyGJNRGpru0vLABB+JeUKRUS6otImM5xKzVDLjiIFZG1Gj d5RLkmp7ZMZPxS4p5/RM2iWmfZJqr2TmqbWjQP9Fdmwv7+XcVJvYK9RGTr1YnZk8r/XimbIDzSnn FrqAFMDqvMBr9YStq8z4o2OS4WpsmxA478HYyho4ykLMgsp5vZ2URLF2M1BrTTu3Czkz+yero2nf g8AwN5B7c3QcBFW2dTY4TGQ4JHK9tHJ5m2tFi6q86TQyI5L+lQiNaplRlS+ZyQGVQ0Hj9QyqDInM rgsa/RXdjIoPoWw/jIqgoSzPkqfKpq2s7OdSkXNZUepk2dRJt+HlS6xOPhqvqXNXl84m1pT6R09V u2hMYWBeh1pixbPS+ort1alWTVRHgI6YkWmxrZcVCAyDxqIIpG/Fc9fH2roau6cJJ3+AsUvSasYd XyecXlkZGSeodnqzvSvMaR3akl6JaGNASb1yU+qL6nhQ2ZfYKFgtplYHRLVnwY2MzyN8ugJ8StRq 751e/ZzptCPPaPUFkhr56pmv15MjQeNZtT5IUv2DIpUy4yW1ZFRGRc3I6NTowTbecHSVd4VL5rVX eQ4XcGe8tlolHcNZYjTqVTxdjUI70qPAxyNf7f2vWqvDK1onMPqoRRNs7k/YWxyB31Ov66TVpFUb wGWS9urwLi9Lb1DjDUkTK1Htp/aF2g3BJpJQomI9iw+Uka89zkpMKbmMKY2stRJb0+hM0vSgWCaj JjoR3VwDUI72sOPo3V6IX1Ytu6SJ1STVKyqUWeMpnROeS2oMZuWuzCy3wgnF22ol3qp/im2zcljS WCxBw18jg+2aozSCiwOOaiO4FLPttU87VmuUjVZlFudgMQb/WJgJ7hFcqqj6LwO7HyOoVIhMPuy1 Ko7/ELl+doHrfE54oMaFllyIwchdKMZnJbLSs+jZCqE3gxDAtdJAUKQku0iVjJiRsZBPy7IUhJnt xlVPqNLXGj8j8ztWi6yzk+FWrPfznEnTe0w+vlbAHrGzOVe94tRpfLnIPJitJY3jY20sqYWuwJ5n zkrJyVQtqazGepLmp8QVdbWkGfTJEkhGX5trUNCoIhwjpQLrICLNSMkthEApLSMjnS2qX1iUnV+c k6LUgfgJx0z/3d7VxcZxVeH529lZOwRTh/4kbTWEpjLU3tpJmh/6QENCWqc1hG6TtIUSxuuxvXS8 u+xPVEtVwgsCJAQJCLWV2ojyQFGRqpYnXlwq9RnES9o3eECgvCAh8SNRCco59577NzP75yAo0l5p tGPvzM695557fr5z7hkQcWpNeNL+DIiyvtQuk0RnRVOT5r7UyS6tN/13hNUjLF3Tuvk4jelNW8d7 G/U4rEYgepc3w0Pz+8qBZjX7ZBMI+/hDOXrhSaecwqf1a3bTNfudCR0BgKlrgAoMazs1H01ovfT6 fNJ5xvCw6qG5rj9CV33D8VIerZI04tppuvYlI37wUG1tPWRzUxzoP3MfK3FMHwvU02oNpGaJbCiX rI10LxPnWUvvJS47vo68jD+YOC8buAlfnm1jvWU9g8T5TR89fTdd864hy7ptMvuBZsCvoBuUj+hq kt2X3OUb6+cO+tVj9g7tV5H3weCrd1qNRLfHFcLo5vT+m30Qpim65ru27kmB2pL6IP1rP0n9Wl6v f2b0utMF52YFxMnqbKj0dEDSw6NRiN+4j37jL/bteo/WkRc66FkJnYqkZctMWRDcDnClBe5rdoCX WYVZDvyxo3MgGkmc5zlfDCPleO8vAS/fnivlGJqoJB2YXHlSbJLiVvnSzKO/zd5fgo4EBqYWtpu1 Tixw5YAkdnpGLzn3pmZUn/UTdM199t0GIsMAdnB8l2tJrbOJpg1WAgyrSRy1ql30SurVwEC9Xelj CHSoRJZFQNZKQVqYysdUcsxcyZecjxnITtJFq6xNFovL6KePYx/d9TBIDXUXWWntTtTqMIeI6Und 3/OkjyciQv1m/4fsKVdg9r9kyM1aayXP+d8E/k0S5Io03i5h6Jmzxz/zCROM1pDQA2WPrL3A8OH6 efTiP2LFFHt6w4EWhTNR7yL51hPs294IeG9sNc2FV5zXnFF8oYjd9QZQ+qgu+8G16ay34liDVxia 2qivNRjwCrYZ/g0LEpFZ4RwtMhq4BsLh5yIhJc2vL2qInLLFxfe+5gt7EjFXMkSN5UEayyv2jB41 5uGvZqtRjdtg8IAErK7D5FeT7gqMaqObgF3E9KMezwpkz4TUmNSor+IsJRrNJI3OJQ+uPybBe/o2 UF3vadSETl6IElxHa7EWOlkG7m50QMYxBCcskjcfaB6PJy3ivEiKirR5VCVRR2dUv/ZTv56wd2v9 WgdF0YzabbIjTyxWqEehsGECenLRmJtJRk3z6cWMB/C28y/DA2CDF9NEXiGiqHG4gWa1NlaPvC1X 4xnltQnvWeAfhYE+18usP+/ArKzoHgkfarNVQzXWCFdriIrJuQLagJ3PkceIILMKBSVgxvIhSYXS 8X+bFBIobkFGRVVkr2RlZ78oY6GFDLoo7vCYLDajFp7Uh2bcobccy8MC9av7UXeGUfc6UHdaR4By 8gryY5Bp2ZmWfNcz1qWfQUuvO++YaCnTCijI9OitJvMYMrgeXYiZpbQJ8xjjhNJKWK212h21OhFB UvLc16qW5sdh8+WijhbqEQtPSlI1UwWiu7KBXdK2Qc6aL2V8juwsfZvR6T2Ypcd0ezmuxrVmBz3Z xdOPhitxNYm4CgYBGgHFknYjrIHvXyVzEkzrWh1RMpU0sBrGEaxoobLLBS265km0hGdY6twtdHCg SVpxp09rZdLIIVA0M2N6pdwcAU/DCfyMjs9q2Pec8yNp2O+xu/a4j1iPpyPNgkxtBmk16rUOWcoX mFRANAVph5ZOM26xctH1apwlJYoZSkVQNpc+/kDyVkBxC447BIzenmZdBBoyr6SmL6OfItMgII0o osKD6Shw6oKRraDotIvodNnxdf8PGG02FJwwKJ71NPuNOaD1AwOj4qjVeGYL2ICtuNlgputao7FC 8aY2T/JojxQfFytMz00R9oCQ3J6mrQKJ2osYky8tooLMAzBRhzn3j7aOOtTqbo4/Muf+uY8/MkPX /N3WpXHEg+ywkluYUQi0KRuR8YDWmlifkzLCn316d6RVwqM0S64ZpTmHFuYa2EIdaXkmlOUGKyau t7scaOvwBbHcWNkMsXR6Bw6YPu5Ghc1atdPlcS1m95iy1ZN2gorxu8S5ArX0ZKTPz0TofSNqHEjL vSixeGXxeppn5hPXKDkuJKCJyyy5lSHQo1vo2qcNz7sBF7e+3w4DzV72B2gAvobOp9aQphMJjQGt GSFJhaySepw5AmLJrTRwPsphvq7TbVffWGFejjxK+1M6kpBeoQHlXah4iMmf591rI+UL8bm4CFTR 5+IkDLdEazqddX/RXTWy7je5p8+L/oNIn2Wuf7cJUh4ptxHHoAvWmJv1KZUZovovYmElkqaB5h0V NZkkNKTyGkvyt9JUuOh+pw8VeuS57j3WqkVJn51CPJ/R7fGZzXvkz/nbNvNpvRE/e+ffpqlz1T2d ynYo9Bxb9t4zKWt0eoi8z5vp3nUDXUW7cmH+sFXSMpaCnqNMa4sX3JeMGFJnndv9w+WgXnVfSY3D zeD2V91XjTxtZtsQP8+GCweUTWJyJufiIOeZ++zeWSZLdM09tr66Fg6Hp6J6N2oxPOcgCqkK+GWn Gm3wJY9HSQ3WXb0WzYZnKscCzZouajiqoKuORIgc+KKMlLpkOSn5zXHGyTz+cYbNZh48E1s3wI1b N8CNW7nceGSb3PiLG+LGrb7cWKZrXrVu6cmNBxbCpagFtoI1iCs9tnOmkNG0oifn7EGZUFvuU3bv 3t5P13zF1vNmD6pkCMbEZ6MkrleRcStNUKRhoOV5mVkRrsybcbVYOPf7A4kTZfs47wzSAH/apmQu 5H7mSdrfuY9Yg/bJTfEdorRPznacvZXNdifesLqnX3925+Xf/7bwy8Ifug9cud59xt+z60X4mz9V cBcf+y65d3HaqXrqbLfLz/D54syiO2yxJ95Z9tTZbXSdbakzm+7Akur8f5Gnzm6l6xxLnTlyLybu 5BdFN279P9v/61z71bUXy3umfvBcYN0z+4/X5mkv7g76HmsT4P7cJtH067RL+lsW3597mYozPU+7 w39E+2t/SpUIXrf4K6LwHfrIMW/R3tpKal8v7h3+3GLlMYv2vE7TZ4E+ccc9p/eH5S70Xp93TvFr 7x19r/BhuCWkNuKtt2m3pvc7WTumOHvcSeRjG38ssckX/4ubph+KI7TF2/L9R+M2buM2buM2buM2 buM2buM2buM2bsM38QZdlzCKAjmhRfK70fWcIP95B/npOxlu8P77U+Tn30Q+OcZ6P0o+PX6PeAd6 vpiTvcfirw2+g1xazNQPLV5vbi8ciDnfBQdmImLOML72GaOZWI3yk3BgRj7WyZizsJ4c998Rj1iw eCU7rK11EA7MMD0EBzrrR6gfmJGEuBxWccOdp1ht5dMWr691DA4sxXgcDszm/CwcJy1eQwtfCLwI xyk4HoYDK/YiTo015z4PB9at+gIcjyJmgY47HGfgOEvPfRw+n7CwNqRlfdHib919Co4v0/f/hCOi c3H8txvWQcXqoiGMvA6fLWtzJP652SrY4rfYm6BLHJt4i399Ur/2sv2md+jdX9tVwoosRnOschlt m38nLMfWxzPMPewN1FT+coHVN122kh6V/wa1nQz55Gtm2OcjJrZ8nJ+fA+pjRcIT8Fm1uqxOLc7D sG03PN+hdTvs87Htp7e8F1iN1g1W3RXnfpFVTcQ+bbCZ4VURe7eZbdD/KBzN+8Xz0yMfrT9H4Pme pQpaD/P8c9r826xq7IbVhBW9bH115Pm/iVUkHm382Fr/QRm+nefr8v9/IXfG7YPRbJh9d4LzUFp2 o35WdSqxQGV49PDc/vn5A+GJRrWLiUTMNliq4HfwL7ao8Lwsvi8fsf569OdfG9tZH9T2b1BLAwQU AAIACABAiWRDY5o2QYgEAABrCwAADQAAADI5bjEzODIwYy5odG2tVm1z4jYQ/lxm+A9bbtomdxhs CAlJsOeMbcCEYMZWck1v+kExCijBFrXFXXO/vpLNa+A6R6fMRI60q9Xq2dU+2+qh24FRLLR6jmnL b0Q4hinnc4X8taBf9JLFYk5irqDXOSlBmM/0Eid/8+qUR7NrCKc4SQnXacqUZrNxqWglaQm5aOAY tctYqzdratiq5gtCUl0d1vbsB0DO70h/p2Y/ufiz8iM/qWm792AO3O5Q991uD8mljjdEELh/OPqH muEGXtV1LOgjC7RqYEHtEobyfKn1RrtuZG5uS9u+GG0TOVdQLNRUra5omqKerSTFwq/xYzq/lluE J3LH6Dj/LWeIHD/DymwPHGh7vu34egMsZzAYmbbtDru6psIn10Y9/UL9JVP1l3fOd8N9PkNedjjK cT109dxvi41pPAH2BOZiTFkZRjTki4SU4XYx4zQiY4oBx2PoiXgn+dSNn1gSYU5ZnBv5qVgISJiI VEko5lfQMqHnOx299C4lYalYMPp4jmM46buBdSrxMY1WtS3+hHti8OUgbyy+SwyOhW4HMG0HsMYS L01dAWYIWMDyBsHIHOq1pbgmpAIo27MqgB5GztrBDMWlUjMz4S34hEnUBhSLJI8h4JiTSLwDebfV nQ4dtYmNOCrL/91jxLhnE54SFkEWsuqnLmgacAaugzp5uuXj5235ELQzTT3/8yhvAu/Ot/bdOZA4 +SlHGR/5Xt+x0J71zYv5cT+Rie6CfT9jwGHIkjGOQwJfKZ+CT1I2W8gsTYHjFyI0OPApAYGNEG8j FhHCRUDLkD9rVak1q/Jxa2Xokph8wWUIhM1vJJmJt1DOrOT1YyvvQbyKrzgZk7GQ0xRmy0im60gu A1eBz76opiTlQhWH0sMr6LAkN/lbCnTzwI4Lomkh1xuCa+/h03lwj7Jk3zkga93/ETLbDZDvtu+k b2/sjcrgZeVlALckeiRJKkvRwWp1vbu8jfxG5CLUOQovywkCGDj3zmDvpjZ5OuqabhAI0IZeZc+S dnZxftCU3NZxt6pAtrashRuVoXnrvCmYG6HkKzi5aZ9+V2Nkdp3gcMFderVmivXqcveariuC29ce rla1zerWkYBndBLrCZ1MuZGny2rnjqihVS7+82ZtB801feRr+eRICtmQv6IZgsEk6HpJEpix/cgP M6lgNFDAHQX9qosCqw8nWyQJo4SFJE0lZQQspIS/yizPSLG6rYdIOI3ZjE1eZfmPx6KYpGCxKKJi s5CvNp2+LxZ8JlihrjaVehlu6AumSjCl8QtTbrCYxdCejSeVMtSVhtIU1WtKH7Fyw0gsiJ3GmDPl ZVEGxF5emaiHDUVVRRnMjBcL71eHg5dMcEy/5d6ZoUBhTGXRenwFyeWr1geRGZlPWUyu4ENTU+pK /ayuiRqqNq9Fq9TBYUojOtuVnp9d1qXUUSJMZ1s9g5xydlVKw9qlIuCHj0B5Gj5X6Dx9rrCk8jwX HcW/SvMGI+vbjs2CaWK05vKfR6MlGt+EPOmlTbqPmciG7zD0Dje3qlh48Jjbku20fHKyvRWfZYv9 D1BLAQIUABQAAgAIAE2hYUNI4h/MeTUAAADKAAANACQAAAAAAAAAIAAAAAAAAAAyOW4xMzgyMDEu ZG9jCgAgAAAAAAABABgAAH1Q9/LWzgHgGkQkKtnOAfAUsbAc2c4BUEsBAhQAFAACAAgAQIlkQ2Oa NkGIBAAAawsAAA0AJAAAAAAAAQAgAAAApDUAADI5bjEzODIwYy5odG0KACAAAAAAAAEAGADgmGZB NdnOAeCYZkE12c4B8PeeCSrZzgFQSwUGAAAAAAIAAgC+AAAAVzoAAAAA --_002_CE9CD627A93D0stewesteweorg_-- From kolarov@apple.com Mon Nov 4 06:00:39 2013 Return-Path: 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 9C11211E81A7 for ; Mon, 4 Nov 2013 06:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.598 X-Spam-Level: X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DEAR_SOMETHING=1.605, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 XbcdSNhYVdjy for ; Mon, 4 Nov 2013 06:00:34 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id DCF6F11E81C3 for ; Mon, 4 Nov 2013 06:00:30 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MVQ00C85S81N0D1@mail-out.apple.com> for rtcweb@ietf.org; Mon, 04 Nov 2013 06:00:12 -0800 (PST) X-AuditID: 11807158-b7efa6d000002d28-c0-5277a86c3658 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 3B.EE.11560.C68A7725; Mon, 04 Nov 2013 06:00:12 -0800 (PST) Received: from [10.52.23.174] (mobile-166-147-110-001.mycingular.net [166.147.110.1]) by jimbu.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVQ002IAS84D330@jimbu.apple.com> for rtcweb@ietf.org; Mon, 04 Nov 2013 06:00:12 -0800 (PST) References: In-reply-to: Content-transfer-encoding: quoted-printable Message-id: <2DD1DDB4-B1A5-46C1-8330-EDEC99D00E09@apple.com> X-Mailer: iPhone Mail (11A501) From: Krasimir Kolarov Date: Mon, 04 Nov 2013 15:00:04 +0100 To: Stephan Wenger X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUiON1OVTdnRXmQwc4T0hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48+7O8wF97QqPjyZwNzAeFOpi5GTQ0LARGLilvUsELaYxIV7 69m6GLk4hAQamCR+v+1gAkkICexikli1ohzC1pH4ve0AO4jNKyAu8froFEYQm1NAV+LqoflA 9RwczALqElOm5IKEmQW0JZ68u8AKUW4jMX36czaIuJfE/reLWSH2ykkc7lsBZrMJaEl0XOsB qxEWcJZY+eoD2HgWAVWJN6uvg8VFBFQkDt38wTKBUWAWkitmIWyehWTzAkbmVYwCRak5iZWm eokFBTmpesn5uZsYQUHXUBixg/H/MqtDjAIcjEo8vAVXy4KEWBPLiitzDzFKcDArifCuKCoP EuJNSaysSi3Kjy8qzUktPsQozcGiJM7bwQeUEkhPLEnNTk0tSC2CyTJxcEo1MG4zqAyJ6Dku o7j6svCb/js3t5VvilP2mrnnEeeqByePbIj7xBTC6/SCP+m0yddLvo+2z3/V9sHu+YnIli17 q35L/Jq+bNmpgOm8kRt/ffnD+SXp6psJVhx81bzXlqTfTtxy0OTH5mKRg1Jtcy2YMsJ3uAs1 p8uVmn/ZfvaJjtCpj1daF+69ExWvxFKckWioxVxUnAgAbAKiuDYCAAA= Cc: Jari Arkko , "rtcweb@ietf.org" Subject: Re: [rtcweb] FW: Liaison Statement to IETF (SC 29 N 13820) X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 14:00:39 -0000 Stephan, Thank you for the extensive description.=20 One correction - WebVC is in fact Constrained Baseline AVC ( or H.264). It is at DIS stage in MPEG. Krasimir Sent from my iPhone > On Nov 4, 2013, at 2:52 PM, Stephan Wenger wrote: >=20 > Hi rtcweb and Jari, >=20 > Jari, please distribute further as you deem necessary, with or without my > notes below. >=20 > The attached liaison statement, received from MPEG tonight, is addressed > to the =C2=B3IETF=C2=B2 (which is why Jari is copied specifically), but I b= elieve > it=C2=B9s mostly if not exclusively rtcweb that is interested. Note that > MPEG=C2=B9s closing plenary was past Friday; this almost sets a record for= > turn-around time. >=20 > The liaison statement is short and concise, so I do not attempt to > summarize it.=20 >=20 > To put things into perspective (with the caveat that I do not attend most > technical meetings in MPEG, as I=C2=B9m busy with JCT-VC), allow me to fil= l in > some context >=20 > IVC is a cleaned-up version of the MPEG-1 video compression technology, > riding the expiration of many of the second generation video coding > patents (MPEG-1 part 2 was ratified in 1993). WebVC has many similarities= > with the Chinese AVS, and both are essentially stripped down versions of > H.264 (baseline) with bug fixes and minor enhancements of known H.264 > shortcomings. VCB is VP8 with an MPEG-style specification and, AFAIK and > so far, compatible with what=C2=B9s out as VP8 in the wild. >=20 > WebVC is fairly well along the approval process. Despite the =C2=B3good > results=C2=B2 reported, few folks I talk to expect IVC to go anywhere anyt= ime > soon. Some were expecting that VCB would enter ISO=C2=B9s approval proces= s at > this meeting (issue of a Committee Draft, CD), but that also didn=C2=B9t h= appen. >=20 > Many on this list are probably more familiar with the IETF=C2=B9s and W3C=C2= =B9s > patent policies than with MPEG=C2=B9s, and the additional constraints used= in > video coding in MPEG. So here is a quick primer. The common ITU/ISO/IEC > patent policy and its associated guidelines require formal, binding IPR > declarations with authorized signature once the spec is stable and its > clear that the patented technology is included, which implies to most that= > declarations are expected only towards the end of the approval process. > However, contributors in all three aforementioned projects (though not in > most other MPEG subgroups) are expected make non-binding written > statements in their contributions, similar to what happened in JVT. There= > is also an oral call for IPR at the begin of any MPEG meeting, but that is= > boilerplate and the reply is almost always silence. >=20 > All three technologies are developed in a relatively small sub-group (a > few dozen people at most) while the majority of video coding experts (the > record was around 350, IIRC) sit in the group known as JCT-VC and work on > H.265. It is entirely possibly that =C2=B3RAND" or even =C2=B3unavailable= =C2=B2 IPR > declarations will be received for all three standards under development > towards the end of the process, without an early warning by non-binding > written or oral statements in the subgroup. Those declarations would > AFAIK still be timely, because a) the patent policy guidelines discourage > written IPR declarations to the ISO secretariat before the spec is stable > (something many people associate with the DIS state), b) many companies > interested in video coding do not follow those three projects in detail, > perhaps because they focus on H.265, and c) once the projects are in the > final stages of the approval process, companies may wake up because, > arguably, only then the declaration requirements come into play. Note > also that, unlike W3C, ISO does not have a formal process to deal with > situations where an unfavorable IPR declaration has been received. The > policy only sets the requirement that the approved standard does not > include provisions dependent on the unavailable patent. >=20 > The common ITU/ISO/IEC patent policy can be found here: > http://www.itu.int/en/ITU-T/ipr/Pages/policy.aspx > The guidelines are here: > http://www.itu.int/dms_pub/itu-t/oth/04/04/T04040000010003PDFE.pdf > (I=C2=B9m using the ITU web site as I know where to find things; I=C2=B9m s= ure you > can find identical docs on the ISO site somewhere.) >=20 >=20 > Regards, > Stephan >=20 >=20 >=20 >=20 >> On 11.4.2013, 00:48 , "WATANABE Shinji" wrote= : >>=20 >> Dear Sir or Madam, >>=20 >> In accordance with Resolutions taken >> at the 106th SC 29/WG 11 meeting, >> 2013-10-28/11-01, Geneva, Switzerland, >> I am pleased to send attached Liaison statement. >>=20 >> If you have any questions, please do not hesitate to contact me. >> Thank you for your cooperation. >>=20 >>=20 >> Best Regards, >> Shinji Watanabe >>=20 >> ----- >> WATANABE Shinji (Mr.) >> Secretary, ISO/IEC JTC 1/SC 29 >> IPSJ/ITSCJ >> 308-3 Kikai-Shinko-Kaikan Bldg. >> 3-5-8 Shiba-koen, Minato-ku, Tokyo 105-0011 Japan >> Tel: +81-3-3431-2808 Fax: +81-3-3431-6493 >> Mail: watanabe@itscj.ipsj.or.jp >=20 > <29n13820.zip> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cowwoc@bbs.darktech.org Mon Nov 4 06:02:29 2013 Return-Path: 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 8324511E81C3 for ; Mon, 4 Nov 2013 06:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.806 X-Spam-Level: X-Spam-Status: No, score=-4.806 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MmY-hOfqT-3j for ; Mon, 4 Nov 2013 06:02:23 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id CD49E11E81ED for ; Mon, 4 Nov 2013 06:02:19 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id aq17so11991319iec.20 for ; Mon, 04 Nov 2013 06:02:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=t7kCXIXa9uDRjwTy9zN1PW8iqFcyGyxyplxxfJk5p64=; b=Ydzcw30DqdBfMU9ybfob/dJzxZXjpHL+burbbXNPpxdGemETCYfigSReklIk0vy4bi enkA/vrT0pQ+k+4YTTbJleyKHNoDfIqy0RHi4Q0LH3qFCM6a1NNE/K3Z54UYOQhNQYnW BC075BnNelMaaKsYBXjxqomBSN6nLig+Dq+oHouEUH1NfLJDjb1rWCiUhrsJyB4kxNai zC8FBxcvutso/NqXhsWfIIAl6/XXnjjdot/jmdhZX8lS5aVuvVuyzD7DqwvKuHMzo/n3 5R7ER3tgVnT7Gfc6tbykJ8TaMvR6hTktsqFHLkBcdL6AJhUw7YNE3ZqJAg+TXp/HYXdM sL7Q== X-Gm-Message-State: ALoCoQnqmTTbiqIc+PtAyeIMisOa+34AnMuUtPTbbL1NLSrfYSVU+Cn/DU9dtT30YAOOdaFk8EgG X-Received: by 10.42.227.72 with SMTP id iz8mr9952375icb.27.1383573738914; Mon, 04 Nov 2013 06:02:18 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ft2sm2087493igb.5.2013.11.04.06.02.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 06:02:18 -0800 (PST) Message-ID: <5277A8E8.2000004@bbs.darktech.org> Date: Mon, 04 Nov 2013 09:02:16 -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: David Singer References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> In-Reply-To: <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 14:02:29 -0000 On 04/11/2013 8:51 AM, David Singer wrote: > On Nov 3, 2013, at 2:41 , Gili wrote: > >> So... the only platform that supports H.264 natively (real-time encoding/decoding) is Windows 8? Any others? > The fact that there currently isn't an API is different from whether the platform can do it (in the iOS case). reverse engineering suggests that FaceTime uses AVC (H.264). > Same difference. Whether you need to implement a new API or simply expose existing an implementation, it takes months for users to upgrade to this new version and for it to actually work as expected (initial releases tend to be unstable or missing features). Furthermore, there is no guarantee that Apple will release said API anytime soon. For these reasons, I stand by my comment that real-time H.264 support does not exist (for developers outside of Apple). Gili From singer@apple.com Mon Nov 4 06:12:41 2013 Return-Path: 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 396FB11E81DC for ; Mon, 4 Nov 2013 06:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 r1W2+IbEciUN for ; Mon, 4 Nov 2013 06:12:34 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) by ietfa.amsl.com (Postfix) with ESMTP id AADFD21E816F for ; Mon, 4 Nov 2013 06:12:31 -0800 (PST) Received: from relay3.asia.apple.com ( [17.82.200.17]) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 2A.57.21841.D4BA7725; Mon, 4 Nov 2013 22:12:29 +0800 (MYT) X-AuditID: 1152fe11-b7f256d000005551-cb-5277ab4d215c Received: from echium.asia.apple.com ( [17.82.200.52]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id F4.C9.26194.D4BA7725; Mon, 4 Nov 2013 22:12:29 +0800 (MYT) Received: from [17.83.34.51] (unknown [17.83.34.51]) by echium.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVQ0021PSSQRX60@echium.asia.apple.com> for rtcweb@ietf.org; Mon, 04 Nov 2013 22:12:29 +0800 (SGT) Content-type: text/plain; charset=iso-8859-1 MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: David Singer In-reply-to: <5277A8E8.2000004@bbs.darktech.org> Date: Mon, 04 Nov 2013 23:12:27 +0900 Content-transfer-encoding: quoted-printable Message-id: <6CA57EC6-2CFD-4527-9A83-5647DB474144@apple.com> References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> <5277A8E8.2000004@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUiGHRCUNd3dXmQweG3ghZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49fyl0wFZzgr/m87xt7AeJm9i5GTQ0LAROLJ2dNMELaYxIV7 69m6GLk4hAR2M0q8vvadEaZo087JLBCJHiaJXds2s0I4i5kkzq1pYQWpYhbQkej9/o0ZxOYV 0JPYuXcbUJyDQ1jAUOLfplCQMJuAqsSDOcfAhnIKGEjMmdICVs4CFJ9/5S4jxBhhie+P77FA 2NoST95dABvDK2AjMWNeMEhYSGAWq8TJR2BbRQRUJG4cuwX1jKzE6XPPwe6UEPjKKnG1eznj BEbhWUium4XkullIVixgZF7FKJ6bmJmjm5lnqJdYnJmol1hQkJOql5yfu4kRHND/BHcwTl1o eIhRgINRiYfXM6k4SIg1say4MvcQowQHs5II7/6V5UFCvCmJlVWpRfnxRaU5qcWHGKU5WJTE eaMdY4KEBNITS1KzU1MLUotgskwcnFINjOIX7/Bn2X3v7rz94ajdOsvq6ZNuxc2YLFK5V7/T WdrpW2vEuYp/UnPL8w9YnWHe8vpsa2Ca/aYpZr86b5jvE+1bk5PpxffbTkkh4Ynk8mXpHmYM Rp3Ot1hVrlpMlUj2/DU9w3F71W2TyhcZL2WOzzjPZjfhiST75+4yYU+ByZ7dnqnKvXdXKrEU ZyQaajEXFScCAJAJacxkAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUiGHTCRNd3dXmQwd1p/BZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49fyl0wFZzgr/m87xt7AeJm9i5GTQ0LARGLTzsksELaYxIV7 69m6GLk4hAR6mCR2bdvMCuEsZpI4t6aFFaSKWUBHovf7N2YQm1dAT2Ln3m1AcQ4OYQFDiX+b QkHCbAKqEg/mHGMEsTkFDCTmTGkBK2cBis+/cpcRYoywxPfH91ggbG2JJ+8ugI3hFbCRmDEv GCQsJDCLVeLkI7CtIgIqEjeO3YK6WVbi9LnnLBMYBWYhOWgWkoNmIZm6gJF5FaNoUWpOYqWx XmJxZqJeYkFBTqpecn7uJkZIAAruYPww1fAQowAHoxIPL9ProiAh1sSy4srcQ4wSHMxKIrz7 V5YHCfGmJFZWpRblxxeV5qQWH2KU5mBREudVPuEQJCSQnliSmp2aWpBaBJNl4uCUamC0/fOM 6+C7Mqm+3nObF9Sqrfvl3tNhvF7ZobNaR1A3+tOVasnrrtMi9mswCqX7fzp4Zb6D0o8vPqtE D96aMYOxWpmpWLP+eYL/tdhNjf0XDk4v0chasW+C+Z5zHoeaA6dPPCs0b9r97ycYWoLux6wW DrqzyS78RBKfDHP6/TC3wGOlN9Ky/z5XYinOSDTUYi4qTgQAO4dwfjwCAAA= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 14:12:41 -0000 On Nov 4, 2013, at 23:02 , cowwoc wrote: > On 04/11/2013 8:51 AM, David Singer wrote: >> On Nov 3, 2013, at 2:41 , Gili wrote: >>=20 >>> So... the only platform that supports H.264 natively (real-time = encoding/decoding) is Windows 8? Any others? >> The fact that there currently isn't an API is different from whether = the platform can do it (in the iOS case). reverse engineering suggests = that FaceTime uses AVC (H.264). >>=20 >=20 > Same difference. No, it really isn't. There is a world of difference between = implementing something and making an API to it public or available. = Good grief. > Whether you need to implement a new API or simply expose existing an = implementation, it takes months for users to upgrade to this new version = and for it to actually work as expected (initial releases tend to be = unstable or missing features). Furthermore, there is no guarantee that = Apple will release said API anytime soon. For these reasons, I stand by = my comment that real-time H.264 support does not exist (for developers = outside of Apple). >=20 > Gili David Singer Multimedia and Software Standards, Apple Inc. From cowwoc@bbs.darktech.org Mon Nov 4 06:18:34 2013 Return-Path: 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 A0EC111E82E2 for ; Mon, 4 Nov 2013 06:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.765 X-Spam-Level: X-Spam-Status: No, score=-4.765 tagged_above=-999 required=5 tests=[AWL=-1.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gqMxktfJ2QJs for ; Mon, 4 Nov 2013 06:18:26 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5480A11E82E4 for ; Mon, 4 Nov 2013 06:18:19 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so12283434iet.18 for ; Mon, 04 Nov 2013 06:18:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YPFFuM9kj0Q50ANhXBhAAzeLNdCxMDNd4sOtW4LScfg=; b=OiuhSpcpIBZu1UrzqBKSCYD7SvnEWIeOuADHHDpeLIBuqjJmle64Pux9W5VGxYq9xJ 0YOIfJ9aNpv5YfILV/nZdKLySXESxGasZdNFYZAjBc5LE1QE8SOik9dDLUCANoy1jTUm TS46e1k9p4cL//hOWofanf3/mbbd5EBhYudAitwyOydN2nhRHgauNM3N+gg/qlK420Ke HQBSn+37hlAe/0TvVxhzEPq/XlE3Puld6s4OBBcLQnaSjnH4zXyUimKC9eu7kmx3k3TY Rmd0w6NzO1u2zSj1RjnwSOR/KeWw1r/PLa+hMCGJU/V3Tz+UiC1jDXLxa80o2ykY0uDf iBBw== X-Gm-Message-State: ALoCoQmXYg1SsyDqJlalkpk5KxG/ptdbKtngC92AY6dinksCF238vct1HbwytdcO08DfHiJ8p7l0 X-Received: by 10.50.16.68 with SMTP id e4mr11940188igd.12.1383574698593; Mon, 04 Nov 2013 06:18:18 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id y10sm2166205igl.4.2013.11.04.06.18.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 06:18:17 -0800 (PST) Message-ID: <5277ACA8.8030008@bbs.darktech.org> Date: Mon, 04 Nov 2013 09:18:16 -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: David Singer References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> <5277A8E8.2000004@bbs.darktech.org> <6CA57EC6-2CFD-4527-9A83-5647DB474144@apple.com> In-Reply-To: <6CA57EC6-2CFD-4527-9A83-5647DB474144@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 14:18:34 -0000 On 04/11/2013 9:12 AM, David Singer wrote: > No, it really isn't. There is a world of difference between > implementing something and making an API to it public or available. > Good grief. Yes, yes, obviously... but my point was that there is a huge hump even after you publish the API. There is still a long ramp-up time until that API becomes publicly available, garners sufficient market-share and is proven to have the necessary stability for production use. We're talking about what exists *today*, not a few months in the future. Today, iOS does not have real-time H.264 support. Gili From jdrosen@jdrosen.net Mon Nov 4 06:58:53 2013 Return-Path: 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 814A621E81A1 for ; Mon, 4 Nov 2013 06:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.876 X-Spam-Level: X-Spam-Status: No, score=-101.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 IPKJPDdfnW5X for ; Mon, 4 Nov 2013 06:58:39 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id DBF7111E823A for ; Mon, 4 Nov 2013 06:58:28 -0800 (PST) Received: from mail-pa0-f44.google.com ([209.85.220.44]:57052) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1VdLbk-0004yj-0r for rtcweb@ietf.org; Mon, 04 Nov 2013 09:58:27 -0500 Received: by mail-pa0-f44.google.com with SMTP id fb1so7047817pad.31 for ; Mon, 04 Nov 2013 06:58:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E540fIV7HC9mxfHI/FZy8/038l3uCj7V1Skjx/GHHsc=; b=Jn1/iFojwn1+gXpVyfk2uTxPy8tZEkGUrhKLfZNZ99aZm8S5s9JVmXeiP6NtQGoWHc HiBsMwZGAMWNLcLRKGnFxu37dpFS5M0Bz4fmR9HDlD5aoil1Xluv40+AYBePFjAm9jRj daLkTBCVPSi364yOdYk/pXjXW2bddWkP4DvIIQlvbKNqg45oHc8Qo9ZhGNEOwRYrtu8i vvn6JnblpmWu6j1mEaFk+JAFOJMrXFgMPEiRbE2tKTedU1D6AtRi4Fn/c4h+A/Bu4XjF rZZaknoPpusySCHzKxPdwXMHt/tsX406Sobq7KC7YNT4a1czIiTceWngWLpk3dHlw6vQ +cmg== MIME-Version: 1.0 X-Received: by 10.66.218.166 with SMTP id ph6mr18357916pac.28.1383577103286; Mon, 04 Nov 2013 06:58:23 -0800 (PST) Received: by 10.70.49.48 with HTTP; Mon, 4 Nov 2013 06:58:23 -0800 (PST) In-Reply-To: <20131102124801.GY3245@audi.shelbyville.oz> References: <20131102124801.GY3245@audi.shelbyville.oz> Date: Mon, 4 Nov 2013 09:58:23 -0500 Message-ID: From: Jonathan Rosenberg To: Ron Content-Type: multipart/alternative; boundary=047d7b5db49ac2cc0404ea5b256c X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 14:58:53 -0000 --047d7b5db49ac2cc0404ea5b256c Content-Type: text/plain; charset=ISO-8859-1 I do not believe that "genuinely free" is the only, nor even the primary, consideration here. I believe we should in general be thinking about what it takes to make webRTC successful. And more than anything else, that means making it a platform that application developers can utilize. If we do our jobs well, we'll have many thousands (hundreds of thousands even) of applications on the web that are enabled with real-time comms and frankly a great many of them will know nothing about codecs or the nuances of MPEG-LA licensing. What are the considerations for making webRTC attractive to them? I assert that the primary thing they'll want is to interconnect their application with some kind of video network or user base that can add value to their application. Let me give an example. Lets say there is a bank, and this bank wants to add the ability for a user to look at their investment portfolio online, click a button, and have a voice/video call with their investment advisor. To build such an app into their existing banking web app, the bank will need webRTC to connect to the voice and video contact center and clients their investment advisors have. Today, all of that is based on H.264. So - I would assert that frankly our primary consideration for webRTC is interoperability. And interoperability as a requirement clearly points to H.264. There are other considerations too. Some of the ones I'd list are: * Interoperates with install base * Widespread deployment * Appeals to the existing set of video application developers - in other words, the biggest consumers of webRTC should be the folks who are already providing video communications applications on the Internet (which by definition none of them do so natively from the browser). Don't we want them to come to the web with webRTC? * Available widely in hardware - especially mobile phones * Broad availability of expertise * Broad availability of toolsets * Multiple codebases and implementations to choose from And none of that has anything to do with IPR or royalties. -Jonathan R. On Sat, Nov 2, 2013 at 8:48 AM, Ron wrote: > On Thu, Oct 31, 2013 at 07:47:31PM +0100, Harald Alvestrand wrote: > > We congratulate Cisco on their intention to make an open source H.264 > codec > > available and usable by the community. We look forward to seeing the > result > > of this effort. > > > > Google still believes that VP8 - a freely available, fully open, > > high-quality video codec that you can download, compile for your > platform, > > include in your binary, distribute and put into production today - is the > > best choice of a Mandatory to Implement video codec for the WebRTC > effort. > > This is my belief also. > > While the Cisco announcement is certainly an interesting approach to trying > to extricate their existing technology investment from the deep quagmire of > encumbrances that currently bind it, the result still falls well short of > not only the ideal, but also the already existing alternative choices that > we have available to us. > > Given the choice between a genuinely Free option, that anyone is free to > improve and distribute however they wish - and a no-cost binary-only option > that is available from only a single supplier, while Happy Hour lasts - the > decision still seems to be something of a no-brainer. Even before you also > consider that the Free Option is not constrained to only its lowest > possible > performance mode in the implementation that is available to people today. > > VP8 still seems like the only obvious and enduring choice for an MTI codec > for WebRTC at present. > > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --047d7b5db49ac2cc0404ea5b256c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I do not believe that "genuinely free" is the on= ly, nor even the primary, consideration here.

I believe = we should in general be thinking about what it takes to make webRTC success= ful. And more than anything else, that means making it a platform that appl= ication developers can utilize. If we do our jobs well, we'll have many= thousands (hundreds of thousands even) of applications on the web that are= enabled with real-time comms and frankly a great many of them will know no= thing about codecs or the nuances of MPEG-LA licensing. What are the consid= erations for making webRTC attractive to them?

I assert that the primary thing they'll want is to = interconnect their application with some kind of video network or user base= that can add value to their application. Let me give an example. Lets say = there is a bank, and this bank wants to add the ability for a user to look = at their investment portfolio online, click a button, and have a voice/vide= o call with their investment advisor. To build such an app into their exist= ing banking web app, the bank will need webRTC to connect to the voice and = video contact center and clients their investment advisors have. Today, all= of that is based on H.264.=A0

So - I would assert that frankly our primary considerat= ion for webRTC is interoperability. And interoperability as a requirement c= learly points to H.264.=A0

There are other conside= rations too. Some of the ones I'd list are:

* Interoperates with install base
* Widesprea= d deployment
* Appeals to the existing set of video application d= evelopers - in other words, the biggest consumers of webRTC should be the f= olks who are already providing video communications applications on the Int= ernet (which by definition none of them do so natively from the browser). D= on't we want them to come to the web with webRTC?
* Available widely in hardware - especially mobile phones
<= div>* Broad availability of expertise
* Broad availability of too= lsets
* Multiple codebases and implementations to choose from

And none of that has anything to do with IPR or royalti= es.=A0

-Jonathan R.



On Sat, Nov 2, 20= 13 at 8:48 AM, Ron <ron@debian.org> wrote:
On T= hu, Oct 31, 2013 at 07:47:31PM +0100, Harald Alvestrand wrote:
> We congratulate Cisco on their intention to make an open source H.264 = codec
> available and usable by the community. We look forward to seeing the r= esult
> of this effort.
>
> Google still believes that VP8 - a freely available, fully open,
> high-quality video codec that you can download, compile for your platf= orm,
> include in your binary, distribute and put into production today - is = the
> best choice of a Mandatory to Implement video codec for the WebRTC eff= ort.

This is my belief also.

While the Cisco announcement is certainly an interesting approach to trying=
to extricate their existing technology investment from the deep quagmire of=
encumbrances that currently bind it, the result still falls well short of not only the ideal, but also the already existing alternative choices that<= br> we have available to us.

Given the choice between a genuinely Free option, that anyone is free to improve and distribute however they wish - and a no-cost binary-only option=
that is available from only a single supplier, while Happy Hour lasts - the=
decision still seems to be something of a no-brainer. =A0Even before you al= so
consider that the Free Option is not constrained to only its lowest possibl= e
performance mode in the implementation that is available to people today.
VP8 still seems like the only obvious and enduring choice for an MTI codec<= br> for WebRTC at present.

=A0 Ron


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb



--
=
--047d7b5db49ac2cc0404ea5b256c-- From randell-ietf@jesup.org Mon Nov 4 08:26:52 2013 Return-Path: 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 52DFA21E817F for ; Mon, 4 Nov 2013 08:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 s9sk7x0yWlZm for ; Mon, 4 Nov 2013 08:26:47 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 298C021E8175 for ; Mon, 4 Nov 2013 08:26:43 -0800 (PST) Received: from [64.114.24.114] (port=53127 helo=[172.16.33.155]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VdMzD-0009nT-9W for rtcweb@ietf.org; Mon, 04 Nov 2013 10:26:43 -0600 Message-ID: <5277CAC2.8000001@jesup.org> Date: Mon, 04 Nov 2013 08:26:42 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20131102124801.GY3245@audi.shelbyville.oz> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070806070402000605020307" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 16:26:52 -0000 This is a multi-part message in MIME format. --------------070806070402000605020307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/4/2013 6:58 AM, Jonathan Rosenberg wrote: > I believe we should in general be thinking about what it takes to make > webRTC successful. And more than anything else, that means making it a > platform that application developers can utilize. If we do our jobs > well, we'll have many thousands (hundreds of thousands even) of > applications on the web that are enabled with real-time comms and > frankly a great many of them will know nothing about codecs or the > nuances of MPEG-LA licensing. What are the considerations for making > webRTC attractive to them? Those are all important considerations. > > I assert that the primary thing they'll want is to interconnect their > application with some kind of video network or user base that can add > value to their application. Let me give an example. Lets say there is > a bank, and this bank wants to add the ability for a user to look at > their investment portfolio online, click a button, and have a > voice/video call with their investment advisor. To build such an app > into their existing banking web app, the bank will need webRTC to > connect to the voice and video contact center and clients their > investment advisors have. Today, all of that is based on H.264. Here you're stretching - most of these don't have an existing system "based on H.264" for this. Some may, but most do not; video access would be something new in any case. And for many of those use-cases, end-to-end WebRTC would be preferable to gatewaying to another system. > > So - I would assert that frankly our primary consideration for webRTC > is interoperability. And interoperability as a requirement clearly > points to H.264. Interop is certainly a consideration and that's where H.264's advantage lies. (H.264's only real technical advantages are interop and the possibility of existing hardware support). > > There are other considerations too. Some of the ones I'd list are: > > * Interoperates with install base > * Widespread deployment Not in of itself a consideration. > * Appeals to the existing set of video application developers - in > other words, the biggest consumers of webRTC should be the folks who > are already providing video communications applications on the > Internet (which by definition none of them do so natively from the > browser). Don't we want them to come to the web with webRTC? This is just the interop argument again. > * Available widely in hardware - especially mobile phones > * Broad availability of expertise I don't see this as a consideration. > * Broad availability of toolsets It's unclear if this has any import or not. > * Multiple codebases and implementations to choose from Only of use to those willing to pay MPEG-LA fees. Everyone else has to use platform OS codecs, HW codecs, or Cisco's plugin. Randell Jesup, Mozilla > > And none of that has anything to do with IPR or royalties. > > -Jonathan R. > > > > On Sat, Nov 2, 2013 at 8:48 AM, Ron > wrote: > > On Thu, Oct 31, 2013 at 07:47:31PM +0100, Harald Alvestrand wrote: > > We congratulate Cisco on their intention to make an open source > H.264 codec > > available and usable by the community. We look forward to seeing > the result > > of this effort. > > > > Google still believes that VP8 - a freely available, fully open, > > high-quality video codec that you can download, compile for your > platform, > > include in your binary, distribute and put into production today > - is the > > best choice of a Mandatory to Implement video codec for the > WebRTC effort. > > This is my belief also. > > While the Cisco announcement is certainly an interesting approach > to trying > to extricate their existing technology investment from the deep > quagmire of > encumbrances that currently bind it, the result still falls well > short of > not only the ideal, but also the already existing alternative > choices that > we have available to us. > > Given the choice between a genuinely Free option, that anyone is > free to > improve and distribute however they wish - and a no-cost > binary-only option > that is available from only a single supplier, while Happy Hour > lasts - the > decision still seems to be something of a no-brainer. Even before > you also > consider that the Free Option is not constrained to only its > lowest possible > performance mode in the implementation that is available to people > today. > > VP8 still seems like the only obvious and enduring choice for an > MTI codec > for WebRTC at present. > > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Randell Jesup randell-ietf@jesup.org --------------070806070402000605020307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/4/2013 6:58 AM, Jonathan Rosenberg wrote:
I believe we should in general be thinking about what it takes to make webRTC successful. And more than anything else, that means making it a platform that application developers can utilize. If we do our jobs well, we'll have many thousands (hundreds of thousands even) of applications on the web that are enabled with real-time comms and frankly a great many of them will know nothing about codecs or the nuances of MPEG-LA licensing. What are the considerations for making webRTC attractive to them?

Those are all important considerations.


I assert that the primary thing they'll want is to interconnect their application with some kind of video network or user base that can add value to their application. Let me give an example. Lets say there is a bank, and this bank wants to add the ability for a user to look at their investment portfolio online, click a button, and have a voice/video call with their investment advisor. To build such an app into their existing banking web app, the bank will need webRTC to connect to the voice and video contact center and clients their investment advisors have. Today, all of that is based on H.264.

Here you're stretching - most of these don't have an existing system "based on H.264" for this.  Some may, but most do not; video access would be something new in any case.  And for many of those use-cases, end-to-end WebRTC would be preferable to gatewaying to another system.


So - I would assert that frankly our primary consideration for webRTC is interoperability. And interoperability as a requirement clearly points to H.264.

Interop is certainly a consideration and that's where H.264's advantage lies.  (H.264's only real technical advantages are interop and the possibility of existing hardware support).


There are other considerations too. Some of the ones I'd list are:

* Interoperates with install base
* Widespread deployment

Not in of itself a consideration.

* Appeals to the existing set of video application developers - in other words, the biggest consumers of webRTC should be the folks who are already providing video communications applications on the Internet (which by definition none of them do so natively from the browser). Don't we want them to come to the web with webRTC?

This is just the interop argument again.

* Available widely in hardware - especially mobile phones
* Broad availability of expertise

I don't see this as a consideration.

* Broad availability of toolsets

It's unclear if this has any import or not.

* Multiple codebases and implementations to choose from

Only of use to those willing to pay MPEG-LA fees.   Everyone else has to use platform OS codecs, HW codecs, or Cisco's plugin.

  Randell Jesup, Mozilla


And none of that has anything to do with IPR or royalties. 

-Jonathan R.



On Sat, Nov 2, 2013 at 8:48 AM, Ron <ron@debian.org> wrote:
On Thu, Oct 31, 2013 at 07:47:31PM +0100, Harald Alvestrand wrote:
> We congratulate Cisco on their intention to make an open source H.264 codec
> available and usable by the community. We look forward to seeing the result
> of this effort.
>
> Google still believes that VP8 - a freely available, fully open,
> high-quality video codec that you can download, compile for your platform,
> include in your binary, distribute and put into production today - is the
> best choice of a Mandatory to Implement video codec for the WebRTC effort.

This is my belief also.

While the Cisco announcement is certainly an interesting approach to trying
to extricate their existing technology investment from the deep quagmire of
encumbrances that currently bind it, the result still falls well short of
not only the ideal, but also the already existing alternative choices that
we have available to us.

Given the choice between a genuinely Free option, that anyone is free to
improve and distribute however they wish - and a no-cost binary-only option
that is available from only a single supplier, while Happy Hour lasts - the
decision still seems to be something of a no-brainer.  Even before you also
consider that the Free Option is not constrained to only its lowest possible
performance mode in the implementation that is available to people today.

VP8 still seems like the only obvious and enduring choice for an MTI codec
for WebRTC at present.

  Ron


_______________________________________________
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



-- 
Randell Jesup
randell-ietf@jesup.org
--------------070806070402000605020307-- From cowwoc@bbs.darktech.org Mon Nov 4 08:35:31 2013 Return-Path: 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 99CF321F9ED1 for ; Mon, 4 Nov 2013 08:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 jAb9DJmAD03z for ; Mon, 4 Nov 2013 08:35:25 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDAD21F9E28 for ; Mon, 4 Nov 2013 08:35:22 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id ar20so12987539iec.12 for ; Mon, 04 Nov 2013 08:35:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=zGzHTTdi36E/y8u4kYYMb2FRhXu8EG2LdBQtGyx3tgE=; b=mNLyEn52r1vHZZvbKCHWjgtwuc5JeYCkNaqohbk2x0juHnkaxg5JFWF8LP118LEdjr Ry/6S1QuvGuw6D3aVCaInlpFfYxkBiReGV/t2iib+7xg1Jk0UnnhkSNeJOu94GkcsJ9x KtgtX5scYc0+if3xBfMJB+rBV+fh/obTAz3WAF4XqLfIhEAh5JNKS5V7ho3HV67U/ZsC QZQ45oMxFjY/+PeV6Kbb8vcUf7EfN/bsasjyHTVw98Qy/wemrkqXJ1PAskE+mScgdqN7 JMhf5fhHtdJ+kkogd/0B2HoUzf/2SCvCEK6Jf0ZLIZBhZskdY516rAIwto3NikIHi3PX V24g== X-Gm-Message-State: ALoCoQkzYqFYLEa95DNSxn00j43U5dElYKhWaAa81o5GmPNME18v7cspacPVQsJmD53Smt8xlkSh X-Received: by 10.50.30.66 with SMTP id q2mr4730766igh.17.1383582921540; Mon, 04 Nov 2013 08:35:21 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id j16sm2854868igf.6.2013.11.04.08.35.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 08:35:20 -0800 (PST) Message-ID: <5277CCC7.7000003@bbs.darktech.org> Date: Mon, 04 Nov 2013 11:35:19 -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: rtcweb@ietf.org References: <20131102124801.GY3245@audi.shelbyville.oz> <5277CAC2.8000001@jesup.org> In-Reply-To: <5277CAC2.8000001@jesup.org> Content-Type: multipart/alternative; boundary="------------070203060806060004050702" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 16:35:32 -0000 This is a multi-part message in MIME format. --------------070203060806060004050702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/11/2013 11:26 AM, Randell Jesup wrote: > Interop is certainly a consideration and that's where H.264's > advantage lies. (H.264's only real technical advantages are interop > and the possibility of existing hardware support). When was Constrained Baseline Profile defined? Based on Wikipedia I'm guessing it was sometime in 2009. If so, how widely is it implemented? We keep on referring to H.264 as a black box that is supported universally, but when you dig into the specifics (specific profile on specific platforms) the story is a lot less clear. Gili --------------070203060806060004050702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 04/11/2013 11:26 AM, Randell Jesup wrote:
Interop is certainly a consideration and that's where H.264's advantage lies.  (H.264's only real technical advantages are interop and the possibility of existing hardware support).

    When was Constrained Baseline Profile defined? Based on Wikipedia I'm guessing it was sometime in 2009. If so, how widely is it implemented?

    We keep on referring to H.264 as a black box that is supported universally, but when you dig into the specifics (specific profile on specific platforms) the story is a lot less clear.

Gili
--------------070203060806060004050702-- From richard@shockey.us Mon Nov 4 08:38:32 2013 Return-Path: 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 D643821E81A2 for ; Mon, 4 Nov 2013 08:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.063 X-Spam-Level: X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 19FnRfKctIhO for ; Mon, 4 Nov 2013 08:38:21 -0800 (PST) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 9CB7321E8173 for ; Mon, 4 Nov 2013 08:38:17 -0800 (PST) Received: (qmail 2736 invoked by uid 0); 4 Nov 2013 16:37:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by qproxy1.mail.unifiedlayer.com with SMTP; 4 Nov 2013 16:37:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=AM7hhYl8jv/hBpXp7YiPmKwZP75qvjNlxWDmhzgRJ+s=; b=VHwnE+PxIK7+Ca97NbJtNxvV7dy9oJ06b/uhqjcDip4Pz2IeuPwFjEzK9rXeRsQgJMAEjTvu4IWA4sZmgadpk4iaXafHgf782NA/mz3kRqztVH7dgaZ6+qn2YCaxeYhO; Received: from [173.79.179.104] (port=53745 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VdNA2-0005jH-O6; Mon, 04 Nov 2013 09:37:55 -0700 From: "Richard Shockey" To: "'Jonathan Rosenberg'" , "'Ron'" References: <20131102124801.GY3245@audi.shelbyville.oz> In-Reply-To: Date: Mon, 4 Nov 2013 11:37:54 -0500 Message-ID: <012501ced97c$37021ae0$a50650a0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0126_01CED952.4E2D9980" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH6pu1RcnTqG2CSG3ZFwm2jX+BNyQIbS425AbBlFiCZn0zk0A== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 16:38:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0126_01CED952.4E2D9980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 Well stated. From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Monday, November 04, 2013 9:58 AM To: Ron Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 I do not believe that "genuinely free" is the only, nor even the primary, consideration here. I believe we should in general be thinking about what it takes to make webRTC successful. And more than anything else, that means making it a platform that application developers can utilize. If we do our jobs well, we'll have many thousands (hundreds of thousands even) of applications on the web that are enabled with real-time comms and frankly a great many of them will know nothing about codecs or the nuances of MPEG-LA licensing. What are the considerations for making webRTC attractive to them? I assert that the primary thing they'll want is to interconnect their application with some kind of video network or user base that can add value to their application. Let me give an example. Lets say there is a bank, and this bank wants to add the ability for a user to look at their investment portfolio online, click a button, and have a voice/video call with their investment advisor. To build such an app into their existing banking web app, the bank will need webRTC to connect to the voice and video contact center and clients their investment advisors have. Today, all of that is based on H.264. So - I would assert that frankly our primary consideration for webRTC is interoperability. And interoperability as a requirement clearly points to H.264. There are other considerations too. Some of the ones I'd list are: * Interoperates with install base * Widespread deployment * Appeals to the existing set of video application developers - in other words, the biggest consumers of webRTC should be the folks who are already providing video communications applications on the Internet (which by definition none of them do so natively from the browser). Don't we want them to come to the web with webRTC? * Available widely in hardware - especially mobile phones * Broad availability of expertise * Broad availability of toolsets * Multiple codebases and implementations to choose from And none of that has anything to do with IPR or royalties. -Jonathan R. On Sat, Nov 2, 2013 at 8:48 AM, Ron > wrote: On Thu, Oct 31, 2013 at 07:47:31PM +0100, Harald Alvestrand wrote: > We congratulate Cisco on their intention to make an open source H.264 codec > available and usable by the community. We look forward to seeing the result > of this effort. > > Google still believes that VP8 - a freely available, fully open, > high-quality video codec that you can download, compile for your platform, > include in your binary, distribute and put into production today - is the > best choice of a Mandatory to Implement video codec for the WebRTC effort. This is my belief also. While the Cisco announcement is certainly an interesting approach to trying to extricate their existing technology investment from the deep quagmire of encumbrances that currently bind it, the result still falls well short of not only the ideal, but also the already existing alternative choices that we have available to us. Given the choice between a genuinely Free option, that anyone is free to improve and distribute however they wish - and a no-cost binary-only option that is available from only a single supplier, while Happy Hour lasts - the decision still seems to be something of a no-brainer. Even before you also consider that the Free Option is not constrained to only its lowest possible performance mode in the implementation that is available to people today. VP8 still seems like the only obvious and enduring choice for an MTI codec for WebRTC at present. Ron _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net ------=_NextPart_000_0126_01CED952.4E2D9980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Well stated.

 

From: = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Jonathan Rosenberg
Sent: Monday, November 04, 2013 9:58 = AM
To: Ron
Cc: rtcweb@ietf.org
Subject: = Re: [rtcweb] Congratuiations on the Cisco announcement - but we still = prefer VP8

 

I do = not believe that "genuinely free" is the only, nor even the = primary, consideration here.

 

I = believe we should in general be thinking about what it takes to make = webRTC successful. And more than anything else, that means making it a = platform that application developers can utilize. If we do our jobs = well, we'll have many thousands (hundreds of thousands even) of = applications on the web that are enabled with real-time comms and = frankly a great many of them will know nothing about codecs or the = nuances of MPEG-LA licensing. What are the considerations for making = webRTC attractive to them?

 

I = assert that the primary thing they'll want is to interconnect their = application with some kind of video network or user base that can add = value to their application. Let me give an example. Lets say there is a = bank, and this bank wants to add the ability for a user to look at their = investment portfolio online, click a button, and have a voice/video call = with their investment advisor. To build such an app into their existing = banking web app, the bank will need webRTC to connect to the voice and = video contact center and clients their investment advisors have. Today, = all of that is based on H.264. 

 

So - I would assert that frankly our primary = consideration for webRTC is interoperability. And interoperability as a = requirement clearly points to H.264. 

 

There are other considerations too. Some of the ones = I'd list are:

 

* = Interoperates with install base

* Widespread deployment

* Appeals to the existing set of video application = developers - in other words, the biggest consumers of webRTC should be = the folks who are already providing video communications applications on = the Internet (which by definition none of them do so natively from the = browser). Don't we want them to come to the web with = webRTC?

* Available widely = in hardware - especially mobile phones

* Broad availability of = expertise

* Broad = availability of toolsets

* = Multiple codebases and implementations to choose = from

 

And none of that has anything to do with IPR or = royalties. 

 

-Jonathan R.

 

 

On Sat, Nov 2, 2013 at 8:48 AM, Ron <ron@debian.org> = wrote:

On Thu, Oct 31, 2013 at 07:47:31PM +0100, = Harald Alvestrand wrote:
> We congratulate Cisco on their = intention to make an open source H.264 codec
> available and = usable by the community. We look forward to seeing the result
> of = this effort.
>
> Google still believes that VP8 - a freely = available, fully open,
> high-quality video codec that you can = download, compile for your platform,
> include in your binary, = distribute and put into production today - is the
> best choice of = a Mandatory to Implement video codec for the WebRTC = effort.

This is my belief = also.

While the Cisco announcement is certainly an interesting = approach to trying
to extricate their existing technology investment = from the deep quagmire of
encumbrances that currently bind it, the = result still falls well short of
not only the ideal, but also the = already existing alternative choices that
we have available to = us.

Given the choice between a genuinely Free option, that anyone = is free to
improve and distribute however they wish - and a no-cost = binary-only option
that is available from only a single supplier, = while Happy Hour lasts - the
decision still seems to be something of = a no-brainer.  Even before you also
consider that the Free = Option is not constrained to only its lowest possible
performance = mode in the implementation that is available to people today.

VP8 = still seems like the only obvious and enduring choice for an MTI = codec
for WebRTC at present.

  = Ron



_______________________________________________=
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



 

-- =

------=_NextPart_000_0126_01CED952.4E2D9980-- From thp@westhawk.co.uk Mon Nov 4 08:11:42 2013 Return-Path: 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 B2B6811E8310 for ; Mon, 4 Nov 2013 08:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=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 1M2kdGe7MWoe for ; Mon, 4 Nov 2013 08:11:36 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id E863411E82FB for ; Mon, 4 Nov 2013 08:10:49 -0800 (PST) Received: (qmail 86909 invoked from network); 4 Nov 2013 16:10:48 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10634 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 4 Nov 2013 16:10:48 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 6D03218A0C8B for ; Mon, 4 Nov 2013 16:10:48 +0000 (GMT) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 3849D18A06CC for ; Mon, 4 Nov 2013 16:10:48 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_14B792FE-27E7-462B-9773-8FF01ACD703E" From: Tim Panton Resent-From: Tim Panton In-Reply-To: Date: Mon, 4 Nov 2013 16:01:22 +0000 Resent-Date: Mon, 4 Nov 2013 16:10:39 +0000 Message-Id: References: <20131102124801.GY3245@audi.shelbyville.oz> Resent-To: rtcweb@ietf.org To: Jonathan Rosenberg X-Mailer: Apple Mail (2.1816) Resent-Message-Id: <20131104161048.3849D18A06CC@zimbra003.verygoodemail.com> X-Mailman-Approved-At: Mon, 04 Nov 2013 09:17:38 -0800 Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 16:11:42 -0000 X-List-Received-Date: Mon, 04 Nov 2013 16:11:42 -0000 --Apple-Mail=_14B792FE-27E7-462B-9773-8FF01ACD703E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 4 Nov 2013, at 14:58, Jonathan Rosenberg wrote: > I do not believe that "genuinely free" is the only, nor even the = primary, consideration here. >=20 > I believe we should in general be thinking about what it takes to make = webRTC successful. And more than anything else, that means making it a = platform that application developers can utilize. If we do our jobs = well, we'll have many thousands (hundreds of thousands even) of = applications on the web that are enabled with real-time comms and = frankly a great many of them will know nothing about codecs or the = nuances of MPEG-LA licensing. What are the considerations for making = webRTC attractive to them? >=20 > I assert that the primary thing they'll want is to interconnect their = application with some kind of video network or user base that can add = value to their application. Let me give an example. Lets say there is a = bank, and this bank wants to add the ability for a user to look at their = investment portfolio online, click a button, and have a voice/video call = with their investment advisor. To build such an app into their existing = banking web app, the bank will need webRTC to connect to the voice and = video contact center and clients their investment advisors have. Today, = all of that is based on H.264.=20 But the scale of such _video_ deployments is so negligible compared to = current VP8 deployment in chrome and firefox as to make that=20 argument unconvincing to me. >=20 > So - I would assert that frankly our primary consideration for webRTC = is interoperability. And interoperability as a requirement clearly = points to H.264.=20 >=20 > There are other considerations too. Some of the ones I'd list are: >=20 > * Interoperates with install base An irrelevant install base, mostly consisting of non-realtime decoders. > * Widespread deployment Deployments that can't interoperate with web RTC because they don't = support the required security features, or don't support APIs that expose realtime H264. > * Appeals to the existing set of video application developers - in = other words, the biggest consumers of webRTC should be the folks who are = already providing video communications applications on the Internet = (which by definition none of them do so natively from the browser). = Don't we want them to come to the web with webRTC? Really? That's quite some assertion. I suppose many web designers did = come from a print-design background initially,=20 but they have rapidly been overcome by webnative developers. > * Available widely in hardware - especially mobile phones But entirely in-accessible to developers- except to the platform = players, giving the platform browser an unfair advantage. > * Broad availability of expertise > * Broad availability of toolsets I'll grant these two, but with the caveat that if VP8 were to be an MTI = in webRTC we could expect toolsets and expertise to grow pretty fast, and probably overtake h264 before long. I say this = because creating such tools in h264-land requires lawyers and licences. The VP8 coders can do their initial work in a = garage in spare time. > * Multiple codebases and implementations to choose from That's the best argument for h264 I've seen so far.=20 >=20 > And none of that has anything to do with IPR or royalties.=20 That's where we disagree. The legal framework shapes every decision in = this space. Open source hackers will be very edgy of messing with h264 for fear of falling off the legal = straight and narrow. T. >=20 > -Jonathan R. >=20 >=20 >=20 > On Sat, Nov 2, 2013 at 8:48 AM, Ron wrote: > On Thu, Oct 31, 2013 at 07:47:31PM +0100, Harald Alvestrand wrote: > > We congratulate Cisco on their intention to make an open source = H.264 codec > > available and usable by the community. We look forward to seeing the = result > > of this effort. > > > > Google still believes that VP8 - a freely available, fully open, > > high-quality video codec that you can download, compile for your = platform, > > include in your binary, distribute and put into production today - = is the > > best choice of a Mandatory to Implement video codec for the WebRTC = effort. >=20 > This is my belief also. >=20 > While the Cisco announcement is certainly an interesting approach to = trying > to extricate their existing technology investment from the deep = quagmire of > encumbrances that currently bind it, the result still falls well short = of > not only the ideal, but also the already existing alternative choices = that > we have available to us. >=20 > Given the choice between a genuinely Free option, that anyone is free = to > improve and distribute however they wish - and a no-cost binary-only = option > that is available from only a single supplier, while Happy Hour lasts = - the > decision still seems to be something of a no-brainer. Even before you = also > consider that the Free Option is not constrained to only its lowest = possible > performance mode in the implementation that is available to people = today. >=20 > VP8 still seems like the only obvious and enduring choice for an MTI = codec > for WebRTC at present. >=20 > Ron >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 >=20 > --=20 > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_14B792FE-27E7-462B-9773-8FF01ACD703E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On 4 Nov 2013, at 14:58, Jonathan = Rosenberg <jdrosen@jdrosen.net> = wrote:

I do not believe that "genuinely free" is = the only, nor even the primary, consideration here.

I = believe we should in general be thinking about what it takes to make = webRTC successful. And more than anything else, that means making it a = platform that application developers can utilize. If we do our jobs = well, we'll have many thousands (hundreds of thousands even) of = applications on the web that are enabled with real-time comms and = frankly a great many of them will know nothing about codecs or the = nuances of MPEG-LA licensing. What are the considerations for making = webRTC attractive to them?

I assert that the primary thing they'll want is to = interconnect their application with some kind of video network or user = base that can add value to their application. Let me give an example. = Lets say there is a bank, and this bank wants to add the ability for a = user to look at their investment portfolio online, click a button, and = have a voice/video call with their investment advisor. To build such an = app into their existing banking web app, the bank will need webRTC to = connect to the voice and video contact center and clients their = investment advisors have. Today, all of that is based on = H.264. 

But the scale = of such _video_ deployments is so negligible compared to current VP8 = deployment in chrome and firefox as to make = that 
argument unconvincing to me.


So - I would assert that frankly our primary = consideration for webRTC is interoperability. And interoperability as a = requirement clearly points to = H.264. 

There are other considerations = too. Some of the ones I'd list are:

* Interoperates with install = base

An irrelevant install = base, mostly consisting of non-realtime decoders.

* Widespread = deployment

Deployments that can't = interoperate with web RTC because they don't support the required = security features, or don't
support APIs that expose realtime = H264.

* Appeals to = the existing set of video application developers - in other words, the = biggest consumers of webRTC should be the folks who are already = providing video communications applications on the Internet (which by = definition none of them do so natively from the browser). Don't we want = them to come to the web with = webRTC?

Really? That's quite = some assertion. I suppose many web designers did come from a = print-design background initially, 
but they have rapidly = been overcome by webnative developers.

* Available widely in hardware - especially mobile = phones

But entirely = in-accessible to developers- except to the platform players, giving the = platform browser an unfair advantage.

* Broad availability of = expertise
* Broad availability of = toolsets

I'll grant these = two, but with the caveat that if VP8 were to be an MTI in webRTC we = could expect toolsets and expertise
to grow pretty fast, and = probably overtake h264 before long. I say this because creating such = tools in h264-land requires
lawyers and licences. The VP8 = coders can do their initial work in a garage in spare = time.

* Multiple = codebases and implementations to choose = from

That's the best argument for = h264 I've seen so far. 


And none of that has anything to do with IPR or = royalties. 

That's = where we disagree. The legal framework shapes every decision in this = space. Open source hackers will
be very edgy of messing with = h264 for fear of falling off the legal straight and = narrow.

T.

-Jonathan = R.



On Sat, Nov 2, 2013 at 8:48 AM, Ron <ron@debian.org> wrote:
On Thu, Oct 31, 2013 at 07:47:31PM = +0100, Harald Alvestrand wrote:
> We congratulate Cisco on their intention to make an open source = H.264 codec
> available and usable by the community. We look forward to seeing = the result
> of this effort.
>
> Google still believes that VP8 - a freely available, fully = open,
> high-quality video codec that you can download, compile for your = platform,
> include in your binary, distribute and put into production today - = is the
> best choice of a Mandatory to Implement video codec for the WebRTC = effort.

This is my belief also.

While the Cisco announcement is certainly an interesting approach to = trying
to extricate their existing technology investment from the deep quagmire = of
encumbrances that currently bind it, the result still falls well short = of
not only the ideal, but also the already existing alternative choices = that
we have available to us.

Given the choice between a genuinely Free option, that anyone is free = to
improve and distribute however they wish - and a no-cost binary-only = option
that is available from only a single supplier, while Happy Hour lasts - = the
decision still seems to be something of a no-brainer.  Even before = you also
consider that the Free Option is not constrained to only its lowest = possible
performance mode in the implementation that is available to people = today.

VP8 still seems like the only obvious and enduring choice for an MTI = codec
for WebRTC at present.

  Ron


_______________________________________________
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

Tim Panton - Web/VoIP consultant and implementor

<= /div>

= --Apple-Mail=_14B792FE-27E7-462B-9773-8FF01ACD703E-- From thp@westhawk.co.uk Mon Nov 4 08:12:03 2013 Return-Path: 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 AE81811E831A for ; Mon, 4 Nov 2013 08:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 3F34bLzZGFAR for ; Mon, 4 Nov 2013 08:11:57 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 5570D11E82AE for ; Mon, 4 Nov 2013 08:11:33 -0800 (PST) Received: (qmail 95605 invoked from network); 4 Nov 2013 16:11:14 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10647 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 4 Nov 2013 16:11:14 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 9B63B18A0C8B for ; Mon, 4 Nov 2013 16:11:14 +0000 (GMT) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7C57818A06CC for ; Mon, 4 Nov 2013 16:11:14 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=us-ascii From: Tim Panton Resent-From: Tim Panton In-Reply-To: <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> Date: Mon, 4 Nov 2013 16:04:22 +0000 Content-Transfer-Encoding: quoted-printable Resent-Date: Mon, 4 Nov 2013 16:11:06 +0000 Message-Id: <5216B691-E8BC-415D-A04A-C03D3A6E49F0@westhawk.co.uk> References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> Resent-To: rtcweb@ietf.org To: David Singer X-Mailer: Apple Mail (2.1816) Resent-Message-Id: <20131104161114.7C57818A06CC@zimbra003.verygoodemail.com> X-Mailman-Approved-At: Mon, 04 Nov 2013 09:17:38 -0800 Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 16:12:03 -0000 On 4 Nov 2013, at 13:51, David Singer wrote: >=20 > On Nov 3, 2013, at 2:41 , Gili wrote: >=20 >>=20 >> So... the only platform that supports H.264 natively (real-time = encoding/decoding) is Windows 8? Any others? >=20 > The fact that there currently isn't an API is different from whether = the platform can do it (in the iOS case). reverse engineering suggests = that FaceTime uses AVC (H.264). Which nicely encapsulates the problem, only the platform owner gets to = use the accelerated hardware, where as the 3rd party developers have to use a software emulation, and = pay for it. That's hardly the open model the IETF espouses. T. >=20 >=20 > David Singer > Multimedia and Software Standards, Apple Inc. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk From andrew.hutton@unify.com Mon Nov 4 09:35:58 2013 Return-Path: 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 4BB1611E82BA for ; Mon, 4 Nov 2013 09:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] 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 ii8Pm6aBlmyq for ; Mon, 4 Nov 2013 09:35:51 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 97E4611E831D for ; Mon, 4 Nov 2013 09:32:35 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 8887723F048E; Mon, 4 Nov 2013 18:32:32 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 18:32:32 +0100 From: "Hutton, Andrew" To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 Thread-Index: AQHO2RUiKJ2ySAuLmEC6pK8t8AzdJpoVPHKw Date: Mon, 4 Nov 2013 17:32:30 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C2D222@MCHP04MSX.global-ad.net> References: <52772073.6090000@jesup.org> In-Reply-To: <52772073.6090000@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 17:35:58 -0000 On: 03 November 2013 20:20 Randell Jesup Wrote: >=20 > IANAPL (I Am Not A Patent Lawyer) - but if you make an image that > includes Cisco's plugin for imaging machines, that would be a violation > of the rules - you would be the one distributing it to end-use > systems.=A0 While you're unlikely to get pinged on it, the company > lawyers may not see it that way, and it might show up flagged in an > audit, and IT guys don't like that. >=20 I also have a concern about this issue and made the same assumption however= yesterday I was told by one of the Cisco experts that as long as it is the= owner of the end devices (i.e. An enterprise) that is doing the distributi= on that would be within the rules. However IANAPL and those that are will n= eed to examine the small print.=20 Maybe this is something that Cisco could clarify in the FAQ's. Andy From elagerway@gmail.com Mon Nov 4 09:38:28 2013 Return-Path: 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 78B1121E80CA for ; Mon, 4 Nov 2013 09:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 1uRcZKAlpG5y for ; Mon, 4 Nov 2013 09:38:25 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AAC8A21E81D9 for ; Mon, 4 Nov 2013 09:37:38 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id t60so2367266wes.16 for ; Mon, 04 Nov 2013 09:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=68TeS7FHISsGcRD37S3a74/SchnTY/MF6t9Wugd3b+o=; b=dTkYbtWGR41POCExw4OdfoRr0leygQyqBM5wxFvLkhQosVKeDbDXOYdpnGIuWThmsb 8mcwNlI7LlGKYKwr6nkkeL/3PMSUWpynqNg2wy7cQDhQ/Q9XjBIQJMNh0QzA3IGnCIdi IP81HWYdkH1Lr+O7Mx2DUeLbMtURopyl6SqVOu9Tu/8V5aWMpsg7FyaTu/yFMbRtppLE OHvdF6pp2bvJVEdaXErreiqu1HjxRJHUuEOk7op/te5LIKvOHtgizFlw01dW+GKYbBeU n37cwfzFS8PnRU1PUgTU2TEtREXi7lrt8VqAdfQzdCjG11/CgzjJstBWAW75SlfhxV88 USWA== MIME-Version: 1.0 X-Received: by 10.194.58.104 with SMTP id p8mr14023714wjq.1.1383586656311; Mon, 04 Nov 2013 09:37:36 -0800 (PST) Sender: elagerway@gmail.com Received: by 10.216.182.200 with HTTP; Mon, 4 Nov 2013 09:37:36 -0800 (PST) In-Reply-To: References: <20131102124801.GY3245@audi.shelbyville.oz> Date: Mon, 4 Nov 2013 09:37:36 -0800 X-Google-Sender-Auth: oXJTyBNgtCPs4fOHyiABNTa119I Message-ID: From: Erik Lagerway To: Tim Panton Content-Type: multipart/alternative; boundary=047d7ba978042a5fcc04ea5d5f71 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 17:38:28 -0000 --047d7ba978042a5fcc04ea5d5f71 Content-Type: text/plain; charset=ISO-8859-1 +1 Tim Not sure if forcing developers to implement a royalty bearing codec is helpful at all, whether they be indie or corporate. Furthermore, it seems that the industry should be allowed to make their own decisions with this in mind. Many will end up supporting both codecs anyways, at least that is what we are hearing from our customers and prospect customers building with WebRTC and Object RTC in mind. *Erik Lagerway | *Hookflash* | 1 (855) Hookflash ext. 2 | Twitter | WebRTC.is Blog * On Mon, Nov 4, 2013 at 8:01 AM, Tim Panton wrote: > > On 4 Nov 2013, at 14:58, Jonathan Rosenberg wrote: > > I do not believe that "genuinely free" is the only, nor even the primary, > consideration here. > > I believe we should in general be thinking about what it takes to make > webRTC successful. And more than anything else, that means making it a > platform that application developers can utilize. If we do our jobs well, > we'll have many thousands (hundreds of thousands even) of applications on > the web that are enabled with real-time comms and frankly a great many of > them will know nothing about codecs or the nuances of MPEG-LA licensing. > What are the considerations for making webRTC attractive to them? > > I assert that the primary thing they'll want is to interconnect their > application with some kind of video network or user base that can add value > to their application. Let me give an example. Lets say there is a bank, and > this bank wants to add the ability for a user to look at their investment > portfolio online, click a button, and have a voice/video call with their > investment advisor. To build such an app into their existing banking web > app, the bank will need webRTC to connect to the voice and video contact > center and clients their investment advisors have. Today, all of that is > based on H.264. > > > But the scale of such _video_ deployments is so negligible compared to > current VP8 deployment in chrome and firefox as to make that > argument unconvincing to me. > > > So - I would assert that frankly our primary consideration for webRTC is > interoperability. And interoperability as a requirement clearly points to > H.264. > > There are other considerations too. Some of the ones I'd list are: > > * Interoperates with install base > > > An irrelevant install base, mostly consisting of non-realtime decoders. > > * Widespread deployment > > > Deployments that can't interoperate with web RTC because they don't > support the required security features, or don't > support APIs that expose realtime H264. > > * Appeals to the existing set of video application developers - in other > words, the biggest consumers of webRTC should be the folks who are already > providing video communications applications on the Internet (which by > definition none of them do so natively from the browser). Don't we want > them to come to the web with webRTC? > > > Really? That's quite some assertion. I suppose many web designers did come > from a print-design background initially, > but they have rapidly been overcome by webnative developers. > > * Available widely in hardware - especially mobile phones > > > But entirely in-accessible to developers- except to the platform players, > giving the platform browser an unfair advantage. > > * Broad availability of expertise > * Broad availability of toolsets > > > I'll grant these two, but with the caveat that if VP8 were to be an MTI in > webRTC we could expect toolsets and expertise > to grow pretty fast, and probably overtake h264 before long. I say this > because creating such tools in h264-land requires > lawyers and licences. The VP8 coders can do their initial work in a garage > in spare time. > > * Multiple codebases and implementations to choose from > > > That's the best argument for h264 I've seen so far. > > > And none of that has anything to do with IPR or royalties. > > > That's where we disagree. The legal framework shapes every decision in > this space. Open source hackers will > be very edgy of messing with h264 for fear of falling off the legal > straight and narrow. > > T. > > > -Jonathan R. > > > > On Sat, Nov 2, 2013 at 8:48 AM, Ron wrote: > >> On Thu, Oct 31, 2013 at 07:47:31PM +0100, Harald Alvestrand wrote: >> > We congratulate Cisco on their intention to make an open source H.264 >> codec >> > available and usable by the community. We look forward to seeing the >> result >> > of this effort. >> > >> > Google still believes that VP8 - a freely available, fully open, >> > high-quality video codec that you can download, compile for your >> platform, >> > include in your binary, distribute and put into production today - is >> the >> > best choice of a Mandatory to Implement video codec for the WebRTC >> effort. >> >> This is my belief also. >> >> While the Cisco announcement is certainly an interesting approach to >> trying >> to extricate their existing technology investment from the deep quagmire >> of >> encumbrances that currently bind it, the result still falls well short of >> not only the ideal, but also the already existing alternative choices that >> we have available to us. >> >> Given the choice between a genuinely Free option, that anyone is free to >> improve and distribute however they wish - and a no-cost binary-only >> option >> that is available from only a single supplier, while Happy Hour lasts - >> the >> decision still seems to be something of a no-brainer. Even before you >> also >> consider that the Free Option is not constrained to only its lowest >> possible >> performance mode in the implementation that is available to people today. >> >> VP8 still seems like the only obvious and enduring choice for an MTI codec >> for WebRTC at present. >> >> Ron >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > > -- > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > Tim Panton - Web/VoIP consultant and implementor > www.westhawk.co.uk > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7ba978042a5fcc04ea5d5f71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 Tim

Not sure if forcing developers t= o implement a royalty bearing codec is helpful at all, whether they be indi= e or corporate.=A0

Furthermore, it seems that the = industry should be allowed to make their own decisions with this in mind. = =A0Many will end up supporting both codecs anyways, at least that is what w= e are hearing from our customers and prospect customers building with WebRT= C and Object RTC in mind.


Erik Lagerway=A0|=A0<= span style=3D"font-size:small">Hookflash<= /span>=A0| 1 (855)=A0Hookflash ext. 2 |=A0Twitter=A0= |=A0WebRTC.is Blog=A0 <= /span>


On Mon, Nov 4, 2013 at 8:01 AM, Tim Pant= on <thp@westhawk.co.uk> wrote:
On 4 Nov 2013, at 14:58, Jonathan Rosenberg &l= t;jdrosen@jdrosen.= net> wrote:

I do not believe that "= genuinely free" is the only, nor even the primary, consideration here.=

I believe we should in general be thinking about what i= t takes to make webRTC successful. And more than anything else, that means = making it a platform that application developers can utilize. If we do our = jobs well, we'll have many thousands (hundreds of thousands even) of ap= plications on the web that are enabled with real-time comms and frankly a g= reat many of them will know nothing about codecs or the nuances of MPEG-LA = licensing. What are the considerations for making webRTC attractive to them= ?

I assert that the primary thing they'll want is to = interconnect their application with some kind of video network or user base= that can add value to their application. Let me give an example. Lets say = there is a bank, and this bank wants to add the ability for a user to look = at their investment portfolio online, click a button, and have a voice/vide= o call with their investment advisor. To build such an app into their exist= ing banking web app, the bank will need webRTC to connect to the voice and = video contact center and clients their investment advisors have. Today, all= of that is based on H.264.=A0

But the scale of such _video_ = deployments is so negligible compared to current VP8 deployment in chrome a= nd firefox as to make that=A0
argument unconvincing to me.


So - I would assert that frankly our primary considerat= ion for webRTC is interoperability. And interoperability as a requirement c= learly points to H.264.=A0

There are other conside= rations too. Some of the ones I'd list are:

* Interoperates with install base

An irrelevant install base, mostly consisting = of non-realtime decoders.

* Widespread deployment

Deployments t= hat can't interoperate with web RTC because they don't support the = required security features, or don't
support APIs that expose= realtime H264.

* Appeals = to the existing set of video application developers - in other words, the b= iggest consumers of webRTC should be the folks who are already providing vi= deo communications applications on the Internet (which by definition none o= f them do so natively from the browser). Don't we want them to come to = the web with webRTC?

Really? That's quite some = assertion. I suppose many web designers did come from a print-design backgr= ound initially,=A0
but they have rapidly been overcome by webnati= ve developers.

* Available widely in hardware - especially mobile phones
<= /div>

But entirely in-accessible to d= evelopers- except to the platform players, giving the platform browser an u= nfair advantage.

* Bro= ad availability of expertise
* Broad availability of toolsets

I'll grant these two, bu= t with the caveat that if VP8 were to be an MTI in webRTC we could expect t= oolsets and expertise
to grow pretty fast, and probably overtake h264 before long. I say thi= s because creating such tools in h264-land requires
lawyers and l= icences. The VP8 coders can do their initial work in a garage in spare time= .

* Multiple= codebases and implementations to choose from

That's the best argument for h264 I've seen so far.= =A0


And none of that has anything to do with IPR or royalti= es.=A0

That's where w= e disagree. The legal framework shapes every decision in this space. Open s= ource hackers will
be very edgy of messing with h264 for fear of falling off the legal st= raight and narrow.

T.


-Jonathan R.
<= div>


On Sat, Nov 2, 2013 at 8:48 AM, Ron <ron@debian.org> wrote:<= br>
On Thu, Oct 31, 2013 at 07:47:31PM= +0100, Harald Alvestrand wrote:
> We congratulate Cisco on their intention to make an open source H.264 = codec
> available and usable by the community. We look forward to seeing the r= esult
> of this effort.
>
> Google still believes that VP8 - a freely available, fully open,
> high-quality video codec that you can download, compile for your platf= orm,
> include in your binary, distribute and put into production today - is = the
> best choice of a Mandatory to Implement video codec for the WebRTC eff= ort.

This is my belief also.

While the Cisco announcement is certainly an interesting approach to trying=
to extricate their existing technology investment from the deep quagmire of=
encumbrances that currently bind it, the result still falls well short of not only the ideal, but also the already existing alternative choices that<= br> we have available to us.

Given the choice between a genuinely Free option, that anyone is free to improve and distribute however they wish - and a no-cost binary-only option=
that is available from only a single supplier, while Happy Hour lasts - the=
decision still seems to be something of a no-brainer. =A0Even before you al= so
consider that the Free Option is not constrained to only its lowest possibl= e
performance mode in the implementation that is available to people today.
VP8 still seems like the only obvious and enduring choice for an MTI codec<= br> for WebRTC at present.

=A0 Ron


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb



--
=
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

Tim Panton - Web/VoIP consultant and implementor
<= br>



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--047d7ba978042a5fcc04ea5d5f71-- From partha@parthasarathi.co.in Mon Nov 4 09:45:15 2013 Return-Path: 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 EE2A021E825E for ; Mon, 4 Nov 2013 09:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 UMPVL1kt3yNx for ; Mon, 4 Nov 2013 09:45:09 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9C13321E824B for ; Mon, 4 Nov 2013 09:44:39 -0800 (PST) Received: from userPC (unknown [122.179.36.6]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id D5FBD19082AF; Mon, 4 Nov 2013 17:44:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1383587076; bh=Nc4Pid9xGDcrw4aJ5l0ZCnzMb5/2dymFoKObNuOyiNU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=nESrTmyS32um1p0d0F8Zyf53PDuZs7cZMSFMOHLxCz8vub8K/bTt8/bf3iK88yMkI PGU9urf9MRpCW5yPeTcQKCqBzdBKN3d8zwo50ljCcNR6E+vvAGBcvA4EWMwgkzppMP klDBeQ7lOJLgrNtuPGxwiAXl+EFdsSY/w2fa3bkQ= From: "Parthasarathi R" To: "'Justin Uberti'" , "'Paul Kyzivat'" References: <527420FC.3070805@alum.mit.edu> In-Reply-To: Date: Mon, 4 Nov 2013 23:13:34 +0530 Message-ID: <00b901ced985$85594160$900bc420$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01CED9B3.9F117D60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7ZKu97RkimDg8HS1yf9W6X1FrNbAAV/t7w Content-Language: en-us X-CTCH-RefID: str=0001.0A020208.5277DD04.0149, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.100 X-CTCH-Rules: SUBJECT_NEEDS_ENCODING, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 17:45:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BA_01CED9B3.9F117D60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin, =20 As the signaling is not defined in WebRTC, it is not possible to assume = that the remote side capabilities will not change between browser to = browser scenario as well. RTCWeb Server shall transfer the session = using RE-INVITE equivalent functionality.=20 =20 Re-INVITE without offer is a power tool in SIP for getting the = capabilities before selecting the final codec. It shall be used to = initiate the offer from the remote side. One of the INIVTE/Re-INVITE = without offer usecase in WebRTC shall be used to get ICE-TCP candidate = from the browser wherein the incoming TCP connection is forbidden by the = firewall. =20 Thanks Partha =20 =20 =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Justin Uberti Sent: Monday, November 04, 2013 12:26 PM To: Paul Kyzivat Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers =20 =20 =20 On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat = wrote: Section 5.2.2 (Subsequent Offers) says: o The m=3D line and corresponding "a=3Drtpmap" and "a=3Dfmtp" lines = MUST only include codecs present in the remote description. o The RTP header extensions MUST only include those that are present in the remote description. o The RTCP feedback extensions MUST only include those that are present in the remote description. o The "a=3Drtcp-mux" line MUST only be added if present in the = remote description. o The "a=3Drtcp-rsize" line MUST only be added if present in the remote description. Including only codecs that were present in the prior answer is a bad = idea. It doesn't play well with SIP. There is no harm in continuing to = include all the codecs you support. And it keeps options open for = changing codecs later. The same is true for most other things that are being restricted based = on what was in the last answer. (But I won't say that with certainty = without checking the semantics of each one.) For further info, see RFC 6337, especially section 5.1. =20 According to section 5.2.5, it seems that this is only the cases for = offers triggered by offerless reINVITEs. I don't think we want to be = re-allocating and negotiating codecs every time we want to make a change = to the session descriptions in use.=20 =20 Generally I think we should consider that the capabilities of the remote = side will not change unexpectedly during the call, and so full = renegotiation is not needed with each reINVITE. If full renegotiation is = needed, use an INVITE-with-replaces, as Cullen has suggested. This = avoids complicated cases like having to unBUNDLE in mid-call, or = re-reserve codecs that are unlikely to be used. =20 =20 Thanks, Paul _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------=_NextPart_000_00BA_01CED9B3.9F117D60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Justin,

 

As the signaling is not defined in WebRTC, it is not = possible to assume that the remote side capabilities will not change between browser = to browser scenario as well.=C2=A0 RTCWeb Server shall transfer the session = using RE-INVITE equivalent functionality.

 

Re-INVITE without offer is a power tool in SIP for = getting the capabilities before selecting the final codec. It shall be used to = initiate the offer from the remote side. One of the INIVTE/Re-INVITE without offer = usecase in WebRTC shall be used to get ICE-TCP candidate from the browser = wherein the incoming TCP connection is forbidden by the = firewall.

 

Thanks

Partha

 

 

 

From:= rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Justin Uberti
Sent: Monday, November 04, 2013 12:26 PM
To: Paul Kyzivat
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent = Offers

 

 

 

On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Section 5.2.2 (Subsequent Offers) says:

   o  The m=3D line and corresponding = "a=3Drtpmap" and "a=3Dfmtp" lines MUST
      only include codecs present in the remote = description.

   o  The RTP header extensions MUST only include those = that are present
      in the remote description.

   o  The RTCP feedback extensions MUST only include = those that are
      present in the remote description.

   o  The "a=3Drtcp-mux" line MUST only be = added if present in the remote
      description.

   o  The "a=3Drtcp-rsize" line MUST only be = added if present in the
      remote description.

Including only codecs that were present in the prior answer is a bad = idea. It doesn't play well with SIP. There is no harm in continuing to include = all the codecs you support. And it keeps options open for changing codecs = later.

The same is true for most other things that are being restricted based = on what was in the last answer. (But I won't say that with certainty without = checking the semantics of each one.)

For further info, see RFC 6337, especially section 5.1.

 

According to section 5.2.5, it seems that this is = only the cases for offers triggered by offerless reINVITEs. I don't think we want = to be re-allocating and negotiating codecs every time we want to make a change = to the session descriptions in use. 

 

Generally I think we should consider that the = capabilities of the remote side will not change unexpectedly during the call, and so = full renegotiation is not needed with each reINVITE. If full renegotiation is needed, use an INVITE-with-replaces, as Cullen has suggested. This = avoids complicated cases like having to unBUNDLE in mid-call, or re-reserve = codecs that are unlikely to be used.

 

 


        Thanks,
        Paul
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 

------=_NextPart_000_00BA_01CED9B3.9F117D60-- From mzanaty@cisco.com Mon Nov 4 09:47:52 2013 Return-Path: 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 5700C21E8255 for ; Mon, 4 Nov 2013 09:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Dt1bo7kwZyCM for ; Mon, 4 Nov 2013 09:47:45 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD7D21E8250 for ; Mon, 4 Nov 2013 09:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5045; q=dns/txt; s=iport; t=1383587245; x=1384796845; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=UNQKxGINIZUFnGKlQ1xi+sxkBksamcAohBx1zJUzfQQ=; b=PWEqkHpgWHO/PYCjI4g+fbBrjICzBaumZLHlTllQuylS9wRraquhVvnJ xKoj5MKGHRsmDtF6BIV7qosJvuRWHeA3tGHeFBygV0924aRe1T3EEMZAM yHjxzRMLFI48+/O9cV3Z9loqHFMQ5GIikP6mwAKQ7E/meN9MZ45A472Bw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFACLdd1KtJV2Z/2dsb2JhbABZgkNEgQu/PoEpFnSCLIELAQgEOzkUEQIEARKIAb5Uj1+ELgOYCpIJgWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,633,1378857600"; d="scan'208,217";a="280492201" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 04 Nov 2013 17:47:23 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA4HlNG6006521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 17:47:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 11:47:23 -0600 From: "Mo Zanaty (mzanaty)" To: cowwoc , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 Thread-Index: AQHO2YXqtuYmm9Hvxk6LyuM6V4y7Jg== Date: Mon, 4 Nov 2013 17:47:22 +0000 Message-ID: In-Reply-To: <5277CCC7.7000003@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.254.33] Content-Type: multipart/alternative; boundary="_000_CE9D3DBB1B371mzanatyciscocom_" MIME-Version: 1.0 Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 17:47:52 -0000 --_000_CE9D3DBB1B371mzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Baseline Profile was in the original 2003 version of H.264, along with the = optional constraint (constraint_set1_flag) to exclude some rather exotic er= ror resilience tools (ASO/FMO/RS). This constrained Baseline Profile was un= iversally deployed. The unconstrained Baseline Profile was not as widely de= ployed. The 2009 version merely acknowledged industry practice by giving it= an official name, Constrained Baseline Profile, which is easier to say tha= n Baseline Profile with constraint_set1_flag=3D1. There were no changes in = the bitstream or tools, just an easier official name. To be fair, H.264 interop has not been a painless endeavor over the years, = in part due to multiple profiles. Implementers have worked through many iss= ues to achieve the nearly universal interop enjoyed today across hundreds o= r thousands of vendors and implementations. VP8 should have an easier time,= since it doesn=92t have multiple profiles, packetization modes, etc. But V= P8 will go through some of the same pains when many implementations flouris= h (software and hardware). The pain is not felt yet since there are only tw= o vendors (Google and Mozilla) in close contact using a shared software imp= lementation. Mo On 11/4/13, 11:35 AM, cowwoc > wrote: On 04/11/2013 11:26 AM, Randell Jesup wrote: Interop is certainly a consideration and that's where H.264's advantage lie= s. (H.264's only real technical advantages are interop and the possibility= of existing hardware support). When was Constrained Baseline Profile defined? Based on Wikipedia I'm g= uessing it was sometime in 2009. If so, how widely is it implemented? We keep on referring to H.264 as a black box that is supported universa= lly, but when you dig into the specifics (specific profile on specific plat= forms) the story is a lot less clear. Gili --_000_CE9D3DBB1B371mzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <993B98CF034CF948AF98B456DA96F986@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Baseline Profile was in the original 2003 version of H.264, along with= the optional constraint (constraint_set1_flag) to exclude some rather exot= ic error resilience tools (ASO/FMO/RS). This constrained Baseline Profile w= as universally deployed. The unconstrained Baseline Profile was not as widely deployed. The 2009 version merely ackno= wledged industry practice by giving it an official name, Constrained Baseli= ne Profile, which is easier to say than Baseline Profile with constraint_se= t1_flag=3D1. There were no changes in the bitstream or tools, just an easier official name.

To be fair, H.264 interop has not been a painless endeavor over the ye= ars, in part due to multiple profiles. Implementers have worked through man= y issues to achieve the nearly universal interop enjoyed today across hundr= eds or thousands of vendors and implementations. VP8 should have an easier time, since it doesn=92t have m= ultiple profiles, packetization modes, etc. But VP8 will go through some of= the same pains when many implementations flourish (software and hardware).= The pain is not felt yet since there are only two vendors (Google and Mozilla) in close contact using a shared = software implementation.

Mo


On 11/4/13, 11:35 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

On 04/11/2013 11:26 AM, Randell Jesup wrote:=
Interop i= s certainly a consideration and that's where H.264's advantage lies.  = (H.264's only real technical advantages are interop and the possibility of = existing hardware support).

    When was Constrained Baseline Profile defined? Based on = Wikipedia I'm guessing it was sometime in 2009. If so, how widely is it imp= lemented?

    We keep on referring to H.264 as a black box that is sup= ported universally, but when you dig into the specifics (specific profile o= n specific platforms) the story is a lot less clear.

Gili
 --_000_CE9D3DBB1B371mzanatyciscocom_-- From basilgohar@librevideo.org Mon Nov 4 09:49:17 2013 Return-Path: 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 8AB6F21F9E26 for ; Mon, 4 Nov 2013 09:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 t4iAnDvf+rR3 for ; Mon, 4 Nov 2013 09:49:11 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id B958221E8267 for ; Mon, 4 Nov 2013 09:49:01 -0800 (PST) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 6C1E765A863 for ; Mon, 4 Nov 2013 12:48:55 -0500 (EST) Message-ID: <5277DE04.5070004@librevideo.org> Date: Mon, 04 Nov 2013 12:48:52 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52772073.6090000@jesup.org> <9F33F40F6F2CD847824537F3C4E37DDF17C2D222@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C2D222@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 17:49:17 -0000 On 11/04/2013 12:32 PM, Hutton, Andrew wrote: > On: 03 November 2013 20:20 Randell Jesup Wrote: > > >> >> IANAPL (I Am Not A Patent Lawyer) - but if you make an image that >> includes Cisco's plugin for imaging machines, that would be a violation >> of the rules - you would be the one distributing it to end-use >> systems. While you're unlikely to get pinged on it, the company >> lawyers may not see it that way, and it might show up flagged in an >> audit, and IT guys don't like that. >> > > I also have a concern about this issue and made the same assumption however yesterday I was told by one of the Cisco experts that as long as it is the owner of the end devices (i.e. An enterprise) that is doing the distribution that would be within the rules. However IANAPL and those that are will need to examine the small print. > > Maybe this is something that Cisco could clarify in the FAQ's. > > Andy The problem is that, while on the surface Cisco's offer seems to solve a major problem, in fact it poses so many unanswered questions or unclear situations that it may not be a net gain. No doubt, we have our wonderful Western patent system to blame for this, but that is what we have to navigate around. If things are still muddy after this offer, then we likely have gained very little, as that was the main complaint against VP8 from the beginning. -- Libre Video http://librevideo.org From emcho@sip-communicator.org Mon Nov 4 09:53:42 2013 Return-Path: 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 3549421E80BC for ; Mon, 4 Nov 2013 09:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 12xbH6QM7bwi for ; Mon, 4 Nov 2013 09:53:35 -0800 (PST) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4B00D11E8147 for ; Mon, 4 Nov 2013 09:52:52 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id r10so6944836pdi.4 for ; Mon, 04 Nov 2013 09:52:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3H8Z+l/LPErPy0BliVGOLumYQ+bEZOpCeokr/mfjHV0=; b=T5mE7aEX0yNPUI+Hyo27yRWZBA/DmS3vfp7yMYKxwoU+lAcooelxOBdL2VwZ6rGrNB 300xuPpQ43iajrL7EMFDvPPLbRcbnUh6i5CNAGVXXJntw1+iFRSgCec+FTyjuPYsLBTt iuD0bkq2HIpQZVx+fNxPLNABLrME4o9m79QJM0D4+9/8WE5PVvb54ASN7X6YbCKNN508 G8BaiQq011/+cQ9AaVDUfTmZhEEhpEiczhWxGd+ejlxjPyXbI32YW9gcsb13EQ+ttXOo biRHkTttrAJdN2KB+7GFxoLaTGk3TBwuoCVxKAj2Kx8v61IR7bILkwEfgjaVrtzZD8BE 48qw== X-Gm-Message-State: ALoCoQkxN59+2woTAaD0i0A2A7RF4CSqC3lwrs8Hp0hWqB157Q2QCLf36ddMI8DLLW8/En97+c38 X-Received: by 10.66.171.13 with SMTP id aq13mr18793554pac.30.1383587561944; Mon, 04 Nov 2013 09:52:41 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [2607:f8b0:400e:c03::234]) by mx.google.com with ESMTPSA id ed3sm29450418pbc.6.2013.11.04.09.52.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 09:52:41 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id bj1so7165897pad.25 for ; Mon, 04 Nov 2013 09:52:41 -0800 (PST) X-Received: by 10.66.154.1 with SMTP id vk1mr18981579pab.85.1383587561123; Mon, 04 Nov 2013 09:52:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Mon, 4 Nov 2013 09:52:21 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C2D222@MCHP04MSX.global-ad.net> References: <52772073.6090000@jesup.org> <9F33F40F6F2CD847824537F3C4E37DDF17C2D222@MCHP04MSX.global-ad.net> From: Emil Ivov Date: Mon, 4 Nov 2013 18:52:21 +0100 Message-ID: To: "Hutton, Andrew" Content-Type: text/plain; charset=ISO-8859-1 Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 17:53:42 -0000 On Mon, Nov 4, 2013 at 6:32 PM, Hutton, Andrew wrote: > On: 03 November 2013 20:20 Randell Jesup Wrote: > > >> >> IANAPL (I Am Not A Patent Lawyer) - but if you make an image that >> includes Cisco's plugin for imaging machines, that would be a violation >> of the rules - you would be the one distributing it to end-use >> systems. While you're unlikely to get pinged on it, the company >> lawyers may not see it that way, and it might show up flagged in an >> audit, and IT guys don't like that. >> > > I also have a concern about this issue and made the same assumption > however yesterday I was told by one of the Cisco experts that as long > as it is the owner of the end devices (i.e. An enterprise) that is doing > the distribution that would be within the rules. So as long as no one subcontracts IT maintenance, we should be fine ;). -- https://jitsi.org From basilgohar@librevideo.org Mon Nov 4 09:54:26 2013 Return-Path: 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 7833021E8248 for ; Mon, 4 Nov 2013 09:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 DXox4d+bFkkU for ; Mon, 4 Nov 2013 09:54:04 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4776511E8235 for ; Mon, 4 Nov 2013 09:53:36 -0800 (PST) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id B9F8765A0FF for ; Mon, 4 Nov 2013 12:53:34 -0500 (EST) Message-ID: <5277DF1C.8080207@librevideo.org> Date: Mon, 04 Nov 2013 12:53:32 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 17:54:27 -0000 On 11/04/2013 12:47 PM, Mo Zanaty (mzanaty) wrote: > > To be fair, H.264 interop has not been a painless endeavor over the > years, in part due to multiple profiles. Implementers have worked > through many issues to achieve the nearly universal interop enjoyed > today across hundreds or thousands of vendors and implementations. VP8 > should have an easier time, since it doesn’t have multiple profiles, > packetization modes, etc. But VP8 will go through some of the same pains > when many implementations flourish (software and hardware). The pain is > not felt yet since there are only two vendors (Google and Mozilla) in > close contact using a shared software implementation. > > Mo To be even more fair, in fact, there are more than just Google and Mozilla on the VP8 playing field. The ffmpeg/libav community(-ies?) have made a successful implementation of a vp8 decoder (ffvp8) that is also widely deployed and, to the best of my knowledge, has no known major problems. There was also the xvp8 project which, while I believe stalled, was not due to incompatibilities or challenges, just lack of energy for that project and motivation. And there have been many hardware VP8 implementations in silicon across multiple vendors no less, both for encoding and decoding. And yes, while H.264 no doubt has a larger market segment, to say Google and Mozilla are the only two players would not be accurate, and the design and spec have shown they can be implemented widely and without as much pain as the, arguably much more complex, (full) H.264 spec. -- Libre Video http://librevideo.org From vsingh.ietf@gmail.com Mon Nov 4 10:07:02 2013 Return-Path: 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 2B51511E8117; Mon, 4 Nov 2013 10:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, 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 qw9MiKPBSkM1; Mon, 4 Nov 2013 10:06:59 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1700C11E812B; Mon, 4 Nov 2013 10:06:56 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id e14so12652268iej.39 for ; Mon, 04 Nov 2013 10:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=qn3hlVoSN94zfRmOH4bDPTixPJF0CA4SbpCBAvhvEeo=; b=JAV5cx6mCjQZPz0bnk4g4YFx7bZ9H25/6CEz61ri12m98rZovljen5H4TFVRXjp9Kq XKf8CM9iDTTtN8LImODnWLQlIqQXKoGSmAT5we+94k4u0yc4ztG+NjiMaa9pzUeDlmJn KdBQMGI8KEEDhnfBpNv+zA5ReHY7IJTR+cMeznDa28KUrbRR4vZu1zNZX4e4UGHjRhqz IiRxDFLfTYMmF8XYCj/fVANBuR1iHxhUtUxxzO97B8kxMjIshLB1J0CfKvNFCKgD+BrQ UrkGNj+mKz5SzXq6g2pF5bZzgbAaB9am+q2ysXJux5D8M0ZOzITICtKDIWhoJd8tQ7VK y2eQ== X-Received: by 10.50.39.51 with SMTP id m19mr12679666igk.51.1383588414417; Mon, 04 Nov 2013 10:06:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Mon, 4 Nov 2013 10:06:34 -0800 (PST) In-Reply-To: References: From: Varun Singh Date: Mon, 4 Nov 2013 10:06:34 -0800 Message-ID: To: "rtcweb@ietf.org" , "avt@ietf.org" , rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 18:07:02 -0000 Hi, Slideset from yesterday's meeting are available at: https://speakerdeck.com/vr000m/media-traffic-generator-discussion Note takers, if you could send the notes to me, I can then process and post them to the mailing lists. Cheers, Varun On Wed, Oct 30, 2013 at 6:49 AM, Varun Singh wrote: > Hi all, > > Practical details for the meeting on **RMCAT Traffic models** > > Date: 03.11. 2013 > Time: 12:30 to 14:30. > Assigned Room: Regency A > > Cheers, > Varun > > On Sun, Oct 27, 2013 at 12:57 PM, Varun Singh wrote: >> Hi all, >> >> In RMCAT WG there has been discussion surrounding the use >> of a media traffic generator and to facilitate discussion, >> RMCAT is hosting a side meeting on Sunday, 03 November >> at 1300-1500. I suppose the room details will be announced >> shortly. >> >> Below is a list of questions that will help design or choose >> an appropriate traffic generator for Interactive multimedia traffic. >> The list is an initial set and mainly to foster discussion both >> on the mailing list and at the meeting. >> >> Mirja and Lars are not available that day, hence on their behalf, >> the meeting is hosted by Colin and I . >> >> Cheers, >> Varun >> --- >> >> Traffic generator: to model the intrinsic variability of video: >> >> - what target bit rates can be achieved? (max?, min?) >> - how much variability in media bit rate for a given target bit rate >> - how to model motion? capturing high motion leads to bursty video >> (higher than target bit rate), but by how much? can this even be done? >> >> Traffic generator: on responsiveness to a new target bitrate: >> >> - how quickly can the codec generate a lower bit rate? >> - immediately? does this depend on the new or requested bit rate? >> - what is immediately? is it next frame or a few frames later, until then >> does it generates at the current rate? >> - if not immediately, what bitrates (and duration) will it generate before >> meeting the target bitrate. >> >> >> - how quickly can the codec generate a higher bit rate? >> - immediately in the next frame? does this also depend on the new >> or requested bit rate? >> - not immediately but in steps of intermediate bitrates, i.e., intermediate >> bitrate for a short duration then an increase in step, repeating until >> reaching the target bit rate. >> >> - If the target bit rate is achieved in steps, can they be announced to the >> congestion controller, i.e., the congestion controller knows the ramp up >> curve to meet the target bit rate. >> >> - If the media bit rate has not yet reached the requested target bit rate and >> the congestion control requests a new target bit rate, how does the codec >> respond? >> >> Application design related: >> - should the congestion control be able to change the frame rate (video) or >> packetization time (audio) or is this something that the application controls. >> - should the congestion control be able to change video resolution? >> - should error-repair: NACKs, FEC be considered part of congestion control or >> outside it, i.e., it is something that the application does and not >> congestion control >> - If FEC is controlled by the congestion control, how quickly can the sending >> rate be adapted by reducing/adding redundancy (FEC)? is something link this >> done? Does this makes sense at all? >> - Apart from loss and RTT, what other congestion cues are currently used by >> congestion control algorithms? e.g., Decoding rate/goodput, application >> decode error rate, ECN, PCN, etc. >> - If the codec is data limited, i.e., producing a sending rate smaller than the >> one calculated by the congestion control, can the congestion control probe >> the bandwidth by sending additional data packets in a certain pattern (e.g., >> PathChirp)? would somehting link this help? >> - application input on prioritization: audio vs video (vs data) >> >> >> >> >> >> -- >> http://www.netlab.tkk.fi/~varun/ > > > > -- > http://www.netlab.tkk.fi/~varun/ -- http://www.netlab.tkk.fi/~varun/ From ron@debian.org Mon Nov 4 10:11:30 2013 Return-Path: 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 AEFF521E822F for ; Mon, 4 Nov 2013 10:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] 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 p2gjTTU-4g-w for ; Mon, 4 Nov 2013 10:11:25 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 9751A21E821B for ; Mon, 4 Nov 2013 10:11:17 -0800 (PST) Received: from ppp118-210-230-117.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.230.117]) by ipmail05.adl6.internode.on.net with ESMTP; 05 Nov 2013 04:41:13 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 9BB814F8F3; Tue, 5 Nov 2013 04:35:37 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12felVnYnGD6; Tue, 5 Nov 2013 04:35:36 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id CFD1E4F902; Tue, 5 Nov 2013 04:35:36 +1030 (CST) Date: Tue, 5 Nov 2013 04:35:36 +1030 From: Ron To: Jonathan Rosenberg Message-ID: <20131104180536.GZ3245@audi.shelbyville.oz> References: <20131102124801.GY3245@audi.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 18:11:31 -0000 On Mon, Nov 04, 2013 at 09:58:23AM -0500, Jonathan Rosenberg wrote: > I do not believe that "genuinely free" is the only, nor even the primary, > consideration here. > > I believe we should in general be thinking about what it takes to make > webRTC successful. And more than anything else, that means making it a > platform that application developers can utilize. If we do our jobs well, > we'll have many thousands (hundreds of thousands even) of applications on > the web that are enabled with real-time comms and frankly a great many of > them will know nothing about codecs or the nuances of MPEG-LA licensing. > What are the considerations for making webRTC attractive to them? > > I assert that the primary thing they'll want is to interconnect their > application with some kind of video network or user base that can add value > to their application. Let me give an example. Lets say there is a bank, and > this bank wants to add the ability for a user to look at their investment > portfolio online, click a button, and have a voice/video call with their > investment advisor. To build such an app into their existing banking web > app, the bank will need webRTC to connect to the voice and video contact > center and clients their investment advisors have. Today, all of that is > based on H.264. And 'tomorrow' it will be based on something else that is better. I don't think anyone in either camp doubts that change is in progress. > So - I would assert that frankly our primary consideration for webRTC is > interoperability. And interoperability as a requirement clearly points to > H.264. Interoperability as a requirement clearly points to the fact that selection of a MTI codec that is Free in as many dimensions as possible is absolutely *essential* for the future success of WebRTC. How can you have interoperability if a significant portion of potential implementers are fundamentally prohibited from distributing the MTI codec? You are talking here of interoperability with legacy equipment, which the WG charter explicitly notes is something to be considered on a best effort basis only, not something to sacrifice other goals over. I'm talking about interoperability with _all_ future implementations of *this* standard. If some people can't distribute the MTI codec, then we have already guaranteed interoperability failure and a forking of the developer and user base. Before we've even got started. The Cisco announcement does indeed make it possible that more people than otherwise might have would also be able to provide H.264, both as a negotiation option and for creating gateways to legacy equipment. That can only be a good thing, for which I'm sure many will be grateful. But it's still not without significant problems, as many people here have already indicated, and it still doesn't come close to either the immediate freedom, or assurance of future availability, or out of the box quality, that we would have by choosing VP8 today. And that _is_ more than anything what it will take for WebRTC to be successful in an already fragmented application space. > There are other considerations too. Some of the ones I'd list are: > > * Interoperates with install base Which means all installed WebRTC applications need a freely available codec and solid guarantees of always being able to distribute it. > * Widespread deployment Which will come once there are many implementations of WebRTC that meet a wide range of users needs. A codec with limited freedoms means limited deployment. Kind of by definition. > * Appeals to the existing set of video application developers - in other > words, the biggest consumers of webRTC should be the folks who are already > providing video communications applications on the Internet (which by > definition none of them do so natively from the browser). Don't we want > them to come to the web with webRTC? As you noted above, most of them care nothing about the nuances of codec selection - they just need it to be available on all of their target platforms, and they need to be able to distribute their apps on their own terms, that meet their needs and the needs of their users. Requiring all their users to download a separate plugin blob before their application will work at all, if it's actually still even available at the time they need it, is both a huge barrier and a huge risk. Who do I complain to and what recourse do I have if my customers cannot download it because of a temporary or permanent outage of the only legal download site? > * Available widely in hardware - especially mobile phones I think the earlier discussion on this point has cast a pretty deep shadow over how actually available hardware H.264 is to developers in general on pretty much every platform. > * Broad availability of expertise > * Broad availability of toolsets > * Multiple codebases and implementations to choose from Again, all excellent points that point to the necessity of a Free codec selection which encourages the maximum possible diversity. > And none of that has anything to do with IPR or royalties. I wouldn't go quite that far, but indeed the important question is which choice places the least restrictions on the broadest number of potential WebRTC developers and users. And on that question, it still seems clear that the evidence indicates it is a no-brainer to see that of the currently proposed candidates, VP8 wins on this very important point hands down. Ron > On Sat, Nov 2, 2013 at 8:48 AM, Ron wrote: > > > On Thu, Oct 31, 2013 at 07:47:31PM +0100, Harald Alvestrand wrote: > > > We congratulate Cisco on their intention to make an open source H.264 > > codec > > > available and usable by the community. We look forward to seeing the > > result > > > of this effort. > > > > > > Google still believes that VP8 - a freely available, fully open, > > > high-quality video codec that you can download, compile for your > > platform, > > > include in your binary, distribute and put into production today - is the > > > best choice of a Mandatory to Implement video codec for the WebRTC > > effort. > > > > This is my belief also. > > > > While the Cisco announcement is certainly an interesting approach to trying > > to extricate their existing technology investment from the deep quagmire of > > encumbrances that currently bind it, the result still falls well short of > > not only the ideal, but also the already existing alternative choices that > > we have available to us. > > > > Given the choice between a genuinely Free option, that anyone is free to > > improve and distribute however they wish - and a no-cost binary-only option > > that is available from only a single supplier, while Happy Hour lasts - the > > decision still seems to be something of a no-brainer. Even before you also > > consider that the Free Option is not constrained to only its lowest > > possible > > performance mode in the implementation that is available to people today. > > > > VP8 still seems like the only obvious and enduring choice for an MTI codec > > for WebRTC at present. > > > > Ron From giles@thaumas.net Mon Nov 4 10:33:11 2013 Return-Path: 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 337F221E808D for ; Mon, 4 Nov 2013 10:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ENJoumDbPloo for ; Mon, 4 Nov 2013 10:33:06 -0800 (PST) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by ietfa.amsl.com (Postfix) with ESMTP id C7A9521F9EF6 for ; Mon, 4 Nov 2013 10:33:05 -0800 (PST) Received: by mail-bk0-f46.google.com with SMTP id e11so820073bkh.33 for ; Mon, 04 Nov 2013 10:33:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=p8kKkX7XrACXsbZSjgNZ3w1+4++DfRdSdHt/wYxjGts=; b=QsbpOXG2fXNQbfHSj+lCZC9MlGjhERcRBQoLhQjymCCBrJxmk1QbPhPZm8yLIsgXki GpTeTnIR4yd+B8zfn5zW7jJDpJClALUjzDUGzEFfak2Q/hLBjN5x2gJUoCMj+VvG0UzS TZSQj04TxzmytsW/GEy77hrOkMIK+Sah11bn8tZ1PQ1dLpaB75Aq/iBMe/H4MvwdtJft UI0inKSIb/DNR9jJEY4MVs/1VnEnMe5H8P0aoyLu5s7oYhmtNdyvdJ36JyDJ5TboaEw6 UsRqFHRufqMRBjRLzLod3pGPaPgkXic05a19jUfqbPQ6yG2/jF1acubqNZa1tUVpBmKz z3OQ== X-Gm-Message-State: ALoCoQn/FIY+VJVThCyaSwW1jSRY3ppsXN3xqqkUsyGgKEtXyP5e5T2Tjh07eIiKBXplegWP5Ga5 X-Received: by 10.204.163.203 with SMTP id b11mr10513214bky.21.1383589984745; Mon, 04 Nov 2013 10:33:04 -0800 (PST) Received: from tamias.local (static-68-179-67-77.ptr.terago.net. [68.179.67.77]) by mx.google.com with ESMTPSA id zl3sm16301368bkb.4.2013.11.04.10.33.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 10:33:03 -0800 (PST) Message-ID: <5277E85C.4060905@thaumas.net> Date: Mon, 04 Nov 2013 10:33:00 -0800 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> In-Reply-To: <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 18:33:11 -0000 On 2013-11-04 5:51 AM, David Singer wrote: > reverse engineering suggests that FaceTime uses AVC (H.264). Reverse engineering isn't necessary to establish this, although it's nice to have ongoing confirmation of the details. :-) http://cdn1.appleinsider.com/facetime.002.jpg -r From mzanaty@cisco.com Mon Nov 4 10:52:55 2013 Return-Path: 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 08CA211E81C4 for ; Mon, 4 Nov 2013 10:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 BTDL888pStaA for ; Mon, 4 Nov 2013 10:52:50 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3E11E8117 for ; Mon, 4 Nov 2013 10:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3199; q=dns/txt; s=iport; t=1383591170; x=1384800770; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=QoO/wBv0rJjhGWIGR1Zb/L+Y5AG5UVA/AGfopdBYv14=; b=lgrQYNp81CruPMlZak1JqPKWc2woFQ4xn8ZHnb7uZIWE85CdWWmI5BIU AQ33DHkLEdvVKWTlMAIdF38Q7L1ZSCCoG+2EyS1T+U8lHyJDZApVzSyMG GgktvzJaWUN44MMdRxxwbp1sp6ocTUf/VhoYeRHQr71gF+1/WPHpne2fN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFALLrd1KtJV2a/2dsb2JhbABZgwc4U75zS4ErFnSCJQEBAQMBAQEBC1cJEA0BCBhVCyUCBAESFIdnBg2+TI8lDS2ELgOYCoEvkFqBaIE+gio X-IronPort-AV: E=Sophos;i="4.93,634,1378857600"; d="scan'208";a="277506668" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 04 Nov 2013 18:52:49 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA4IqnYC030766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 18:52:49 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 12:52:49 -0600 From: "Mo Zanaty (mzanaty)" To: Basil Mohamed Gohar , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 Thread-Index: AQHO2Y8Or0eCM6H8SkuQfdXivrBnVQ== Date: Mon, 4 Nov 2013 18:52:49 +0000 Message-ID: In-Reply-To: <5277DF1C.8080207@librevideo.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.254.33] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7ACE3E8CD3113542A8FD29AAB05F9282@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 18:52:55 -0000 > ffvp8=8Ahas no known major problems. There were indeed problems, some rather severe, like bugs in the ON2 encoder implementation that became enshrined in the bitstream itself and forced decoders to mirror the ON2 encoder bugs. See =B3Practical problems= =B2 in Jason=B9s old rant at: http://x264dev.multimedia.cx/archives/377 > xvp8=8Astalled Too bad, it would have likely been a very fast/good vp8 encoder. If you followed that project, you would learn just how similar vp8 and h.264 truly are. (Hint: the base is x264 not libvpx.) > many hardware VP8 implementations True for decoders, not yet for encoders, but the latter will improve over time. Since app devs don=B9t understand how to use hardware codecs (there are unofficial/hacky ways in Android and iOS, and official ways in Android 4.1+), actual interop has not been widely attempted yet despite hardware support. > arguably much more complex, (full) H.264 spec Agreed, the spec sucks as a practical implementers guide, although some argue that is not its main purpose. I find it silly to need a separate implementers guide. Both H.264 and VP8 suffer from this, for opposite reasons; the H.264 spec is far too verbose, the VP8 spec is far too terse, essentially making the code the spec. Maybe Daala will strike the right balance? ;) Mo On 11/4/13, 12:53 PM, Basil Mohamed Gohar wrote: On 11/04/2013 12:47 PM, Mo Zanaty (mzanaty) wrote: >=20 > To be fair, H.264 interop has not been a painless endeavor over the > years, in part due to multiple profiles. Implementers have worked > through many issues to achieve the nearly universal interop enjoyed > today across hundreds or thousands of vendors and implementations. VP8 > should have an easier time, since it doesn=B9t have multiple profiles, > packetization modes, etc. But VP8 will go through some of the same pains > when many implementations flourish (software and hardware). The pain is > not felt yet since there are only two vendors (Google and Mozilla) in > close contact using a shared software implementation. >=20 > Mo To be even more fair, in fact, there are more than just Google and Mozilla on the VP8 playing field. The ffmpeg/libav community(-ies?) have made a successful implementation of a vp8 decoder (ffvp8) that is also widely deployed and, to the best of my knowledge, has no known major problems. There was also the xvp8 project which, while I believe stalled, was not due to incompatibilities or challenges, just lack of energy for that project and motivation. And there have been many hardware VP8 implementations in silicon across multiple vendors no less, both for encoding and decoding. And yes, while H.264 no doubt has a larger market segment, to say Google and Mozilla are the only two players would not be accurate, and the design and spec have shown they can be implemented widely and without as much pain as the, arguably much more complex, (full) H.264 spec. --=20 Libre Video http://librevideo.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Mon Nov 4 14:11:03 2013 Return-Path: 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 B0FC321E808F for ; Mon, 4 Nov 2013 14:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, DEAR_SOMETHING=1.605] 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 vlZbRmEMC06K for ; Mon, 4 Nov 2013 14:10:58 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 38AFB21E820F for ; Mon, 4 Nov 2013 14:10:55 -0800 (PST) Received: from [10.21.78.155] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BDC1350A85; Mon, 4 Nov 2013 17:10:53 -0500 (EST) From: Cullen Jennings Content-Type: multipart/mixed; boundary="Apple-Mail=_39DF267F-BCD0-4EAC-AE2A-6563F15154B4" Message-Id: <07125D97-E244-4449-A135-D3B8C0C22D57@iii.ca> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Mon, 4 Nov 2013 14:13:32 -0800 References: To: Stephan Wenger , "rtcweb@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1510) Subject: Re: [rtcweb] Liaison Statement to IETF (SC 29 N 13820) X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 22:11:03 -0000 --Apple-Mail=_39DF267F-BCD0-4EAC-AE2A-6563F15154B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thank you for sending this. For folks that prefer PDF, I have converted = the word file in the liaison to PDF and attached to this email.=20 --Apple-Mail=_39DF267F-BCD0-4EAC-AE2A-6563F15154B4 Content-Disposition: inline; filename=29n138201.pdf Content-Type: application/pdf; x-unix-mode=0644; name="29n138201.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1XMty40aW3eMrcjMRVIQKxpMEvZNVak857KrpMt1edM2i VLQlu9uEzCq5W/Of8z9zEpnnJEgAKaBrOrQgBSRu3vcrL/i7+bP53eR5ut1ma33WmzwttlVlmnyT brNmbY4/mR/NwXxx/TE3Hz6arPv7+AHPZmlRuf/tl7wo001WFWazKdOi3hbJh9/MVztTuyf8x+43 88Vul6eZyc3uZ/NXs3p1YV4Aklm95pfdzVt+9deS1RWv7LT+zYXFoPec1nxreE+AvvaLry6Ss90E 73tuITiRvcyfOoDJarCTEZydAIm0l4M9hOFLYrYUof82u2/Mza4T56lIKkiiKtbNIpGszIXZ/ToO MM+gLnVWmk29SatcMs7SLKtKs/tg6qbTCP8xlPabt19fvQaFkBv4lJvV1a77eHWR4NKb19i87HTC CtbduukWvH2tlfbhN6+vvu2uu7vusZf8JwGM12/efgdu2y3cytFdHawLE2Hitk7zJgMTT2mOUhpj YpFXaVlnMJQqT8vyhImwoxlMfGVVDIRB916AF184DoL4F3myunYXwRGs+MYtBCPten8rd/+5xzwo f6twt7b2I/GAf8Q/lVnBguxm/mF8TLOsbIp002Tbcwr/ZZbl1SbNmmptNkXd9y3z9e76zUsn/9df O115AwMGS8yF1RWvKG/+4sg/Xflfjr2dzl47lfzhrdM0p8IO4NXrlw7Y1Q9+K4hnmkdVDeSrdS2S zIi7TM4MKKpW2yat1zUA5kVaQ60+F2BZl2mdAeB6u02z7TyAfYduVavz0GBE9wmN6z7BX3fjxqpd d8l8s7umA8y5TgC0rNjyntXKLK07vewg5H2VTM6jU7XdpM0GGhQjxoyyO+l8az4V9+osWwI56eKe DXZTTrbOtmldISY/g2rSD6SrvMqzdQA6GaahGQPoyXNhOqZ3JWyzKLPcrJu6HxOei/uKie0fP3m9 +O2W6uCuJKujv2OKLC8vDaM4HzicrjerP95fhvj7j+7uxqx+uUg6Ffn0Px4cnyf4v/vr7wVwH7Pd wMMFJMd4iMhSb7ONWa9hchtFhOdYKPtoH8kIUvRBlDrSvzSyoVZEivG60uL5aZ+Vw2cBvUVoziK7 2qbr+Rnj7hdP3CfKjfL80nzr7iWr91z0kawJdJveV+vys7RTEuecIHnnkgDUssKZ/7k/ydfbtNis C7P2uI952zN/ksA5tj05aCeiKjHcmZ+tJJxn/IrfWin0R7pKEs4lIHZafEVTpdsK2dspzsmYmhXM 0GfJr6zT7Xy13bVfmlfk8s3OZdI2FAfcB/47t05x2yAY+b1m8NtWF2/JKYQXL1dFDjJPXqePwbC+ WSP37bi3gNpZ3LM1WJx7i6RRN01axa1J8Gy4lhdBmHaazxj76sbr4LX5RnzkpZEofRKdO+W1SaOP zuZdl2bhv2SFlMpd5gZa9+7COC1Hqtk+0r73ht9oKn9zwktW5pNHqDW8d/i5A4/coD3+RisSLcjg Ooygdg4H8767kqxu20cCM+3jEZWvXxqcqXv0oGUPx/ZOy+RpZJ5wNFGdot+vN9VzKduJyIQAMTwe +E2oOccGNpIt+598GIQPave8ergz5AhBkNz7Q0u2t3dcz0Wi8dLzz6wO+yAC8+C4alZHYkQIBC/p vvd4HQ2B//NBGx8Jh2Da41NPRY5/szzu0erCHWh1ojqntaca8ySzztJ1KHSjrhLG9NXRO2nwXepA XI7+CpT2llQNFu1P6JGhNOb2yaY/TmXb9s4xKFkReNrzngPfVRQNmjmb3NSenDHv6YsNKdoc31WX KMzipYHggT22zuqMT3TdeDmJNKkQOKNQNhIO4DNLtKliCPjw20dAWvtIvu2lvuaaQqHy8dP0tUao H9uHVvDOH5Vc4fau9biehZt7xjUUSDDqLQoWUhhpp/UpfDXPN/guGG1y0l5m+gZndeRpIJ7wDwgg XvQy+yeb1OeXwZjd4mRFS7+fZ6HoO+YIn3NUGioo4ETWtLe/drihD8BrdFFczAJCCbNpJVMj3uku 9aZ9EP13Qc2kM4RO3Tns+e24D1y5J1KKM8G3fvKek0skexPckCID3Q8yLe3DB80DoDshBsfNm/te jL2TPw57EVowEwEDCBnxwCtVG1swoj1ZR0QII7aFrlR89SIUuedJebXZAmCxjQIcuDkryqlavGos xGohxBiKW7RkczjiCMnnGEJrqZD35PXxjtKZZyRIn5/pyYvD2I4KTPXl9tzzIB3mlSgWoNlFH4/F TFN9t9r56PD0oH3yQSo4AznScTAj2W4wpyPpJpcPH84MDH47ptEFWmb5Zg2nvYxSeoJWlnkwjwcZ vPwp1x3pKkk7b5BNe3N4ZOp7y4vHzmtN22MJZc/LTS3s54ScWJaAJuRygFA/sv9BaSAFSHqZMsoJ iUU2rvL54ERbiXav8oIwlRdfRmXLXL3CeYDt0Ywp8cBZHWynYcq5wP11XZ8YxHNfEHN/8H51s0Z/ ZglAsFu1gJhINns9MyvqEnl2cCwOsdpm5cOklssFODWqNu7PbiIrHkmUQhEmGEoghkrvQCargyKW pN3OKi6Ik5QokevlblzyB7+c36C5CeFLY5Oy0xRpZsE2XsRcJNNGLDVt8q6nNqGm9hS28/iJO4V9 t3qlIuoaXo4mhJoO/ZIuZyddt/1yy93yKVBi21snpeW71eDp/jZQh++YFyo3vun2S7oDp25jI04+ 3uorsfldmbx8Ab04NNKtCkIkWdRnQhG90heulBNWygdF5c29TOdcCVpvISGWznMua5y6z+wFwXK5 K8mg3Z5V7qeqJxbKSJRVEJ4hoH4LplftCARt4DbwnLwhCNk5kfRpcq91oxTX3LV4fFq5C0SoumgK U3k+Oe2OdzB7+YzwljCRDJNoj8W4HzrpckgnSL7g6ovXymTVqy+pdMFCVEQQEHm0NyommLYnauTA OfXKjzP0T/uog5xb7qGu0mx+k3DMMxPng7lyNpysHhQwqA/dwU20N5FXa1fKVx4lyHTqQEo5aizr EIklvAd6E3OyGOjIzru5oIztgVQ80QUlq8dbipH0S+b6wjsQFL8eBoEM3GqRR/uqmIKXNrb6FhCa 0rsk9JrkDff/pnbGwEGKhBAWvCtPVg0cvEZehJooC+nudLqKfhEauThZn/YKEni+7np1M0OefLco oMsSn1ULoxBwkY7ydPLqMZ6xJjhlcYqy5WfIToJoVVAt1C96W8TpniNwDj+o3O+PxFukUYuFFB8X N+RkRj31iEe4nAzmbnoE5ghQYgtRDxseWiKhCKvAAjynNaDC7AMaCY1BO2F2uzbqQzDotBhgLyC3 hvwllf7AYq4qZ0WK438WGTCCLMPEkJ0N6o/TDaqD98gypsqNNQ7pQNPGVKfAoxBBk4KUEu+BWwwl GwXIjpmEKyhkCC2KT6CCiIm4CxNZjdDvsZ/j1mMiRlcHXYmFAMEO4t1SwnISCn4yZgQAVd+kU/pP y+NnCBZc6q0A9cyJdTtPxKhrViGjltnIX923xzRknokd+YQZ9sY2y/UaUz6Y8yRfn/OefmxTg5QP gX5RQgKkKJfWHiL2iyPVpqiFwxzZQhStvFlwflSvg/FZbaJullRQnm2Y/c1Mn2yrJJt/LCQrGHp3 suq8QNybW/psLmESEkKM6CfVTif7YYky+Sf1lhf4qfb1mI5Jk4kDcXqQM+DWXCG45wTA96t5fL5Y DLrsZUwxjSnLKm3qrDILJdGqHa4ahwQIB3bC7ZHbOvuPaPZa5Q00Fw1d4jFmPgM3HfHSVZEvBwhb +I6ZZDCKMFh17HGVrA/lTozPmFNN0VHfROkLB21uug3o/CfRocLc3Qc3NDKqzBwO7UceKD5bBGAb NQ2OoSLijnQ+EmeMTrSoi3qNE9IeAmPT6ydnEUDginQ+44ShXNPuL69xPGt1yBM/x/1FQ5sdVVkI D7Q89izA93UGepOsQs5KTaLF63He0IWo6AuMQRclAvES8oHupDORZbdqux3tJMO0AIrtOi0ydE6J wudaMerOfwEgUoOp5K3M7PxqOcDQZ4bJeWYYTNK9aLF6D2FMAse7HsgLSfznql9Z2InYReAgTirN Y2iNYhZCMdt/SVbxLn3ZTdJgGpXEjEkyMEf+SlmZ2lXBffh8iwhqRVBv/zSmDn2ZGG71ahoBoMFI UQePzfJZGM5OmxLHnc/Qeu6zxNP2GPIm4RSzE3lpOJje6x8nFURgrtM8iFbcWJL+yKHKx2MGhr6d rBxNiVz1S54yTRcS6EnEaMwRCnCM0phyGZGvDgEZnfsTT8ddZEBBobsRM9KjbrEopPpxBSE9eZHZ XvteLlDqK5Xi85Qr2XFkHhhm3XjI2apq4MMhIhCNrmU17UirqkqRFsOXL2PevNaBREhmiCheILW9 rmtM1tJnzLBX81uF3E2eAPMa3Jmja5CPpMP1gYkq1CiN8yW90yWnzk+SLImmkPhJDPahEccNJ89n +q5g1uwa6qN3KDj9+ND1VzgqGh77BUxQAI/ZMfGyY0EelOqJbiyojCbddY5XsrYYvrbvHli5OScf PwaIJUzSA/sOY3gj6zm/dsXkjyLgZ3CrqNBOT1/GJD9tTzn6WQ0G3Uy5DDMyuKdGLorxBtGSSQkv 1ZQ4Sb9ruR5jotQ7NCP41a+FXxOcx+enqcSdsR43BjS8RsTGkTF3S8uhsgkDfbGjZR6WLJVP3YfM lpcovEdVxILku3no/nPRub1qUoHoRGOM9A1jIs38NgLZ/gDy/+A/xIgiCGfyXKFRoUDPMzbrb4fW CTdRgxZB9Eef65DiW1n6dZT4AtVOs8mRtiyjXqeUgQy1nvylXuODWI11NXQkEaaBghdzpAbSRXKU qLLB5E+DgVQSNZZ3nvcB+qkRFWogtN6AZE+LnVO5j7b4A596XQ+mQ6FNMOtsxVZI+cRLhf2Mz48T SL+oOPwM3Axnhb00tA0zhOwgKzUiCHmfcTMgAwP1Ghbq5jCcH6R6HAWeAqDHGznB/975+6GF9Sc3 YRkzZ3C7o79wrGvdznQkwJsnadXkpYlJYkTBhhMZk4Mesl/HApxdk0ttVPfpzXAwnxbwZjNV/3RS ZEkm4p16l4n489MuE6HoQwgjAczKbM+Yq5zAbZ72JJViLDhXhkgcdfokB6TgJndFWGxI4y1FomV6 1eETLxIvpZQabOEK0Tfm3MRIKjIGCDzDhMnz5gkt3g0OxKGfydRvDUgJ1ngNeYajwDGCfR9OpJDz pJHYPwjpXun0SjXhW45fhxkf+gnK+Uzg4YWY3vH72XFdsgoqQXDyJ+FFI/pShSESIZzZ1Q9NMy6x vanTlOygA/I9xrGH7xX1glu/jCTDSC43uI8otYseA6V+imbdeKcMIaBcG/yiRE/En591FygaN/OH ntTplhLceE6Gl0hCSTvNZQlUJhtObdsD9Y8S7AWpIExxsOcpyf9wPigdlyFi62lPX+D9vWZbV4Z8 GfOniLnnbR1ijJpL49JHeYPwKhwVRdU+a4HP1SqrzslKPCHnn7qI2Juy5g0iTI4puXYY4u3veK9P LgeDPg1mmSb45Ecd1epbEp2Ds+hJuAtczoRQFsnPB32SwEkZbVQ2T6fyZBM4B+qh1ZtyXL7HPFy7 DzmedhCnyEp/B4WYpBtextNj0ShernGiVuGFI7zM37HTt4GnZg/6WZ89E179coh0mNGWzTc4ZT4D Hq2wYxV7udksB4h4Q/ZQMmQgdRGh2YlD9aGcPGouCobX+L/keupALaTeUbt93wW/igLDnqWwvnEP oe1+HX8JXQaAwwH7QzJxA/Dt2GQwksvKESdAd8NakRw6bwf83TOKnCNn+b+0Dv6IMMIQdph8e5QF aJlMis8pFeImFN+9uW33T73o7YRHHCQXPqcbwk4Go/4abZOawGePRm1dbk/8LA0umPd9aM/JD15g hKGh8s+hC0tkZ09JHIUhBvV2GQx3VLDpapPX0V3GigYSpm2O/xs4FtuRKmm76AtOCMjjc8ZSXggq jm4ixhvke8COd4LWiQgvawQWPsZ9J8Q2YKj92Ydms23MQvoUFHthhLS2fhARYz743YeuxOxeXQ/m QGznFZZ7ZB6OWaROLOmNAo2cweMMFkNveNmNxDl/8vkJnuXaAmX4E9uqyLme7Iv4wr/HnXMazxWj PVx2JyyPD+IzvbbA3amvRw7z8xza4S4oGLkqJfqyZxADQ+9OgvFWlSET5jhpF/nGnT7e4O7eGsqr etYLHl1sfnGRTB3+wkW4t4ZmACztr4LYFk8sNG9QHdgfs5kBD/PcSst2g3IzzzY9zg5tEaM3RbWG utYY1gz1g52VLNZ2VrIsux9t8h/ux53CCPmn++l8JS/gONdb/C6i5/LnnonnBU4qlgJEvjKn2KEp UHn5OVTiS5OXMZYWOLmv1lZZl5D9YpqPheUjfrdlEUCQnW/CC+O0t8Mjv6Fhg1fHK/gF5+cO4Tef uKT3wjle0j8bsr8czsYTVM/DqAQkzEvzAyF9zy9XMXZW4GJlfzJmETu7hG/89xdl+3ZIbOZ5ZeyN wWD7zwPsbL9zJhEEZfvPw5MhQtxjtt/EOJvL9q1dhROU/1/bX0BEzCEG218A8N9g+2UeBvSp0xoH uI8eAxTI6zaYc8SvvDrNi0cx59RjmldgPmADiM8BPGlyxJhcQJefBTiS6lZhjjqcSLAEoJtxuX3v LJtHClxIl6ueCnMM8rn3s3TqFnINfiMo8nZLZX2y/QmCRayP2ChTdDvzlm/zhqIc+eVWxec+5//8 f5PVBggKZW5kc3RyZWFtCmVuZG9iago1IDAgb2JqCjUwNTcKZW5kb2JqCjIgMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAv TWVkaWFCb3ggWzAgMCA1OTUuMjc1NiA4NDEuODg5OF0KPj4KZW5kb2JqCjYgMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8 PCAvVFQzLjAgMTAgMCBSCi9UVDIuMCA5IDAgUiAvVFQxLjAgOCAwIFIgPj4gPj4KZW5kb2JqCjEx IDAgb2JqCjw8IC9MZW5ndGggMTIgMCBSIC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZ2Wd1RT2RaHz703vdASIiAl9Bp6CSDSO0gVBFGJ SYBQAoaEJnZEBUYUESlWZFTAAUeHImNFFAuDgmLXCfIQUMbBUURF5d2MawnvrTXz3pr9x1nf2ee3 19ln733XugBQ/IIEwnRYAYA0oVgU7uvBXBITy8T3AhgQAQ5YAcDhZmYER/hEAtT8vT2ZmahIxrP2 7i6AZLvbLL9QJnPW/3+RIjdDJAYACkXVNjx+JhflApRTs8UZMv8EyvSVKTKGMTIWoQmirCLjxK9s 9qfmK7vJmJcm5KEaWc4ZvDSejLtQ3pol4aOMBKFcmCXgZ6N8B2W9VEmaAOX3KNPT+JxMADAUmV/M 5yahbIkyRRQZ7onyAgAIlMQ5vHIOi/k5aJ4AeKZn5IoEiUliphHXmGnl6Mhm+vGzU/liMSuUw03h iHhMz/S0DI4wF4Cvb5ZFASVZbZloke2tHO3tWdbmaPm/2d8eflP9Pch6+1XxJuzPnkGMnlnfbOys L70WAPYkWpsds76VVQC0bQZA5eGsT+8gAPIFALTenPMehmxeksTiDCcLi+zsbHMBn2suK+g3+5+C b8q/hjn3mcvu+1Y7phc/gSNJFTNlReWmp6ZLRMzMDA6Xz2T99xD/48A5ac3Jwyycn8AX8YXoVVHo lAmEiWi7hTyBWJAuZAqEf9Xhfxg2JwcZfp1rFGh1XwB9hTlQuEkHyG89AEMjAyRuP3oCfetbEDEK yL68aK2Rr3OPMnr+5/ofC1yKbuFMQSJT5vYMj2RyJaIsGaPfhGzBAhKQB3SgCjSBLjACLGANHIAz cAPeIACEgEgQA5YDLkgCaUAEskE+2AAKQTHYAXaDanAA1IF60AROgjZwBlwEV8ANcAsMgEdACobB SzAB3oFpCILwEBWiQaqQFqQPmULWEBtaCHlDQVA4FAPFQ4mQEJJA+dAmqBgqg6qhQ1A99CN0GroI XYP6oAfQIDQG/QF9hBGYAtNhDdgAtoDZsDscCEfCy+BEeBWcBxfA2+FKuBY+DrfCF+Eb8AAshV/C kwhAyAgD0UZYCBvxREKQWCQBESFrkSKkAqlFmpAOpBu5jUiRceQDBoehYZgYFsYZ44dZjOFiVmHW Ykow1ZhjmFZMF+Y2ZhAzgfmCpWLVsaZYJ6w/dgk2EZuNLcRWYI9gW7CXsQPYYew7HA7HwBniHHB+ uBhcMm41rgS3D9eMu4Drww3hJvF4vCreFO+CD8Fz8GJ8Ib4Kfxx/Ht+PH8a/J5AJWgRrgg8hliAk bCRUEBoI5wj9hBHCNFGBqE90IoYQecRcYimxjthBvEkcJk6TFEmGJBdSJCmZtIFUSWoiXSY9Jr0h k8k6ZEdyGFlAXk+uJJ8gXyUPkj9QlCgmFE9KHEVC2U45SrlAeUB5Q6VSDahu1FiqmLqdWk+9RH1K fS9HkzOX85fjya2Tq5FrleuXeyVPlNeXd5dfLp8nXyF/Sv6m/LgCUcFAwVOBo7BWoUbhtMI9hUlF mqKVYohimmKJYoPiNcVRJbySgZK3Ek+pQOmw0iWlIRpC06V50ri0TbQ62mXaMB1HN6T705PpxfQf 6L30CWUlZVvlKOUc5Rrls8pSBsIwYPgzUhmljJOMu4yP8zTmuc/jz9s2r2le/7wplfkqbip8lSKV ZpUBlY+qTFVv1RTVnaptqk/UMGomamFq2Wr71S6rjc+nz3eez51fNP/k/IfqsLqJerj6avXD6j3q kxqaGr4aGRpVGpc0xjUZmm6ayZrlmuc0x7RoWgu1BFrlWue1XjCVme7MVGYls4s5oa2u7act0T6k 3as9rWOos1hno06zzhNdki5bN0G3XLdTd0JPSy9YL1+vUe+hPlGfrZ+kv0e/W3/KwNAg2mCLQZvB qKGKob9hnmGj4WMjqpGr0SqjWqM7xjhjtnGK8T7jWyawiZ1JkkmNyU1T2NTeVGC6z7TPDGvmaCY0 qzW7x6Kw3FlZrEbWoDnDPMh8o3mb+SsLPYtYi50W3RZfLO0sUy3rLB9ZKVkFWG206rD6w9rEmmtd Y33HhmrjY7POpt3mta2pLd92v+19O5pdsN0Wu067z/YO9iL7JvsxBz2HeIe9DvfYdHYou4R91RHr 6OG4zvGM4wcneyex00mn351ZzinODc6jCwwX8BfULRhy0XHhuBxykS5kLoxfeHCh1FXbleNa6/rM TdeN53bEbcTd2D3Z/bj7Kw9LD5FHi8eUp5PnGs8LXoiXr1eRV6+3kvdi72rvpz46Pok+jT4Tvna+ q30v+GH9Av12+t3z1/Dn+tf7TwQ4BKwJ6AqkBEYEVgc+CzIJEgV1BMPBAcG7gh8v0l8kXNQWAkL8 Q3aFPAk1DF0V+nMYLiw0rCbsebhVeH54dwQtYkVEQ8S7SI/I0shHi40WSxZ3RslHxUXVR01Fe0WX RUuXWCxZs+RGjFqMIKY9Fh8bFXskdnKp99LdS4fj7OIK4+4uM1yWs+zacrXlqcvPrpBfwVlxKh4b Hx3fEP+JE8Kp5Uyu9F+5d+UE15O7h/uS58Yr543xXfhl/JEEl4SyhNFEl8RdiWNJrkkVSeMCT0G1 4HWyX/KB5KmUkJSjKTOp0anNaYS0+LTTQiVhirArXTM9J70vwzSjMEO6ymnV7lUTokDRkUwoc1lm u5iO/kz1SIwkmyWDWQuzarLeZ0dln8pRzBHm9OSa5G7LHcnzyft+NWY1d3Vnvnb+hvzBNe5rDq2F 1q5c27lOd13BuuH1vuuPbSBtSNnwy0bLjWUb326K3tRRoFGwvmBos+/mxkK5QlHhvS3OWw5sxWwV bO3dZrOtatuXIl7R9WLL4oriTyXckuvfWX1X+d3M9oTtvaX2pft34HYId9zd6brzWJliWV7Z0K7g Xa3lzPKi8re7V+y+VmFbcWAPaY9kj7QyqLK9Sq9qR9Wn6qTqgRqPmua96nu37Z3ax9vXv99tf9MB jQPFBz4eFBy8f8j3UGutQW3FYdzhrMPP66Lqur9nf19/RO1I8ZHPR4VHpcfCj3XVO9TXN6g3lDbC jZLGseNxx2/94PVDexOr6VAzo7n4BDghOfHix/gf754MPNl5in2q6Sf9n/a20FqKWqHW3NaJtqQ2 aXtMe9/pgNOdHc4dLT+b/3z0jPaZmrPKZ0vPkc4VnJs5n3d+8kLGhfGLiReHOld0Prq05NKdrrCu 3suBl69e8blyqdu9+/xVl6tnrjldO32dfb3thv2N1h67npZf7H5p6bXvbb3pcLP9luOtjr4Ffef6 Xfsv3va6feWO/50bA4sG+u4uvnv/Xtw96X3e/dEHqQ9eP8x6OP1o/WPs46InCk8qnqo/rf3V+Ndm qb307KDXYM+ziGePhrhDL/+V+a9PwwXPqc8rRrRG6ketR8+M+YzderH0xfDLjJfT44W/Kf6295XR q59+d/u9Z2LJxPBr0euZP0reqL45+tb2bedk6OTTd2nvpqeK3qu+P/aB/aH7Y/THkensT/hPlZ+N P3d8CfzyeCZtZubf94Tz+wplbmRzdHJlYW0KZW5kb2JqCjEyIDAgb2JqCjI2MTIKZW5kb2JqCjcg MCBvYmoKWyAvSUNDQmFzZWQgMTEgMCBSIF0KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2Vz IC9NZWRpYUJveCBbMCAwIDU5NS4yNzU2IDg0MS44ODk4XSAvQ291bnQgMSAvS2lkcyBbIDIgMCBS IF0KPj4KZW5kb2JqCjEzIDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUiA+Pgpl bmRvYmoKOSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250 IC9YSVdWRlIrVGltZXNOZXdSb21hblBTTVQgL0ZvbnREZXNjcmlwdG9yCjE0IDAgUiAvRW5jb2Rp bmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgMjEzIC9XaWR0aHMg WyAyNTAKMCAwIDAgMCA4MzMgMCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAw IDUwMCA1MDAgNTAwIDAgNTAwIDUwMAo1MDAgNTAwIDI3OCAwIDAgMCAwIDAgMCA3MjIgNjY3IDY2 NyA3MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAzODkgMCAwIDg4OSAwCjcyMiA1NTYgMCA2NjcgNTU2 IDYxMSA3MjIgNzIyIDk0NCAwIDAgMCAwIDAgMCAwIDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMz Mwo1MDAgNTAwIDI3OCAyNzggNTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4 IDUwMCA1MDAgNzIyIDUwMCA1MDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgXSA+PgplbmRvYmoKMTQgMCBvYmoK PDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvWElXVkZSK1RpbWVzTmV3Um9tYW5Q U01UIC9GbGFncyAzMiAvRm9udEJCb3gKWy01NjggLTMwNyAyMDAwIDEwMDZdIC9JdGFsaWNBbmds ZSAwIC9Bc2NlbnQgODkxIC9EZXNjZW50IC0yMTYgL0NhcEhlaWdodAo2NjIgL1N0ZW1WIDk0IC9M ZWFkaW5nIDQyIC9YSGVpZ2h0IDQ0NyAvU3RlbUggMzYgL0F2Z1dpZHRoIDQwMSAvTWF4V2lkdGgg MjAwMAovRm9udEZpbGUyIDE1IDAgUiA+PgplbmRvYmoKMTUgMCBvYmoKPDwgL0xlbmd0aCAxNiAw IFIgL0xlbmd0aDEgNDQyNTIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB1Lx5fFTV /T98zr139u3OTGbf10wySWaSSQIJkdwAYQuYKFtCTQn7IkoSFkGlREUR0IL7VgGrKAiWIREM4FfQ r7a16ldsrVVrJbZosUpLW2qrkMzzPneCS/t9fs/reT1/Pbk5yz3n3HvPPZ/P+ex3VnWvXkj0pIfw RJp/zdxOIv8FsoTQjfPXrArmz8VdhKjeX9S5+Jr8ufNGQpTli5evW5Q/D/UTsmX6koVzF+TPyUWU 1UvQkD+nlSijS65ZtTZ/7mf3J8tXzB/uD7H+m6+Zu3b4+eQDnAevnXvNwvz4/RhPSjpXrFw1fK5H +URn98Lh8bSVEFPj4u5VC3l0sJIjRvYIQiTyN1JHHiUqwhGRpMhMzDwmfEYUOGf9Cv0bs5z3pueY 6v6hdqnRQMiP/+B7iZWvHPxi+4VVg3eIRI2bEY08nnXgOlVoqJHMEsmFVV+dEvNPYj2X/qQjZDr/ eR9fHKhvsPGnSQf/KdnJf0xOIQlERIuIWj1SJ+o5JEXuBP9RX2NjhdSPMlkml72JooojrKPX7a34 L/4jbj8pJAE0nOq1e+SeD3vHjBmuVI/MV/qKSytONWj5D8lfkDj+Q/4USeSv6kuUVZxrMKCB8j8g JkpJgOzif0eySByR+Pf7ovGKncf519H/C/5VskC+7NVeg7kCN/wZ/xyxkAB/mD803HOoz2iuIA0r +TuxJieQn0QaQDqHJJAV/FNkA9I2pANIAjEhDyClkJpZC7+P34d57sb1JuQppBVI25AELOHTaL+a 5fwefhkJ49o7+HuJDeVW/h65fAKlG+c/Rrsf5WM4Z+XO4fNHULL+h4fbH8K5HecPDpcPoN2D8/tx zsr7hs/X8Kvl61YNl7v4lb3+gNjgR38QKY3Eo3Yvavdi6e7FGUFO+Vv45fIMDqKswB2vyZeA2vre UESG0fo+h6tiF5Z0PZZ+PVZuPVZuPREw5sZLY27Mjynlb8SYGzHmRoy5EauS5lfieSsBMIJcRAoi 8Vj3lVh31p5FfgLpJBJPNiLfjrSLnfHXYR2LMKvN/LLeRADItrivRqqoP8YvwlJL/KI+l69i2zdn Gi1DxEV9GuNwaWJjF8pjF/Zp9Kx1YZ/bly8x6uoGIz+f3IDEkQLkUaRKpHFIAj+/N5oKHOUvJ9eo iWQMbOA28BuEDQohPY5ajvMVpAU7MEAsfCmpw4CiwJw6OqJD06np0fCiJqhJayRNi0axgt/Ab+P5 AJ/i6/lmfg6v6M+d6FXVZlBIE5S1me26Xbqs7oTupE6RVZ5QnlQOKM8pFUFlWikpW5Qdyk5lj3K7 cpdSs125XcV16Dp1PTpe1AV1aZ2ka9EpAiq6q+FWfh5ekyAXkTqRtiMJWOM5aA/y30eaA2jMwbJ9 H+0EOcGZiHQS9QGUCpyZMM6EcSa0mtBqQitBznpakDqQOpFYr/LrnkvXsPHnWA9SIXqNuJORcLiP Ee2oIU3GmQFnBpwZMOokdxEzFJEHkVqQeLltADVgDfJLfenh/g6USsL6zyFx8nWsT0LiuYvS3MIT RTRbRHcV0e1FVKqrb6iQwsgsFsucyJzYnMSc3cKKyIrYisSK3UJzpDnWnGjeLdRH6mP1ifrdQiqS iqUSqd1CIBKIBRKB3cK2KQemHJ/y5hRhzpQVUzZM4UcAdH29yXSFXIZjrDzU63JXjDA1jOIO4HXm IN+JdAqJJwHkKaR6pBVIAncAeYB7Bq3PoPUZ0ow0B0mBK57B9SbkrJ/1sfadSAq5dgo17jv9YIbc /t7aTHPDZJDcOUg7kXjcez+u3y+PztcOyO1Z5ANyezNyNn4XEpvl/q+v4UHgZrN5IA8g1SPNQepE UpA3+VlgDrPYnZEHkDqRDiAJ/Gwcs/hZ3DM49nP7+RLJUG4LELsd3MZiVosNIqcHDhjoHjl/UM43 y3m9nEcl42TDF5MNL0w23DbZUIgKlyANuOBeOQ9JugbDsw2G5gZDUYMBd3OQEDFwNjlXspx+JueX y3mJVBAyfBky/D1k+GvI8GjI0BUyXBZi13mxdw1cgZzrWE7vl/PJch6XdAHDTwOGWQHDiIChwUB3 UMyBjJFzv5x7WE7/9qxpnIlojtG/kXG4H+2tKwr0c0QuaK63riHQT4d66yagGOyt24Hiq966ewLP 0y+pzNLoF73R04EGGz1PJwlgcfTvw+Vf6SSyD+fnUC5G+SSpozGUT/TW3cTGP47rH8b5j0lYza57 jLTI1++kk+T2R4ev+1FvyTw89ZHeknV46sOkhLLRD/SWnEbrPb0lm1Hc3VuyHMW23hib4LLeuuJA g5kuJlGOjZ1PYhybyZThJ07EnZfjfEL+4sbeEnbVOPaAfjq2N1KOopDN8nkaIS3y4wK9EfklfSQi T85LIvKkPSQml0ZqkidvIGG5VPdGbsJdlM/GTgf+WXeMvTj5BzX17gj84Xm830yc/p5O6t0XeOsI W67ewJsl/TR2OPA/kWOBV6L9dGZv4ERJvxodx0v6OXoocBCLnMVYjh4OHChZHHgmIvfujqAXoN5Z Vxp4JDI78FAM572Bm0qeZ9Mg1+CNZ6K7rWR0YErdvsD4WD9Ft1SHh0naQG2kO1CD5pH9dFLfvkB5 tJ9NJY177DscKMYT4xF5KjNGHOWqiIqulkpUq1TzVDNVV6hGqTKqUlVQ5VN5VQVqi1pUG9V6tVat VivVgppTE3VBf25ASjJxrUApS21KkG1KBLkugjRSbEBZmuOomsPeyVr5Jq5p2hiatTSRpuljsiOS Tf2q3JXZkcmmrLrle60HKf1hG86y3O39lExv7ac51nSrJ2sZ23qEUJq69U4PK2+89c62NtqUPTGf NM0LZr+YhvfQXjE7q4iMcRL7mnpnvWW0uWb8uP8l65AbO8Ylv/lzflNFzenL3t80rTX7tK8tW8Eq OV9bU3bCtOBVrUe4Lm5F47gjXCcr2lqP0Ou5rsYrWTu9flzb18NImOvEMFLHCjasj4TZMBKmffKw KfLdgKbhxnEHw8jYoJfoJDYI6POSPGixPAg43sXu1cIKDOP8JCrfK8r52TDgQ/5mpm/fTE+oSb6Z SU/km3nZoIOxGJ5Xgqyt9eCIGAYcjI2Qu/d90x2Ru4/QNsIGHCEx2iY/h8rPyd8ikR8DLBgew6kx 5jvL+P/1ZOGY/xd3oH1zP1gwv3FhpLEj0rgQqSO7dc0SZ7ZnXjB4cMEHrCOY5eMd8+YvYeXchdkP IgvHZRdExgUPzpWv+7fu+ax7bmTcQTK/cXrrwfnSwnG9c6W5jZG549r6ntwwtuk7z9r89bPGbvhf nrWB3Wwse9aT8nX/9qwm1v0ke1YTe1YTe9aT0pPys5quHEObWloPqsmYtrEAICv7OJ0W+6HDE2ob Yxc7R8ubY1TI+QPPUYGAbemSbVl9ZEzWgMT2TWlDaQPrwu5kXUY0m4a7nD8YFfIcpXuGu0Q0myNj SJI4G5eO+/p/5cqVq1havTqJfNVq1okKNm1oWlN2/BWzW7N12brGrNQxro0yqK0e/hvbKonH696s 41bUbajbVrez7kCdYvXqNjRbjoffDHNzwivCG8LbwjvDB8JK1nFV62Gpbmf4L2F+NbCJrsJfI3sU Ho0S/+x01WpMZuVKgoesRMo/Lrk6Oba1IUzmQ9qlkMxLiRUpgpRBmoakIP+N/FdIf0D6O5JAbkF+ D9LjSH2shS/lSxudS8exJ7bhjkeIk6/oS1dVjOxHOXdRvpw2O182Xp4v6xoqnOjvrc9oG0wQvCk5 ivwXSO8j/QnpKyQFX8FXyDfHnNlf20qyMkmxWgQnq1i2MrmKJlGhbLlXrUwmMYCdowFnWFt5eXE+ /EfoytUESwGAoMAguX0luwzPwLXDf6wDpFjxQ6QpJIDkhXblIST3EdJppDNDk3MXFVeTyNCy3ABv xeBnhhMhMXI/2Umi5BwtJy+RE6DkT0LUaSH3kgnkTXIAxoF19DWsZgQSxh7QiwDo/njioAryEHmP XEW6ycdkAFpzE/mQWnCfRtIJrbEm9ynyJnJ77ghGaclY8hNylC6n02BXGEsmciVYiRjZljtBHCSR eyP3Ls4eJR/TaO4gmYjaJ8QM6XwDuQtq9DLyixyzkkTJPPIUvZF+Ctmqg2wVKoUtuavJKHKI/Jo2 oTaVrFO8qzkE6eAu8jh10BO5U7k/khfASxfiTjeT2zHjXnKCK+PHKnaRIImTy8jlZC56byDvUSst 56VcYW5M7iG0PkX+xiW5n/IqzCNJJpE55E7yGFbjHXIaooCOVtFH6T4cb9E/K97F3JrIanI96cHM n8S1+8kRWk7LOQfkQw5vWERmoG8b2Y3n95GTtIm20RP0RX63Ij1UnyvI2XJ/zOVIMWnFDHeSF/GM 8zSNMXgCH+ZXCX5hlaJi8Ca84QLyI3KSvIV5fIh1/wf5Fy3G8RH3A25DblZuT+5jzEUN2WEkuYLM JivIGnId+TGg+hJ5mfyVXuA0GPmm8IriesW53N1Y2zgZg7k3Y/Q03HsroNRL+nG8g7c00yDeYiS9 nF5JF9Nt9H7aT9+j73FKLgRW+Sc+y7/GfyBUKxS5WtzJzjR5YMkssgQQ+AFW+2687x7yCnmV2mic luKN3sH1X3CjuHE4Hufe5D7kb+W3CRcVtw0NDH02dCG3BbanccC7Vqzm01iFv1A75lBEl9GV9A+Y +XbuWd7Ii3yEr+Ib+Ol8G387fy//c/5/hG5hn/C+YpJirmKfau7QtUNv5ZpyG7EWFLqaH5hUQirJ CODPImDT1ZhfJ45uciO5iWwhPwS+3E12Qd7tJ8fJq+TX5Hfkc0CA0BDmvBRPvwZYdyv9IY6H6H76 In2Fvko/ol+wgwvjSHDVXD03lhvPLeZuxXEvd5J7hzvDe/n50L97cOyAKeg9UGlByCkqcExUbFU8 pXxNlVBNVM1Tv37x7GDxYNvgh0NkyD30vaH7h14c+mNuZm4d5h8jpaQMM92EWT4EHNyN42lg4mHy U/I6+Y08179RjiqA8U4aATaUAGr1dAJEjUl0Kr0Cxwwcs+hsHHPpPLoExwbaQ2+mt9CN9E56n3w8 iHfbTffSwzieo0dx/Jqeop/QP9G/cUBijgc2x7hCLsXV4E3HchO4Zu5KHIu5FTg6uW5uDSD0FNfH HeHe4a18DNR2Lt/FP8T/hH+Jf5v/UuCEEiEl1AkzhcXCLcKbwlvCu8IFRUDRqFii2KF4SelRVipn KJcpH1QeUJ5RXlQpVS0QV29Uva3KqWOgWD/Dex8CTL/5SynfpCsVBcJa7hT2hZPvVGyiM7BiSm46 v5z/If9LxSJ6jg/S9+kWfil/de5xfjz3L34Fnckdp2E+oKiFKecOkqP7uI+489wfBRudzn1KE8Jd 9DluBT+Wg40BNPVXgk24RXEG1oDfkFpuPT3BvQLL1S25/yK1ih30lGIH9xYJCgOclZzCrt7EPYCL /odbym0lrUKl4gJZinXfq1iL9R7N3U6L+beFHeRjPsL9HdrV/aAab9DJQpT7PldD94HiDlI/OUu7 SCe9j0j0GP0d7YdMvId/ik7h9IBWljPQETC2vMGH6Nu8lrSxOdI4Z6Mt3DluBv+88iRfBbXnJPkl uZ7yNA3cufQ3RK7FDriXKwRNawQ1+RWtIE7yAOj9+aHnGcVWvKvYCjx7jC8hV5I0aedeI7XYGx/j aCW3wUZ3FDh4O0lzD5Ibcz10Aej+VNBPjkBvIymqA7V0YG4bwC/sXBi0cA4e/S/Q/1+A6jfRP5Pr aBA76wRJCKznDqERlKkD9HcrjgWkHWc/IncrDyl+RZqpgxAhOLQDWP4B+T54zh/wfDcs1HeBsj0m lGDWQVDmLlzxo6GJRMJxG3mNcmQ95jwa+7xFmAjKe39uGd5wKXjUFPDEV8nS3ANkLGB3Ze6W3FYy J/dY7ipouNNye0B/1+R6STXZpGjjZiqSQiVo7Kv0ZfCj39KtoNsTyfugRzHqJH/C8RPMf7TiGNki /Aa0sz53R+7XsLImYHl9CHRmMqjXNeTPWLeJ/AmSGbqcO5gbz3eCQ50iV+SeygWolizJLQflfZ7s VilAe3qIX7EbuLtVWMSlMd8iYqcptF6l2EmINGbGdKl+9GV1o2prRo6orqrMVJSnU2WlJcniokRh PBaNhEPBgN/n9bhdToe9wGoxiyajQa/TatQqpULgoUqXNEbGdwSz8Y6sEI9MnFjKziNz0TD3Ww0d 2SCaxn93TDbIrpuLru+MlDBy0b+NlPIjpa9HUjFYR+pKS4KNkWD2jXGRYD+dfUUr6neOi7QFs2fl +lS5vl2uG1APhXBBsNG5ZFwwSzuCjdnxa5ZsaewYV1pCD+q0YyNjF2pLS8hBrQ5VHWpZR6TzIHWM pnKFczTWHuSI2oBXzLoj4xqzrgguxW34WOPcBdmWK1obx3lCobbSkiwdOz8yL0uY1JyUh5Cx8mOy yrFZlfyY4NIs3oZsDR4sObHljn6RzOtI6hdEFsy9qjXLz8U9GrPmJJ47Luu4/rTzm1PcHPL5pm/3 evgtkBCDbPCWLZuC2V1XtH7rWk+I3aGtDffIcrHxHVvG48F3AE5NTH3Lcre2tWbprXggNIyY/E75 t8urP7GOZcGsJjImsmTLsg4Axr0lS65cF+p1u6UjuQHibgxumd4aCWXrPZG2ueO8BwvIlivX9bmk oOu7PaUlB0VzflkPGk3DFb3h25WFWPJ8n1yTh7Na05Vfrytlc4xMgtKQDc4PYiatEbzTSJYtHEm2 zB+J5cdfG8VV2QWAx9KsZmzHFrEW7SJekWYVMTES3PIPAvhHzn7+3Za5wy3KmPgPwjoZlnyNaFkw uWGkyyaT2eJihiCqsYAo5jhaPq8qLVnTz2UjnWIQBbRH0oK1ndtWm8Lih0IMvFv7JTIPJ9meK1rz 50Eyz9NLpBS0LK6D9Zy41GObwXp6LvV8fXlHBHj8LHg4IbasOv71v0m0WxuX1Gap/f/QvTDf3zQt 0gQdLNi4pWMYZ5umf+cs388WFOuGvuEazV+IBc8KsawyNikC1LsSyhwa8K+IjY80Lu2YiK2GOWat Y1t5D4cbsBrn4eVbAX+vmn3pfuykVc/uJcSUMv4v6FepgcByCw2Oz4odE/N5mzYUGt5e/08X9efO savk4pvLht85W5scfqv8O2ZHfef8O9PTb+GbpoM6cU3TZ2/Zov1O33jQvS1bxkeC47d0bJnbn+uZ FwmKkS1H+Fa+dUtnIyhWHvz9uaNbPdnxd7ThVZbQWiA5R8YcjNDbrzgo0dunzW49AuNX8Pbprb0c 5cZ2jGk7GEVf65Eg6LPcyrFW1siGBNkJeB52RS+nlsd7jkiE9Mi9gtwgn8+HNUxuyw9CGyXzYcSV 28RL4zi0Cfk2SW5rwx+jFGOntw6vlwx5rBjDBALfbQ31MhOd8mnoW0+T6UhlOL8W5TSUd3E1hBcI mYx0DqkEaRpSEKkVaQrSjUhXYFxW8TMiKmaSMNJk1CPCH0ixsJKEUJ/IznHPDO8jxSofxqANfWxs BGUPxo5Gmw7JorqTePg7ySSB5C6gHI/7j0M5Bdc3o34ZkgHPq+NqcvNRN6N+mbKGmFHXIzXiui9R jsN4A563AP0FOOeQzLi/AaUHSY/+F/HqEOGR45wo6RqUQUjN+RbWyhYHbiLIKuxPAU1BBd1JA2lF hysMaDMS+J4g01jkEZcyKykAp7dDr3MSFyQSD/HKXT7kTAdizwlBDohAY41duuhbZRz6SAL8vRhS WIks3acga5VDuslAS6mCBDIC+lsNpJhRkHYugyzz/8+/ennao8go2gBN42XOyknccm43P5rPCg8q NilF5RuqieorNTZNu/YxfUZ/zrDXeLdpmbjYvNFisxy3ni24wbbW/nNno/Oc67ynyhcM+IL1oWvD v4n+LK5JzCg6m5xYsrRsR+qO8r9mdlf+trphxLUjb6s9U2e9bOHoiw2lY68f915jMebAUcBH4VUw WKvI1IMcPca9wKDNHe8lCqGfe+FZnmhVrHKIEpdaqTiOfo7wtIho6NX0+8SZFL+oG6y7XDxfN3Ww jtSjLl5EVp4OmUPmGDLqFcjFIH/ioqQgF7CHTgCfJuZ+rpwPqwsPDAoDvg20UYrA4MNze5VP6veK e2NPluxNH1Ee1h8Rj8QOlxxJ6+9W8xzXzxdKBbC7Q4inXMBG+NHVnvFay3htP207LGDPVoyHRbxN cteOLy7mINnxVFc4cvRX1SNbyqhYJpVxZf3ch5JhjGpk4CvbSKNrzPTZziQmP3Xwi7PiF+1dKEh9 vViH4+zgWbEOxVnxLDVbampY2lSWXC++XJ52jl0ndSoaKmPpeCwmxUfGS2J1MTEeijvsTrvLziv1 MV8sU17tIw3R0T5ak0RtVBFqVrON0YGAj7p1qHk1qFWlKny0Po5sRGmtj1yWQFZgsvhoUInMbvD4 iF+NjNnD5L9vGcOKL7UlbyLttJ1Cyw1V2G0Fykg4Hq+qrK52hJW2AofdYc9UMOG4ME4r7N/tV8kD LnUrOi9G2/gPLs7YdN+eNc0bm1u2js80281RWyAdrigP8nsn3Dn16VWTNjc3b56QjpSWhdNl0XQ6 pLj6q3bF4wN3/eSFWfuXLj04a+TaE1snjfBbKqc++8LUzOC1s/cvPnhs9lNXL/3JzKrq8f/dNyEz YlLv800Z0JzpQ5O5G2Ghs5JaKXK/+Skzd5t+s5nTPqgxkwdheyJEq9ljDLcoqbKnYPr3GcK1nx0E ZIBtZ+vPlkMXw4vb4oVxrkokI2xKJYc39nPcjQ8s3P4jWvHFDTsuD7knrx9aEZuy6C665W1aTXPX Fo/7fOj+V945sOWphzGHMsxhpjyHGilaJBSrJyp4PNyMSVihYmq0mEDe8c8re2ytT/znJGi7tQqr bLGJRFVVXW3BUgPZHly47UdDb/7zhp1TQ66mGxULipsW3T103a+HfjFEr401fkavfuXX2S1Pshlc O7SPPkh+Dso5TSps49ocL9t5jaPDddLFayhRCYJJbSGHLZJeJ9SabAFbj4239dNi+MBMc0ycyeX8 ESYFRG6fOtgOFD572lIDrHXUlKexOF1WTIkBPxJWMcwAYmRkLLl2cZdGpdLFLAXltU3VYxZvG9pX Et7WYjVoCjS1mfLxK+csPsh4xTTaw7XCYseTeinIKXp8C6o3KLAJWZQITziRtkDK3E530ZNUCVNY 5SHwNrazxC8G2xmgUmeRs6kkrSFbaBqnGLzAOWAMoOSu3Gm6ArqtjiQlL5GUOl7SSLVVGqm+ao6G 7tQc0HCaW/XLrmf36upOJtm7ladjl3Acb0JJSmooK2toeEnOy1ISuy+fO82NBkR5cqWkIYrXAour AUhGPwwcX8BxmDaonw7aeUAqCPJpvoPv5HfxA7ySP0af4V4T+umKg6fYU8+eZwtaV1+3STG8+5Ns m3Gjh2wt9DPFD7+aqXiacczJuTP8c4ol4IpRcrR3rhrqnLJXoQCUlL0Gg7ufmiSLxk3iUpyT4h3x XfGBuBA3s2bjHJgjN8AIuguk0RU7Sv1Y2mFonr1cbO/6Yip7bfbioDtTaDQSDUdha4QJg1OqYl6P z+P38Epr3BTTxZ0uh4tThgTzPBJQuufRAiNqdj1qURqcRz1qZBbRNo+4tMgY+ZDJCSMkxcni4pus lZYRwA6H3VzAAVcK4yNERjyqR1SbgUB5FOIm37FqdsePbnzk9l/Ne+mma15urOmqXuUvS0drimrH VU2s5Hacoc1XNux8ZejA50OH7/v4xX8OnTl439zu/bTmzCMr06HLpg39CDA6B7ajxIrZyQNSgeTs cO5yDjgF4pSc3BoYLDhjgxU2xgZwml3gErxcV6MeAYD/hcCzpbADNKD+NwluahMMuFShUes5Hub0 f2L4JMliNJokc1XatMG03bTLJJhcjqNclJ4eXtxk3VTx7GlGRwBdkHdqriH/OHuR/iOZlKlKV7s1 ljEX2O0OW6hqNFfFFoBtoXN0cshad9UQ1zHSrlXF3LExws8eu7Cpe6Sfi8U4X/n13Af3Fgf9EHdg WsA77sM7+ukS6WaVU1fjcHovq3RKyFwsM/nt9iJVnWqSaq9KKQW/J8xWf88x23m1epV5leVHukeN D5n36/YbX1W86vi58z3He86B4JfClw6bjfoEl8Jjc9ldDp9TpXHonDpfpWuCa7NjW1DldHGcw+3S u5QG3sUplDB82ApUVsHQj2loNFKBvr5HQzX9fEbSiwr3Nhfd6Trg4lxH+QwW7s4+yun9/fROyUCU v2+2zrGusG6wCtZ+qpKsEl7KTYJSsCfIdwR3Bbmg6xj9EvvMQCWpYA4Mnhu4bdxxmLBPcX+BdO8K HIVx+Gt8Pl2Xx+j2qdhWIttYZwfbu+rqB7sOKpnA/tw2DT2ueVPDkfautuRpRsJkyID5cmJ+yLPr XXe60N9mrNskKta/bARDpl3d7eADQGKSpHyoipCqSoBKqYpU50kdTKacKlRRXT2C3zfn4gAU4eCO axfsjMdcbz6y+3fpyU9+OZrOWz5rvJsqhi7E6Bj64N6bnlzddeSnb29fvPjHh4bOjRTLmYdtGnb5 TMCzgk45QrS5gV59jYYFjNXpaxo0jdrxuqaw8KaGFhWNLJIqOyrfrByo/KdWRSppg2ZD5Pqyp6NH okfLXi07FTkV+23Zn8KfxvST1EX99I6+REIk/dzpvpNpmu7nKw/xCtFO7f105yGflExV+hDB0Sca ihLH6BII2RruD4gxAwy47TIMAMm+rJ7q++l2tJf2lHLbS3eVcqVoPzRHtQHv3s99LGmlSrqr8kQl Vwm6N/o5yXrcylldGUZwzlwiOKcZvWk/294F+LR3nYZcB9KTPNtdf7b9rKUmladB1WUpf1xrEpTh UCQUDcVCglIRM8bjWhCXlFA6j/pNqIV0hfOoVlOmTM+jAYOPURuxbtiVV3wT/gCxrvZu0pVMWhmY ZCRl0olKGRpmUg5sPkZ9GPNimy/C9iGDrGpJ7cGNj88ac3R9T+fdQ59tnp8KudzmtY5Y8aIHIu5A 8v7Lg807J97U8cgSYfLm+5Y1z753R/nhG7I37RlX6CtRK+qVuh3Lm5tG+hINfu33NzYv3vAko+FB 7NYjgK4WOs5vpITdQE2k0SCZeMlEi/XUpgLBpbxGoaSCXmcggt4gKPUG7CqvZFGpC1QqtZoXVEo9 /EwGajhGfwRZWkd3SgYFVWrUSqVaIej1wjEEQPBETRdJOo3GxNOd/AGe4/vpPyUnrZe3l4l2gF4N mHiTUlJRlcv4rT3UVSdDqA4bCNVPRCZ119ek8jKrONhdZ64xM97PhFUB0iqrmkwmULRuCEpd3dQW MUfMoSqaQUH5I4d3D77Erb5291CUnv/h0MN0UQ9/88U7uMcG57AVaQW+H8SKOKGXXZSKV2vWaK8z 3qx5L/ZpTKnk6Xr+euF6+60OoU6dUCr4iCvhUvLBOWqqBr4eDsZpPG6CQHBnn5MoGEPsMxngJKYS wo3ADnVuUiwVc1JxR/Gu4oFiodh1lI4mHtZFrKI1aE1bJet26y6ryuoq+oYtXoSQc3qYL8roCSIC 1Gw/2w1qIUs9w4RCB8cJIxQy3yzxxjQWn9fv5ZTmmCEe00SAlaJnHgkZUYtq4/Oo1xKcR8J6ZLLv mTHHJBBVRlNqM/KqS7SE8UVzpSVanaGQni+hKCM4/P0bn3r86uj2u7a+vvjG17fOfeFuavrX1YOv WyaMz0yatfn29fFZiiUxQ/OPf7Z5/kD26TuevqqP+g7TiUOtg+M2Tev4aEzqiQf3fRUEFkzJnYYX dAokoxePIKh3oM/qGY0Q1QEpiYpLTRV8sWYMkQwdhl2GX9BXuXfpu9yAAUsKHywxSAaeUwiQYu6R 3DxXwPOcwBsU0oQqxe+pEoXy94hYAhV46PAuHdW59Iqj3BnCc3+U9AhkEiShRdglKITnuU+Iflgc YWI3Vh0S5nlGtZPi2WReJtpkXP9yfsElzSrFKuVGxUZERLFVl6lyN6gypD6ITCFIn6rC/+F+M1QH F87Q1q709IxPMSX+1QvCK56yDh02H3wnZ/gtwDcX/K8Zer10tA3idyaQKS5ckbk+3KPr0fe4ezw3 x3riWzJ7nbvdT8X69M+6n4sfK3xF+4ruNwa7imip0sC5NYV2g8MdM8SMTfQOeovhVuNeYhxFailC sOikxBz6vcKrMsvIMrqUWxxfVrgkcwO9sXBNyY2ZbcI2RY+qR32z+WbLtoJt9geF+9X3mu+3PGJ/ Mv5M4TOZfuGw+lPdn/SfGj8t/LSiSGXQFNaSGjqyQjFOTfTuQkHORIcs/ykVpUz+sxp8DRrQEg0w n6U06iL2v0iqpCpOquqo2lU1UCVURZ5HB489UIw9oE07JMd2B+9wVR6lf4Zv/5JIeP4sowBnT5/P S4WMR1Im6UM4rEim/GGzXVDbYiFFBCKgyjePlhQUzyNlFlDhsACy7GciYNJeOo+kzMi+kQGTjCaD IhP8d2Pnfq0mqIDhsk5ZyNpiTJdguM4w36pkxTCFppsfa3997xM/X74vWzPl/YMvLp+5jpavldYs WtRTVV49reXOa5bfHJ/A7du4a+bG473dU3Zcffvli7q2vbZu7srZB99Zvr556XVrmiuXpIb+OH53 x02PXD9rYs0y0KArsBP2ACccpJDqpcwNhe8pfhN+r1BYIqxTrFdfr7lOv9awznpdcKv6Fiu8OtuK uFFqRaEzVOhU8P6YQFSKo3Q+cVLp2cIWUFNQJkmTiq2IQVojEHOUvUYFaNQdzzocxOBkFMhNTfhI QbQELbylny4ENSqSinqKeKmoo2hX0UCRUAQfsERCGCZpj2s5rSvxHR4KoZIx0cHT2Cgi5PY8cRLP nwUplqGFMg+vYk9UbdbHxZg3HokHDKF5xGdioroataDOD3ndjCysiX2bJCUBKAamdgfTNEcoZY0u L7TbCjhoeJQBKA8hmXsuv3ngraJHN2x7fdENP33qurs//OljL3AZy5h1U9tua2uYU/YDb4xbTaMH Fv7uud6te7fsu/D7oXU3LeOO3Hz53I/W7trxq+tmlgAKWWhq2/ks6JEDtl/exUItfYbF1dtdu6Bw SESlB0E3STYocJXbbbtsnO15GgPf+CU0eFlfBtpeUmOgCMIOkTdTAKOs36rTEFQ5ps6VpBrGsJLP 5vW6soZBq9xQVjaGcSZYnBVZ2JAQL8w5D8LAPB3hVTTg5/ywq/i9xBegoPUFL/C/Jw4kFZKW/73k UHNeP29Se+0+EuiEr5+jVG3i1CRVz8D0xsk3UikGIxh+/vw5TeX/xPWbXn5ZRCpPeySP2mgyGUSt XxNoCSltJqvoNrs9Hq/TpwxBFOyNVbGiL91aKZfJMrnsLco3B+P5Zrc/3+yQm3ttciE9IForDSYd bl5jmmwaL07yN4faTLPEGQWt/mWmxeIS/xqxR9hk3GLaJG6ybPbfHnjE9Ij4kPkR/xHTEfG/3Ef8 r5l+If7c9wv/b03vip+Zzohn/F+a/iV+6fvSX6IxNXm4AJRLLBLx+f1ejVHr0di9Do9dzak8apu5 wGNb6zeJQdHv9YbNYoG500yZu9TYz70qmTk/FGd/wLebwAXPFq6fHpL0atHE2+x2tVqj9iKIWtKY cA232yiZ+7l0X7Of+vu5zyVjUDK2GM8ZeeNTwau3yPjgcsNU4XSLoGZMD2ACDPLzMBgM1m0yliUV EF42tRvLnMlNkPKTTgJDnHjiP/NN4vqX61R1+Gccp13m2iyj3e1tNMTMW7ICBw12BM3QvDYnm0N0 HL938O9XhUfNG5oxw5UZTX8Xoe/WtE8b/PSKmsS1n3xOf/pOc2EgpYrFTM70PcJVFx68/QpFLCaU hUrmUAMXHfyAcawwfPGfgE/7YbMeya2X0rPJbP9mcrt/c+Yh96OF+937Cz91/6nwjyn9SHJ94brM wxUPZXZHn86863638N2EVqjt5/7YZ1pcXcuQxhuuZKX0B5ujMiOFSpC5/JUVUiSBzOOrHBcdF9vs fo++E30/83FMJURpzFAh8jalx13gt0ftCVu6rKIxOrlyFm11zS68nzOLRKydQWdHO2o7a3tqd9Wq 3Wl3RQvhRZU76k+4UoKS4/0Of3Pm9ujD0fcyqmCtVNtSO5+bz3coOpQdqo70GuVK90pPp39VdGXh 9YmNyts8t/m3ZXpqf5F6P/VZ9Kuoq01tCng0obAY8NhDkUwUzpMSUpUMRPlw0ciSDF8WTlRVaexF CYfDzpUlGKZsh2TI9kptlVyMYUVPX31DJTvtGzteLqUCtE+Z46Vaf9rLeWcIycDIknK2PGJjlUWC hMIRZAMw/LJGrcFcSQQaFCjEnrekWInSauVmlOhhGkBuMCAPA5dNIjfDFGSnph01tc/Tt0iIzKVO 0Kjk5eeTsAmcBe5AJ022d7E4yHK+9FPEXqM42wb1BXbH8+3dbEgy2Z0n7yDxoOeps7KqCnU1L4Iy GwIYckOqMpJw+qnK7XF5OKUyHgXbycQTzniGplTlGRrxxzN8JS3P8IWeogxNK8oyJOYLZ4i/gq/K QHGGylSHh31t9JU1JwjytLu7m3R3fc2+ESLSTvOMWhkJVckGXWaxgM4UgmrFqG3Mzjh1nnurzHmu LfMJFd975/i5Pac+HuzJzIg5fIVTM9zkJ+bfv+PGwRtic2ruvufyl44uaFnVdeiFmS9tG93q4Z71 j7nq1oVHZsSqI9388h+ESmLO6HPXLXrMpFLV3zz1uj32Cys8j69tvnu6AN8ChW3sI4UJtDpKOWmM xp+iKS7FpwL3mx7yP2563HLY9JxFp/Zj9lAomGfjTn6L/VH+fvd+/hiv0fNGgfNNREibIqUWzVEP xFbFIc5D6VHSzzcdDj6sSHh52s+dOoRwA5GK/XzDoW2GnQbO0M+npFSBhtsP2x+tEPcfMNOAud7M md0SEFBTF3RSkzPg5JwyejgnxRbMl4WsZHv3VGan+KK7a+rZ810gT4PQh89/Un/28/MgQmfByl6V wRu0eZR6mIDiurg9pvRoSonehkztUpRSrcMAZ+PXkMvz7O6udmqNyIsOM7WFwWCEQylEgky0skSZ EswgN0J4KxAY/cljm95fv+bsgxt/sS6waOjcsaEDR7YcpvX/dc+2YounwK1TXD2UefPw5qG3T/UP /W17156CQ3u+OnrxNTr92ES71ZNmXDICLrkO1MkOaYWX2nQene828T7x16JijbimYJP4oPUh26ue V31vi2qn2VLg8/MqG93kvt3PJdTKgIdAZg94DKGII+QKJIxGA+dK4JMhtbeu2ULzIlLaIlkUlv7c h4fZnrJMirC9OLq+SorQYIR2RnZFBiJ8JOSQd6ND3o0OebkdUAf0InajUm5Uutn1yh3hucMwYHtx EJgPKx3U1uQXMlC+2XI1NcNbzOv2m2xirCDuN3lnUrcNmc8cmEk9VtfMS8vPlDjsmPauzHc3RlCA xR7mhkKsOgGthGEhkpkZtXvZDkggxvGyF/e/OLT6txtmnqEVQ/9zbvbK2IjQSn75hmBJbMvQC78a +viFt+d56XhEGLroOPhoKHyXRHgWK56h1VK9VLXYe533kfRe5/70sfRAlXqmq1PZqdqg3qDpUfao tqm3aTTRgMcXCscCnmQoopbYgqhDRmNA41Gr2FKGWIsqxHEBpUflFT0cjUD+8GXI7mQZKRWZkYf7 FVhFSRIItdvnOeP1+tSa/fheZX89s/wQlahqVvG41ydSi3yvNWX7S5KB0hQuXe7eH4REc8rDe6a1 VHVCDeGriCiDSpShIsqgEsOxqAyqqNwYlUEV3VE5cIRukoU7BiYZVtgz7bCYnx4EuNph9Zc5++fg 6GDtQzJrB6mEf5BZJcSznxPxH0nsJ7kctrq2U3OI7QCYJ2STT4hZYDNsn6ANpj22PaplWyyjbGwv gcYh9rR4VWGlMhYzGi1Xzhh6R0yM/GTlkvTohsTqC5+l08mgwx2dnhZspkJbpiKxUMENnomUrRpK zPdGEkMNswsdwdTo9UP7Yw5Rms933eRPxIZ+c3WLzcQgGgJEWex4KS0+mEj1U780IragWiNotNkU /2DyaPKnyff4XyU/FT7VXhAuaDWdik7lBsC4R9Gj3AYYq1VaTTGsj3qY5+KSQe1R+QIeRyisBFBZ S5HCozTKvNMf8MRDkWRJQqvWCwo4MCNYfgfi+eMkISa4BIN0rBCeLrtDXZhM7CdFlBSloZx0QifZ rlTik9NmFT0uKzmHpDJilCFplIFmlCFpDPt9MiR9cqNPhqRvR9l/bDpYl7rrZJco02IAvT+3A4p5 4MlqDGNz2IJ56A1eKmFmAoUD96RmBjIAsYyLRMx5F2QGdvSv+VKeM1lZP338nzOaDbEYLWwc90+D NliSLh88mp4edxq0AbBR/q+GiLtx4TIA7bOmFUNVzZNjQzMXh1wWZyxWHryeX56vD70zpy3B4DUR 3OZpcJtK2i5N1wrjyzhXoTvBiU7RxQWrpeqO6rXqTmena23xdud2V9aZdelKU2t0m3S8s7rM3VLd WX2H8IwwUC3o+dt0J6r5iWrAxfn3sIVBLVIp858+mf/gAyfCN0ljyx8ucTidYWWihDcmwhqaDPj1 TPjwy4vsVzLKBr3c3GLZbuFMlmYLx2jnBkvOIlgEtictIKCnn5UJaD/3L0mnrWuJU1M8EOcgEJ2T RCbDxEXWH59UtQDyMwwxSUYQsc9SkFQAKnn7AVZ5fbNOvMSphqlkZTCpEtWxRGFRYXEhHNQQREwh 8ygaDIhmVVJbSgwRZGIQNhJNobKU6mLGUiZbQO5gkjlqxXm1Mwkxo50y0YMxMkAxyETsPCczM7Wz KmQDGVXazEplnq1h41bD3yiroiOET7Ftp697YWhwU9f9f+9puqMh0HAlZ3Bd7itYObB56LrXH5q5 qPe+1yavWzHSavXwYHHTd12x+o1n/vLS0In74jF6+6L6UDxeGbtmaO7o2ov/9c++J/576SxnkS3C fMmM2z2KndpIr8trhM9NkNiikVh/7otDDCKxyv7cRcnCqpUy7lfKIKq0YoBkZc1WGpZhF5b3S7g/ dwY+EoAoLA8MuxtEaJI+pBKkFFIZ0SPXINUj1UHH1F1GotGyy7gyr5Yj9SlZs3wDCuXnn8sZTWE1 kyfeAOSSyd8lT5Snkx6pq3PCrgknJwxMEKwTdnil6hZUOWCcLhQOBzzeULgy4CkLhRsDntGhMBfw aEMRa8DjCUXAOEpDkaqA57JQBCsQiUY9oy+7TKfTcmWlpV6vR22xhjkpTE+FaTCcDneGd4VPhgfC ynA/F5Tc4oSOCScm8MEJdEJjLFzVAp8FV7lj/NwPnMmp4vluFtQhdnXLxEAO7xjW0oAReVLA3oT9 QfWCTs8UrmE34SU0AB78++YHRZcjEv4XciBjjtJGd3NrQAeS6TQ3TibeIAQl6fTg8+lpcdfgFrmr fPDYMIlAD9eIRYQg9xu6cUmeMDjEhgUX7/uGStBHh+Z/c8Zf/a1hjGZkICytBeYEyIvSipDMhUMy 6oSkRJUrNNe8oFod8HChsDPgsYTCroCHhiKagMcciljMINRquNwY9rjUbKu6BIZ1rrCmU92jHlDz OTVNq1vUHWp+jvqE+qSaVwtsmFrGQHV/7l/PsmtRGZJ8DNfUc4OdoZ7QQIhPh1pCHSH+ROhkiGNA uRx7nW19bP4u7Pq8gCQT6DwUWB77TzI7vCPz686t/belw6LKSxr7Dj1ltPXivfKayXJN7iPejBWK kE+lUY0WOsc6p4Bb4Oh03KrfZzoRU1icNB2TYpxbnV8o8Dgskd3pFe0uRAWmC6QCrqWAFvTz2kOu hEHj8/bnvpLfG5Xzz7L1YBUpxJbOG9Zo0mpJvU29U31ArTiuPqXOYdXkJcYy/UkqkJfJzsaq3bFT kPoHovi+t7wvNPBjpsmdbhe/kBcJ0qNMGUEY4c+Cn1fmW5dkR9Ht0erdeu8oqtN6dK5R8B6C1jFR nfkTETdxiZYVgJgxn9Q3lEwWQUD+XgfuTYs7xz6x6vvLXaGSYKbQEfWk5PVUFMoLOrj0oRfubK8r dwWKv1c9Zjq/4+s1he1A+TesaZq+Kp0xOamRqB1GlyFhKjIVC2mV5TJ6WarNuYIucV6TWud8gD6c es35vvMM/cxpMDihYCjT49N8tbM6PcHJ29OFzniaVzoVaYeDT5IinMHe7ahxVrmq0vUVzRVL8EXF Guc616r0FrLZeWv6IfJAei95Mr2rIlvxuuNV54mKD+BgPllx1vEn559cAxVfkK8c/0zH8Fm5Y3xq Nm1zzEwtc6x1/dT5Svod5zvpj50fp415zT8Y8LhD4bKAJyHTJnUokrcFhAKeQugOYI2EFhCni1CX 08lsSaPTqYK005FOOaELYu5wVrscnEaNX+5IpwsT6vT3sB9dqbJwMBjaFcqGGP4PhJShHVIFraAc u4VBNAVNZqbFl8sbA7uCUSsoC1+0swognRrCzpANS7JpCTXmH6rZpB42LqlhW2JWpuEPoRkNw67q 6oIIg5BeyZMS4Sin+UyscTrNNU7RUkPUzhpHf+7kIUeNI11Qk3c6y58rtlEgTYgy8pb5DnFjTJHS r3HpO92UHz943hNrSQ8l0tA8CoxNiLahn9PTtCc1C5pIrCU1eCI9K2If/Iew+uKa9YHiWKwy2M2v mZ3wFcYu/FaQTy9u+bpjy4WtTPNjUtBaSEF64iEHpfIHLHtUe7V7ReE6uk61id6uEsaqDQnC2xJK jbOO/QoKB6MQz0JhJF7BT/Ix3cNdXxX0ST7OZ65jv5zCmTQBxONM8g6ryUxLnip2Jb9glW8iVCqo h0WiuOPWuFFvLoVDz1lKC1So2RWoiVpDKXVxyCxqWylxCMgY2frawnETwECDTB0LsXwEgthUSrMc hoKPNyD9nqVqesvQ9fgw7szQLR8c/+fhazf/8Jq+419uvhbiwoqht4deG1qCoIM6Ovb1g5M27Rl6 fujZPnxehGDLq/bdztaG2eySMrUvoWuPkDK86j21Vamy1c5VnlXeGxOdZfd5Veucz0WPJn7r+a33 /ajSVSiWJeI1sZrCUYl02ezCpYWdZT1lup8S6vYWeZu8v3H91qPYk6C/iL7neD/6Hix7n0WVXini S6gh2qtDYRrwqEIRbBdbKEJ8wZJiX6I+0hyBcKyyFUOntnFqFUK83CLsc5K7061wTyob1qRJGZXK smXczrITZSfL+LISKov1VBZIqCym0LDJKEspw7K+zFiMO0rL+ul1fSEm3MvGrX/TqNunMgtXPG/h QnG2LS/qy/Ys5u6vYRJ+3pDljRY5vM5YIl7kgOkq6kVW6CrO0JgHktcw8KBlT5q+ThL94VAgMkoI +4OjAMIAAU0FVSXJvHOpG8IjREhoCP+xT2Rb1aX4xELZWpX3ZKjoE9741MrBY5mZsQIPlHP618O/ 3P7bn5d3N1Rd6VvywMSN0zMt3A1Dq3sCJbHYyMAqfjmrNfVe/+RJ4wSt9rGe1gearMP2kCWAfIJU cpzUG3UyvhOTV3JTmFpujb8SeaWUnxR9qpRzBhxli6IIv9PE4jF8eUnxNV/0BnoDtzKwMrgmvDa2 hW4KPliKL1Fjz8WfL81FbcrgRnpHdGPhw9Hd9AnuyeiB0uOl76b/UporNeArUOrmLAlAt7y2rDa9 KLo0pS2GL8JLbQGPKRQmsYSHgHMawTOZvBeRuJJYNBrmaAHEi+h+RM2riot2yyYBB5s01PoWVYeK 367ahfAO4tnvreynd0mmioTP5+Vgs4ftUG2RPRKteedCY3MVCR0Icc0gqVzokFhNJeg6J6v56kq1 jFFqeR3UMkapw3abjFE2udEmY5RtR9XcI9SV90QCM4blD7GdSYhJ+bvxVB6bUMjYNCwvsihaS017 dyoJebLOBaM/LPxOFkxLLTVuYKds20/K8Tz58Fpvabkfv/NTGkllaLkfWVm4JEMi0XSwIkPJpUAS cGpY1KCLMIKN32yQA3IoVKbegpoEnOWHCxA25GLVc4fEmrRoqgGHZ8SGJEGsk8lQiDK+Xvh/QkUV 8xnAXQV9Nh96oliCz1CrMkGDX/TGp1TJSGljFiP653ff2Pb4Purs2LLi4mVWr+alV3beAlv69fAx Da35LmrW7129vj8+dMNtrXruXrrn5g078fE5JT25jwQFqPZIbpbkstxXgh86MXE6/OyPgLh4RbKZ NnMac20/HS+drB5Z7eY9whznHNcc9xyPUmFQGEnxiVphlW6VYZVxjanT3xnoTHWmN6tv020ybDJu NG1K7hH2ZESLIWOoNFT5Mr5KXxUzxpYKQX8wUFRUCifIaK5eSLvS/nQAgXqVl1VNNEwsnq6baZgl ziyamYRXLcB5MoEqT/V053TXdHdbxVWZqyqvqrqqevYII6/TFVl1nqKILlg7qihd223ptm6OPqh6 MPVQek/qROLF4p8mT9Seqy24XD3Sg59c8hygb8KPtIEO23IlQ9XD5YhnXBHw+P1HfbDuSpWuhwsQ nFinNxbo9cakvtgoxDVyAT/nIOSnRDkfSTAbL5X84Uo4t5hrgUYkMWU+buZO4VNt8wHzKTMPd9Sm 5wL7/UmRRb5hQGBnGT1e9peyHEgqIiKksjdxwpOyYFkahFYoe56Oh19/vOwaYHEP7ckusLnu8yxg rXuwuyYlB6PWMyPXsFPXUcP8VkYmUZCv9W+51k7FLliNZZtxdTStsibiuhJNhhSZGDG1IlOlcaot 1WeITl+SLBRBWk3GouKYBeRVnVIynM8r4jItzfNKYD9wvx2/K6GZr1tkWCzOTwrtbQiq6k7i409Z htHrnKYaIW2qySAxNttGZZMM895DCfPDZogNIMc1IljOnPFzeTQvjEeHAwDyaju/L2Zp33/VktuT oz99YWvTX54fVRn4b7fLB+eYu/XQ8vV3jagtHHrinikDzyxfN9LhDmnBiZObdn1/wxWjM03rF11z 7xUPn9Io6mH6f+vuuzo2zq5YVOL/71V3TL/7V1WuQIphPr7lELIyT/6rVIsPsrnZvtn+q+nV3NW+ q/3qVKg+1Bx6UPGAZ4/iSY+Koz4/yKQYCkMHM4UiKmcEbmDRpA71cyckKywwRHIY6y0mKHQt+CQc oS5cQnKrNTKd08gkTSPTOU3YYQ8k/YzVGtkVxC/65/h3+QX/Ufy+lT33uaRjqoZdpn923L0vuKCd +S+TyfNY+SPEDzeWrordoFdnqsQCJxFSKqscrB/Bx5KuCulS1ycyix2EQYWKrzIvApMZ85YUuGr+ jQ4xOwrAYhUeM8V11sDi6cc98ebU4ItMUHx8TqJysiouKqYMvTQ9WjviwvlLEqCgN1qXX4U4Bqyq LjegOIhVLaO3HCFp+NaKU5VpzLUvGJVLabrdW5lQ1iqnKNeZhFgkVlgRqShsjDQW7i5UFRXWFHIt 6VW6G0wPFx4v/FdcWWfMK3eBgMcVChfLKh7MEM5QBII9+BQXg2ZXXNSf++uzbNVQ+UTW7OQKU9aK mOguajRqSV+jRpB3UJ3Gjyoxvc9cUABdTja9qJWydofWw3k1mc1YGldfJaZpZ3pXOpseSAvpQFAG ZlAGZlAGZjBssWyw0hVWapV5lxWWclh0/OzJVlfqPFRD2XAG2/QlvZDFkcG3gD+wg0uNTJaV9QbW Xp5uumLdwRFqePPioYTWzGIeOaUpVhiLGoMwmZnj+iLYy7QhMVZKEjpkDLZ1jEXJ4WOwhsI318W2 LP03fRJOH5jMmNRzSUGX99+weZt/iw5kWpK2K86+/uEn6WAjc8pVTo+6fFO2Lbn1l1PBcZiCOTbQ Nfj+6x899vDNbf/gLOsvj8Wqot2DB5tf75686tC7XAyuCuCBBdrAT9ju4izPak3KAJe3jz1rp34R brLfP2cMcHaVEYIEs1bVi4MnT56gKRbuoLeIIWpX62r22qksTTjzgQyZqnwgQ0lKLqVbgpHKv1su BM6F+KOOI85j7mzoS5Vir2u/+3nFYeURFUyyTyn3qp62PWVXPKLabtpuedi+PaRYalvgWCWs0/aE FLPtsxwtoYXKpSrF91Rt6u9pv29ssymkUAt+w3OWYppSEQxVCiNt48kkoyKmLFIl1Albwq6AiBlK w0hyMqQYDkPzEmMoqLW77cV23q4ysFf0GJWwiqsDRhjk6uphyn7llVdgv4azAVKuRyogCuohcCN5 TEY1Bgccfk+gP7dJMttVyqBapYI0BDeETaFUMgTGpx4sLDxggphFOJVSc8FBHX9M2yX7dvs5u2A/ k7ZJthZb1nbOpgjaOmyd+F5DsPVznx0Ohu4PsfgHEI92F/wk7cQpW9eBbez7AsY7UDrlyv99yIMc W9f+zR9DUwKJupuprRqtExGfkqUGXvEzh8UatdpaA7Hx3cPWGm3CylrfPWiS1VZ2GX5PDF/PKBGZ hwg95nApBDKyoC4HlcOIEHdbpfjJxFhV0VBhbEgoFF2TRnPF3x9Zhh9hkVK1jQq9YkrMECpfeOEH wl2zCwIRREhoyqIVyy5+zJtXlfqqdCAKjBJ5ch+p1gMDa3h/HvcOa+jIoniBGdgnmSw1+AENrybt EXQWTodoHKChowafYgERv0ZFl0ZpUOHH2DQqrTatrFFZjE5rjR7JwyiaWlOJsoeVMCT1SGdQqdZU pSZr2oRWzVMaZVyZVJfoEvqENeEu8hQnCsurlTXuyvQE5ThVk26iZ7qyVdWqbtO26lvdrenp5UuV C1TLdUvcSzxXZ9YIa5RrVGu0a3U36G9wr/Ws964Nrk7dKtyh3uK9PXV7enP53aqHdPdY73E+5H7Q c2/ivtS96T3qpzVP65527/Hs9T7teyrVp+pTP6ftdz+b/ln6S/WXuou+L4OTl6QWppeUb9YIIz3L /SsC15YKC1UL1Us0fJNmSmBioikltHlmpa5I8y2qFvVsHcKLEcak03ntqWJvUaBcVaPTDGO9j1hG 1XrSGq+gM+dX1mNRq3RUp64phMMBlpB65oAD4jPUlyNlGeqXaLxetUajhakYMUFqfA/qIVZ3gcea SBV5Eha92WMp9Mc9hTXlIz01/bnOPo9OG+zPrZAK0mpVUK/ThRF74vG4vV6/Rqtlu8Pm8aLBm/Kp 1WFm50mnypUqBKC/KnnT5Tgtt1oKEwkolwS/6IVf1lNpRu1Q7kZgR0+vVMXiOxAWIod5xEvTleny nvLt5Xxz+ZzyjvJO+WSg/Fy5uvyM+o+aK3WeQ27dUS6IkL2vJJ2kb9Gf1PP6p2pH9XPL+vIbjYWt usTTTnHwvKykJAcZC87rJXKR33ksilXeed9U1MMtbFPi9/H+M/LoP1tUorFOjUMl1rE9emmHgv4z FRksgG3QggQiy+v9LAumkQWcFl29PIApJW3Uhu8W5O04vCPz7EHeklY4//LHtxqH92mkSrW+aoy/ IDl0WwIWkDeiQ9eU6gsaR9EvnFUjS6juo0QQWpzV5bIWcWJ0ZGUpFShX4rPHL8MOjldGNl44xs+/ +Kiw6AcOfNUYS4cjPxhUcZu6v1cRtxosavhW00WZDYMB7rMb0w6YNbCrOTIpdxa/AnwAX+hexk/K 72spWC9bzuvhT+Fm2Dyqsphap2NaNmPDMaLHL+yek3QWCzcjY2dDcP6hLC6gcl6yMZadkcdmalRy qYIdAwJAUINLEB7jF4pK0pV6SYOb6iWfj+VmdOn7c29LfjYIQfYbnNQptzrlEU4x5lfV4UvuFPxj gGY73BeM/L2RGmQc4O3kG/DKvCE3JU+c+F0y+bL49hvwKcAzs0Ln3ZLhLNOqqSUYqOmp36M5rOUt Sct6sj5zG9mq21ql9FnstWJ9T72g8U5RTFE2BhvDU2ql+s0+tdaoCpLwJNqknaSbVNU0YmztpMtm 6RbrbtVs1G7Umabbb7Fzgfo59VyHGp8415UVlVYewwbUE33uxGFNjT6hq8FrwRJXWyUCuzmG4h16 PigXa/SCvs4Jei4V6WqanXOcK5x8yrkB8Sw/CMAijjdO10l1HF67k30SUlqFdevnx0tmQVd2opSW dsRIxqDXV1Zi4S8CAsoZmWMUvy4KPRpPNNaQWCDWE9seE6TYuRjXE6MxkQ2KHePG4nNhGzZqoAbf ty2W/J5UTblKMtYEYZPoUSG4jJ5TURZsO3b02GtloQs6U3cSwTQIHB9kDksWLzC8/eBlxjcM5wdh sz/bVX+2mwVfmWvYmGQylSduvbyeIqQ8H0A7HDs7oWqUN6KwjhhZPZLD1xVaNT57CwfDnLJKVwO7 oc/qJRarKWDw0nBklKLGS0aqK4O0qlJn8Ypeagwjq1XWeZlShIlgcw7LbMX4Co7ZFfBLQ11QpaBH tfbWW9jGbE8SxmGfLcebAiMHekW5OGysGRHEu4Pd4nMgFAOSTlfjDOJjLyTwonOSWwfeq6sZgaRN aFFqUWpQamSljGHipb82vGcMBGDY3VA9Im90UNoc8le9clA2c5/Br8YMZHCu2vImDFwDGoEmbsKd 0erL5tzgL3rt81nT6mNxLhWPpbI7r798lNeidZhEva2uc1F5LX2gpHnczJFTNl5jdt28bGz5uLUz o5sXhcMltWUVlaUztxcFxiRvHXr1llEFKkPdyPvH3UPb61wlHTUT2ZchuQuIyj6i+CEii6L0l/md f9CPDxTOw3kG0V9RoCdOLdvxTiDwJ7KjB5WLspNbrrB9jsp5WPIxXq//vxr7EvA4qivdutV79Va9 793V6l29aemW1LJBJbzLFhJg2RZGWIAJkJCxZMIaHCshLA4ZrKwESJCTSSATvgnGuyEEQRxCFgfP DGGANwQmz0PYTDwM4TEBye8/t1oG5pt5b2RX1a3q2uvcs/7n3GAABZgtHlIHXF7VgiO9PiGSsViT o1BLKa7d92JRM7V5P0XkVH4SnRZKalMCZnEKHU6B4+gYOjZuMGSBQgYbMY4ERaJeup33cBdGuvhb B2mTzZbNgAvgrOj4s9Q62rzeURKUpAVfL2fZ940HjPtNryf0huwS+1iXkr1ad43+Ft2t+vt0D5hN K0ys1+zN2fs9ce/SYAB5FBG/ANX59J20JwzTBnHcMGV40KAzvGFD5eVg2maT7cP2Cfu0XT+F2W47 Eulku2JvQ3PWfsxusqP3H1xct49nnlitWS/oGGSnUOeZAxSR3+nWPlegwXMXuYshH1J0VlNW0cUV FpaCUSEUtNqiZqwl9EmFhawR4KONEaQ7geqI8LmtAvftJNE4ovvQCilkT6lY3D3G4eSmHNIhXQte WbJN2aKb7/7rf/je7Q8M/2CdUwlGWx3MU+78dGPjd76zuV7Pi+8e/re/f+cbU729uv3fXhmWUxNz +bl/7uh86rHdj0a80AmXg4YGID2S7M97zHq2ID/E8MeAYVwGGP0Zp8U0npyA6xKvhAfzkwhSPLPP A7sRjV8dIIkSa9eBxYN9F8f6jpzgkfajhNp+yM1xaVe1lmtCir5ewL7eIEY9a/XnwbJYa9oQ2RA1 XWa4xjAlTCX3RX6uHFNeFv7VYOlGtbh1wZHoptR4cDx6TXBr9EvuOzzTrungfXDxPpjai5p3vzD9 IvSa+Xj0deUdFjSKA+717tsTtytTqZMpk0thP0GRIQVTAgxDiAGyuFxtA12MJ6eSopCUYb1QiHci OQ237EKk62TSnvxE7CU4/37hz1hMeLzn4NGkhdrjbuAhrcnfJGxsyLbTJtqqMopkqMI4CvdNC7uF WRT0stAGUfjRVeGbwuJwmM2EGTKQgdA/aUTdP9moJbMbjEtalhwWv6L5cwnrOLZ1cm5y7PgkJ6ti ETHTSXi+Jrcedze7mHRe7JLYVTHd12Lgx5Oj6Bs9PT2ohEjpCAQK4RrOPkEOkk5+EiaHQZYbcMjO gleCM84+JGsMj5HhMckoqoqEPkFLR+eOKIRUQVmckYG36QYyz9307VcZ23frj9tLi+Iuayp15uYz zvnujovP7q6xC/b/jBlfeo45dg5mq1nfNYn4wMXf/f77SyrX4+mXnjoOX+odcAGVxdVN2spWeWy/ YEQEFWhDHq1vEpugxPycYfmtuFM4JIieFO6QUPje2PqeqnkbgsSylOjDAHzESFBjLZZwE+uSParF AW+DV4AdZCqViBw1zlUF99KgH0UoGEfkWeJipGMssK9z3TgKaR86HR0anYgxNTaO4FvCitNY/ZyH +QEXMo7gDhEAN44ogBFgLhI3U5RqpcD34Q+HeoHGaoVztaNFjbkR5KRI7OLFsbGjyEqBffUicc/D QhXm04oVtSo+kHoWEhbGqzfqbzR8ST9VfbA6WzWp1amqKFT9rb7iiGHEvLb4TROKMzKl2i2tkNZJ 39Lf37qrapqtniyKiiIoyYdB7XA8qcsWK0PKhconpCuVG5QZYUb5kemw6clWa9bsydn63XHPUl8s 5++PxmNLEzjMqi/5+FtLlFiplNBZE4I1aUMe1WWq2zfun/I/6NclYGGL/jcKw0bcK0YiqdHyIPLZ llSWbG96dwZPzG0dA8aQ/qDqU+4qsUeZ80cgDinFm7PJcLaoN+cyWXNBEYp6zPKmjMJaDSXOGMlh Q7hREDinb+BHKbtgFNKZmCLgukDrNsNTxBk1cRwwpOouYNoWaFj8xZKpgW++/N7Prh8ChwwX7cxV dib9kbJ1/mTFuPiS6oZlG3dfufGy5We8//OfsxWDf/sdzijff/G7K6Ku1OQv2XNLJxpDlz/1q38C RVNO4HnIwfECgLStSdF5sx/yzkawdgHRPyyaSD9fmyowBaxBFJAsg0KEp2Y5r6SG6nIhdI7CyJGM y0QIUSQI42c6mhr7iaei7MupZ/kRaPzqIPUGfbvVCgIi9gr+SnlNWALnSWQNcVw9CizTAjXHfFPC LrAjHd2CKui0m9CuqCFb00TCMmqt7zah/Mw4FMddJr3pq/rv6fcA0o9LmfBo1BOzRN9ebyKO56Qm nhZkT0+LhQMgEMwdifjHRXgRqTy417EjcNx3aDlYIHuS5SH3puBYaFwY9z6rM4SUKNS0aMOvRhvw +CCNYMlAzZwgEUGryMuu8c3ntVZqEWPIssFzoX8TMvQ3hk3IBDaaUHHA4Ftl3CF+2Xir7UvyzbG/ ER8I7vc8Iz7vfEF+R/x3ncc9bho3T+DpdlgeNz3lPGmCpDPZvyjqLNRPjOgnA12W5eIKy1BirbjW cjHqhe7w7Ajd5fm+5fvSIfN+y27pF+IfxZdt70he8zETqoEcM4mTtKR3R+G/3TAXt+m9QpvfR0/g cTfcm3zbfTO+l+B18kX+kTIiTh2DAMHi1T2aC0hdCQcR3vEFEUY0YPqN2Z+PNJx+tsW/3b8TfrN3 vN4pgi1Nm8U24HBeMutkAHLwJObdgDQZzT9y+PTCDqIrjCXhbnNQfo9OcMgOxaE76WAOuhML3qVj SXxJU3OBCTA4N0lqyyTlLgOPg7gfvhE6KPraVgA2SNfe4oOuDfOAMi0geiBi4CLv6SFc6ZIN+4wC E8XJUW4c4CBNIz8smHA1a6phU8sNOyZ4lGf35MntRQviEXsi2lpE+625Jmlrkvabha+pDkvDh6Bh SHE17Ji4ZU6K0uk/1BfzGLW4SKApwcAL/Mi5JAcaMiNfYJs333r+zeWE71ff+sEb/3bg7ifnbmU/ NMihS7rOu0lc9JvPfOaS67w7/oWx599gpl//qHdDukf9PPShIcBJbzB8WSiK5mbvzpS5vCqrpC2X uV0dgXfZYWRmR4GZSYgxN9716ypGUUHXd9OWJgjASOIJuERVMqczcdQMBazoEIvscRsp2+3ErDzb dxRxWU0oQSTNykfkJ+kfFCY8a7MjH0alDToGWRcRNVYwpnEmc4FgB8YRZqQeyLhezW/jOdXKeyPf jtt6gevXDke5tCCCoGEXZ3H5o5BAVNEkop55u3KX766sbqluqW1l6GbdzTbD3XpWLW9P0sA6M+YZ y73yva7dZYtsBJ/a1LqpKEbNjn1x81db2L646ZDOrCZS8Zn4Y0j9c6UzAVYchvHb1lpwu4yAXssg 8EPs3L07YfAeEt/dw1qLh5is2vMF5na65K86nSxNxLp3fLzGl7292rKvT1um2/lS9UeTtWkHIxLf 5JhwzDqOOYyOUOlhlIwxaRrUGFmsRVi5IF1u2y7G4pWx45QoBPfbYiTn983BsgW35PLHncl5/dmM L5vx56NCzpuOch8R4c+aUW0oSR8JCRHuPVWH470LynkzJZfD31tg+fk6fey+aObM8+ZeLOTPCu3Z s2H/5BUbemvxQOdAIpGtqNE3dWvm7ptqKaXT+aUXi+evXLzjp1cvLffE68lPezztlz171kqQn3DG /HLd/4JOvkhYJYzq7lS/4PYP35m9q0uHZION4jWt16BEXquxYjz3dkXf1z20cUv31dmJjTuRNX1T 4IvBnfUvnXnTsp2rbxn6RuAbwbuGDukPG/YF9gV/Wfvl6tmNxza+vPHkxkhY8XXKdW9XYqPhfvNA V19E8Ou6kgMRIbTkw+qsFo/HazHD6eAGePf3+9yQSGjM7gUki5ZwIFn7ZjIPZh7L6DKH2L37NxSn YGxhV9VO+7pnAHV4LKkjY4GO4UscksS+anB6gA1QFZQB5Kz2DZSo6wxwcCIzq54tZrYdFQxghSIg VTfetYQtOaRrV22hAakaYsOhKVRKeVT8B9R2sOgGAfhtVyWjKYRq0qWSc/CnujbIuzjmDWFQ16Ym ELPa0razbaZN1xYk+dpmI7HXVm9UdFNr2Vp6Njv6Nhq/2ifjinwL7YLGSSS1oYOtxXBHDBiGWRVA udrOPBvKT+Rn88fy+ryD9sRPGoASjbdUN+mm+auVjW0b1Y278M4NG+nQqNVW2+jY+c3lbDn34ixv V/zM6Z/wPw1mf+jU26qLjvPbSDHw83tEtPNR1XNXH+sDBn9YJw7rUFdJplIVeKWhWI0vcVYs3+H2 PTUO0jPqrjh/48PsOiHJpId2INihxddgVWydQ/8YmzxR3HpcLk5qCM2ilk43KR/nkHZwpKZQmHuF RESffIIQr9Aytsp0MEQFpMS+p5MvJUXICcTjoZQBerLv6cxLGWzZStYsme3gOKdrx6DJe9wNq9f3 LkvXo7FAkMEx0NHe2V5r1xn7s0PZSqY1uy6zNsqii5A9vLo+qAhnsT5FOMPQFxWGy4NR4dziWoUt DS6PspHc+ihbtz7WG8HukUXCmvYBha0eqHep4hIFfPxM/eIoO7t6TlQ4r3COIiwLLEGdPdyl5mLi fibN2aTF8ekX/BHAnv6Qp0TCbpI7m1SpIoNG6wAeVkAQDwF/iF1HF9LzAxxYT3a6MZXSMqpz3A1E LiKe9UcWPCWXEQq/m8f0mRb854F+FITjwR64jYBuIdcyq689/+ium8afKDpQnUnnLF7bc+QHS1eU Esm26MRvzxjb8slvv//4zautrrppU63YYL6BzUtrw2suXtY5/161rXfzo/se6Kzd/S/s7MLXRm87 ohqMlkBYMhhXTkwd8GYbXpdi0usMFvvEuZOXfHV9R1cwmDnLckmiPZG6ULz1mhvuXX/W1htmzj/r g893bsi0pc/cvrLm9+sh9KnqpO7fYc11iTubsjHWA6EnjsiSS+KCUAqmaT3IQ/Vwi77HQ89ovKwh +IMO8jYHkVHxOrolyDSbrNVzZZZEURZxJMnPkSwH6RxlwibTVjTe5S4rNLQ+hsabqpMOL/PzlRms MIzC9weMOPcHIYMpjykn1CB4nXXux6p3CTlXrITQTd8JBLZgB/I8ABBl0x7kfif5yJMdCDSQVQi7 EAYiieEFbXpDDd3aOFLnc1wxV8NJ6ZSunMTFr8RFrsTFstT0dPFNTd9XsKebJfmeSb45yfdM4mlO cs8vGhgyC8wGjQ8OkhAvl3u6m1KbC+1mGzZkkcJzMCPhHaN+BSKOqNUetbUu9YxDb3ZmnNmpnuke /e6e2Z5jPbqikQ33jPdM0Ca1hynmYCGOqB9Kc7WUC/HcQItUiMsDqWQhnj2kc6iVVD1X6a/F60uZ kusS+FNCrXK5ZCkUTFumJbZbYk5pQpqRnpb0iDg9qiLmnkxXEuXh8nh5oqyfKk+Xxd1lRulxs+Vj ZX15vPs+WIdwNEOhJM0SGigtFwJBiPa7Gpr/jF4+ZxXecNSAoEckGzWEoggdh00xEs9NTxl3DFOe E/kxXCSPNZcsupyG/EVvo9g+aYMmbhr6kvVm5hpthC+NDW75Qv/ZExGPQ2pT58/0qR2SLrG0rf2T A77G8vneM1LeoDMR9lUdzG24Y+7iG5atu0D90fxP1sPPlk7nsvLZbOk3L6zWhuajF1YS6bRH6lmn O0OzHikysxgzE/qLVWgRm5GZw0IagiBGKqLbzsndnuSejCSHQSY9QZ0FEoTzcjRe5oSPxrO8I6Hx 2wNE9xY7+pTG8dH4A9+LetlCd3t2P+0VVMgdEhhKbkluhxhu2YI+PI4ijlyT5VY79UZji9EDbfBZ MPWjY/KLmikJ8ue94Ci6BHhmER2Bne4JdoX3gSSf03n2rV4NZwc1+vu1hhrq7jaOqOTq2mUU6aIC 3AstJg893rtqlHoS8i5Tdt4f7CKRvZ33B3oyrT+g8S7vD7SF94dgMJ36SB/gzaO49xeP9h0FOXG6 4V0hNJ1m4+mJ9HR6V/pk2qCkh9OiSrM0Cc6Ojhpf9vRqS8Q4+Xoqw5dqJRSuoYN4Blrshbgb3SIX 6lfiyaW2kM0zjUdpCChRZPK4pWng2Bokg/csqdNCdfbVdZ+y2ewhezqoFhu4cURxunpr00E2HGTj wYngNErsnQwagntSe/6Gdwe6barNSCklJzQ1FeYYHk3zklBX0EQUSF1zC3+kVIfnNF03EzKbdF1o XbSotXXxos+F2vvnlyypRCymeDiadzCv4Q76YXFr66L55JyyrgFCDi8eYRd9o6SEnOkJRBUumV/O dhp2gmoL7EiTz1vzHm4EeRL0/d7ZRwyaN4iQ0dAID43nVI9GnxptS2Qz2WG9z/ND0HiT0yoa/8xp FY3nVAsdkhCMhRzRqy2PDVCfCv7IbzHS74mj5LWTnz2qMWrwvgXCLD4J2+XAt8PMGGJFetN93XV7 cQ/Yn1ocLk4Xf+j4YWxX0ahgZaqok7HlWFEXNudzSn8unl8aokcyjnjCltZQRCnYTCj15kAkBBWZ TbiycwYQJnJ8LW7VPjMAirpKMRAI4/tqVMtdf9SLQbvpRGJaYU6FUUW+k4pOUejk8Ff+GRYjdlD2 tBb/PknfnMPAifk102LOlpdduvSVwXfw9aFsQT719Wme3t3Go5F9nN5ObB1FEZvFzapi7mKzSCJn knI07nDGMlFnIsriDkQVOLxWs18gJiYRNPs4wUAZgS7CzRdSOTSkU5Nu8sXFi4sgj6mndm3c0J4M R1wXJYMV/4fUs5P/3FpcPK988Ik3jp+VSnXYTesz678ifvnOYpJTEENFYdRlA9/r1j3WpJ9iGOos 0rH4XAOKudDbYTnzObYQBfhpDt3gVU4j1FCLdFg22ZWrJFhTPeB5W0kjVxgqXP5X/ESP0M00PQEN TU9A4y1IVv7TvJbBWZGZK6HPSqhLBU0dFwJ95h+BtpAV6qA9dxfXFrq6hWwInxk3aANJHgBOEfuh WOMfHpKM+ELFE8WmEjGHUDXCVYByaEoDqRHF2SfBNQmwgFRcEmaEOoioh52NREN0G2WG/1+zfEOa tk7b7nHe7brHfXdiprFXkhqhRniTvMm1KXGlvMW1JXGPaHkjfiIhTlk+73hS96TzNfE15wnXn9zm PhfGGUz0KH2N5c6t0tVOc1VslZWMkq02EAmQTT55hJ0rr1X0KXk9W+98Rf6zbFjlWpl4wvKE9L8l Q8DilxOxRGKZeJbTaHU5PfawLeaMOxLG83QjiMaMymtdaz3GkDMWiyfOE/XNwEO1C5IKlMxknZSr 4x3diHKHnwULlJCbYbPh0k3thjsFk3j7r3C9Bo2TnI+j8RfOxyuVRk+Tj+N98XAf6TNHIYC4SsOL 5uKVjchOJrqQKiqHEuF4qAJVJdciiZa4RJpKLtWVq/bX411LhapgBd9JKwmvwkQlAd2wjYmoUS3C +6okPEyfE52SLAelbkEIHGJvqmuCtt8gQdMIrSYUCkrWNtuUTTxpY8dsL9vECdssxXQCgRkgGMKJ BmtAtRHS1apQkZEFQikgBlSznqpMo8DweE/jELtub/I+BNnRtZG1ho4N7fJseStlQZEHDZ62BTUH LjfqySF6emhuRDioaMKR+Bx4RvlQ1BCwQ7ApATRgPp8DGSMfOWIyjUIobN06SSGfrU2IC+DGk4iM HxZkdBsv7JVEHvVUMcVUEF7e2RBJTlkbVlq4Gk5tAZZNa4jDzj6EvDwi1gWS5UAYF9ks8LBrkDST ycNtGtKvwDhqObhGtGo+FARf0LZIsRp6bcBmTmbZHed+uv+NNy5uaUuHzpxfko3k5/8YqgzOV5an fFanQwn7Wl1MNtzxweQzS902mzeG6IVYWfT8/D99Nll1SOk083kCneyy+WOjPUGWTrusgeQ5urNm VkRcqQloM2dAw3KC0/jYVzROc1gIQL3g+pXXZmSmpn+O8wzGeQYqdELNJsUHjde5hYGGpkKh8Sxn GGj8fj+PjhseBXMwYzJhWD/kFXtOx8UJp/lisYMMiWbnJ70cNoMMuXRaV8p5uJbk9XJZgzABxpxv eu64EGFciNBNaUoPGsS8eGhcU3psNlQC5n5+mCSk+PfxmBHxlIPTgdnASdSnw+fb27e8Rku1t7Go xgJ77Ju7hgNMDQwHxpEhOh3YhR1NtkLcNNDCCnFjLrUQKMctmYySwNJ2XJufhpZquL6oNm1jwzY2 bpuwTdt22U7aDLY9/o+oLZr63rf4dMVeKnTN/Wc8fP1x3WRB5f5sqLZivq+vEnYkguE8ClUZ7ni/ f11PjOshOvWeFRSkJrQipIixDV6w9bp/bEqRwCi3Nke5Dzbg4iqGa2QNoMkav0fjdf75aIvqpG/c VuR7Fdu7ly/shYa2F21Rk7TX8v4V/Xy/fk4o/ZxQ+td4SaysWTgODU2+oKGdAI2/qJAT2Emi06wp 8sOL/PAihsIGxoqIqJuXDcD6MypHsndH6cRYhxFMR3cjekhzOke3i5/Dxc/hgv7wqnYOpY32wfoT 2jmUVjoH1l9QrXQOikDy9Q9AoziP4g9VO5atJIVKWbF2RKV9qiNsaGTLyPYR3cg644r2YKZkBSDL oCE7UGaNopLFo/IcRNrs7IJAI6JryraPNJukDnoEvVMsqgivNVkJp53W6mKcHme3mgymtSPrTMH2 FS5O8S6FB1CVIjeCi3xbsbufr/Xztf41eK7XuaRQlA14T+9xOcIb1DXQeJv/2t29Ad/gLd5f0NB6 EBrv8V/XrBnd0Ow4iGvgFmku4875hIeBzOG2A/xb8glw1N12DFHzGCARrwrLMFUxtZ16dX84CGR9 kGKQ+BuNqNGa6djon/y6KZido2RtI6I4PQqjWinEkVr7wb6W7kK8HQ3V2rKmEF8x0OIqxAOwq/el ioU44F/2fan+Qnw5GuqZqZHcYP/a+MhSc6F7UG0U8mbBlFmxbj19mEzJJllNRr3BtGI5UrIC0ii0 T5RfSrYpbELZrYgIzNZVZ3ehUkz3tHWzie7d3WI3bfMPru9Pr1mTGBweFKcGpwdFYVAeFAfRrw94 /bXB8Q2jh8TzIbO2Bw+xzTdzlbSpkcIOIbscVYe5eX426aYQXvRH8NXFKM5FAmwBvbpQrRtvt2mz t6BAjT2TyqZtSUC8nC2OzEdtdmC5ikAqELilWzPZ/wvDvSlLCIZgNJkCH/IRLmJoM6JtH279qAbb yYY3u8uXd6670XfZHatXTSb9dqnrjPnFnkXJgKSP5NbVP7VGFH29y+fb1zSshmRpqKt+XjnUvnp+ UV9HmOu5OSfzFsU3NzuzrZs3Xbd69UjvjfPXrFP8MPADcso1zL40UVHrK63F+dXc6odUOhfb2tVY qXved35XBOUfFo2wC+8sLejDNvjN/g84Wad4mpPVOScjR7Q40s7nDrPTnyKWUKFtqVi6YOYsqVmn gPMDs5+715qZMBwXAb+xxvzQ0CCcaLylZqm/+4UYZyYxfqIYP0WswL1rBa44FxYUZDRIRePpIhqT w5a/qBKdpSBExTSo9g+qpZ1bZu0ddirpSEU4WjDB36Za0s50hylc0lBi1Sp3rskcK/YxDxsC1EQp 5FzjnOMIsY+PxbrUC6t+EpWaj76dt/kNtGvnd6YpOdI4Yuacwsy5htnP4Rd+vskPQAngGX5AWmJ8 zxjfEOM/xviD0vG8QRdC4+2DdEihUK812cX/19kG3bS3Dm+buU79v60+jPqxE/XpuqGsZ1RLdqI+ hbXddePu+rG6uLvOxrFhtq6Lmf2FuFNzvBUK8fRAi7kQdwykYoV4SnO8teda+9vi7UsxDHxHJ3+j 6VQKSQ5SwJ82TZvZbjNzIgA8Y34aY6GT4w0l62Lp1kRhGJVRUYNoqjBd2F3QCQW5IOLRZlULOnxh vKY53wj2+T90vrmDIZ1RnwnpAlGG8vWG8EI3hmmJQl6UUcPguqCe/N953tBPKXS24I5rOuMIw8ZW f/erq69U/A5r+1nzizxqp6TvH7z2GquDOqJ3eTu8blGtH554YvW6xTfOX78+EeI+N+cQu3bb5Bfm Y2P+GHrais1s7Q9WhrnnAkwbeEj0M6cQE21NnSEKNZA6lI2jhpo2nUxgaFsYsfh3uL5ADdVDG/V8 N30AeGk5A52PIqRcEjbdYR+CKyz0O+0XpoMjRFNhvZdTnNeGakHQ4CD2McfJoQdQU6+P22wJDpLg ooi6AWQRvwiFYZe5p3zsfv8BP4ZwtRyJPW8xuv8osZWWZf71vpvZly07nM9HTAm1o67n4IiZBHvS 98uwqCbYKvPC3bhxuVm1CP1/CKSoZ8doPqwf10/op/W79Ub9m1Qktk+1zcDEOY0LIFwwOWaLq3fn MbD28DnnP2SLr3oooV+FUdkeJSQ06l/PAj83SyJwyYafCGFdB1L6vLqO1+TXIh9ZhXRACjuPKyNb q4vF3KhKL6K4rpQxZl1OryJg4B2F+S1oBU1oeeyywiI6zHzWgCKEDJgRh9CcXtRC0jqQwKA1UB3w B6rravFq4w3SDY4b3Nf5rw5eHTUj41LLtbREZVcjggkojJMPWbVADUhUC9XC88HLJ9OQPIC3ATDA Ay6icOxzn7rm6e1P33DZtt+cV//UWTNfuOhzV6zQPXjvrQ9+9oOpH9z+d5/7j2v7++698an53+/6 2TtfHofRceo/5gd0D4PWckJDbGnSWmERx9t3SK2kgVE4APOgJyQouoKH82CPwuH2UG/+wn0caHzA +S4aTRSuossX3XqHMUzQAZTNVa1QPyoZR9coKndzLixwLiwwUCc4LOIZiGiA4X7ohQCOALhcMFYw 26Mf2iKHhY5TH+wnQuyQiCaBqDOOSNKiXtwdp1sP55Ee3AvJAO69ekuNcJtfwV55oyOH8iEO3IyV 7oZugL50n6yFISiRC1cE8zzGTXpQN1H156RFBOVpyKvkjfIOl/6WEltU6lu0urSx9EnXJ0tXma93 XV/6ovkHptfM/2Gxty3a0Dlau7KmVxexqlmXL7g9UKtCt7R4oFzlUkIuOZSLY4w1dzGv01eQQE93 IiLBwWENBR0d7QlpWhLHpSnpQUknvaGI3IUXUZRhwDtFhKcJ7qlBPA3J8V4C9FKFNSretYDlXYwn Ig/sAlytWNQ5qOooatuCopVq3WQ3Z2pZW7YtUzd1KKxqx6zT0qWwdmtFoSBjk3TBKKmGDRBro6O6 TKePNB2CDGjhQCS8NzmjH5rQAm80aAwT5vTCYEEiC2dX7Bz60gWTt038aKAr3xForJ5XQt05j09O xYMZVrM4Pn3e5jPPuUDd0FZN6xpbn73+oiu/+MyJe7b7nOX51y7sjKOsm9/avll38Whb0LF9/kdb Ur0bzv7E4X+YPDuIweOA0pzHOHug5Rhch880aTmcBUnA9ebjBX58MKXjTVvaQTYJR2Y6tBoXXA/B 1pc5L0XjPW46OwxEwTCdVdkUMzrj7lQmaCyMuq0mh0Y38H9A8/7QeJ7lFKsRzWyklVhopJXoMNJK NBh2huPrZB1yJkjlVoK54bKoIqni+/ldZX1buC3Z19pTHJLVsJocal1Z3OAcDo/Gh5PnA62yRb44 fHFyS+uN8mR4e3wyub14c/ivi992fjP87fg3k99qvbf4Q/994Qeif1c87P8pyPaF4pvF94utSvmq zFX5nZ47PXd6Z8um81CXDJCfuCnXtKAjQWc8oUuFC4weK5XBKDAmoyMSERIJB3mOq0ICQzKJ4ygm 8yDTMTM9BXsj2y4jMVF8zPe0708YQoojAXxLSgvYScpwR3oGiWnqTxy3cqJvjuiRSoFwIgym855A OpAFXNKDWcafUljOSxBKoj0tfE056D3AZoF/EoJlQQpzWiPEFHzAhPkNAODbDJJxwG+X7lPBzoH5 Dk9PzBvceNuqm/+eeX/WGM/21m/Kbe6b2PU3Vy26QPfg+5/Y0BHNZGRrA6rvlUNv//o1llGUaHqu yn4Mef3Txw/PopwXjxiLB0FZeba/SVf5Vs4jjYmAK8eV01wwwZqm/EctXwQGNL0WDU0jReMtDSGR 4IZ5gquw2Ao7izhtAn5JDP1GztwgKqr8QXUM5bbktud0ubwpaANAqO8oWbgnYN/ixX7cYUtRrqYm uhDuTdHpsjh2i2U7Ku7gBEEj7pQzShe3YF24NrFx4wgar3MjlBocb5VItBY+VCYB64Lb5mjTu0kB W+Q0wXxzdogdTlVUnV/Qm9RWtqmVJYjLcXvxllQOgYpsPLdUkKytLq8iM32QhgxqyHC7jmL0LBMs wk1GhiCbsZJoZa2CC0GIhMKmlGlFFBQZFuIsQPQGZbxAzkkqoABGx/MWtgJfzikLyI4TYyAtnoTb BOYSkQH9hCQYJMKRcqdViW9aXU197j87/NZcdX33ylo6td7n9pXbPPazzpwvLm8JSQYUjkzkJObT Pfjb3y4p5bqWeQsXzq9ak4PylvZze+qSXWdESYEDvWw+dVz8HeilXV9r0kuuk9NLJ/J5xBGR8Vgp 47FS5oyEzTlkP4ojuSTcmRr7QeMdtYPowdluMuecSb27aGDXG9iVBmbIVBljrabQtXF2CaqiZ5Qw G0ehHzHsBqYWKFXoQFUssRiDZ7aPFD/ofUefOSo/o0nS0269jqQzZ9a3+uPuikFsbTdppwm5VxvY pwyfNYiGTKtpaZxtjn8GkLiM28roDt9WwTCNI05nZ0fY7KCmOQe0oHEkl+vs4NQCzIG2PAIdagz4 3rEx+HvH+uQjNGwBuYuJdAqWUqgkut0V1dooIZ8p6B21nZ+9R/562iCZkNxUGO+c6JzqNDo7DzFF vRXs8tf2XzuOpI9k/in1bPr50iv6V1KvpF8rWd19pbHSX5W3lXayneJO3ZRvCiN7TEV3lHdW7FT1 RELpZ2NUKj3V8suUOarze92o2R8qREp3We6S7lG+lvpa2uou2vOlgdJQ56bO6wrXlW5x/DD1YOer uleitoK5PS48KsZZglXhiT/EinuER1EOKay6WoPx0KOReDgRZnJYwQegH0OPIgIXVlvcbsSFrXpn ji8McfYLoVJtbUdhSbzU8OdCoSAlcHj9VXqx4m/cjLkJivQnQprpvKp1gsbumcB4YzpgLbtUVB4N VRJAk5Vmcmw8N5GbyumUXFtOzD3MFIwipTykYWPROai2CEcmzBEK9lQSKNhGFU71PacYmoSTPY7f ofJQvPb4R4qOQCuVYKel7Vav3W5dKEEyqtUggYue6lUvVCFBUwuo7KsoFnsNZXA4T4/mCwlFdhlN CRccJ8aCOYouDBiUKW+IUuURztjJ9qKKFu+b3pXfdb2fR60RpHxQoZENamiGzYgzuhnr3fZp33R4 OjIdvavlztRM2Qb1GE4XnhmyQbVWU9X07aV70veUDGOjeDjVlVdCDUs+1GCq1BAxUS73HqkBw2ZW DUmNCjaV+IRsSDnu7nMoNIMKCUQvX4QaaSgFgDXDgUELGxZIPCk188L3oMAQnQsp5gxJ8SKmkuKm Y04CioDdnA2dbMd17HSCk6rbjuvYsQ8mVHyjiZsE3Bj4r2Z4N5SzBzmX4nAPXlilic7k7iKUVYEA 5NWDgNtoRj+x3i1OJ7PXXrB8nZLY9NVfP3r12iuTvoA9mYzee/Gy9RfN/75cvuezXYOdLtlt0z04 /9TXPjlQ7skXKisu+d62u+JSmK348h3nNJZdON3bWD/5rYDTEQQP8576N3Gx/nHUXJtr8rBMDOVO kZ6CeLM4YrVxB4zN52EGD296uCDzLKCl0HiHGwdonNRgUx6rueT0e1FUH0N5A0rRd3QOg2ScONL0 0b64kIX3ofM1FIBTCW4QPqcqUgttfNtXuTcVX0RrhNBQvbTHBDLVnRHmu8LLVqFMJF1OBSni2tYI M3DjwMCdKQYuBQ24QYqvIoaOO+XyDw0twufxxKIfyr8izwPomzs2NjYrA1IytoBpwGdF7osdN9Bv a2xim0SxL3aX667QY77H/IdCr4ZMMzG2I4wkqyH7Jtsm+5+D8ET4gjmUK/QFQ2Edo5k3sovpfG3N u9W1oQaK0Vanm/Y/Dfg96ViXeiO/EawU9yspEJ6Vamw3knpQkV6vN6S9wx42hUFOMdzVbs+s55jn ZY/RMx59AKhJzTTgeX4Y8gvDscFRjNExUIv+OPLXsYafjjOIT4FrZ1rlZdL5t3JMUifG+eIj83R3 co0LpUZSiJvBvckGnn22M58805VLTS2tbGj9SvdV5UBB//j8Py6f+/HomYX8xZd0brpEvDzpv2Jl 9lKSjCJ8G3O6rwsZsa1JVf4c9yGCsZGizqxKvhkRaOpDCq+5AmPuuIbJUMJ8x7CbRx9Q7VgD56Gh 2aJovMNhQ+70gunpCGaMVsURNMZKDqSCoA/vJ2iGWRKAyTgKO0lT4TFIC/VKrZouz6z60OhU15u0 lAWdWbIq1qAD8HCcVTultakTAyYCzZgTFVPCUAPJl0KEFZZIPIbdZnNW4ZSnoJAzDFMli7t9m9Me GhpKiBrc7+92Y2gwLWDG/f6Ykcefu/2Ls+Sc6AMRcuQc9EEYyBG1znJkVSg5kg+7c/qatTvRq6xM rFQMYbNniCzP5FA8k0uZc6zfFDcvVayZGAZYW6Z6JORLQSTRK3JIVslqTfJ0KYewm6Fy2ASbQX0t PYZGAETOHQrDfzuM8dTEKcx2e3REdEqT7EB02Se0BKrTehpAcrADIG0ofgy3OwFr+VgXC0g5DQIS iTpdUWc4iko4ETmGfGrCyFHiFHJJiSuS9t/RTXlRC3QIWJypnmxSJ/T/XF13CXKiEjnH/Fvla25c NjhZinavZP2jfcVPr26cr/v63O9meDbUE1NnjX55it3V3xFhmbl7poa71oims7tRYAQRO9DoCdCo Ij6u0egBi0UIu418BCAX9HIFkwgQBXDbyGt8880+xMB5iZsmwqA9KKHmvsXSksRxVi93/no9Rhe3 /1xuo8i3oH8rvKHQeY4WP/xPA4jiw794FB4J+qwW93nShuDGEIZKQvamtY5S0rPqRb66N+QNpywt UtKluNNBJaSEey0NqRch93qoNzxgXmVZKi0LLgutCl9h/rb5Lst3wndHZlr+Vvih+QeW74W+h3Ii P0VS0AHpQPBg6OHwI5HZlt8F35XeDb4fLs9YGF1lb8d4jS+L7doyXtCWyPHj23M5bZlKaUuXiy9V NRStOVtuxOhfW8UJw43K5w03u3a2WHrNNamGjM4njbPJ58Km26QdwVtDum73yqDoCXrjHiGixAW3 5IqjF9yCgiLhkBIMhdoskhd1RSLhcNpiRstsMmJEOjNUMo8bapNgDIesiABBPG2SUBQ0DTznAekZ ySBtsyBh4zJVVo3VXebD5t+i8O82S+jqMBVGUAQLns/prlnoOQFCp+WejjotDtrqgmUW5tIh9tgB uYVNtWhvA3vRUx9wempJYqwh4MippjWxjfBc8JUQ2GrwnfAJWm4NQtGicvec1om7YhhFDo74f1Xl gUQhoAWdkP446WvVePZLCip8gHm9ehBLSxr6MowFaClwgr2sSp6GWUH5GkzQIgj9QMoEsouoHhQV /PB4uCuGF1VHfj+v0QOMds7FHozmCr7fPRswW1H0rljzpqLzjxTmD/vzCVeH7uuZrJJqmzeK9p6Y w+K0YtAiV3z5B2/pDF1V2WJGb7GfOm7Yh95S0h1t9pZsMu5yiCVy8jkESzZo1uczCaPTSGTehyLm 8Eh9pBaP1mdQPBTScylxxWCU5mY+h50E9gmPA82DWYteyPOTX4+8TuFqlJGwXo18Bqt29lKpnExW ytR1wCvpWn1jKND04hgv/EN+RYrr4g853BV8RjXaV/fnYGC6MjmlsqlyhWWi8lrmtfx7mffyNtph j6fO93sqkqglK5XC5q5YCPW6U3JFL2Vj2VK2kR0J3B+4P3h/1mzNdKe7c0PCGjZoWmVekV6eG8wP Fm4zTclTrr/O3Ja/rTBVuVv+Ou2ceQRD0R/OP1Z5KvNU/vnM8/ljlYRgwGifPn3AkjHlLHljoR5Y Ii9xDRvONa0LnlvYYd0p3xbcEdqRui1zW3aqErjVckvg1qzObhll18rXuvToE0jfyWQkZkKvkAOu uKykknFFKJTiglNyxJ2JUDwOs/6WvQQcPHRqm6oGM2nUozJbTOlC3lso5EENmVyb2eLFsErQTkK+ tJTxSlIGdeDbgiFvMBgqZFGcLYCB8UwSvsMj7E10ojh7c2+COV20JgsO6CaQgrIMA14RRNqIkYux Czpp8BH2SSGD0UrvU515FTeL7CGr8oHzUgk21UP7ZoVLC6lDSJbxoVzycIjtCrFHQ0+HXgLX+2q6 iu4dOag4M6hFwnjyDrJFMo8wGYA3H3q4TZWqm7JMzU7ROAfszX2Wbbmq+WF0czOUPwkOJjaVP5nH uBeQ/Tg0vwuD912mRoYLbIpGvpALCsa+2F2YLRwrmArj5dNa0wnki0yGwifmMEbi2GSzb2NTGBsg 3oLHw1ClaKLOTl2dRiGDhCMVS+v6XMEicafZWadrc1HVUjNgULxUEG8sbPkfVwii+kCcYSCioIWx UDifCgPtz1KpaTJMKGEJ2uzLe2JUafr0wktrJ/cEGniXJ/f4+NpDPo11UA/ROAfP5/B4wCU04BQo tMlImusspaPKQtmcnU1BDB/5eS2Y8y9m+1bGkV/6uDfXYMn1hfnfFv51/s+Z+RdiPYvBT/TxaKI0 92/s725dHHAgP12HaLTXN/c2e79L8dC41/YrPnhDXDV3UCeu6rSTzhhB3PmP4DA9urebOqMtKwVr WX1ZwKmq4DP7yh5Z7EHjgFCOuzRGg2AClZ7jMy2mQKL0Vvcyie2073TsdN2avbX2rPXZwAu5Fzot zgoiO9a0DTBE6ysdpmhvxXl+l77SZ+iT+1w92b58o9bWu8o6JA+5lsdXZdfkV9fU3nWhdZnh3qtN 263b5e2u7f7tgW+YZuQZ1/3BR7Jxh8EpO13OUkJOuBKlglQIVHsljKBmOb9ruHcBi5jGfV8PrCM9 yDWon1rJ1oKSXqjQM8QrsVijUukljwlnaEB59NGTcI42q83pmb6XRd+EPytXq9UloGg6oX6YTKFs rV7rrGfcO/1VwJPqUEv9tti20DA8RhizMrUdFaN3plgqlAGMsbP8dqGQ6xzG295WZ3WDwZQJmUzp esZbr2ds/lyurdPm7ey0AUIXtNgCnblMyNpTzQYlna1mqjuRu5TAl6hW6DNAgLtcJJUreiRKluPx mIThapbt34JRqCtIsHPsVUIMmswsjMK6Gtodejl0MqSnDSSNQ4+IXRhDwcQu21Ov5MAP9mL8o85H xMeRBdcrDu5NHuVpYBgaCB5QVFpEMdSFQf/GFqQtJewjEIL+x6vyccMG7438GbwmF3U0ajCUt9tW Db4pHx+jd4wxwvGi3ciqHMMWma/KN76JlsksL8YY4YifbDtyhBZHzEdMWJixFW4PpFnxYicL0EUr +pRECMX3DlqQEg4vA9qv7sUS8bxXVUvU1WdHQKoPAvzVvVihpepBzVADxTRNVMSri1q9eCcYz6yv ANgjznDygLORUZwk8J/b46RE45ex6MDigB0/2PkW8k5k4ZXIIt84gwnHQWXkSgL8F6QrACfJVYaI vSHjBbgwBeDKkFHSGCM0wkXia5AhDK4ACAYtoIvNYgFL+6Tq8TW6zL5GHuXqC5hcZj+NWv6yGvE3 CqoLk6/RQROuHKCrY6LDF0CZxFs+/vefPSJce6Fd+A9cgWlWmA1QMOm0/gIIpz+gZcIgxJQj1sTX ySztptzpCHuwkExZ/f2rV7ZkWVd7un1k2/G1Kxvzw2VA5m/52tJyef536Uj2/NkfD5xzBhhTNBDs kFsuv/ySsC8GthRs2Xr//KHr23XptNcRCIwdObLRFcyJ6bTBG7v21AdXdqOv2JDh+g44U8fp2Cm0 02KrTrgux3IxWAzQX1B8iBiTizepROEBkTdFanbwZgeamjEBRPab+NdXPUqe24/aFHFLUYh5XeIN GLZAQA61MXUDXcPp9SJCUetc4BGwBI/ALiSdh4cH2tt2y0CDPYqiie8JoVMnhTACypKM8DdBwB6w UEago/iNguipVfybu24y3GwULRaD2xwyhy1FbzhrSbvTqG7Rw7rc9cgK9+WWy6UrQp8IXxK5vHSd +Xrp+tC14c9ErivtkHaEviV8y3Jn+JvFR4RjtX81pqCTFIul1laJcU09ROp9qaOp3mfNSigcbmuV vNihVCxyxb7YikNawxa9ZC5hGYKmYU41VfwcqEh14G5z1VQj5qwBQoaBY81qZKfEXpJOUrB0QvoT gqXb+ixDlk0WnWUbDFuHGis+i2wGpzKDOMXOTSVWLfWVxFKos/a3BBsjyBiGHDiO8ennMCwfNO+5 JlQMA4NjVGqS4fQhiO3SYA9cfyf2AcFNNtp/W8oPIyQ1hTObJC0eEvW/VsW5Lt4MZPHAKrnzuql+ Jv7Z2AO+cjn50lGXydxSZK2ZfNASmr+968FzFq3pbks28lJ8Rbp//qAzGZIDnaDhXCy3bL6D/aWQ d1usGAdLH0w6+j74q5tvW1pq7fQ7zxydEfcmKimbbAP1Pq67lL2NCuFhYUiNWUJg2QbZ4hUO2FWv Lor3a+h1BhKBKcLlsta9cigS/QmiM0mMw3sGstTx5gbnxk58+Lo0q7VBCokHsPrTkV8eo+vWAjAm 41uXZcJWm8PqDrvyZyZae5d8anSR7tLqGfVsHUVQTZbF5Y5odnLtNRepiOjyv1NJYbPW+k9zFes6 wYwMHxuwMrLgEjDYu+AVfKgkFsC432FoDqhOJaAKHdTEHCr1F4RWjK1aEspIrO6AlKkLXUK30EOi RVgqLBOWCyuElchWHxBWC2uEQeFs1FEYFs4RzhXOE9YKI8I6Yb2wQRgVzhc2ChcIB/n9oCIu3iX9 GRGwEzasWr9uOfJ7r/j0pVedfem152759EV/NXze4FpB+L8wDHeyCmVuZHN0cmVhbQplbmRvYmoK MTYgMCBvYmoKMzI0ODAKZW5kb2JqCjEwIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9U cnVlVHlwZSAvQmFzZUZvbnQgL1lSWlBKSCtBcmlhbE1UIC9Gb250RGVzY3JpcHRvcgoxNyAwIFIg L0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDMyIC9X aWR0aHMgWyAyNzgKXSA+PgplbmRvYmoKMTcgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9y IC9Gb250TmFtZSAvWVJaUEpIK0FyaWFsTVQgL0ZsYWdzIDMyIC9Gb250QkJveCBbLTY2NSAtMzI1 IDIwMDAgMTAwNl0KL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA5MDUgL0Rlc2NlbnQgLTIxMiAvQ2Fw SGVpZ2h0IDcxNiAvU3RlbVYgOTUgL0xlYWRpbmcKMzMgL1hIZWlnaHQgNTE5IC9TdGVtSCA4NCAv QXZnV2lkdGggNDQxIC9NYXhXaWR0aCAyMDAwIC9Gb250RmlsZTIgMTggMCBSID4+CmVuZG9iagox OCAwIG9iago8PCAvTGVuZ3RoIDE5IDAgUiAvTGVuZ3RoMSA2NzgwIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4AYVZCXxU1dU/9943SzYyCZB1knnDkEEyiZEADZA0mSwT0IgECDpDg0wI kYBgIgnggjBUERg2Sy0VXHCpilrlZYJ0AliiqK0owqdU6wqi/dT+iqC/n1q3vO9/3wwI1l+/d/M/ 59xzzt3OO++++ybdi5e0UTKFSJC3dVFLJxlX9kdgOa1Lu9VYPSWLyNx0Tee8RbH64IWoXzdv4Y3X xOo5VvDC9raWubE6fQ/+i3YoYnU2Bnx4+6LuG2L17HfBrQs7WuP2HKk2L2q5IT4+Sbt6XcuiNmnA VJpB1M6Orm6jSjmyv4s6F7fF/ZmfKOnP8xZ3twkYJOc0iIihwukLqqB7yQLJRiV0JZHyRyWPTKhL uym1+bd7Hx03O7XiS2uuXAbRgx+OKJT8hbvnXPXtrh/m2ciajGqC4S8NaGepHLiCam307a5vb7LF RpKWsxfvoyZxUa87y3F0vxhJJwAuRkY8eY4+MULkRcod3qhw9aYPLU2tLhYqeiwxqAraAewCDgAK zRb5sNpAVwIhYBdwADgKmIlApVUFOoAdwAnALPKEPaI6bNUjRDbaZmO9qSKTTgM6IMgBWgJMAWYD m4EdgNnwk5oOYCVwADgDmMkrMiNbRmPumZH1ButdsLDUqLbEqs2zjGrvVYEYnzw1xusujblNiLmN GhNTX1wT4yOKYjy9oDSEznsTU0r7qzNEBhaZgYl3gjL+PKUyRg66XwwlDeACUzU0XpHeO9xduuOA UIgJLhjNJYfeL1gkJa20OpHr/DSlk4N/xk/FLPxU76C00h3Vl/GTtAs4AAh+EuUD/gGt5CdkzEGr gB3AAeAIcBow8xMox1He5+9TKn+PSoAqYDawAzgAnAYs/D1QG39XZoxBpVwFcP4uqI2/g2W9A5rK 34b0Nn9b7+evR8rGl/YZgqckLjgK4kJmblxIzyiN8tci34xERrlxp5FR+8QwqqTRYlikYJQjKrIi FfMdUf5hr+px3F99CT9GGsAxk2MY+RipQCMQBDoBM6Q3IL1BIeAO4H5AA5BloDZA5YeAV4A36BLA CzQCVn40gmGi/EjEXeOozuCv8r9QJiJ+mP/V4K/wFw3+Mn/B4C+B58N+iL8YyXdQdRLshDY2cBt4 Cewm/mzv8HSHXp3GDyCCDtASoAqYAswGNgNmfoAPi8x1pKOTfXQIz7CDR+hTgz9CD1rJu8Dhddci AVVJ3BN+CQlkh7rDzb3urdtQlcS9aQskSdy3bYAkifumVZAkcS9cCkkS99wFkCRxz5wNSRL3lCZI IFF+35+Gj3CUTbmWqdWpfBmitAxRWoYoLSOFL5OFvlHkHO+OFBYiYtu9npGFjtBeFtrPQtNY6EEW amOhFSy0ioUqWOhqFvKwkJ2F8lnIy0L72DiEIsS8uy+ojvdmsdAhFnqShbpYyM1CBSw0nIVUVuaN cmfkUjx1YD6D9VbLh447e39Zid0nlTsRUSdy3ok94QDoEUA3al44qcNiztn5kg/rLayK1S+eUNpR PYkfRMODuA0H6Tig4AYdRBodRCcH0V0qaBUwG+gHTgM6YIb3MKxjs0FTQUuAKmA2sBI4DZiN6ZzG VDh1gMop7jImVgJaBUyRNX4QZRiKkzu9eTa7zWObJDbbWWo+m5Kv5/MyysjAvpyeZk2LspQ9X6f8 ++sUSqhO4Jv4ZsrDjbgjzjdHvslzRNldEfc+R/VQ9nvKV5B1bDy5WQH4OOoy6mPJbpX6MWTnT4CX RuxXollqxF3k2MsGyVZ7HN/YP3J8ao9yiJ/Y9zneVKMKizj+Bs0TexzH7OscL5VErdDsd0cZ2F7V cO2zj3M8echwXQXD9ohjhWR7HLfYJzqutRuGtpjh6i7UvKmOae6Zjknor84+x+HtQp97HFX2qx0V Ma+xss0exyWYgicmFmKyI+3GoK58o8MZZVHW7i2ybLX4LVMsv7CUWoosTovDkmfJtQyxpltt1kHW ZGui1Wo1WxUrt5J1SFQ/4fXIt94Qs/HyMyOhGSmGbMMOw+Q2A0qcWTldRtpg0cAbptewBq2/lRrm qNpX011Rljh1pmZy1TAtvYEammq0cZ6GqEWfppV5GjRL46/8PYxtCkCr8bVRRk3+KNOlanWull7r 7yPG0lZvzJX8otUbAwHKylhalVWVXpk2vr7uZ0jQUAbrPD9eWT+KnixPnra1YbpfezwvoJVKQc8L NGi/na42+/vYF+yMr66PfS5ZwN8nKtkXvmlSLyrrAoGGKLvS8COVfQ4/ZAwY/Kx4MUs/Uq35Mb/t Mb8CtIffcMngl5BABYZfQUKC4acw6dfTNdxX1zMcBD6ZKnUZPl2Z6vk+hwrgUwACn4wQHTJ8DmWE pI9WaXRjt8MlHwQuLIfshoud5Rguxsx7DJeSuMu6cy7rjJFEbDaGjyToJuXEWZ+UE/A5L5D/XWyr 8XhYb3mgtdnX5vIFXb42IKitX9qepYXmqGpPa0AaVE24g3Na2yVvadMCrrY6rdVVp/aUG+1+Ym6W 5nJXXQ81+5r8Pc3etrpIubfc52qpC/RObBxTdsFY686NNabxZ8ZqlJ2NkWNNNNr9ZKwyaZ4oxyqT Y5XJsSZ6JxpjkZHjjf4eK9UEanH/JO/lSYnI12CuM1CTYeusNJK33Jm1IncvTis7KckT0JJdNVoK IPO6uLq4WprwTEnTIKhT46asFeXO3L1sZ9xkgzrNVUOe7iVdSyjLN78u9teFC6ruJfJWxKhH6n72 gotP87bUybN1g1Y4vUGrmjrT32OxQBusC0A34awuKckX1ftjyouhnCAdhTjnKHUVUpeQEHf8z1ww 5gQ1otOHg8a+XubNZ93UFRBafkMTx1bQNBNhaJ7p34uzlHxJdAWwwC7mYV1ne5PrMGSKaQjL7jqL 7iVxKR6L7jg3XLs85Ok6G5Kz3XlksAxixKrbg63NtJeygRzTo5StuAnfP/rHwCeSD8zXP5F2yfk/ sdFF4yDaSU+y+fQkHaDn2Bm02kV9tJvkEaiO7qHldCetwWttJjTraBqKCfo7Wba+G18mD+CF+QAd hu9VtIL2UgbL0j+llbRavI5WqymFhlE1NVIHbWSX60uomY4rt1IZXU7XUScL6X59k75F/wM9TH3i r/oPlEQ51IpyWP/M9Hf9XSpGi9/RNjrOtiQ8TV6MEoLnvbSYtotZCtPn6d9iBk5ahjkoNJkOs37u Qe9t9DHLYstFLXp5SNf05+Flp1nUTttpLxvLJnKnqVmfrB+mDIxxA3rdRhHagxKlZ+htlmw6o/9B P0PZVESXYj276VXWLwZ+WDVQhbiZEKWRNB6WDvoz/YWOMhd7lneYkk2lJq/pJv0YDaFRNAOzfRQt /5d9zVegrBQvKvV6DT7yVtNvZLTpBfqA5bASNoVdyUfyDn6fWExWjDgKZS7NR7zvQu/vI4328GR+ RDykPKF8Z84bOKEPwh1x0910Lz3LUrBSlXWxX7M32Ie8ls/md/OT4k7lMeU1SwtWfTUtoo30BH3N 0tk4NpX9irWz5WwN+w3bxg6zo+wTXs2b+LX8tGgX14tnlBqU6UqXcqvpdtN68ycD/oHnB/5n4Gu9 VL+dpiIfVmH2v6P7sLI+OkJvoRynk8zEktggFJU52Qx2M8oKtpE9yHayx9hujHKUnWSf4pX0JfuO 403LzTwXhx95BHLxxThh3snv4UdQjvJ/8W9EphgmPGKsqBAB0YFZrRF3oDwtPlBylCOKjjiXmraa dph2mp4wPWc6Y062/Brv+Fe+f+iHwh/eH6CBtQNbByIDu/UPaCjuId4e+ASrwOxbUBbgfm9Fxu2i 11kyYpfDClkluxyRmc0WsOvZDYjkbWw7e9iY+1NsP6L0JjuNOadwuzHni/lYXsOnoFzN2/j1OIxt 4bv5G/xbYRFJIlUMFYViopgl2kS3uFFsFZp4RbwnToqvxPcoupKoOJRhilvxKBOV2coS5T7lY+Vj U7PpZdM/zInmRebbzVHz5zjVVFoaLVMtsyybLXssx6xBZOdBepr+hAw8d7ETYpXwiadpEx+tZOMT 5lXk82yaKyZzZCrfydbyW9huPtx0g7mcl7Mr6IziRqxf5Dv4V7xcTGYNbDot4KNiHZqHKI9DqlAO 0illP9b2Knq+wZzMVvDT5mSK4Iw0HmekF8Qlike8TG+L48yiPEDvKIksk53ij4pGZMEzSqXJT05x Dz0lrme30NPcR5T4nXUD8vgK9jj2hSZWyv4tdByDr0AWlYkP6Va6lv+dTuE5Xku/Z3OVebSJRrPl 9DE9gqdipOk6c6F5KHuJz1fCfDDbTVx5DKsbz4YzYRpCt7FZYrv5NH+LltARJZHeF3/E7I/wp8Rk 5YxpGmvHE3AL3U7X66voRpNfeY3NI8GupALlBHa35aJUcYKvxK7SjD1tD57uvdgHqsVkaLKQOZcj L2Zgh9iOchf2CQUZNB/P+FXYxV6l3eYmHqV5pkEMuw5+qXl5YBrN1B+hbfo8uk7fQsXYD9boy9Hj TvoHbaadbPXAzdSJT8m38GxfbqrnR0z1ejEP87f4dL71wvuLaBewLPonylO4M5WmfRRW3qTpVKVv 0P+G7L4IO+w2moMD60dY5WcYYZLop9EDV/AevV50Yr3Haar+qO5gidSuL6QptJ8etpioxeLBPdbY a1jvzdTGp+ndom1gPuKwGVHwIlpLsP+s89bOaKr2VlX+sqJ8wvhxZWPHjC4ddUnJxcVFnsKRF41w Fwx3DXOqjvw8e25OdlZmxtAhg9PTbKmDUpKTEhOsFrNJEZxRkc9VH1Q1d1BT3K5Jk4pl3dUCRct5 iqCmQlV/oY+mynYtMF3g6YXnNT/x9MY8vec8mU2toIriItXnUrXDdS41ymZO9UPeWOcKqNopQ55s yHcYcgpkpxMNVF9We52qsaDq0+qXtod9wbriItaTlFjrqm1LLC6insQkiEmQtExXZw/LrGSGwDN9 E3o4WVOwRC3HVefTsl1oim5Ega9lrtY41e+ry3U6A8VFGqttdc3RSJ6UPIYL1RrDaOZazWIMo87H GUej9WpPUX94Q9RGc4Ke5LmuuS3Nfk20oA+flubBuHVa5k0fZf1YRec4k60535orwr6s+ap0DofX qNr9U/3ntc11yh4CAfSBtrygPhiux9AbcKca5Flc46sDfo2txpA4WBYYq4qtL3bqLQguULUEV42r PbwgiFuTE9Zo2o3OSE6Ot08/QTk+Ndzkdzm1qlxXoKXO3jOEwtNu7M32qtkXWoqLemxpscD2DEqN C8kp5wttCHrMZkiGu5Qapp2LLJNzdF2Kk6CmtqqYid+FNY2TpG0chVvH4QbgCjC00ubijszXEmqD YdsEqccSmWYqsLnU8JeEDHCd+teFmpa4xlxg+5KkUebJuVTTWMtZWfN4tMJCmSKWWtxTzLHSqI8t Lloa5S5Xpw3fz/KjgRoR25bAhBKE3+mUN3h91EtzUNFCU/2xukpzciPkLcHZmgelpf+sZegMaQmd tZxrHnQhk3fL71kaqlnd5/5SbRmDfe0TNJbxX8xtMXvDdFcDjsaqLxyMZ21D0wW1mF0GFHGDLS5p g2v9IpdDJyWeKwxr7IR81gXHZX+yphTgz2wk9dyoxYqsNDRMrddswUkxGkh0OuPPzP/XKKqfka0M 9mOz+DK0CZ74RGPT1sovqF8wveSwaGjClsNxsg+HEy+wIdVis7w0zpDx+NB3qrUazcCTWYA/fHKM kwjkal6EDJYmPEWGOpAbr17gmBtvFMAls7O4qB57Zjhc71Lrw8FwS1QPzXGpNle4jz/Hnwt3+rDb xRInqu9dn6vVbwggYu1sAh4PTjU9LrZ2ao+XrZ0+09+HnzjUtU3+CGe8NlgT6BkOm79PJfIaWi61 UildVFmhBoZFRrjV8M/t8xKFDKtiKIx6K37dMHQxJ+gYtUZ5TGc768ehU2I6r6GT65N7TG2TP35b jISQjx5yCP9QQTfyjIGLocgrGUr5vwz1nAYpjSJ/qQExoeB0byFypjnTCkDwqw59r4r+770m+o5U pR9exo87YPoInP1+7uJQCsPAKD0+sln+QyYwbWbjZZM81Yvntyyc3PR/rSf1SwplbmRzdHJlYW0K ZW5kb2JqCjE5IDAgb2JqCjQ1MzUKZW5kb2JqCjggMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5 cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvRFFNWk5EK1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQKL0Zv bnREZXNjcmlwdG9yIDIwIDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hh ciAzMiAvTGFzdENoYXIKMTIyIC9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1 MCAwIDAgMjc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgMAo1MDAgMCAwIDUwMCAzMzMgMCAwIDAgMCAw IDAgNzIyIDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDAgMzg5IDUwMCAwIDY2NyA5NDQKNzIyIDc3 OCA2MTEgMCA3MjIgNTU2IDY2NyA3MjIgNzIyIDEwMDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDU1 NiA0NDQgNTU2IDQ0NAozMzMgNTAwIDAgMjc4IDAgMCAyNzggODMzIDU1NiA1MDAgMCAwIDQ0NCAz ODkgMzMzIDU1NiA1MDAgNzIyIDAgMCA0NDQgXSA+PgplbmRvYmoKMjAgMCBvYmoKPDwgL1R5cGUg L0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvRFFNWk5EK1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQg L0ZsYWdzIDMyCi9Gb250QkJveCBbLTU1OCAtMzA3IDIwMDAgMTAyNl0gL0l0YWxpY0FuZ2xlIDAg L0FzY2VudCA4OTEgL0Rlc2NlbnQgLTIxNiAvQ2FwSGVpZ2h0CjY2MiAvU3RlbVYgMTU5IC9MZWFk aW5nIDQyIC9YSGVpZ2h0IDQ1NyAvU3RlbUggNDMgL0F2Z1dpZHRoIDQyNyAvTWF4V2lkdGgKMjAw MCAvRm9udEZpbGUyIDIxIDAgUiA+PgplbmRvYmoKMjEgMCBvYmoKPDwgL0xlbmd0aCAyMiAwIFIg L0xlbmd0aDEgMzA2MDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvLx5fFTV/T98 zrmzr3cmmX0ms9yZSWYmyYSsBEJyEwiyBYKgJEgkrLIJCSAILqCCCC5gXRC1Fa27tgwThCBaU5dq 6wKtttpqBSu12jZqW6StksnzPnfi9v3+Xr/n9Xr+eDKc/dxzz/l8zmc957J+7WVLiIlsJQKRF126 oIcof9I2JG8s2rA+lC8X3kuILr6055JL82X/i4So/3nJqk1L8+XoM4Sc7162ZMHifJmcQ1q7DBX5 Mq1GGl126frL8+VIP9LXVq1ZNNIenY3ysksXXD7yfvIeyqHVCy5dku+/cR7Sip4169bnyxveQnpD z9olI/1pByEFzZesXb9EQANPGbEQQlGoIv8kDWQ30RBGRJImF2IlN7IXiRpl3q42vT46Oe79+daG L3QeHSoIeeDDmok8feng2Vu/2jl0k0h0NeirV/rzBjynDedayRyRfLXzy5Ni/k285eu/qoOzQ/0q U5/JUsnTbIGrsl9l7CsJBa3NospOtiIwYkXchDAfQVBiSmSVPXt5ldyPZG0+WZ1PVuST2VXyM+g+ hVQND6jsfS53Je/bZzBVbuWpTs/LtuzcKrlZr7JhubyfjczKp9l2Poot28ZHsZHz8rV9E1rzT7Xk qxtHOo+pCjZH0S2EICP0IBxA+BxBg9nbSBphD8Iwgkop8X5bEHYj7Ec4haDhU8jqqqzNPpWIFlFZ u0iCyKURBNKt4tDNKLFVpQNUdGQGwn0qLVGpDFmyKngUgwh9ra18pkJfqlxJsyWJSqUh6/VXPqsS 2D5STILoSbNOn9JCsi0tI5na0flMX7Ks8mSzQUXIZwhMRVSUlOSf6ispr/z8OZSpkCNWSnmtcK5P LMTbhKE+a0Gl3CwK/yXtCIxkhINkAIGRNcIXZAsCQ/cD2bJR/EXCgT6DpVJE/89ICGErgkD2I6ZK WUaO9/+sr8DJh/9L1mpTnjuZrajOZ/pEd2V7c6HwHubzS+E3RCJB4U9Ii5C+jDSA9BfCK8SszPPB PqtYuRXv+zG6/1jYRBJofkjYTCqRPipcTXxKt99nLfn3/D5bkqxsNgiPCFcqXdYJvaQaXVcJK7OV wdAx4UHMVBb+3qc38vn9PSs6Kp8VPhFWkkL0Oo1erqD1WWE1SSPwlfT36c2Ve5pNQj+W2Q+wBDFH Su5TYln4TRYD4X2PCVuJE23HhWuIA+njwrVZR3DgmPBv5X1n+Sh43wPYMTzpM1sqB5r1wgNozQj/ BMT/qbztTF98dCVpjgs3kQoEBqB+iNyHyInCp8h9CjR9CtR8CtR8ill8ik1LhEG0DKJPWnif9Ajv kj0I9yGvwgI2ZQFBjrpN2WhJ5VHhKuFKQEI8BthR1F7dp7fwmV2ZtRco3a7kBN70rPA2mYHAAKx3 OEWuOSbcoixlT5/bxx94K6s3AXRX5HGBkTZzHDwrbBWuVSBxjQKBzM9QpMQqXKc8PNxnslVuAfZn o7gG8W6EEwifIajQbTbWMJvMRwDzFtr7LNZK6zFhrvLw5KylKvisMAlLn6RAa1LWEVHmfN5IRmXN +ooqfwZasZIycLRKlUWlyaaDM48JU7F/ZgjTs4uDmPvMLMblMJneN3pMZcUxYboCi+nZoJSvzhZ4 lMzErD6/r8b3GWx8JhOUjqmszqK0p0ZIUkj2Fboqg82iMEZZbRViItQBfXVATR3opEpBRmWfaMfu XyxUKiuqJN3I7UfIIKiA40p0rwSOK8kppcYq1GK5tWQYQQBua8nnCGCzwijShLAb4TmEUwhqpbYb OYb6CryhG/EeBIYR0yiLiGWEboStCPsRBhA+R9CS40IZ3lOG3hWItyJkEE4iqICrUsyjFG12IUSG IFSCZAvbJ4+hW8gWuoVtEbaotqi3iFtsOrkmVlopr+BROY9KENV163v0W/VChV7Wt+sFUR/Ss/7h gax2TBUS2a4ZU/WHtr+2fdkm2Ov2aPZo2fFmE7WRkwifIQjkOBVRElES5R3C8caTjZ81CsfbTrZ9 1iYcf//k+5+9LxwvO1n2WZkgt/nGVNbNp2voFrqbqoI0TZvoDKqaL6wRtgi7BVVQSAtN2AuqbmOP catRqDDKxnajIBpDRrbHuN+YMQ4YTxjVGc2A5oTmlOZzjbpd063p0WzV7NHs12iC2rS2SStrVJ83 j2fvAqj7EWcQGNmKeI+SExFTMoD4hFLmtUAH4h6lLCNuV3IS4gqeQ5Aw1h/QbyviPQggPqUsIa7g ZQQJ3P336NODeA8CY7+X/ZGKqBxlYjQUZSRKP4/SE9FTUZaJDkTZQPMY9g7670ecQeCzfAdP8pyE uILnECTM9m2l39voxwl/K+I9Sm4/4v9Z1426HqVVRtyu5CTEFTzH3s5KddZmF7sHI85HfB/CSQSB pBE3IaxRSkHElN2DWGZ39xWXQuCzu7Nx8EgkkXxSlE/8StLn8VbOb7ayuzHk3RjybgzJS0GEJl4a HmD7shN4333ZcflkTNXJ5jpIUT6VfeQAAiMzEN+n5NKIm5QcbwGr+qacQe6U0tKDeL+S48/xUSAH EH/9rMDuxm8faqxsM2o3y0ZGnE5oTnabzt7Pns4utwf72aFsiYikL59kedJcwATA3kw/VeKfKvF9 Sny7Es9RYqtslMz/lcwvSeZHJHOzgU0hUTz0uRJ/osQrZEvU/HHU/Iuo+cdR8wNR8zH6IYmgU1j2 Rsx/jpj/GDEfiZgfj5hvi5jnRcwzI+ZpET5UCQkRMwvwmF6sxH7ZFTKfC5k/CJlfDZlfCZnvD5k7 Q+YxIXSn/yTV6HivEu9V4poj1eZgtTlQbX6agTPRi7JWoj/GGL2ImAVDNtkY7Bf0SsLC2bYYIODP tjUj8WXbzkfizbatRVKQbbst2KxnVnoQykqQWehBHU9N2eQ1aDbmE102eTFK6myyPthPc9mkhOSr 7NIAki+zS4uQnM0urUbyBU+eof8iSxmGof/ILv0Rhqd/JSV8WPoXEmdPIO3PtjWh95H82+kh0khj qM5CO+TdnswmMTn6aDZZguSRbDKK5OF88uNsMojS/dml5Uh+lF16G5IfZpeeRnJ3tmQVf90+UqKM cxeJK+m6bJsPzb3ZNj5QT7YtjWRNtq0Gycps4+tIlmcbT/NHL6EHKXY2XUqSykwXZJcm0Tx/ZCFd pERpnkdqlJHPy7ZxkEzkgzSbaevIQibQ8Vznoy30oDKKnE1WoFtjNhlHMi4PuYbs0hRKo7MlADWt y5b8CJCrHXlBguPnGRrFNPhAUjb5BDoFs0sTSIqyS1uR+PiTmHPByFvtpFGZlC2b5L3EbDIU/Bk1 kqXKlA0kTu8+HBzCuF819tMLs8Ev5X4dzQb/XYLkcPDvbQuDf2vrh8Yb/Cso+YnDwZPo+n4jsrIx +F7ydPDdpZHgr5LoIfuCv0yWB1+Ibwr2lxwL9rUVBQ9iYpmlC4MHlioj/DSOx7LBR0v6GcXT+5dO C96VTAX3xoGkw8EfoPMO/g4MtD25KXht/JrgZdiI69t2BtclA8GekouDK0r4i1zB5cnzg8uwkEvw zJKllwQXJG8LdtcoM744+XpwFs9mg1OXKiua3Kg0TFp6fnAiZoCGJt6AGYzFvqzEo+U1xziMoKmM 73s9eEHdMwxSmG5FWCuXa5/VXq1dqJ2tbYG8KdbGtGFtkbZQZ9eJOovOpDPodDqNTqVjOqIjrLB/ +JSc4iZboUax3DQwAiiBGYJYZDxGhJgwqmMwtDIFwlQ2dVZLpi41tV87fH5mdGpqRtd+UcdBSm/p pFMzA4vI1IWhzNlZUj81zJybUUstNGOfSqbObnGjc4bd0E/J7I5+Osyf2O7L2Md3HCWUlm6/2cfT idtv7uwkzg1N7iZ7o61+4oT/Q9StVHZPaJ2Q+vbP/W0WOXcqkLlz6qyOzOOBzkwlzwwHOqdmErNC 8zqOslVsReuEo2wlTzo7jtJlbFXr+byeLpvQiW5jlW6kka1EN9LGE3Rj80gj74b6ed/pRg+iesLB RkS80wx6kHcC0cxQOs1VxqLjv9tJuJGOVzqNF25UOv0o/8Ik5oEXyjzBWOpVJKm8MKlepXRz824H 43G8bimizo6DlXF0OBivVJpnfttckm/+Sb75J7y5n9Jv22uU9qPg4bzHUbC0EvT5Hgj/fy4safn/ 8ELaN27D6o7WJVJrt9S6BKE7c+OGZe7M1oWh0MHVG3hDKCPEuxcuWsbTBUsyG6QlEzKrpQmhg+OU 5/5HcwdvHidNOEg6Wmd3HOyQl0zIjpPHtUoLJnT2Tb9mdO/33rXzm3eNvub/8K5r+GCj+bumK8/9 j3f18ubp/F29/F29/F3T5enKu6ae30Kntncc1JGWzvHAOU/7mNEAaun2hTtbnGJPo0I6Y8Puq31P qwh9lBhTnRmT1JIxI3CqKmsua+ZNIGneZEG1daTJffXYsO9p+uhIk4hqm9RC1rtbl0/Av3X4W7/+ MvwBJ+vW5RHD23h9qlVpR4f1yCHGH3oizwMqvm1fT/gYI3+pVL4vWZca33Gwra3VvXyCD0p8H9e7 U53rSCqFnsq7CN6JVSuKvlNR9I0aZ9Vv2/7c9kWbMKBo+Ceg3Z9SNPwBaPcnEE5Bwy8SBhpPNJ5q FAbaTrSdQt/3T7x/6n1hoOxE2akyoW5kBvxVnRRT/fZ3WWrdZbw6RZXVKutGCTXrU+sAAsQjYEAJ DesROJR4G8/yR1MYTmlM5VeBmnxGeXLdehT4A0qtUsWf4U9dxofnzf/rb6QWLFh9CwmqpynBL9wO 7wUZ/gDhNMLHuSnD59QriZRbMXxKKAC7jubDiAMuRrZB0fuY3EmeI13kVeiNrbScdMDT4yYeMPZ6 MhXgcxE1NcD1I5GppB2uiCnkz9RMDpBR5K90IrkGus0Mci/0wukw0pvJrWQ/PW/4E3INeZMuJ0/g 6UepDHfTNDpp+CSZSdqHj+AdhIwle8nd1AJhNY0aqDT8PkZYR3aQp8nvyDCZS+5S78co7eR8snr4 CJlHfk3n0ouG/WQyWU2uJneR+8mz5DS9gQ6o1MPdpIYsJGuplhbQEuHa4UfJaPU7+qeGXxw+AW/m avR9mvydpVQThz8lMvlYRYeXQckvgNezCq0PkMPkPeqmNcJ4YoH6OQ+wuJIcEEowx0lkJ9b2NL2C HhAsww9iNXVkEdmCLXU5HWBh9Tvqz4c3EzvWV42Z7iIPkp+TF8jfMNpEOlu4NNc0DD8A5GmKtOJN 28j15KeA3PP4vUitNEwnY+Sf0/fpB8Jq4SOM/AgZJGfJf2gJXU6vZk3sWnXl0DXDT5E4VihjjMlk DllFnqRxKtOL8Oy9bCO7GqbyYeE9VYnqs+HRwy/AfQOTnFxLHse63iBvkreBr4m0jf6OXS30qa8f vgLzTZNlWMU28hA5Sr6gaqqnJlpIQ7SK1mFlV9AB+gELMIl1CAuFA+qbhjcN30zC2CtdZAmeXEGu I9vJEXKc/In8jQxSL55M48km2k5vhon8IjsuzBHmCXeqZNWdqidUz6vOqW3q53O/zp0C1Pk4FaQN vy6ylGwGrPvxe4H8gQrUR4sw0jg6BSPNp0vplXQPvYP+mD5MD9OX6Qn6Cf2M/pe52U3sdnaMvcSO sxNCQEgKE4T7hNdUYdUfVF9pFwwFcs/lPhs2DqeGq4b3DN87/O7woIIFP4mRJjIeu2sl2YrV7yF3 kB8C5ofI6+S32Hcnld9p8jlw8BXVYDd5MKMIlWgxLcXq5tAOupHuorfRB+kv6Af0ND3HCDOxCH5J VsumsHnsWvZ3dk4wCJLQLFwu7BV+I3yp2qSuxO8J9VPqzzWntTHda+fuGXo/R3LLc3fm7hmuwV7U YOcVgOaqSQv23BRgeTHpxW8t2UA2AkabAfF7sXMOkCw5Rl4hrwH2x8m7OAE4SU4rv0+AiTNkiOQo Az7VVIdffu4VwMx47JZuugS4zf+uoNfSnfQu/O6hP6L3A76/pr+hb9KT9EP6BdZEWBlrZudhRe3s ItaF33y2iF3DbmSH8HuD/Y69y/7EvhREwSYEhWKhVbhEuEHYJWSEQ8Jbwm9VcVWzapJqpepl1a+x 8knqyer56kXqG9X3q3+sfl79K/Vp9bDmNs0Dmn7Nx1qDtlbbDrV0p/Yx7THte9phXTH2Uxtmnxjh Uzy5jV6kSrM9dJj1Y90/Y+uFV9nt9Inv9CDqXZjBYhjT/cKz7IdX7oET+El2LSGqCUqvceBir5Fn yGvqN1UO9cfkZeYln4If3i4sYD+Dqe2mtcJY1XbVa+A6mzDPH7OTTMsOoMffgI355ALqIf9UXUg+ A/yPq3cBphPZ+/QJ9guYzl3kHfIgO0Zg1JMltA6zW0yeIl+SW+lRIUQPY99tISfI38mpb+erSg+1 sCaNm23QjAGGjtKZwy+zxPDfQPUf0O3kXeFL7P0L6XSaJg+TD4H139JqGlTlVD7ya3C+InIPdu1f SB9o8FeqKCjoC3JUqCZzVaewX9NDv8xNUK8XrqNnWTPQ6VI49wzOjcGD7wKv4nzUQg6A1sFFFIr+ G3mdRiBP3tT8gdxNdpOnBQeJCQ+xrWxYeEUVIj+AS3Aa3noV+JMfZ1WPkkvJckA3NPxR7kGMsIKM JqPpQjqXTEDLJFI0fClm/jB4kTw8b3ifulOdIm/QadRBngP3cgOKd6r1uUH0PAQ6fJdMojeSvtxi MgC54qYxWondNKjeoN6jflx9SP0z9euaUeRyUO09wOKfyBlIjRBdBFj8lfwbe70F1FMK+mnGLCZB hq1incKzZDz1kh7wwBLw7RbAYC4wuQ6jXEtuAj09BBnyBvmcinQe+Rl5B5TjAp0vwvt1GGcquQBY X0ceBne8jvahZjGOFJKgsy+phY5m6/E+zmfvBJ8dwJzeIx+Bcwwr8yqlY+kEYG8R+TenZbyhlrTD HiDDh0k9JOUE4TXyZzjWRNIC/vIgnuvG3rDgqKJe/SFlpDQ3fXg0Wy48S52QhhbsqtmQ7ONoL2Zh xTqGiIPOIDW58zDaE+Bl7eqHIH1TkAwO5lDNUV+Aef8BkuwNsna4g96tBQXILRfMlpsaxzWMHVM/ uq6muqpyVEW6vKw0lUyUFMdjUSkSDgWLAn6f1+N2OR2FBXabaLWYTUaDXqfVqHFqRElpqzSxO5SJ d2dUcWnSpDJelhagYsF3KrozIVRN/H6fTIg/twBN3+spo+fS/9FTzveUv+lJxVADaSgrDbVKoczr E6RQP507swP5mydInaHMoJJvU/J7lLwZ+XAYD4Ra3csmhDK0O9Sambhh2a7W7gllpfSg0TBeGr/E UFZKDhqMyBqRy7iknoPU1UiVDHO1jjnIiM6MJWa80oTWjEfCoxhGiLUuWJxpn9nROsEXDneWlWbo +EXSwgzhSnRK6ULGK6/JaMZntMprQsszWA25MXSwdGDXTf0iWdidMi2WFi+Y15ERFmCM1owthfdO yLg2n3Z/W8TgUNd3fLfVJ+yCehzinXft2hHK7J/Z8Z1nfWE+QmcnxsCzLDaxe9dEvPomYGoqN/Ey bHtnR4ZuxythcsSUVeXXl7eHYt0rQhm91CIt27WiG6jx7sqQ8zeFs16vfHT4FPG2hnbN7pDCmSaf 1Llggv9gIdl1/qY+jxzyfL+lrPSgaMsD9qDFOpIxmb+bWQKg59uUnNKd56ae/w1kKZ+jNDkjY0ct CmEmHRLWNJpHS0aTXYtGAwH466R4KrMYGFme0Y/v3iWO4fVYIs2oY6IU2vUFwQ6QBv/+/ZoFIzWa mPgF4Y18n3yz1TJ0wdf5TCqVSSb5FtGOB04xx0alXFNWuqGf3Sf1iCEkMCdJO2C7oHNMGuAPhzmC b+yXyUIUMltnduTLIbLQB0dgGmYX6+YtA1+3OC7gLVu/bvnm8W4JO/kQ97QQR0YX/+afVXQWtC4b k6HO/0vzknz71FnS1JlzO0Ktu7pHdu3U2d8r5ds5QAE3tI3kMgXjOwQfQx3PMZ+gtGJTzpv7TRcU OkwZVQz/NMqmXtyv1WFXKjU0NDEjdk/Kx52GcHiEZv7fHuof/pw/pSTfPjayjMyY1MhE89POjP1e +XvTM+0Sps4Gy2FTZ8/dtcvwvbaJYGa7dk2UQhN3de9a0D+8daEUEqVdR6HPFO/qaQUbymO0f/jp G32ZiTd1YinL6BjsW0ZaDkr0hpkHZXrDrLkdR+EVC90wuyPLKBvf3dJ5MIq2jqMhMF2lln1Ty/uE eAmWFXZ6lumUJt9RmZCtSl+VUqGUF8EhptTlO6GOkkX9LF8nKv06Ozlu2PjZHSOwURDH9z8QSYim nvoZgY+OkBZWzw/xyRSEHQiVCGGEKoRpCE3scXJA/TIR1ReSFNKZCD7kE6oPSbmmnswSAsgT4kRd XHszSaA9gPp2tFcjH1etIyvQNgX5CgQRB3p29J+H+pRwM5mOdAbSGXhPC+rbMJ8kQkrzON6/jkxE 3RS0T8V7ZqIPH68JdQUYy4Z6B5aBCweICW7iaCBxAXNy0UgNr/3+H182DkyJiqjRWwsbjOBuCv8z EKOSfh2ZcDHAAqkqEhssI7wRB/egNchTF+F2MCFeyF4/ZDMuFHz90HfSECyaCKzjKLS8OOqLlbYS 3CtIQiLzv1JSRsphc1XAZuZ/lUqMuz/4bSQPwGY6y+4WWoQnVOer/qmu1Og0w9pXdHv0Ww3nGzuM r5vqTP3mrOV+60HxfNuF9mb7rwr2FHY4fuJKuEX3c57nvbf6LvEfDVwQeCvYHXowvD0yR/p39NLY qnh38W8TJtjxfmh1fjWHhpa0HGL0BY22X9DJBUStekEgBq3qBUo8Oo36BSY8Q5uJHsrXhcSdEs82 DDVMF880tA01kCbkxXOIRlWEbWFbDBH1q8i5kDBwTlaTr3D9ZYBjqCW3jz5Lq7ilLNv+y6hWr6LP k9fsk00G1VQHDhNkI60KWqm12f2Tm/GOM11nhgZJ0+CZQWqrrx9VQbsKampra6qL41JEq5Ei8Zrq 2qpK6COapeuXa7VajSmQGjtn8XkXbv5Jbl9p5X2zbFBPbPMaWxZvX7/7fT4DNvwBa4LXQyC1cgCO 4yYmFDImEIFSZhQOEK+aHmClqmda+dsHp4tn2/D+hqaGHery1FXii5gCFGjWlBu/lT6nXvnlBvUu TkBThk8LT6mXcS2LTpE9ep8mqInpEy6t2+cIOWLuhF6roxt1ATi3s3Z1MZI+jdnu6hcMcozI0Xg1 kVPliKpqEY0dVy1Di9uPOXrL7NZIEBYk72nZbaZmucBRbfaUfvEPdwqTS61tG+wa3yG7InK0uDrC B4nwQSJ8kDUR2stdQ53oqGTaBrnT3AXfGTq7uA8N/ZUUj/D0KTzV7Rp5CmBvGhxVMX6TvJAmQ+Fg mGmsFtHCNFEpJjGN0WQw6U06k0rjcBY6mcbj9rp9bkHDYKirqKBJphIppimyRRaCIyDyF7gW0hI1 orAlsJBKpuKFxO1ELkWR4/OkPEqO/F1DemkvLdRaGLBcjF9NdV0tx7XLqRZ5mW8AjU10OZ1VlXW1 dcJT9ZF1P7hw4Y/GlYZTjVUn1m94vWJ87jWVIe4ZnfLEvIXW0eWVnqSGPfxqZtWumYu7JvTu+/Ef j+778f03HHuPLh5746iQWzo49Fnu1MLzKkKjL+N7ZQeIYhGw6iLXPUMs9Ce0hujoQ4cj87VrtIzi zIvXaOl/Qd5O+hCx0n9D8a4hTsZki1VH1DqtCZVBWA44kJRFi6XdusZ6wCqI2OAet+Vn4EI69gvi Zi56UqGo06Cnrq6GNnGoi9NUk73+i8Fz9IsU7Uph49kKsdYqR7imqhI0YKuOcxgUx9g9zoltwaHa 6JwpXvuoUNVkO/2XetlXT1zVWhqLlUzcyp67OB0ORU/zFYG3CPdiRX7ysRy9gf2UPSkIxaY7BGYw GoyUqH32/c5DTub0M8zJYNT5+2n3YXvalXExVz+NZKldx7eN0Vyt6xeihyxqiotK9IzsI2pRzdTv 2d+0+ulzfur3FuHm13OUUk/gafhF9mB508XTXb3i2a7etjNDXadJU9Mgd9bKBTrZaW7SyS4LIo8V kbmeb4ROAAHt+f2KHso+RScl9YlKmvXbmpS+p8EdbPZ6itBlq7fXoyj+krML0hUO1xB7TbUCK2UD gVtoNTQMGNZVCe3n/kTX/PDai+++IFb73p5LHu+esiT3JI2tak5Gok76FC3fs/zGu80D/d2PTN6+ 82juKXuqlcMxPPyhsAtwTJHjclBrdVmXpTaltju2O+8puMP5mP1h59MFxjJ/k58V6mg/vUOGbOEX 9kjYiDPLboibMHsNhydvQHjoAE+zDfBEancgZW8cli1qr5kU4oz6UIhSteFpegcxUu/hojyYwQyO 2N4kCTHBEpwx2Kwu6vKWWYtoEWcPRZ7S78A8BZj3gkucGewSzwzZ6tMe72ADcTc1eQdTKXHotHja Xp/uGrQr3JV00ZpG9l1ogbVqnQAZCUc4DYICFYoDD47T9NoOedPcmxbGJn2w6+YjF1x02RW513O5 J2fUt6TCAfGFC6asGGCPSuH6yxpmbbzd/MijT66bemNN/SNXv5V7u76kqbzZorvvsrk7/wLAVGFf /gTwNEDa7pPdTWb4GinEM9PqDWqd2URUOrPZaOyn82SRUEhgaiRUqzOaqYoco+cgxQ1MlE06qtaZ zARnlkx3TNBjYC3tlt1pVZOKWVVBFVN5rYSDiHgseQ56GnKsq6vtTINCcU0QZ2cbsHn4RrLX7yhP qcDzrVZrfisV0CpblUOCgAvXhW1VbNvmK6/MDeYcC+D1GxaWn9t7PHeCVhxnLrx4GiTC8wrvKMYe 0RcKdKlzg5MZ+of/IzvshdVJIep42SE06dQRtzuo1scdz7JfQR7dAemvp3c/FY+LRI2TbMMh0Rx5 z9RPP+gj3oS7n/3yKas36GVejnhjIV9Moackv5gzKeBZkVlnudAE+0gPioOnlbXwFSnMvNwXMxRE 435fwMc09pglHjNEFtIim3chCVmRk4zxhdRXEFxIwmZEnDMrjDmVTF1zDekCL+qiDgvT1taNSF4u hrFl7FGqcRTaXWDHtTXg0FJEeP6pd7dIpYHmlrteXf2rdVe9tfFdelvul7qa8nBZ+aTxqckl6mX+ 8luP7yvSF/7xuetPbd5Jdfecpjs/GVq9S96Vy1XHVj5IC5dPADSbAM0jgKYTvpoB2WcQvHDrCnfp H9X3618xqSbo1C5JrXMFi+kxBYI6its9uMUK+Mkmq5qYXb8mHtHDPBxq9gJvUnrP+GvKgUc9iW+A l5f3I8wpD7zvw67SG9fbwzFz3Bbzef3egFfQxOIhi7SQFImehTSuRy5iCi6kXjuiqAGC7Rv4JQFI DkDa5QKJ1Wk42EBPHIh2RyFTUUWtycs1B8RaVWXTw3/Z4WucU3H362veWLPxratfz62gCUPSnfaU VPqLW1KTi/3++O1/uCXkef/n15+84oZc7qHf5S4fZDf0XHD4h3MSztTYh3N/A/gAvwPDf6HnhOeh 27pI5VHiGR6QPfaCas1kojVNthutwmR96XMO6vC43znOOfUZkARX6xQNABJaUbHyEy74Tp5e2Lpg QSvChIkLFvJUeF4pIju0VqlobQUIGJgfUWeAP3j3aYV8W0Q02puWihvEjdIO8XrpcfMRUXunuc/M aFRiJCJJYYPFGDC4wu6Ay6ineqYL6J02R8AJmJKIc51kFUMSCYthFpZYuMwmFtpsosSkMCuxWAst FivbYKEWw2YbDcNNpXJKYZsFEHZJ1ki0BMyD0tOiLFoFsDIDHFhWJ3U+Ta8lEi2XpZDBUxHviW+N 74+fiJ+KwwEQD8XleDtq9sQzce3uSwGgXrHrjMfbNjTYBU7aIOLX1ODlUnsI3MNmd3EG4qrvgjSq 32EpT+nARZC6eabrxRQXVvX1biIOUnEgH3d9t6AVGxq0DdCl+W4B9MNaUJbL6YLoh9ACa4QSxAtc 8eG6cHGxIAizc+F6f7lvRW7c5Itb6Z8L6CcTyyKNQz2+GSGnhvlX/OoEvXZbS6reJ+piMeOie1Rj vnr0R4mgOhZzikX2An3Lv+ibuTLonLBK1BacGfpgs4yiF8i33uWi9iW+DWxDxSPuJ0qfLnq69DXt e2X/TRtK6Gg6iU72XcA6fUvY9WxbxaP05dK3Sj8q+jhytug/kf9U2Cbp4jF/NFpsCQX0kYg1FCiM SBWxIiFKykMVo5IkVhSF/aEv9JfHYvrCaLkDpJAs1+n0OhISQyz0vueHdpW3KjrKWhwsZsVlVoun sqqfqvrC4zpwdWM6Nz+6oDadbRvfcZiUi+WsvO2TLt/B8rbBTkg8KFHiIA+g4/Sgh8cKRSNSWLyr HoNoRUsDhzY03cpUWVhyutVaVywSd8U08dKY5AylaYRHKW15mobdUR5JqJPK1Mk0CFxs+JpFKiSe J3Ku2tg3V3xSxuKlqYr6SGfp9aW/02o4RjsRAYNcDYFy8o0uVxOu5IJWo+Y1UO60Npu2kHNTpSTs /vn0niv25k4Nzbh4vM83oYvt+uT5nluGPrhlx6Tztv2A1tW275jUcTc7XiZfdOu+xZti0ujVQs/q +khs1kNdC/fZ5fVz565roEP35toqa+vO2zFr/t4GrsnMHP5APQf2UJQGjhLn8NY+vaHaD28HTzUj qRmp3IkKk1fvqy1o817vvNG727fTr1tpW2nfZNtk32l7RPOo+SHXy65XfQaNk8THO5v9W53bXdf7 tvmPqI4VGdLxZcGNmg3mDb7rC562aussNns0QOayAIWCVAhTbG74MZvdol4RECwrHHo6P22jNm9P nMbtsdVHaaWiQMLS0VsNQQMztHk8Zzii+/K5Qdg4XWe72qBWgmWBuP4Oi1GE2Ui4Gjh11qaDlTqg N+r0a8wmIFan1+qZxhc3Ow0xovEjMrotMaL3qmMQdlzegV1fcw3t6iVdvYr4ozaJ69saTop2jpU6 B2fhUUXycaWIV6nnFJd+fteWt0Y1zXvx3q2/3bD23w/9PnfgyKu08/nd983zhNJa9cpcsv/FH2zY e/Rw7rf7enZetnHlT+nE/ufpvIHGaBpqEAPdEXWvQn8papTnebcC8BKPRB6leHRJwTL3JbG7E/0l 6ktsy1HYa7vL+WCBZpFFGwqQSEQXClgikr/camGRGp+P6OxlfmsgGGCBRl2FlrZrqfaq0nFP5Tl9 Lych2BwArkjiYpzF20ihWFhRKBTWAqQA8uF4W0UhVUqDnSMkBeUxD9iLOWCnSCnRay+wFTBNSXGi OFksaL4tMY3T4XK4HR6HShONpcR4jCZ5JHkRFRf4eZRCXSrmiMS+Q06KJZinJiAkVcXtHjA8xfCR QC0uLjihiWgkAaYRx0BdrU2xDX1lY5useuf4+jI2/1+3P3Vs3g+e2zXuurliga/qkY7Lz29eOikW CzmWC1cuqy6OtczM9R/f/Y8fzveaVMNfvT87brCuvRvnM+p7N5cGQSE4Z1R9CXyMotPlQafKo2eh qoqqnqo9VY+63i582/WR698u/SbDeseV5TuFHxSqdxruEu4y3OZ4VHjUoAkVtjrkqvaqTYLaIBgM rEouNDXdrrpX/6Dqp/qHC9UmSrQzTaZXdQFtKBRwRyKpmaNGfVAaSGlmUvqqOqAJhwKJiEQ1xKQ1 E4eIAxxnqtDhFFxal7PPXu4eVZKg5SaTO8HcOo3Wqp2hZU2IdmsPaI9rT2o1Vm6raiurDqSeS7F0 qik1IzU/tSa1JbU7dV9Kl7pOdPY49zgFp1eugl/Gag6ambkxHPJUjmwPZXOMEFdXL/hmV+/aNDSD EeVSHBxsGJF3sLxgeNnrUyC8vxNxaCT5uiiI6hGRlurtwh/sextHaJVNKmdS3rblRSEv1xREK3Y+ UM1pD5oRK/dds16Mx01tSxcUVI+Z+bM/V8bGfbWqbGzUazGqDb54S5lqTTywvHv03arc0DsP/Gho zPrbq3LX9lSGModyM2MOS8S9VLhynkPCpsutuW1rkR34xX0T1cPAbykNy21ald5QKkSMU4xqjVpj ADEIcVXcEDfGTTOEiYYZxqWGDYbrDZbNiT3lT6meMvxC9QvDR6qPDGfVZw0GCDmIt0Ao4IhE4jNL S/tZibyiOBC34ridI1kf0MEg0c5k7FVNQFsUCkQjkk6rjTPTDDObQePPxWjMmymn5YSarZaghVka A1Z4FRlpLCoKeMoKHaUlUVZCS0xmc7TQEqjnFTFSEosyh66s/BnKoGCNo1rwyhQw1ADlX2w4A/zU pxsGlQJVHHYiTEGQfAPcd2CaIP2PxI+UTiO4+qIrj7tvUk7rnBfmUabgDMxwBGkjish3KPNrdFUV z107wyRJBY+tLHaBGIfG5lHFCVN1ecKy7tKGB4CoN2u3Xjo05+dX5BZwcvwaSzyfu2LnNp8VOJo1 fEoTVa8iVXSV7DSI6qgQsyQuD94Q3BbdFrs5cUPSII3IKtP/kF1JLrvGg2cu0y4zbjRujB4Vfqbq 1xyJHokfSRomSBMTcnJH4vqkel98b/IRzY+1jxpfir2a0E6xuGV4GXrctOiVgHtehLsd5ELUbHFR 2ysBV0Sq+o74ipC5FY+lioJUDJpdbndEXZMSzDURPbGJNmZrpEXeGv683iRW19hLPNU1z9BZwNVq eorjavoZrr1Y9UE90yvaix7ay3QxdbYB9pwi0TgG7TBLEYj4tWzjbqG8a4hwCdfKGXFlKKmxGkEt seIomLA2ZpL0MWIJiy0U302KmiRKhmJzjFhD5haiSyjyDgKPq7CK1FP4bS8GxhYCuqU4jn417GuZ 9zXvheyDILRpVLAJQJk1IuHsOC8Dt8fG587cd9evZs97/eZRl9Q6W0dJ7LapY0X9tbm/7P358At1 EylE3pKZpS/Z/RWFEIiRF197IvfG/S/k/rDLUUi97el4LKYORgum5D4aM3b5Eyt3PUEr6cOibmqi nmss4MfsU9BrkOySy8Jynb/JEAqwSMQbCtgjEV8oAM3MGArYIpLdho8CdF6rL+hjvkYjbO8B2T1R ajploBUG2dBjGDCo5iNiBk8ozBt9vkD1qTDtCQ+EWUVYDs8Pbw1nUNCM2wBZCc7HPdKIFaaouIU5 nEAbEF3fYVucNmrCDu6h5FDibjv26Xc3P3uJE4LVCKKIfW/D5zf/uW3Y/Fipc/gD4QxWmiRzZEN+ kXEsr5+9Jbslh8OKA6VwjVUfJzExxmKNhvuMFC6ShX2lgYC7ny7ts89I7T6qbDHx7GB9Gp6OvJsD GjE2lDLx706T6zPfONThXOU2Bzj0iMSlEvt1aUPUYzVOf/mmJ968sHHcLK2qzhsflxrtwjrUX1Pu 0LIXDm48dOnEOdPr/Q7DTJu3wF/a9Rb7LV8S1oQzELUZa4qR3XLtQlyYukLqKVbtkfZEH44K3yJy WiSPQuw+wSdFCV9iT2xrbH9MHeunR2UxFC5hwC+ul+tivyE/BFAOyM5vUe2JVxTLxfuLBW4mTIfn S0HZmTND4IuwB4YaznQ1cDePi/saRwyt70qe/4VCgILDok5trvpq2rdsjL05VsGkW/J0967aszxN 38tFv8vCRjC6f1m9RT/twf35/atdBgjU0hny2iJuCRuLqL7oiiJWMbq1tn30I+QVoo75a+lGstG/ MXA92eHfEdgXeDTw18CXAVPP6FOjWdAeLAgWilExprbarQXWQn68pK/VfAu/SKR8TCAeGYFicEwg FpHSoUBNBHzyBnk8CfhDOC0r8fsK/X4fqa0lpCxQVBgIFBFaG/ALQdyMqa3B/orHAn58U0RI3Wif 6KXeRsNx40kjM3pHK/zMX1StTAilrbLe4aweXRQsSZfzNhtvKz9VzgbKT8Aq89SN7qezYbZtwNYs 3c6ZXpdCSBBCqbUpLoYgkhQLzQ3K4n88HrHSdHDFqWFEI3UrGdzUV/64XOpay9V00pui9PtEl/eV 43AAWxinNjbsZ6dS5wQiv1UkhRO0h5Xk97ZzQn3pUEM+P/Qf99DnavOcrlyFpWx6iZGhMcWS9A3h amA17F5y7trvCKzBr1Kq1861LnZVNsViNFidNl4kzL2kqjjGd30AVtZe4DyMD3HsdvCa/2TN9TyR N5rqRb/fKvoDAat5TECncDBXJMLGBLQRyRYKOKeNeDqgV4RFv4taA4HGvA804IsQm9VCacAV1kGR IMzl1Fn1lHtBzHQ+TouuapeoJNpK/MRH232U+NaAE14VUdiZeKa3ay2gDvkPLUDJcaUh787gwgYq gaLQcQ/GDtVVLxJUuhWfhSIedogNV724Q3wR5hFsZzjqyXBGThXUEKtorSNrQz3hraGt4VvJHuue 0J7wIXIobFaFVOGkqtgYKUh6NWL/8EXZghokD8sFdv5NkVhIRXEP3e/PiBm/Dr7GFIUk4hfZnxJ1 hb4mdD0l6+3uJqKzFDQRnP+PlKyFTdb+4b/0oQ/SP2QtribFaOMXsTsptcFHogWnszCHjW+D/CkK Z2zFkF41NMd+KFX00oELx4Yj51aubA3lgj0dgVRLo3rauSPsvM2pMQwuE2lG91d7VcvPPXDZ+UDw 3FXCs9HaCItBO2sHdj+HDW0mRfQJuWqZuKzgLsPb9rc973jf8b8d+Itdr3Vri1zMbXJ5Xf5isbig uLDEayjippyLR44RpQWTVwxvbnBzAxyHAlvlxchoeC/KI/teeifbp9mnu9O01/wwe9j0svpl/S8C b9O3zWam0uo0eo0BpwHMZXKZnQH9Us9S/+XqjaYNng2BvdbD7sOBt32f64wXWiy4WOqs0ertRk9w NeeRIldCZA/xidgibbJABW861AQXjNUetDM79BKuLfZy/US2fq+DvQ0+Z97EjUPFY8jVkZlcHWmg RWIsEC+M62PquMfr9uIM0WyPAU6+GHXokHNpkLOZLDFq9jPEtMDgjBGvClEq1YCfgkjuPIVBjvOc Xn4odEinsder+4fPyEZ7PXPb600I+MD346ytHgrg35Gg9WPQmB6lg2ZcJBj568zvC5SwtWgU+pmW hUPFcRu87RDX/DyRm5H2GhGavwtW4B17X8ndlvvBKz/CXdjRTy+YsfmCfZe0dixcfI96vim3Oveb XO7F3Ln/vEjNtJzeNu1n9+beyz308PpKmXr+hDrjam7RV8PCeAjU7wWbPn6UhED9pvoQp/55xvoZ cbrXfdZ1NvTfiCqp8xNqCoHyIzQU0EQkM9dpJF+5nZT7/ZoCO4xdnRim4fe7nVud98Fs25WGh8SX P2QsMxOTaGLtpm4TM10Vi3/PHuDsVmGxCrUreiVIHWoA7AJAY8Q6A8qKglKh1+3yuJhGKgynadCL KOKA1yvkKuLuLo6RZN4s5wVFvYH2842iUBMOcTeWViPYuPrAD5NYwtc67xvH1QwazT24Z8FfwrbN 27Zdx5bmbuBuqm8dVifu3fZMxM3uGjrMbr1r700cglxr+D0gKJEyerncdIF3rfcuh6CT3NJU73n+ 8yIL/IsiWju/zCGqRY2qIn2Jb6NvY+QG6TXfq9KJtG6f8y3vf91feb7yqtM6Uz/77SEFxkqGgxkZ uZ6DGsJQIYAyKVIoSZEt0o1wK5OkP+zbGjkdORMRxEh75EREOBGhEVfSH5HisXJfP/2T7JJwoSZa Vl4AJIV+Ew5HIlCRdVArqRpqP0mKSZZ8Hwf+THaaojEIhRGcmUztnE+XjzuKC8T8VkUXtBME/oN7 GZoKd7jwH/djDnGMNQzCy5x3YPau7YIrGYUuzqS7LBCRXDAqvsxQcWmh1xHzxPFBfGEyTYu9iFLO sjRNuONp4vV967fMYzN/3FqCbWk01ad0pnq/u8DRSPNMFCep/ydUKy5LqLkjLmkqcJs+j/MQnJRD U0aclRvOnt6zqvVKXPDwJWpzF+SmdtbfuGvGrfezFblt38f+hCNX3LmwMZir6XQGhRhbwfYN/bRq +8p7budyFF+qqMLgtPW0TK53V8xJbAwLGgvVW7UpTYXb6kqVWVNiwpaOhFLR0tpkbeqSxM7EzuRj 1f3Jp6sL6r+x2CbLDjLXWhusZbWPjYLWMzcUCIaCFOdFl8sTi+YSr4gTtscciZRVF7carVa/0W9V bbBuSNxjfcj4lPFFqyaVsBpVkrpmlCDVOPQz8D1C/j8AUNM5eScaPkKVLXbvWBmH5WOtuiAUVVQd Co4q94zpp/UHR3ju6UHw1RRumXSdzpt6UEnhcgRKFVOPH9uOODL/jrySPajhV7rkkGAUrCyWiKdW GJdbNxs3Wa9PbE/dYX3SeMz4K+OvrGa4Lju5atuLQ4QCeFBgyCnHCPz0ABTKbTc4VeDSlGxViu3G vc7F5fBo1n59ylsnPG9MBD7ctnSjIyCnH/901vm5f78mr72wIugdY4/FSr+6tWd71bJtRx+Y8+lT LY3pHT5vkRkWXcPjxy89r0xKl4dnX7Zs2fWPf+GNFpYkGHnnw80zK+bObL5o64/mP3BaNDWHxnGs TgF1m0DdIfLkURLBObjbWx3hOuRY0V4disgguYGIqgIZRv+o1Z6D09gdCoiRiD4UsEak4B+93nNF gaDWi0/LmYibFz044emnSTkCbYgb1Y0e0U1D7nb3HrfgDolB2MLtwS3BPUFV8GmaxAWMn/aFuRAU z8K8axARQIKwEBQTb6jha0/W164sKJ3cQlZcwoDg//aDKJafZFOboqHpE+Lzl7jGjykbGpO3+Rbu bJzjiqun5W7dsiZs/+qv36qQKueYmXfSNRwiFcOn1A8CIuVUkO93Wz0R5jYUR5LSFdLNllukA9Lr 0rDE/7cfRgSRikwUeqDCbnFucR21vFLyTsnHJRa15LCIkVA4Lo0Kz41onw9/IbGHLYctrEoHHzGN RIKKuzEZKofDOAo9Ex4Nt8tFMaZpRVQPnTG0JUjnB4eDLHhVRYVc0V7RU7G/Ql2hs2qD8Cg2JhLt SZq8Kj2iS3I3EoCmSBfuUVYODxXGxSWvwpAi4RJ47+PxmCVmjOnSpLjELImQLWF9sSlNrBFEACq4 kuKKUA5Le9fC7bS2gKv1sEcVUTMiZwB3xXbNW9jcdIUup/iGtRXsGWnGWE/d1d2r72mLB8rOp7/1 10+zmZvOvJnpvm6VV75QPS0WHrN+aNnhDdMX/fQdlrhoutUVi5WXh2YNDX32VjYtv/IYu+uy+ghM JGil0O6ywEWYn5BI2JVjvNHqExKtUu11MFGio1203rXc9Zir36VyuuDo9nj4R3EB4gFjd1gCZpPO GDCFPVDf5f7hm+Ral1YTgiMQmodWW+YCSbocao2mxOVBzuPAdXqVSe2BAHbo1GptGJcfIPX1sNsG jpRNrpZcLi8+OSsnLnqtbA+ZZNR1m6jJE5FWhXE2+Y1xlfJ62oaG3NNbl0z4CN5AxZriB5NgLGAx O9rKU1xaqLlBhQxOJb3fO5D83rHkDpyQ8ZDnPEfcIZ2tGlomNHTOYIAkWGAp6gAutLCzuE6dN8Qc cMtTqsgDji91dsqY5KxcWTiXnl0/g+1ydoRcYjkNU1OFMxRMnQe0mMZXHv3qjKr2hQl6HExaA/ZR K4e6WOelU7xF5SabYkvZhz/Qcv/PKKaR+3br/5Ngk93LPY+5+92veD7xfJLQ1rupttQFD0MtmVE5 v7K9aiXRWSvFKu6H76naCsf9/qpMlf55erzyQ/IvMlypXqdf51lfsl1/nWc/ecSRwedmercngQ2a rqonk0MTR63F94N6IsL9t5VQvcej1esNHtx48+qMxAcq/LMK+M47+1z2gC1UEg6ECCjTZA2IQS94 06hkRWCUrMIdWWP/8LY+t9EA/e8KeXkC1Ig7QPzCiq4sUVKYSJSYiFGEhW0sc7sK3W6XHgfUhhK3 B3mPRqstSSTRKenClxcqscTrwf1GjVtzAUgxgU81+NcZJlgAxlGhIFRafPmr0+qr+JZpNtBnwWAT rIHIYHhNyIvDA4dFW7XIT1TZJX3f3T3K5vG6h7yekR2kmOR5szy/idbyXYTs9zYSP+f+dkd9m4Mv UVFY6v8ve+y7G+6Lrh2irkHHzcsGODlHtl0ypDdXh0pGth3s/q5efAMHNV7xRvKd983mU5xXtADC jHMJ7Esu+QoK8juxRvtpvLpQU5+bU5zL5G6J5Vom1Mps2nnpUdTwW9wSbG5it7YWOdxl//6jJI6e gV0pRGOm3V/dL6w4d6dq1iMTNbEYg1v/iqHVjO3ZMAO6KzVoww7XhqGrWevcFn8iDbMQu2Le8L+E 94UXcK+3gU2RHRpRrFeFxPpKuWFC9Y01t2nvqREauZhbMLXmcD29Wvtw2ZMNR8p+UfZO+O2yd2o+ KtPXaFu1UwqmuCbXdLiW6u4g99Q8hE8dD+tMVfh/Gxr3qe4uu3eUijS2Ny5ydjeudd3pOEAfGvMc PdVo0DnbG9ePFSbpmMPuYGP5W1501X82llZW4WxdmyotSZXGUqWJhqonqo5VCaqqcVVtVVdV3Vx1 X9VPqp6teqPqj1WDVcYenAmNLdSFdUt0l+lUTDdWN023WbdTd5/uYd0rut/r9EadT9ejEwrtOsFt jgdTGDGxND12EqvcS7rSaeaWE6lqqzvonu9e477PfcD9nFt70v139znIYbdsEavdDMLEaC0NlqZL m0pVpRMS462xILyZfyUkrW/Sb9E/p1eFkDCiFyHJ++kxWZQbtzYyubG7kTU+iksr/GtwuaS9pGnY R30pUifWsbpKtSzFqtfALGcValndru5Wq9SecaMvAIMctV254dKL21K9Z3pTP++CwMe1y7Vc8T7L tTCcbaXS4GhQus/wY5OhM6dxg4DrZWuV86+RC2K4YqgTG3B3gN+KWpvfpIdM7oCbkS7wRe6NHz3G LxlEQWWFERyOGeP1cUuRrYiYQvoieKnHCHVFRPSbi6ghgmi0amzRyH2hvASE4LwGfxR7XNnnvXDJ oy424qeNcX2Nqxpcq4PFlffeQnfj6l1eVta5uGSMF9u4mFTcuWzyEze0r+inNS65pDnp9ccnj226 YO1rq7ff47IYCs1e/H9mKye0zzVsGlsc9pRV7tq7fMbKJ265eEVdImB3O4KpklGt06omXTextyW5 N3eHHBZj7injp95B68+bWVtXLuHwmpHU8GmVDxzaRYrpTNlqn6gjLtHFqNtjiwZxj/RT2SfFtwna orjRaFlrtYpGFyEiLCpZ67UngM3s1BqeyKNxH7k9cSLBKhJyoj3Rk9ifyCQGEtqEBVfyPUHc50ra 7LJIK3Cbp10cEE/A+vOUTO9V7Khe5fYomFyfJ8xdR1ArQ0qK/3KP3xrt5EoevOJwQ/KLqEdJIt+V v5l3VSYy0vWscpUEBthp7uBICRbc0KFdeRx7YyqzOhaN8xthTKOPh2IxVaSYBkyeImK2BA3IS5p4 MfWai4pIWFcENzjezo9ckOTvGcDxIl2l7tH3hLZE79Q9on5Yd0Slu1a3Xc/wv5wZtgS3xO5U741q FPdHJ7VxFHOEK6iF9g73Fndj5f2bivkFaRuhBzbc1P149+bXrpu2of6eiNaQqqLbNIZpY6smj6ot boESNDS0uffEDfu+vK6idonqoZkFfh+LDT2Y694ijZ085slTb7eP4frPdNy9mw8uJpF/yJd+oaFR Pe3UP1z0EntJeof+lf6JaQ06WsqShXOCS/WXBDfoNxjWFu0teLLgSVxgfbrwcNHT0ktFx2M2Qh0F RLD4T5BT2CMn6CmKK1mFuBwdLoDO5P7cRm1/c8eN2vAklRFOTUuKckRUepp4Kvv0tmpcKd5PM3jC eyD2GXiE1R/0M3+ldqQfTw+XpKpP4IyVP6I3Waq1nujoWxTvVgoaO6ws5cgTVNR2eq3irBrsFfmF TxuIu56bXa6vLw5DrqztjSn0A4uojsM8T2NfXz7nyo0T1q4gB1teWnPs1NIr3rn1idbRY9v0Gpcr WBGpnj25buqojn+4r9xEvb947tYDP5hbP2H64iaPp6rtvm3/GJvCwTP+YzDQSitopQiejc2ydJf5 UfNR8xGnym6v0+FWYRFzBcv0OvcDwaKXpLzmDfo5RB/A/wvXTy86okttM0G/hOE6X/a4NoXjhVoM hXvlXKOAZSO6mTupANACSFrxH9OxDIwjbxoAApXxpA9ExlPcTLBUt6dPpFlPen+apYPwLMmcbmQH f/RrKjshqkRP+ehrFKCCSeZhChqCD18pDebtJly+Ab0MisoN9q48yXxDNCWRpLkgGpNiuIIa5zdG mMYSixTEi0nSjChmCxfTYmtKIRXusUtyjxOoJN1j7inoifQkM+mBtKbHssW+wbVF6klcUXa9a1fZ Xea9zntKH3biklqpZat1p43BXYj7Vgp1p/PUrawY1K0AANTNR+cXshTigSJew6lKuemsMFKFtqSa AtCTokQoKK8TfqPRlY3OXXbemol9y2Yve2rZ+GVj9aaKlh1TVsbcsXR1maukY7p62levXVoYhsu7 7fYLG/df++zezzZXN1PvSmfAnxy6/pbC4L33H3w8XrArvwuELtCYg4RojdyhsU8t7CpcU7jMscS9 qVAbMzyC78h/afs1+7Xwjvkdx7+E/5gNWxzgl7jAeqGwVFgT2ShsiVwnXG/5q/ljhz6pG3ZSnV6f 4tsgpBN0XeqQk9CJzn5acsgXL9Cq8f9o9ZmMeifHrhHYdcqeSLVzOVzqA4c5skH2yPYZLdU8ld22 GuJNR5oi8yOfRVSRUCLvvKpUuCr6K2mRPZ/GK6qVXWPCdjoBHdgTHqFA5dQgf12v62wqxTcLXLwK FeKyKRe2Xaep+Mteha1CTAZieTek3x4sIt5CJ66323xF1OVANOKG5C5hCMUufCoSzlNjXuJxBNpB sdpqxcUB4ecQuoaG9XNbFzQsHB2Z1r/pxMoLhx6/5defSjGHVB0eS794etWs8XOc91yz/5rn/kod nzxw/+VBe1XnPRJA0YLb6S3wOpXRlDxPTlNNQTDKrPhuLKgRtapkChdKEzbRbDLZwfBTotUUDWpf itBoUAOaxeFzk084ANWkMn6tg5ZZritFF8hjQ5p/82BNB9Mn00IaOjp1c1hXeHzV7qJEREYa2ZNI /+FkGS37HSGJEaAnTSfw+cjvToBD/s5stifg7x7ow0A8ldOJyuqQ6YSJQcUwVZi2mvaY9ptwd0iE T5hnT5g+N2lNuIhWkWbl6V+Fn6aLcbUILsNe+IdxsA22CBnXe7oXqpCS+wjfGJ35OfQlbkYC1Hk7 EuZ90+AgyD3Fr07y26rKFcp8zOUiCCpPUnXwDOODAptUU1VT/PW3WoqiggM4yC3uk3I5qhz0ZGHo wqHfN9UU3nADffPQFRunjKseB0NYdAWK2S6hdWjjxW6o4VHqq5jGdi5sTe8ZmDe6rKU2rPfbrA6D taLmwMaFQBNpy00U3gUlVZBx+L9jXpNnxkSjtak0tkN/Q9ltiadUR/XZxOHyz6NfTDAYqvQ1mnrN 2NB0tQ5km9AngqODk4I36bYn79E/UvbIeKM8KdoSNuNDOiKM0UYLGxPmtEnR2L3Y7I2yvb5RjhdX N8Jnjsjhrq5opLy5z+6ubuwXVLKjMH9BP1C312QKpJkgp0dVC/2CX8a9r9SovWltazxgncQfwTEw T2UDZhuaRCdNco/pHz6hsF7zGDqm0r0WnxytDWppmks3QSMnSltw+tGEyNqUbqHWlmALa5kUFnkl IlSK1CoG4RzqF9RyYby6AoTKqqm1OljNquVwPFXK3xdEbalckqgu5QqztXRN6e5Sob30RCkr3dgG dZl7pLnSebqB4xs3h0DFI/FQV+857JZBpZrfOIJqhA8pUsqFI3xQkkqP6MSFcjBcneoc5CIYf/la /H9oWHYM4MM0soFgNfgw93oqhmI+5XlbvbKboAHjHrRD4qqtovgUc2ems6oO105QoQXThvunurYu H/G4qlKb78PPIIrjgqIoc4HNS3H2Qzq2b1SBe81zUzRry8bVNf7kNzN6l11wzaNXn5jbevG1K9Zd f/mpTNeUMe0zahvay0KXLQ3Xb/jxjfdZfZcK964eVVI7dvFts9RjE1EcbcvbL7gxPGrUnIryyR55 beu1FaP2L9/5y8bL+u9Ys/q+vuaKr/5hC9ZUzZoy3mMrcnKZn0Qk4TaTEd9hvSs7i7baXE1W/nmp H0a7XfRrXNGgnYv5iDkatPGM5I4G/ceU/7RTA6TZqmurD2ioRsZpkV9jtxn0HJV+1OatJFlImEz5 u3xJt0vG8Pz6UnZMjfLxVEjKf/RX4FJSOV1WUZ1x0d1w6HA13XWFXNRexIJF3UX7izJFqnRRU9Fu ZAaKThVpAtMHsCXAKvDVDN8WYOD8tAJe6jxvaEIGf5wH/I/PBmCQKBfY8wfvUFfjzXMvkuW5c18r H5/TNhYVlreoVykVsnxRbuyQb1GdKhplEdciFkE2Bj6Mm+ksCl1JxDcgfjuHWrcd/0sgxQceGiIG cfIjihoj2K4CO/BfyDnADuxYREZ2SnhSozaMHL0kTUYOGfhjOGR40ldWXa2kgBBPZQkgyhjpbnwa p/hkrgja99szdiFtb7Lvtg/YT9nVdv7cqOpqnh4uK6+2KQBKpbp6vwchhXF+DRhAjp+lfB8cfd+C YdpXG75ZvPDKQr54rH4aDpguA2ebyKbLwfMYtduDsqGoTmctIA1kYrAAAnSihtbWeaJBKN5vH4qU RYP4PyjflgsjzdFggxSxRoMFkiQX00g0WNzP3jkiyWNpXTT4/7R1rcFRXFe6b/dMz6N7pntmWjOa V/e8NCPNaDQCz4CEhacFWAjLSDIGxdglMMVj/QCbx5I1EAIJJCl7s8Hr2FQ21Ja93q1Q8Y81RhjL 9g/LZS8Oqa2CysNOslUxtUttbGeLJWvi2CGS9ju3JYx3M1X0mdvTuvTj3Hu/c853Tt+K73Y5v6xg DeTznlx1UdbDXGbfwm0uc5vfj+rxA3Lfre0lI+IftDFb8GlqnZmrC4PPDZ4anBp0DWLxCmqapYla ORG3lzbidqVafzb+RvxCXLLjx2CnfZjNlbuq+KnKf6q+Ub2A0snVY1Wx+qGgLbZgspeX9dM9T6Rz 9fv7L/WLz/Wf6p/ql2rYXOyX+uMrByfFuyeyw0CeRB6Zp2Hx6Ql5F3NyvI97PKGb3GVFLJImvNIw 4+dpqqSdnDpHUU8sX3N2XKG2IJlWAm65u5gqLnB3mUz2pJWEydRATV6IgLVqOrBj3kFNprmwau0+ O2xlvL4MDDu35cuWhEzW64EXG4cJMN8BWgv3D14aFGW1oNZVe/BdxT3iHvEO+0aUqUF3jzgij6h/ RP1MrJi7djtQdRAqFU3zGz2htzRBw/90ArRhLsMKrfRXJ+Yl3Np8PyTfrylOG5K39bm/g6T2S8rn sXAyQjn2bVnEsS7fcs/BTZpJK7SHwDHto5V8zueAff9Hgc+vPjJ87/7s6HdHN+2plm6bSfcmw0Yl XbmnGor1z6SQu2HUku3ZWgO/mbfGQ6XbpJMH1i5fO3bv6PrHj898bXvdWyi4S8lN7KmDK7LN5ox/ K0xrTAH5BWvYU4fsQos1NOPf3JQLBTkT3S7qD9W9NCsMILq+GOOiIrpexWsSPnhZ6fXJrEq61DPU GK0yt9stt8nSL8V3pZ8npBa54R4QpXfZ+0kxrAXBwqxYQT2rV17U3gBRN5kyCpY2Kf6bHcoVC1Y2 n/MXrGA+nypYKOTxK7slXypYFWQoZTKaFvTHt7kllwcR4I0TF2FXTc6+bI+1Ntg+2Piy30LqUhkZ LXa2v2lA9zWDZYwLhmjYt6+sG/byhmH3LsGXxiJsuhdgg2Fj2KV2bHIFbIArDJtctGDfk+dLs6qn qmKtuhPDxr6tQdc4gR64RCdcoh8uO7scid54G32RtDXYDMgG4LTicqlUpH1BnOBV5HMWp5DzJNGu icVL6lwCsPBDfOlCvRjvpNEHqghmMkxiTshHpwmfPuRFc745LawNFBLCOMQf7II12EcWIQ0M+syN PW6bZfAfQqHhEofVDk3XiCXPWxFk/mocJ1NusGbDA6/hqNNZgyf+UkcUgthNFgAcOUQCm9PmP6PI /19n3xo8eud9jxk6VLLUiOnhSmLsjlJjpjSnnvuGV24d6n1+5untDU+h4GmLb2bP7enLHphRHuzB jpvUEKs61QB4BXoYELJsrd36ToKVVBb+kjdYDIDkHyt6fIgD2S5+vzGNuuwiXKMu5kpQaAe2OBcr HdHkYqJ3aZ322gV4NabyF5Ebl7fz9+fpK/ybz4Ka4JBz7IvE/MRNRL9comuSZ2GCKYgMgUZ0ptTo gV9s/uE5VjshfnyoOgAvc0APqM/J+V/B4NoT2ywzY4qyEWlBZodcTKYSqXhKIg5PCVeZNlnUFzaF Vk+6RByeEjOloAkGT8wUUu5Yifxc8/ydMiXUYDJc0M56Udhwlb5Pde+UD6mH9J3xw/Ix9Zh+OP4j 8ZzlP+SBja8daj3mORw4rB1r9cLrhUA20XXmyAb5HCXdxCgiiHkJiI4YfpiXSkU2s/8nO7buf++n lz+8cMuqWFAZ7KqapYBRbEtIb331gyfe+ebzrP2t86yycvV//Pjh8ZV3xHNLN7LsC4fSLbTCDsGA eARPsIOVgMOLSq9iqLpzQzEccUN/M5EETqUbjRUf8vBpq8GbadPZrelc2iUjWtcr7LjyZEVU4kjv 1qg+SIeV1k29Q2YtiBMKOfh0OFCJnbNQGAJAJV+wOgiopPP+hZpt9kHfU4ub2l/QFCN0yGbar40L SAbfiBqcG1950nPRc8kjwQ30mq0IHVrMAnYr5ylwDm0iMdFd53H0iWTGiacjc6k+lWM7EdjM6agq 8avysIPwHSwHKHft2jgyBZBGxdfNPhjoxA7ykL+TL5RA4XO4DwssHq4z2OYdY+QkIVs7Rs+FLyLE sgTaBtw7P/7t/p7l/V2NYY8/kE50tGSYR631zHiWVrz+Yrd08md/u/H25vI7VrjkaK65ae97Pb16 Mg6Tz927X3SPRlPIzcIzumv2svgzPKOF4gtgT3W36E2XHugw9HSHSzaixrm2c8Vf6h/pn+meDr2t 3KMvKn9LeSb/TOGHyj/mJ5UzeQVMg4C3o0VdqQypsq3YqhheaAknRIsxmnVQsjvcfJamcnY7aqCc CNewo177uNJqxU8krUSChhUOeRJkWFRQt834iejH4bC7WPGEzWJYCTuuERup/Ow+YnpeOuMz5HX0 xfb7DHGdk7aKXmxF0epOKxek9hKMXgtmfUKrs1p9pL6x/mj9UP3FulwPezPUCW3FdQ6XBBZe3fmW S3S000nhrzXkhlBP5Plsj99CA54ma3haQDOBID/3y94MJlEvHRbDn3htI9v09rXksYm2oYlro2GL eRWu0l2f7CYH3/yfZjO4Q/xSfOgjuwF/j9bUBLrgEr1wiY5Inr7RV2X95Qr54+04s9tbcZNRuIHZ ehIb4mragajznxKBkM7RNE2taU7O/vuEajgSR1CbqJ385PhxrwpuLLhhHOs2caDbxFFuY/4QSpQA 0nPSAP+LF5vQarY/1KwhixAbXAtdJh3kHEX/c1sVp4ahfnHCkZdsHxaetio8LNj7U9uHL21VrEpt k7O/m4ADEfIyIuJNNYUwA5/x6PyAq+DH4u5Hslxvot+45g1YcinmpRvMG3IrzzFvYKMuFp/WckuP 9HcsMTKsOD78nbHlO00lG83querfD3Qv7Xvg76rLnvmbO1cmQ+Foq/TmzJvfeWBxIRnveOevx4aP j5aVhWz06NFby90DKx/qWbN5+4ttmgaGGvj3sx+Lx13TqFz0PRSUUY6pIt8oqhCfZGfxfFyGIbUc EZmcUbrxphJJ2e3bGlRElPkI2mm3clZNJJkLr85xWyj4UY5EW/YZRsTG3Y+QSulA77XIVORiRIrE EzS7QAFxfwEVrnE0gOWfF9VBU2hOXx6nykEECq6BZUMVO5wkIxRZoKyJhfDmUfgKxI58g1KfJ3/9 a62o9y8x7zq7/kDIv/+rLy1zTc+8sHn6jbtq6c3Rqc1Lc8fZZ/n1bwOAMaoa4FognRRy7KlXhQLO 7gfAg4WLBdGnJtWyukp19arfT/0wNZly/bfnilfMEVcrSxtYlBHYkxHX+x4262FkSubzjv1kFiwk qCM7zB/f6lP8CtItcQNkQS47I79sygTvZOA9GRBPJognE7qTCdjJBOxkwnkyoTuZ0N0FmWkyy8gX ZBH8RVmE+fq67S8QaiwA5RVohKETLtEPl0B3JE+XnZ/RM9+NLknacYC8qQKzCqcKYq2wsyAWDAuR 0rJGE80EOuYSGI9LYDyS6IyEHQHUuxpkteBU8GJQCsbzc6BvbuLnLFJyAXA9pw2Cpze1yCOACiMO 1OOgjyM+oqGRU4C7awHV5i1gHsXizB2wRuae+qLFtJw3pH9tXzpzZPk37x45UC7dxg5GOpKFdHsP GQ7ThYcByQ6Ortr09efZHrIEpr+2ZYkZSYywa3N2QQR47AqefoodtRNhEZWuwkKYubrN9bH1raPm K+ol86rpwaRy+HSgATFlF1NWvRkdiY7JkifotTwuEKmTrVbMeSrMbclRvcWC0/xx+yFNSGWSqdSA phsIYIIotEEL4lswFcR7EGQ9gxlCp9mSQpOinoxpSdTLZO4UFkaUqZJTgpL8g76vW7O1UU3SxoMf MSqDw5egDKJceCuJxS4wiY3SmU30jdT5GSbzpbppB7S6zr0zl0yXbrJTuA4xDSwhTWTfxIgDEKdn A3p/pTIdRwmtVqeEFUFvIm+Qlw0/EXnDIQGhthUnAb1d+QIFaK4mwbzgD2+cSKJ2i0kna9IMKuqh VJPRBrpz6bTRy0ULiU9PwwuJB84/690M45iIQU7AGmQMhK+pDZ4sY7+d+ZfeTKzKflcLtXZ+/0Cj 2ssWdvb0zPwoJf78SD4BMlAoarZtm/kHVvv6IlQCaGuTFx2dztEoD81edp/Gc+4Uv3QmLIRYJxGr T6LECrzBLiWqxHS8h0p3eWpGLVqLNY1mtBkbMUaiI7F73PeEx8wd7m3+LcoD4YejD8e2mNusL+v7 wwejX4ntMfdlHisd6/pe5RfyB8J/Bj/q/FT4vf/3yifB651F2S8rctClu0Mu0+4a7bq/y4cCYuFw KBIR/Lpi+VvNuNXqQhSr0m6VHK+cy2v5YpEMziwStWKIE1tFe3L2yxMhSYSts8d+0BI6M5XOzgEr Y1hWJiL4BNkShQ2Wiabpknzg5G8I8VoXiIEK4kAojLoXYR3FV12+TjMSZoIcUjLst5nroO1XSlYF JVupUKuL+TtLxdaY3yd3SqKgdJHOdzYgYOf11LnMZLm0W+OJepdNgR9ck/giklHh3CntzSDCWD1r 3x/aiXzG11kV9CEfRgyPDIKdMXvjVVu+eLVrUhzjmniDi7aL84nGbyYUUdQdH+6k+ZxXxFVzFzRz jqJ2g1C06wZZ7fNvtKvyRdpa5YvlNL5QVYNTilDmAZYExYygx6+iCvEl8rwjXjUvPwVA6I16jd4Y /jnKC9VFwe557SWjIxLhmJZ0l7duVmXp8qxwvf5ZTyl+C/tFdyHz+FG/Cc71+z1m+uhjieJi1tK1 qDLzx5T4z9NrxB+cqGWCbW1IsVo38122o3WoA8U5pHgsOoTm6GCiVHBB0xtfmY6TpsNIwYsFTwph sQyYhvwNvEjwuuQKINXB9sF7L2USeCkSWhNmhuRVewhBpCWo0/0AXkW2V31C/LZ0PHCdoodD0oC6 InCfNKa+Lv1Y8oDH2Fbfq/6PKNa8NV8mlAmPqe+pv1H/gNiy6FKToqG6HLe93a6K8ASKCfGg+IT4 sugWA8yttqh71W+or6luFcXNB/xyYID5eTwAD5TSwhEMwqSDN7WEoTS9IX/T6wuFQ7gENRDeEvjL wNHA04F/CpwJnAtcDnwS8AU2OFX5RCYFBJ9qKHg5kzSg+Caloh1Q/EJYR0ZKmPnlMO1pDwwI4lmB +Q1yTwrwlZD+gkyZULxnQdS7j0l7lY5wRaA5Xjd6BRtDsInKyeKjuKmTYtvpwF5Gv/kJQgP6xyPw tgzNTabDoAitnoa/ETMq2EBAMch24aRK0HHgWoRn8Qolw4/rfVd4nRG6VLpaXj9qN1ezANQL0BSP 5BIBWsjXSO14Gw4+LpHDRPI0Mpv4yKis/9bBt6kv/bx+XuBeDnK5g5RAPzOHrC+hQ2BZ8uzZPszB Yis26ObKS5TYCOBZQanjBiP2LHgi2RZG0PIWafmffiKKxzetrafyUmRGtKdeqKSi0tr86s1MT/7p zCNPUZSCf2azIEP+uQ9KVWB+1RC0oIqYTj3MOK+D6VS6LKFSE9W4pOqWNV7bciGqfDXAyVyMGty9 whJhBd5YMIDXpw4Kq8AAvxPviRhF9fE1qKs9hqrY9wjrhXuR1Ud6T1n69JEFkCxX3LX63uEVlbUP 7ti6Z3jrX615dMemR0bvri57dPuW1WuF/wXwn3zuCmVuZHN0cmVhbQplbmRvYmoKMjIgMCBvYmoK MjI2NzAKZW5kb2JqCjIzIDAgb2JqCigyOW4xMzgyMDEpCmVuZG9iagoyNCAwIG9iagooTWFjIE9T IFggMTAuOC41IFF1YXJ0eiBQREZDb250ZXh0KQplbmRvYmoKMjUgMCBvYmoKKEN1bGxlbiBKZW5u aW5ncykKZW5kb2JqCjI2IDAgb2JqCigpCmVuZG9iagoyNyAwIG9iagooV29yZCkKZW5kb2JqCjI4 IDAgb2JqCihEOjIwMTMxMTA0MjIxMTIyWjAwJzAwJykKZW5kb2JqCjI5IDAgb2JqCigpCmVuZG9i agozMCAwIG9iagpbICgpIF0KZW5kb2JqCjEgMCBvYmoKPDwgL1RpdGxlIDIzIDAgUiAvQXV0aG9y IDI1IDAgUiAvU3ViamVjdCAyNiAwIFIgL1Byb2R1Y2VyIDI0IDAgUiAvQ3JlYXRvcgoyNyAwIFIg L0NyZWF0aW9uRGF0ZSAyOCAwIFIgL01vZERhdGUgMjggMCBSIC9LZXl3b3JkcyAyOSAwIFIgL0FB UEw6S2V5d29yZHMKMzAgMCBSID4+CmVuZG9iagp4cmVmCjAgMzEKMDAwMDAwMDAwMCA2NTUzNSBm IAowMDAwMDcwNzA1IDAwMDAwIG4gCjAwMDAwMDUxNzMgMDAwMDAgbiAKMDAwMDAwODE4NSAwMDAw MCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDUxNTMgMDAwMDAgbiAKMDAwMDAwNTI4NyAw MDAwMCBuIAowMDAwMDA4MTQ5IDAwMDAwIG4gCjAwMDAwNDY5MzkgMDAwMDAgbiAKMDAwMDAwODMy OCAwMDAwMCBuIAowMDAwMDQxODYwIDAwMDAwIG4gCjAwMDAwMDU0MTMgMDAwMDAgbiAKMDAwMDAw ODEyOCAwMDAwMCBuIAowMDAwMDA4Mjc4IDAwMDAwIG4gCjAwMDAwMDg5OTcgMDAwMDAgbiAKMDAw MDAwOTI2NyAwMDAwMCBuIAowMDAwMDQxODM4IDAwMDAwIG4gCjAwMDAwNDIwMzMgMDAwMDAgbiAK MDAwMDA0MjI5MyAwMDAwMCBuIAowMDAwMDQ2OTE4IDAwMDAwIG4gCjAwMDAwNDc0MDYgMDAwMDAg biAKMDAwMDA0NzY4MiAwMDAwMCBuIAowMDAwMDcwNDQzIDAwMDAwIG4gCjAwMDAwNzA0NjUgMDAw MDAgbiAKMDAwMDA3MDQ5MyAwMDAwMCBuIAowMDAwMDcwNTQ1IDAwMDAwIG4gCjAwMDAwNzA1Nzkg MDAwMDAgbiAKMDAwMDA3MDU5OCAwMDAwMCBuIAowMDAwMDcwNjIxIDAwMDAwIG4gCjAwMDAwNzA2 NjMgMDAwMDAgbiAKMDAwMDA3MDY4MiAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDMxIC9Sb290 IDEzIDAgUiAvSW5mbyAxIDAgUiAvSUQgWyA8ZGYyZjQ5OGViODVmNWY2MTBmZWEyYzY5YTQxZDdi MTg+CjxkZjJmNDk4ZWI4NWY1ZjYxMGZlYTJjNjlhNDFkN2IxOD4gXSA+PgpzdGFydHhyZWYKNzA4 ODAKJSVFT0YK --Apple-Mail=_39DF267F-BCD0-4EAC-AE2A-6563F15154B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 4, 2013, at 5:52 AM, Stephan Wenger wrote: > Hi rtcweb and Jari, >=20 > Jari, please distribute further as you deem necessary, with or without = my > notes below. >=20 > The attached liaison statement, received from MPEG tonight, is = addressed > to the =B3IETF=B2 (which is why Jari is copied specifically), but I = believe > it=B9s mostly if not exclusively rtcweb that is interested. Note that > MPEG=B9s closing plenary was past Friday; this almost sets a record = for > turn-around time. >=20 > The liaison statement is short and concise, so I do not attempt to > summarize it.=20 >=20 > To put things into perspective (with the caveat that I do not attend = most > technical meetings in MPEG, as I=B9m busy with JCT-VC), allow me to = fill in > some context >=20 > IVC is a cleaned-up version of the MPEG-1 video compression = technology, > riding the expiration of many of the second generation video coding > patents (MPEG-1 part 2 was ratified in 1993). WebVC has many = similarities > with the Chinese AVS, and both are essentially stripped down versions = of > H.264 (baseline) with bug fixes and minor enhancements of known H.264 > shortcomings. VCB is VP8 with an MPEG-style specification and, AFAIK = and > so far, compatible with what=B9s out as VP8 in the wild. >=20 > WebVC is fairly well along the approval process. Despite the =B3good > results=B2 reported, few folks I talk to expect IVC to go anywhere = anytime > soon. Some were expecting that VCB would enter ISO=B9s approval = process at > this meeting (issue of a Committee Draft, CD), but that also didn=B9t = happen. >=20 > Many on this list are probably more familiar with the IETF=B9s and = W3C=B9s > patent policies than with MPEG=B9s, and the additional constraints = used in > video coding in MPEG. So here is a quick primer. The common = ITU/ISO/IEC > patent policy and its associated guidelines require formal, binding = IPR > declarations with authorized signature once the spec is stable and its > clear that the patented technology is included, which implies to most = that > declarations are expected only towards the end of the approval = process. > However, contributors in all three aforementioned projects (though not = in > most other MPEG subgroups) are expected make non-binding written > statements in their contributions, similar to what happened in JVT. = There > is also an oral call for IPR at the begin of any MPEG meeting, but = that is > boilerplate and the reply is almost always silence. >=20 > All three technologies are developed in a relatively small sub-group = (a > few dozen people at most) while the majority of video coding experts = (the > record was around 350, IIRC) sit in the group known as JCT-VC and work = on > H.265. It is entirely possibly that =B3RAND" or even =B3unavailable=B2 = IPR > declarations will be received for all three standards under = development > towards the end of the process, without an early warning by = non-binding > written or oral statements in the subgroup. Those declarations would > AFAIK still be timely, because a) the patent policy guidelines = discourage > written IPR declarations to the ISO secretariat before the spec is = stable > (something many people associate with the DIS state), b) many = companies > interested in video coding do not follow those three projects in = detail, > perhaps because they focus on H.265, and c) once the projects are in = the > final stages of the approval process, companies may wake up because, > arguably, only then the declaration requirements come into play. Note > also that, unlike W3C, ISO does not have a formal process to deal with > situations where an unfavorable IPR declaration has been received. = The > policy only sets the requirement that the approved standard does not > include provisions dependent on the unavailable patent. >=20 > The common ITU/ISO/IEC patent policy can be found here: > http://www.itu.int/en/ITU-T/ipr/Pages/policy.aspx > The guidelines are here: > http://www.itu.int/dms_pub/itu-t/oth/04/04/T04040000010003PDFE.pdf > (I=B9m using the ITU web site as I know where to find things; I=B9m = sure you > can find identical docs on the ISO site somewhere.) >=20 >=20 > Regards, > Stephan >=20 >=20 >=20 >=20 > On 11.4.2013, 00:48 , "WATANABE Shinji" = wrote: >=20 >> Dear Sir or Madam, >>=20 >> In accordance with Resolutions taken >> at the 106th SC 29/WG 11 meeting, >> 2013-10-28/11-01, Geneva, Switzerland, >> I am pleased to send attached Liaison statement. >>=20 >> If you have any questions, please do not hesitate to contact me. >> Thank you for your cooperation. >>=20 >>=20 >> Best Regards, >> Shinji Watanabe >>=20 >> ----- >> WATANABE Shinji (Mr.) >> Secretary, ISO/IEC JTC 1/SC 29 >> IPSJ/ITSCJ >> 308-3 Kikai-Shinko-Kaikan Bldg. >> 3-5-8 Shiba-koen, Minato-ku, Tokyo 105-0011 Japan >> Tel: +81-3-3431-2808 Fax: +81-3-3431-6493 >> Mail: watanabe@itscj.ipsj.or.jp >=20 > <29n13820.zip>_______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_39DF267F-BCD0-4EAC-AE2A-6563F15154B4-- From bernard_aboba@hotmail.com Mon Nov 4 15:14:17 2013 Return-Path: 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 1405C11E821A for ; Mon, 4 Nov 2013 15:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 M-iCNkUWl9xs for ; Mon, 4 Nov 2013 15:14:12 -0800 (PST) Received: from blu0-omc3-s32.blu0.hotmail.com (blu0-omc3-s32.blu0.hotmail.com [65.55.116.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7856A21E8267 for ; Mon, 4 Nov 2013 15:14:11 -0800 (PST) Received: from BLU169-W55 ([65.55.116.72]) by blu0-omc3-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Nov 2013 15:14:11 -0800 X-TMN: [CJVwE9hOvd/kFe2oDFE8eMjMB7JS6nne] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_3be80354-82da-4de9-96bd-345517333d1d_" From: Bernard Aboba To: "rtcweb@ietf.org" Date: Mon, 4 Nov 2013 15:14:10 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2013 23:14:11.0251 (UTC) FILETIME=[92053030:01CED9B3] Subject: [rtcweb] Reflection of SRTP/SDES discussions at IETF 87? X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 23:14:17 -0000 --_3be80354-82da-4de9-96bd-345517333d1d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF 87 we had a discussion of SRTP/SDES. In looking at the most recent= version of several documents=2C I didn't see the consensus of that discuss= ion reflected. Was that because the consensus in the room wasn't verified = on the list=2C or some other reason? Or maybe I missed the text somewhere?= Here is what seemingly relates to this topic:=20 =20 http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07 Section 5.5:= =20 =20 [OPEN ISSUE: What should the settings be here? MUST?] Implementations MAY support SDES for media traffic for backward compatibility purposes. =20 [BA] As I recall=2C the room consensus was MUST NOT with respect to SRTP/SD= ES=2C no?=20 =20 http://tools.ietf.org/html/draft-ietf-rtcweb-security =20 [BA] Nothing related to key management (which seems fine).=20 =20 http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage =20 [BA] The security and security-architecture documents are referenced norma= tively in Section 13 Security Considerations (which seems fine).=20 = --_3be80354-82da-4de9-96bd-345517333d1d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At IETF 87 we had a discussion o= f SRTP/SDES. =3B In looking at the most recent version of several docum= ents=2C I didn't see the consensus of that discussion reflected. =3B Wa= s that because the consensus in the room wasn't verified on the list=2C or = some other reason? =3B Or maybe I missed the text somewhere? =3B He= re is what seemingly relates to this topic:
 =3B
http://tools.iet= f.org/html/draft-ietf-rtcweb-security-arch-07 =3BSection 5.5:
&= nbsp=3B
 =3B =3B [OPEN ISSUE: =3B What should the settings b= e here? =3B MUST?]
 =3B =3B Implementations MAY support SDES= for media traffic for backward
 =3B =3B compatibility purposes.=
 =3B
[BA] As I recall=2C the room consensus was MUST =3BNOT = with respect to SRTP/SDES=2C no?
 =3B
http://tools.ietf.org/html/draft-ie= tf-rtcweb-security
 =3B
[BA] Nothing related to key managemen= t (which seems fine).
 =3B
http://tools.ietf.org/html/draft-ietf-rtcweb-= rtp-usage
 =3B
[BA] =3B The security and security-archite= cture documents are referenced normatively in Section 13 Security Considera= tions (which seems fine).
= --_3be80354-82da-4de9-96bd-345517333d1d_-- From bernard_aboba@hotmail.com Mon Nov 4 15:15:54 2013 Return-Path: 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 5884921E80ED for ; Mon, 4 Nov 2013 15:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.273 X-Spam-Level: X-Spam-Status: No, score=-102.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 DM6HgLNtjmLf for ; Mon, 4 Nov 2013 15:15:49 -0800 (PST) Received: from blu0-omc3-s8.blu0.hotmail.com (blu0-omc3-s8.blu0.hotmail.com [65.55.116.83]) by ietfa.amsl.com (Postfix) with ESMTP id E2AA911E8200 for ; Mon, 4 Nov 2013 15:15:45 -0800 (PST) Received: from BLU169-W25 ([65.55.116.73]) by blu0-omc3-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Nov 2013 15:15:45 -0800 X-TMN: [J7Db2QM+hSvmNXetlj4lJ38B/pOSjeNP] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_35339612-d356-4b3b-af9e-2932f326875b_" From: Bernard Aboba To: "rtcweb@ietf.org" Date: Mon, 4 Nov 2013 15:15:44 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2013 23:15:45.0621 (UTC) FILETIME=[CA44E850:01CED9B3] Subject: [rtcweb] Reflection of SRTP/SDES discussions at IETF 87? X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 23:15:54 -0000 --_35339612-d356-4b3b-af9e-2932f326875b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF 87 we had a discussion of SRTP/SDES. In looking at the most recent= version of several documents=2C I didn't see the consensus of that discuss= ion reflected. Was that because the consensus in the room wasn't verified = on the list=2C or some other reason? Or maybe I missed the text somewhere?= Here is what seemingly relates to this topic:=20 =20 http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07 Section 5.5:= =20 =20 [OPEN ISSUE: What should the settings be here? MUST?] Implementations MAY support SDES for media traffic for backward compatibility purposes. =20 [BA] As I recall=2C the room consensus was MUST NOT with respect to SRTP/SD= ES=2C no?=20 =20 http://tools.ietf.org/html/draft-ietf-rtcweb-security =20 [BA] Nothing related to key management (which seems fine).=20 =20 http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage =20 [BA] The security and security-architecture documents are referenced norma= tively in Section 13 Security Considerations (which seems fine).=20 = --_35339612-d356-4b3b-af9e-2932f326875b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At IETF 87 we had a discussion o= f SRTP/SDES. =3B In looking at the most recent version of several docum= ents=2C I didn't see the consensus of that discussion reflected. =3B Wa= s that because the consensus in the room wasn't verified on the list=2C or = some other reason? =3B Or maybe I missed the text somewhere? =3B He= re is what seemingly relates to this topic:
 =3B
http://tools.iet= f.org/html/draft-ietf-rtcweb-security-arch-07 =3BSection 5.5:
&= nbsp=3B
 =3B =3B [OPEN ISSUE: =3B What should the settings b= e here? =3B MUST?]
 =3B =3B Implementations MAY support SDES= for media traffic for backward
 =3B =3B compatibility purposes.=
 =3B
[BA] As I recall=2C the room consensus was MUST =3BNOT = with respect to SRTP/SDES=2C no?
 =3B
http://tools.ietf.org/html/draft-ie= tf-rtcweb-security
 =3B
[BA] Nothing related to key managemen= t (which seems fine).
 =3B
http://tools.ietf.org/html/draft-ietf-rtcweb-= rtp-usage
 =3B
[BA] =3B The security and security-archite= cture documents are referenced normatively in Section 13 Security Considera= tions (which seems fine).
= --_35339612-d356-4b3b-af9e-2932f326875b_-- From randell-ietf@jesup.org Mon Nov 4 15:28:39 2013 Return-Path: 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 150A511E821A for ; Mon, 4 Nov 2013 15:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 RsYmlP3AFDlQ for ; Mon, 4 Nov 2013 15:28:34 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id BD8A521E82B1 for ; Mon, 4 Nov 2013 15:28:31 -0800 (PST) Received: from dhcp-a56f.meeting.ietf.org ([31.133.165.111]:59056) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VdTZP-000Gsh-6L for rtcweb@ietf.org; Mon, 04 Nov 2013 17:28:31 -0600 Message-ID: <52782D9E.3050905@jesup.org> Date: Mon, 04 Nov 2013 15:28:30 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060300020003000201040309" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Subject: Re: [rtcweb] Reflection of SRTP/SDES discussions at IETF 87? X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 23:28:39 -0000 This is a multi-part message in MIME format. --------------060300020003000201040309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/4/2013 3:15 PM, Bernard Aboba wrote: > At IETF 87 we had a discussion of SRTP/SDES. In looking at the most > recent version of several documents, I didn't see the consensus of > that discussion reflected. Was that because the consensus in the room > wasn't verified on the list, or some other reason? Or maybe I missed > the text somewhere? Here is what seemingly relates to this topic: I think people just didn't update them to match. > > http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07 Section > 5.5: > > [OPEN ISSUE: What should the settings be here? MUST?] > Implementations MAY support SDES for media traffic for backward > compatibility purposes. > > [BA] As I recall, the room consensus was MUST NOT with respect to > SRTP/SDES, no? Yes. Strong consensus in-room (as best I could tell remotely) -- Randell Jesup randell-ietf@jesup.org --------------060300020003000201040309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/4/2013 3:15 PM, Bernard Aboba wrote:
At IETF 87 we had a discussion of SRTP/SDES.  In looking at the most recent version of several documents, I didn't see the consensus of that discussion reflected.  Was that because the consensus in the room wasn't verified on the list, or some other reason?  Or maybe I missed the text somewhere?  Here is what seemingly relates to this topic:

I think people just didn't update them to match.

 
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07 Section 5.5:
 
   [OPEN ISSUE:  What should the settings be here?  MUST?]
   Implementations MAY support SDES for media traffic for backward
   compatibility purposes.
 
[BA] As I recall, the room consensus was MUST NOT with respect to SRTP/SDES, no?

Yes.  Strong consensus in-room (as best I could tell remotely)

-- 
Randell Jesup
randell-ietf@jesup.org
--------------060300020003000201040309-- From richard@shockey.us Mon Nov 4 15:32:46 2013 Return-Path: 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 2045E11E82CC for ; Mon, 4 Nov 2013 15:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.943 X-Spam-Level: X-Spam-Status: No, score=-101.943 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 V9SITDVvEvzB for ; Mon, 4 Nov 2013 15:32:39 -0800 (PST) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id CCE5F11E82E3 for ; Mon, 4 Nov 2013 15:32:33 -0800 (PST) Received: (qmail 23499 invoked by uid 0); 4 Nov 2013 23:32:09 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.mail.unifiedlayer.com with SMTP; 4 Nov 2013 23:32:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=25hlnE8lFEr0/73Ch2GVAjQ+jjttyCHt3ccle03u0VE=; b=Mye/DzFkAIrxblKmbrtytIW7UBIouQj7K1thFBGHXyKqqPZeMg3FtJSiSPqn6yLePWBCkXZgJddGw3jqj4JWFiPgMYXholPcYD+Ova4Tt5IUPxYXLl8R8OE9TNRpJGr2; Received: from [173.79.179.104] (port=61123 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VdTcv-0006DJ-Hh; Mon, 04 Nov 2013 16:32:09 -0700 From: "Richard Shockey" To: "'Ralph Giles'" , References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> <5277E85C.4060905@thaumas.net> In-Reply-To: <5277E85C.4060905@thaumas.net> Date: Mon, 4 Nov 2013 18:32:08 -0500 Message-ID: <014601ced9b6$15233ff0$3f69bfd0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH6pu1RcnTqG2CSG3ZFwm2jX+BNyQJbu+6tATDasOsBrtz7FAInK4ITAmPE1jICxzHZDwIXVPOnAUGXIhEBtjfzeAIZqFxrAfSgzYiZEMXMcA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 23:32:47 -0000 That has been confirmed by independent Wireshark analysis. http://www.packetstan.com/2010/07/special-look-face-time-part-1.html Its also SIP with some Apple "enhancements" -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ralph Giles Sent: Monday, November 04, 2013 1:33 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Platforms that support H264 On 2013-11-04 5:51 AM, David Singer wrote: > reverse engineering suggests that FaceTime uses AVC (H.264). Reverse engineering isn't necessary to establish this, although it's nice to have ongoing confirmation of the details. :-) http://cdn1.appleinsider.com/facetime.002.jpg -r _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From trac+rtcweb@trac.tools.ietf.org Mon Nov 4 15:33:38 2013 Return-Path: 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 D399A21E811F for ; Mon, 4 Nov 2013 15:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ucWdBlHN3RLv for ; Mon, 4 Nov 2013 15:33:38 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5B12911E82CA for ; Mon, 4 Nov 2013 15:33:24 -0800 (PST) Received: from localhost ([127.0.0.1]:57551 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdTdy-0003a6-UT; Tue, 05 Nov 2013 00:33:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Mon, 04 Nov 2013 23:33:14 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/rtcweb/trac/ticket/24#comment:1 Message-ID: <081.4f72c51d25ef2cbb72290851e4dfc0a9@trac.tools.ietf.org> References: <066.d4b18b2abc7a8310f3af088ef9377a47@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <066.d4b18b2abc7a8310f3af088ef9377a47@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: csp@csperkins.org, jorg.ott@aalto.fi, magnus.westerlund@ericsson.com Resent-Message-Id: <20131104233326.5B12911E82CA@ietfa.amsl.com> Resent-Date: Mon, 4 Nov 2013 15:33:24 -0800 (PST) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #24: Section 17.1 Normative reference to draft-westerlund-avtcore-transport-multiplexing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 23:33:39 -0000 #24: Section 17.1 Normative reference to draft-westerlund-avtcore-transport- multiplexing Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-rtp- bernard_aboba@hotmail.com | usage@tools.ietf.org Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: rtp-usage | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: rtcweb From trac+rtcweb@trac.tools.ietf.org Mon Nov 4 15:34:16 2013 Return-Path: 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 11E9A21E80EC for ; Mon, 4 Nov 2013 15:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 0iYthq2z4isg for ; Mon, 4 Nov 2013 15:34:15 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BA00321E811F for ; Mon, 4 Nov 2013 15:34:12 -0800 (PST) Received: from localhost ([127.0.0.1]:57718 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdTet-0003Cg-OX; Tue, 05 Nov 2013 00:34:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Mon, 04 Nov 2013 23:34:11 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/rtcweb/trac/ticket/30#comment:2 Message-ID: <081.e8094164cd0639535b96189b7e29da0c@trac.tools.ietf.org> References: <066.e4120f60682a48aa7753e29f3071d4d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <066.e4120f60682a48aa7753e29f3071d4d8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: christer.holmberg@ericsson.com, goran.ap.eriksson@ericsson.com, stefan.lk.hakansson@ericsson.com Resent-Message-Id: <20131104233412.BA00321E811F@ietfa.amsl.com> Resent-Date: Mon, 4 Nov 2013 15:34:12 -0800 (PST) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #30: Wiretapping X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 23:34:16 -0000 #30: Wiretapping Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-use- bernard_aboba@hotmail.com | cases-and- Type: defect | requirements@tools.ietf.org Priority: critical | Status: closed Component: use-cases-and- | Milestone: milestone1 requirements | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: rtcweb From ekr@rtfm.com Mon Nov 4 15:36:01 2013 Return-Path: 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 E74A021E827A for ; Mon, 4 Nov 2013 15:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Ju6npGzWSX2t for ; Mon, 4 Nov 2013 15:35:57 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id B09FB11E82CA for ; Mon, 4 Nov 2013 15:35:53 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id b13so2800350wgh.27 for ; Mon, 04 Nov 2013 15:35:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JIa9ltEetbIvyjqIq/bc3F1l3SOJCD7hAF3ZFJQRriQ=; b=Pe83KXNk6m0/p0S/46i/6rqvRhKv2C6JRpE84LFV3/79MuBsKQdD+pwc1oxTnGawcP kNAlx1GtOw6DU+IgCcKAkJKguSzJb7nLwLaN7T1/kvK2uaPnzk+tE5DKM4TkFRzALxcY /80nEMBK3K+1lAZ/rC2IhrV8GXo75Ir1F1HTeNKYmAUeVu819SyOaqtGPVqyMbX7YZ4n OWSSs6x1PyJrA/fHULibTdDZtzuIAezSu6kNiKeoOs/JbH6KtqlHNzySIm2XKAQCsne6 ggGGBpKz51qDuGUy+X85fCkDSYW2nwm9LlGapcvSJAqxlQvIQCFOWQe6m4zFIuiSZ2c5 M9Eg== X-Gm-Message-State: ALoCoQlQyyvq/PCwBb4Uv1Q21qK8tPdenfEuX58q21nw1mt+d0MYCTRGNYBaEQKvG5AmObvoX3LR X-Received: by 10.194.240.41 with SMTP id vx9mr71168wjc.70.1383608152871; Mon, 04 Nov 2013 15:35:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Mon, 4 Nov 2013 15:35:12 -0800 (PST) X-Originating-IP: [2001:67c:370:176:2dc1:e065:5ec8:3a6c] In-Reply-To: References: From: Eric Rescorla Date: Mon, 4 Nov 2013 15:35:12 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a11c28dcc75e9eb04ea626032 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Reflection of SRTP/SDES discussions at IETF 87? X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 23:36:02 -0000 --001a11c28dcc75e9eb04ea626032 Content-Type: text/plain; charset=ISO-8859-1 I haven't updated the documents at all. Yes, I am a bad person. -Ekr On Mon, Nov 4, 2013 at 3:14 PM, Bernard Aboba wrote: > At IETF 87 we had a discussion of SRTP/SDES. In looking at the most > recent version of several documents, I didn't see the consensus of that > discussion reflected. Was that because the consensus in the room wasn't > verified on the list, or some other reason? Or maybe I missed the text > somewhere? Here is what seemingly relates to this topic: > > http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07 Section > 5.5: > > [OPEN ISSUE: What should the settings be here? MUST?] > Implementations MAY support SDES for media traffic for backward > compatibility purposes. > > [BA] As I recall, the room consensus was MUST NOT with respect to > SRTP/SDES, no? > > http://tools.ietf.org/html/draft-ietf-rtcweb-security > > [BA] Nothing related to key management (which seems fine). > > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage > > [BA] The security and security-architecture documents are referenced > normatively in Section 13 Security Considerations (which seems fine). > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c28dcc75e9eb04ea626032 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I haven't updated the documents at all.

=
Yes, I am a bad person.

-Ekr



On = Mon, Nov 4, 2013 at 3:14 PM, Bernard Aboba <bernard_aboba@hotmail.= com> wrote:
At IETF 87 we had a discussion of SRTP/SDES.=A0 In lo= oking at the most recent version of several documents, I didn't see the= consensus of that discussion reflected.=A0 Was that because the consensus = in the room wasn't verified on the list, or some other reason?=A0 Or ma= ybe I missed the text somewhere?=A0 Here is what seemingly relates to this = topic:
=A0
http://tools.ietf.org/html/draft-ietf-rtcweb-securi= ty-arch-07=A0Section 5.5:
=A0
=A0=A0 [OPEN ISSUE:=A0 What should= the settings be here?=A0 MUST?]
=A0=A0 Implementations MAY support SDES for media traffic for backward
= =A0=A0 compatibility purposes.
=A0
[BA] As I recall, the room consens= us was MUST=A0NOT with respect to SRTP/SDES, no?
=A0
http:/= /tools.ietf.org/html/draft-ietf-rtcweb-security
=A0
[BA] Nothing related to key management (which seems fine).
=A0http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage
= =A0
[BA]=A0 The security and security-architecture documents are referenced nor= matively in Section 13 Security Considerations (which seems fine).
=

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--001a11c28dcc75e9eb04ea626032-- From trac+rtcweb@trac.tools.ietf.org Mon Nov 4 15:38:10 2013 Return-Path: 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 A43CA21E8180 for ; Mon, 4 Nov 2013 15:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Dx1w+w5Dax8M for ; Mon, 4 Nov 2013 15:38:09 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B99EE21E8138 for ; Mon, 4 Nov 2013 15:38:09 -0800 (PST) Received: from localhost ([127.0.0.1]:58213 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdTig-0004Ag-IZ; Tue, 05 Nov 2013 00:38:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Mon, 04 Nov 2013 23:38:06 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/rtcweb/trac/ticket/23#comment:2 Message-ID: <081.57895a6b03345471a2f1c4670beb7362@trac.tools.ietf.org> References: <066.e25c55f4beabdbb9b445f98350fa83ad@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <066.e25c55f4beabdbb9b445f98350fa83ad@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: csp@csperkins.org, jorg.ott@aalto.fi, magnus.westerlund@ericsson.com Resent-Message-Id: <20131104233809.B99EE21E8138@ietfa.amsl.com> Resent-Date: Mon, 4 Nov 2013 15:38:09 -0800 (PST) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #23: Section 4.4 SDP signaling requirement X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 23:38:10 -0000 #23: Section 4.4 SDP signaling requirement Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-rtp- bernard_aboba@hotmail.com | usage@tools.ietf.org Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: rtp-usage | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: rtcweb From cowwoc@bbs.darktech.org Mon Nov 4 15:40:48 2013 Return-Path: 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 C06BA21E82E3 for ; Mon, 4 Nov 2013 15:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.693 X-Spam-Level: X-Spam-Status: No, score=-4.693 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 zRWO12oJxCJV for ; Mon, 4 Nov 2013 15:40:41 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3333811E8243 for ; Mon, 4 Nov 2013 15:40:41 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id ar20so13329892iec.26 for ; Mon, 04 Nov 2013 15:40:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ugq+Bntn9y1dV23n3OmFvbf/FCs2DMauEYDWebSfZPI=; b=XmoEsRv0GHUpKtlQ3JyuBAKSvZnG+5K/0BCkorWhBl07Lup54QbuvFdDSOBynZGowC IWkoVtZjz/fx0Fa3+GW1qzirO9t80KpJ7cGgnbbmJw7eVg2zHe7LSfDzRFsE12jdy2zy AJ8eTXFGoo8A6Fp3RYDos9+U8O5QZoGNK0si05UCNdyCti3VsjQm3+hx9q30FUHlMPd5 R0E1/+Ndh26k8UhK+FlnzBRXozgEj/UG9YXrYmklt+PTqVYZCgAkP3J5DPQVrhFcifKN dIYhoIs6bWXd/Jo5Q4eqh+m+h4ao3g+adZ6vwg+gsp9t8M5J8+OghPcaN2MDIrO3Dql5 vYXg== X-Gm-Message-State: ALoCoQn2pHykcDx8br+Fi1401x8tkm6uQBWsoi46bWCuBlpBeTANLKieBWw0ApH28V9aibb3aiB+ X-Received: by 10.50.126.74 with SMTP id mw10mr14119406igb.24.1383608440653; Mon, 04 Nov 2013 15:40:40 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id m1sm5095114igj.10.2013.11.04.15.40.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 15:40:39 -0800 (PST) Message-ID: <52783076.8040909@bbs.darktech.org> Date: Mon, 04 Nov 2013 18:40:38 -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: rtcweb@ietf.org References: <066.e25c55f4beabdbb9b445f98350fa83ad@trac.tools.ietf.org> <081.57895a6b03345471a2f1c4670beb7362@trac.tools.ietf.org> In-Reply-To: <081.57895a6b03345471a2f1c4670beb7362@trac.tools.ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] #23: Section 4.4 SDP signaling requirement X-BeenThere: rtcweb@ietf.org 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: Mon, 04 Nov 2013 23:40:48 -0000 On 04/11/2013 6:38 PM, rtcweb issue tracker wrote: > #23: Section 4.4 SDP signaling requirement > > Changes (by bernard_aboba@hotmail.com): > > * status: new => closed > * resolution: => fixed > > Here we go again. I'd love to know how the WG plans to remove SDP as an implementation detail from version 2.0 if version 1.0 explicitly mentions the use of SDP (instead of an opaque token). Gili From trac+rtcweb@trac.tools.ietf.org Mon Nov 4 15:42:43 2013 Return-Path: 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 15B7421E82DD for ; Mon, 4 Nov 2013 15:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5kDeTjX16K20 for ; Mon, 4 Nov 2013 15:42:42 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6D65821E82E1 for ; Mon, 4 Nov 2013 15:42:37 -0800 (PST) Received: from localhost ([127.0.0.1]:58396 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdTmm-0000NJ-7s; Tue, 05 Nov 2013 00:42:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Mon, 04 Nov 2013 23:42:15 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/rtcweb/trac/ticket/22#comment:2 Message-ID: <081.816d0f3c81a1c002ab9ffd4b0fc6a398@trac.tools.ietf.org> References: <066.06808f782ff829d089ef906c558013c8@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <066.06808f782ff829d089ef906c558013c8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: csp@csperkins.org, jorg.ott@aalto.fi, magnus.westerlund@ericsson.com Resent-Message-Id: <20131104234237.6D65821E82E1@ietfa.amsl.com> Resent-Date: Mon, 4 Nov 2013 15:42:37 -0800 (PST) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #22: Section 4.3: Negotiation requirement X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 23:42:43 -0000 #22: Section 4.3: Negotiation requirement Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-rtp- bernard_aboba@hotmail.com | usage@tools.ietf.org Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: rtp-usage | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: rtcweb From trac+rtcweb@trac.tools.ietf.org Mon Nov 4 15:54:42 2013 Return-Path: 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 95AAF11E8253 for ; Mon, 4 Nov 2013 15:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 OVEDt+Ohkr+7 for ; Mon, 4 Nov 2013 15:54:42 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 962E211E8250 for ; Mon, 4 Nov 2013 15:54:40 -0800 (PST) Received: from localhost ([127.0.0.1]:60143 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdTyg-0006Hf-6e; Tue, 05 Nov 2013 00:54:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: csp@csperkins.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Mon, 04 Nov 2013 23:54:38 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/2#comment:1 Message-ID: <081.dbea2460e04a050a34c1888f30e24972@trac.tools.ietf.org> References: <066.81f7a0339f5b268a5112f46329622778@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <066.81f7a0339f5b268a5112f46329622778@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: csp@csperkins.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #2: Section 7.1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 23:54:42 -0000 #2: Section 7.1 Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- ---------------------------------------+-------------------------------- Reporter: bernard_aboba@hotmail.com | Owner: csp@csperkins.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: rtp-usage | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+-------------------------------- Ticket URL: rtcweb From trac+rtcweb@trac.tools.ietf.org Mon Nov 4 16:00:34 2013 Return-Path: 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 C882111E82DF for ; Mon, 4 Nov 2013 16:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 jd0gK88nDkK6 for ; Mon, 4 Nov 2013 16:00:34 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4674711E82DD for ; Mon, 4 Nov 2013 16:00:25 -0800 (PST) Received: from localhost ([127.0.0.1]:60818 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdU46-0004I2-El; Tue, 05 Nov 2013 01:00:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Tue, 05 Nov 2013 00:00:14 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/rtcweb/trac/ticket/19#comment:1 Message-ID: <081.ff310e4fc42002940f1d02b5d27e280e@trac.tools.ietf.org> References: <066.cafc635ba698c26a8adc82620078c6ab@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <066.cafc635ba698c26a8adc82620078c6ab@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: csp@csperkins.org, jorg.ott@aalto.fi, magnus.westerlund@ericsson.com Resent-Message-Id: <20131105000026.4674711E82DD@ietfa.amsl.com> Resent-Date: Mon, 4 Nov 2013 16:00:25 -0800 (PST) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #19: Section 7.2: Congestion Control Extensions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 05 Nov 2013 00:00:35 -0000 #19: Section 7.2: Congestion Control Extensions Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-rtp- bernard_aboba@hotmail.com | usage@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: rtp-usage | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: rtcweb From martin.thomson@gmail.com Mon Nov 4 16:11:09 2013 Return-Path: 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 D4D1D21E81A2 for ; Mon, 4 Nov 2013 16:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_18=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 rZggR4Xq3Y5L for ; Mon, 4 Nov 2013 16:11:08 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7EA21E8341 for ; Mon, 4 Nov 2013 16:10:40 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w62so2770191wes.7 for ; Mon, 04 Nov 2013 16:10:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lUcmLQTH8wgTtF7ABF8gaPrzMukxqWDYZew/tBLFmqg=; b=mWKumE8RlCaZDKygi285VlDk+qFN0vLitD0CUEphQb8oiiUdh0EgJ0ayL1KsdyW5ad ob2JDzDFa8Mr/eScQCBmn7ZyGOgMRMirG1HQaU+ls6KI6SjwRCUZkdRADVTAiypvX7/w TIzGEkl3LPB0HUVxXAwcz4sFkruty2JHlQ8T/OuaeKRoIDeqNOK6bOWYx6irXphRo9UF SbKNX56PT28Y2oHwnhI1Y+spvmpC7Wi+bMWYrHcqAuTtx8Sz4o2kdV6GjboRGdcYcB+g 6Kp4jAtsDgC5HE0grc8/kLb4gL1AtlNyF3N6vnKPra+oTkeLBhfrzSrb/JZAU00GKSkG ZrTg== MIME-Version: 1.0 X-Received: by 10.194.2.108 with SMTP id 12mr323315wjt.64.1383610239601; Mon, 04 Nov 2013 16:10:39 -0800 (PST) Received: by 10.227.202.194 with HTTP; Mon, 4 Nov 2013 16:10:39 -0800 (PST) Date: Mon, 4 Nov 2013 16:10:39 -0800 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] a=sendrecv X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 00:11:09 -0000 I thought that the current assumption was that if you add a stream, then the offer that you generate was marked a=sendrecv, unless you have an explicit OfferToReceiveVideo set to false/0. Or is it the case that an offer for a new m= section on an existing session is different to an initial offer? I'd prefer to keep this consistent. Oh, and what was that BUNDLE question Justin? From trac+rtcweb@trac.tools.ietf.org Mon Nov 4 16:12:51 2013 Return-Path: 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 B5BCE21E833F for ; Mon, 4 Nov 2013 16:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Ql7EKPtU+uBd for ; Mon, 4 Nov 2013 16:12:51 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 34BFC11E82D8 for ; Mon, 4 Nov 2013 16:11:22 -0800 (PST) Received: from localhost ([127.0.0.1]:33591 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdUEp-0005By-JI; Tue, 05 Nov 2013 01:11:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Tue, 05 Nov 2013 00:11:19 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/25#comment:1 Message-ID: <081.644bb4f0d3d1d1a569d13c8d1a66b9fa@trac.tools.ietf.org> References: <066.c4782f9f452cb0c5049d3712dcfdcda1@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <066.c4782f9f452cb0c5049d3712dcfdcda1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: csp@csperkins.org, jorg.ott@aalto.fi, magnus.westerlund@ericsson.com Resent-Message-Id: <20131105001122.34BFC11E82D8@ietfa.amsl.com> Resent-Date: Mon, 4 Nov 2013 16:11:22 -0800 (PST) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #25: Section 5.1 Conferencing Extensions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 05 Nov 2013 00:12:51 -0000 #25: Section 5.1 Conferencing Extensions Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-rtp- bernard_aboba@hotmail.com | usage@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: rtp-usage | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: rtcweb From trac+rtcweb@trac.tools.ietf.org Mon Nov 4 16:19:26 2013 Return-Path: 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 932DD21E80A5 for ; Mon, 4 Nov 2013 16:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 na6PTRcC9wPO for ; Mon, 4 Nov 2013 16:19:25 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 99F7521E8304 for ; Mon, 4 Nov 2013 16:19:24 -0800 (PST) Received: from localhost ([127.0.0.1]:34415 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdUMb-0001HI-Uo; Tue, 05 Nov 2013 01:19:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Tue, 05 Nov 2013 00:19:21 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/rtcweb/trac/ticket/33 Message-ID: <066.8331de585e9ba3cb788de1503915ecd5@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-security-arch@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com Resent-Message-Id: <20131105001924.99F7521E8304@ietfa.amsl.com> Resent-Date: Mon, 4 Nov 2013 16:19:24 -0800 (PST) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: [rtcweb] #33: Section 5.5: SRTP/SDES guidance X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 05 Nov 2013 00:19:26 -0000 #33: Section 5.5: SRTP/SDES guidance [OPEN ISSUE: What should the settings be here? MUST?] Implementations MAY support SDES for media traffic for backward compatibility purposes. [BA] As I recall, the room consensus at IETF 87 was MUST NOT with respect to SRTP/SDES, no? Is that missing because the consensus in the room wasn't verified on the list, or some other reason? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb- bernard_aboba@hotmail.com | security-arch@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: security-arch | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: rtcweb From bernard_aboba@hotmail.com Mon Nov 4 16:24:51 2013 Return-Path: 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 E0A8321E823D for ; Mon, 4 Nov 2013 16:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 3jLrixvmn7jI for ; Mon, 4 Nov 2013 16:24:47 -0800 (PST) Received: from blu0-omc1-s20.blu0.hotmail.com (blu0-omc1-s20.blu0.hotmail.com [65.55.116.31]) by ietfa.amsl.com (Postfix) with ESMTP id 279A821E811A for ; Mon, 4 Nov 2013 16:24:46 -0800 (PST) Received: from BLU169-W54 ([65.55.116.7]) by blu0-omc1-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Nov 2013 16:24:46 -0800 X-TMN: [7VlheAGRpa8A3/2opRXlcO517j/UbgVM] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_50871cad-b513-46a5-b6e2-c253191cd270_" From: Bernard Aboba To: cowwoc , "rtcweb@ietf.org" Date: Mon, 4 Nov 2013 16:24:45 -0800 Importance: Normal In-Reply-To: <52783076.8040909@bbs.darktech.org> References: <066.e25c55f4beabdbb9b445f98350fa83ad@trac.tools.ietf.org>, <081.57895a6b03345471a2f1c4670beb7362@trac.tools.ietf.org>, <52783076.8040909@bbs.darktech.org> MIME-Version: 1.0 X-OriginalArrivalTime: 05 Nov 2013 00:24:46.0854 (UTC) FILETIME=[6EA2EA60:01CED9BD] Subject: Re: [rtcweb] #23: Section 4.4 SDP signaling requirement X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 00:24:52 -0000 --_50871cad-b513-46a5-b6e2-c253191cd270_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I resolved this issue as fixed because RTP Usage document -10 Section 4.4 = no longer mandates SDP signaling on the wire.=20 =20 Feel free to file an issue if you find a remnant of this problem elsewhere = in the document.=20 =20 =20 > Date: Mon=2C 4 Nov 2013 18:40:38 -0500 > From: cowwoc@bbs.darktech.org > To: rtcweb@ietf.org > Subject: Re: [rtcweb] #23: Section 4.4 SDP signaling requirement >=20 > On 04/11/2013 6:38 PM=2C rtcweb issue tracker wrote: > > #23: Section 4.4 SDP signaling requirement > > > > Changes (by bernard_aboba@hotmail.com): > > > > * status: new =3D> closed > > * resolution: =3D> fixed > > > > >=20 > Here we go again. I'd love to know how the WG plans to=20 > remove SDP as an implementation detail from version 2.0 if version 1.0=20 > explicitly mentions the use of SDP (instead of an opaque token). >=20 > Gili > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_50871cad-b513-46a5-b6e2-c253191cd270_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I =3Bresolved this issue as = fixed =3Bbecause RTP Usage document -10 =3B Section 4.4 no longer m= andates SDP signaling on the wire.
 =3B
Feel free to file = =3Ban issue if =3Byou find a remnant of this problem elsewhere in the d= ocument.
 =3B

 =3B
>=3B Date: Mon=2C 4 Nov 201= 3 18:40:38 -0500
>=3B From: cowwoc@bbs.darktech.org
>=3B To: rtcw= eb@ietf.org
>=3B Subject: Re: [rtcweb] #23: Section 4.4 SDP signaling = requirement
>=3B
>=3B On 04/11/2013 6:38 PM=2C rtcweb issue trac= ker wrote:
>=3B >=3B #23: Section 4.4 SDP signaling requirement
&= gt=3B >=3B
>=3B >=3B Changes (by bernard_aboba@hotmail.com):
&g= t=3B >=3B
>=3B >=3B * status: new =3D>=3B closed
>=3B &g= t=3B * resolution: =3D>=3B fixed
>=3B >=3B
>=3B >=3B>=3B
>=3B <=3Bsigh>=3B Here we go again. I'd love to know= how the WG plans to
>=3B remove SDP as an implementation detail from= version 2.0 if version 1.0
>=3B explicitly mentions the use of SDP (= instead of an opaque token).
>=3B
>=3B Gili
>=3B __________= _____________________________________
>=3B rtcweb mailing list
>= =3B rtcweb@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/rtcweb<= br>
= --_50871cad-b513-46a5-b6e2-c253191cd270_-- From bernard_aboba@hotmail.com Mon Nov 4 16:39:00 2013 Return-Path: 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 3540C21E839A for ; Mon, 4 Nov 2013 16:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.311 X-Spam-Level: X-Spam-Status: No, score=-102.311 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 xHxRZez4Cctj for ; Mon, 4 Nov 2013 16:38:54 -0800 (PST) Received: from blu0-omc2-s12.blu0.hotmail.com (blu0-omc2-s12.blu0.hotmail.com [65.55.111.87]) by ietfa.amsl.com (Postfix) with ESMTP id F2BDA21E82EF for ; Mon, 4 Nov 2013 16:38:50 -0800 (PST) Received: from BLU169-W72 ([65.55.111.72]) by blu0-omc2-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Nov 2013 16:38:50 -0800 X-TMN: [Jjq4JWeREAC38bK2y7k0kov0JF4JQS7y] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_608cd471-ca73-4836-8faa-0b2780a4899d_" From: Bernard Aboba To: Eric Rescorla Date: Mon, 4 Nov 2013 16:38:49 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 05 Nov 2013 00:38:50.0338 (UTC) FILETIME=[65645C20:01CED9BF] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Reflection of SRTP/SDES discussions at IETF 87? X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 00:39:00 -0000 --_608cd471-ca73-4836-8faa-0b2780a4899d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ekr said:=20 "Yes=2C I am a bad person." [BA] I'll open a TRAC issue. You can point to = it if the Wednesday morning "Internet hardening" plenary crowd gets unruly = :) = --_608cd471-ca73-4836-8faa-0b2780a4899d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ekr said:

"Yes=2C I am a bad person."
 =3B
[BA]= I'll open a TRAC issue. =3B You can point to it if the Wednesday morni= ng "Internet hardening" plenary crowd gets unruly :)
=
= --_608cd471-ca73-4836-8faa-0b2780a4899d_-- From tony@att.com Mon Nov 4 16:57:42 2013 Return-Path: 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 4605011E82C7 for ; Mon, 4 Nov 2013 16:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.691 X-Spam-Level: X-Spam-Status: No, score=-103.691 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 2ck2FaJv-Viy for ; Mon, 4 Nov 2013 16:57:36 -0800 (PST) Received: from flpi406.enaf.ffdc.sbc.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id 6636E11E82CF for ; Mon, 4 Nov 2013 16:57:33 -0800 (PST) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com (8.14.4/8.14.4) with ESMTP id rA50vWwO032211 for ; Mon, 4 Nov 2013 16:57:32 -0800 Received: from vpn-135-70-97-231.vpn.swst.att.com ([135.70.97.231]) by maillennium.att.com (mailgw1) with ESMTP id <20131105005731gw100q0gg3e>; Tue, 5 Nov 2013 00:57:31 +0000 X-Originating-IP: [135.70.97.231] Message-ID: <5278427A.8020003@att.com> Date: Mon, 04 Nov 2013 19:57:30 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: , In-Reply-To: Content-Type: multipart/alternative; boundary="------------020001010602060700010005" Subject: Re: [rtcweb] Reflection of SRTP/SDES discussions at IETF 87? X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 00:57:42 -0000 This is a multi-part message in MIME format. --------------020001010602060700010005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/4/13, 7:38 PM, Bernard Aboba wrote: > Ekr said: > > "Yes, I am a bad person." > [BA] I'll open a TRAC issue. You can point to it if the Wednesday > morning "Internet hardening" plenary crowd gets unruly :) EKR, do you have your Evil Bit set properly? Tony Hansen --------------020001010602060700010005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/4/13, 7:38 PM, Bernard Aboba wrote:
Ekr said:

"Yes, I am a bad person."
 
[BA] I'll open a TRAC issue.  You can point to it if the Wednesday morning "Internet hardening" plenary crowd gets unruly :)

EKR, do you have your Evil Bit set properly?

    Tony Hansen
--------------020001010602060700010005-- From stpeter@stpeter.im Mon Nov 4 17:01:53 2013 Return-Path: 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 606C011E82FF for ; Mon, 4 Nov 2013 17:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 TYDnWxfUgxD9 for ; Mon, 4 Nov 2013 17:01:48 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 753D711E8263 for ; Mon, 4 Nov 2013 17:01:48 -0800 (PST) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A994C4032B; Mon, 4 Nov 2013 18:01:47 -0700 (MST) Message-ID: <5278437A.7020108@stpeter.im> Date: Mon, 04 Nov 2013 17:01:46 -0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tony Hansen , "rtcweb@ietf.org" References: , <5278427A.8020003@att.com> In-Reply-To: <5278427A.8020003@att.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Reflection of SRTP/SDES discussions at IETF 87? X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 01:01:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/4/13 4:57 PM, Tony Hansen wrote: > On 11/4/13, 7:38 PM, Bernard Aboba wrote: >> Ekr said: >> >> "Yes, I am a bad person." >> >> [BA] I'll open a TRAC issue. You can point to it if the >> Wednesday morning "Internet hardening" plenary crowd gets unruly >> :) > > EKR, do you have your Evil Bit set properly? He only said that he's bad. It remains to be determined whether he is also evil. ;-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSeEN6AAoJEOoGpJErxa2pcc8P/3RxG6u0UcF6BznFD2riwLq1 MwEntf/hwCqeBzcktIPP+HSAZvyT7QnRGqZzMHyFO7mMa6kFftvZ9Ijn53gq/ckW HBzVTQy6U31o8Eki1OuCe3eTFS8yrBYpUTAwZTgJHMI25Hb9sxs/Iki8RlDWFDNO FFXw45czYRk78MUb7AQk00yCZnXE9LCwfhBDMb1clP4bRYwapqpj2JnzAAmKh1DV 0N/Kit0gzB9BaQbZUVPzTi7D++pimPNmrn2jrjItt9LahTn/FyCyyt3TUghIW6Zk wgVYZDMEtY1e0bX2Lh15xhR+rPJclwwEqJOZXNlBnr3yX1Xcdhzcx4XtiiSf9AgZ 2YXbvlHFlsEwSSyS1tsoCGSO09q0qeCW5CkJtg8KvkvR+dndOQ6GrtLcHLF2m/p+ 5XhoLOBKVsLbNRBaEfMr4NCHp893z5IxiXHHa2Z88uGGlH8K5W2nePrfqUbBcwna ryanAIyTDSDRrW2ANzHS+F3Lk/YMkapIB3GjjS8XlU7t/1cEruqGqkbj7w2BEkdt 51AEnenY7riaHoa/W4xngfyAINIMYaiBzjArmChEX6bsQJwnhdPzcUGZEpZR4wgR 6UEZq6QGTgRc6mzxTCNCuRkuqwX7YENjTGFg5UYFnDhs5Ql8Gc7LIHyTRHZHPvnC BOmM4FqhtavYcK0oOuMH =Saed -----END PGP SIGNATURE----- From cowwoc@bbs.darktech.org Mon Nov 4 17:31:09 2013 Return-Path: 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 0C5F221E80DA for ; Mon, 4 Nov 2013 17:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.659 X-Spam-Level: X-Spam-Status: No, score=-4.659 tagged_above=-999 required=5 tests=[AWL=-1.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 7A3MioWERnai for ; Mon, 4 Nov 2013 17:31:03 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFA111E814B for ; Mon, 4 Nov 2013 17:31:03 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id at1so14055546iec.1 for ; Mon, 04 Nov 2013 17:31:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=O6SwptDyhOVfumN+3ny6C1mTIraFGGDSvqJg4nVWItc=; b=BgVA+xHuhLo7yoZR+37+VcOhhlLdv0eJnFUPtPMzybqoeiURs5hYhuJZt7TgDd4P9z n6266j/4G2Exj0tmfzthK8nXe1ujc9gd/sq4b6xUob058i7tEgnpBmfij8/QDXQ6YVEA P6/4g+7pDk7dLt6ZDteAsAJYl9Xca9bQGLsWIxk4/sAI489LKHGX0A5iN9iwdLo3LzHb tPXcMBVneSRkYs911GobG+nj4x0ajJ2B0alWfBJbwZ/I/DjHd9kiEM2qbS2kpCBoqCw8 gn7RTXSK2Zf+E29VWSW2yYPYV7dvdsRPUAT8gaBLf53TykcYxRIc1vlTg0VEBf94NUwo sRjg== X-Gm-Message-State: ALoCoQlpKzy57DkGHKVWsN/GjxeCBnm4MSw/XULto0/z+/m3o6yCx6BhYE3MEQR9j/B8oTCaEliK X-Received: by 10.50.61.179 with SMTP id q19mr14094711igr.33.1383615062730; Mon, 04 Nov 2013 17:31:02 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f19sm5698617igz.1.2013.11.04.17.31.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 17:31:02 -0800 (PST) Message-ID: <52784A54.1050003@bbs.darktech.org> Date: Mon, 04 Nov 2013 20:31:00 -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: Bernard Aboba , "rtcweb@ietf.org" References: <066.e25c55f4beabdbb9b445f98350fa83ad@trac.tools.ietf.org>, <081.57895a6b03345471a2f1c4670beb7362@trac.tools.ietf.org>, <52783076.8040909@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010804060701040800020006" Subject: Re: [rtcweb] #23: Section 4.4 SDP signaling requirement X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 01:31:09 -0000 This is a multi-part message in MIME format. --------------010804060701040800020006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Good to hear. Thanks for the clarification. Gili On 04/11/2013 7:24 PM, Bernard Aboba wrote: > I resolved this issue as fixed because RTP Usage document -10 Section > 4.4 no longer mandates SDP signaling on the wire. > > Feel free to file an issue if you find a remnant of this problem > elsewhere in the document. > > > > > Date: Mon, 4 Nov 2013 18:40:38 -0500 > > From: cowwoc@bbs.darktech.org > > To: rtcweb@ietf.org > > Subject: Re: [rtcweb] #23: Section 4.4 SDP signaling requirement > > > > On 04/11/2013 6:38 PM, rtcweb issue tracker wrote: > > > #23: Section 4.4 SDP signaling requirement > > > > > > Changes (by bernard_aboba@hotmail.com): > > > > > > * status: new => closed > > > * resolution: => fixed > > > > > > > > > > Here we go again. I'd love to know how the WG plans to > > remove SDP as an implementation detail from version 2.0 if version 1.0 > > explicitly mentions the use of SDP (instead of an opaque token). > > > > Gili > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb --------------010804060701040800020006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    Good to hear. Thanks for the clarification.

Gili

On 04/11/2013 7:24 PM, Bernard Aboba wrote:
I resolved this issue as fixed because RTP Usage document -10  Section 4.4 no longer mandates SDP signaling on the wire.
 
Feel free to file an issue if you find a remnant of this problem elsewhere in the document.
 

 
> Date: Mon, 4 Nov 2013 18:40:38 -0500
> From: cowwoc@bbs.darktech.org
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] #23: Section 4.4 SDP signaling requirement
>
> On 04/11/2013 6:38 PM, rtcweb issue tracker wrote:
> > #23: Section 4.4 SDP signaling requirement
> >
> > Changes (by bernard_aboba@hotmail.com):
> >
> > * status: new => closed
> > * resolution: => fixed
> >
> >
>
> <sigh> Here we go again. I'd love to know how the WG plans to
> remove SDP as an implementation detail from version 2.0 if version 1.0
> explicitly mentions the use of SDP (instead of an opaque token).
>
> Gili
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

--------------010804060701040800020006-- From singer@apple.com Mon Nov 4 18:26:02 2013 Return-Path: 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 7611221E839C for ; Mon, 4 Nov 2013 18:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 9jzetC0czg6H for ; Mon, 4 Nov 2013 18:25:57 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9F721E8118 for ; Mon, 4 Nov 2013 18:25:55 -0800 (PST) Received: from relay3.asia.apple.com ( [17.82.200.17]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 18.0E.03695.13758725; Tue, 5 Nov 2013 10:25:53 +0800 (MYT) X-AuditID: 1152fe06-b7f5a6d000000e6f-08-5278573152bd Received: from galingale.asia.apple.com ( [17.82.200.117]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id EC.D2.26194.13758725; Tue, 5 Nov 2013 10:25:53 +0800 (MYT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.83.34.55] (unknown [17.83.34.55]) by mail.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVR0044KQR39E20@mail.asia.apple.com> for rtcweb@ietf.org; Tue, 05 Nov 2013 10:25:53 +0800 (SGT) From: David Singer In-reply-to: <5277CCC7.7000003@bbs.darktech.org> Date: Tue, 05 Nov 2013 11:25:54 +0900 Message-id: <38496E6A-057F-4507-9FDA-B61A4BCFD797@apple.com> References: <20131102124801.GY3245@audi.shelbyville.oz> <5277CAC2.8000001@jesup.org> <5277CCC7.7000003@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUiGHRCUNcwvCLI4P5xa4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcXTZD/aCxRwVb9+uZGtgvMvWxcjJISFgInHn7GYmCFtM4sK9 9UBxLg4hgd2MEmfvvWPsYuQAKzp7XQmkRkhgApPExr40EJtXQFDix+R7LCAlzALyEgfPy4KE mQW0JL4/amWBGDOfSeLJtI1gu4QFoiV+7XzGDmKzCahKPJhzjBHE5hQwkNjzciULiM0CFL+z 9RQLxCBhie+P77FA7LKROLl4DRPE0C4miWeTf4INFRFQkbhx7BY7xAOyEqfPPQfbLCHwlVVi 4rJ1jBMYhWchOXYWwrGzkBy7gJF5FaN4bmJmjm5mnpFeYnFmol5iQUFOql5yfu4mRnA4/2Pb wbjgteEhRgEORiUe3tlvi4KEWBPLiitzDzFKcDArifDu9q8IEuJNSaysSi3Kjy8qzUktPsQo zcGiJM77+295kJBAemJJanZqakFqEUyWiYNTqoFxhc3fPfncBtHzf920Yj0/n3l2sKJTZaa7 5Opl3TW5WadixVdv3n6vtHJZ6855KiUpQfYvA+eEc58oFxDy+Tm7O5ppQeAdDg43vQVR2XPP nmxoXbf0r4qz43yvKU/5JFmCN6wLaFwbqBf3vyso33l5sevqABnu+XWMRzJv5QkxRvW672tO 9lBiKc5INNRiLipOBAAz8+OrYwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUiGHSiVNcwvCLIoL3X0mLtv3Z2B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlHF32g71gMUfF27cr2RoY77J1MXJwSAiYSJy9rtTFyAlkiklc uLeeDcQWEpjAJLGxLw3E5hUQlPgx+R4LSDmzgLzEwfOyIGFmAS2J749agcJcQOXzmSSeTNsI 1issEC3xa+czdhCbTUBV4sGcY4wgNqeAgcSelytZQGwWoPidradYIAYJS3x/fI8FYpeNxMnF a5gghnYxSTyb/BNsqIiAisSNY7fYIQ6VlTh97jnLBEaBWUjum4Vw3ywk9y1gZF7FKFqUmpNY aayXWJyZqJdYUJCTqpecn7uJERJ+gjsYP0w1PMQowMGoxMPL9LooSIg1say4MvcQowQHs5II 727/iiAh3pTEyqrUovz4otKc1OJDjNIcLErivLL/yoOEBNITS1KzU1MLUotgskwcnFINjJOf dfAvY45aLh1c8eVB5KGn973XWV2Kq9bas7VWq0tFzyXfxfdkoequtXuKlhn4ZFyX7Do1Kd9l 5lr1hIn955bwzeBNfNRXcvqQalDIPq8stxfF709HXU6bzM1bzttX0BGsVrJwzvrFBbIn5l+5 yPp9aQzHzbiCyi3Pwhe+Y5nHUPjq7uH0l0osxRmJhlrMRcWJAD2sfYk7AgAA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 02:26:02 -0000 On Nov 5, 2013, at 1:35 , cowwoc wrote: > On 04/11/2013 11:26 AM, Randell Jesup wrote: >> Interop is certainly a consideration and that's where H.264's advantage lies. (H.264's only real technical advantages are interop and the possibility of existing hardware support). > > When was Constrained Baseline Profile defined? Based on Wikipedia I'm guessing it was sometime in 2009. If so, how widely is it implemented? It got its name then, yes. Previously it was known as that portion of baseline that was compatible also with the main profile, which was such a mouthful, people finally gave it a name. > > We keep on referring to H.264 as a black box that is supported universally, but when you dig into the specifics (specific profile on specific platforms) the story is a lot less clear. > > Gili > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb David Singer Multimedia and Software Standards, Apple Inc. From mzanaty@cisco.com Mon Nov 4 18:52:46 2013 Return-Path: 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 4782111E82CF for ; Mon, 4 Nov 2013 18:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.765 X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666] 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 H9Ez8PSt8AqU for ; Mon, 4 Nov 2013 18:52:41 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 949C511E8317 for ; Mon, 4 Nov 2013 18:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7341; q=dns/txt; s=iport; t=1383619954; x=1384829554; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ru2D5m2dpKVulo2TXCeXid48Xk77cVVqZD5wmhA4G9Q=; b=jITXCxUdAQADkqP7HpQt0YtY2H2IA5MPsKzVI4Eog3ICtGkkIa5fHfA9 GRPfclejz8Sd3zrdlUIvwBAJVWThUCljp6FgczFoHOsLP7XDcZzeGzxKM pyVKzm0vVW2G8OhGMHm4QdHJA/QLXP2eWn8Qvqji4P3+26HMOA2ZCLAkB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFACpdeFKtJV2c/2dsb2JhbABZgkNEOFO+cEuBKBZ0gicBBAEBAWsLEgEIPygGCxQRAgQBDQUUB4dUAw8NtDwNiWcEjFuCbAQHhC4Dlh+Ba4xShTeBO4Frgio X-IronPort-AV: E=Sophos;i="4.93,637,1378857600"; d="scan'208,217";a="280661073" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2013 02:52:34 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA52qYJf025470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 02:52:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 20:52:33 -0600 From: "Mo Zanaty (mzanaty)" To: Kaiduan Xie , Eric Rescorla Thread-Topic: [rtcweb] Platforms that support H264 Thread-Index: AQHO2dIT0OsOgTLqXE2Wnbsc3UuMdA== Date: Tue, 5 Nov 2013 02:52:33 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.248.160] Content-Type: multipart/alternative; boundary="_000_CE9DC5C81B814mzanatyciscocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 02:52:46 -0000 --_000_CE9DC5C81B814mzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think you meant *every* phone, tablet, laptop, desktop, set-top, camera= =85 On 11/2/13, 7:41 PM, Kaiduan Xie > wrote: Every BlackBerry 10 phone has H.264 hardware encoder/decoder. /Kaiduan On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla > wrote: On Sat, Nov 2, 2013 at 1:01 PM, Gili > wrote: Martin, I fully understand why Firefox would be happy but as someone who plan t= o integrate WebRTC into a non-browser application, especially on iOS, Cisco= 's solution simply does not work. I appreciate their contribution, but agai= n, it simply doesn't help my use-case. I haven't seen you explain how your use case is different from that of a browser. Could you please do so? -Ekr Gili On 11/2/2013 11:02 AM, Martin Thomson wrote: On 2 November 2013 07:37, cowwoc > wrote: I can't think of a single platform that supports real-time H.264 encoding/decoding natively today. That's a very strange way to put the question. Let me put another spin on it, and please excuse the example... Skype runs on more platforms than you might think. Those platforms can all support H.264 to the extent that Skype requires. Cisco's generous offer opens almost the same capability to anyone, with the caveat that some platforms currently remain closed. Of course, you could let your ideals get in the way of progress. Me, I'm a pragmatist. This gift represents a great opportunity for people who actually care about the practical outcomes. There's been a lot of mouth-gazing of gift horses on this list of late. I sure hope that this isn't representative of the real sentiment of the community. I'd like to think that people are better than that. (BTW, I understand and respect Harald's position. From where he sits, I'm sure that his conclusion makes perfect sense.) _______________________________________________ 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 --_000_CE9DC5C81B814mzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I think you meant *every* phone, tablet, laptop, desktop, set-top, cam= era=85 


On 11/2/13, 7:41 PM, Kaiduan Xie <kaiduanx@gmail.com> wrote:

Every BlackBerry 10 phone has H.264 hardware encoder/decod= er.

/Kaiduan


On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla <ekr@rtfm.com><= /span> wrote:



On Sat, Nov 2, 2013 at 1:01 PM, Gili &l= t;cowwoc@bbs.d= arktech.org> wrote:
Martin,

    I fully understand why Firefox would be happy but as someone = who plan to integrate WebRTC into a non-browser application, especially on = iOS, Cisco's solution simply does not work. I appreciate their contribution= , but again, it simply doesn't help my use-case.

I haven't seen  you explain how your use case is different from t= hat of
a browser. Could you please do so?

-Ekr
 
Gili


On 11/2/2013 11:02 AM, Martin Thomson wrote:
On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
     I can't think of a single platform that supports real-t= ime H.264
encoding/decoding natively today.
That's a very strange way to put the question.

Let me put another spin on it, and please excuse the example...

Skype runs on more platforms than you might think.  Those platforms can all support H.264 to the extent that Skype requires.

Cisco's generous offer opens almost the same capability to anyone,
with the caveat that some platforms currently remain closed.  Of
course, you could let your ideals get in the way of progress.  Me, I'm=
a pragmatist.  This gift represents a great opportunity for people who=
actually care about the practical outcomes.

There's been a lot of mouth-gazing of gift horses on this list of
late.  I sure hope that this isn't representative of the real
sentiment of the community.  I'd like to think that people are better<= br> than that.

(BTW, I understand and respect Harald's position.  From where he sits,=
I'm sure that his conclusion makes perfect sense.)

_______________________________________________
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


 --_000_CE9DC5C81B814mzanatyciscocom_-- From giles@thaumas.net Mon Nov 4 18:58:31 2013 Return-Path: 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 42F8B21E83A0 for ; Mon, 4 Nov 2013 18:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, RCVD_IN_DNSWL_LOW=-1] 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 GYqaseW9Jbed for ; Mon, 4 Nov 2013 18:58:26 -0800 (PST) Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by ietfa.amsl.com (Postfix) with ESMTP id 94E2F21E83AE for ; Mon, 4 Nov 2013 18:58:21 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id my12so1351183bkb.24 for ; Mon, 04 Nov 2013 18:58:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=/Q75zdyMqiwIPDxmRkiIY/hRLro5/BljUIkjMzoosr4=; b=Bo4praEsJwwzwbnodtJuleT26lftS6/lXjEyY6Sf19gWvuIq1KQvcvleqQo0PlB1Gv HRTENkP7JJxkW5MHVNM0i7iNAF2cPkSY5huJ/Ve2kFR8SYjUkHk/S9y9UvvCrC6QHdLm S1quugeSnjukMpU4bibH+SLSh9bq4oIEAMzYsyHV+qh/hWuoPWPgH434jBgGLTsDTbLf jhx1bPmS7465AZOALkxefi72sBpEdOS0pIc+q0oQBfm4bvGKICUxa9/29z8wIBkde5sO J0wZ6H0hFkEM2RM1Fb6Z2WlqKQrC/BKUd4dGiZ4WR9kE2wAvR4Y9nkpun1GLKLP049FU RGpA== X-Gm-Message-State: ALoCoQmmDx8m0Nuc6+qGm15zjLFjydxtrRRnEkRrkDhJcxv8xybo/w0xdOMWvq4nFsvK3Nw7L3LQ X-Received: by 10.204.69.202 with SMTP id a10mr559403bkj.36.1383620300754; Mon, 04 Nov 2013 18:58:20 -0800 (PST) Received: from tamias.local (static-68-179-67-77.ptr.terago.net. [68.179.67.77]) by mx.google.com with ESMTPSA id pk7sm17391173bkb.2.2013.11.04.18.58.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 18:58:19 -0800 (PST) Message-ID: <52785EC7.1040904@thaumas.net> Date: Mon, 04 Nov 2013 18:58:15 -0800 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Cullen Jennings , Ted Dardie , Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: [rtcweb] Notes from the IETF88 Monday RTCWEB session X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 02:58:31 -0000 Here are the notes I took during today's RTCWEB session. Conclusions/decisions are marked with a leading dash. Original at https://etherpad.mozilla.org/ietf88-rtcweb === IETF 88 - Vancouver BC === RTCWEB WG meeting notes 2013 November 4 14h50-17h20 IETF Note Well Agenda Chairs JSEP (15m) Data channel Security RTP == Discussion notes == Chair update: Magnus Westerlund Milestone review: documents, dependencies. We'd like complete milestones as quickly as possible; out overall goal is to finish in 2014. This will be a challenge. Help by reviewing documents and sending comments. Authors, consider if our normative references make sense. Are they really needed? Waiting on references slows down publication. Ted Hardie: hum calibration. "Some counterfactual humming." = JSEP update: Justin Uberti Look at examples at least if you can do a minimal review of the draft. Manditory-to-implement SDP features and things manditory to use now documented. Q1: Re-offer handling Proposal: Use a new peerconnection for full renegotiation, heavy-weight changes. MUST NOT re-offer e.g. codecs rejected by the other side. Don't make things harder for application developers by leaving this to implementators. - Conclusion: Complex matrix of options, difficult to judge the room. More discussion is needed. Think of more specifc proposals. Notetaker's summary of discussion: Some concern that there's no way to upgrade options. SDP could come from a non-webrtc endpoint, so we can't rely on the other side respecting this. MUST so applications behave uniformly. Available resources, like hardware codecs can change. Bundle less controversial, since it's constant for the implementation. Has specific language about initial and subsequent offers already. There's no way to tell the difference between unsupported and unsupported-right-now with this proposal. Q2: a=connection. Should we add it? Is it useful to use connection=new to force DTLS renegotiation. - Conclusion: No, per existing specs. (no concensus call) Discussion summary: Makes sense of TCP, not the best interface for DTLS. Unless we can come up with a reason to swap roles mid-stream, don't mess with this. Just set it up and keep it up. MITM attacks are a use case! Q3: CNAMEs Is there a way to synchronize multiple MediaStreams from the W3C API so they can share a CNAME. - No proposal, just discussion. Discussion summary: Can we just map MediaStreams to CNAMEs? It should be the senders choice to use the same CNAME or different for two MediaStreams. There's no compelling reason to expose that to the application running on the browser on the other side. Shared CNAMEs don't _have_ to be synchronized at playback. Could use the absense of an attribute to indicate unsynced. Application could add a track to two different MediaStreams to indicate sync. This is a W3C problem, not an IETF problem. Q4: BUNDLE control Try to bundle everything, add a BundleOnlyPolicy contraint to PeerConnection: all, none, or per-media type all audio bundled, all video bundled. Use per-media the default. Don't try to control things per-track. - Conclusion: General aggreement from commentors. Discussion: Disagreement. Wrong forum? (withdrawn later) Bundle is strictly better, so this is good, and gives us the minimum set of controls. We can always add more later. Could be same-priority instead of same-media? This is reasonable if it just controls what legacy applications see. Q5: m= section recycling - Conclusion: Discussion directed to the list for reasons of time. = Chairs note: Security discussion moved to the end, with the understanding we may not have time for it.] = Data Channels: Randell Jesup Remaining issues: DTLS Overhead: resolve by specifying IP Layer MTU? - Conclusion: (roughly) ask TSV working group to advance the ndata draft and try to get that solution implemented and spec'd in time for RFC. Discussion: What' is it specified to? PMTU up from some lower bound is easier to implement. max of all ciphersuite overheads, which changes with time, so we can't specify in advance. Doesn't max give you a number which could be too large? SCTP needs to know, but since it can change we shouldn't specify anything. Large message block other channels: tsv draft proposes to alleviate this In the meantime, support PPID-based fragmentation + length limit for unreliable, as discussed in drafts, implemented in Firefox How do we retire the PPID issue once SCTP interleaving works? SCTP implementaitons know what the other side supports, so it's negotiated, but you still have to implement forever? Could remove the fallback even before we finalize the draft, since implementations are ahead of the spec. Also easy to update a spec by just removing a section. Why not just do that now, and not doc the fallback or doc it as non-normative. Old, new, or both forever; which do we want? The ndata implementation is in an svn branch, needs testing before merge, so very close. Draft is still and individual submission. Expect it could be advanced if this WG asks TSV for it. Message size limitations: Propose a minimum supported maximum size of 100 MB Websocket has no spec limit, implementations pick one in practice. Maybe we should do that too? - Conclusion: write up the ack signaling as a new proposal. Discussion: What happens if you go over an implementation limit? In WebSockets, there's no way to stream things. This isn't any different Is there a way to query the limit? Get an error when it's exceeded? Not having that is bad. Imitating the mistakes of others is the best we could do. Let's make our own mistakes. We can't figure out what people want to use this for. It would be nice if there were a well known set of properties applications could assume so they would know e.g. when they need to do chunking. We've had enough discussion to decide whether we should have a deterministic limit. Could pass a limit in the handshake ack to the js api could handle it. Nagle: no longer an issue. (?) Initial number of streams: Propose not to set the maximum number of streams to 64k streams. There's no complexity advantage. - Conclusion: Set it to maximum and be done with it. Hum: I approve of setting this to the maximum, vs. I still have an issue with this. Discussion: SDP shouldn't have to worry about these details. Like IP applications applications shouldn't have to preallocate ports. SCTP implementations all pre-allocate this state, so you need 128K per connection, and never use them. Rewriting them for lazy allocation or sparse array is "just" work. While protocol renegotiation will last forever. Servers are memory-limited devices, just like low-end mobile devices. Avoid encoding numbers on wire to save implementation complexity. Better to make implementations smarter. Out of Band Negotiation: Handling collisions between in-band and out-of-band negotiations. Discussion: Browser can detect and warn on these sorts of things. In the text just say it's wrong, and error. - IANA registration protocol question. Discuss on the list. = RTP issues: Colin Perkins Discussion: - Signalling the most number of ssrc values -- Not an issue This is the same as the number of m-lines. So we don't need to say anything. Confusion between max sources, max streams. Limits are based on resolution etc., not just the number of streams. Signalling RTP topologies -- - Should multiple cnames per session be mandated? Yes - Do we need to say anything about SDP signalling for gatewaying? No - Simulcast -- Maybe, but not in this forum. See AVTEXT. - Forwarding -- If you wish to forward media, treat the RTP as if you'd transcoded. Forwarding without transcoding sounds really complicated and we shouldn't worry about it. With transcoding already works in Chrome, it's just plumbing. We can do an RTP translator later if we decide it's important. Nutty to do a middlebox in the browser. Transcoding does add delay. We're talking about two different ways of implementing something that's already possible in the W3C api. The browser has a choice on how to do this, there are easy cases where it could switch behaviours as an implementation quality issue. - Differentiated services -- Make a draft outlining the issues; make no concrete recommendations. Work going on in other working groups on these issues. - Correlating Media Streams -- No, this isn't in jsep. It doesn't makes sense to put unified-plan in the RTP usage draft. Security: Eric Rescorla Hope to update the draft in Decemeber. On the screensharing issue, both Firefox and Chrome were planning to punt in the same way. End of session. From cowwoc@bbs.darktech.org Mon Nov 4 22:10:48 2013 Return-Path: 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 103A611E8176 for ; Mon, 4 Nov 2013 22:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.628 X-Spam-Level: X-Spam-Status: No, score=-4.628 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 q-O51vqrArse for ; Mon, 4 Nov 2013 22:10:43 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id A0B8B11E8182 for ; Mon, 4 Nov 2013 22:10:39 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id x13so14246575ief.37 for ; Mon, 04 Nov 2013 22:10:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=131J8A9PZX7FoGomsKTx0yT67yVx7VBTHhqbjEkGuBQ=; b=ZJazThAsy64B/gO5uIvJpZRhq/DBWscSnpaJnM7CZ181mr6LTBDqARKp2krD2BRpzy e31VnGonIKjrP2yRR2akfO9E+39m691UHjKUGwWBBx8XBUCt6wbS8V7uPZQBZgQKHRqd fpLfTOPQK4LNPwJv92vPqhaqoxiegEkLkHxN67fM9R6jHKCuLwrcNTeSBp60x01/03h3 ae0Dr4mM61neWU/YY71MMg9rH/+WeTUvg+LkTDzAwEpPiV1QRm9x+q5RBJ2GCmH0MmS0 7EYd9niPAH3kUqhVHh3yEOgiiVByr+V3VbCLlbq8j6H/uGLXOdEJqFOmak/Ext/gF71H dnsw== X-Gm-Message-State: ALoCoQlVFkt4ccHOBMurpwUKd7OC12D5vkN9NsUGMHnFqp89gucrBRTowENlp9PFPqSQ1xqPqjJq X-Received: by 10.50.45.100 with SMTP id l4mr14563766igm.8.1383631838768; Mon, 04 Nov 2013 22:10:38 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p5sm6982603igj.10.2013.11.04.22.10.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 22:10:37 -0800 (PST) Message-ID: <52788BDC.90109@bbs.darktech.org> Date: Tue, 05 Nov 2013 01:10:36 -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: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040205090505000207000304" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 06:10:48 -0000 This is a multi-part message in MIME format. --------------040205090505000207000304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm not sure if you're being sarcastic or not... In any case, I had a question regarding BlackBerry 10. Are you implying that every BlackBerry 10 phone includes an API for real-time encoding/decoding of H.264 video streams? If so, which API is it? I took a quick look but couldn't find it. Thanksm Gili On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote: > I think you meant *every* phone, tablet, laptop, desktop, set-top, > camera... > > > On 11/2/13, 7:41 PM, Kaiduan Xie > wrote: > > Every BlackBerry 10 phone has H.264 hardware encoder/decoder. > > /Kaiduan > > > On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla > wrote: > > > > > On Sat, Nov 2, 2013 at 1:01 PM, Gili > wrote: > > Martin, > > I fully understand why Firefox would be happy but as > someone who plan to integrate WebRTC into a non-browser > application, especially on iOS, Cisco's solution simply does > not work. I appreciate their contribution, but again, it > simply doesn't help my use-case. > > > I haven't seen you explain how your use case is different from > that of > a browser. Could you please do so? > > -Ekr > > Gili > > > On 11/2/2013 11:02 AM, Martin Thomson wrote: > > On 2 November 2013 07:37, cowwoc > wrote: > > I can't think of a single platform that supports > real-time H.264 > encoding/decoding natively today. > > That's a very strange way to put the question. > > Let me put another spin on it, and please excuse the > example... > > Skype runs on more platforms than you might think. Those > platforms > can all support H.264 to the extent that Skype requires. > > Cisco's generous offer opens almost the same capability to > anyone, > with the caveat that some platforms currently remain > closed. Of > course, you could let your ideals get in the way of > progress. Me, I'm > a pragmatist. This gift represents a great opportunity > for people who > actually care about the practical outcomes. > > There's been a lot of mouth-gazing of gift horses on this > list of > late. I sure hope that this isn't representative of the real > sentiment of the community. I'd like to think that people > are better > than that. > > (BTW, I understand and respect Harald's position. From > where he sits, > I'm sure that his conclusion makes perfect sense.) > > > _______________________________________________ > 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 --------------040205090505000207000304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    I'm not sure if you're being sarcastic or not...

    In any case, I had a question regarding BlackBerry 10. Are you implying that every BlackBerry 10 phone includes an API for real-time encoding/decoding of H.264 video streams? If so, which API is it? I took a quick look but couldn't find it.

Thanksm
Gili

On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote:
I think you meant *every* phone, tablet, laptop, desktop, set-top, camera… 


On 11/2/13, 7:41 PM, Kaiduan Xie <kaiduanx@gmail.com> wrote:

Every BlackBerry 10 phone has H.264 hardware encoder/decoder.

/Kaiduan


On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Sat, Nov 2, 2013 at 1:01 PM, Gili <cowwoc@bbs.darktech.org> wrote:
Martin,

    I fully understand why Firefox would be happy but as someone who plan to integrate WebRTC into a non-browser application, especially on iOS, Cisco's solution simply does not work. I appreciate their contribution, but again, it simply doesn't help my use-case.

I haven't seen  you explain how your use case is different from that of
a browser. Could you please do so?

-Ekr
 
Gili


On 11/2/2013 11:02 AM, Martin Thomson wrote:
On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
     I can't think of a single platform that supports real-time H.264
encoding/decoding natively today.
That's a very strange way to put the question.

Let me put another spin on it, and please excuse the example...

Skype runs on more platforms than you might think.  Those platforms
can all support H.264 to the extent that Skype requires.

Cisco's generous offer opens almost the same capability to anyone,
with the caveat that some platforms currently remain closed.  Of
course, you could let your ideals get in the way of progress.  Me, I'm
a pragmatist.  This gift represents a great opportunity for people who
actually care about the practical outcomes.

There's been a lot of mouth-gazing of gift horses on this list of
late.  I sure hope that this isn't representative of the real
sentiment of the community.  I'd like to think that people are better
than that.

(BTW, I understand and respect Harald's position.  From where he sits,
I'm sure that his conclusion makes perfect sense.)

_______________________________________________
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

--------------040205090505000207000304-- From mzanaty@cisco.com Tue Nov 5 00:56:04 2013 Return-Path: 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 5CED511E810D for ; Tue, 5 Nov 2013 00:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 vNYyOL4-Bt8y for ; Tue, 5 Nov 2013 00:55:59 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id CB9DD21F9E9F for ; Tue, 5 Nov 2013 00:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10610; q=dns/txt; s=iport; t=1383641755; x=1384851355; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=DqJTm9PUa9FxWlz7ij5+GJAEWRzrAh4Kas9fw5Doc7c=; b=RFLKLXKmtwJnjAuMrGNti9+ectFfrGEbgulvg0DiMWy5KDz9t1ssVAXS MY+lnD51RFIo4qhgmX4LSQTQ7eapv2u5/CcBOKC5a7MSgo2meM+RaTCSf 84bkzuFMMjuFvz4Rcvxc2MoYPgRBvIJogi183j1TcWrvhSI4mK67p4f1h Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FALaxeFKtJV2a/2dsb2JhbABagkNEOFO+b0uBJRZ0gicBBAEBAWsdAQg/KAYLFBECBAESCQsHh1QDDw20EQ2Ja4xYD4J5hC8Dlh+Ba4xShTeDJoIq X-IronPort-AV: E=Sophos;i="4.93,638,1378857600"; d="scan'208,217";a="280818225" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2013 08:55:53 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA58trro003174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 08:55:53 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 02:55:52 -0600 From: "Mo Zanaty (mzanaty)" To: cowwoc , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Platforms that support H264 Thread-Index: AQHO2gTU0OsOgTLqXE2Wnbsc3UuMdA== Date: Tue, 5 Nov 2013 08:55:52 +0000 Message-ID: In-Reply-To: <52788BDC.90109@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.211.238] Content-Type: multipart/alternative; boundary="_000_CE9E0E331B9A4mzanatyciscocom_" MIME-Version: 1.0 Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 08:56:04 -0000 --_000_CE9E0E331B9A4mzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92m serious. Name a device in mass production that is relevant to rtcweb = but does not have H.264 hardware. Your second point is valid; hardware is useless without supporting software= . OS APIs to access codecs (both hardware and software, real-time and buffe= red) is an important issue. Android is the dominant OS on the planet. If yo= u are not happy with its OS APIs, just change them; it=92s open source like= VP8 right? Mo On 11/5/13, 1:10 AM, cowwoc > wrote: I'm not sure if you're being sarcastic or not... In any case, I had a question regarding BlackBerry 10. Are you implying= that every BlackBerry 10 phone includes an API for real-time encoding/deco= ding of H.264 video streams? If so, which API is it? I took a quick look bu= t couldn't find it. Thanksm Gili On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote: I think you meant *every* phone, tablet, laptop, desktop, set-top, camera= =85 On 11/2/13, 7:41 PM, Kaiduan Xie > wrote: Every BlackBerry 10 phone has H.264 hardware encoder/decoder. /Kaiduan On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla > wrote: On Sat, Nov 2, 2013 at 1:01 PM, Gili > wrote: Martin, I fully understand why Firefox would be happy but as someone who plan t= o integrate WebRTC into a non-browser application, especially on iOS, Cisco= 's solution simply does not work. I appreciate their contribution, but agai= n, it simply doesn't help my use-case. I haven't seen you explain how your use case is different from that of a browser. Could you please do so? -Ekr Gili On 11/2/2013 11:02 AM, Martin Thomson wrote: On 2 November 2013 07:37, cowwoc > wrote: I can't think of a single platform that supports real-time H.264 encoding/decoding natively today. That's a very strange way to put the question. Let me put another spin on it, and please excuse the example... Skype runs on more platforms than you might think. Those platforms can all support H.264 to the extent that Skype requires. Cisco's generous offer opens almost the same capability to anyone, with the caveat that some platforms currently remain closed. Of course, you could let your ideals get in the way of progress. Me, I'm a pragmatist. This gift represents a great opportunity for people who actually care about the practical outcomes. There's been a lot of mouth-gazing of gift horses on this list of late. I sure hope that this isn't representative of the real sentiment of the community. I'd like to think that people are better than that. (BTW, I understand and respect Harald's position. From where he sits, I'm sure that his conclusion makes perfect sense.) _______________________________________________ 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.orghttps://www.ietf.org/mailman/listinf= o/rtcweb --_000_CE9E0E331B9A4mzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <642D09BCB36DB6438C043893D5B119EF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I=92m serious. Name a device in mass production that is relevant to rt= cweb but does not have H.264 hardware.

Your second point is valid; hardware is useless without supporting sof= tware. OS APIs to access codecs (both hardware and software, real-time and = buffered) is an important issue. Android is the dominant OS on the planet. = If you are not happy with its OS APIs, just change them; it=92s open source like VP8 right?

Mo


On 11/5/13, 1:10 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:


    I'm not sure if you're being sarcastic or not...

    In any case, I had a question regarding BlackBerry 10. A= re you implying that every BlackBerry 10 phone includes an API for real-tim= e encoding/decoding of H.264 video streams? If so, which API is it? I took = a quick look but couldn't find it.

Thanksm
Gili

On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote:
I think you meant *every* phone, tablet, laptop, desktop, set-top, cam= era=85 


On 11/2/13, 7:41 PM, Kaiduan Xie <kaiduanx@gmail.com> wrote:

Every BlackBerry 10 phone has H.264 hardware encoder/decod= er.

/Kaiduan


On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Sat, Nov 2, 2013 at 1:01 PM, Gili &l= t;cowwoc@bbs.darktech.org> wrote:
Martin,

    I fully understand why Firefox would be happy but as someone = who plan to integrate WebRTC into a non-browser application, especially on = iOS, Cisco's solution simply does not work. I appreciate their contribution= , but again, it simply doesn't help my use-case.

I haven't seen  you explain how your use case is different from t= hat of
a browser. Could you please do so?

-Ekr
 
Gili


On 11/2/2013 11:02 AM, Martin Thomson wrote:
On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.o= rg> wrote:
     I can't think of a single platform that supports real-t= ime H.264
encoding/decoding natively today.
That's a very strange way to put the question.

Let me put another spin on it, and please excuse the example...

Skype runs on more platforms than you might think.  Those platforms can all support H.264 to the extent that Skype requires.

Cisco's generous offer opens almost the same capability to anyone,
with the caveat that some platforms currently remain closed.  Of
course, you could let your ideals get in the way of progress.  Me, I'm=
a pragmatist.  This gift represents a great opportunity for people who=
actually care about the practical outcomes.

There's been a lot of mouth-gazing of gift horses on this list of
late.  I sure hope that this isn't representative of the real
sentiment of the community.  I'd like to think that people are better<= br> than that.

(BTW, I understand and respect Harald's position.  From where he sits,=
I'm sure that his conclusion makes perfect sense.)

_______________________________________________
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
rtcwe=
b@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb

 --_000_CE9E0E331B9A4mzanatyciscocom_-- From mzanaty@cisco.com Tue Nov 5 01:52:14 2013 Return-Path: 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 8D97A11E81A9 for ; Tue, 5 Nov 2013 01:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 jD4ZqbtnaazK for ; Tue, 5 Nov 2013 01:52:09 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id ED0AB21E80BB for ; Tue, 5 Nov 2013 01:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9398; q=dns/txt; s=iport; t=1383645129; x=1384854729; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Wwl8V37lYiOYmorDuJYZ57VBjmIfFzZJNlgmGYthhmQ=; b=TDlTyVb4OnrOA8P0iogUlHDwTm8s5XRUC9ulJ+lbnhWde51yiT7sVCJI b9n113lmW0mAQIlgcEclnJT6tqYTZSE5/Qk8WUgwR8cXlDEZS18q/hR0k VXnuFf9wtjafu3C36TOzyIuNWvJ0bHPo3C+OVFFwmQnp2S9nuPWAMVaHE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAFG/eFKtJXG//2dsb2JhbABagkNEOFO/OoEnFnSCJQEBAQSBCwEZBAEBKDkUCQgCBAESCYd4vh6PXwGELwOYCpIJgyaCKg X-IronPort-AV: E=Sophos;i="4.93,638,1378857600"; d="scan'208,217";a="280820608" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 05 Nov 2013 09:52:08 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA59q73u013663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 09:52:07 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 03:52:07 -0600 From: "Mo Zanaty (mzanaty)" To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: OS Codec APIs Thread-Index: AQHO2gyw8j4+0037VkqJng1+MvnW/w== Date: Tue, 5 Nov 2013 09:52:06 +0000 Message-ID: In-Reply-To: <5277262E.3050600@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.211.238] Content-Type: multipart/alternative; boundary="_000_CE9DD01F1B8E7mzanatyciscocom_" MIME-Version: 1.0 Subject: [rtcweb] OS Codec APIs X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 09:52:14 -0000 --_000_CE9DD01F1B8E7mzanatyciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Khronos OpenMAX IL is the de facto standard for how all chipset vendors exp= ose their codecs to the OS/platform. The problem is the OS/platform does no= t usually expose those same codecs up to apps with the same API richness (o= r at all). There are unofficial/hacky ways to access this in Android via IO= MX (NDK), or iOS via AV Foundation, as well as official ways in Android 4.1= + via MediaCodec (SDK). But they typically lack the richness of the underly= ing OMX IL from the chipset vendors, especially real-time and error resilie= nce features. In my experience with the dominant codec silicon vendors (QCOM, IMG, TI, et= c.), their OMX IL implementations are quite robust but not fully interchang= eable, i.e. the OS/platform (or app) must cope with different feature sets = across the various vendor components. Mo On 11/3/13, 11:44 PM, Randell Jesup > wrote: On 11/3/2013 12:34 PM, DRAGE, Keith (Keith) wrote: The only stuff I am aware of is done by http://www.khronos.org/ But that is as far as my knowledge goes. My understanding from someone at Skype who worked with OMX stuff was that i= t was horribly poorly compatible because most people never ran any of the t= est suites that Kronos charges for. Take with a huge grain of salt as this= is second-hand and wasn't the primary topic. It would certainly be desireable that there is an standardised API that eve= ryone uses to get access to embedded hardware codec support. Always a good thing, if it's done well. Keith ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: 03 November 2013 18:10 To: rtcweb@ietf.org Subject: [rtcweb] API standardization on phones? (Re: Platforms that suppor= t H264) On 11/03/2013 06:52 PM, DRAGE, Keith (Keith) wrote: And this is where it would be useful to see some work done, although probab= ly not by IETF. There a a few bits of API work out there, but nowhere do we see much push f= or adoption. As fae as I see there is no political reason why they should n= ot be adopted, or even a fresh effort adopted to create some new ones. The = only thing seems to be lack of impetus. What's the industry state on standardization of APIs for phones? Most of what I see seems to be platform specific, with some exceptions (Ope= nGL / WebGL for graphics, OpenES for audio). But it's not where I spend the most time looking; it would be good to have = someone who knows this space summarize -- Randell Jesup randell-ietf@jesup.org --_000_CE9DD01F1B8E7mzanatyciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <395744D196E7944EB39045C0B56B4EFF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Khronos OpenMAX IL is the de facto standard for how all chipset vendor= s expose their codecs to the OS/platform. The problem is the OS/platform do= es not usually expose those same codecs up to apps with the same API richne= ss (or at all). There are unofficial/hacky ways to access this in Android via IOMX (NDK), or iOS via AV Foundation, a= s well as official ways in Android 4.1+ via MediaCodec (SDK). But they = typically lack the richness of the underlying OMX IL from the chipset vendo= rs, especially real-time and error resilience features.

In my experience with the dominant codec silicon vendors (QCOM, IMG, T= I, etc.), their OMX IL implementations are quite robust but not fully inter= changeable, i.e. the OS/platform (or app) must cope with different feature = sets across the various vendor components.

Mo

On 11/3/2013 12:34 PM, DRAGE, Keith (Keith) = wrote:
The only stuff I am aware of is d= one by
&= nbsp;
http://www.khronos.org/
&= nbsp;
But that is as far as my knowledg= e goes.

My understanding from someone at Skype who worked with OMX stuff was that i= t was horribly poorly compatible because most people never ran any of the t= est suites that Kronos charges for.  Take with a huge grain of salt as= this is second-hand and wasn't the primary topic.

&= nbsp;
It would certainly be desireable = that there is an standardised API that everyone uses to get access to embed= ded hardware codec support.

Always a good thing, if it's done well.

&= nbsp;
Keith

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 03 November 2013 18:10
To: rtcweb@ietf.org
Subject: [rtcweb] API standardization on phones? (Re: Platforms that= support H264)

On 11/03/2013 06:52 PM, DRAGE, Keith (Keith)= wrote:
And this is where it would be use= ful to see some work done, although probably not by IETF.
&= nbsp;
There a a few bits of API work ou= t there, but nowhere do we see much push for adoption. As fae as I see= there is no political reason why they should not be adopted, or even a fresh effort adopted to create some new ones. The on= ly thing seems to be lack of impetus.

What's the in= dustry state on standardization of APIs for phones?

Most of what I see seems to be platform specific, with some exceptions (Ope= nGL / WebGL for graphics, OpenES for audio).

But it's not where I spend the most time looking; it would be good to have = someone who knows this space summarize 

--=20
Randell Jesup
randell-ietf@jesup.org
--_000_CE9DD01F1B8E7mzanatyciscocom_-- From kris@kriskinc.com Tue Nov 5 06:01:19 2013 Return-Path: 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 A15FE21E8235 for ; Tue, 5 Nov 2013 06:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 yAFEUlM+HZ0y for ; Tue, 5 Nov 2013 06:01:13 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 880CE11E8188 for ; Tue, 5 Nov 2013 06:00:53 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id b13so3530937wgh.22 for ; Tue, 05 Nov 2013 06:00:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rdTU+OweFkjxCq2oi7IIQSe2TM4IW6wwZkEkiEeuEVM=; b=CxUUp50mWy7CuCkE9gtvATd/0wz0ZT7DLXvnrBKO8+cVVPna+C9+LtGwM7Q3ZEB4QE Wb2DsivtBd5NFHj3m29EQhOLzWv4SK2p3qQXfB5I8Wbn9OhELx6qPZweaKGUVeBqps2E pmO09ezUlK9EuGp64Y0FCt/zZz9sPA0ZXqklo/6LSEp7sC0ZuXET+SPXyTz7au9U/jtd wcT68mGtZ9kItdzuuVybSRu8Gyo0tmWym0uteeGr91tBcTbRUnOn0RJqppIQNI3jH4Ih 4pXf9U/Z2fKJBqqiLnyQEf3x0rg0Fe9W+FdsGSXLzyhVjeqbayBJ8I1/eni0aEuKmZAK +/bg== X-Gm-Message-State: ALoCoQl/NGygik00zED9eIxbsYz2xM6PTpzY+ASZN2EMQ6MGUwwbJabWAQhPcs7/5y882ylaVN43 MIME-Version: 1.0 X-Received: by 10.180.13.13 with SMTP id d13mr16980805wic.34.1383660034985; Tue, 05 Nov 2013 06:00:34 -0800 (PST) Received: by 10.227.154.136 with HTTP; Tue, 5 Nov 2013 06:00:34 -0800 (PST) In-Reply-To: <014601ced9b6$15233ff0$3f69bfd0$@shockey.us> References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> <5277E85C.4060905@thaumas.net> <014601ced9b6$15233ff0$3f69bfd0$@shockey.us> Date: Tue, 5 Nov 2013 09:00:34 -0500 Message-ID: From: Kristian Kielhofner To: Richard Shockey Content-Type: multipart/alternative; boundary=001a11c2a462e0288704ea6e7465 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 14:01:19 -0000 --001a11c2a462e0288704ea6e7465 Content-Type: text/plain; charset=ISO-8859-1 You might be interested in my updated analysis here: http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html SIP "enhancements" indeed! On Monday, November 4, 2013, Richard Shockey wrote: > > That has been confirmed by independent Wireshark analysis. > > http://www.packetstan.com/2010/07/special-look-face-time-part-1.html > > Its also SIP with some Apple "enhancements" > > > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto: > rtcweb-bounces@ietf.org ] On Behalf Of > Ralph Giles > Sent: Monday, November 04, 2013 1:33 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Platforms that support H264 > > On 2013-11-04 5:51 AM, David Singer wrote: > > > reverse engineering suggests that FaceTime uses AVC (H.264). > > Reverse engineering isn't necessary to establish this, although it's nice > to > have ongoing confirmation of the details. :-) > > http://cdn1.appleinsider.com/facetime.002.jpg > > -r > _______________________________________________ > 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 > -- Sent from mobile device --001a11c2a462e0288704ea6e7465 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You might be interested in my updated analysis here:


SIP "enhancements" indeed!

On Monday, = November 4, 2013, Richard Shockey wrote:

That has been confirmed by independent Wireshark analysis.

http://www.packetstan.com/2010/07/special-look-face= -time-part-1.html

Its also SIP with some Apple "enhancements"



-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Ralph Giles
Sent: Monday, November 04, 2013 1:33 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Platforms that support H264

On 2013-11-04 5:51 AM, David Singer wrote:

> reverse engineering suggests that FaceTime uses AVC (H.264).

Reverse engineering isn't necessary to establish this, although it'= s nice to
have ongoing confirmation of the details. :-)

http://cdn1.appleinsider.com/facetime.002.jpg

=A0-r
_______________________________________________
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


--
Sent from mobile device
--001a11c2a462e0288704ea6e7465-- From andrew.hutton@unify.com Tue Nov 5 06:18:19 2013 Return-Path: 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 4ADAC21E815A for ; Tue, 5 Nov 2013 06:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] 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 lT7nP3PgRrPR for ; Tue, 5 Nov 2013 06:18:14 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1281621E8155 for ; Tue, 5 Nov 2013 06:18:13 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 54BD11EB8552 for ; Tue, 5 Nov 2013 15:18:12 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 15:18:12 +0100 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: Making both VP8 and H264 MTI Thread-Index: Ac7aMdpANg5/0KzyRDSTwYCn1us4cw== Date: Tue, 5 Nov 2013 14:18:11 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C2EFD0@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 14:18:19 -0000 It seems to me that making both VP8 and H264 MTI might be a good option for= WebRTC in terms of maximizing interoperability and would be a better decis= ion coming out of this IETF meeting than no decision at all. Can we have some clarification as to whether any consensus call during this= week's meeting will include this option? Previously it was stated that the questions to be asked would be: 1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 2. If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. How would we conclude that the community would like both to be made MTI? Regards Andy=20 From martin.thomson@gmail.com Tue Nov 5 06:46:49 2013 Return-Path: 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 437D421E82FB for ; Tue, 5 Nov 2013 06:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 eZViUvWLBzXa for ; Tue, 5 Nov 2013 06:46:48 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7426321E82CA for ; Tue, 5 Nov 2013 06:46:47 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id y10so3599640wgg.20 for ; Tue, 05 Nov 2013 06:46:46 -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=yQJ7hUuGx050hRwCoxj0/G9mhTHECo5r5Dvbz/C2eLA=; b=I1Wz2XCEGL/rhZrjkpIrQ0V+YbhYruQdNyQkPflIy8kpNOuuR6m1ZnYYT3/vEjgDSA 4b0asR18LdfZQwemgjMLkivBGMqgTG60thxQzCTRw6MMqBuhDyDAUUggOyn3unOzJIEz WHgzwUC1vmDxXqPXkuKhX3lY4dkdY/ypa3Gt+80yDbCfceDkB70gFEwAlJaTtVFL8yqG G8wkwhRwFzLioFcckt0FpDxW8fNR0CRa0xy06vj+1trW8odxyVHT29chINRY64elDcMF HEi/Pk34NkyYTjJ39FTT1eBKfLkPa9oFC3qwoFingKBijR/i2f9FHBV1QdhZlQsurfkT 5UIQ== MIME-Version: 1.0 X-Received: by 10.181.13.204 with SMTP id fa12mr16973935wid.22.1383662806007; Tue, 05 Nov 2013 06:46:46 -0800 (PST) Received: by 10.227.202.194 with HTTP; Tue, 5 Nov 2013 06:46:45 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C2EFD0@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17C2EFD0@MCHP04MSX.global-ad.net> Date: Tue, 5 Nov 2013 06:46:45 -0800 Message-ID: From: Martin Thomson To: "Hutton, Andrew" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 14:46:49 -0000 On 5 November 2013 06:18, Hutton, Andrew 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. From randell-ietf@jesup.org Tue Nov 5 06:58:17 2013 Return-Path: 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 53AF321E8262 for ; Tue, 5 Nov 2013 06:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 efacs3rVmvPa for ; Tue, 5 Nov 2013 06:58:11 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EAA1B11E8292 for ; Tue, 5 Nov 2013 06:58:09 -0800 (PST) Received: from [64.114.24.114] (port=65475 helo=[142.131.18.239]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Vdi53-0009G7-6l for rtcweb@ietf.org; Tue, 05 Nov 2013 08:58:09 -0600 Message-ID: <52790780.6020704@jesup.org> Date: Tue, 05 Nov 2013 06:58:08 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020406030208020308040501" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 14:58:17 -0000 This is a multi-part message in MIME format. --------------020406030208020308040501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/5/2013 12:55 AM, Mo Zanaty (mzanaty) wrote: > I'm serious. Name a device in mass production that is relevant to > rtcweb but does not have H.264 hardware. Plenty have hardware is out there that might not be optimized (or usable) for the types of arbitrary-sized, realtime simultaneous h.264 encode/decode. Even just handling streaming decode on Android via OMX has been a year of pain for one of our engineers, because (especially before JB) the interfaces were unsupported, randomly modified/incompatible, and with lots of restrictions on what actually is supported. Even with "perfect" API layers exposing them, the hardware layers (especially encoders) may not have the low-latency and other realtime characteristics needed, or knobs to tell them about things like packet loss reports that require IDR generation. How many does this affect? who knows - and the API layers on top are inconsistent enough (or non-existent at the present) that it's especially hard to tell. And many of them can handle only a single stream at a time; which makes "hangout"/simulcast cases more fun (need to run HW and SW in parallel, or drop to SW only - makes capability signaling fun too; the LCD of the SW and HW codecs needs to be what you offer probably, unless you want real pain). > > Your second point is valid; hardware is useless without supporting > software. OS APIs to access codecs (both hardware and software, > real-time and buffered) is an important issue. Android is the dominant > OS on the planet. If you are not happy with its OS APIs, just change > them; it's open source like VP8 right? Not really. You can't modify the underlying OS provided by the manufacturer (no rooting of phones to run webrtc should be required...) and even custom roms are going to get much harder or virtually impossible with kitkat. And witness my comments about the pain of platform decoders on Android today. Randell > > Mo > > > On 11/5/13, 1:10 AM, cowwoc > wrote: > > > I'm not sure if you're being sarcastic or not... > > In any case, I had a question regarding BlackBerry 10. Are you > implying that every BlackBerry 10 phone includes an API for real-time > encoding/decoding of H.264 video streams? If so, which API is it? I > took a quick look but couldn't find it. > > Thanksm > Gili > > On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote: >> I think you meant *every* phone, tablet, laptop, desktop, set-top, >> camera... >> >> >> On 11/2/13, 7:41 PM, Kaiduan Xie > > wrote: >> >> Every BlackBerry 10 phone has H.264 hardware encoder/decoder. >> >> /Kaiduan >> >> >> On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla > > wrote: >> >> >> >> >> On Sat, Nov 2, 2013 at 1:01 PM, Gili > > wrote: >> >> Martin, >> >> I fully understand why Firefox would be happy but as >> someone who plan to integrate WebRTC into a non-browser >> application, especially on iOS, Cisco's solution simply does >> not work. I appreciate their contribution, but again, it >> simply doesn't help my use-case. >> >> >> I haven't seen you explain how your use case is different from >> that of >> a browser. Could you please do so? >> >> -Ekr >> >> Gili >> >> >> On 11/2/2013 11:02 AM, Martin Thomson wrote: >> >> On 2 November 2013 07:37, cowwoc > > wrote: >> >> I can't think of a single platform that supports >> real-time H.264 >> encoding/decoding natively today. >> >> That's a very strange way to put the question. >> >> Let me put another spin on it, and please excuse the >> example... >> >> Skype runs on more platforms than you might think. Those >> platforms >> can all support H.264 to the extent that Skype requires. >> >> Cisco's generous offer opens almost the same capability >> to anyone, >> with the caveat that some platforms currently remain >> closed. Of >> course, you could let your ideals get in the way of >> progress. Me, I'm >> a pragmatist. This gift represents a great opportunity >> for people who >> actually care about the practical outcomes. >> >> There's been a lot of mouth-gazing of gift horses on this >> list of >> late. I sure hope that this isn't representative of the real >> sentiment of the community. I'd like to think that >> people are better >> than that. >> >> (BTW, I understand and respect Harald's position. From >> where he sits, >> I'm sure that his conclusion makes perfect sense.) >> >> -- Randell Jesup randell-ietf@jesup.org --------------020406030208020308040501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/5/2013 12:55 AM, Mo Zanaty (mzanaty) wrote:
I’m serious. Name a device in mass production that is relevant to rtcweb but does not have H.264 hardware.

Plenty have hardware is out there that might not be optimized (or usable) for the types of arbitrary-sized, realtime simultaneous h.264 encode/decode.  Even just handling streaming decode on Android via OMX has been a year of pain for one of our engineers, because (especially before JB) the interfaces were unsupported, randomly modified/incompatible, and with lots of restrictions on what actually is supported.  Even with "perfect" API layers exposing them, the hardware layers (especially encoders) may not have the low-latency and other realtime characteristics needed, or knobs to tell them about things like packet loss reports that require IDR generation.  How many does this affect? who knows - and the API layers on top are inconsistent enough (or non-existent at the present) that it's especially hard to tell.

And many of them can handle only a single stream at a time; which makes "hangout"/simulcast cases more fun (need to run HW and SW in parallel, or drop to SW only - makes capability signaling fun too; the LCD of the SW and HW codecs needs to be what you offer probably, unless you want real pain).


Your second point is valid; hardware is useless without supporting software. OS APIs to access codecs (both hardware and software, real-time and buffered) is an important issue. Android is the dominant OS on the planet. If you are not happy with its OS APIs, just change them; it’s open source like VP8 right?

Not really.  You can't modify the underlying OS provided by the manufacturer (no rooting of phones to run webrtc should be required...)  and even custom roms are going to get much harder or virtually impossible  with kitkat.  And witness my comments about the pain of platform decoders on Android today.

   Randell


Mo


On 11/5/13, 1:10 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:


    I'm not sure if you're being sarcastic or not...

    In any case, I had a question regarding BlackBerry 10. Are you implying that every BlackBerry 10 phone includes an API for real-time encoding/decoding of H.264 video streams? If so, which API is it? I took a quick look but couldn't find it.

Thanksm
Gili

On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote:
I think you meant *every* phone, tablet, laptop, desktop, set-top, camera… 


On 11/2/13, 7:41 PM, Kaiduan Xie <kaiduanx@gmail.com> wrote:

Every BlackBerry 10 phone has H.264 hardware encoder/decoder.

/Kaiduan


On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Sat, Nov 2, 2013 at 1:01 PM, Gili <cowwoc@bbs.darktech.org> wrote:
Martin,

    I fully understand why Firefox would be happy but as someone who plan to integrate WebRTC into a non-browser application, especially on iOS, Cisco's solution simply does not work. I appreciate their contribution, but again, it simply doesn't help my use-case.

I haven't seen  you explain how your use case is different from that of
a browser. Could you please do so?

-Ekr
 
Gili


On 11/2/2013 11:02 AM, Martin Thomson wrote:
On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
     I can't think of a single platform that supports real-time H.264
encoding/decoding natively today.
That's a very strange way to put the question.

Let me put another spin on it, and please excuse the example...

Skype runs on more platforms than you might think.  Those platforms
can all support H.264 to the extent that Skype requires.

Cisco's generous offer opens almost the same capability to anyone,
with the caveat that some platforms currently remain closed.  Of
course, you could let your ideals get in the way of progress.  Me, I'm
a pragmatist.  This gift represents a great opportunity for people who
actually care about the practical outcomes.

There's been a lot of mouth-gazing of gift horses on this list of
late.  I sure hope that this isn't representative of the real
sentiment of the community.  I'd like to think that people are better
than that.

(BTW, I understand and respect Harald's position.  From where he sits,
I'm sure that his conclusion makes perfect sense.)

 


-- 
Randell Jesup
randell-ietf@jesup.org
--------------020406030208020308040501-- From lgeyser@gmail.com Tue Nov 5 08:33:50 2013 Return-Path: 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 766F021E808A for ; Tue, 5 Nov 2013 08:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 6pHiWxtSGgN3 for ; Tue, 5 Nov 2013 08:33:49 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9746921E8093 for ; Tue, 5 Nov 2013 08:33:48 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id ec20so1386131lab.16 for ; Tue, 05 Nov 2013 08:33:47 -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=LPq0ZhDcytzonOtcAnSFgRqkF2M/cx/YYXyuFBuRiAk=; b=EmL/qS1bjx6AcVw5sQw3dIboTLYuTnN+4y3UV1dD1MXUIG82nO8rS2amakE6c8MLJa wotltmzlCUOMLf0TV88wenNeRkbUW+h//4dyhpZFwMPH5NTfYTJ9fg+siiSZJC72RIFM v0xSF9gJq8tWpVYDDROBkGMwcjwvaZl0lpk91UxMw7jrFjmavZCNd+XuCc1rRTMcsSGw jqKJykFtxWezoSfO5tKxUhrhsnlfbvlJu9sy1tfXe5J7IUljR9ZbfG2qGJKeEFBExgEZ EQpXka2QZ2PMgtPV78t2QtHnfb76dTpwUvwtm3ai6S1GF6jzuT0HrreBiSI/jeUwMe8E VZAA== MIME-Version: 1.0 X-Received: by 10.152.202.167 with SMTP id kj7mr2085780lac.43.1383669226913; Tue, 05 Nov 2013 08:33:46 -0800 (PST) Received: by 10.114.168.70 with HTTP; Tue, 5 Nov 2013 08:33:46 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C2EFD0@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17C2EFD0@MCHP04MSX.global-ad.net> Date: Tue, 5 Nov 2013 18:33:46 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1135f79cc1c97104ea7098b5 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:33:50 -0000 --001a1135f79cc1c97104ea7098b5 Content-Type: text/plain; charset=ISO-8859-1 Both can't be made mandatory, because some parties would refuse to implement VP8 or H.264. This will cause negotiation failure anyway. What about a 3? 3. If you support a codec with expired IPR(such as H.261) as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. None should only be an option if 1/2/3 can't be satisfied. Actually None shouldn't even be an option, because it won't solve negotiation failure. On 5 November 2013 16:18, Hutton, Andrew wrote: > It seems to me that making both VP8 and H264 MTI might be a good option > for WebRTC in terms of maximizing interoperability and would be a better > decision coming out of this IETF meeting than no decision at all. > > Can we have some clarification as to whether any consensus call during > this week's meeting will include this option? > > Previously it was stated that the questions to be asked would be: > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > > How would we conclude that the community would like both to be made MTI? > > Regards > Andy > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1135f79cc1c97104ea7098b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Both can't be made mandatory, because some p= arties would refuse to implement VP8 or H.264. This will cause negotiation = failure anyway.
What about a 3?
3. If you support a codec with= expired IPR(such as H.261) as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

None should only be an option if 1/2/3 can't be satisfied. Actually N= one shouldn't even be an option, because it won't solve negotiation= failure.


On 5 No= vember 2013 16:18, Hutton, Andrew <andrew.hutton@unify.com> wrote:
It seems to me that making both VP8 and H264= MTI might be a good option for WebRTC in terms of maximizing interoperabil= ity and would be a better decision coming out of this IETF meeting than no = decision at all.

Can we have some clarification as to whether any consensus call during this= week's meeting will include this option?

Previously it was stated that the questions to be asked would be:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.


How would we conclude that the community would like both to be made MTI?
Regards
Andy
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a1135f79cc1c97104ea7098b5-- From bernard_aboba@hotmail.com Tue Nov 5 08:58:50 2013 Return-Path: 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 6D5E721E8089 for ; Tue, 5 Nov 2013 08:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.027 X-Spam-Level: X-Spam-Status: No, score=-102.027 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] 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 Dw4J1ec9HCzR for ; Tue, 5 Nov 2013 08:58:45 -0800 (PST) Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com [65.55.116.91]) by ietfa.amsl.com (Postfix) with ESMTP id 26CFF21F9F74 for ; Tue, 5 Nov 2013 08:58:39 -0800 (PST) Received: from BLU406-EAS413 ([65.55.116.72]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Nov 2013 08:58:39 -0800 X-TMN: [r4L2WqlmsJZ7ma0KHfjxVkdy9M4PKY7K] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_897330e2-330f-44e9-bd4f-e88e3227c412_" Date: Tue, 5 Nov 2013 08:58:36 -0800 From: Bernard Aboba To: Leon Geyser MIME-Version: 1.0 X-OriginalArrivalTime: 05 Nov 2013 16:58:39.0131 (UTC) FILETIME=[463E46B0:01CEDA48] Cc: rtcweb@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:58:50 -0000 --_897330e2-330f-44e9-bd4f-e88e3227c412_ Content-Type: multipart/alternative; boundary="_a7578fb4-f3a5-4fd9-8c14-c7ca4ec41f55_" --_a7578fb4-f3a5-4fd9-8c14-c7ca4ec41f55_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The H.261 option has been explored previously and has little or no support = from implementers. Leon Geyser wrote: Both can't be made mandatory=2C because some parties would refuse to implement VP8 or H.264. This will cause negotiation failure anyway. What about a 3? 3. If you support a codec with expired IPR(such as H.261) as the mandatory to implement codec or are willing to live with it as the MTI=2C please raise your hand now. None should only be an option if 1/2/3 can't be satisfied. Actually None shouldn't even be an option=2C because it won't solve negotiation failure. On 5 November 2013 16:18=2C Hutton=2C Andrew wrot= e: > It seems to me that making both VP8 and H264 MTI might be a good option > for WebRTC in terms of maximizing interoperability and would be a better > decision coming out of this IETF meeting than no decision at all. > > Can we have some clarification as to whether any consensus call during > this week's meeting will include this option? > > Previously it was stated that the questions to be asked would be: > > 1. If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI=2C please raise your hand now. > > 2. If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI=2C please raise your hand now. > > > How would we conclude that the community would like both to be made MTI? > > Regards > Andy > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --_a7578fb4-f3a5-4fd9-8c14-c7ca4ec41f55_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
The H.261 option has been explored previously and = has little or no support from implementers.

Leon Geyser <=3Blgeyser@gmail.com>=3B wrote:

Both can't be made mandatory=2C because some parties would refuse to i= mplement VP8 or H.264. This will cause negotiation failure anyway.
What about a 3?
3. If you support a codec with expired IPR(such as H.261) as the mandatory = to implement codec or are
willing to live with it as the MTI=2C please raise your hand now.

None should only be an option if 1/2/3 can't be satisfied. Actually None sh= ouldn't even be an option=2C because it won't solve negotiation failure.


On 5 November 2013 16:18=2C Hutton=2C Andrew <= span dir=3D"ltr"> <=3Bandrew.h= utton@unify.com>=3B wrote:
It seems to me that making both VP8 and H264 MTI might be a good option for= WebRTC in terms of maximizing interoperability and would be a better decis= ion coming out of this IETF meeting than no decision at all.

Can we have some clarification as to whether any consensus call during this= week's meeting will include this option?

Previously it was stated that the questions to be asked would be:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI=2C please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI=2C please raise your hand now.


How would we conclude that the community would like both to be made MTI?
Regards
Andy
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--_a7578fb4-f3a5-4fd9-8c14-c7ca4ec41f55_-- --_897330e2-330f-44e9-bd4f-e88e3227c412_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_897330e2-330f-44e9-bd4f-e88e3227c412_-- From wolfgang.beck01@googlemail.com Tue Nov 5 09:06:28 2013 Return-Path: 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 1915D11E80D9 for ; Tue, 5 Nov 2013 09:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 wbc88uDn1KRW for ; Tue, 5 Nov 2013 09:06:27 -0800 (PST) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id BDE0511E8119 for ; Tue, 5 Nov 2013 09:06:26 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id o19so2561816vbm.35 for ; Tue, 05 Nov 2013 09:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=03uHyGULlOdYt1sldENfjRVWmjRoGhWrpvwkzfJsq84=; b=H/8v8WsRSBWeFU/AHF63vEf06XYA2GyKMyYyJRRle2R+P7duINBPqx+npF83YjBNgI aGk6ydHkHGvD92j0Y/MhNIiRivUyAvdfzmGwLiY7BgzZqzB5ShIapQRpa+FWwDqCX097 Q6KSGbjeWfSWO4+nEr6Gs8qt1RjUNrKwzR57hIzBYpzIS54cwhPvSt5ieqRJvsmv4Iux SxVbcQT9AlXSl19K7IOc7jODZDcznaogs4zzjVnuHLwvothI6jzMvkSKtE5vUEt1k8B7 xPwlAn1O02PUtFb8TPLl3cPHlYesyu1x7kTNAO9fn3FIxOFNNXQ4yM816UuiVv4Zrowj KY0A== MIME-Version: 1.0 X-Received: by 10.220.144.80 with SMTP id y16mr16332229vcu.4.1383671185573; Tue, 05 Nov 2013 09:06:25 -0800 (PST) Received: by 10.58.45.169 with HTTP; Tue, 5 Nov 2013 09:06:25 -0800 (PST) Date: Tue, 5 Nov 2013 18:06:25 +0100 Message-ID: From: Wolfgang Beck To: "" Content-Type: multipart/alternative; boundary=047d7b343974808bc904ea710d05 Subject: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 17:06:28 -0000 --047d7b343974808bc904ea710d05 Content-Type: text/plain; charset=ISO-8859-1 What I am missing in this draft is the link between authentication towards the web server and signing of DTLS info towards the remote party. To make a call, a user will have to 1) log into the web server application 2) permit the browser to access camera/mic 3) log into the IdP to sign the DTLS info To receive a call, I will have to 1) log into the web server application 2) permit the browser to access camera/mic when there is a call 3) log into the IdP to sign the DTLS info ..and hope the caller has not given up before I clicked all permission boxes and entered all user credentials. Can 1) and 3) be merged somehow? How would you explain 3) to a user? Wolfgang Beck --047d7b343974808bc904ea710d05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What I am missing in this dr= aft is the link between authentication towards the web server and signing o= f DTLS info towards the remote party. To make a call, a user will have to
1) log into the web server application
2) permit the browser= to access camera/mic
3) log into the IdP to sign the DTLS info
To receive a call, I will have to
1) log into the web s= erver application
2) permit the browser to access camera/mic when there is a call<= br>
3) log into the IdP to sign the DTLS info
..and= hope the caller has not given up before I clicked all permission boxes and= entered all user credentials.

Can 1) and 3) be merged somehow? How would you explain 3) to= a user?


Wolfgang Beck

--047d7b343974808bc904ea710d05-- From mzanaty@cisco.com Tue Nov 5 09:12:29 2013 Return-Path: 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 6D31E11E8178 for ; Tue, 5 Nov 2013 09:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.132 X-Spam-Level: X-Spam-Status: No, score=-10.132 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] 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 Cl6Ybbe8CKcT for ; Tue, 5 Nov 2013 09:12:24 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C45B411E817A for ; Tue, 5 Nov 2013 09:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5398; q=dns/txt; s=iport; t=1383671540; x=1384881140; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=rgvVbrpzfvaLY4slUITf8lcEc1racqR9nrNjqnW4kSU=; b=YzOu88VnaC7nlCggfZ/f7hL4LPiNu+3/EK5EKet0SdAbH3sZqJ/+2Mdb plwG7ro8sao/MplLragFH7i9Z7y5hrWWVSa4z+zw0RispwudMb5+mVhpH AdbZWXUzeHEUw2rjYjA+hHFF72mOhfDEzR8b/sADHftZS69pqDAkuxh6K w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAMEleVKtJV2Z/2dsb2JhbABZgkNEOFO+bUuBLBZ0gicBBAEBAWsdAQgECjEoBgsUEQIEARIUh1sDDw20eA2JZwSMZ4JuC4QvA5YfgWuMUoU3gyaCKg X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208,217";a="280971831" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2013 17:12:14 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA5HCEX9014435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 17:12:14 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 11:12:13 -0600 From: "Mo Zanaty (mzanaty)" To: Leon Geyser , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Making both VP8 and H264 MTI Thread-Index: AQHO2korzslk1I1xbU+9ODKbbBKnhQ== Date: Tue, 5 Nov 2013 17:12:12 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.253.154] Content-Type: multipart/alternative; boundary="_000_CE9E89B31BE14mzanatyciscocom_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:12:29 -0000 --_000_CE9E89B31BE14mzanatyciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any implementation can refuse to implement any MTI, whether it is 1 or 2. I= see more good than harm by mandating both. We mandated Opus and G.711, rig= ht? Did anyone complain that 2 MTIs would increase the chance of negotiatio= n failure? Forcing a binary MTI decision suggests an intent to let one live= and kill the other. Live and let live... Mo On 11/5/13, 11:33 AM, Leon Geyser > wrote: Both can't be made mandatory, because some parties would refuse to implemen= t VP8 or H.264. This will cause negotiation failure anyway. What about a 3? 3. If you support a codec with expired IPR(such as H.261) as the mandatory = to implement codec or are willing to live with it as the MTI, please raise your hand now. None should only be an option if 1/2/3 can't be satisfied. Actually None sh= ouldn't even be an option, because it won't solve negotiation failure. On 5 November 2013 16:18, Hutton, Andrew > wrote: It seems to me that making both VP8 and H264 MTI might be a good option for= WebRTC in terms of maximizing interoperability and would be a better decis= ion coming out of this IETF meeting than no decision at all. Can we have some clarification as to whether any consensus call during this= week's meeting will include this option? Previously it was stated that the questions to be asked would be: 1. If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 2. If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. How would we conclude that the community would like both to be made MTI? Regards Andy _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CE9E89B31BE14mzanatyciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Any implementation can refuse to implement any MTI, whether it is 1 or= 2. I see more good than harm by mandating both. We mandated Opus and G.711= , right? Did anyone complain that 2 MTIs would increase the chance of negot= iation failure? Forcing a binary MTI decision suggests an intent to let one live and kill the other. Live a= nd let live...

Mo


On 11/5/13, 11:33 AM, Leon Geyser <lgeyser@gmail.com> wrote:

Both can't be made mandatory, because some parties would refuse to imp= lement VP8 or H.264. This will cause negotiation failure anyway.
What about a 3?
3. If you support a codec with expired IPR(such as H.261) as the mandatory = to implement codec or are
willing to live with it as the MTI, please raise your hand now.

None should only be an option if 1/2/3 can't be satisfied. Actually None sh= ouldn't even be an option, because it won't solve negotiation failure.


On 5 November 2013 16:18, Hutton, Andrew <andrew.hut= ton@unify.com> wrote:
It seems to me that making both VP8 and H264 MTI might be a good option for= WebRTC in terms of maximizing interoperability and would be a better decis= ion coming out of this IETF meeting than no decision at all.

Can we have some clarification as to whether any consensus call during this= week's meeting will include this option?

Previously it was stated that the questions to be asked would be:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.


How would we conclude that the community would like both to be made MTI?
Regards
Andy
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

 --_000_CE9E89B31BE14mzanatyciscocom_-- From lgeyser@gmail.com Tue Nov 5 09:21:53 2013 Return-Path: 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 D5C7C21E80F8 for ; Tue, 5 Nov 2013 09:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 G7hsbBjIPQtv for ; Tue, 5 Nov 2013 09:21:53 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9441C11E8133 for ; Tue, 5 Nov 2013 09:21:52 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id w6so6874267lbh.13 for ; Tue, 05 Nov 2013 09:21:51 -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=8q/tk4XdE3D7TNYSlP3TzloatHQ9HIYsED+WPayICuU=; b=aQUxyJ3T62GKgZ9ZFwE4aCLf8tVkwGxV+4auJeTA0wAxaz8i6DZnMddojfQ19TA2Ri mVRw3keUKglTNkhk+tXNFNOSAqYGY8bqbXnEU7b3mIh+G3T2e6eKKSFtHmBLIGKOvseg /15uRZAaE62OETioE9LiPoqXoA3hfC68VFP2DRXocboeLJ653RyTq+oy0dD7St4KpjDR x/NqkS/3/11nxkjmVVkBgZmBYdn4Eg6+xhselSlB+4JhBP9HfWnty9+4Xyaf/7uAGrvu REgEsQRrYtDRA/6uvzMjnYdNYJasFQlHNl4/IvA5RmwTfAQdkDoRbQnF+5o17xOl6YwJ EcbA== MIME-Version: 1.0 X-Received: by 10.112.143.138 with SMTP id se10mr9536841lbb.26.1383672111188; Tue, 05 Nov 2013 09:21:51 -0800 (PST) Received: by 10.114.168.70 with HTTP; Tue, 5 Nov 2013 09:21:51 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Nov 2013 19:21:51 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e01182830ac4fc204ea7144d8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:21:54 -0000 --089e01182830ac4fc204ea7144d8 Content-Type: text/plain; charset=ISO-8859-1 >>Any implementation can refuse to implement any MTI, whether it is 1 or 2. I see more good than harm by mandating both. Mandating 2 is just as good as mandating 0. I just don't get the logic of mandating 2. >>We mandated Opus and G.711, right? Did anyone complain that 2 MTIs would increase the chance of negotiation failure? I disagree. Completely different situation. G.711 is there, because it has NO IPR issues and can be implemented in like +/- 10 lines of code. Nice for testing and has NO IPR issues. Both are royalty free codecs btw. On 5 November 2013 19:12, Mo Zanaty (mzanaty) wrote: > Any implementation can refuse to implement any MTI, whether it is 1 or > 2. I see more good than harm by mandating both. We mandated Opus and G.711, > right? Did anyone complain that 2 MTIs would increase the chance of > negotiation failure? Forcing a binary MTI decision suggests an intent to > let one live and kill the other. Live and let live... > > Mo > > > On 11/5/13, 11:33 AM, Leon Geyser wrote: > > Both can't be made mandatory, because some parties would refuse to > implement VP8 or H.264. This will cause negotiation failure anyway. > What about a 3? > 3. If you support a codec with expired IPR(such as H.261) as the mandatory > to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > None should only be an option if 1/2/3 can't be satisfied. Actually None > shouldn't even be an option, because it won't solve negotiation failure. > > > On 5 November 2013 16:18, Hutton, Andrew wrote: > >> It seems to me that making both VP8 and H264 MTI might be a good option >> for WebRTC in terms of maximizing interoperability and would be a better >> decision coming out of this IETF meeting than no decision at all. >> >> Can we have some clarification as to whether any consensus call during >> this week's meeting will include this option? >> >> Previously it was stated that the questions to be asked would be: >> >> 1. If you support H.264 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> 2. If you support VP8 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> >> How would we conclude that the community would like both to be made MTI? >> >> Regards >> Andy >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --089e01182830ac4fc204ea7144d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>Any implementation can refuse to implement an= y MTI, whether it is 1 or 2. I see more good than harm by mandating both.
Mandating 2 is just as good as mandating 0. I just don't get th= e logic of mandating 2.

>>We mandated Opus and G.711, right? Did anyone complai= n that 2 MTIs would increase the chance of negotiation failure?
I disagr= ee. Completely different situation. G.711 is there, because it has NO IPR i= ssues and can be implemented in like +/- 10 lines of code. Nice for testing= and has NO IPR issues. Both are royalty free codecs btw.

On 5 November 201= 3 19:12, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Any implementation can refuse to implement any MTI, whether it is 1 or= 2. I see more good than harm by mandating both. We mandated Opus and G.711= , right? Did anyone complain that 2 MTIs would increase the chance of negot= iation failure? Forcing a binary MTI decision suggests an intent to let one live and kill the other. Live a= nd let live...

Mo


On 11/5/13, 11:33 AM, Leon Geyser <lgeyser@gmail.com> wrote:

Both can't be made mandatory, because some parties would refuse to= implement VP8 or H.264. This will cause negotiation failure anyway.
What about a 3?
3. If you support a codec with expired IPR(such as H.261) as the mandatory = to implement codec or are
willing to live with it as the MTI, please raise your hand now.

None should only be an option if 1/2/3 can't be satisfied. Actually Non= e shouldn't even be an option, because it won't solve negotiation f= ailure.


On 5 November 2013 16:18, Hutton, Andrew <andrew.hut= ton@unify.com> wrote:
It seems to me that making both VP8 and H264 MTI might be a good option for= WebRTC in terms of maximizing interoperability and would be a better decis= ion coming out of this IETF meeting than no decision at all.

Can we have some clarification as to whether any consensus call during this= week's meeting will include this option?

Previously it was stated that the questions to be asked would be:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.


How would we conclude that the community would like both to be made MTI?
Regards
Andy
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--089e01182830ac4fc204ea7144d8-- From wolfgang.beck01@googlemail.com Tue Nov 5 09:24:02 2013 Return-Path: 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 296F521E80F8 for ; Tue, 5 Nov 2013 09:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 uMIkCYpCQIUe for ; Tue, 5 Nov 2013 09:24:01 -0800 (PST) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 037E321E80F3 for ; Tue, 5 Nov 2013 09:24:00 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id db12so2794510veb.9 for ; Tue, 05 Nov 2013 09:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QAEMSaT+kT2MohC9tlRJuzs0VLMECmN9ybq3ugCP7Gw=; b=Q3VUrWC5dtyiApzhfOnl8x4FmDRAht+eKIolQ8wY9gziGBxoqV+s6x6km0thBknW8G XcJXQxTdLloDZsCjYUraVmBosWt420KJKHqrkeTAQrNlpvda4Yfbn3trtvqVMCvb2fKx e+CAqFY9FsapX3sxsaNChiVHUoMUEgMID6EPUwJx9Rx5n19T52swL2JKboAccjgwlH7k PDhlNAB17+b9PTeAT0xJ6ngSixtMnVzW0K7mnnQFkMz+sV31uvAAjUhzsHB3UK0bPKDn 97xSOcVt8GfgU98v4E3Wc1Jby4szNwG7rOBJ4lrL23M7QeWu41avs8Q/A/FQb/A7eAfb 6aTg== MIME-Version: 1.0 X-Received: by 10.58.144.168 with SMTP id sn8mr728884veb.33.1383672238971; Tue, 05 Nov 2013 09:23:58 -0800 (PST) Received: by 10.58.45.169 with HTTP; Tue, 5 Nov 2013 09:23:58 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Nov 2013 18:23:58 +0100 Message-ID: From: Wolfgang Beck To: "Mo Zanaty (mzanaty)" Content-Type: multipart/alternative; boundary=047d7b5da93b4a209c04ea714c1d Cc: "rtcweb@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:24:02 -0000 --047d7b5da93b4a209c04ea714c1d Content-Type: text/plain; charset=ISO-8859-1 H.264 for legacy interop, VP8 for the use cases where the MPEG LA's licensing conditions might get into the way of a novel service.. sounds like a good compromise. Of course this moves the complexity from the network (video transcoding gateways) into the browser. As transcoding gateways don't scale well, I'd prefer the browser support for both codecs. Wolfgang Beck On Tue, Nov 5, 2013 at 6:12 PM, Mo Zanaty (mzanaty) wrote: > Any implementation can refuse to implement any MTI, whether it is 1 or > 2. I see more good than harm by mandating both. We mandated Opus and G.711, > right? Did anyone complain that 2 MTIs would increase the chance of > negotiation failure? Forcing a binary MTI decision suggests an intent to > let one live and kill the other. Live and let live... > > Mo > > > On 11/5/13, 11:33 AM, Leon Geyser wrote: > > Both can't be made mandatory, because some parties would refuse to > implement VP8 or H.264. This will cause negotiation failure anyway. > What about a 3? > 3. If you support a codec with expired IPR(such as H.261) as the mandatory > to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > None should only be an option if 1/2/3 can't be satisfied. Actually None > shouldn't even be an option, because it won't solve negotiation failure. > > > On 5 November 2013 16:18, Hutton, Andrew wrote: > >> It seems to me that making both VP8 and H264 MTI might be a good option >> for WebRTC in terms of maximizing interoperability and would be a better >> decision coming out of this IETF meeting than no decision at all. >> >> Can we have some clarification as to whether any consensus call during >> this week's meeting will include this option? >> >> Previously it was stated that the questions to be asked would be: >> >> 1. If you support H.264 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> 2. If you support VP8 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> >> How would we conclude that the community would like both to be made MTI? >> >> Regards >> Andy >> _______________________________________________ >> 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 > > --047d7b5da93b4a209c04ea714c1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
H.264 for legacy interop, VP8 for the use cases where= the MPEG LA's licensing conditions might get into the way of a novel s= ervice.. sounds like a good compromise. Of course this moves the complexity= from the network (video transcoding gateways) into the browser. As transco= ding gateways don't scale well, I'd prefer the browser support for = both codecs.

Wolfgang Beck


On Tue, Nov 5, 2013 at 6:12 PM, Mo Zanaty (mzanaty) <m= zanaty@cisco.com> wrote:
Any implementation can refuse to implement any MTI, whether it is 1 or= 2. I see more good than harm by mandating both. We mandated Opus and G.711= , right? Did anyone complain that 2 MTIs would increase the chance of negot= iation failure? Forcing a binary MTI decision suggests an intent to let one live and kill the other. Live a= nd let live...

Mo


On 11/5/13, 11:33 AM, Leon Geyser <lgeyser@gmail.com> wrote:

Both can't be made mandatory, because some parties would refuse to= implement VP8 or H.264. This will cause negotiation failure anyway.
What about a 3?
3. If you support a codec with expired IPR(such as H.261) as the mandatory = to implement codec or are
willing to live with it as the MTI, please raise your hand now.

None should only be an option if 1/2/3 can't be satisfied. Actually Non= e shouldn't even be an option, because it won't solve negotiation f= ailure.


On 5 November 2013 16:18, Hutton, Andrew <andrew.hut= ton@unify.com> wrote:
It seems to me that making both VP8 and H264 MTI might be a good option for= WebRTC in terms of maximizing interoperability and would be a better decis= ion coming out of this IETF meeting than no decision at all.

Can we have some clarification as to whether any consensus call during this= week's meeting will include this option?

Previously it was stated that the questions to be asked would be:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.


How would we conclude that the community would like both to be made MTI?
Regards
Andy
_______________________________________________
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


--047d7b5da93b4a209c04ea714c1d-- From mzanaty@cisco.com Tue Nov 5 09:27:49 2013 Return-Path: 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 9021E11E81DE for ; Tue, 5 Nov 2013 09:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 0P+jjDoaNXbH for ; Tue, 5 Nov 2013 09:27:40 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 88AF311E81CD for ; Tue, 5 Nov 2013 09:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=967; q=dns/txt; s=iport; t=1383672458; x=1384882058; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=W5+b3LCjdaN8g5q7biC8wELC26zAWogu4XmHKZYTjoA=; b=HbfgeRtvJa8DOzC67GzRYI4fj8CCfKK2eLiOngBOp9TDeyteMEVt28ay Kx/+m4HMh/7CgzlCm8uzVirKkpsHSjxTTNjrceznskp4rHeHaVsCnHSPB l8VF4VxZ39iDVkTYN+VBjeCIZ3eGKjxyJpq6cDVe8k58+Jh9RIclA0bKC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADcqeVKtJV2d/2dsb2JhbABZgwc4U75tS4EsFnSCJQEBAQQBAQE3NAsSAQgYHjEGCyUCBAENBRSHWwMPDbR3DYlnBIxngnIHhC8Dlh+Ba4xShTeDJoIq X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208";a="280992688" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 05 Nov 2013 17:27:16 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA5HRGtO030615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 17:27:16 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 11:27:15 -0600 From: "Mo Zanaty (mzanaty)" To: Martin Thomson , "Hutton, Andrew" , "'Magnus Westerlund'" , "Cullen Jennings (fluffy)" , Ted Hardie Thread-Topic: [rtcweb] Making both VP8 and H264 MTI Thread-Index: AQHO2kxFGh+JzgPRUEOKvqjNfmPjeg== Date: Tue, 5 Nov 2013 17:27:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.253.154] Content-Type: text/plain; charset="us-ascii" Content-ID: <85BAA397AE99C8459120763F8417F7E5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:27:50 -0000 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 wrote: On 5 November 2013 06:18, Hutton, Andrew 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 From fluffy@cisco.com Tue Nov 5 09:45:10 2013 Return-Path: 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 3B89C11E816F for ; Tue, 5 Nov 2013 09:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.581 X-Spam-Level: X-Spam-Status: No, score=-110.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 WlDYdmqBocR5 for ; Tue, 5 Nov 2013 09:45:04 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 86BCD11E81FD for ; Tue, 5 Nov 2013 09:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2074; q=dns/txt; s=iport; t=1383673476; x=1384883076; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=C/JOhyYBYpY19BLbLosbXOTf4zHvwUblYO1/EXkbhxo=; b=Csqe0Cm6TGzdhugtLwdggcI0v+LKYoQPLyaVJYViZrecXHn2rYlLcWJH oC0jYWillM4IXRpzVgte5an0SYELGj7LfqiGSEJKEH/pdeKjEdBtIKK52 cTTeAnH62HUVEY/XDwPBYT8eNIS+wtrDeS2qHN1a/rOvS2L+aBHzH/fkG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEGAD0teVKtJV2c/2dsb2JhbABZgwc4U75tS4EsFm0HgiUBAQEDAQEBATc0CwULAgEIGB4QIQYLJQIEDgUUh1sDCQYNtHUNiWcEjGeCPzMHgyCBDwOWH4FrjFKFN4Mmgio X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208";a="278002950" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 05 Nov 2013 17:44:29 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA5HiTWF020766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 17:44:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 11:44:28 -0600 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Making both VP8 and H264 MTI Thread-Index: AQHO2kxFGh+JzgPRUEOKvqjNfmPjepoXThOA Date: Tue, 5 Nov 2013 17:44:28 +0000 Message-ID: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.120.246] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:45:10 -0000 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 f= eel ready to discuss in the thursday meeting.=20 I will note that in the past when this idea was discussed, the people who w= ere concerned about IPR for either codec pointed out that this could only i= ncreased, not decreased, the IPR concerns.=20 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 wi= ll 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 re= ally better if people actually honestly answer the question in a consensus = call instead gaming the system.=20 Cullen - Just one of the chairs and I hope my co-chairs add more but they a= re both in meetings right now On Nov 5, 2013, at 9:27 AM, "Mo Zanaty (mzanaty)" 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 likelihoo= d > of an alternative process, I will only support one (despite objecting to > being forced to support only one). >=20 > Mo >=20 >=20 > On 11/5/13, 9:46 AM, Martin Thomson wrote: >=20 > On 5 November 2013 06:18, Hutton, Andrew wrote: >> How would we conclude that the community would like both to be made MTI? >=20 >=20 > 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 >=20 From cowwoc@bbs.darktech.org Tue Nov 5 10:01:53 2013 Return-Path: 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 B7FC221F9E51 for ; Tue, 5 Nov 2013 10:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 PEfc-XBp8bpC for ; Tue, 5 Nov 2013 10:01:47 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 11A8211E8127 for ; Tue, 5 Nov 2013 10:01:43 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id aq17so15105880iec.6 for ; Tue, 05 Nov 2013 10:01:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NjLvaV6+r+g5uZFT2mKqQUFZwP5kJN7Uu7BqKJ3GfEg=; b=TylbTgKWoy2OQJ3gPNv0wwGGAQ1wpBLucLp6d75YF7nht9PCe5nY1XQ1f7DgVXxN8z wpk8AXJGsLJRYa2K/1bhzQthwJngGgXx9KuV8p4TxdzRMu0N4G01jp9Tt9dcywLXQFBk iqF6kWYG/wk6oIBbXQMOF/YASt9RWWKUNgu++V+ZLtmobXHOqvOyCN/B0sQWh0YVC5qR oluf2zDB4696CFq7vBycRu3rU2ShncB6/XwTPydWwa6KYbHSXITlq2kn04+Zl42McvlT JSYMHaGb8QLVrHHQXJSRMyy+WC2MGknK7gbvakKXsd7y8HnC7QA5VASQpbZHGKvSjzrp zNHw== X-Gm-Message-State: ALoCoQmqJ/p8CIBo0ElKqSwj6OXF9MbkXgDLYAEldXhmATEO5udblb26815/OYKGCFN6jx4ZIYxq X-Received: by 10.50.30.66 with SMTP id q2mr9038392igh.17.1383674503145; Tue, 05 Nov 2013 10:01:43 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id c14sm8760309ign.0.2013.11.05.10.01.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 10:01:42 -0800 (PST) Message-ID: <52793283.3020809@bbs.darktech.org> Date: Tue, 05 Nov 2013 13:01:39 -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: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:01:53 -0000 On 05/11/2013 12:21 PM, Leon Geyser wrote: > >>Any implementation can refuse to implement any MTI, whether it is 1 > or 2. I see more good than harm by mandating both. > Mandating 2 is just as good as mandating 0. I just don't get the logic > of mandating 2. If new IPR issues bubble up for H.264 or VP8 we're free to drop one of the MTI codecs and fallback on the other. If we only have a single MTI codec, we have no way to drop it and therefore we're forced to pay royalties to whomever decided to sue. Gili From cowwoc@bbs.darktech.org Tue Nov 5 10:04:08 2013 Return-Path: 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 92C6A21E80BA for ; Tue, 5 Nov 2013 10:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.571 X-Spam-Level: X-Spam-Status: No, score=-4.571 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SuB5DtPEw6O4 for ; Tue, 5 Nov 2013 10:03:56 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id EDA5E11E815C for ; Tue, 5 Nov 2013 10:02:46 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id ar20so15965588iec.0 for ; Tue, 05 Nov 2013 10:02:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4xviesyuasAe/YvUqEwJ94NICs/VJBKmuJJd+W2sYlg=; b=e2K+lMQTJ5Z1nrHdF9gdq0zLVPG6qMdGwr1TnvFlyjYI24D1DEOF4B+huSlJ0BDB/N LWYy2aJOKnwwACmikta78Fz5rItysjn2SoWk1T4MCCOe6k8KuhCoIo9CvrPTkzwNj2kB 4wujuwL0EPztAWb7Z2lAR1EC5BBAgFDiNOxaIpM2Udc3n91fVK4ZM5nThY+IUHC/JIHg ieWCB26sU74o1NrK9S4vLjZo0VSLChuQIMIk8XwrjPXdJ9oIcws/i7MsufU6KUMMu4pm I68/4lySYC6H3dRkUNhosN18joAfLJiZvVJ8fDplN275yqVlVKBnRXb2vlQISBRt2/Dc ANWA== X-Gm-Message-State: ALoCoQlYvFpNaKQeUTGlzJ0olFmjdBed9ymgF9/vmK9CY5Tg76NCPM6H7xTig5nM5xzElpcLM49y X-Received: by 10.50.30.229 with SMTP id v5mr16858908igh.27.1383674556040; Tue, 05 Nov 2013 10:02:36 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id l7sm9569617igx.2.2013.11.05.10.02.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 10:02:35 -0800 (PST) Message-ID: <527932B9.6090502@bbs.darktech.org> Date: Tue, 05 Nov 2013 13:02:33 -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: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:04:08 -0000 On 05/11/2013 12:23 PM, Wolfgang Beck wrote: > H.264 for legacy interop, VP8 for the use cases where the MPEG LA's > licensing conditions might get into the way of a novel service.. > sounds like a good compromise. Of course this moves the complexity > from the network (video transcoding gateways) into the browser. As > transcoding gateways don't scale well, I'd prefer the browser support > for both codecs. You're always free to use H.264 for legacy interop. I don't see why this means it should be MTI (forcing everyone to pay a license or jump through distribution loopholes). Gili From cowwoc@bbs.darktech.org Tue Nov 5 10:07:05 2013 Return-Path: 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 E7F7C21E809D for ; Tue, 5 Nov 2013 10:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.545 X-Spam-Level: X-Spam-Status: No, score=-4.545 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1hXVYJibejG9 for ; Tue, 5 Nov 2013 10:06:52 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id C99CC21E80EB for ; Tue, 5 Nov 2013 10:06:34 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id qd12so15437500ieb.5 for ; Tue, 05 Nov 2013 10:06:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8+k5IvjN8ZuPmY2olnUXkzZDUHC1ZicIcSVoLHtUVqk=; b=mHDk0VY6AjPLtOEEK/LSPADnLtSANw/W1IZsRxEh2f3XbjNIYfmPGT3qP9HVJCoDPs drEXH/bIvtiDKIU26pMZ/epPVdoKGS2gBEOX7EMaZVJ2pvsxRmVmT/DKEzpyxsLman/r bVcu30OIsRR7kytmNHv0mt1gU3rRPkEYOmLqIp6Cf1yIOfUYUzrZTDjLyyO7zJjTPMOS rixe9hjHuxdBkLNrqHppN09WpHDMTLv3E49L7MMB1bmht0YMn5PKmlSacS4BnqossPjX eOpcqKWe2HDmaSquN9IVQPw3HglzbVGBTJVf3WyvN3jIKF75nDERBvUBLfODVtfDc1pX OXSw== X-Gm-Message-State: ALoCoQnwFhQpCVTmNwbqgJR2zsbmxHW6MxYkh3PwSfcNTe7d3OMPKDUZoEWmmgrvApJU/9C+bwpf X-Received: by 10.43.60.139 with SMTP id ws11mr14023775icb.12.1383674782691; Tue, 05 Nov 2013 10:06:22 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ka5sm9585364igb.2.2013.11.05.10.06.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 10:06:21 -0800 (PST) Message-ID: <5279339B.9040506@bbs.darktech.org> Date: Tue, 05 Nov 2013 13:06:19 -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: rtcweb@ietf.org References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> In-Reply-To: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:07:05 -0000 X-List-Received-Date: Tue, 05 Nov 2013 18:07:05 -0000 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)" > 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 wrote: >> >> On 5 November 2013 06:18, Hutton, Andrew 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 From martin.thomson@gmail.com Tue Nov 5 10:56:20 2013 Return-Path: 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 9F24021E80B0 for ; Tue, 5 Nov 2013 10:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, 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 sveZy-jF26sH for ; Tue, 5 Nov 2013 10:56:19 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9289521E809F for ; Tue, 5 Nov 2013 10:56:19 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id ez12so2573724wid.9 for ; Tue, 05 Nov 2013 10:56:18 -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=kwyIPNDuHUsEMVxGgD+XwJo6Oy7xVxYME08bgF/1KYE=; b=uUCzN6K06pm3gSMc5uK8owsbuSv0shIafRCONZOpl3dqMlgOZtewRNgLip2rGLnMxs 3nTyhQNiIa1dVYUlBAftCFUOzaCHNZtNa+NTmF5kM88nXst4mqDY3rd6A0OjsOvm2EM9 EYls/LXspemmw2r/xbeFkjOiraz2qeBbxHnnKG5hHM7ENihPMISADPVayh832JRYs7qu QXcq8hHMvTFxfpRK9o+FjWd4heehUPXzM8qP0/tTufW485Y/xjM47dVgAm4OBeGASGgJ TGyv6h/pKqa0cUXuFKCpT/GkVRoNWkukErg7tgfb+rbk/gReH2ne0r+8XBzD23gdVK7s 7GMA== MIME-Version: 1.0 X-Received: by 10.180.9.139 with SMTP id z11mr18107765wia.22.1383677778694; Tue, 05 Nov 2013 10:56:18 -0800 (PST) Received: by 10.227.202.194 with HTTP; Tue, 5 Nov 2013 10:56:18 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Nov 2013 10:56:18 -0800 Message-ID: From: Martin Thomson To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 18:56:20 -0000 Most of the heavy login-related interactions can be moved earlier in the process. That is, before the call commences. Keep in mind that you are sitting on a page, logged in to the site of choice, when you are making or receiving a call. On 5 November 2013 09:06, Wolfgang Beck wrote: > What I am missing in this draft is the link between authentication towards > the web server and signing of DTLS info towards the remote party. To make a > call, a user will have to > 1) log into the web server application > 2) permit the browser to access camera/mic > 3) log into the IdP to sign the DTLS info > > To receive a call, I will have to > 1) log into the web server application > 2) permit the browser to access camera/mic when there is a call > 3) log into the IdP to sign the DTLS info > ..and hope the caller has not given up before I clicked all permission boxes > and entered all user credentials. > > Can 1) and 3) be merged somehow? How would you explain 3) to a user? > > > Wolfgang Beck > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From mail@makk.es Tue Nov 5 12:58:37 2013 Return-Path: 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 18F2D11E8196 for ; Tue, 5 Nov 2013 12:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 MxhPnBDQ87N7 for ; Tue, 5 Nov 2013 12:58:31 -0800 (PST) Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id CC8A111E815B for ; Tue, 5 Nov 2013 12:58:29 -0800 (PST) Received: (qmail 14020 invoked from network); 5 Nov 2013 20:58:26 -0000 Received: from unknown (HELO ?192.168.0.20?) (31.18.104.182) by lupus.uberspace.de with SMTP; 5 Nov 2013 20:58:26 -0000 Message-ID: <52795BF0.1020207@makk.es> Date: Tue, 05 Nov 2013 21:58:24 +0100 From: Max Jonas Werner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Wolfgang Beck , "" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxQs5SHU05kxwCCSa2SLfweJQ9bMF8wP" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 20:58:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EuxQs5SHU05kxwCCSa2SLfweJQ9bMF8wP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wolfgang, On 05.11.2013 18:06, Wolfgang Beck wrote: > What I am missing in this draft is the link between authentication towa= rds > the web server and signing of DTLS info towards the remote party. To ma= ke a > call, a user will have to > 1) log into the web server application > 2) permit the browser to access camera/mic > 3) log into the IdP to sign the DTLS info >=20 > To receive a call, I will have to > 1) log into the web server application > 2) permit the browser to access camera/mic when there is a call > 3) log into the IdP to sign the DTLS info > ..and hope the caller has not given up before I clicked all permission > boxes and entered all user credentials. >=20 > Can 1) and 3) be merged somehow? How would you explain 3) to a user? 1) and 3) can be merged if a) the user is already logged from the IdP's point of view prior to even visiting the site (using either built-in browser logic or manually) or b) the IdP is the able to identify the user from step 1) somehow (e.g. when the web server is run by the IdP). Keep in mind, though, that the user to be able to provide an identity to the other WebRTC peer that is different from the identity of step 1) is exactly what the user wants sometimes. Max --EuxQs5SHU05kxwCCSa2SLfweJQ9bMF8wP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFSeVvw1IVn4/X13N8RAkYqAJ9HwFRkgCOdsS6ouLyphzO+cVmFCQCdHkWx MLYkxPJkXJmjeEID05824iw= =fB2d -----END PGP SIGNATURE----- --EuxQs5SHU05kxwCCSa2SLfweJQ9bMF8wP-- From mohammedsraad@raadtech.com Tue Nov 5 13:31:51 2013 Return-Path: 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 3DAFE11E80E3 for ; Tue, 5 Nov 2013 13:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 j8O7vycE3IYm for ; Tue, 5 Nov 2013 13:31:47 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 53FD711E8103 for ; Tue, 5 Nov 2013 13:31:41 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id ex4so3974000wid.5 for ; Tue, 05 Nov 2013 13:31:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Uc8K6MZ+debrHMFFyN1QVZ9GZP7fgHO6c2ZcoNhf3Gk=; b=UXokOgTDr+zq98YK8zcOHEAN2lYHI4NQ21XHPjRJBZAtZeNi+JicbXuCJazRZxqD/h PTVpKZgmvsseIgCRtI7Y7BSRqRiO8RQ/dAts3os1OI70A+GSuSpn1bfhl4OiJT4XfyjA oQ/mrbnV0LChqpTSF4owdLQR+pQkCnvPecLf9G7QFlXLO1eP/7uzK5dBrDoVWEcW4xXS zsYetXIsvhe5Gp9VqC5yeX1p1TYDRGSATQaYXly6vwJ+Cn/NNInLFaltjZw7q2c5/Xex jApA7NzgDEHiOQIwIXI+KPcTDrXfvAxE24zgFf4ZXP8G6wH/KgrQ0WLc+oiFD9pitJdo g83Q== X-Gm-Message-State: ALoCoQkH1+iY7VvR6aBhuLfVxypYKWTymTpONBur3tAhuOUrKzgRK2t8ApZ9cW0vwE973Fe4hKA2 MIME-Version: 1.0 X-Received: by 10.180.76.196 with SMTP id m4mr379672wiw.59.1383687101058; Tue, 05 Nov 2013 13:31:41 -0800 (PST) Received: by 10.194.179.166 with HTTP; Tue, 5 Nov 2013 13:31:40 -0800 (PST) Received: by 10.194.179.166 with HTTP; Tue, 5 Nov 2013 13:31:40 -0800 (PST) In-Reply-To: <5279339B.9040506@bbs.darktech.org> References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> Date: Wed, 6 Nov 2013 08:31:40 +1100 Message-ID: From: Mohammed Raad To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=f46d043c7f0623ab9404ea74c22c 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 21:31:51 -0000 --f46d043c7f0623ab9404ea74c22c Content-Type: text/plain; charset=ISO-8859-1 Hi, Given the lack of agreement on a single MTI, for business reasons primarily, and given that the debate is really focused on two candidates, I suggest that a transcoding function between these two codecs be defined at the service provider level. I suggest that the transcoding function only include the VP8 and AVC CBP to make the development and use of this part of the service feasible. Having such a function would allow different organizations to make their own decision about what works for them. I sense that different experts have become entrenched in their respective positions with very little freedom to make a change, for multiple reasons. I think it should be clear that having transcoding at the service level would be a reasonable compromise. Note that no end device would be required to perform the transcoding, this would be done at the service provider level. BR, Mohammed On Nov 6, 2013 5:07 AM, "cowwoc" wrote: > 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)" >> 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 wrote: >>> >>> On 5 November 2013 06:18, Hutton, Andrew >>> 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 > --f46d043c7f0623ab9404ea74c22c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

Given the lack of agreement on a single MTI, for business re= asons primarily, and given that the debate is really focused on two candida= tes, I suggest that a transcoding function between these two codecs be defi= ned at the service provider level.

I suggest that the transcoding function only include the VP8= and AVC CBP to make the development and use of this part of the service fe= asible.=A0

Having such a function would allow different organizations t= o make their own decision about what works for them. I sense that different= experts have become entrenched in their respective positions with very lit= tle freedom to make a change, for multiple reasons. I think it should be cl= ear that having transcoding at the service level would be a reasonable comp= romise. Note that no end device would be required to perform the transcodin= g, this would be done at the service provider level.

BR,
Mohammed

On Nov 6, 2013 5:07 AM, "cowwoc" <<= a href=3D"mailto:cowwoc@bbs.darktech.org">cowwoc@bbs.darktech.org> w= rote:
Cullen,

=A0 =A0 In light of the fact that vendors are highly polarized on this topi= c, 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)

=A0 =A0 Given the final choice (H.261 or no MTI) I suspect many vendors wou= ld 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 chai= rs feel ready to discuss in the thursday meeting.

I will note that in the past when this idea was discussed, the people who w= ere concerned about IPR for either codec pointed out that this could only i= ncreased, 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 wi= ll 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 re= ally 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 a= re both in meetings right now


On Nov 5, 2013, at 9:27 AM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
=A0 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<= br> MTIs, or declare no consensus, forcing us into alternative processes? I
support both as MTI. But if raising my hand twice increases the likelihood<= br> 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
--f46d043c7f0623ab9404ea74c22c-- From cowwoc@bbs.darktech.org Tue Nov 5 14:03:21 2013 Return-Path: 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 9FCB221E8160 for ; Tue, 5 Nov 2013 14:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Q6-ToS93jQKu for ; Tue, 5 Nov 2013 14:03:16 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 96C6821E80FD for ; Tue, 5 Nov 2013 14:03:13 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id e14so16137265iej.11 for ; Tue, 05 Nov 2013 14:03:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=GUTQL3S92NTKn8WuS49ahvRcN2svlM466pQmEJC/AsU=; b=bOL9gycAgSOWrmwiV0xmFqoWurVjV546jGAhigYDPgck0cHSF+nFVfXRnSHkEsnmaj lpvCJKg11j3pfdqZU8C+ybe5/ZXkixIwiCxh2RYsM8RYOwMyN7sMyOfCLyaoMVGhj4wE JEH4Uq8zCzOv7vDSaAHFAy/R+dw08swr09sC9rrGkBKDmLz+w23odDfmIEBgMQrODnbe Z+8VmQ5RY63IZ5x/CWmMFAGodPzRajDtELPEHnFHBjqbMlgbJk1a4tasSuBHZWlk3iSy 1pYiWLAbyIChnRStXnloU2OmwhbnxdoNeyf3CW9mKcGllRp2EsYfm0fTzt8fJXhcyaVv Q4Xw== X-Gm-Message-State: ALoCoQkmg4Fv8xaL1//cSsVfsIH6g0gVppmCxBj4mDYLEOLDO7IWzuNSe4qV8Hmpbw1nGFgwXQ2f X-Received: by 10.42.172.67 with SMTP id m3mr14961917icz.21.1383688992544; Tue, 05 Nov 2013 14:03:12 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f19sm10585958igz.1.2013.11.05.14.03.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 14:03:11 -0800 (PST) Message-ID: <52796B1D.5030704@bbs.darktech.org> Date: Tue, 05 Nov 2013 17:03:09 -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: rtcweb@ietf.org References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040500020202060900090907" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:03:21 -0000 This is a multi-part message in MIME format. --------------040500020202060900090907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mohammed, Your approach does not work for the typical browser-to-browser (P2P) connections. Gili On 05/11/2013 4:31 PM, Mohammed Raad wrote: > > Hi, > > Given the lack of agreement on a single MTI, for business reasons > primarily, and given that the debate is really focused on two > candidates, I suggest that a transcoding function between these two > codecs be defined at the service provider level. > > I suggest that the transcoding function only include the VP8 and AVC > CBP to make the development and use of this part of the service feasible. > > Having such a function would allow different organizations to make > their own decision about what works for them. I sense that different > experts have become entrenched in their respective positions with very > little freedom to make a change, for multiple reasons. I think it > should be clear that having transcoding at the service level would be > a reasonable compromise. Note that no end device would be required to > perform the transcoding, this would be done at the service provider level. > > BR, > Mohammed > > On Nov 6, 2013 5:07 AM, "cowwoc" > wrote: > > 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)" > > > 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 > > wrote: > > On 5 November 2013 06:18, Hutton, Andrew > > > 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 --------------040500020202060900090907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Mohammed,

    Your approach does not work for the typical browser-to-browser (P2P) connections.

Gili

On 05/11/2013 4:31 PM, Mohammed Raad wrote:

Hi,

Given the lack of agreement on a single MTI, for business reasons primarily, and given that the debate is really focused on two candidates, I suggest that a transcoding function between these two codecs be defined at the service provider level.

I suggest that the transcoding function only include the VP8 and AVC CBP to make the development and use of this part of the service feasible. 

Having such a function would allow different organizations to make their own decision about what works for them. I sense that different experts have become entrenched in their respective positions with very little freedom to make a change, for multiple reasons. I think it should be clear that having transcoding at the service level would be a reasonable compromise. Note that no end device would be required to perform the transcoding, this would be done at the service provider level.

BR,
Mohammed

On Nov 6, 2013 5:07 AM, "cowwoc" <cowwoc@bbs.darktech.org> wrote:
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

--------------040500020202060900090907-- From wolfgang.beck01@googlemail.com Tue Nov 5 14:03:57 2013 Return-Path: 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 82D7E21E8097 for ; Tue, 5 Nov 2013 14:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 GOV3VMmK0ifJ for ; Tue, 5 Nov 2013 14:03:56 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 187AB21E8154 for ; Tue, 5 Nov 2013 14:03:54 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id lc6so5973964vcb.39 for ; Tue, 05 Nov 2013 14:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AHtnsPk4IXxse7kvcJuEav/juzvnlVvncsPAfrtwLUs=; b=1FOTWEM7ipqZcPXYhF6Jx5nxTEzQE70kGRr2KPAiihDxU7QYPZ6uxTE29i1Ou5Fvqs 5zjt2r9OMwjFbE4eHBmSEjHDGYvpvQzM7wumv5subT/4mm3N/0khBrP8133lO5X7n6i5 IIPtu4+2NuEEvJ4QaYUwxZpfwJSE8GQWR7iqYq6M3tDcebl0YSemVPQDhTpneL44kygf /D9YKb6nhXwVrxKSp7MTGFeUcVJmApQSVAJmWEKU/hwlRQYzKADCbh44EztH/d0OnClJ BQALlLM6PNwjeZMIpuFngqY+GOJMGwqudpZFMVViHY7n0uSu2ACd3nGRQzzy3RVBWJIb 1pAw== MIME-Version: 1.0 X-Received: by 10.52.166.200 with SMTP id zi8mr1205052vdb.38.1383689034401; Tue, 05 Nov 2013 14:03:54 -0800 (PST) Received: by 10.58.45.169 with HTTP; Tue, 5 Nov 2013 14:03:54 -0800 (PST) Received: by 10.58.45.169 with HTTP; Tue, 5 Nov 2013 14:03:54 -0800 (PST) In-Reply-To: <52795BF0.1020207@makk.es> References: <52795BF0.1020207@makk.es> Date: Tue, 5 Nov 2013 23:03:54 +0100 Message-ID: From: Wolfgang Beck To: Max Jonas Werner Content-Type: multipart/alternative; boundary=089e01634aa6600d3904ea7535cd Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 22:03:57 -0000 --089e01634aa6600d3904ea7535cd Content-Type: text/plain; charset=ISO-8859-1 According to the draft and the w3c doc, the Idp exchange is completely hidden from the JS. I don't see how a web server could use the result to verify the user without looking at the SDP. Or how the peerconnection could reuse the result of an Idp exchange that authenticated the user towards the server. Did I overlook something? Having to log in twice will only be tolerated by a small minority of people. Wolfgang Beck Am 05.11.2013 12:58 schrieb "Max Jonas Werner" : > Wolfgang, > > On 05.11.2013 18:06, Wolfgang Beck wrote: > > What I am missing in this draft is the link between authentication > towards > > the web server and signing of DTLS info towards the remote party. To > make a > > call, a user will have to > > 1) log into the web server application > > 2) permit the browser to access camera/mic > > 3) log into the IdP to sign the DTLS info > > > > To receive a call, I will have to > > 1) log into the web server application > > 2) permit the browser to access camera/mic when there is a call > > 3) log into the IdP to sign the DTLS info > > ..and hope the caller has not given up before I clicked all permission > > boxes and entered all user credentials. > > > > Can 1) and 3) be merged somehow? How would you explain 3) to a user? > > 1) and 3) can be merged if > > a) the user is already logged from the IdP's point of view prior to even > visiting the site (using either built-in browser logic or manually) > > or > > b) the IdP is the able to identify the user from step 1) somehow (e.g. > when the web server is run by the IdP). > > Keep in mind, though, that the user to be able to provide an identity to > the other WebRTC peer that is different from the identity of step 1) is > exactly what the user wants sometimes. > > Max > > --089e01634aa6600d3904ea7535cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

According to the draft and the w3c doc, the Idp exchange is = completely hidden from the JS. I don't see how a web server could use t= he result to verify the user without looking at the SDP. Or how the peercon= nection could reuse the result of an Idp exchange that authenticated the us= er towards the server. Did I overlook something?

Having to log in twice will only be tolerated by a small min= ority of people.

Wolfgang Beck

Am 05.11.2013 12:58 schrieb "Max Jonas Wern= er" <mail@makk.es>:
Wolfgang,

On 05.11.2013 18:06, Wolfgang Beck wrote:
> What I am missing in this draft is the link between authentication tow= ards
> the web server and signing of DTLS info towards the remote party. To m= ake a
> call, a user will have to
> 1) log into the web server application
> 2) permit the browser to access camera/mic
> 3) log into the IdP to sign the DTLS info
>
> To receive a call, I will have to
> 1) log into the web server application
> 2) permit the browser to access camera/mic when there is a call
> 3) log into the IdP to sign the DTLS info
> ..and hope the caller has not given up before I clicked all permission=
> boxes and entered all user credentials.
>
> Can 1) and 3) be merged somehow? How would you explain 3) to a user?
1) and 3) can be merged if

a) the user is already logged from the IdP's point of view prior to eve= n
visiting the site (using either built-in browser logic or manually)

or

b) the IdP is the able to identify the user from step 1) somehow (e.g.
when the web server is run by the IdP).

Keep in mind, though, that the user to be able to provide an identity to the other WebRTC peer that is different from the identity of step 1) is
exactly what the user wants sometimes.

Max

--089e01634aa6600d3904ea7535cd-- From juberti@google.com Tue Nov 5 14:58:30 2013 Return-Path: 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 5C0D821E80D8 for ; Tue, 5 Nov 2013 14:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 sU0WCr53kfj2 for ; Tue, 5 Nov 2013 14:58:28 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id A78DA21E80CA for ; Tue, 5 Nov 2013 14:58:22 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id jz11so3068182veb.12 for ; Tue, 05 Nov 2013 14:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3O2EmztsgUvm3ugwO9efqdsbX1U05zd+1MmpiAyT9/o=; b=HNO5aIFxH0aJMaZ4OeoWvjBL7GkLpUrjbiU6UULqJBZcLCqY3J5gZIBHuQ1V9/3Csc d2cgiqBWTIhMmC2oUJGfTwKVau5dIw/LHoTP0fxtGCKcc23x3DBx7fPmN9+BxWyfxgo2 rFBYfbYcOsdeBVlBJVlYeOw6G48ETZdDREg24A9FGxKaJXVvJGzXZ9zT7iz160wt7gNA vC6nNKK8kOcg7GHruGxv16NjHhQpBVeoBzKksTnEK8C5b8X0108+RV2bgXVzt3enpNEx H3CCQwi6NCoE5d12QJzVMlXkZDESwLcQQ5SS8Z5w8TgvntuleR8s/UCbIDyNSzUDZ4bl IsXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3O2EmztsgUvm3ugwO9efqdsbX1U05zd+1MmpiAyT9/o=; b=YSTwWAIomLWsHctNgFY57oI3yuwXIl/fJCgw6u50ickgZbKgk00JOq9dqBzaKdLG42 2bRc6ix7KzfYxP3nuh+HVTzVew6EAif8pPdz4kyX1GRwY3HaInm8YEe8aIdjRoP2XynG oupBgZp1WZf3TcBnI8Hu1UXnD2de9PoRr7ply2X0eIZuphOvWRzHMnHou+0IVwh1og1K mg1ghhGMHbP0MsYD73urfcX5t87yTsXTX5AXOzIhjfnnscPaD5LMNUtL/bYZoPtBZWos NVWZRW1J1IlyCRLDwvxmoE8x6AmZdxppflGucnDi9xotXlyUjEwQg5UYnU4NVdwDuMx3 c3Bg== X-Gm-Message-State: ALoCoQkUKjXmHf1wLghzDqosF6aAd85hrgcZ0Yw7dtkqFT0VCqhDRbcck8f/NlZ6OwnoOnqq6uXGowObrrso19OYTLIr2yPGqw4ZgXbpONqBFN2H00MaehUhZ4vu65PiTObcJwDeNJ1THtH47r1U91SHxsu/hhjuSucJxZjqH08Fnf7yrOm2BrBC9WpQHozNhYZs5dk9Cdix X-Received: by 10.52.37.69 with SMTP id w5mr22730vdj.32.1383692296666; Tue, 05 Nov 2013 14:58:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Tue, 5 Nov 2013 14:57:56 -0800 (PST) In-Reply-To: <52790780.6020704@jesup.org> References: <52790780.6020704@jesup.org> From: Justin Uberti Date: Tue, 5 Nov 2013 14:57:56 -0800 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=20cf30780db0d25a8104ea75f721 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 22:58:30 -0000 --20cf30780db0d25a8104ea75f721 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 5, 2013 at 6:58 AM, Randell Jesup wrote= : > On 11/5/2013 12:55 AM, Mo Zanaty (mzanaty) wrote: > > I=E2=80=99m serious. Name a device in mass production that is relevant to= rtcweb > but does not have H.264 hardware. > > > Plenty have hardware is out there that might not be optimized (or usable) > for the types of arbitrary-sized, realtime simultaneous h.264 > encode/decode. Even just handling streaming decode on Android via OMX ha= s > been a year of pain for one of our engineers, because (especially before > JB) the interfaces were unsupported, randomly modified/incompatible, and > with lots of restrictions on what actually is supported. Even with > "perfect" API layers exposing them, the hardware layers (especially > encoders) may not have the low-latency and other realtime characteristics > needed, or knobs to tell them about things like packet loss reports that > require IDR generation. How many does this affect? who knows - and the A= PI > layers on top are inconsistent enough (or non-existent at the present) th= at > it's especially hard to tell. > > And many of them can handle only a single stream at a time; which makes > "hangout"/simulcast cases more fun (need to run HW and SW in parallel, or > drop to SW only - makes capability signaling fun too; the LCD of the SW a= nd > HW codecs needs to be what you offer probably, unless you want real pain)= . > Exactly. Name a 3rd-party software application in wide use on any of today's popular platforms that uses a H.264 HW encoder for rtcweb scenarios= . > > > > Your second point is valid; hardware is useless without supporting > software. OS APIs to access codecs (both hardware and software, real-time > and buffered) is an important issue. Android is the dominant OS on the > planet. If you are not happy with its OS APIs, just change them; it=E2=80= =99s open > source like VP8 right? > > > Not really. You can't modify the underlying OS provided by the > manufacturer (no rooting of phones to run webrtc should be required...) > and even custom roms are going to get much harder or virtually impossible > with kitkat. And witness my comments about the pain of platform decoders > on Android today. > > Randell > > > > Mo > > > On 11/5/13, 1:10 AM, cowwoc wrote: > > > I'm not sure if you're being sarcastic or not... > > In any case, I had a question regarding BlackBerry 10. Are you > implying that every BlackBerry 10 phone includes an API for real-time > encoding/decoding of H.264 video streams? If so, which API is it? I took = a > quick look but couldn't find it. > > Thanksm > Gili > > On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote: > > I think you meant *every* phone, tablet, laptop, desktop, set-top, camera= =E2=80=A6 > > > On 11/2/13, 7:41 PM, Kaiduan Xie wrote: > > Every BlackBerry 10 phone has H.264 hardware encoder/decoder. > > /Kaiduan > > > On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla wrote: > >> >> >> >> On Sat, Nov 2, 2013 at 1:01 PM, Gili wrote: >> >>> Martin, >>> >>> I fully understand why Firefox would be happy but as someone who >>> plan to integrate WebRTC into a non-browser application, especially on = iOS, >>> Cisco's solution simply does not work. I appreciate their contribution,= but >>> again, it simply doesn't help my use-case. >>> >> >> I haven't seen you explain how your use case is different from that of >> a browser. Could you please do so? >> >> -Ekr >> >> >>> Gili >>> >>> >>> On 11/2/2013 11:02 AM, Martin Thomson wrote: >>> >>>> On 2 November 2013 07:37, cowwoc wrote: >>>> >>>>> I can't think of a single platform that supports real-time H.264 >>>>> encoding/decoding natively today. >>>>> >>>> That's a very strange way to put the question. >>>> >>>> Let me put another spin on it, and please excuse the example... >>>> >>>> Skype runs on more platforms than you might think. Those platforms >>>> can all support H.264 to the extent that Skype requires. >>>> >>>> Cisco's generous offer opens almost the same capability to anyone, >>>> with the caveat that some platforms currently remain closed. Of >>>> course, you could let your ideals get in the way of progress. Me, I'm >>>> a pragmatist. This gift represents a great opportunity for people who >>>> actually care about the practical outcomes. >>>> >>>> There's been a lot of mouth-gazing of gift horses on this list of >>>> late. I sure hope that this isn't representative of the real >>>> sentiment of the community. I'd like to think that people are better >>>> than that. >>>> >>>> (BTW, I understand and respect Harald's position. From where he sits, >>>> I'm sure that his conclusion makes perfect sense.) >>>> >>> >>> > > -- > Randell Jesuprandell-ietf@jesup.org > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf30780db0d25a8104ea75f721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 5, 2013 at 6:58 AM, Randell Jesup <= ;randell-ietf@j= esup.org> wrote:
=20 =20 =20
On 11/5/2013 12:55 AM, Mo Zanaty (mzanaty) wrote:
=20
I=E2=80=99m serious. Name a device in mass production that is relevant to rtcweb but does not have H.264 hardware.

Plenty have hardware is out there that might not be optimized (or usable) for the types of arbitrary-sized, realtime simultaneous h.264 encode/decode.=C2=A0 Even just handling streaming decode on Andro= id via OMX has been a year of pain for one of our engineers, because (especially before JB) the interfaces were unsupported, randomly modified/incompatible, and with lots of restrictions on what actually is supported.=C2=A0 Even with "perfect" API layers e= xposing them, the hardware layers (especially encoders) may not have the low-latency and other realtime characteristics needed, or knobs to tell them about things like packet loss reports that require IDR generation.=C2=A0 How many does this affect? who knows - and the API layers on top are inconsistent enough (or non-existent at the present) that it's especially hard to tell.

And many of them can handle only a single stream at a time; which makes "hangout"/simulcast cases more fun (need to run HW and = SW in parallel, or drop to SW only - makes capability signaling fun too; the LCD of the SW and HW codecs needs to be what you offer probably, unless you want real pain).

Exact= ly. Name a 3rd-party software application in wide use on any of today's= popular platforms that uses a H.264 HW encoder for rtcweb scenarios.



Your second point is valid; hardware is useless without supporting software. OS APIs to access codecs (both hardware and software, real-time and buffered) is an important issue. Android is the dominant OS on the planet. If you are not happy with its OS APIs, just change them; it=E2=80=99s open source like VP8 right?=

Not really.=C2=A0 You can't modify the underlying OS provided by th= e manufacturer (no rooting of phones to run webrtc should be required...)=C2=A0 and even custom roms are going to get much harder or virtually impossible=C2=A0 with kitkat.=C2=A0 And witness my comments a= bout the pain of platform decoders on Android today.

=C2=A0=C2=A0 Randell



Mo


On 11/5/13, 1:10 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:


=C2=A0=C2=A0=C2=A0 I'm not sure if you're being sarca= stic or not...

=C2=A0=C2=A0=C2=A0 In any case, I had a question regarding Bl= ackBerry 10. Are you implying that every BlackBerry 10 phone includes an API for real-time encoding/decoding of H.264 video streams? If so, which API is it? I took a quick look but couldn't find it.

Thanksm
Gili

On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote:
I think you meant *every* phone, tablet, laptop, desktop, set-top, camera=E2=80=A6=C2=A0


On 11/2/13, 7:41 PM, Kaiduan Xie <kaiduanx@gmail.com> wrote:

Every BlackBerry 10 phone has H.264 hardware encoder/decoder.

/Kaiduan


On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Sat, Nov 2, 2013 at 1:01 PM, Gili <cowwoc@bbs.darktech= .org> wrote:
Martin,

=C2=A0 =C2=A0 I fully understand why Fi= refox would be happy but as someone who plan to integrate WebRTC into a non-browser application, especially on iOS, Cisco's solution simply doe= s not work. I appreciate their contribution, but again, it simply doesn't help my use-case.

I haven't seen =C2=A0you explain h= ow your use case is different from that of
a browser. Could you please do so?

-Ekr
=C2=A0
Gili


On 11/2/2013 11:02 AM, Martin Thomson wrote:
On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org> wrote:
=C2=A0 =C2=A0 =C2=A0I can't t= hink of a single platform that supports real-time H.264
encoding/decoding natively today.
That's a very strange way to pu= t the question.

Let me put another spin on it, and please excuse the example...
Skype runs on more platforms than you might think. =C2=A0Those platforms
can all support H.264 to the extent that Skype requires.

Cisco's generous offer opens almost the same capability to anyone,
with the caveat that some platforms currently remain closed. =C2=A0Of
course, you could let your ideals get in the way of progress. =C2=A0Me, I'm
a pragmatist. =C2=A0This gift represents a great opportunity for people who
actually care about the practical outcomes.

There's been a lot of mouth-gazin= g of gift horses on this list of
late. =C2=A0I sure hope that this isn= 't representative of the real
sentiment of the community. =C2=A0I&#= 39;d like to think that people are better
than that.

(BTW, I understand and respect Harald's position. =C2=A0From whe= re he sits,
I'm sure that his conclusion make= s perfect sense.)

 


--=20
Randell Jesup
randell-ietf@je=
sup.org

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--20cf30780db0d25a8104ea75f721-- From karl.stahl@intertex.se Tue Nov 5 15:12:34 2013 Return-Path: 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 1211F21E80D8 for ; Tue, 5 Nov 2013 15:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1] 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 6WZoWhS7NK+9 for ; Tue, 5 Nov 2013 15:12:29 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id D0F0321E80BA for ; Tue, 5 Nov 2013 15:12:28 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201311060012242663; Wed, 06 Nov 2013 00:12:24 +0100 From: "Karl Stahl" To: "'cowwoc'" , References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> In-Reply-To: <5279339B.9040506@bbs.darktech.org> Date: Wed, 6 Nov 2013 00:12:25 +0100 Message-ID: <014301ceda7c$7d8a0440$789e0cc0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7aUfbpiJsXv3xXQbaQMmPxW3oKOAAJGFRg Content-Language: sv 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:12:34 -0000 I support this voting suggestion and don't think it violates the = proposals on the table.=20 I actually think "1. Should *both* H.264 and VP8 be MTI?" is the only = one that has a chance of reaching consensus. Also,=20 - 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. =20 /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = cowwoc Skickat: den 5 november 2013 19:06 Till: rtcweb@ietf.org =C4mne: 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=20 > they are both in meetings right now > > > On Nov 5, 2013, at 9:27 AM, "Mo Zanaty (mzanaty)" > wrote: > >> This is an important point the chairs must clarify. If there is=20 >> strong support for both questions, will the chair interpret that as=20 >> support for 2 MTIs, or declare no consensus, forcing us into=20 >> alternative processes? I support both as MTI. But if raising my hand=20 >> 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 wrote: >> >> On 5 November 2013 06:18, Hutton, Andrew = 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=20 >> 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 From dave.taht@gmail.com Tue Nov 5 15:20:37 2013 Return-Path: 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 4202821F9D19 for ; Tue, 5 Nov 2013 15:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ak-jpdPjM1Ci for ; Tue, 5 Nov 2013 15:20:36 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7465B21F9D35 for ; Tue, 5 Nov 2013 15:20:27 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t60so4060461wes.26 for ; Tue, 05 Nov 2013 15:20:26 -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=Fw1LcyRm1Gflpj589OK1kDRpKrHdS/63a3ci/YCqCpg=; b=i9EHcAoF46w8MZqEZzNvJqtc0KVvQTLd5rmxWYOxOpnSVGMUWF6fc7SL5pLpbLbMJw wl4GcZYkRjG0zkbiNNuOY7qflqgJz4y4OECJyftmrc9rlCXTXxptpkkxixz95qTTRUK4 11pJr2xSk8xzaBvtMN5GD8SsfC+HXn/+DHzV1g4ozNhv30twqZYWzmgDe7NVV103pzMP cvBvkrQqpyAORnX+h1uquhkfZjVLexwJsUaVAJlbhgBYAw4DN5rXCuSO6oS3HK06Yv95 JQCKOBjtttwJuUwon8KV0LagqZAk+eDgEA47kbakmP8OI5x2RzzvJw31k7taBad4+7Ll aN5A== MIME-Version: 1.0 X-Received: by 10.180.83.194 with SMTP id s2mr64871wiy.60.1383693626445; Tue, 05 Nov 2013 15:20:26 -0800 (PST) Received: by 10.217.51.5 with HTTP; Tue, 5 Nov 2013 15:20:26 -0800 (PST) Received: by 10.217.51.5 with HTTP; Tue, 5 Nov 2013 15:20:26 -0800 (PST) In-Reply-To: References: <52740478.6030109@nostrum.com> <52750E3C.9060206@bbs.darktech.org> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> <7208CC8D-1F25-43A7-A887-C85D3B18363E@apple.com> <5277E85C.4060905@thaumas.net> <014601ced9b6$15233ff0$3f69bfd0$@shockey.us> Date: Tue, 5 Nov 2013 15:20:26 -0800 Message-ID: From: Dave Taht To: Kristian Kielhofner Content-Type: multipart/alternative; boundary=f46d0434bc141516dc04ea7647a0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 23:20:37 -0000 --f46d0434bc141516dc04ea7647a0 Content-Type: text/plain; charset=ISO-8859-1 On Nov 5, 2013 6:01 AM, "Kristian Kielhofner" wrote: > > You might be interested in my updated analysis here: > > http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html > > SIP "enhancements" indeed! Oh that was excellent thank you! All the evidence to date on videoconferencing points towards a smaller than 1500 quantum default for fq codel. > > > On Monday, November 4, 2013, Richard Shockey wrote: >> >> >> That has been confirmed by independent Wireshark analysis. >> >> http://www.packetstan.com/2010/07/special-look-face-time-part-1.html >> >> Its also SIP with some Apple "enhancements" >> >> >> >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of >> Ralph Giles >> Sent: Monday, November 04, 2013 1:33 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Platforms that support H264 >> >> On 2013-11-04 5:51 AM, David Singer wrote: >> >> > reverse engineering suggests that FaceTime uses AVC (H.264). >> >> Reverse engineering isn't necessary to establish this, although it's nice to >> have ongoing confirmation of the details. :-) >> >> http://cdn1.appleinsider.com/facetime.002.jpg >> >> -r >> _______________________________________________ >> 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 > > > > -- > Sent from mobile device > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d0434bc141516dc04ea7647a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 5, 2013 6:01 AM, "Kristian Kielhofner" <kris@kriskinc.com> wrote:
>
> You might be interested in my updated analysis here:
>
> http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspect= ive.html
>
> SIP "enhancements" indeed!

Oh that was excellent thank you! All the evidence to date on= videoconferencing points towards a smaller than 1500 quantum default for f= q codel.
>
>
> On Monday, November 4, 2013, Richard Shockey wrote:
>>
>>
>> That has been confirmed by independent Wireshark analysis.
>>
>> http://www.packetstan.com/2010/07/special-look-face-time-par= t-1.html
>>
>> Its also SIP with some Apple "enhancements"
>>
>>
>>
>> -----Original Message-----
>> From: rtcweb-bounces@ie= tf.org [mailto:rtcweb-bounce= s@ietf.org] On Behalf Of
>> Ralph Giles
>> Sent: Monday, November 04, 2013 1:33 PM
>> To: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Platforms that support H264
>>
>> On 2013-11-04 5:51 AM, David Singer wrote:
>>
>> > reverse engineering suggests that FaceTime uses AVC (H.264).<= br> >>
>> Reverse engineering isn't necessary to establish this, althoug= h it's nice to
>> have ongoing confirmation of the details. :-)
>>
>> http://c= dn1.appleinsider.com/facetime.002.jpg
>>
>> =A0-r
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --
> Sent from mobile device
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>

--f46d0434bc141516dc04ea7647a0-- From juberti@google.com Tue Nov 5 15:25:33 2013 Return-Path: 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 41AD621E80D8 for ; Tue, 5 Nov 2013 15:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 y8mk8Vgb-0fT for ; Tue, 5 Nov 2013 15:25:32 -0800 (PST) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8BB21E808F for ; Tue, 5 Nov 2013 15:25:31 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id 11so2882912vbe.17 for ; Tue, 05 Nov 2013 15:25:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CeQpFPkMjmy1B89gtK/lTqI3+6Hdoz9IOOtv897XWFw=; b=MV1RmftVKqup8MlOldTH+m+Y8ooOMpCJySYihjucvYoU3llQ28AGKBjB7aQXRUhCt/ JLJNJkd65t9D7SUIwKHKogvtTPGyjm1VdTeO1VyP+aOQRj+UaTFB9X/Y7BuQWxQr4Itq hDU4kOLLH7NWA8LVMRFwcWpPlC6MChBtWYogEthoYjGQAPN8US+SIJlaxUfkuOmHORzj rFs9zax+IEElJOGCtE62Zu15UQ8ORDTfVgKvhaDrf3ReMXkBv2Bu+gG2s3hQ5dEcaPc7 00OpQzn+3rwVmZfIcGBvZB0ZpMpe6ACTI77DcVJyAYo3UeOzceqa28D+h018jFkpWSB0 TPww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CeQpFPkMjmy1B89gtK/lTqI3+6Hdoz9IOOtv897XWFw=; b=kAh9YEpSsErGPVIUv6w/sOffykN4imgs9qrJbGAW4PIJRRtWsjZtIgUNqab9Sz0vHh 3Jp52Wf4l3+xQxBgc/RFsJ1SvXh3011UBHZglKgEy0w3YZtF9ZwPHFmTi/vX7eyNnfy6 bnTlreV+L8DIzruAbEzCZijaq6NybhnMjQITY43F1bmoQhwfKhzR6SEx0BoB8h8+WUeO YHGwRIZ8Pje/J01kXlCMW4kfTepHJLfQ8ZGZG5xwTbWYrOCp4yaJ7IcWT2/ZSLoalzas SKQkZ+wrX0xOqXrvxkKUzlLgKztAQ9kTiKlvs7Lb0/M3/VZPSk4xw98YKzs71s3uGGVQ sL4Q== X-Gm-Message-State: ALoCoQm7QDs82a9CUjICCbLUvBprmgXHLsU5zRVSCZF23KXrqA5MKDm6QgBSeqt7zbxiOa/mvJzEiV/JQ5uDvr50+/92VSxKHkyoDSAQQh0q+13UVT+E72dEGVrlRC34Y4kawEHWLt3lRYesLAWRFz90Icx964rBVrvd2DMZ2R6iW8C/JhtiftaIOuGxUa5IJ9O8Yak8i2Tc X-Received: by 10.52.97.138 with SMTP id ea10mr25891vdb.31.1383693931505; Tue, 05 Nov 2013 15:25:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Tue, 5 Nov 2013 15:25:11 -0800 (PST) In-Reply-To: <5279339B.9040506@bbs.darktech.org> References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> From: Justin Uberti Date: Tue, 5 Nov 2013 15:25:11 -0800 Message-ID: To: cowwoc Content-Type: multipart/alternative; boundary=20cf307f38f844008404ea76597c Cc: "rtcweb@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:25:33 -0000 --20cf307f38f844008404ea76597c Content-Type: text/plain; charset=UTF-8 The cost equation for CPU versus network is shifted enough in favor of CPU that considering old codecs like H.261 makes no financial sense. If you look at AWS pricing, the CPU cost of reducing bitrate from 1 Mbps to 750 Kbps is more than made up by the network cost. http://aws.amazon.com/ec2/pricing/ 250 Kbps * 1 hour = $0.11 high-compute instance for an hour = $0.05 (1 HD transcode = 4 SD transcodes) Transcoding isn't the bogeyman people are making it out to be. On Tue, Nov 5, 2013 at 10:06 AM, cowwoc wrote: > 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)" >> 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 wrote: >>> >>> On 5 November 2013 06:18, Hutton, Andrew >>> 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 > --20cf307f38f844008404ea76597c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The cost equation for CPU versus network is shifted enough= in favor of CPU that considering old codecs like H.261 makes no financial = sense. If you look at AWS pricing, the CPU cost of reducing bitrate from 1 = Mbps to 750 Kbps is more than made up by the network cost.

250 Kbps * 1 hour =3D $0.11
=
high-compute instance for an hour =3D $0.05 (1 HD transcode =3D 4 SD t= ranscodes)

Transcoding isn't the bogeyman people are making it= out to be.


On Tue, Nov 5, 2013 at 10:06 AM, cowwoc = <cowwoc@bbs= .darktech.org> wrote:
Cullen,

=C2=A0 =C2=A0 In light of the fact that vendors are highly polarized on thi= s 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)

=C2=A0 =C2=A0 Given the final choice (H.261 or no MTI) I suspect many vendo= rs would choose H.261 and upgrade to H.264/VP8 at runtime. No one really wa= nts 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 chai= rs feel ready to discuss in the thursday meeting.

I will note that in the past when this idea was discussed, the people who w= ere concerned about IPR for either codec pointed out that this could only i= ncreased, 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 wi= ll 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 re= ally 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 a= re both in meetings right now


On Nov 5, 2013, at 9:27 AM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
=C2=A0 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<= br> MTIs, or declare no consensus, forcing us into alternative processes? I
support both as MTI. But if raising my hand twice increases the likelihood<= br> 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

--20cf307f38f844008404ea76597c-- From martin.thomson@gmail.com Tue Nov 5 15:38:34 2013 Return-Path: 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 90ACA21E80CE for ; Tue, 5 Nov 2013 15:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, 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 vmgStWWzt4K9 for ; Tue, 5 Nov 2013 15:38:32 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 985EC21E80B7 for ; Tue, 5 Nov 2013 15:38:31 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id f4so2903660wiw.4 for ; Tue, 05 Nov 2013 15:38:29 -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=phCmVK/pZcg0NoHTzhlQbyVv+JnEC4tPsrIaLwRv5hY=; b=Jvt95guZYSNOBpYr0qNnGBfh6c8Q047uIPtDK7N6zbGu+jdo4J+733W1m/jCnC52eP yJf9sJJLjRiUXzJgJQWuz1MsqyzMxzvzNRfpTWSTaDJwyhb0jCh0UM6gtdUDLfk9vqhA 5w3FuAuNv9dLg6tOWmcu6IvyvmdXOqXpIrmzwYA43rbjaqEsGlGSqOlzXDDg4KlzGoYs 66FFIAWyWImBy5Bwrdjqw4DT3klmTq6fVOxA1aK8vMFhJkfVHnZIp9V2Wm6Gi7mi0IlJ 59k/TNuBVVtvXZE9HYtIMlTWLMY1MrUxBGNs/FJwWB///OF9k24XuctHZ7z1SlRs9bwH Hbxw== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr18995692wij.30.1383694709235; Tue, 05 Nov 2013 15:38:29 -0800 (PST) Received: by 10.227.202.194 with HTTP; Tue, 5 Nov 2013 15:38:29 -0800 (PST) In-Reply-To: References: <52795BF0.1020207@makk.es> Date: Tue, 5 Nov 2013 15:38:29 -0800 Message-ID: From: Martin Thomson To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Tue, 05 Nov 2013 23:38:34 -0000 On 5 November 2013 14:03, Wolfgang Beck wrote: > Having to log in twice will only be tolerated by a small minority of people. That assumes that the login is not persistent. I believe that there are plenty of options an IdP can use to ensure that this doesn't become necessary. From cowwoc@bbs.darktech.org Tue Nov 5 15:59:51 2013 Return-Path: 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 0E0D411E815E for ; Tue, 5 Nov 2013 15:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.496 X-Spam-Level: X-Spam-Status: No, score=-4.496 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 1+osnR508PBL for ; Tue, 5 Nov 2013 15:59:46 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2194711E8125 for ; Tue, 5 Nov 2013 15:59:46 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id aq17so15871093iec.20 for ; Tue, 05 Nov 2013 15:59:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=tLCcKLYcNZNIE3jfzdF2TsbJjlpdZFPFNy06Xb0fZaY=; b=hDm16IDwjunUl77zk/6qH2YOxTny4/lCNzcTI3psFsmuJ75xUB2w0pk/oy6jQS1WFJ +7wgssYn344TuZ+iuOgym3ARJjJqwFwSvZ90zl4JWBGR7Q712hftItWx44lkBSK+pW99 Ggye6cGZe+8DNUN1X9KIYevQRxmDMf+OULrV2YRl8uaK/NJP7C58W670NWst8NED1QR/ MzF78yhDm/zH9jl6RywQ66Oa4guWjn83E4U70BJ4pTQm2GPgwgmr61JVb8So99YJLXfx l0REM929iPfQsbM6yVO/kekIVsa0xYq4/dnWDYKUDmYEATcPSq8c5oJIcnSCHmwJ0HMt vcxw== X-Gm-Message-State: ALoCoQlFgGosatIjSz15Dg+J6wV3pnRJv49i8hsoNZRgizxxyH9ddC98US3VOIZ1lT3esh/EQXWN X-Received: by 10.50.6.99 with SMTP id z3mr119180igz.27.1383695985191; Tue, 05 Nov 2013 15:59:45 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id l7sm11074020igx.2.2013.11.05.15.59.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 15:59:44 -0800 (PST) Message-ID: <5279866E.1040604@bbs.darktech.org> Date: Tue, 05 Nov 2013 18:59:42 -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: Justin Uberti References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030907000106020803080609" Cc: "rtcweb@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:59:51 -0000 This is a multi-part message in MIME format. --------------030907000106020803080609 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Justin, What happens to P2P video chat? Are we throwing that out of the window? A P2P-based mesh is superior to one with AWS in the middle for a couple of reasons: * Privacy * Cost * Consistent latency * Ease of deployment Gili On 05/11/2013 6:25 PM, Justin Uberti wrote: > The cost equation for CPU versus network is shifted enough in favor of > CPU that considering old codecs like H.261 makes no financial sense. > If you look at AWS pricing, the CPU cost of reducing bitrate from 1 > Mbps to 750 Kbps is more than made up by the network cost. > > http://aws.amazon.com/ec2/pricing/ > 250 Kbps * 1 hour = $0.11 > high-compute instance for an hour = $0.05 (1 HD transcode = 4 SD > transcodes) > > Transcoding isn't the bogeyman people are making it out to be. > > > On Tue, Nov 5, 2013 at 10:06 AM, cowwoc > wrote: > > 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)" > > > 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 > > wrote: > > On 5 November 2013 06:18, Hutton, Andrew > > > 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 > > --------------030907000106020803080609 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Justin,

    What happens to P2P video chat? Are we throwing that out of the window? A P2P-based mesh is superior to one with AWS in the middle for a couple of reasons:
  • Privacy
  • Cost
  • Consistent latency
  • Ease of deployment
Gili

On 05/11/2013 6:25 PM, Justin Uberti wrote:
The cost equation for CPU versus network is shifted enough in favor of CPU that considering old codecs like H.261 makes no financial sense. If you look at AWS pricing, the CPU cost of reducing bitrate from 1 Mbps to 750 Kbps is more than made up by the network cost.

250 Kbps * 1 hour = $0.11
high-compute instance for an hour = $0.05 (1 HD transcode = 4 SD transcodes)

Transcoding isn't the bogeyman people are making it out to be.


On Tue, Nov 5, 2013 at 10:06 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
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


--------------030907000106020803080609-- From ggb@tokbox.com Tue Nov 5 16:23:16 2013 Return-Path: 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 1784211E8125 for ; Tue, 5 Nov 2013 16:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 iWHeffC9lDLT for ; Tue, 5 Nov 2013 16:23:11 -0800 (PST) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id EC14411E8170 for ; Tue, 5 Nov 2013 16:23:10 -0800 (PST) Received: from mail-vc0-f176.google.com ([209.85.220.176]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUnmL7lHlx8YETU7Vua7T30OXH/2eOCJX@postini.com; Tue, 05 Nov 2013 16:23:11 PST Received: by mail-vc0-f176.google.com with SMTP id ia6so6074220vcb.21 for ; Tue, 05 Nov 2013 16:23:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8duetkzAxvEIzWbuuezGkRoBwQAu2Tn1a6MILW51DiI=; b=C2y55p5mpxnpHhLvfTUGupZyCT1IT+IrOueUPi/sAynvULpFMWg0Tkcrun07To29Z6 rXqFPxbdRfSzy2jeBmju8uj/btMqN/U0QOOXXXo7uDTaKj3EWZYHoKaaYDjjGt2YpFKv AMV+nT6i9LzJEwDYiOFiQGp4/Cog4htWbXBymA/mzA7Y2EUIg3DPmVW3mOwJVf+yT3Bw zfm17XhPOcK6vuSCbprz3Hg4u36sSRsgKMMBs9eQoQBlX6AHpJ/fjHrXOZ6HObfAKn+f Ef42Uq0V7MHE28DFrPVz9k9bnrisF8mCxaIN5bJ8D1f+LlIrV9HJeynsWZ+a6sljG7RR rSTQ== X-Gm-Message-State: ALoCoQnaXMwzUOCxscAkEDLwLj//fi723rdS4TzLwji7+uFPbEdKo7ctbaGqdkeS5AVzkiLrUiqiB2rUA1tngQ8o468EJO1ytqgQQfmoN6womn0isICaQYb4URUsb5YaNG8qSbpzuByfFDmC7FkdWpPcDO3oHN4PuA== X-Received: by 10.220.252.71 with SMTP id mv7mr129598vcb.68.1383697389989; Tue, 05 Nov 2013 16:23:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.220.252.71 with SMTP id mv7mr129590vcb.68.1383697389859; Tue, 05 Nov 2013 16:23:09 -0800 (PST) Received: by 10.58.211.200 with HTTP; Tue, 5 Nov 2013 16:23:09 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Nov 2013 16:23:09 -0800 Message-ID: From: Gustavo Garcia To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e01227b3666570004ea77272c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 00:23:16 -0000 --089e01227b3666570004ea77272c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 H.264 licensing as introduced by Cisco is great because it opens the door to truly present H.264 as a viable alternative codec for broad implementation in WebRTC endpoints, but Cisco=92s proposal as it stands is not enough to warrant H.264 being adopted as an MTI for WebRTC. >From TokBox=92s point of view, WebRTC needs to be able to solve two needs i= f true adoption is intended: 1) supporting interoperability with legacy end-points and 2) enabling novel and innovative real-world use-cases on a broad range of software-powered end-points (mobile included, not just browsers) The option as proposed with H.264 is not really viable in mobile native applications (specifically iOS devices as the situation stands today), whether both endpoints are mobile native or one is browser-based. At TokBox, we are already seeing a wide range of very interesting applications being built on top of WebRTC using native mobile apps as one of the endpoints, and the standard must do the right thing by not preventing these scenarios from playing out. As far as MTI codecs go, we still believe VP8 is the right option and believe H.264 should be embraced as an optional alternative video codec.The purpose of the WebRTC is not to create a browser compatible with existing solutions (many of which are closed systems) but rather to bring the best possible experience to application developers, extending the capabilities of the web for real-time communication. (More of our views here: http://www.tokbox.com/blog/is-webrtc-ready-for-h-264/) On Thu, Oct 31, 2013 at 11:47 AM, Harald Alvestrand wrote: > We congratulate Cisco on their intention to make an open source H.264 > codec available and usable by the community. We look forward to seeing th= e > result of this effort. > > Google still believes that VP8 - a freely available, fully open, > high-quality video codec that you can download, compile for your platform= , > include in your binary, distribute and put into production today - is the > best choice of a Mandatory to Implement video codec for the WebRTC effort= . > > Harald (sending this from my Google address) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e01227b3666570004ea77272c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+1

H.264 licensing as introdu= ced by Cisco is great=20 because it opens the door to truly present H.264 as a viable alternative codec for broad implementation in WebRTC endpoints, but Cisco=92s=20 proposal as it stands is not enough to warrant H.264 being adopted as an MTI for WebRTC.=A0

From TokBox=92s point of view, WebRTC needs to be able to solve two needs if true adoption is intended: =A01) supporting=20 interoperability with legacy end-points and 2) enabling novel and=20 innovative real-world use-cases on a broad range of software-powered=20 end-points (mobile included, not just browsers)

The option as proposed with H.264 is not really=20 viable in mobile native applications (specifically iOS devices as the=20 situation stands today), whether both endpoints are mobile native or one is browser-based. At TokBox, we are already seeing a wide range of very interesting applications being built on top of WebRTC using native=20 mobile apps as one of the endpoints, and the standard must do the right=20 thing by not preventing these scenarios from playing out.

As far as MTI codecs go, we still believe VP8 is the right option and believe H.264 should be embraced as an optional=20 alternative video codec.The purpose of the WebRTC is not to create a=20 browser compatible with existing solutions (many of which are closed=20 systems) but rather to bring the best possible experience to application developers, extending the capabilities of the web for real-time=20 communication. (More of our views here: http://www.tokbox.com/blog= /is-webrtc-ready-for-h-264/)



On Thu, Oct 31, 2013 at 11:47 AM, Harald= Alvestrand <hta@google.com> wrote:

We congratulate Cisco on their in= tention to make an open source H.264 codec available and usable by the comm= unity. We look forward to seeing the result of this effort.


Google still believes that= VP8 - a freely available, fully open, high-quality video codec that you ca= n download, compile for your platform, include in your binary, distribute a= nd put into production today - is the best choice of a Mandatory to Impleme= nt video codec for the WebRTC effort.


Harald (sending this from my Google address)


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--089e01227b3666570004ea77272c-- From Markus.Isomaki@nokia.com Tue Nov 5 16:30:41 2013 Return-Path: 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 3734511E8163 for ; Tue, 5 Nov 2013 16:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sFa2iEec-rmF for ; Tue, 5 Nov 2013 16:30:01 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id F17CF11E8196 for ; Tue, 5 Nov 2013 16:30:00 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.47]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA60OxZB010351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 Nov 2013 02:25:00 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.204]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.03.0136.001; Wed, 6 Nov 2013 00:24:59 +0000 From: To: , Thread-Topic: [rtcweb] Platforms that support H264 Thread-Index: AQHO2np3XZTSBx4DE0acC/uGF4sfIpoXVf/g Date: Wed, 6 Nov 2013 00:24:58 +0000 Message-ID: References: <52790780.6020704@jesup.org> In-Reply-To: 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+/nZJb9Kg7IoXudYJHPDxfPkxFCz+4V5qyGOTzq66RIT4/8P/TkEIrw2EbtfmXoTub3Hy+ZR/kyGgCp/SaUHSbGQECT7atWxE3KjNo/W7hVJqGs0XLgAIW9mv/FrAc3P++GLkcpVbDqYAEGa99X2GDqKEa56rqcxX5SM1yQlDdJ08nDqyTOz6eJlE+w83rCOsvNmpmdLnEESmfJ+NbnyoXzU9pUUg63a1pHoZDSio/w035gbgi2HjD x-originating-ip: [10.163.34.237] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620A108A95008AM1MPN1041mg_" MIME-Version: 1.0 X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 00:30:41 -0000 --_000_E44893DD4E290745BB608EB23FDDB7620A108A95008AM1MPN1041mg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWdyZWUgdGhlcmUgaXMgZGVmaW5pdGVseSBhIG5lZWQgdG8gaW1wcm92ZSB0aGUg YWNjZXNzIHRvIHRoZSBILjI2NCAg4oCcSFfigJ0gY29kZWNzIHNvIHRoZXkgd291bGQgYmUgcmVh bGlzdGljYWxseSB1c2FibGUgZm9yIFdlYlJUQyBvciBvdGhlciBpbnRlcmFjdGl2ZSB2aWRlbyBh cHBzLiBCdXQgdGhhdCBzdGlsbCBzZWVtcyB0byBtZSBhcyB0aGUgYmVzdCB3YXkgZm9yd2FyZCBj b21wYXJlZCB0byB0aGUgb3RoZXIgb3B0aW9ucy4gSSBrbm93IGltcHJvdmVtZW50cyBhcmUgY29t aW5nIGF0IGxlYXN0IHRvIFdpbmRvd3MgUGhvbmUgYW5kIFdpbmRvd3MgUlQuDQoNCk1hcmt1cw0K DQoNCkZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgSnVzdGluIFViZXJ0aQ0KU2VudDogMDYgTm92ZW1i ZXIsIDIwMTMgMDA6NTgNClRvOiBSYW5kZWxsIEplc3VwDQpDYzogcnRjd2ViQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3J0Y3dlYl0gUGxhdGZvcm1zIHRoYXQgc3VwcG9ydCBIMjY0DQoNCg0KDQpP biBUdWUsIE5vdiA1LCAyMDEzIGF0IDY6NTggQU0sIFJhbmRlbGwgSmVzdXAgPHJhbmRlbGwtaWV0 ZkBqZXN1cC5vcmc8bWFpbHRvOnJhbmRlbGwtaWV0ZkBqZXN1cC5vcmc+PiB3cm90ZToNCk9uIDEx LzUvMjAxMyAxMjo1NSBBTSwgTW8gWmFuYXR5IChtemFuYXR5KSB3cm90ZToNCknigJltIHNlcmlv dXMuIE5hbWUgYSBkZXZpY2UgaW4gbWFzcyBwcm9kdWN0aW9uIHRoYXQgaXMgcmVsZXZhbnQgdG8g cnRjd2ViIGJ1dCBkb2VzIG5vdCBoYXZlIEguMjY0IGhhcmR3YXJlLg0KDQpQbGVudHkgaGF2ZSBo YXJkd2FyZSBpcyBvdXQgdGhlcmUgdGhhdCBtaWdodCBub3QgYmUgb3B0aW1pemVkIChvciB1c2Fi bGUpIGZvciB0aGUgdHlwZXMgb2YgYXJiaXRyYXJ5LXNpemVkLCByZWFsdGltZSBzaW11bHRhbmVv dXMgaC4yNjQgZW5jb2RlL2RlY29kZS4gIEV2ZW4ganVzdCBoYW5kbGluZyBzdHJlYW1pbmcgZGVj b2RlIG9uIEFuZHJvaWQgdmlhIE9NWCBoYXMgYmVlbiBhIHllYXIgb2YgcGFpbiBmb3Igb25lIG9m IG91ciBlbmdpbmVlcnMsIGJlY2F1c2UgKGVzcGVjaWFsbHkgYmVmb3JlIEpCKSB0aGUgaW50ZXJm YWNlcyB3ZXJlIHVuc3VwcG9ydGVkLCByYW5kb21seSBtb2RpZmllZC9pbmNvbXBhdGlibGUsIGFu ZCB3aXRoIGxvdHMgb2YgcmVzdHJpY3Rpb25zIG9uIHdoYXQgYWN0dWFsbHkgaXMgc3VwcG9ydGVk LiAgRXZlbiB3aXRoICJwZXJmZWN0IiBBUEkgbGF5ZXJzIGV4cG9zaW5nIHRoZW0sIHRoZSBoYXJk d2FyZSBsYXllcnMgKGVzcGVjaWFsbHkgZW5jb2RlcnMpIG1heSBub3QgaGF2ZSB0aGUgbG93LWxh dGVuY3kgYW5kIG90aGVyIHJlYWx0aW1lIGNoYXJhY3RlcmlzdGljcyBuZWVkZWQsIG9yIGtub2Jz IHRvIHRlbGwgdGhlbSBhYm91dCB0aGluZ3MgbGlrZSBwYWNrZXQgbG9zcyByZXBvcnRzIHRoYXQg cmVxdWlyZSBJRFIgZ2VuZXJhdGlvbi4gIEhvdyBtYW55IGRvZXMgdGhpcyBhZmZlY3Q/IHdobyBr bm93cyAtIGFuZCB0aGUgQVBJIGxheWVycyBvbiB0b3AgYXJlIGluY29uc2lzdGVudCBlbm91Z2gg KG9yIG5vbi1leGlzdGVudCBhdCB0aGUgcHJlc2VudCkgdGhhdCBpdCdzIGVzcGVjaWFsbHkgaGFy ZCB0byB0ZWxsLg0KDQpBbmQgbWFueSBvZiB0aGVtIGNhbiBoYW5kbGUgb25seSBhIHNpbmdsZSBz dHJlYW0gYXQgYSB0aW1lOyB3aGljaCBtYWtlcyAiaGFuZ291dCIvc2ltdWxjYXN0IGNhc2VzIG1v cmUgZnVuIChuZWVkIHRvIHJ1biBIVyBhbmQgU1cgaW4gcGFyYWxsZWwsIG9yIGRyb3AgdG8gU1cg b25seSAtIG1ha2VzIGNhcGFiaWxpdHkgc2lnbmFsaW5nIGZ1biB0b287IHRoZSBMQ0Qgb2YgdGhl IFNXIGFuZCBIVyBjb2RlY3MgbmVlZHMgdG8gYmUgd2hhdCB5b3Ugb2ZmZXIgcHJvYmFibHksIHVu bGVzcyB5b3Ugd2FudCByZWFsIHBhaW4pLg0KDQpFeGFjdGx5LiBOYW1lIGEgM3JkLXBhcnR5IHNv ZnR3YXJlIGFwcGxpY2F0aW9uIGluIHdpZGUgdXNlIG9uIGFueSBvZiB0b2RheSdzIHBvcHVsYXIg cGxhdGZvcm1zIHRoYXQgdXNlcyBhIEguMjY0IEhXIGVuY29kZXIgZm9yIHJ0Y3dlYiBzY2VuYXJp b3MuDQoNCg0KDQoNCllvdXIgc2Vjb25kIHBvaW50IGlzIHZhbGlkOyBoYXJkd2FyZSBpcyB1c2Vs ZXNzIHdpdGhvdXQgc3VwcG9ydGluZyBzb2Z0d2FyZS4gT1MgQVBJcyB0byBhY2Nlc3MgY29kZWNz IChib3RoIGhhcmR3YXJlIGFuZCBzb2Z0d2FyZSwgcmVhbC10aW1lIGFuZCBidWZmZXJlZCkgaXMg YW4gaW1wb3J0YW50IGlzc3VlLiBBbmRyb2lkIGlzIHRoZSBkb21pbmFudCBPUyBvbiB0aGUgcGxh bmV0LiBJZiB5b3UgYXJlIG5vdCBoYXBweSB3aXRoIGl0cyBPUyBBUElzLCBqdXN0IGNoYW5nZSB0 aGVtOyBpdOKAmXMgb3BlbiBzb3VyY2UgbGlrZSBWUDggcmlnaHQ/DQoNCk5vdCByZWFsbHkuICBZ b3UgY2FuJ3QgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIE9TIHByb3ZpZGVkIGJ5IHRoZSBtYW51ZmFj dHVyZXIgKG5vIHJvb3Rpbmcgb2YgcGhvbmVzIHRvIHJ1biB3ZWJydGMgc2hvdWxkIGJlIHJlcXVp cmVkLi4uKSAgYW5kIGV2ZW4gY3VzdG9tIHJvbXMgYXJlIGdvaW5nIHRvIGdldCBtdWNoIGhhcmRl ciBvciB2aXJ0dWFsbHkgaW1wb3NzaWJsZSAgd2l0aCBraXRrYXQuICBBbmQgd2l0bmVzcyBteSBj b21tZW50cyBhYm91dCB0aGUgcGFpbiBvZiBwbGF0Zm9ybSBkZWNvZGVycyBvbiBBbmRyb2lkIHRv ZGF5Lg0KDQogICBSYW5kZWxsDQoNCg0KDQoNCk1vDQoNCg0KT24gMTEvNS8xMywgMToxMCBBTSwg Y293d29jIDxjb3d3b2NAYmJzLmRhcmt0ZWNoLm9yZzxtYWlsdG86Y293d29jQGJicy5kYXJrdGVj aC5vcmc+PiB3cm90ZToNCg0KDQogICAgSSdtIG5vdCBzdXJlIGlmIHlvdSdyZSBiZWluZyBzYXJj YXN0aWMgb3Igbm90Li4uDQoNCiAgICBJbiBhbnkgY2FzZSwgSSBoYWQgYSBxdWVzdGlvbiByZWdh cmRpbmcgQmxhY2tCZXJyeSAxMC4gQXJlIHlvdSBpbXBseWluZyB0aGF0IGV2ZXJ5IEJsYWNrQmVy cnkgMTAgcGhvbmUgaW5jbHVkZXMgYW4gQVBJIGZvciByZWFsLXRpbWUgZW5jb2RpbmcvZGVjb2Rp bmcgb2YgSC4yNjQgdmlkZW8gc3RyZWFtcz8gSWYgc28sIHdoaWNoIEFQSSBpcyBpdD8gSSB0b29r IGEgcXVpY2sgbG9vayBidXQgY291bGRuJ3QgZmluZCBpdC4NCg0KVGhhbmtzbQ0KR2lsaQ0KDQpP biAwNC8xMS8yMDEzIDk6NTIgUE0sIE1vIFphbmF0eSAobXphbmF0eSkgd3JvdGU6DQpJIHRoaW5r IHlvdSBtZWFudCAqZXZlcnkqIHBob25lLCB0YWJsZXQsIGxhcHRvcCwgZGVza3RvcCwgc2V0LXRv cCwgY2FtZXJh4oCmDQoNCg0KT24gMTEvMi8xMywgNzo0MSBQTSwgS2FpZHVhbiBYaWUgPGthaWR1 YW54QGdtYWlsLmNvbTxtYWlsdG86a2FpZHVhbnhAZ21haWwuY29tPj4gd3JvdGU6DQoNCkV2ZXJ5 IEJsYWNrQmVycnkgMTAgcGhvbmUgaGFzIEguMjY0IGhhcmR3YXJlIGVuY29kZXIvZGVjb2Rlci4N Cg0KL0thaWR1YW4NCg0KT24gU2F0LCBOb3YgMiwgMjAxMyBhdCA2OjE4IFBNLCBFcmljIFJlc2Nv cmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KDQoNCk9uIFNh dCwgTm92IDIsIDIwMTMgYXQgMTowMSBQTSwgR2lsaSA8Y293d29jQGJicy5kYXJrdGVjaC5vcmc8 bWFpbHRvOmNvd3dvY0BiYnMuZGFya3RlY2gub3JnPj4gd3JvdGU6DQpNYXJ0aW4sDQoNCiAgICBJ IGZ1bGx5IHVuZGVyc3RhbmQgd2h5IEZpcmVmb3ggd291bGQgYmUgaGFwcHkgYnV0IGFzIHNvbWVv bmUgd2hvIHBsYW4gdG8gaW50ZWdyYXRlIFdlYlJUQyBpbnRvIGEgbm9uLWJyb3dzZXIgYXBwbGlj YXRpb24sIGVzcGVjaWFsbHkgb24gaU9TLCBDaXNjbydzIHNvbHV0aW9uIHNpbXBseSBkb2VzIG5v dCB3b3JrLiBJIGFwcHJlY2lhdGUgdGhlaXIgY29udHJpYnV0aW9uLCBidXQgYWdhaW4sIGl0IHNp bXBseSBkb2Vzbid0IGhlbHAgbXkgdXNlLWNhc2UuDQoNCkkgaGF2ZW4ndCBzZWVuICB5b3UgZXhw bGFpbiBob3cgeW91ciB1c2UgY2FzZSBpcyBkaWZmZXJlbnQgZnJvbSB0aGF0IG9mDQphIGJyb3dz ZXIuIENvdWxkIHlvdSBwbGVhc2UgZG8gc28/DQoNCi1Fa3INCg0KR2lsaQ0KDQoNCk9uIDExLzIv MjAxMyAxMTowMiBBTSwgTWFydGluIFRob21zb24gd3JvdGU6DQpPbiAyIE5vdmVtYmVyIDIwMTMg MDc6MzcsIGNvd3dvYyA8Y293d29jQGJicy5kYXJrdGVjaC5vcmc8bWFpbHRvOmNvd3dvY0BiYnMu ZGFya3RlY2gub3JnPj4gd3JvdGU6DQogICAgIEkgY2FuJ3QgdGhpbmsgb2YgYSBzaW5nbGUgcGxh dGZvcm0gdGhhdCBzdXBwb3J0cyByZWFsLXRpbWUgSC4yNjQNCmVuY29kaW5nL2RlY29kaW5nIG5h dGl2ZWx5IHRvZGF5Lg0KVGhhdCdzIGEgdmVyeSBzdHJhbmdlIHdheSB0byBwdXQgdGhlIHF1ZXN0 aW9uLg0KDQpMZXQgbWUgcHV0IGFub3RoZXIgc3BpbiBvbiBpdCwgYW5kIHBsZWFzZSBleGN1c2Ug dGhlIGV4YW1wbGUuLi4NCg0KU2t5cGUgcnVucyBvbiBtb3JlIHBsYXRmb3JtcyB0aGFuIHlvdSBt aWdodCB0aGluay4gIFRob3NlIHBsYXRmb3Jtcw0KY2FuIGFsbCBzdXBwb3J0IEguMjY0IHRvIHRo ZSBleHRlbnQgdGhhdCBTa3lwZSByZXF1aXJlcy4NCkNpc2NvJ3MgZ2VuZXJvdXMgb2ZmZXIgb3Bl bnMgYWxtb3N0IHRoZSBzYW1lIGNhcGFiaWxpdHkgdG8gYW55b25lLA0Kd2l0aCB0aGUgY2F2ZWF0 IHRoYXQgc29tZSBwbGF0Zm9ybXMgY3VycmVudGx5IHJlbWFpbiBjbG9zZWQuICBPZg0KY291cnNl LCB5b3UgY291bGQgbGV0IHlvdXIgaWRlYWxzIGdldCBpbiB0aGUgd2F5IG9mIHByb2dyZXNzLiAg TWUsIEknbQ0KYSBwcmFnbWF0aXN0LiAgVGhpcyBnaWZ0IHJlcHJlc2VudHMgYSBncmVhdCBvcHBv cnR1bml0eSBmb3IgcGVvcGxlIHdobw0KYWN0dWFsbHkgY2FyZSBhYm91dCB0aGUgcHJhY3RpY2Fs IG91dGNvbWVzLg0KDQpUaGVyZSdzIGJlZW4gYSBsb3Qgb2YgbW91dGgtZ2F6aW5nIG9mIGdpZnQg aG9yc2VzIG9uIHRoaXMgbGlzdCBvZg0KbGF0ZS4gIEkgc3VyZSBob3BlIHRoYXQgdGhpcyBpc24n dCByZXByZXNlbnRhdGl2ZSBvZiB0aGUgcmVhbA0Kc2VudGltZW50IG9mIHRoZSBjb21tdW5pdHku ICBJJ2QgbGlrZSB0byB0aGluayB0aGF0IHBlb3BsZSBhcmUgYmV0dGVyDQp0aGFuIHRoYXQuDQoN CihCVFcsIEkgdW5kZXJzdGFuZCBhbmQgcmVzcGVjdCBIYXJhbGQncyBwb3NpdGlvbi4gIEZyb20g d2hlcmUgaGUgc2l0cywNCkknbSBzdXJlIHRoYXQgaGlzIGNvbmNsdXNpb24gbWFrZXMgcGVyZmVj dCBzZW5zZS4pDQoNCg0KDQotLQ0KDQpSYW5kZWxsIEplc3VwDQoNCnJhbmRlbGwtaWV0ZkBqZXN1 cC5vcmc8bWFpbHRvOnJhbmRlbGwtaWV0ZkBqZXN1cC5vcmc+DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3 ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_E44893DD4E290745BB608EB23FDDB7620A108A95008AM1MPN1041mg_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5ob2VuemINCgl7bXNv LXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNv bnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAyLjBjbSA3MC44NXB0IDIuMGNt O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhlcmUgaXMg ZGVmaW5pdGVseSBhIG5lZWQgdG8gaW1wcm92ZSB0aGUgYWNjZXNzIHRvIHRoZSBILjI2NCZuYnNw OyDigJxIV+KAnSBjb2RlY3Mgc28gdGhleSB3b3VsZCBiZSByZWFsaXN0aWNhbGx5IHVzYWJsZSBm b3IgV2ViUlRDIG9yIG90aGVyIGludGVyYWN0aXZlIHZpZGVvDQogYXBwcy4gQnV0IHRoYXQgc3Rp bGwgc2VlbXMgdG8gbWUgYXMgdGhlIGJlc3Qgd2F5IGZvcndhcmQgY29tcGFyZWQgdG8gdGhlIG90 aGVyIG9wdGlvbnMuIEkga25vdyBpbXByb3ZlbWVudHMgYXJlIGNvbWluZyBhdCBsZWFzdCB0byBX aW5kb3dzIFBob25lIGFuZCBXaW5kb3dzIFJULg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXJrdXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX19fX19yZXBseXNlcGFyYXRvciI+PC9hPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5leHQgSnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiAwNiBOb3Zl bWJlciwgMjAxMyAwMDo1ODxicj4NCjxiPlRvOjwvYj4gUmFuZGVsbCBKZXN1cDxicj4NCjxiPkNj OjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBQ bGF0Zm9ybXMgdGhhdCBzdXBwb3J0IEgyNjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE5vdiA1LCAy MDEzIGF0IDY6NTggQU0sIFJhbmRlbGwgSmVzdXAgJmx0OzxhIGhyZWY9Im1haWx0bzpyYW5kZWxs LWlldGZAamVzdXAub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmFuZGVsbC1pZXRmQGplc3VwLm9yZzwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gMTEvNS8yMDEzIDEyOjU1IEFNLCBNbyBaYW5hdHkgKG16YW5hdHkp IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5J4oCZbSBzZXJpb3VzLiBOYW1lIGEgZGV2aWNlIGluIG1hc3MgcHJvZHVjdGlvbiB0aGF0 IGlzIHJlbGV2YW50IHRvIHJ0Y3dlYiBidXQgZG9lcyBub3QgaGF2ZSBILjI2NCBoYXJkd2FyZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBs ZW50eSBoYXZlIGhhcmR3YXJlIGlzIG91dCB0aGVyZSB0aGF0IG1pZ2h0IG5vdCBiZSBvcHRpbWl6 ZWQgKG9yIHVzYWJsZSkgZm9yIHRoZSB0eXBlcyBvZiBhcmJpdHJhcnktc2l6ZWQsIHJlYWx0aW1l IHNpbXVsdGFuZW91cyBoLjI2NCBlbmNvZGUvZGVjb2RlLiZuYnNwOyBFdmVuIGp1c3QgaGFuZGxp bmcgc3RyZWFtaW5nIGRlY29kZSBvbiBBbmRyb2lkIHZpYSBPTVggaGFzIGJlZW4gYSB5ZWFyIG9m IHBhaW4gZm9yIG9uZQ0KIG9mIG91ciBlbmdpbmVlcnMsIGJlY2F1c2UgKGVzcGVjaWFsbHkgYmVm b3JlIEpCKSB0aGUgaW50ZXJmYWNlcyB3ZXJlIHVuc3VwcG9ydGVkLCByYW5kb21seSBtb2RpZmll ZC9pbmNvbXBhdGlibGUsIGFuZCB3aXRoIGxvdHMgb2YgcmVzdHJpY3Rpb25zIG9uIHdoYXQgYWN0 dWFsbHkgaXMgc3VwcG9ydGVkLiZuYnNwOyBFdmVuIHdpdGggJnF1b3Q7cGVyZmVjdCZxdW90OyBB UEkgbGF5ZXJzIGV4cG9zaW5nIHRoZW0sIHRoZSBoYXJkd2FyZSBsYXllcnMgKGVzcGVjaWFsbHkg ZW5jb2RlcnMpDQogbWF5IG5vdCBoYXZlIHRoZSBsb3ctbGF0ZW5jeSBhbmQgb3RoZXIgcmVhbHRp bWUgY2hhcmFjdGVyaXN0aWNzIG5lZWRlZCwgb3Iga25vYnMgdG8gdGVsbCB0aGVtIGFib3V0IHRo aW5ncyBsaWtlIHBhY2tldCBsb3NzIHJlcG9ydHMgdGhhdCByZXF1aXJlIElEUiBnZW5lcmF0aW9u LiZuYnNwOyBIb3cgbWFueSBkb2VzIHRoaXMgYWZmZWN0PyB3aG8ga25vd3MgLSBhbmQgdGhlIEFQ SSBsYXllcnMgb24gdG9wIGFyZSBpbmNvbnNpc3RlbnQgZW5vdWdoIChvciBub24tZXhpc3RlbnQN CiBhdCB0aGUgcHJlc2VudCkgdGhhdCBpdCdzIGVzcGVjaWFsbHkgaGFyZCB0byB0ZWxsLjxicj4N Cjxicj4NCkFuZCBtYW55IG9mIHRoZW0gY2FuIGhhbmRsZSBvbmx5IGEgc2luZ2xlIHN0cmVhbSBh dCBhIHRpbWU7IHdoaWNoIG1ha2VzICZxdW90O2hhbmdvdXQmcXVvdDsvc2ltdWxjYXN0IGNhc2Vz IG1vcmUgZnVuIChuZWVkIHRvIHJ1biBIVyBhbmQgU1cgaW4gcGFyYWxsZWwsIG9yIGRyb3AgdG8g U1cgb25seSAtIG1ha2VzIGNhcGFiaWxpdHkgc2lnbmFsaW5nIGZ1biB0b287IHRoZSBMQ0Qgb2Yg dGhlIFNXIGFuZCBIVyBjb2RlY3MgbmVlZHMgdG8gYmUgd2hhdCB5b3Ugb2ZmZXINCiBwcm9iYWJs eSwgdW5sZXNzIHlvdSB3YW50IHJlYWwgcGFpbikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4YWN0bHkuIE5hbWUgYSAzcmQtcGFydHkgc29m dHdhcmUgYXBwbGljYXRpb24gaW4gd2lkZSB1c2Ugb24gYW55IG9mIHRvZGF5J3MgcG9wdWxhciBw bGF0Zm9ybXMgdGhhdCB1c2VzIGEgSC4yNjQgSFcgZW5jb2RlciBmb3IgcnRjd2ViIHNjZW5hcmlv cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3VyIHNlY29uZCBwb2ludCBpcyB2YWxpZDsgaGFy ZHdhcmUgaXMgdXNlbGVzcyB3aXRob3V0IHN1cHBvcnRpbmcgc29mdHdhcmUuIE9TIEFQSXMgdG8g YWNjZXNzIGNvZGVjcyAoYm90aCBoYXJkd2FyZSBhbmQgc29mdHdhcmUsIHJlYWwtdGltZSBhbmQg YnVmZmVyZWQpIGlzIGFuIGltcG9ydGFudCBpc3N1ZS4gQW5kcm9pZCBpcyB0aGUgZG9taW5hbnQg T1Mgb24gdGhlIHBsYW5ldC4gSWYgeW91IGFyZSBub3QgaGFwcHkNCiB3aXRoIGl0cyBPUyBBUElz LCBqdXN0IGNoYW5nZSB0aGVtOyBpdOKAmXMgb3BlbiBzb3VyY2UgbGlrZSBWUDggcmlnaHQ/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3QgcmVhbGx5LiZuYnNwOyBZ b3UgY2FuJ3QgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIE9TIHByb3ZpZGVkIGJ5IHRoZSBtYW51ZmFj dHVyZXIgKG5vIHJvb3Rpbmcgb2YgcGhvbmVzIHRvIHJ1biB3ZWJydGMgc2hvdWxkIGJlIHJlcXVp cmVkLi4uKSZuYnNwOyBhbmQgZXZlbiBjdXN0b20gcm9tcyBhcmUgZ29pbmcgdG8gZ2V0IG11Y2gg aGFyZGVyIG9yIHZpcnR1YWxseSBpbXBvc3NpYmxlJm5ic3A7IHdpdGgga2l0a2F0LiZuYnNwOyBB bmQgd2l0bmVzcw0KIG15IGNvbW1lbnRzIGFib3V0IHRoZSBwYWluIG9mIHBsYXRmb3JtIGRlY29k ZXJzIG9uIEFuZHJvaWQgdG9kYXkuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IFJhbmRlbGw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAxMS81LzEzLCAxOjEwIEFNLCBjb3d3b2MgJmx0OzxhIGhyZWY9Im1haWx0bzpj b3d3b2NAYmJzLmRhcmt0ZWNoLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvd3dvY0BiYnMuZGFya3Rl Y2gub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgSSdtIG5vdCBzdXJlIGlmIHlvdSdyZSBiZWluZyBzYXJjYXN0aWMgb3Igbm90Li4u PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IEluIGFueSBjYXNlLCBJIGhhZCBhIHF1ZXN0 aW9uIHJlZ2FyZGluZyBCbGFja0JlcnJ5IDEwLiBBcmUgeW91IGltcGx5aW5nIHRoYXQgZXZlcnkg QmxhY2tCZXJyeSAxMCBwaG9uZSBpbmNsdWRlcyBhbiBBUEkgZm9yIHJlYWwtdGltZSBlbmNvZGlu Zy9kZWNvZGluZyBvZiBILjI2NCB2aWRlbyBzdHJlYW1zPyBJZiBzbywgd2hpY2ggQVBJIGlzIGl0 PyBJIHRvb2sgYSBxdWljayBsb29rIGJ1dCBjb3VsZG4ndCBmaW5kIGl0Ljxicj4NCjxicj4NClRo YW5rc208YnI+DQpHaWxpPGJyPg0KPGJyPg0KT24gMDQvMTEvMjAxMyA5OjUyIFBNLCBNbyBaYW5h dHkgKG16YW5hdHkpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHlvdSBtZWFudCAqZXZlcnkqIHBob25lLCB0YWJsZXQs IGxhcHRvcCwgZGVza3RvcCwgc2V0LXRvcCwgY2FtZXJh4oCmJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDExLzIv MTMsIDc6NDEgUE0sIEthaWR1YW4gWGllICZsdDs8YSBocmVmPSJtYWlsdG86a2FpZHVhbnhAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2FpZHVhbnhAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVyeSBCbGFja0JlcnJ5IDEwIHBob25lIGhhcyBILjI2NCBo YXJkd2FyZSBlbmNvZGVyL2RlY29kZXIuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi9LYWlkdWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0 LCBOb3YgMiwgMjAxMyBhdCA2OjE4IFBNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWls dG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gU2F0LCBOb3YgMiwgMjAxMyBhdCAxOjAxIFBNLCBHaWxpICZsdDs8 YSBocmVmPSJtYWlsdG86Y293d29jQGJicy5kYXJrdGVjaC5vcmciIHRhcmdldD0iX2JsYW5rIj5j b3d3b2NAYmJzLmRhcmt0ZWNoLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TWFydGluLDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSBmdWxs eSB1bmRlcnN0YW5kIHdoeSBGaXJlZm94IHdvdWxkIGJlIGhhcHB5IGJ1dCBhcyBzb21lb25lIHdo byBwbGFuIHRvIGludGVncmF0ZSBXZWJSVEMgaW50byBhIG5vbi1icm93c2VyIGFwcGxpY2F0aW9u LCBlc3BlY2lhbGx5IG9uIGlPUywgQ2lzY28ncyBzb2x1dGlvbiBzaW1wbHkgZG9lcyBub3Qgd29y ay4gSSBhcHByZWNpYXRlIHRoZWlyIGNvbnRyaWJ1dGlvbiwgYnV0IGFnYWluLCBpdCBzaW1wbHkg ZG9lc24ndCBoZWxwIG15IHVzZS1jYXNlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmVuJ3Qgc2VlbiAmbmJzcDt5b3UgZXhwbGFpbiBo b3cgeW91ciB1c2UgY2FzZSBpcyBkaWZmZXJlbnQgZnJvbSB0aGF0IG9mPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hIGJyb3dzZXIuIENvdWxkIHlv dSBwbGVhc2UgZG8gc28/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpbGkgPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KT24gMTEvMi8yMDEzIDExOjAyIEFNLCBN YXJ0aW4gVGhvbXNvbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyIE5vdmVtYmVyIDIwMTMgMDc6MzcsIGNv d3dvYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvd3dvY0BiYnMuZGFya3RlY2gub3JnIiB0YXJnZXQ9 Il9ibGFuayI+Y293d29jQGJicy5kYXJrdGVjaC5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7SSBjYW4ndCB0 aGluayBvZiBhIHNpbmdsZSBwbGF0Zm9ybSB0aGF0IHN1cHBvcnRzIHJlYWwtdGltZSBILjI2NDxi cj4NCmVuY29kaW5nL2RlY29kaW5nIG5hdGl2ZWx5IHRvZGF5LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGF0J3MgYSB2 ZXJ5IHN0cmFuZ2Ugd2F5IHRvIHB1dCB0aGUgcXVlc3Rpb24uPGJyPg0KPGJyPg0KTGV0IG1lIHB1 dCBhbm90aGVyIHNwaW4gb24gaXQsIGFuZCBwbGVhc2UgZXhjdXNlIHRoZSBleGFtcGxlLi4uPGJy Pg0KPGJyPg0KU2t5cGUgcnVucyBvbiBtb3JlIHBsYXRmb3JtcyB0aGFuIHlvdSBtaWdodCB0aGlu ay4gJm5ic3A7VGhvc2UgcGxhdGZvcm1zPGJyPg0KY2FuIGFsbCBzdXBwb3J0IEguMjY0IHRvIHRo ZSBleHRlbnQgdGhhdCBTa3lwZSByZXF1aXJlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2lzY28ncyBnZW5lcm91cyBvZmZlciBvcGVucyBhbG1vc3QgdGhl IHNhbWUgY2FwYWJpbGl0eSB0byBhbnlvbmUsPGJyPg0Kd2l0aCB0aGUgY2F2ZWF0IHRoYXQgc29t ZSBwbGF0Zm9ybXMgY3VycmVudGx5IHJlbWFpbiBjbG9zZWQuICZuYnNwO09mPGJyPg0KY291cnNl LCB5b3UgY291bGQgbGV0IHlvdXIgaWRlYWxzIGdldCBpbiB0aGUgd2F5IG9mIHByb2dyZXNzLiAm bmJzcDtNZSwgSSdtPGJyPg0KYSBwcmFnbWF0aXN0LiAmbmJzcDtUaGlzIGdpZnQgcmVwcmVzZW50 cyBhIGdyZWF0IG9wcG9ydHVuaXR5IGZvciBwZW9wbGUgd2hvPGJyPg0KYWN0dWFsbHkgY2FyZSBh Ym91dCB0aGUgcHJhY3RpY2FsIG91dGNvbWVzLjxicj4NCjxicj4NClRoZXJlJ3MgYmVlbiBhIGxv dCBvZiBtb3V0aC1nYXppbmcgb2YgZ2lmdCBob3JzZXMgb24gdGhpcyBsaXN0IG9mPGJyPg0KbGF0 ZS4gJm5ic3A7SSBzdXJlIGhvcGUgdGhhdCB0aGlzIGlzbid0IHJlcHJlc2VudGF0aXZlIG9mIHRo ZSByZWFsPGJyPg0Kc2VudGltZW50IG9mIHRoZSBjb21tdW5pdHkuICZuYnNwO0knZCBsaWtlIHRv IHRoaW5rIHRoYXQgcGVvcGxlIGFyZSBiZXR0ZXI8YnI+DQp0aGFuIHRoYXQuPGJyPg0KPGJyPg0K KEJUVywgSSB1bmRlcnN0YW5kIGFuZCByZXNwZWN0IEhhcmFsZCdzIHBvc2l0aW9uLiAmbmJzcDtG cm9tIHdoZXJlIGhlIHNpdHMsPGJyPg0KSSdtIHN1cmUgdGhhdCBoaXMgY29uY2x1c2lvbiBtYWtl cyBwZXJmZWN0IHNlbnNlLik8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0tIDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+UmFuZGVsbCBKZXN1 cDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4 OCI+PGEgaHJlZj0ibWFpbHRvOnJhbmRlbGwtaWV0ZkBqZXN1cC5vcmciIHRhcmdldD0iX2JsYW5r Ij5yYW5kZWxsLWlldGZAamVzdXAub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K cnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci PnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E44893DD4E290745BB608EB23FDDB7620A108A95008AM1MPN1041mg_-- From Markus.Isomaki@nokia.com Tue Nov 5 16:34:17 2013 Return-Path: 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 ; 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 ; 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 ; 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: To: , , Thread-Topic: [rtcweb] Making both VP8 and H264 MTI Thread-Index: Ac7aUfbpRZsZzyI8mkaenBhjJPm94gAJGFRgAAQkLOA= Date: Wed, 6 Nov 2013 00:28:48 +0000 Message-ID: References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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".=20 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 >=20 > I support this voting suggestion and don't think it violates the proposal= s on > the table. >=20 > I actually think "1. Should *both* H.264 and VP8 be MTI?" is the only one= that > has a chance of reaching consensus. >=20 > Also, > - it is the best to avoid connection failure > - it will avoid requests for transcoding in the network (which would be v= ery > bad technically) > - with the royalty free solutions VP8 from Google and H.264 from Cisco, w= hy > not? None of these offers are conditioned being the only MTI. It is techn= ically > 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- >=20 > In short: Why not making both MTI? We have both G.711 and Opus for > Audio. >=20 > /Karl >=20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r > cowwoc > Skickat: den 5 november 2013 19:06 > Till: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Making both VP8 and H264 MTI >=20 > Cullen, >=20 > In light of the fact that vendors are highly polarized on this topic= , I'd like to > suggest the following voting order: >=20 > 1. Should *both* H.264 and VP8 be MTI? >=20 > If there is a consensus for yes, stop here. >=20 > 2a. Should *only* H.264 be MTI? or, > 2b. Should *only* VP8 be MTI? >=20 > If there is a consensus for either one, stop here. >=20 > 3a. Should *only* H.261 be MTI? or, > 3b. Should no codec be MTI? (this implies transcoding) >=20 > Given the final choice (H.261 or no MTI) I suspect many vendors woul= d > choose H.261 and upgrade to H.264/VP8 at runtime. No one really wants to > go back to the days of transcoding. >=20 > Gili >=20 > 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 onl= y > 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 re= ally > better if people actually honestly answer the question in a consensus cal= l > 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)" > > 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 > wrote: > >> > >> On 5 November 2013 06:18, Hutton, Andrew > 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From wolfgang.beck01@googlemail.com Tue Nov 5 16:36:36 2013 Return-Path: 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 C14B021E809A for ; Tue, 5 Nov 2013 16:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 hEzV58ZiWSNZ for ; Tue, 5 Nov 2013 16:36:35 -0800 (PST) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id E4E0411E81E1 for ; Tue, 5 Nov 2013 16:36:28 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id f12so2364936vbg.11 for ; Tue, 05 Nov 2013 16:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2zy9tOUCWSQ1KessJ4m220ZvGQ1b7CRkZna70KF5iH0=; b=EDYUF7HaDu2elqiqZ7zCSsKqZRa6DaFyrSzCQi8p+P9A1HgZUDWIQAm1eK8b+txY3j Qk9pNDBy8laYFER8Gh0uFUmH408zEoxpxE4ywFsygh6CqU3AdqCjTzepTW2VXCX/iMFP rQfTcDOZUGkyWXmv2v4In5reSdqnMMjOb2Vrdo6PliPaz6v8GAQiqdlJjfRs4UBXue9j vTT2i3m5/LiB+/Qqd0qAc5b0RVsFOReUUuRwPEenuHWX5obcw8JmHTQbt+OGxf8JTL42 N4q3ALHiYaixhMqEu6EpImE9HSqAPeqgtWFsFMEXdYOOcfwTAW1oYLNxQwcX4NNFRV/E yYGA== MIME-Version: 1.0 X-Received: by 10.52.165.131 with SMTP id yy3mr114083vdb.25.1383698188239; Tue, 05 Nov 2013 16:36:28 -0800 (PST) Received: by 10.58.45.169 with HTTP; Tue, 5 Nov 2013 16:36:28 -0800 (PST) Received: by 10.58.45.169 with HTTP; Tue, 5 Nov 2013 16:36:28 -0800 (PST) In-Reply-To: References: <52795BF0.1020207@makk.es> Date: Wed, 6 Nov 2013 01:36:28 +0100 Message-ID: From: Wolfgang Beck To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c2c54afc872d04ea7756f9 Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 00:36:36 -0000 --001a11c2c54afc872d04ea7756f9 Content-Type: text/plain; charset=ISO-8859-1 I'm not convinced. How would you explain to the user why he has to login -- or select an idp -- twice? Maybe this is more an API/W3C topic. Am 05.11.2013 15:38 schrieb "Martin Thomson" : > On 5 November 2013 14:03, Wolfgang Beck > wrote: > > Having to log in twice will only be tolerated by a small minority of > people. > > That assumes that the login is not persistent. I believe that there > are plenty of options an IdP can use to ensure that this doesn't > become necessary. > --001a11c2c54afc872d04ea7756f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I'm not convinced. How would you explain to the user why= he has to login -- or select an idp -- twice? Maybe this is more an API/W3= C topic.=A0

Am 05.11.2013 15:38 schrieb "Martin Thomson= " <martin.thomson@gmail= .com>:
On 5 November 2013 14:03, Wolfgang Beck <wolfgang.beck01@googlemail.com> wrote:
> Having to log in twice will only be tolerated by a small minority of p= eople.

That assumes that the login is not persistent. =A0I believe that there
are plenty of options an IdP can use to ensure that this doesn't
become necessary.
--001a11c2c54afc872d04ea7756f9-- From bryandonnovan@gmail.com Tue Nov 5 16:53:46 2013 Return-Path: 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 67C4E11E81C3 for ; Tue, 5 Nov 2013 16:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 j5Q1QHYfupic for ; Tue, 5 Nov 2013 16:53:45 -0800 (PST) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id AF21B11E8163 for ; Tue, 5 Nov 2013 16:53:45 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id w5so2907580vbf.38 for ; Tue, 05 Nov 2013 16:53:45 -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=ySvvFasQH4DmSY5kmxLS8phZqKzKGx3uzy43PWgf6Tk=; b=ICWu7vskEfYFiWHByMIIIy3FhFQ116+AIodjixT7K4rcbNUpe8K572TvAgq5PE+59L jKFd5Xo83n4w0hxgeGg49mJ/AQf30lpEpKXA3IhPdFUNJBvrGdYJ8eOTW//Bu7fZTVPT FhQHhdRHiqddrnX76ARjY0B8nug8+NeubXsWG3nIF1crlQDE2q10TYqGEodBNiss9SxB MoxmdHRDBevq1z4HqfHRHZoSVv303VXkZ0YMphbjB1C56uMl6YTA687pufq0a357RqOo ovv9c2ZPb48S4zDwreDxv4KS0OLmA6U27RDHx7hLYPTyfOvCJ5orAS1rRDFC/TMfeGBE p0RQ== MIME-Version: 1.0 X-Received: by 10.221.29.200 with SMTP id rz8mr162808vcb.33.1383699225179; Tue, 05 Nov 2013 16:53:45 -0800 (PST) Received: by 10.52.231.233 with HTTP; Tue, 5 Nov 2013 16:53:45 -0800 (PST) In-Reply-To: References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> Date: Tue, 5 Nov 2013 16:53:45 -0800 Message-ID: From: bryandonnovan@gmail.com To: Markus.Isomaki@nokia.com Content-Type: multipart/alternative; boundary=001a11339f3ccafde604ea779480 Cc: rtcweb@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:53:46 -0000 --001a11339f3ccafde604ea779480 Content-Type: text/plain; charset=UTF-8 "real IPR issue" : ability to compile and distribute an h.264 codec without getting a license and paying royalties. "not real IPR issue" : claims made against Opus by Qualcomm and Huawei On Tue, Nov 5, 2013 at 4:28 PM, wrote: > > > Define "real IPR issue". > > Markus --001a11339f3ccafde604ea779480 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

"real IPR issue" : =C2=A0abi= lity to compile and distribute an h.264 codec without getting a license and= paying royalties.

"not real IPR iss= ue" : claims made against Opus by Qualcomm and Huawei

On Tue= , Nov 5, 2013 at 4:28 PM, <Markus.Isomaki@nokia.com>= wrote:

Define "real IPR issue".

Markus
--001a11339f3ccafde604ea779480-- From juberti@google.com Tue Nov 5 17:01:36 2013 Return-Path: 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 AD86D21F9D52 for ; Tue, 5 Nov 2013 17:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 FWM2EP-1q-Nf for ; Tue, 5 Nov 2013 17:01:35 -0800 (PST) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5779F21E80C9 for ; Tue, 5 Nov 2013 17:01:22 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id q12so2901930vbe.41 for ; Tue, 05 Nov 2013 17:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=j/s8zcLt3+pGdQG4UszjqQPSXdRcW2egW+hgm7XOKWU=; b=dX5pEm7l8SohhnajqdeA7w5U01Qa9vIdbb3fDOmNJJxzoALuLPcCThhfNjoFIllZIg ExfGQAOOdj+R+0X+Gh9KC4q5na4TGLwHH89mCHwmP0HAVcfaVw9fNNIoFa5J7padWiuu YGaQL9EI37DcTsNeY01oyEtfiacBGg7GJT07E+iwTOFwaDBie/jJMXT8ghoikqcfbzPm SwPcLYLVdS5Zfjc48tVox1EZs0eUoW69plhY8qk+p2VQCv0LyAiXd0JvDgKvRlR03KN/ RNDAN7HAbUT3w13SPmRax2nlli9wiwU/bOvcjQW1CJkZKcOH4BgjbiS+HDXhW4XbthDr QLfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=j/s8zcLt3+pGdQG4UszjqQPSXdRcW2egW+hgm7XOKWU=; b=dSohyZJIQiR5A/f04od08xfsihd7h7eObTG38dnABIVF5P9rqAadQlvZUr5+broh96 kpBKoMW003sNbj3rsNZ8LrV0Bs7tTGkON22kNY4UrHUiFFocPtGYGnAGxMEASlPsHMgu IYepoMEJLlkH1kxGvTcE/iEjUH293kj6nxZePL6zswqtbRCWRtxEXIYcx2INxl5a6zcP AmsWFdjhYRjxkBuBnjCW95jY8hNNBqeYuy9pn6ksX9/hk1ctRcSzcy2Ti3DnWxgP1Bh2 7vu7mMrGd1IWOZy0Nr34mcOxsmkVAOg+t5Pfo0wtHHgxYnZSyEjXsy4GwmSsPeDqCm49 fwCQ== X-Gm-Message-State: ALoCoQnfubrKvDJMi5lHMfNqsPSmYkOXayTaPd4auI57yztkRJ5d9J2sTMe48nbaVltY6RK5eUU35PxWR7MHlb2Z/klvHkCKNpMbZ5vpJMrEeoQsWHrz2cHsW+rFROoA/ZYoXvUyXy+tbBLbZNcJXskVZ6oz2gx/lGv28u8lO6qoCfsPk+Y+yTRN1zxwlRB3WamoaOxQkeIt X-Received: by 10.58.246.136 with SMTP id xw8mr179971vec.41.1383699681652; Tue, 05 Nov 2013 17:01:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Tue, 5 Nov 2013 17:01:01 -0800 (PST) In-Reply-To: <5279866E.1040604@bbs.darktech.org> References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <5279866E.1040604@bbs.darktech.org> From: Justin Uberti Date: Tue, 5 Nov 2013 17:01:01 -0800 Message-ID: To: cowwoc Content-Type: multipart/alternative; boundary=047d7bdc869e0076e904ea77b0bb Cc: "rtcweb@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:01:36 -0000 --047d7bdc869e0076e904ea77b0bb Content-Type: text/plain; charset=UTF-8 True P2P isn't always possible, witness TURN. So everyone deploying a reliable WebRTC app is going to have bandwidth costs. Those costs will be higher and/or quality much lower, when using H.261 or comparable codecs. On Tue, Nov 5, 2013 at 3:59 PM, cowwoc wrote: > Justin, > > What happens to P2P video chat? Are we throwing that out of the > window? A P2P-based mesh is superior to one with AWS in the middle for a > couple of reasons: > > - Privacy > - Cost > - Consistent latency > - Ease of deployment > > Gili > > > On 05/11/2013 6:25 PM, Justin Uberti wrote: > > The cost equation for CPU versus network is shifted enough in favor of CPU > that considering old codecs like H.261 makes no financial sense. If you > look at AWS pricing, the CPU cost of reducing bitrate from 1 Mbps to 750 > Kbps is more than made up by the network cost. > > http://aws.amazon.com/ec2/pricing/ > 250 Kbps * 1 hour = $0.11 > high-compute instance for an hour = $0.05 (1 HD transcode = 4 SD > transcodes) > > Transcoding isn't the bogeyman people are making it out to be. > > > On Tue, Nov 5, 2013 at 10:06 AM, cowwoc wrote: > >> 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)" >>> 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 wrote: >>>> >>>> On 5 November 2013 06:18, Hutton, Andrew >>>> 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 >> > > > --047d7bdc869e0076e904ea77b0bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
True P2P isn't always possible, witness TURN. So every= one deploying a reliable WebRTC app is going to have bandwidth costs.
<= br>
Those costs will be higher and/or quality much lower, when us= ing H.261 or comparable codecs.

On= Tue, Nov 5, 2013 at 3:59 PM, cowwoc <cowwoc@bbs.darktech.org>= ; wrote:
=20 =20 =20
Justin,

=C2=A0=C2=A0=C2=A0 What happens to P2P video chat? Are we throwing th= at out of the window? A P2P-based mesh is superior to one with AWS in the middle for a couple of reasons:
  • Privacy
  • Cost
  • Consistent latency
  • Ease of deployment
Gili


On 05/11/2013 6:25 PM, Justin Uberti wrote:
The cost equation for CPU versus network is shifted enough in favor of CPU that considering old codecs like H.261 makes no financial sense. If you look at AWS pricing, the CPU cost of reducing bitrate from 1 Mbps to 750 Kbps is more than made up by the network cost.

250 Kbps * 1 hour =3D $0.11
high-compute instance for an hour =3D $0.05 (1 HD transcode = =3D 4 SD transcodes)

Transcoding isn't the bogeyman people are making it out to be.


On Tue, Nov 5, 2013 at 10:06 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
Cullen,

=C2=A0 =C2=A0 In light of the fact that vendors are highly pola= rized 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)

=C2=A0 =C2=A0 Given the final choice (H.261 or no MTI) I suspec= t 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)&quo= t; <mzanaty@cisco= .com>
=C2=A0 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<= /a>> 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
rt= cweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcw= eb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb= @ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



--047d7bdc869e0076e904ea77b0bb-- From martin.thomson@gmail.com Tue Nov 5 17:39:07 2013 Return-Path: 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 EF6F521E8169 for ; Tue, 5 Nov 2013 17:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, 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 vyW34kG0Uzfm for ; Tue, 5 Nov 2013 17:39:06 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A088321E816B for ; Tue, 5 Nov 2013 17:37:27 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id m15so4207724wgh.13 for ; Tue, 05 Nov 2013 17:37:21 -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=5YEfzR625O4nDdpcbTzEcOcxN9/KJAY4va9+Iw36/yM=; b=iyVBQki1KfbAuYwd5AKUQpkb7oIu4MJbzfeKpFEmvJwL4NUTnrUmEyvA2K8OT7NnuZ 1TS7llEPOwW9/MjTNxWq6Wl9A+3YgzbLA2fJ9WePft4pl2vIcP/rOeqE8/V4uIBYDq1W ITiDVnR5KR4tU+G7kPCF7u9ZgEp9xoFDrdbgChSFoqP3+LvB2bYMA/LkMwg3FnOf/VPE z6/epG3TwbLM32KoFqXTNUNYQU+VqocRfe0bn7mNP6e6NXwuvE/gCUpXR4MdRvJVhi3x O7UJqyaGREj9Hh7LEmfBVQ16/eQb/IHJ+XEhQplD3L5DBTrP1/Q16zgCIOBpQkqPxGWz Zm9g== MIME-Version: 1.0 X-Received: by 10.180.9.139 with SMTP id z11mr19155816wia.22.1383701841462; Tue, 05 Nov 2013 17:37:21 -0800 (PST) Received: by 10.227.202.194 with HTTP; Tue, 5 Nov 2013 17:37:21 -0800 (PST) In-Reply-To: References: <52795BF0.1020207@makk.es> Date: Tue, 5 Nov 2013 17:37:21 -0800 Message-ID: From: Martin Thomson To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 01:39:07 -0000 On 5 November 2013 16:36, Wolfgang Beck wrote: > I'm not convinced. How would you explain to the user why he has to login -- > or select an idp -- twice? Maybe this is more an API/W3C topic. As I have said a couple of times already, the user should not have to login more than once. If that were the case, then that would be a problem with the IdP. The generation of an assertion might require login, but validation definitely shouldn't. It's also possible that you already have a session open with your IdP. In that case, you wouldn't necessarily see a login flow at all. From simon.perreault@viagenie.ca Tue Nov 5 17:45:21 2013 Return-Path: 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 9258B21E80CA for ; Tue, 5 Nov 2013 17:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ROzmaS74xC91 for ; Tue, 5 Nov 2013 17:45:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C1E4C21F9D38 for ; Tue, 5 Nov 2013 17:44:12 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 420E740402 for ; Tue, 5 Nov 2013 20:44:12 -0500 (EST) Message-ID: <52799EEB.6030203@viagenie.ca> Date: Tue, 05 Nov 2013 17:44:11 -0800 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52795BF0.1020207@makk.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 01:45:21 -0000 Le 2013-11-05 17:37, Martin Thomson a écrit : > On 5 November 2013 16:36, Wolfgang Beck wrote: >> I'm not convinced. How would you explain to the user why he has to login -- >> or select an idp -- twice? Maybe this is more an API/W3C topic. > > As I have said a couple of times already, the user should not have to > login more than once. If that were the case, then that would be a > problem with the IdP. The generation of an assertion might require > login, but validation definitely shouldn't. > > It's also possible that you already have a session open with your IdP. > In that case, you wouldn't necessarily see a login flow at all. +1 I've been working on IdPs and WebRTC recently, and I also don't see why double login would be necessary. Where does this idea come from? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From cowwoc@bbs.darktech.org Tue Nov 5 17:59:48 2013 Return-Path: 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 D125A11E8163 for ; Tue, 5 Nov 2013 17:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 eL4cHIT4fiyF for ; Tue, 5 Nov 2013 17:59:24 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id C0FCE21E80CD for ; Tue, 5 Nov 2013 17:59:16 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so16106612iet.4 for ; Tue, 05 Nov 2013 17:59:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=sRjzyK+f4+wNSwi8JVamPAE+Ezo96iKdBBpHtnihuTo=; b=Rmn5kNTJ7fLH8DmxLJFCgxG77K7BjNrLvMYyG/ifwSOHeS+o3gTQIOyqH/3TrpqDZN O+a+TqdLWXjDJ30lPgQwk42AoVkZXNMS4ch5H2ueurhw2mUC+05Ucipqus5qVzXKH3uW yzqyuHRQe1gpSDO0z/Z+ol8g0sKcMZ5h7RfAdk/3XOG1bX9J97jwlVdxuMN2ABTkpp1e rj9ytDCZOyUQ8EBmH1WUOQAMzvn8n5zOI7qYt2slz0f6130t/2QNUgxwgj0UPx36tM3B kWocP88aUAx3d1mkNb5xcmcKSYoD9clzRZMfnvsffR5d/cV/z3JsbCAhzPcXLLilL0Eb 7Vzg== X-Gm-Message-State: ALoCoQkFkqG6I9Ai+ZTTQnaP/+HX8uvP7k2ciWFxgVpdCJg1EAnRa6EJtnwlMUIjH2ZJ+HLNw6yl X-Received: by 10.42.215.11 with SMTP id hc11mr352542icb.47.1383703154521; Tue, 05 Nov 2013 17:59:14 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p5sm11548387igj.10.2013.11.05.17.59.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 17:59:13 -0800 (PST) Message-ID: <5279A26F.7030204@bbs.darktech.org> Date: Tue, 05 Nov 2013 20:59:11 -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: Justin Uberti References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <5279866E.1040604@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040406080609000204060706" Cc: "rtcweb@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:59:57 -0000 This is a multi-part message in MIME format. --------------040406080609000204060706 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 05/11/2013 8:01 PM, Justin Uberti wrote: > True P2P isn't always possible, witness TURN. So everyone deploying a > reliable WebRTC app is going to have bandwidth costs. > > Those costs will be higher and/or quality much lower, when using H.261 > or comparable codecs. So what? Assuming the endpoints can't agree on a codec... If you mandate H.261 as MTI, vendors have the choice of either: * Using H.261, or * Upgrading endpoints to H.264/VP8, and transcoding. The choice is theirs. If you don't mandate any codec as MTI, we are *forced* to transcode. Transcoding might be fine for the big boys, but not for indie developers working out of their garage. P2P calls make up the vast majority of cases. I might be willing to lose 5% of users due to lack of TURN support, if it reduces my costs and simplifies my infrastructure. Gili --------------040406080609000204060706 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 05/11/2013 8:01 PM, Justin Uberti wrote:
True P2P isn't always possible, witness TURN. So everyone deploying a reliable WebRTC app is going to have bandwidth costs.

Those costs will be higher and/or quality much lower, when using H.261 or comparable codecs.

    So what? Assuming the endpoints can't agree on a codec... If you mandate H.261 as MTI, vendors have the choice of either:
  • Using H.261, or
  • Upgrading endpoints to H.264/VP8, and transcoding.

    The choice is theirs. If you don't mandate any codec as MTI, we are *forced* to transcode.

    Transcoding might be fine for the big boys, but not for indie developers working out of their garage. P2P calls make up the vast majority of cases. I might be willing to lose 5% of users due to lack of TURN support, if it reduces my costs and simplifies my infrastructure.

Gili
--------------040406080609000204060706-- From wolfgang.beck01@googlemail.com Tue Nov 5 18:01:05 2013 Return-Path: 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 367F221F96CA for ; Tue, 5 Nov 2013 18:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 avSQOnBqHGlk for ; Tue, 5 Nov 2013 18:01:03 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 74B8E11E8163 for ; Tue, 5 Nov 2013 18:00:40 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id ks9so6222333vcb.31 for ; Tue, 05 Nov 2013 18:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ix+heFXaVPy3X3g2JvZBaG311lqcTPiOcAyq6UNZ7Lo=; b=PFWlDeIu/ZwUMFn0h3LXqUqBpVFRSbeRi0jENa4Vmq9UvwPLbzAmfcuHwbWHfFk/Pe lSZjTuoEe8FGM3AcCkBfLogFoVgWgLJvSJ8Xvipkl8F4qdQG+5UsY+zmhAxXrlNNRE0Q aeQkjT4F2djWobjgosgLBcBHfEJ21/ELhdNoSOnNq/yIdT3CnMWAGCfyYjHgQ1OrSr+y XaMp9/lPUYFm9s9wrXPf+q6XPLp9Z4v633GqhtsgW+GT9I2zHm2RbPZpBbIOB9Bdt4Pf Y7bngcxVZk4NcIKWRUAoTPMzfaCbLcux9I0T7m1o7wLWtqlIvKS3ux8ViPjyESOUpU29 XeFA== MIME-Version: 1.0 X-Received: by 10.52.187.138 with SMTP id fs10mr309216vdc.10.1383703208912; Tue, 05 Nov 2013 18:00:08 -0800 (PST) Received: by 10.58.45.169 with HTTP; Tue, 5 Nov 2013 18:00:08 -0800 (PST) Received: by 10.58.45.169 with HTTP; Tue, 5 Nov 2013 18:00:08 -0800 (PST) In-Reply-To: <52799EEB.6030203@viagenie.ca> References: <52795BF0.1020207@makk.es> <52799EEB.6030203@viagenie.ca> Date: Wed, 6 Nov 2013 03:00:08 +0100 Message-ID: From: Wolfgang Beck To: Simon Perreault Content-Type: multipart/alternative; boundary=bcaec548a3853def7104ea7882cd Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 02:01:05 -0000 --bcaec548a3853def7104ea7882cd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The draft proposes a solution where the peerconnection object does an idp exchange of its own. The JS is kept out of the loop. It's not implemented yet. Am 05.11.2013 17:45 schrieb "Simon Perreault" = : > Le 2013-11-05 17:37, Martin Thomson a =E9crit : > >> On 5 November 2013 16:36, Wolfgang Beck >> wrote: >> >>> I'm not convinced. How would you explain to the user why he has to logi= n >>> -- >>> or select an idp -- twice? Maybe this is more an API/W3C topic. >>> >> >> As I have said a couple of times already, the user should not have to >> login more than once. If that were the case, then that would be a >> problem with the IdP. The generation of an assertion might require >> login, but validation definitely shouldn't. >> >> It's also possible that you already have a session open with your IdP. >> In that case, you wouldn't necessarily see a login flow at all. >> > > +1 > > I've been working on IdPs and WebRTC recently, and I also don't see why > double login would be necessary. Where does this idea come from? > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec548a3853def7104ea7882cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The draft proposes a solution where the peerconnection objec= t does an idp exchange of its own. The JS is kept out of the loop. It's= not implemented yet.

Am 05.11.2013 17:45 schrieb "Simon Perreaul= t" <simon.perreault@= viagenie.ca>:
Le 2013-11-05 17:37, Martin Thomson a =E9crit :
On 5 November 2013 16:36, Wolfgang Beck <wolfgang.beck01@googlemail.com<= /a>> wrote:
I'm not convinced. How would you explain to the user why he has to logi= n --
or select an idp -- twice? Maybe this is more an API/W3C topic.

As I have said a couple of times already, the user should not have to
login more than once. =A0If that were the case, then that would be a
problem with the IdP. =A0The generation of an assertion might require
login, but validation definitely shouldn't.

It's also possible that you already have a session open with your IdP.<= br> =A0 In that case, you wouldn't necessarily see a login flow at all.

+1

I've been working on IdPs and WebRTC recently, and I also don't see= why double login would be necessary. Where does this idea come from?

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
--bcaec548a3853def7104ea7882cd-- From wolfgang.beck01@googlemail.com Tue Nov 5 18:15:53 2013 Return-Path: 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 2731411E81E1 for ; Tue, 5 Nov 2013 18:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 yM364k75XVof for ; Tue, 5 Nov 2013 18:15:52 -0800 (PST) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7744211E81C6 for ; Tue, 5 Nov 2013 18:15:52 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id ia6so6137443vcb.21 for ; Tue, 05 Nov 2013 18:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KTrU5d3DJF3x4uflM0vREpN1sqroKY2gd+4f7J9W4eE=; b=fhAWvudn+43GmSyzyUq1Gxbs3AY9w3jgAjh/bxz653i3xNNqo5/xAB+i8PZrVtUiaR llFvrgCyQOa+/yztpT/Hjvv9jvIYK82M8Oqa5GbaBedmdMK13KjrOyyUD/kfIbUaLhyr zZr4z+vbcUeNXThToWu34t8E5fIly6Q5jTkcQnAtnsqDm1imX+JPOIYcA4g9G9KdzUVD cwQesXH6MkGyKXLA01qQgtAMvmDmlS6PsMh5PKxPNpjm/Ze9SCNCqT1LLFIs7Xanaw0j febOaENzWJMBH3M06kk5RwtBAkGd7YLFxRLLPPCBsUA0bU4tE2cy0skIbAQZNe5AqydH /d9g== MIME-Version: 1.0 X-Received: by 10.221.24.70 with SMTP id rd6mr401913vcb.42.1383704151913; Tue, 05 Nov 2013 18:15:51 -0800 (PST) Received: by 10.58.45.169 with HTTP; Tue, 5 Nov 2013 18:15:51 -0800 (PST) Received: by 10.58.45.169 with HTTP; Tue, 5 Nov 2013 18:15:51 -0800 (PST) In-Reply-To: References: <52795BF0.1020207@makk.es> Date: Wed, 6 Nov 2013 03:15:51 +0100 Message-ID: From: Wolfgang Beck To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113360a872febc04ea78ba2b Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 02:15:53 -0000 --001a113360a872febc04ea78ba2b Content-Type: text/plain; charset=ISO-8859-1 What if the server requests a different set of meta data from the idp than the peerconnection object? The idp will have two ask for permission twice. Am 05.11.2013 17:37 schrieb "Martin Thomson" : > On 5 November 2013 16:36, Wolfgang Beck > wrote: > > I'm not convinced. How would you explain to the user why he has to login > -- > > or select an idp -- twice? Maybe this is more an API/W3C topic. > > As I have said a couple of times already, the user should not have to > login more than once. If that were the case, then that would be a > problem with the IdP. The generation of an assertion might require > login, but validation definitely shouldn't. > > It's also possible that you already have a session open with your IdP. > In that case, you wouldn't necessarily see a login flow at all. > --001a113360a872febc04ea78ba2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

What if the server requests a different set of meta data fro= m the idp than the peerconnection object? The idp will have two ask for per= mission twice.

Am 05.11.2013 17:37 schrieb "Martin Thomson= " <martin.thomson@gmail= .com>:
On 5 November 2013 16:36, Wolfgang Beck <wolfgang.beck01@googlemail.com> wrote:
> I'm not convinced. How would you explain to the user why he has to= login --
> or select an idp -- twice? Maybe this is more an API/W3C topic.

As I have said a couple of times already, the user should not have to
login more than once. =A0If that were the case, then that would be a
problem with the IdP. =A0The generation of an assertion might require
login, but validation definitely shouldn't.

It's also possible that you already have a session open with your IdP.<= br> =A0In that case, you wouldn't necessarily see a login flow at all.
--001a113360a872febc04ea78ba2b-- From martin.thomson@gmail.com Tue Nov 5 18:41:55 2013 Return-Path: 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 73F4321F93B9 for ; Tue, 5 Nov 2013 18:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, 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 XFyvpBzxsRoP for ; Tue, 5 Nov 2013 18:41:55 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 12A8221E80C9 for ; Tue, 5 Nov 2013 18:41:41 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id ey11so3089257wid.6 for ; Tue, 05 Nov 2013 18:41:40 -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=PrWKZqea6YOaAFf4TKFEw9jzEFJv9/k/lcfIhMD3+tA=; b=gW0BeT/9ZoM7SzHtEYKozWXtCpP8g6EjQ6dBYEUCwnd0OcKRP2Hgq8RGnkr3zPFgoN SRAkXoOS+rJcSzX3RDcNYqCfPqq34A9ttYD2y72Je0pRUxHI317Wg8qXCJTd+zmUMC1R UgPmYPchue0/W1+Un51G6Jqs/zEe4eFgOJlJHiAwsxKYe/wH+JSfjVkYpnIi2hc9BkpA Zf+ZgMe3dsJbUtKvRrGVaBojVkm8L9ychQBHaavIMS98I3HPuSOPdV0QcuKYPhqaCL54 9ZEvfIV01FZ2+hgXGNuH1ZiaglQpkdTyhMtlJoL5Q5jifa3nPlQzAXpIHLp7xIl5Ojxv MU/w== MIME-Version: 1.0 X-Received: by 10.194.94.167 with SMTP id dd7mr520790wjb.43.1383705700735; Tue, 05 Nov 2013 18:41:40 -0800 (PST) Received: by 10.227.202.194 with HTTP; Tue, 5 Nov 2013 18:41:40 -0800 (PST) In-Reply-To: References: <52795BF0.1020207@makk.es> Date: Tue, 5 Nov 2013 18:41:40 -0800 Message-ID: From: Martin Thomson To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 02:41:55 -0000 On 5 November 2013 18:15, Wolfgang Beck wrote: > What if the server requests a different set of meta data from the idp than > the peerconnection object? The idp will have two ask for permission twice. The number of questions the browser asks the IdP is completely independent of the number of times that the user is required to log in. If you are both generating and validating assertions with the same IdP, you can ask it twice. THe validating IdP does not require login. From mohammedsraad@raadtech.com Tue Nov 5 20:42:31 2013 Return-Path: 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 EBA2221E80A9 for ; Tue, 5 Nov 2013 20:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 mmi4Vj97G8aj for ; Tue, 5 Nov 2013 20:42:27 -0800 (PST) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8A11E80E7 for ; Tue, 5 Nov 2013 20:42:27 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id u57so4340370wes.18 for ; Tue, 05 Nov 2013 20:42:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IahBrXk8JyId8GFivoHj/4mXlvTdFcYxQgcZhDOpwOs=; b=AuxB7Jpp0VgY8mg4i+hOoRz8GBJY09EyzCmDuwGuwGQ40C/quYo0mEGXS03fafTGvz jttdXdKD04Jc4Eg6dPacHvUS+ewh5NXMu/XSGyoua308bRcVIL9S7rP7wuQygLhcmTQX L0zrWQfUt4w0oKrGNgV/Bh3YtLW0YtTz3UEZkiQaC7FheygsfuZVw0VeSwF2FydxwRl+ Ss0cTcb4dveYQznuHQndufeTAt6s1Dewd49VICRaK556pLKHrG0+bAWlPT31dFfwScFh b6XPG9xdMfQEIlpJFS9qzmT0lRqRWVjkNVRFia/ypLnO9FCIHxf5p2RbR/yR+1zZNHmG SV2g== X-Gm-Message-State: ALoCoQk77b+7yKYGjzAUa2M1IolVmN+e4SjLYulvcrBNCzPmJckrbIlmtTFP7KXyHq/iEX7G8K+Q MIME-Version: 1.0 X-Received: by 10.180.184.14 with SMTP id eq14mr818138wic.56.1383712945905; Tue, 05 Nov 2013 20:42:25 -0800 (PST) Received: by 10.194.179.166 with HTTP; Tue, 5 Nov 2013 20:42:25 -0800 (PST) Received: by 10.194.179.166 with HTTP; Tue, 5 Nov 2013 20:42:25 -0800 (PST) In-Reply-To: <52796B1D.5030704@bbs.darktech.org> References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <52796B1D.5030704@bbs.darktech.org> Date: Wed, 6 Nov 2013 15:42:25 +1100 Message-ID: From: Mohammed Raad To: cowwoc Content-Type: multipart/alternative; boundary=001a11c2436e9cba8804ea7ac6bd Cc: rtcweb@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 04:42:32 -0000 --001a11c2436e9cba8804ea7ac6bd Content-Type: text/plain; charset=ISO-8859-1 Is WebRTC only intended for P2P implementations? Granted, you can't get pure P2P if you have a gateway in the middle, but this would only be the case for connections between endpoints that have not implemented the same MTI. Mohammed On Nov 6, 2013 9:03 AM, "cowwoc" wrote: > Mohammed, > > Your approach does not work for the typical browser-to-browser (P2P) > connections. > > Gili > > On 05/11/2013 4:31 PM, Mohammed Raad wrote: > > Hi, > > Given the lack of agreement on a single MTI, for business reasons > primarily, and given that the debate is really focused on two candidates, I > suggest that a transcoding function between these two codecs be defined at > the service provider level. > > I suggest that the transcoding function only include the VP8 and AVC CBP > to make the development and use of this part of the service feasible. > > Having such a function would allow different organizations to make their > own decision about what works for them. I sense that different experts have > become entrenched in their respective positions with very little freedom to > make a change, for multiple reasons. I think it should be clear that having > transcoding at the service level would be a reasonable compromise. Note > that no end device would be required to perform the transcoding, this would > be done at the service provider level. > > BR, > Mohammed > On Nov 6, 2013 5:07 AM, "cowwoc" wrote: > >> 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)" >>> 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 wrote: >>>> >>>> On 5 November 2013 06:18, Hutton, Andrew >>>> 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 listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c2436e9cba8804ea7ac6bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Is WebRTC only intended for P2P implementations? Granted, yo= u can't get pure P2P if you have a gateway in the middle, but this woul= d only be the case for connections between endpoints that have not implemen= ted the same MTI.

Mohammed

On Nov 6, 2013 9:03 AM, "cowwoc" <<= a href=3D"mailto:cowwoc@bbs.darktech.org">cowwoc@bbs.darktech.org> w= rote:
=20 =20 =20
Mohammed,

=A0=A0=A0 Your approach does not work for the typical browser-to-brow= ser (P2P) connections.

Gili

On 05/11/2013 4:31 PM, Mohammed Raad wrote:

Hi,

Given the lack of agreement on a single MTI, for business reasons primarily, and given that the debate is really focused on two candidates, I suggest that a transcoding function between these two codecs be defined at the service provider level.

I suggest that the transcoding function only include the VP8 and AVC CBP to make the development and use of this part of the service feasible.=A0

Having such a function would allow different organizations to make their own decision about what works for them. I sense that different experts have become entrenched in their respective positions with very little freedom to make a change, for multiple reasons. I think it should be clear that having transcoding at the service level would be a reasonable compromise. Note that no end device would be required to perform the transcoding, this would be done at the service provider level.

BR,
Mohammed

On Nov 6, 2013 5:07 AM, "cowwoc"= <cowwoc@bb= s.darktech.org> wrote:
Cullen,

=A0 =A0 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)

=A0 =A0 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>
=A0 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@i= etf.org
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@iet= f.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

--001a11c2436e9cba8804ea7ac6bd-- From mzanaty@cisco.com Tue Nov 5 21:20:27 2013 Return-Path: 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 8678921E80B1 for ; Tue, 5 Nov 2013 21:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.409 X-Spam-Level: X-Spam-Status: No, score=-10.409 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 0DxZZwrjMqHL for ; Tue, 5 Nov 2013 21:20:22 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5AABF21E80AE for ; Tue, 5 Nov 2013 21:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22964; q=dns/txt; s=iport; t=1383715222; x=1384924822; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=R2HWZ3Ll0qKu4XnLZSTMBtyseD4Gac9hoWkegNICIqE=; b=efO51CFbX5/MovcjEUUwgsfpYdBR3NLFdfNiIgZt66JQ5KM5HN0/Kzeu nsdUPPQIOv7yGJV8eaEd1cfCdo7Exe4unBQUtkZ+mH+fEYYqMRNXvTgIG 1SMLQnSEX/Ye+nV0DFZH7H+vrc5mKA0eoidoRVNKBpayvQ8nSPLMvXnH0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAG7QeVKtJV2c/2dsb2JhbABZgkNEOFO/AUuBJRZ0giUBAQEEAQEBKkELEgEIEQQBASgoBgsUAwEFCAIEAQ0FFAeHVAMPDbRVDYlnBIxngk4gBAYBhC8DhVSQS4FrjFKFN4Mmgio X-IronPort-AV: E=Sophos;i="4.93,644,1378857600"; d="scan'208,217";a="281321064" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 06 Nov 2013 05:20:21 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA65KLkp022822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 05:20:21 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 23:20:20 -0600 From: "Mo Zanaty (mzanaty)" To: "Markus.Isomaki@nokia.com" , "juberti@google.com" , "randell-ietf@jesup.org" Thread-Topic: [rtcweb] Platforms that support H264 Thread-Index: AQHO2q/i0OsOgTLqXE2Wnbsc3UuMdA== Date: Wed, 6 Nov 2013 05:20:20 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.248.188] Content-Type: multipart/alternative; boundary="_000_CE9F22801C16Bmzanatyciscocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Platforms that support H264 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 05:20:27 -0000 --_000_CE9F22801C16Bmzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Note that fixing the OS API issues helps all codecs. We should all be suppo= rtive of that, not using the issues as an excuse to ignore hardware benefit= s or abandon good engineering design. The Google Nexus 5 can encode and dec= ode 1080p60 H.264 or VP8 fully in hardware. Why should Chrome, Hangouts or = other Google apps not take advantage of a Google hardware codec on a Google= phone/OS? Forget H.264 vs. VP8 for a moment. If you have codec X available at 1080p60= in hardware, why fallback to software? Randell, I feel your pain on getting hardware access to work reliably and u= niversally. We have gone through this for several apps and platforms, and i= t is indeed a pain, and sometimes you still need software fallback. But it = is better than giving up and always relying on software fallback. I applaud= Firefox for wrestling with Android APIs, and encourage you and others to c= ontinue doing so for all hardware codecs. (We will get more than H.264 or V= P8 in next year=92s silicon, so this will pay off even more.) Mo On 11/5/13, 7:24 PM, Markus.Isomaki@nokia.com > wrote: Hi, I agree there is definitely a need to improve the access to the H.264 =93H= W=94 codecs so they would be realistically usable for WebRTC or other inter= active video apps. But that still seems to me as the best way forward compa= red to the other options. I know improvements are coming at least to Window= s Phone and Windows RT. Markus From: rtcweb-bounces@ietf.org [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of ext Justin Uberti Sent: 06 November, 2013 00:58 To: Randell Jesup Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Platforms that support H264 On Tue, Nov 5, 2013 at 6:58 AM, Randell Jesup > wrote: On 11/5/2013 12:55 AM, Mo Zanaty (mzanaty) wrote: I=92m serious. Name a device in mass production that is relevant to rtcweb = but does not have H.264 hardware. Plenty have hardware is out there that might not be optimized (or usable) f= or the types of arbitrary-sized, realtime simultaneous h.264 encode/decode.= Even just handling streaming decode on Android via OMX has been a year of= pain for one of our engineers, because (especially before JB) the interfac= es were unsupported, randomly modified/incompatible, and with lots of restr= ictions on what actually is supported. Even with "perfect" API layers expo= sing them, the hardware layers (especially encoders) may not have the low-l= atency and other realtime characteristics needed, or knobs to tell them abo= ut things like packet loss reports that require IDR generation. How many d= oes this affect? who knows - and the API layers on top are inconsistent eno= ugh (or non-existent at the present) that it's especially hard to tell. And many of them can handle only a single stream at a time; which makes "ha= ngout"/simulcast cases more fun (need to run HW and SW in parallel, or drop= to SW only - makes capability signaling fun too; the LCD of the SW and HW = codecs needs to be what you offer probably, unless you want real pain). Exactly. Name a 3rd-party software application in wide use on any of today'= s popular platforms that uses a H.264 HW encoder for rtcweb scenarios. Your second point is valid; hardware is useless without supporting software= . OS APIs to access codecs (both hardware and software, real-time and buffe= red) is an important issue. Android is the dominant OS on the planet. If yo= u are not happy with its OS APIs, just change them; it=92s open source like= VP8 right? Not really. You can't modify the underlying OS provided by the manufacture= r (no rooting of phones to run webrtc should be required...) and even cust= om roms are going to get much harder or virtually impossible with kitkat. = And witness my comments about the pain of platform decoders on Android tod= ay. Randell Mo On 11/5/13, 1:10 AM, cowwoc > wrote: I'm not sure if you're being sarcastic or not... In any case, I had a question regarding BlackBerry 10. Are you implying= that every BlackBerry 10 phone includes an API for real-time encoding/deco= ding of H.264 video streams? If so, which API is it? I took a quick look bu= t couldn't find it. Thanksm Gili On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote: I think you meant *every* phone, tablet, laptop, desktop, set-top, camera= =85 On 11/2/13, 7:41 PM, Kaiduan Xie > wrote: Every BlackBerry 10 phone has H.264 hardware encoder/decoder. /Kaiduan On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla > wrote: On Sat, Nov 2, 2013 at 1:01 PM, Gili > wrote: Martin, I fully understand why Firefox would be happy but as someone who plan t= o integrate WebRTC into a non-browser application, especially on iOS, Cisco= 's solution simply does not work. I appreciate their contribution, but agai= n, it simply doesn't help my use-case. I haven't seen you explain how your use case is different from that of a browser. Could you please do so? -Ekr Gili On 11/2/2013 11:02 AM, Martin Thomson wrote: On 2 November 2013 07:37, cowwoc > wrote: I can't think of a single platform that supports real-time H.264 encoding/decoding natively today. That's a very strange way to put the question. Let me put another spin on it, and please excuse the example... Skype runs on more platforms than you might think. Those platforms can all support H.264 to the extent that Skype requires. Cisco's generous offer opens almost the same capability to anyone, with the caveat that some platforms currently remain closed. Of course, you could let your ideals get in the way of progress. Me, I'm a pragmatist. This gift represents a great opportunity for people who actually care about the practical outcomes. There's been a lot of mouth-gazing of gift horses on this list of late. I sure hope that this isn't representative of the real sentiment of the community. I'd like to think that people are better than that. (BTW, I understand and respect Harald's position. From where he sits, I'm sure that his conclusion makes perfect sense.) -- Randell Jesup randell-ietf@jesup.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CE9F22801C16Bmzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <06026BDE2F12E44DA8A08A084C4EFF1A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Note that fixing the OS API issues helps all codecs. We should all be = supportive of that, not using the issues as an excuse to ignore hardware be= nefits or abandon good engineering design. The Google Nexus 5 can encode an= d decode 1080p60 H.264 or VP8 fully in hardware. Why should Chrome, Hangouts or other Google apps not take adv= antage of a Google hardware codec on a Google phone/OS?

Forget H.264 vs. VP8 for a moment. If you have codec X available at 10= 80p60 in hardware, why fallback to software?

Randell, I feel your pain on getting hardware access to work reliably = and universally. We have gone through this for several apps and platforms, = and it is indeed a pain, and sometimes you still need software fallback. Bu= t it is better than giving up and always relying on software fallback. I applaud Firefox for wrestling with = Android APIs, and encourage you and others to continue doing so for all har= dware codecs. (We will get more than H.264 or VP8 in next year=92s silicon,= so this will pay off even more.)

Mo



Hi,

 

I agree there is definitely a need = to improve the access to the H.264  =93HW=94 codecs so they would be r= ealistically usable for WebRTC or other interactive video apps. But that still seems to me as the best way forward compared to= the other options. I know improvements are coming at least to Windows Phon= e and Windows RT.

 

Markus

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Justin Uberti
Sent: 06 November, 2013 00:58
To: Randell Jesup
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Platforms that support H264<= /p>

 

 

 

On Tue, Nov 5, 2013 at 6:58 AM, Randell Jesup <randell-ietf@jesu= p.org> wrote:

On 11/5/2013 12:55 AM, Mo Zanaty (mzanaty) wrote:

I=92m serious. Name a device in mass production that= is relevant to rtcweb but does not have H.264 hardware.

 

Plenty have hardware is out there that might not be = optimized (or usable) for the types of arbitrary-sized, realtime simultaneo= us h.264 encode/decode.  Even just handling streaming decode on Androi= d via OMX has been a year of pain for one of our engineers, because (especially before JB) the interfaces were unsup= ported, randomly modified/incompatible, and with lots of restrictions on wh= at actually is supported.  Even with "perfect" API layers ex= posing them, the hardware layers (especially encoders) may not have the low-latency and other realtime characteristics needed, or= knobs to tell them about things like packet loss reports that require IDR = generation.  How many does this affect? who knows - and the API layers= on top are inconsistent enough (or non-existent at the present) that it's especially hard to tell.

And many of them can handle only a single stream at a time; which makes &qu= ot;hangout"/simulcast cases more fun (need to run HW and SW in paralle= l, or drop to SW only - makes capability signaling fun too; the LCD of the = SW and HW codecs needs to be what you offer probably, unless you want real pain).

 

Exactly. Name a 3rd-party software application in wi= de use on any of today's popular platforms that uses a H.264 HW encoder for= rtcweb scenarios.




 

Your second point is valid; hardware is useless with= out supporting software. OS APIs to access codecs (both hardware and softwa= re, real-time and buffered) is an important issue. Android is the dominant = OS on the planet. If you are not happy with its OS APIs, just change them; it=92s open source like VP8 right?

 

Not really.  You can't modify the underlying OS= provided by the manufacturer (no rooting of phones to run webrtc should be= required...)  and even custom roms are going to get much harder or vi= rtually impossible  with kitkat.  And witness my comments about the pain of platform decoders on Android today.

   Randell




 

Mo

 

 

On 11/5/13, 1:10 AM, cowwoc <cowwoc@bbs.darktech.org> wr= ote:

 


    I'm not sure if you're being sarcastic or not...

    In any case, I had a question regarding BlackBerry 10. A= re you implying that every BlackBerry 10 phone includes an API for real-tim= e encoding/decoding of H.264 video streams? If so, which API is it? I took = a quick look but couldn't find it.

Thanksm
Gili

On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote:

I think you meant *every* phone, tablet, laptop, des= ktop, set-top, camera=85 

 

 

On 11/2/13, 7:41 PM, Kaiduan Xie <kaiduanx@gmail.com> wrote:<= o:p>

 

Every BlackBerry 10 phone has H.264 hardware encoder= /decoder.

 

/Kaiduan

 

On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:=

 

 

I haven't seen  you explain how your use case i= s different from that of

a browser. Could you please do so?

 

-Ekr

 

Gili



On 11/2/2013 11:02 AM, Martin Thomson wrote:

On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org&g= t; wrote:

     I can't think of a single platfo= rm that supports real-time H.264
encoding/decoding natively today.

That's a very strange= way to put the question.

Let me put another spin on it, and please excuse the example...

Skype runs on more platforms than you might think.  Those platforms can all support H.264 to the extent that Skype requires.

Cisco's generous offer opens almost the same capabil= ity to anyone,
with the caveat that some platforms currently remain closed.  Of
course, you could let your ideals get in the way of progress.  Me, I'm=
a pragmatist.  This gift represents a great opportunity for people who=
actually care about the practical outcomes.

There's been a lot of mouth-gazing of gift horses on this list of
late.  I sure hope that this isn't representative of the real
sentiment of the community.  I'd like to think that people are better<= br> than that.

(BTW, I understand and respect Harald's position.  From where he sits,=
I'm sure that his conclusion makes perfect sense.)

 

 

-- 
Randell Jesup
randell-ietf@jesup.org


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

 

 --_000_CE9F22801C16Bmzanatyciscocom_-- From cowwoc@bbs.darktech.org Tue Nov 5 21:20:32 2013 Return-Path: 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 D30F021E80DC for ; Tue, 5 Nov 2013 21:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.452 X-Spam-Level: X-Spam-Status: No, score=-4.452 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 GDK91vxfqIff for ; Tue, 5 Nov 2013 21:20:28 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id EA57E21E80AE for ; Tue, 5 Nov 2013 21:20:27 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id qd12so16580770ieb.5 for ; Tue, 05 Nov 2013 21:20:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=1Zas8YoZEJKl44HmA0rwijPYt6TRvYEDaMR4c47fRns=; b=ZZL1H3HXDqkWzhdFI1eMztePnef/KtwcKSgNl2+bWDyXgCoG9bD/1sXUAV2LnsrRNV 92DPQEuq97kX1GxIR/D+mpGre8MAgb7110hb+HnQfrZqSUDDVrdIuifyrLfl48gZC4Ib LBoOrsaVOD8X3WxAuVsghEwdyNn8Br+f2kwV0JskyaPrwI8WQyw774UzJ2Yc7cyURjgS Z67+THlDpE6SUKO90aXla2YYjD7ebyTjzm2tRjgtRrFSG959k7Iuhvj5AAIA7HIO83SA /ZWxxPt7Yx6iPeLuxN7UO4j37INmVzvfeCFjpBVA5YgvW9A8Ng0ng08FDVzI4wduyYys Uf8Q== X-Gm-Message-State: ALoCoQnMrdMAMo6qKmY4tA90nvIHMykMQUZKeZroiox8Isz7pmJYlNBO4Mjjrn9/UX9VShpBIaKk X-Received: by 10.42.227.72 with SMTP id iz8mr810395icb.27.1383715227198; Tue, 05 Nov 2013 21:20:27 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id hv5sm12370794igb.9.2013.11.05.21.20.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 21:20:26 -0800 (PST) Message-ID: <5279D197.7050107@bbs.darktech.org> Date: Wed, 06 Nov 2013 00:20:23 -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: Mohammed Raad References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <52796B1D.5030704@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030508020903040606030508" Cc: rtcweb@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 05:20:32 -0000 This is a multi-part message in MIME format. --------------030508020903040606030508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I didn't mean to imply that we should only support the P2P use-case, but it is an important use-case to support. The problem with your solution is that for the P2P use-case where the endpoints don't implement the same codec, the connection would simply fail. Depending on your application, up to 95%+ of calls can be P2P. It is possible/probably that Chrome might only implement VP8 and IE/Safari might only implement H.264. In such a case, you have a fairly large probability of failure (less than 50% but still large). Whatever solution we could up with should have a 95% chance of success for both P2P and gateway use-cases. Gili On 05/11/2013 11:42 PM, Mohammed Raad wrote: > > Is WebRTC only intended for P2P implementations? Granted, you can't > get pure P2P if you have a gateway in the middle, but this would only > be the case for connections between endpoints that have not > implemented the same MTI. > > Mohammed > > On Nov 6, 2013 9:03 AM, "cowwoc" > wrote: > > Mohammed, > > Your approach does not work for the typical browser-to-browser > (P2P) connections. > > Gili > > On 05/11/2013 4:31 PM, Mohammed Raad wrote: >> >> Hi, >> >> Given the lack of agreement on a single MTI, for business reasons >> primarily, and given that the debate is really focused on two >> candidates, I suggest that a transcoding function between these >> two codecs be defined at the service provider level. >> >> I suggest that the transcoding function only include the VP8 and >> AVC CBP to make the development and use of this part of the >> service feasible. >> >> Having such a function would allow different organizations to >> make their own decision about what works for them. I sense that >> different experts have become entrenched in their respective >> positions with very little freedom to make a change, for multiple >> reasons. I think it should be clear that having transcoding at >> the service level would be a reasonable compromise. Note that no >> end device would be required to perform the transcoding, this >> would be done at the service provider level. >> >> BR, >> Mohammed >> >> On Nov 6, 2013 5:07 AM, "cowwoc" > > wrote: >> >> 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)" >> > >> 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 >> > > wrote: >> >> On 5 November 2013 06:18, Hutton, Andrew >> > > 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 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --------------030508020903040606030508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    I didn't mean to imply that we should only support the P2P use-case, but it is an important use-case to support. The problem with your solution is that for the P2P use-case where the endpoints don't implement the same codec, the connection would simply fail.

    Depending on your application, up to 95%+ of calls can be P2P. It is possible/probably that Chrome might only implement VP8 and IE/Safari might only implement H.264. In such a case, you have a fairly large probability of failure (less than 50% but still large). Whatever solution we could up with should have a 95% chance of success for both P2P and gateway use-cases.

Gili

On 05/11/2013 11:42 PM, Mohammed Raad wrote:

Is WebRTC only intended for P2P implementations? Granted, you can't get pure P2P if you have a gateway in the middle, but this would only be the case for connections between endpoints that have not implemented the same MTI.

Mohammed

On Nov 6, 2013 9:03 AM, "cowwoc" <cowwoc@bbs.darktech.org> wrote:
Mohammed,

    Your approach does not work for the typical browser-to-browser (P2P) connections.

Gili

On 05/11/2013 4:31 PM, Mohammed Raad wrote:

Hi,

Given the lack of agreement on a single MTI, for business reasons primarily, and given that the debate is really focused on two candidates, I suggest that a transcoding function between these two codecs be defined at the service provider level.

I suggest that the transcoding function only include the VP8 and AVC CBP to make the development and use of this part of the service feasible. 

Having such a function would allow different organizations to make their own decision about what works for them. I sense that different experts have become entrenched in their respective positions with very little freedom to make a change, for multiple reasons. I think it should be clear that having transcoding at the service level would be a reasonable compromise. Note that no end device would be required to perform the transcoding, this would be done at the service provider level.

BR,
Mohammed

On Nov 6, 2013 5:07 AM, "cowwoc" <cowwoc@bbs.darktech.org> wrote:
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


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--------------030508020903040606030508-- From mail@makk.es Wed Nov 6 00:36:08 2013 Return-Path: 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 E085921E809B for ; Wed, 6 Nov 2013 00:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 fqvOPhzInrXZ for ; Wed, 6 Nov 2013 00:36:03 -0800 (PST) Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id 25B0311E8194 for ; Wed, 6 Nov 2013 00:36:00 -0800 (PST) Received: (qmail 10707 invoked from network); 6 Nov 2013 08:35:56 -0000 Received: from unknown (HELO ?141.22.28.177?) (141.22.28.177) by lupus.uberspace.de with SMTP; 6 Nov 2013 08:35:56 -0000 Message-ID: <5279FF69.5040206@makk.es> Date: Wed, 06 Nov 2013 09:35:53 +0100 From: Max Jonas Werner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Wolfgang Beck References: <52795BF0.1020207@makk.es> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qgNEaGmXe5DkWcS51UUTeOdkUr70NQCp6" Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 08:36:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qgNEaGmXe5DkWcS51UUTeOdkUr70NQCp6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wolfgang, On 05.11.2013 23:03, Wolfgang Beck wrote: > According to the draft and the w3c doc, the Idp exchange is completely > hidden from the JS. I don't see how a web server could use the result t= o > verify the user without looking at the SDP. Or how the peerconnection c= ould > reuse the result of an Idp exchange that authenticated the user towards= the > server. Did I overlook something? >=20 > Having to log in twice will only be tolerated by a small minority of > people. I propose you read the draft again since perhaps you overlooked something. Let me give you an example: You have a WebRTC application that's served from your domain example.com. Perhaps you've implemented some kind of login mechanism so the user logs in (using an HTML form perhaps) resulting in e.g. a cookie being saved in the user's browser carrying a session ID (again, this is just _one_ possibility). Your application creates a PeerConnection object and calls setIdentityProvider with the parameter "domain" set to "example.com" and the parameter "protocol" set to "proto" because you want to be your own IdP. When creating an offer the browser will then load the code from https://example.com/.well-known/idp-proxy/proto into an iframe or such and send a message to that code asking for an assertion. Since the IdP proxy code is served from the same origin it may read out the cookie value set earlier when logging the user in. This cookie value can now be used on the server side to automatically (as in without user interaction) create an assertion since the server already knows who the user is (from the cookie). This also works with using another IdP (say Facebook) with your application served from example.com. If the user is already logged into Facebook: no interaction needed. Max --qgNEaGmXe5DkWcS51UUTeOdkUr70NQCp6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFSef9q1IVn4/X13N8RArykAJ4y9qndtnMCIQeE7zrdPyEy4WmNRgCffYfo xzW/O5zZYl38tF6vkAF4FkM= =sXUI -----END PGP SIGNATURE----- --qgNEaGmXe5DkWcS51UUTeOdkUr70NQCp6-- From ron@debian.org Wed Nov 6 00:44:35 2013 Return-Path: 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 1E5D821E80ED for ; Wed, 6 Nov 2013 00:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] 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 GYVeSQGpZAww for ; Wed, 6 Nov 2013 00:44:30 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 7E85C21E8105 for ; Wed, 6 Nov 2013 00:44:29 -0800 (PST) Received: from ppp121-45-83-213.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.83.213]) by ipmail06.adl2.internode.on.net with ESMTP; 06 Nov 2013 19:14:27 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id B69B44F8F3 for ; Wed, 6 Nov 2013 19:14:24 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1-2Wwn5oBbCD for ; Wed, 6 Nov 2013 19:14:23 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id CF5BE4F902; Wed, 6 Nov 2013 19:14:23 +1030 (CST) Date: Wed, 6 Nov 2013 19:14:23 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131106084423.GC3245@audi.shelbyville.oz> References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5279339B.9040506@bbs.darktech.org> User-Agent: Mutt/1.5.20 (2009-06-14) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 08:44:35 -0000 On Tue, Nov 05, 2013 at 01:06:19PM -0500, cowwoc wrote: > In light of the fact that vendors are highly polarized on this > topic, I'd like to suggest the following voting order: I don't think it's really all that relevant for rough consensus if 'vendors are highly polarised' on the question at all. If you make that a consideration, I'm sure you can find some vendors (who may or may not be present here) who strongly wish that WebRTC will never exist at all in the form that this group's charter has envisaged, since its success would pose a very real threat to their current business monopolies. That doesn't give them a right of veto to this work, though their input, like everyone else's, still merits consideration for its technical contribution to best achieving the charter's aims. Having a favourite horse in a race is fine. Having that horse be the fittest to win is a far more objective measurement. The question of choosing a MTI codec hinges on interoperability, and we have established consensus that having a viable MTI codec is quite crucial for this. Right now we have 2 proposed candidates. So the important questions are: - Are either of those candidates suitable? - Is one clearly more suitable than the other? And the present question has been framed by the WG chairs as: - Are there reasons that people could not possibly use either choice? The reasons that people cannot possibly use H.264 are well established. Its licencing simply does not permit people to use it in all the varied ways that implementors and users of WebRTC would require. The Cisco announcement was clearly an attempt to mitigate this fatal constraint for their preferred choice, and while it goes some way toward doing that - and is certainly a bold and perceptive step for them to take to maintain the value of their existing investment - they are still constrained by these same licencing terms to only be able to offer a very limited solution, of limited use, to a limited number of people. And they still can't offer the sort of indemnity that the H.264 camp has demanded from VP8 in draft-dbenham-webrtc-videomti-02, and they aren't even offering a licence to _all_ of the known IPR covering H.264, only to that covered by the MPEG LA pool - which the Nokia portfolio, some of which was already disclosed, is notably outside of. The reasons that people cannot possibly use VP8 are far less clear. None of the objections beyond "we don't want to" so far have any grounding in reality. The "but but submarine IPR!!" argument applies equally to *anything* that any WG might chose to do or use. Nokia tried to pull some out of their hat, but they lost in court. If they couldn't torpedo this, then the chances of anyone else being able to seem significantly diminished. But the validity of their claims over H.264 are not challenged at all, and remain a clear and present danger for anyone using H.264. Perhaps even more so now than ever, given their current financial situation and being the subject of a takeover bid. This is why I believe that although we have 2 proposals, only one of them can seriously stand up to scrutiny for being an acceptable choice that passes the muster of rough consensus. "We don't want to" is not a blocker for consensus. "The licence of this does not permit us to" is a very real blocker. Given we have consensus for picking an MTI codec, the only reason not to pick that remaining choice would be if someone springs yet another last minute surprise which would delay that decision again. If that actually happens, then maybe we can once again have the H.261 vs Theora debate - but if it doesn't, then VP8 is still the no-brainer choice that can stand up to the full test of having rough consensus and working code that meets the goals of this WG. Re this suggestion: > 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. You might want to review the list archives. This question has already been debated, and I thought the result of that was conclusive, and why we have only the current proposals that we do today. Cheers, Ron From singer@apple.com Wed Nov 6 00:54:07 2013 Return-Path: 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 DC78D21F9B8A for ; Wed, 6 Nov 2013 00:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 qw24uZAY4wzE for ; Wed, 6 Nov 2013 00:54:02 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) by ietfa.amsl.com (Postfix) with ESMTP id 000EB21F9C10 for ; Wed, 6 Nov 2013 00:54:01 -0800 (PST) Received: from relay3.asia.apple.com ( [17.82.200.17]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id FF.B8.03695.8A30A725; Wed, 6 Nov 2013 16:54:00 +0800 (MYT) X-AuditID: 1152fe06-b7f5a6d000000e6f-b3-527a03a8fda8 Received: from gambooge.asia.apple.com ( [17.82.200.120]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id AB.91.26194.8A30A725; Wed, 6 Nov 2013 16:54:00 +0800 (MYT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.83.34.177] (unknown [17.83.34.177]) by mail.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVU007AZ3DZTL40@mail.asia.apple.com> for rtcweb@ietf.org; Wed, 06 Nov 2013 16:54:00 +0800 (SGT) From: David Singer In-reply-to: Date: Wed, 06 Nov 2013 17:53:57 +0900 Message-id: References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> To: bryandonnovan@gmail.com X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUiGHRCUHcFc1WQwcpDqhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/mWa2wFLawVvVdvsDYwtrF0MXJySAiYSLz52cEGYYtJXLi3 Hsjm4hAS2M0oMenaNyaYoi3vXrBDJPqZJG7PmMgMkuAVEJT4Mfke0CQODmYBeYmD52VBwswC WhLfH7WyQNQvZJJovPwQrF5YwEjizsYWRhCbTUBV4sGcY2A2p0CwxPrrC8AuYgGKdz49xAQx SFdi1aIr7BC7bCR+bFgKdqmQwBwmiT0T00FsEQFpiYs32xkhDpWVOH3uOdhiCYGvrBLXN51m nMAoPAvJrbMQbp2F5NYFjMyrGMVzEzNzdDPzjPQSizMT9RILCnJS9ZLzczcxggP6H9sOxgWv DQ8xCnAwKvHwzn5bFCTEmlhWXJl7iFGCg1lJhPczU1WQEG9KYmVValF+fFFpTmrxIUZpDhYl cd7ff8uDhATSE0tSs1NTC1KLYLJMHJxSDYzTLpyavG1d5a0dsuaCD/gMfK6d4Ny5gj92W+zz +yozfFaum/pVW1LqwYTQA2UG6+LK335ado/zdZJ28ZXaQ0pVi2aEZhsbf71+WFCv8vXXGxx9 T998mt/bcG637XNP6cSOMwIrGO1Sv2vEMexYZ54pUvNYjk11XoNlVqzcsvsRbJ8ajqzuYhdT YinOSDTUYi4qTgQA/LiAhGQCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUiGHSiQncFc1WQwfrFyhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/mWa2wFLawVvVdvsDYwtrF0MXJySAiYSGx594IdwhaTuHBv PVsXIxeHkEA/k8TtGROZQRK8AoISPybfA2rg4GAWkJc4eF4WJMwsoCXx/VErC0T9QiaJxssP weqFBYwk7mxsYQSx2QRUJR7MOQZmcwoES6y/vgBsMQtQvPPpISaIQboSqxZdYYfYZSPxY8NS NhBbSGAOk8SeiekgtoiAtMTFm+2MEIfKSpw+95xlAqPALCTnzUI4bxaS8xYwMq9iFC1KzUms NNZLLM5M1EssKMhJ1UvOz93ECAlAwR2MH6YaHmIU4GBU4uFlel0UJMSaWFZcmXuIUYKDWUmE d+PbyiAh3pTEyqrUovz4otKc1OJDjNIcLErivLL/yoOEBNITS1KzU1MLUotgskwcnFINjE5u /Z+2ekV0PsqUDz84e03GY87uYveTN1OZhH+Kzb+8X+fA5FseUpoRRX9j+7R6Woq2eX1ZMNsz 6e0V2WbHW3MDfuuFhbgrlpWndGZNXPjR3bvqRJfTyWUBsaGOj5/GfnNJTr70X0lkyqwIhiUe vX9bpjm6ZpcyfNrU9TSgqUgs+6Ka0EkZJZbijERDLeai4kQALyn+eDwCAAA= Cc: rtcweb@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 08:54:08 -0000 On Nov 6, 2013, at 9:53 , bryandonnovan@gmail.com wrote: > > "real IPR issue" : ability to compile and distribute an h.264 codec without getting a license and paying royalties. > > "not real IPR issue" : claims made against Opus by Qualcomm and Huawei where does Nokia's statement fall, in your opinion? > > On Tue, Nov 5, 2013 at 4:28 PM, wrote: > > Define "real IPR issue". > > Markus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb David Singer Multimedia and Software Standards, Apple Inc. From cowwoc@bbs.darktech.org Wed Nov 6 01:01:46 2013 Return-Path: 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 6F39B21F9A97 for ; Wed, 6 Nov 2013 01:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 u58hcZThqvgO for ; Wed, 6 Nov 2013 01:01:42 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id EAD7B21F9C68 for ; Wed, 6 Nov 2013 01:01:41 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id qd12so16618086ieb.19 for ; Wed, 06 Nov 2013 01:01:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nlmEAPJUgYJXXiPYaOVhB1MVi7yZz7KSxsj7RmxF8lU=; b=k0pl1SirsgvCwolzbEnie//y5ZJ1QbzoWQNGvmqgzVe2FGdAHfxuUd1CxuTKzVxQMC EY399sEq6WkilRvkj0a+t3winoxtl+3IWLOKPQ0rZ0LGPblOOT4ZidzwcRAkbPAWGdDI bF5ybTHx9x5SM8/26eyxLErBn7DerIri2N7XABVViby1Utqqi4vw9zV++Fw8uyxY+MF3 yIlicCp7DhhP10j/xQGb6CaxYNn/QCvauowqgmNgRNtUfGEa913ALKHhZvLODX2oepHA +FG3QYPtNob7pVCR6bZDTORiFqfvYKOEj95YKa2eCKeG3jS1uvy1QHaUYx+zP9nxO0t3 4FSA== X-Gm-Message-State: ALoCoQlaEAhPe/8HS2+j/teAgE4Rfpy8sIZyMw96wjtrYC4lyD6qjuH7QYR2ftDFyqAi0tB8TXO/ X-Received: by 10.50.225.39 with SMTP id rh7mr1650932igc.10.1383728500895; Wed, 06 Nov 2013 01:01:40 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ft2sm13087890igb.5.2013.11.06.01.01.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 01:01:40 -0800 (PST) Message-ID: <527A0572.5000207@bbs.darktech.org> Date: Wed, 06 Nov 2013 04:01:38 -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: rtcweb@ietf.org References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <20131106084423.GC3245@audi.shelbyville.oz> In-Reply-To: <20131106084423.GC3245@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 09:01:46 -0000 > "We don't want to" is not a blocker for consensus. Nice in theory, but that's not how things work in practice. Vendors have some very good (albeit subjective) reasons to align themselves with VP8 or H.264 and I don't fault them for doing so. Ignoring this reality will lead to a never-ending lack of consensus. Knowing that everyone will continue pushing their favorite horse regardless of the facts, I reiterate my proposal for a multi-phased vote, making it clear in advance that if we reach the last phase without a compromise we are implicitly voting for transcoding. The vote should end with a decision being made, one way or the other. TokBox enumerated some concrete compromises needed from either side: http://www.tokbox.com/blog/is-webrtc-ready-for-h-264/ ... We need to start moving down that road in order to meet in the middle. Gili On 06/11/2013 3:44 AM, Ron wrote: > On Tue, Nov 05, 2013 at 01:06:19PM -0500, cowwoc wrote: >> In light of the fact that vendors are highly polarized on this >> topic, I'd like to suggest the following voting order: > I don't think it's really all that relevant for rough consensus if > 'vendors are highly polarised' on the question at all. > > If you make that a consideration, I'm sure you can find some vendors > (who may or may not be present here) who strongly wish that WebRTC > will never exist at all in the form that this group's charter has > envisaged, since its success would pose a very real threat to their > current business monopolies. That doesn't give them a right of veto > to this work, though their input, like everyone else's, still merits > consideration for its technical contribution to best achieving the > charter's aims. > > Having a favourite horse in a race is fine. Having that horse be the > fittest to win is a far more objective measurement. > > > The question of choosing a MTI codec hinges on interoperability, and > we have established consensus that having a viable MTI codec is quite > crucial for this. > > Right now we have 2 proposed candidates. So the important questions > are: > > - Are either of those candidates suitable? > - Is one clearly more suitable than the other? > > And the present question has been framed by the WG chairs as: > > - Are there reasons that people could not possibly use either choice? > > > The reasons that people cannot possibly use H.264 are well established. > Its licencing simply does not permit people to use it in all the varied > ways that implementors and users of WebRTC would require. > > The Cisco announcement was clearly an attempt to mitigate this fatal > constraint for their preferred choice, and while it goes some way toward > doing that - and is certainly a bold and perceptive step for them to > take to maintain the value of their existing investment - they are still > constrained by these same licencing terms to only be able to offer a > very limited solution, of limited use, to a limited number of people. > And they still can't offer the sort of indemnity that the H.264 camp > has demanded from VP8 in draft-dbenham-webrtc-videomti-02, and they > aren't even offering a licence to _all_ of the known IPR covering H.264, > only to that covered by the MPEG LA pool - which the Nokia portfolio, > some of which was already disclosed, is notably outside of. > > > The reasons that people cannot possibly use VP8 are far less clear. > None of the objections beyond "we don't want to" so far have any > grounding in reality. The "but but submarine IPR!!" argument applies > equally to *anything* that any WG might chose to do or use. > > Nokia tried to pull some out of their hat, but they lost in court. > If they couldn't torpedo this, then the chances of anyone else being > able to seem significantly diminished. But the validity of their > claims over H.264 are not challenged at all, and remain a clear and > present danger for anyone using H.264. Perhaps even more so now > than ever, given their current financial situation and being the > subject of a takeover bid. > > > This is why I believe that although we have 2 proposals, only one > of them can seriously stand up to scrutiny for being an acceptable > choice that passes the muster of rough consensus. > > "We don't want to" is not a blocker for consensus. > > "The licence of this does not permit us to" is a very real blocker. > > > Given we have consensus for picking an MTI codec, the only reason > not to pick that remaining choice would be if someone springs yet > another last minute surprise which would delay that decision again. > > If that actually happens, then maybe we can once again have the > H.261 vs Theora debate - but if it doesn't, then VP8 is still the > no-brainer choice that can stand up to the full test of having > rough consensus and working code that meets the goals of this WG. > > > > Re this suggestion: > >> 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. > You might want to review the list archives. This question has already > been debated, and I thought the result of that was conclusive, and why > we have only the current proposals that we do today. > > Cheers, > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cowwoc@bbs.darktech.org Wed Nov 6 01:08:08 2013 Return-Path: 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 8F25C11E8171 for ; Wed, 6 Nov 2013 01:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.413 X-Spam-Level: X-Spam-Status: No, score=-4.413 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 I9mTMlp67zOq for ; Wed, 6 Nov 2013 01:08:03 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4654C11E810D for ; Wed, 6 Nov 2013 01:08:02 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so16919464iec.41 for ; Wed, 06 Nov 2013 01:08:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qazEAS7iSjzwi0/Fd8QwC4OP9/5SLWr4eFaFpf7pC9U=; b=kpxEdmgj9rqKROfyo36/QR2kEIZDvKyDvH3wtfX+J0uHWlaGCuuYmF0odFPt/jFLO/ SzSpNUtQsmj/CcptJbG+MhxIDsaptANsJaSMha7e0SR5rnjbAl8dNPoYLn3QWXJ/V6p4 zFQUpPUwM0OWquxpM0Kyk3Sxuivf/T32m7nZV7ub/hv6O8IlZdCh1XqXviRVKuefDcsB BQf/xNnPJOrZmWPuszLf2g3VW3QL9d1+peI45g7vn2bLZ2DWr/oXPytsYm1kG/jHx4Ps UZlSbURRlsTbJQySHsNBcmM8POIrg1lDtMGH9k3oLun+9cjKk/Ueybu3GcCnF0TNPQXO lxyQ== X-Gm-Message-State: ALoCoQkfZK0tfvr9K/V4GAhf4f2cn90EKzO9o0VpQQWPsaJ0ZEUM/1mjBCbeU5epfYY/jZAtQd7G X-Received: by 10.50.61.35 with SMTP id m3mr1583792igr.56.1383728882119; Wed, 06 Nov 2013 01:08:02 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ft2sm13106913igb.5.2013.11.06.01.08.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 01:08:01 -0800 (PST) Message-ID: <527A06EF.2070007@bbs.darktech.org> Date: Wed, 06 Nov 2013 04:07:59 -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: rtcweb@ietf.org References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 09:08:09 -0000 I don't understand why we are playing these semantic games. If we mandate multiple codecs as MTI, and "something goes wrong" (be it an IPR issue, security issue, etc) we have the ability remove that codec from MTI without breaking interoperability. If we only mandate a single codec as MTI, there is no such ability. Gili On 06/11/2013 3:53 AM, David Singer wrote: > On Nov 6, 2013, at 9:53 , bryandonnovan@gmail.com wrote: > >> "real IPR issue" : ability to compile and distribute an h.264 codec without getting a license and paying royalties. >> >> "not real IPR issue" : claims made against Opus by Qualcomm and Huawei > where does Nokia's statement fall, in your opinion? > >> On Tue, Nov 5, 2013 at 4:28 PM, wrote: >> >> Define "real IPR issue". >> >> Markus >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > David Singer > Multimedia and Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From miconda@gmail.com Wed Nov 6 01:30:57 2013 Return-Path: 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 4901911E810D for ; Wed, 6 Nov 2013 01:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 OPrRq86qNOFK for ; Wed, 6 Nov 2013 01:30:56 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5572B21E80B3 for ; Wed, 6 Nov 2013 01:30:53 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id b13so4669751wgh.22 for ; Wed, 06 Nov 2013 01:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sgRb4U/9/WdL+lGVsW+rAOZZfvwI3kmPq31xUczvj/g=; b=XuBTUlLwf7E1cSFybm8u37ohN2LUTDaAkiXc4BoQ0og2CPq3EOXzY+m8hCvOol7oE6 C2y2oV65jnvTAfJ2DlINQcnds1NAPaWbxRJA+RxjXnoQMt6YYwT98X2sOuPanZLbnFjC bC3uW3t7M1Ljfk3RFAQtL7d3iIBBZ84yz3bbOXQuW8nzB6x1FjvSWci4p9+EEsNwR+je qXIoUk77OPL7HWosgH6nEaKCCPnWcWG3EhRwnc1kgI2L4QUqbuZDxrgGIQqYzsYrWjcE 0YzcKCSIaBPgDVTd4DUiFrYJoGJD7fLoEJTeJQYTx0Wo5rqfNlWowQmzz4XOBDdGygiR /ODg== X-Received: by 10.180.73.231 with SMTP id o7mr1627308wiv.21.1383730252327; Wed, 06 Nov 2013 01:30:52 -0800 (PST) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id fr4sm22658379wib.0.2013.11.06.01.30.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 01:30:51 -0800 (PST) Message-ID: <527A0C4D.7020707@gmail.com> Date: Wed, 06 Nov 2013 10:30:53 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: cowwoc , rtcweb@ietf.org References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <527A06EF.2070007@bbs.darktech.org> In-Reply-To: <527A06EF.2070007@bbs.darktech.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Making both VP8 and H264 MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: miconda@gmail.com 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: Wed, 06 Nov 2013 09:30:57 -0000 On 11/6/13 10:07 AM, cowwoc wrote: > > I don't understand why we are playing these semantic games. > > If we mandate multiple codecs as MTI, and "something goes wrong" > (be it an IPR issue, security issue, etc) As it stands today, there are well known IPR issues with h264. Cisco's move doesn't lift them. So why to choose it if falls under the rules to remove it? With both on board, I still expect the majority of the apps will implement only the most convenient for them, eventually expecting the other to have both. Then responsibility is getting divided, like "it's not _only_ my fault", blaming the other end point as well. Daniel > we have the ability remove that codec from MTI without breaking > interoperability. If we only mandate a single codec as MTI, there is > no such ability. > > Gili > > On 06/11/2013 3:53 AM, David Singer wrote: >> On Nov 6, 2013, at 9:53 , bryandonnovan@gmail.com wrote: >> >>> "real IPR issue" : ability to compile and distribute an h.264 codec >>> without getting a license and paying royalties. >>> >>> "not real IPR issue" : claims made against Opus by Qualcomm and Huawei >> where does Nokia's statement fall, in your opinion? >> >>> On Tue, Nov 5, 2013 at 4:28 PM, wrote: >>> >>> Define "real IPR issue". >>> >>> Markus >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> David Singer >> Multimedia and Software Standards, Apple Inc. >> >> _______________________________________________ >> 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 -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28 - more details about Kamailio trainings at http://www.asipto.com - From cowwoc@bbs.darktech.org Wed Nov 6 02:10:52 2013 Return-Path: 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 BF0A711E8126 for ; Wed, 6 Nov 2013 02:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.394 X-Spam-Level: X-Spam-Status: No, score=-4.394 tagged_above=-999 required=5 tests=[AWL=-0.795, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qeygxDpk5cJG for ; Wed, 6 Nov 2013 02:10:47 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id D479511E8122 for ; Wed, 6 Nov 2013 02:10:46 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id aq17so16967263iec.38 for ; Wed, 06 Nov 2013 02:10:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AO3H6sXQMkcGBixjp8/+9wFx92zn9KDPsMGnmCesEQc=; b=MvQubPJGG47tgKdO71Dl+Qml+PDcjOqo56ThYqM36l506xsS3nNd6zIqiIbIfXukIP hnX370dLE2spBeHcO7/tWMb7MM/0y7nO8YEKbk3cnnWcUd5/rZbHZ5IhTLc2xt7uB3XE kT6Qkim7/LBWEKEOqPxGu/oCk4/2X0C3gfcqFdzXYPTgcBlm4brfuE5tZkTf2iBSDpVL 6wWUFQ51LFaHZYm9uvdDtvXcQA1X034m55+AtYhfoVkHybiQtLfdPwFC25ZEbfyOtUYS F61jZ9N6CmAPe+2tE/SwZV1YLRiboZIBq7m1obJrYAWvE9m68UAf1rvryVgMDgEOpqHn yaoQ== X-Gm-Message-State: ALoCoQl1Vr/Ddsia8diVTvo9GROqeup70i6MAbu8Dyvnxdd9u1456AvKn8PePUt3pb1t7nn3X9l4 X-Received: by 10.50.77.83 with SMTP id q19mr1753834igw.21.1383732645978; Wed, 06 Nov 2013 02:10:45 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id cl4sm26505778igc.1.2013.11.06.02.10.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 02:10:45 -0800 (PST) Message-ID: <527A15A3.2090006@bbs.darktech.org> Date: Wed, 06 Nov 2013 05:10:43 -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: miconda@gmail.com, rtcweb@ietf.org References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <527A06EF.2070007@bbs.darktech.org> <527A0C4D.7020707@gmail.com> In-Reply-To: <527A0C4D.7020707@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 10:10:52 -0000 On 06/11/2013 4:30 AM, Daniel-Constantin Mierla wrote: > As it stands today, there are well known IPR issues with h264. Cisco's > move doesn't lift them. > > So why to choose it if falls under the rules to remove it? > No one says it has to be H.264 and VP8. It could be H.261 and VP8. > With both on board, I still expect the majority of the apps will > implement only the most convenient for them, eventually expecting the > other to have both. Then responsibility is getting divided, like "it's > not _only_ my fault", blaming the other end point as well. That is a reasonable concern, and one that we need to address. Implementations that violate these rules will make it harder for us to replace older MTI codecs without breaking backwards compatibility. Gili From wolfgang.beck01@googlemail.com Wed Nov 6 05:45:34 2013 Return-Path: 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 AE05211E8210 for ; Wed, 6 Nov 2013 05:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 IY-nVOaA90GP for ; Wed, 6 Nov 2013 05:45:34 -0800 (PST) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 08DCB11E81AC for ; Wed, 6 Nov 2013 05:45:33 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id db12so3533236veb.23 for ; Wed, 06 Nov 2013 05:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dh/ECCF1bIMoCPpuGvUa7jifTlTkQSO9k+3XIWC/lXg=; b=qzsWYzXuGRBCJSTRIsXOjfqm1PwLa4Yd0ZBn/fQCC6bvN9/E9Qa2jEHGfb9kEu6StR 1aMZ4OSJ7LE9iX4PYGuSCOKkbi6RFKfIFthgSfwGk4ZfbWkBMv90fvORp5clCfQ6inFz YEyMWIg62QXLOLupVWqy7FJoLtZgOhMxyUcKLeUR54x2OML9LNoM4gvWPhVHllqw96mX 9bQ1hLZycJcZJE0XifWNofMLjBgzZr9G9PKdHFPeNzfgIki/fFfQ+y0ecpcQ78FYVnRN wMs3xlj9STAQ2egC/dpI7KVYAQwjMR31FTLd2R5NSsvS5kVceGwYRY/YBY60auViE4bE cMTw== MIME-Version: 1.0 X-Received: by 10.58.144.168 with SMTP id sn8mr430100veb.33.1383745533416; Wed, 06 Nov 2013 05:45:33 -0800 (PST) Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 05:45:33 -0800 (PST) Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 05:45:33 -0800 (PST) In-Reply-To: References: <52795BF0.1020207@makk.es> Date: Wed, 6 Nov 2013 14:45:33 +0100 Message-ID: From: Wolfgang Beck To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b5da93bfa9d0a04ea825cb6 Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 13:45:34 -0000 --047d7b5da93bfa9d0a04ea825cb6 Content-Type: text/plain; charset=ISO-8859-1 Let's say the user authenticated with my webrtc service using google openid. The webrtc server asked for the attribute 'display name'. The OpenID server asks the user:'Can I tell webrtc server your display name y/n?'. Now the peerconnection object asks the openid server for authentication and the attribute 'email address', to get an rfc822 style name it can return to the JS. This is a new permission the user has to grant. And I dont know which openid attribute the peerconnection obj is going to use. It can even change dynamically when google changes the .well-known/idp document. Am 05.11.2013 18:41 schrieb "Martin Thomson" : > On 5 November 2013 18:15, Wolfgang Beck > wrote: > > What if the server requests a different set of meta data from the idp > than > > the peerconnection object? The idp will have two ask for permission > twice. > > The number of questions the browser asks the IdP is completely > independent of the number of times that the user is required to log > in. If you are both generating and validating assertions with the > same IdP, you can ask it twice. THe validating IdP does not require > login. > --047d7b5da93bfa9d0a04ea825cb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Let's say the user authenticated with my webrtc service = using google openid. The webrtc server asked for the attribute 'display= name'. The OpenID server asks the user:'Can I tell webrtc server y= our display name y/n?'. Now the peerconnection object asks the openid s= erver for authentication and the attribute 'email address', to get = an rfc822 style name it can return to the JS. This is a new permission the = user has to grant. And I dont know which openid attribute the peerconnectio= n obj is going to use. It can even change dynamically when google changes t= he .well-known/idp document.

Am 05.11.2013 18:41 schrieb "Martin Thomson= " <martin.thomson@gmail= .com>:
On 5 November 2013 18:15, Wolfgang Beck <wolfgang.beck01@googlemail.com> wrote:
> What if the server requests a different set of meta data from the idp = than
> the peerconnection object? The idp will have two ask for permission tw= ice.

The number of questions the browser asks the IdP is completely
independent of the number of times that the user is required to log
in. =A0If you are both generating and validating assertions with the
same IdP, you can ask it twice. =A0THe validating IdP does not require
login.
--047d7b5da93bfa9d0a04ea825cb6-- From wolfgang.beck01@googlemail.com Wed Nov 6 05:59:14 2013 Return-Path: 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 5851211E8165 for ; Wed, 6 Nov 2013 05:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 HJoag-K1cbOm for ; Wed, 6 Nov 2013 05:59:13 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6E25F21E80D3 for ; Wed, 6 Nov 2013 05:59:13 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id if17so6709174vcb.13 for ; Wed, 06 Nov 2013 05:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hoiE/GvH6xz/t/DLxsoDxfzD0DrMMb3pd/cOaCpXF0s=; b=D1BKRRHxWCym8lY+FdbH4NFDyKaPFjjTCHqOoXHowBVbtd/akYYdfoQls/f+V596mx B/YO/vyTtL2GYTrH7OG7UIFQIPhmzt5MEceuYUyUTObrN8IN4bjTZOvpnMjzEQxuoeO6 wJ3vUEYd8JCukUeTSxgwnb9wIX8GvFKqdBlMpEOytQUSrf6sYzbCcsRG7qRd5F2kIhpB GHgWFRXj79K8fkEcYDQoDWclE28hathWyDuCbLyToit9nwWsIu328PWtVuABafVwFuQl ihfwfru9fKZwUKVnRbjQy0k7tA1Uf9OZTt9otmyUd93RTBoOXJNoZe2q3njLqmEky4QC eUQQ== MIME-Version: 1.0 X-Received: by 10.220.74.69 with SMTP id t5mr2558144vcj.18.1383746352897; Wed, 06 Nov 2013 05:59:12 -0800 (PST) Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 05:59:12 -0800 (PST) Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 05:59:12 -0800 (PST) In-Reply-To: <5279FF69.5040206@makk.es> References: <52795BF0.1020207@makk.es> <5279FF69.5040206@makk.es> Date: Wed, 6 Nov 2013 14:59:12 +0100 Message-ID: From: Wolfgang Beck To: Max Jonas Werner Content-Type: multipart/alternative; boundary=047d7b624cbed311fb04ea828d42 Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 13:59:14 -0000 --047d7b624cbed311fb04ea828d42 Content-Type: text/plain; charset=ISO-8859-1 You explanation matches my understanding. See my mail to Martin why you still can have two user dialogs with your idp. And the life time of your idp's cookies can be shorter than the liftetime of the webrtc server's session cookies. Wolfgang Beck Am 06.11.2013 00:35 schrieb "Max Jonas Werner" : > Wolfgang, > > On 05.11.2013 23:03, Wolfgang Beck wrote: > > According to the draft and the w3c doc, the Idp exchange is completely > > hidden from the JS. I don't see how a web server could use the result to > > verify the user without looking at the SDP. Or how the peerconnection > could > > reuse the result of an Idp exchange that authenticated the user towards > the > > server. Did I overlook something? > > > > Having to log in twice will only be tolerated by a small minority of > > people. > > I propose you read the draft again since perhaps you overlooked > something. Let me give you an example: > > You have a WebRTC application that's served from your domain > example.com. Perhaps you've implemented some kind of login mechanism so > the user logs in (using an HTML form perhaps) resulting in e.g. a cookie > being saved in the user's browser carrying a session ID (again, this is > just _one_ possibility). > > Your application creates a PeerConnection object and calls > setIdentityProvider with the parameter "domain" set to "example.com" and > the parameter "protocol" set to "proto" because you want to be your own > IdP. When creating an offer the browser will then load the code from > https://example.com/.well-known/idp-proxy/proto into an iframe or such > and send a message to that code asking for an assertion. Since the IdP > proxy code is served from the same origin it may read out the cookie > value set earlier when logging the user in. > > This cookie value can now be used on the server side to automatically > (as in without user interaction) create an assertion since the server > already knows who the user is (from the cookie). > > This also works with using another IdP (say Facebook) with your > application served from example.com. If the user is already logged into > Facebook: no interaction needed. > > Max > > --047d7b624cbed311fb04ea828d42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

You explanation matches my understanding. See my mail to Mar= tin why you still can have two user=A0 dialogs with your idp.=A0 And the li= fe time of your idp's cookies can be shorter than the liftetime of the = webrtc=A0 server's session cookies.

Wolfgang Beck

Am 06.11.2013 00:35 schrieb "Max Jonas Wern= er" <mail@makk.es>:
Wolfgang,

On 05.11.2013 23:03, Wolfgang Beck wrote:
> According to the draft and the w3c doc, the Idp exchange is completely=
> hidden from the JS. I don't see how a web server could use the res= ult to
> verify the user without looking at the SDP. Or how the peerconnection = could
> reuse the result of an Idp exchange that authenticated the user toward= s the
> server. Did I overlook something?
>
> Having to log in twice will only be tolerated by a small minority of > people.

I propose you read the draft again since perhaps you overlooked
something. Let me give you an example:

You have a WebRTC application that's served from your domain
example.com. Perhaps y= ou've implemented some kind of login mechanism so
the user logs in (using an HTML form perhaps) resulting in e.g. a cookie being saved in the user's browser carrying a session ID (again, this is=
just _one_ possibility).

Your application creates a PeerConnection object and calls
setIdentityProvider with the parameter "domain" set to "example.com" and
the parameter "protocol" set to "proto" because you wan= t to be your own
IdP. When creating an offer the browser will then load the code from
https://example.com/.well-known/idp-proxy/proto into an iframe or su= ch
and send a message to that code asking for an assertion. Since the IdP
proxy code is served from the same origin it may read out the cookie
value set earlier when logging the user in.

This cookie value can now be used on the server side to automatically
(as in without user interaction) create an assertion since the server
already knows who the user is (from the cookie).

This also works with using another IdP (say Facebook) with your
application served from ex= ample.com. If the user is already logged into
Facebook: no interaction needed.

Max

--047d7b624cbed311fb04ea828d42-- From andrew.hutton@unify.com Wed Nov 6 11:10:28 2013 Return-Path: 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 C431021E8087 for ; Wed, 6 Nov 2013 11:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=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 90nhI79g9XQD for ; Wed, 6 Nov 2013 11:10:24 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E491421F9CC2 for ; Wed, 6 Nov 2013 11:10:14 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 9C82B23F0677; Wed, 6 Nov 2013 20:10:07 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 20:10:07 +0100 From: "Hutton, Andrew" To: Parthasarathi R , 'Justin Uberti' , 'Paul Kyzivat' Thread-Topic: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers Thread-Index: Ac7ZKu97RkimDg8HS1yf9W6X1FrNbAAV/t7wAGdqfCA= Date: Wed, 6 Nov 2013 19:10:06 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C321EE@MCHP04MSX.global-ad.net> References: <527420FC.3070805@alum.mit.edu> <00b901ced985$85594160$900bc420$@co.in> In-Reply-To: <00b901ced985$85594160$900bc420$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17C321EEMCHP04MSXglobal_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 19:10:29 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17C321EEMCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBqdXN0IGxpa2UgdG8gc2F5IHRoYXQgSSBhZ3JlZSB3aXRoIHRoZSBwb2ludHMgcmFp c2VkIGJ5IFBhdWwgYW5kIFBhcnRoYSBoZXJlIHRoYXQgaXQgaGFzIHRvIGJlIHBvc3NpYmxlIGZv ciB0aGUgYXBwbGljYXRpb24gdG8gY3JlYXRlIGFuIG9mZmVyIHdpdGggYSBjb21wbGV0ZSBzZXQg b2YgY3VycmVudCBjYXBhYmlsaXRpZXMuICBUaGUgcmVhc29uIGZvciB0aGlzIGlzIG9mIGNvdXJz ZSBpbnRlcm9wZXJhYmlsaXR5IHdpdGggZXhpc3RpbmcgU0lQIGltcGxlbWVudGF0aW9ucyB3aGlj aCBuZWVkIHRoaXMuICBIYXZpbmcgdG8gY3JlYXRlIGEgbmV3IHBlZXIgY29ubmVjdGlvbiBhbmQg Zm9yY2UgdXNlIG9mIElOVklURSB3aXRoIHJlcGxhY2VzIGRvZXNu4oCZdCB3b3JrIHdlbGwgd2l0 aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYW5kIHdvdWxkIGJlIGEgaGlnaCBjb3N0IHRvIHBh eSBmb3Igd2hhdCBpcyBob3BlZnVsbHkgYSBzaW1wbGUgQVBJIGNvbnN0cmFpbnQgdG8gY3JlYXRl IGEgZnVsbCBvZmZlci4NCg0KUmVnYXJkcw0KQW5keQ0KDQoNCg0KRnJvbTogcnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFBhcnRoYXNhcmF0aGkgUg0KU2VudDogMDQgTm92ZW1iZXIgMjAxMyAwOTo0NA0KVG86ICdKdXN0 aW4gVWJlcnRpJzsgJ1BhdWwgS3l6aXZhdCcNCkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbcnRjd2ViXSBkcmFmdC1pZXRmLXJ0Y3dlYi1qc2VwLTA1IC0gU3Vic2VxdWVudCBPZmZl cnMNCg0KSnVzdGluLA0KDQpBcyB0aGUgc2lnbmFsaW5nIGlzIG5vdCBkZWZpbmVkIGluIFdlYlJU QywgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGFzc3VtZSB0aGF0IHRoZSByZW1vdGUgc2lkZSBjYXBh YmlsaXRpZXMgd2lsbCBub3QgY2hhbmdlIGJldHdlZW4gYnJvd3NlciB0byBicm93c2VyIHNjZW5h cmlvIGFzIHdlbGwuICBSVENXZWIgU2VydmVyIHNoYWxsIHRyYW5zZmVyIHRoZSBzZXNzaW9uIHVz aW5nIFJFLUlOVklURSBlcXVpdmFsZW50IGZ1bmN0aW9uYWxpdHkuDQoNClJlLUlOVklURSB3aXRo b3V0IG9mZmVyIGlzIGEgcG93ZXIgdG9vbCBpbiBTSVAgZm9yIGdldHRpbmcgdGhlIGNhcGFiaWxp dGllcyBiZWZvcmUgc2VsZWN0aW5nIHRoZSBmaW5hbCBjb2RlYy4gSXQgc2hhbGwgYmUgdXNlZCB0 byBpbml0aWF0ZSB0aGUgb2ZmZXIgZnJvbSB0aGUgcmVtb3RlIHNpZGUuIE9uZSBvZiB0aGUgSU5J VlRFL1JlLUlOVklURSB3aXRob3V0IG9mZmVyIHVzZWNhc2UgaW4gV2ViUlRDIHNoYWxsIGJlIHVz ZWQgdG8gZ2V0IElDRS1UQ1AgY2FuZGlkYXRlIGZyb20gdGhlIGJyb3dzZXIgd2hlcmVpbiB0aGUg aW5jb21pbmcgVENQIGNvbm5lY3Rpb24gaXMgZm9yYmlkZGVuIGJ5IHRoZSBmaXJld2FsbC4NCg0K VGhhbmtzDQpQYXJ0aGENCg0KDQoNCkZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDQs IDIwMTMgMTI6MjYgUE0NClRvOiBQYXVsIEt5eml2YXQNCkNjOiBydGN3ZWJAaWV0Zi5vcmc8bWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBkcmFmdC1pZXRmLXJ0 Y3dlYi1qc2VwLTA1IC0gU3Vic2VxdWVudCBPZmZlcnMNCg0KDQoNCk9uIEZyaSwgTm92IDEsIDIw MTMgYXQgMjo0NSBQTSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRv OnBreXppdmF0QGFsdW0ubWl0LmVkdT4+IHdyb3RlOg0KU2VjdGlvbiA1LjIuMiAoU3Vic2VxdWVu dCBPZmZlcnMpIHNheXM6DQoNCiAgIG8gIFRoZSBtPSBsaW5lIGFuZCBjb3JyZXNwb25kaW5nICJh PXJ0cG1hcCIgYW5kICJhPWZtdHAiIGxpbmVzIE1VU1QNCiAgICAgIG9ubHkgaW5jbHVkZSBjb2Rl Y3MgcHJlc2VudCBpbiB0aGUgcmVtb3RlIGRlc2NyaXB0aW9uLg0KDQogICBvICBUaGUgUlRQIGhl YWRlciBleHRlbnNpb25zIE1VU1Qgb25seSBpbmNsdWRlIHRob3NlIHRoYXQgYXJlIHByZXNlbnQN CiAgICAgIGluIHRoZSByZW1vdGUgZGVzY3JpcHRpb24uDQoNCiAgIG8gIFRoZSBSVENQIGZlZWRi YWNrIGV4dGVuc2lvbnMgTVVTVCBvbmx5IGluY2x1ZGUgdGhvc2UgdGhhdCBhcmUNCiAgICAgIHBy ZXNlbnQgaW4gdGhlIHJlbW90ZSBkZXNjcmlwdGlvbi4NCg0KICAgbyAgVGhlICJhPXJ0Y3AtbXV4 IiBsaW5lIE1VU1Qgb25seSBiZSBhZGRlZCBpZiBwcmVzZW50IGluIHRoZSByZW1vdGUNCiAgICAg IGRlc2NyaXB0aW9uLg0KDQogICBvICBUaGUgImE9cnRjcC1yc2l6ZSIgbGluZSBNVVNUIG9ubHkg YmUgYWRkZWQgaWYgcHJlc2VudCBpbiB0aGUNCiAgICAgIHJlbW90ZSBkZXNjcmlwdGlvbi4NCg0K SW5jbHVkaW5nIG9ubHkgY29kZWNzIHRoYXQgd2VyZSBwcmVzZW50IGluIHRoZSBwcmlvciBhbnN3 ZXIgaXMgYSBiYWQgaWRlYS4gSXQgZG9lc24ndCBwbGF5IHdlbGwgd2l0aCBTSVAuIFRoZXJlIGlz IG5vIGhhcm0gaW4gY29udGludWluZyB0byBpbmNsdWRlIGFsbCB0aGUgY29kZWNzIHlvdSBzdXBw b3J0LiBBbmQgaXQga2VlcHMgb3B0aW9ucyBvcGVuIGZvciBjaGFuZ2luZyBjb2RlY3MgbGF0ZXIu DQoNClRoZSBzYW1lIGlzIHRydWUgZm9yIG1vc3Qgb3RoZXIgdGhpbmdzIHRoYXQgYXJlIGJlaW5n IHJlc3RyaWN0ZWQgYmFzZWQgb24gd2hhdCB3YXMgaW4gdGhlIGxhc3QgYW5zd2VyLiAoQnV0IEkg d29uJ3Qgc2F5IHRoYXQgd2l0aCBjZXJ0YWludHkgd2l0aG91dCBjaGVja2luZyB0aGUgc2VtYW50 aWNzIG9mIGVhY2ggb25lLikNCg0KRm9yIGZ1cnRoZXIgaW5mbywgc2VlIFJGQyA2MzM3LCBlc3Bl Y2lhbGx5IHNlY3Rpb24gNS4xLg0KDQpBY2NvcmRpbmcgdG8gc2VjdGlvbiA1LjIuNSwgaXQgc2Vl bXMgdGhhdCB0aGlzIGlzIG9ubHkgdGhlIGNhc2VzIGZvciBvZmZlcnMgdHJpZ2dlcmVkIGJ5IG9m ZmVybGVzcyByZUlOVklURXMuIEkgZG9uJ3QgdGhpbmsgd2Ugd2FudCB0byBiZSByZS1hbGxvY2F0 aW5nIGFuZCBuZWdvdGlhdGluZyBjb2RlY3MgZXZlcnkgdGltZSB3ZSB3YW50IHRvIG1ha2UgYSBj aGFuZ2UgdG8gdGhlIHNlc3Npb24gZGVzY3JpcHRpb25zIGluIHVzZS4NCg0KR2VuZXJhbGx5IEkg dGhpbmsgd2Ugc2hvdWxkIGNvbnNpZGVyIHRoYXQgdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUgcmVt b3RlIHNpZGUgd2lsbCBub3QgY2hhbmdlIHVuZXhwZWN0ZWRseSBkdXJpbmcgdGhlIGNhbGwsIGFu ZCBzbyBmdWxsIHJlbmVnb3RpYXRpb24gaXMgbm90IG5lZWRlZCB3aXRoIGVhY2ggcmVJTlZJVEUu IElmIGZ1bGwgcmVuZWdvdGlhdGlvbiBpcyBuZWVkZWQsIHVzZSBhbiBJTlZJVEUtd2l0aC1yZXBs YWNlcywgYXMgQ3VsbGVuIGhhcyBzdWdnZXN0ZWQuIFRoaXMgYXZvaWRzIGNvbXBsaWNhdGVkIGNh c2VzIGxpa2UgaGF2aW5nIHRvIHVuQlVORExFIGluIG1pZC1jYWxsLCBvciByZS1yZXNlcnZlIGNv ZGVjcyB0aGF0IGFyZSB1bmxpa2VseSB0byBiZSB1c2VkLg0KDQoNCg0KICAgICAgICBUaGFua3Ms DQogICAgICAgIFBhdWwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dl YkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi DQoNCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF17C321EEMCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JIHdvdWxkIGp1c3QgbGlrZSB0byBzYXkgdGhhdCBJIGFncmVlIHdpdGggdGhlIHBvaW50cyBy YWlzZWQgYnkgUGF1bCBhbmQgUGFydGhhIGhlcmUgdGhhdCBpdCBoYXMgdG8gYmUgcG9zc2libGUg Zm9yIHRoZSBhcHBsaWNhdGlvbiB0byBjcmVhdGUgYW4gb2ZmZXIgd2l0aA0KIGEgY29tcGxldGUg c2V0IG9mIGN1cnJlbnQgY2FwYWJpbGl0aWVzLiZuYnNwOyBUaGUgcmVhc29uIGZvciB0aGlzIGlz IG9mIGNvdXJzZSBpbnRlcm9wZXJhYmlsaXR5IHdpdGggZXhpc3RpbmcgU0lQIGltcGxlbWVudGF0 aW9ucyB3aGljaCBuZWVkIHRoaXMuJm5ic3A7IEhhdmluZyB0byBjcmVhdGUgYSBuZXcgcGVlciBj b25uZWN0aW9uIGFuZCBmb3JjZSB1c2Ugb2YgSU5WSVRFIHdpdGggcmVwbGFjZXMgZG9lc27igJl0 IHdvcmsgd2VsbCB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucw0KIGFuZCB3b3VsZCBiZSBh IGhpZ2ggY29zdCB0byBwYXkgZm9yIHdoYXQgaXMgaG9wZWZ1bGx5IGEgc2ltcGxlIEFQSSBjb25z dHJhaW50IHRvIGNyZWF0ZSBhIGZ1bGwgb2ZmZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QYXJ0 aGFzYXJhdGhpIFI8YnI+DQo8Yj5TZW50OjwvYj4gMDQgTm92ZW1iZXIgMjAxMyAwOTo0NDxicj4N CjxiPlRvOjwvYj4gJ0p1c3RpbiBVYmVydGknOyAnUGF1bCBLeXppdmF0Jzxicj4NCjxiPkNjOjwv Yj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBkcmFm dC1pZXRmLXJ0Y3dlYi1qc2VwLTA1IC0gU3Vic2VxdWVudCBPZmZlcnM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SnVzdGluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgdGhlIHNpZ25hbGluZyBpcyBu b3QgZGVmaW5lZCBpbiBXZWJSVEMsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBhc3N1bWUgdGhhdCB0 aGUgcmVtb3RlIHNpZGUgY2FwYWJpbGl0aWVzIHdpbGwgbm90IGNoYW5nZSBiZXR3ZWVuIGJyb3dz ZXIgdG8gYnJvd3NlciBzY2VuYXJpbw0KIGFzIHdlbGwuJm5ic3A7IFJUQ1dlYiBTZXJ2ZXIgc2hh bGwgdHJhbnNmZXIgdGhlIHNlc3Npb24gdXNpbmcgUkUtSU5WSVRFIGVxdWl2YWxlbnQgZnVuY3Rp b25hbGl0eS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UmUtSU5WSVRFIHdpdGhvdXQgb2ZmZXIgaXMgYSBwb3dlciB0 b29sIGluIFNJUCBmb3IgZ2V0dGluZyB0aGUgY2FwYWJpbGl0aWVzIGJlZm9yZSBzZWxlY3Rpbmcg dGhlIGZpbmFsIGNvZGVjLiBJdCBzaGFsbCBiZSB1c2VkIHRvIGluaXRpYXRlIHRoZSBvZmZlciBm cm9tIHRoZQ0KIHJlbW90ZSBzaWRlLiBPbmUgb2YgdGhlIElOSVZURS9SZS1JTlZJVEUgd2l0aG91 dCBvZmZlciB1c2VjYXNlIGluIFdlYlJUQyBzaGFsbCBiZSB1c2VkIHRvIGdldCBJQ0UtVENQIGNh bmRpZGF0ZSBmcm9tIHRoZSBicm93c2VyIHdoZXJlaW4gdGhlIGluY29taW5nIFRDUCBjb25uZWN0 aW9uIGlzIGZvcmJpZGRlbiBieSB0aGUgZmlyZXdhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZyI+cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVm PSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGN3ZWItYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBVYmVydGk8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAwNCwgMjAxMyAxMjoyNiBQTTxicj4NCjxiPlRvOjwv Yj4gUGF1bCBLeXppdmF0PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRj d2ViXSBkcmFmdC1pZXRmLXJ0Y3dlYi1qc2VwLTA1IC0gU3Vic2VxdWVudCBPZmZlcnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBGcmksIE5vdiAxLCAyMDEzIGF0IDI6NDUgUE0sIFBhdWwgS3l6aXZhdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnBr eXppdmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U2VjdGlvbiA1LjIuMiAoU3Vic2VxdWVudCBPZmZlcnMpIHNheXM6PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwO28gJm5ic3A7VGhlIG09IGxpbmUgYW5kIGNvcnJlc3BvbmRp bmcgJnF1b3Q7YT1ydHBtYXAmcXVvdDsgYW5kICZxdW90O2E9Zm10cCZxdW90OyBsaW5lcyBNVVNU PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgb25seSBpbmNsdWRlIGNvZGVjcyBwcmVzZW50IGlu IHRoZSByZW1vdGUgZGVzY3JpcHRpb24uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO28gJm5ic3A7 VGhlIFJUUCBoZWFkZXIgZXh0ZW5zaW9ucyBNVVNUIG9ubHkgaW5jbHVkZSB0aG9zZSB0aGF0IGFy ZSBwcmVzZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW4gdGhlIHJlbW90ZSBkZXNjcmlw dGlvbi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7byAmbmJzcDtUaGUgUlRDUCBmZWVkYmFjayBl eHRlbnNpb25zIE1VU1Qgb25seSBpbmNsdWRlIHRob3NlIHRoYXQgYXJlPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgcHJlc2VudCBpbiB0aGUgcmVtb3RlIGRlc2NyaXB0aW9uLjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDtvICZuYnNwO1RoZSAmcXVvdDthPXJ0Y3AtbXV4JnF1b3Q7IGxpbmUgTVVT VCBvbmx5IGJlIGFkZGVkIGlmIHByZXNlbnQgaW4gdGhlIHJlbW90ZTxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IGRlc2NyaXB0aW9uLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtvICZuYnNwO1Ro ZSAmcXVvdDthPXJ0Y3AtcnNpemUmcXVvdDsgbGluZSBNVVNUIG9ubHkgYmUgYWRkZWQgaWYgcHJl c2VudCBpbiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyByZW1vdGUgZGVzY3JpcHRpb24u PGJyPg0KPGJyPg0KSW5jbHVkaW5nIG9ubHkgY29kZWNzIHRoYXQgd2VyZSBwcmVzZW50IGluIHRo ZSBwcmlvciBhbnN3ZXIgaXMgYSBiYWQgaWRlYS4gSXQgZG9lc24ndCBwbGF5IHdlbGwgd2l0aCBT SVAuIFRoZXJlIGlzIG5vIGhhcm0gaW4gY29udGludWluZyB0byBpbmNsdWRlIGFsbCB0aGUgY29k ZWNzIHlvdSBzdXBwb3J0LiBBbmQgaXQga2VlcHMgb3B0aW9ucyBvcGVuIGZvciBjaGFuZ2luZyBj b2RlY3MgbGF0ZXIuPGJyPg0KPGJyPg0KVGhlIHNhbWUgaXMgdHJ1ZSBmb3IgbW9zdCBvdGhlciB0 aGluZ3MgdGhhdCBhcmUgYmVpbmcgcmVzdHJpY3RlZCBiYXNlZCBvbiB3aGF0IHdhcyBpbiB0aGUg bGFzdCBhbnN3ZXIuIChCdXQgSSB3b24ndCBzYXkgdGhhdCB3aXRoIGNlcnRhaW50eSB3aXRob3V0 IGNoZWNraW5nIHRoZSBzZW1hbnRpY3Mgb2YgZWFjaCBvbmUuKTxicj4NCjxicj4NCkZvciBmdXJ0 aGVyIGluZm8sIHNlZSBSRkMgNjMzNywgZXNwZWNpYWxseSBzZWN0aW9uIDUuMS48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFjY29yZGluZyB0byBzZWN0aW9u IDUuMi41LCBpdCBzZWVtcyB0aGF0IHRoaXMgaXMgb25seSB0aGUgY2FzZXMgZm9yIG9mZmVycyB0 cmlnZ2VyZWQgYnkgb2ZmZXJsZXNzIHJlSU5WSVRFcy4gSSBkb24ndCB0aGluayB3ZSB3YW50IHRv IGJlIHJlLWFsbG9jYXRpbmcgYW5kIG5lZ290aWF0aW5nIGNvZGVjcyBldmVyeSB0aW1lIHdlIHdh bnQgdG8gbWFrZSBhIGNoYW5nZSB0byB0aGUgc2Vzc2lvbiBkZXNjcmlwdGlvbnMNCiBpbiB1c2Uu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkdlbmVyYWxseSBJIHRoaW5rIHdlIHNob3VsZCBjb25zaWRlciB0aGF0IHRoZSBjYXBhYmls aXRpZXMgb2YgdGhlIHJlbW90ZSBzaWRlIHdpbGwgbm90IGNoYW5nZSB1bmV4cGVjdGVkbHkgZHVy aW5nIHRoZSBjYWxsLCBhbmQgc28gZnVsbCByZW5lZ290aWF0aW9uIGlzIG5vdCBuZWVkZWQgd2l0 aCBlYWNoIHJlSU5WSVRFLiBJZiBmdWxsIHJlbmVnb3RpYXRpb24gaXMgbmVlZGVkLCB1c2UgYW4g SU5WSVRFLXdpdGgtcmVwbGFjZXMsDQogYXMgQ3VsbGVuIGhhcyBzdWdnZXN0ZWQuIFRoaXMgYXZv aWRzIGNvbXBsaWNhdGVkIGNhc2VzIGxpa2UgaGF2aW5nIHRvIHVuQlVORExFIGluIG1pZC1jYWxs LCBvciByZS1yZXNlcnZlIGNvZGVjcyB0aGF0IGFyZSB1bmxpa2VseSB0byBiZSB1c2VkLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgVGhhbmtzLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQ YXVsPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF17C321EEMCHP04MSXglobal_-- From martin.thomson@gmail.com Wed Nov 6 11:14:28 2013 Return-Path: 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 AFAF511E80DE for ; Wed, 6 Nov 2013 11:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, 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 kYSLBXS+JLSl for ; Wed, 6 Nov 2013 11:14:28 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 003A721F9FD5 for ; Wed, 6 Nov 2013 11:14:27 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id ey11so4224386wid.13 for ; Wed, 06 Nov 2013 11:14:27 -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=O11Snpe3Oh5rIvSxWtrB/LuTGEViNjjLHwflEVP5gFw=; b=pnmTqXlIht/SCEFX3wEacMt1/8pFyXOtbAkUTTFPvWUzC90yTHrGI+Szh9JFGHVkpe v4FrFMy8Qxgm2q1ZhY7IKU82AuUdFHQyz9dIJVNQNQ+xeBj2o85nORS933zdklvOT1qU /bTFdLN2Vvi7pGAeTUTPVZ0BIDaCAOh+NVbQD10uOAJAx4ID8LTgHcONrsPK5IHqMKeP 8tWs0tofqvP9gp9Ce6LIXuwAwVbmYVUcFnL3ts5061htS5jvMA9DqiTfMleJKtB76l5s QzhsRXUB6+LGQRdQWxJNWtfpBzse7Qr0RgAKcyBYmzKgCUfzGGOQ9/93s4vaQE8fXVUm bzdQ== MIME-Version: 1.0 X-Received: by 10.194.1.139 with SMTP id 11mr3841912wjm.33.1383765267233; Wed, 06 Nov 2013 11:14:27 -0800 (PST) Received: by 10.227.202.194 with HTTP; Wed, 6 Nov 2013 11:14:27 -0800 (PST) In-Reply-To: References: <52795BF0.1020207@makk.es> Date: Wed, 6 Nov 2013 11:14:27 -0800 Message-ID: From: Martin Thomson To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 19:14:28 -0000 On 6 November 2013 05:45, Wolfgang Beck wrote: > Let's say the user authenticated with my webrtc service using google openid. > The webrtc server asked for the attribute 'display name'. The OpenID server > asks the user:'Can I tell webrtc server your display name y/n?'. Now the > peerconnection object asks the openid server for authentication and the > attribute 'email address', to get an rfc822 style name it can return to the > JS. This is a new permission the user has to grant. And I dont know which > openid attribute the peerconnection obj is going to use. It can even change > dynamically when google changes the .well-known/idp document. This is, overall, correct. However, do you think that you have to login every time that you load or reload a webpage? From magnus.westerlund@ericsson.com Wed Nov 6 12:04:27 2013 Return-Path: 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 0795121F9EAD for ; Wed, 6 Nov 2013 12:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.518 X-Spam-Level: X-Spam-Status: No, score=-105.518 tagged_above=-999 required=5 tests=[AWL=0.731, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 YG7ABjW-JjeI for ; Wed, 6 Nov 2013 12:04:20 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEBD21E8184 for ; Wed, 6 Nov 2013 12:04:20 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-c5-527aa0c34714 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A7.04.23787.3C0AA725; Wed, 6 Nov 2013 21:04:19 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.328.9; Wed, 6 Nov 2013 21:04:18 +0100 Message-ID: <527AA11B.8090408@ericsson.com> Date: Wed, 6 Nov 2013 12:05:47 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvje7hBVVBBs2NGhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+fUacwFq9gqPp6+yN7AOIW1i5GTQ0LAROLixG42CFtM4sK9 9UA2F4eQwCFGicalzVDOMkaJDz2/wDp4BbQldiw5zwJiswioSOy+3QFmswlYSNz80Qg2SVQg WOL8q8XsEPWCEidnPgGrERFQl7j88AJYXFhAR6KtYQdzFyMH0GZxiZ7GIJAws4CexJSrLYwQ trxE89bZzCC2ENDahqYO1gmM/LOQTJ2FpGUWkpYFjMyrGNlzEzNz0ssNNzECw+nglt+6OxhP nRM5xCjNwaIkzvvhrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkYbgWkez1+caX/6zzXy og/nz3S9zQcmeWoGLc5LUv01Q23b7hdT5TcIH9FjmhUm9ePMleuT7VZuYXcrigtPkrwxyz4p 8EebTP18qfM6wQn+5+U+FPeYHTvHlVTup/9Be4NAj0A2u/5+s1M/hG+GPft4NEper+5btO/a d767ry/yPs1wtK2mvEaJpTgj0VCLuag4EQAizA0T9QEAAA== Subject: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 20:04:27 -0000 WG, I invite anyone interested to participate Today (Wednesday) at 15.50 in an adhoc discussion around the RTP to Media Stream API mapping. Lets meet at 15.50 at the level 2 bar. If we are to many to fit we will have to find some other spot. I appreciate a heads up through a private email that you intended to participate. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From mohammedsraad@raadtech.com Wed Nov 6 12:34:03 2013 Return-Path: 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 E0FD721E8192 for ; Wed, 6 Nov 2013 12:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=-1.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_URI_MEDS=0.842] 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 cu2jPCPYe3aZ for ; Wed, 6 Nov 2013 12:33:59 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 58CA521E818A for ; Wed, 6 Nov 2013 12:33:58 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so28159wgg.28 for ; Wed, 06 Nov 2013 12:33:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=C1N2sVBGGnuLT1ci5dkeptsxmYUBKJzAqg6/MyWTsgs=; b=Se4dwon4dsGdwmT9TF6Hf6Is3HWNqQDRVMoHElDKnrJH5rrJiUgC5ESCULezaNmL/E 4xbjYIAjD0GCbcsbK/p0ejY16uZEDKdEVCLa+SXUDT4AD3KUQnZldPioRPXs5jdm1DS1 oB2F+Ov0IUfrOYOOzge6vC6Yd0ENXouqEsSfGDOV9D/DLXOv7woQ26m9qxsdXZl8Cxuk r6KOxcMFPOYdSJGSJtSZZ2uig2+BPBng8rM9a9NaeHEsWmrKsIQzR6++wE5aXEhiXapl Qzm0yemYI6QjhUC4j4y6exol7+NipPJdEHh9A4hvOWGna+d8WzsJ0oVgqzMjF6rh1rM8 Jxqw== X-Gm-Message-State: ALoCoQl4UGa000rgrfIV1uBV6wLJ2eVk+Rd7/5e9aBQlNxXXGcAytEWAXbpcyaXSF93CAOfJzrvE MIME-Version: 1.0 X-Received: by 10.180.76.196 with SMTP id m4mr3991723wiw.59.1383770038146; Wed, 06 Nov 2013 12:33:58 -0800 (PST) Received: by 10.194.179.166 with HTTP; Wed, 6 Nov 2013 12:33:58 -0800 (PST) In-Reply-To: <527A15A3.2090006@bbs.darktech.org> References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <527A06EF.2070007@bbs.darktech.org> <527A0C4D.7020707@gmail.com> <527A15A3.2090006@bbs.darktech.org> Date: Thu, 7 Nov 2013 07:33:58 +1100 Message-ID: From: Mohammed Raad To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=f46d043c7f069333e404ea88112d 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 20:34:04 -0000 --f46d043c7f069333e404ea88112d Content-Type: text/plain; charset=ISO-8859-1 Hi, There isn't much new in the arguments for and against VP8 vs H.264. Its clear that there are concerns that are beyond how well each codec performs and whether or not it is free. Although I recognize that the transcoding option does not address the P2P use case, I do think that the goal of interoperability can be better achieved through a two phase approach. The first is enabling end-points to inter-operate through the availability of transcoding from the service provider. The second is to make one of the codecs the defacto MTI because of the its higher level of adoption. Yes, we may never get to a single MTI if we follow this path but at least we will have endpoints inter-operating. Besides, there are multiple other difficulties in getting seamless P2P communications working all the time, so I would suggest focusing on the service provider centered use case first. BR, Mohammed On Wed, Nov 6, 2013 at 9:10 PM, cowwoc wrote: > On 06/11/2013 4:30 AM, Daniel-Constantin Mierla wrote: > >> As it stands today, there are well known IPR issues with h264. Cisco's >> move doesn't lift them. >> >> So why to choose it if falls under the rules to remove it? >> >> > No one says it has to be H.264 and VP8. It could be H.261 and VP8. > > > With both on board, I still expect the majority of the apps will >> implement only the most convenient for them, eventually expecting the other >> to have both. Then responsibility is getting divided, like "it's not _only_ >> my fault", blaming the other end point as well. >> > > That is a reasonable concern, and one that we need to address. > Implementations that violate these rules will make it harder for us to > replace older MTI codecs without breaking backwards compatibility. > > Gili > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Mohammed Raad, PhD. Partner RAADTECH CONSULTING P.O. Box 113 Warrawong NSW 2502 Australia Phone: +61 414451478 Email: mohammedsraad@raadtech.com --f46d043c7f069333e404ea88112d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

There isn't much new in the arg= uments for and against VP8 vs H.264. Its clear that there are concerns that= are beyond how well each codec performs and whether or not it is free. Alt= hough I recognize that the transcoding option does not address the P2P use = case, I do think that the goal of interoperability can be better achieved t= hrough a two phase approach. The first is enabling end-points to inter-oper= ate through the availability of transcoding from the service provider. The = second is to make one of the codecs the defacto MTI because of the its high= er level of adoption. Yes, we may never get to a single MTI if we follow th= is path but at least we will have endpoints inter-operating. Besides, there= are multiple other difficulties in getting seamless P2P communications wor= king all the time, so I would suggest focusing on the service provider cent= ered use case first.

BR,
Mohammed


On Wed, Nov 6, 2013 at 9:10 PM, co= wwoc <cowwoc@bbs.darktech.org> wrote:
On 06/11/2013 4:30 AM, Dan= iel-Constantin Mierla wrote:
As it stands today, there are well known IPR issues with h264. Cisco's = move doesn't lift them.

So why to choose it if falls under the rules to remove it?


=A0 =A0 No one says it has to be H.264 and VP8. It could be H.261 and VP8.<= div class=3D"im">

With both on board, I still expect the majority of the apps will implement = only the most convenient for them, eventually expecting the other to have b= oth. Then responsibility is getting divided, like "it's not _only_= my fault", blaming the other end point as well.

=A0 =A0 That is a reasonable concern, and one that we need to address. Impl= ementations that violate these rules will make it harder for us to replace = older MTI codecs without breaking backwards compatibility.

Gili

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb



--
= Mohammed Raad, PhD.
Partner
RAADTECH CONSULTING
P.O. Box 113
Wa= rrawong
NSW 2502 Australia
Phone: +61 414451478
Email: mohammedsraad@raadtech= .com
--f46d043c7f069333e404ea88112d-- From pkyzivat@alum.mit.edu Wed Nov 6 12:38:50 2013 Return-Path: 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 79BBF11E8159 for ; Wed, 6 Nov 2013 12:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 6Xe54dvGzR-0 for ; Wed, 6 Nov 2013 12:38:44 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 7857611E81B9 for ; Wed, 6 Nov 2013 12:38:44 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta09.westchester.pa.mail.comcast.net with comcast id mJrg1m0041GhbT859Lek0a; Wed, 06 Nov 2013 20:38:44 +0000 Received: from dhcp-a6d1.meeting.ietf.org ([31.133.166.209]) by omta07.westchester.pa.mail.comcast.net with comcast id mLcZ1m00C4XQ1zz3TLcbAQ; Wed, 06 Nov 2013 20:36:42 +0000 Message-ID: <527AA850.3050807@alum.mit.edu> Date: Wed, 06 Nov 2013 12:36:32 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Justin Uberti References: <527420FF.2@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383770324; bh=50Mzdg1gYUEfnypAhoB5ngSwOZRCrjjeEdEDZ1CzJ3o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YnDoywopHjDRQKHd9yY1def0N6BL18QH6gtwQFXvlwn4c8AxLvQskz568H878BvOm e7RmWpIbhW5ysHtbMZxclAGC08LZpYQVtcAoGr6xQo+MFHP9DXBHPZbUkhNaF0Lkkc 8wcbp68jkm8plC0B7Z/wOm4BAFgm3jaDPfwTJHvhr02wtf2qcyS9MIASdpzwRGiUCY 0akIMhPSw0/QDrONiq26IlC51t9pv7WAKj2ecXfxkvC3gcoYC9iYKao8M8m7NAyWoz iPB8yd0gAC60AHSr9EWp2Z0+KnnPChl3orfULwV6CxtnDnFpxyO7PQlf7M8booGaBl WR3TumN9Ea3sg== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Recycling m-lines X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 20:38:50 -0000 On 11/3/13 11:09 PM, Justin Uberti wrote: > > On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat > wrote: ... > Later in 5.2.2: > > o If a m= section exists in the current local description, but has > its state set to inactive or recvonly, and a new MediaStreamTrack > is added, the previously existing m= section MUST be recycled > instead of creating a new m= section. [OPEN ISSUE: Nail down > exactly what this means. Should the codecs remain the same? > (No.) Should ICE restart? (No.) Can the "a=mid" attribute be > changed? (Yes?)] > > This seems to assume that there is no existing MediaStreamTrack for > these m-lines. > > Yes. The text should state that more clearly. > > If there is, then > - the m-line shouldn't be recycled. > If there isn't, then > - where do its address and port come from? > - what is managing the RTCP? > > > The m= section will still have completed ICE negotiation, despite being > marked as inactive. So the address/port information should already be > present. *Why* would you do this if there is no MediaStreamTrack and hence no possibility of using the port? IOW, why not use port zero in these cases? > I don't follow your question about who is managing RTCP. It may be a misunderstanding on my part. My thinking is that the MediaStreamTrack is a surrogate for the resource that manages the RTP/RTCP for that track. If so, then no track -> no RTCP. Of course, with bundling, that resource gets spread across multiple MediaStreamTracks. Thanks, Paul From michael@voip.co.uk Wed Nov 6 12:47:31 2013 Return-Path: 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 7E06A21F9EB5 for ; Wed, 6 Nov 2013 12:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 LgLdL7nxkiBF for ; Wed, 6 Nov 2013 12:47:25 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with SMTP id B4D2921F9BC3 for ; Wed, 6 Nov 2013 12:47:24 -0800 (PST) Received: from mail-we0-f181.google.com ([74.125.82.181]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUnqq3JC2pgUFpVBPZzm9EFcM4L/rA6rw@postini.com; Wed, 06 Nov 2013 12:47:24 PST Received: by mail-we0-f181.google.com with SMTP id t60so45434wes.26 for ; Wed, 06 Nov 2013 12:47:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=q0L/DRnPAnMyuRaINdx1Hvz7vCmuGUPA0VVb38aRMVI=; b=hI7GMRXhd+M8LPlXHysCf8PIFqbMyd6CjP2fcPiNL/UKlHcCu4f1nUxbd+vUji2Ffp Tjsg7gBjXu2I2s0PscOBzDl+n5OKpalQabKGG3I6IWPwAeePiyO8o32SeDFnpRFQIaWZ EhYGIZlE+oZ11498K024uAlgnimARmS+ctSU6r2mGo+dAp2d7nlTsxTPN6s23g91aCsS aZsdz67F6KThbdLUuZOj5SiQwT9o5gGPi5reFcf9A27XncJ0w4HO1LVzL8KDSYHz85tx 9Su3MhXsZIFVh1ss2DT/w/Dxy+yRvZG9Tjo+9bXgQATS1r17uG5ExEGDhGhJKKS0PKTU mgfw== X-Gm-Message-State: ALoCoQldK7RthpB0MwRRnFR+9a20nh474obzfkZ80bEpc9svr60FAhpVnHqV8gP4YU6YSR31tFX5DioO2Dv+fsR9lEiMyBuSmhF7Dh4pMAEIc5Vc4Th6QpfQrCxwdJhl8RcmgO//p9fpLu2KnHiGcxoSnwesyBbFkw== X-Received: by 10.194.185.73 with SMTP id fa9mr4230605wjc.29.1383770843014; Wed, 06 Nov 2013 12:47:23 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.185.73 with SMTP id fa9mr4230601wjc.29.1383770842959; Wed, 06 Nov 2013 12:47:22 -0800 (PST) Received: by 10.194.93.34 with HTTP; Wed, 6 Nov 2013 12:47:22 -0800 (PST) In-Reply-To: References: <527420FC.3070805@alum.mit.edu> Date: Wed, 6 Nov 2013 12:47:22 -0800 Message-ID: From: Michael Procter To: Justin Uberti Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 20:47:31 -0000 On 3 November 2013 22:55, Justin Uberti wrote: > According to section 5.2.5, it seems that this is only the cases for offers > triggered by offerless reINVITEs. I don't think we want to be re-allocating > and negotiating codecs every time we want to make a change to the session > descriptions in use. Would the partial offer/answer work address at least part of this? m-lines that you don't want to change wouldn't need to be advertised at all, rather than being advertised with a restricted codec set. Michael From harald@alvestrand.no Wed Nov 6 12:51:09 2013 Return-Path: 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 ABDAF11E80E2 for ; Wed, 6 Nov 2013 12:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.484 X-Spam-Level: X-Spam-Status: No, score=-110.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 c59zS127V+sE for ; Wed, 6 Nov 2013 12:51:05 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB0921E811C for ; Wed, 6 Nov 2013 12:51:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6245339E246 for ; Wed, 6 Nov 2013 21:51:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG8w-hTCZRes for ; Wed, 6 Nov 2013 21:51:02 +0100 (CET) Received: from [IPv6:2001:67c:370:160:6056:eeee:f72d:1d19] (unknown [IPv6:2001:67c:370:160:6056:eeee:f72d:1d19]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5FDE439E230 for ; Wed, 6 Nov 2013 21:51:02 +0100 (CET) Message-ID: <527AABB3.1040203@alvestrand.no> Date: Wed, 06 Nov 2013 21:50:59 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <527AA11B.8090408@ericsson.com> In-Reply-To: <527AA11B.8090408@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 20:51:09 -0000 On 11/06/2013 09:05 PM, Magnus Westerlund wrote: > WG, > > I invite anyone interested to participate Today (Wednesday) at 15.50 in > an adhoc discussion around the RTP to Media Stream API mapping. Which parts of which documents do you want to focus discussion on? The subject line isn't clear enough that I'm sure what you want to talk about. > > Lets meet at 15.50 at the level 2 bar. If we are to many to fit we will > have to find some other spot. I appreciate a heads up through a private > email that you intended to participate. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From harald@alvestrand.no Wed Nov 6 12:59:24 2013 Return-Path: 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 49DDE21E805F for ; Wed, 6 Nov 2013 12:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 O0iAfu8nr9bO for ; Wed, 6 Nov 2013 12:59:19 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0E88F11E80E2 for ; Wed, 6 Nov 2013 12:59:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 84B4739E230 for ; Wed, 6 Nov 2013 21:59:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn5yFwnF5pIP for ; Wed, 6 Nov 2013 21:59:16 +0100 (CET) Received: from [IPv6:2001:67c:370:160:6056:eeee:f72d:1d19] (unknown [IPv6:2001:67c:370:160:6056:eeee:f72d:1d19]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5DEB639E09F for ; Wed, 6 Nov 2013 21:59:16 +0100 (CET) Message-ID: <527AADA1.7060304@alvestrand.no> Date: Wed, 06 Nov 2013 21:59:13 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <527420FF.2@alum.mit.edu> <527AA850.3050807@alum.mit.edu> In-Reply-To: <527AA850.3050807@alum.mit.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Recycling m-lines X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 20:59:24 -0000 On 11/06/2013 09:36 PM, Paul Kyzivat wrote: > On 11/3/13 11:09 PM, Justin Uberti wrote: >> >> On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat > > wrote: > ... >> Later in 5.2.2: >> >> o If a m= section exists in the current local description, >> but has >> its state set to inactive or recvonly, and a new >> MediaStreamTrack >> is added, the previously existing m= section MUST be recycled >> instead of creating a new m= section. [OPEN ISSUE: Nail down >> exactly what this means. Should the codecs remain the same? >> (No.) Should ICE restart? (No.) Can the "a=mid" >> attribute be >> changed? (Yes?)] >> >> This seems to assume that there is no existing MediaStreamTrack for >> these m-lines. >> >> Yes. The text should state that more clearly. >> >> If there is, then >> - the m-line shouldn't be recycled. >> If there isn't, then >> - where do its address and port come from? >> - what is managing the RTCP? >> >> >> The m= section will still have completed ICE negotiation, despite being >> marked as inactive. So the address/port information should already be >> present. > > *Why* would you do this if there is no MediaStreamTrack and hence no > possibility of using the port? > > IOW, why not use port zero in these cases? > >> I don't follow your question about who is managing RTCP. > > It may be a misunderstanding on my part. > > My thinking is that the MediaStreamTrack is a surrogate for the > resource that manages the RTP/RTCP for that track. If so, then no > track -> no RTCP. > > Of course, with bundling, that resource gets spread across multiple > MediaStreamTracks. That's why thinking of it in the way you suggest is likely to lead to misunderstandings and confusion all around. I've had greater success thinking of a MediaStreamTrack as an SSRC; the resource that manages the RTP/RTCP is then a container that contains MSTs. From a.badger@gmail.com Wed Nov 6 13:11:54 2013 Return-Path: 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 713D021E81AB for ; Wed, 6 Nov 2013 13:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599] 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 oIdb4Ur1wZl4 for ; Wed, 6 Nov 2013 13:11:53 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7021F9ECA for ; Wed, 6 Nov 2013 13:11:52 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id p10so69947pdj.22 for ; Wed, 06 Nov 2013 13:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=4kRHu9hHaw4+1q7YD9+KIZLzK+vX0Tb3AWLfhYU/+/k=; b=ec43xZe6KINao4zDSfb0VwuOHFR2XeLvxSibkw9a7IBnDeF1Xu4LjL1Y/s1TlfjVGv fP0O0Z7Qm4gqD3n5X3sohKy4PsNv0s3Zukieib1cLK/4wwV8/qGo43pmaO/Kpun9JZRY ZJ3QJ11XdybAN/Uu/oWL6P//rg297pQXAoPLrA4TC6n5wGctd8fbClKGG0VNAD169T4z RB8MNkG/2JUFd57jbAaVLSQ05JnOxAWdQ+0Z1v8BwJDgsqDUVANaX7xvrEAi3LVWAyq7 GYdZg1W7lQCkun/xJpa3ypPsf7Ou/lQHLqOa47fy0U+Eh4LM+e5Q+JPnTBp31jICJNfo Twwg== X-Received: by 10.66.188.203 with SMTP id gc11mr5815777pac.63.1383772312254; Wed, 06 Nov 2013 13:11:52 -0800 (PST) Received: from unaka.lan ([65.78.164.85]) by mx.google.com with ESMTPSA id fa4sm780198pab.17.2013.11.06.13.11.50 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Nov 2013 13:11:51 -0800 (PST) Date: Wed, 6 Nov 2013 13:11:49 -0800 From: Toshio Kuratomi To: rtcweb@ietf.org Message-ID: <20131106211149.GA1763@unaka.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NNMNuNcS5bf7Nky/" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 21:11:54 -0000 --NNMNuNcS5bf7Nky/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Greetings, I serve on the Engineering Steering Committee for the Fedora Project, a Linux Distribution. A few days ago we were asked if we could give input on OpenH264 becoming a MTI codec in the rtcweb standard. We discussed the issue at our weekly meeting and agreed on this statement: Fedora is a distribution that cares about software freedom and our users freedom. Firstly, we cannot ship binary-only prebuilt software within Fedora. This rules out inclusion of OpenH264 binaries direct from Cisco, or other providers. Secondly, we cannot ship software built from source which is not free for any use, freely distributable, and free from patent restrictions. Therefore, Fedora is similarly unable to ship rebuilt OpenH264 code. Fedora would be much happier with a non-patent encumbered codec in the standard as it would relieve us of the burden of caring for a codec implementation that we cannot fix if it is buggy on our platform, let us ship improved or more efficient versions of the codec if that is asked for, and relieve us of the burden of making sure all implementors of the standard were using a proper technique to retrieve the patent-encumbered portion from the internet so that we weren't shipping non-free code. Acceptance of an insufficiently-free license of the OpenH264 codec would mean that open-source vendors are not able to implement it on their own terms. They must rely on the implementation provided by a third party (Cisco) and create workarounds to have the user download that implementation after installation, increasing the burden on open-source users. This creates an unequal environment for open-source vendors. I hope that helps in your decision making. Thank you for your time, Toshio Kuratomi --NNMNuNcS5bf7Nky/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlJ6sJUACgkQX6yAic2E7kjY/QCfVXLAnx47EtnkLplu4EXTJTQ+ ExwAnifsZu9PbFfKuQA1u9ckNBuCZydT =4MFW -----END PGP SIGNATURE----- --NNMNuNcS5bf7Nky/-- From matthew.kaufman@skype.net Wed Nov 6 13:24:04 2013 Return-Path: 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 5CB1A11E8162 for ; Wed, 6 Nov 2013 13:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 HtewI5kMkuE9 for ; Wed, 6 Nov 2013 13:23:58 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id D1BE211E8159 for ; Wed, 6 Nov 2013 13:23:56 -0800 (PST) Received: from DM2PR03CA003.namprd03.prod.outlook.com (10.141.52.151) by BN1PR03MB024.namprd03.prod.outlook.com (10.255.224.42) with Microsoft SMTP Server (TLS) id 15.0.815.6; Wed, 6 Nov 2013 21:23:47 +0000 Received: from BN1AFFO11FD020.protection.gbl (2a01:111:f400:7c10::177) by DM2PR03CA003.outlook.office365.com (2a01:111:e400:2414::23) with Microsoft SMTP Server (TLS) id 15.0.815.6 via Frontend Transport; Wed, 6 Nov 2013 21:23:47 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD020.mail.protection.outlook.com (10.58.52.80) with Microsoft SMTP Server (TLS) id 15.0.815.5 via Frontend Transport; Wed, 6 Nov 2013 21:23:46 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.187]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0158.002; Wed, 6 Nov 2013 21:23:05 +0000 From: "Matthew Kaufman (SKYPE)" To: Toshio Kuratomi , "rtcweb@ietf.org" Thread-Topic: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec Thread-Index: AQHO2zTbiaKQn9DEiEqrQAYM3w+FD5oYtkjQ Date: Wed, 6 Nov 2013 21:23:03 +0000 Message-ID: References: <20131106211149.GA1763@unaka.lan> In-Reply-To: <20131106211149.GA1763@unaka.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(51744003)(13464003)(51704005)(377454003)(66066001)(65816001)(55846006)(50466002)(80022001)(44976005)(80976001)(74662001)(74706001)(2656002)(46406003)(76482001)(81816001)(33656001)(85306002)(56776001)(74876001)(54316002)(69226001)(81686001)(81342001)(59766001)(79102001)(81542001)(53806001)(74366001)(51856001)(87266001)(46102001)(19580395003)(77096001)(20776003)(47446002)(47776003)(50986001)(23726002)(47736001)(74502001)(56816003)(63696002)(77982001)(54356001)(83072001)(19580405001)(47976001)(83322001)(4396001)(76786001)(31966008)(49866001)(6806004)(224303002)(224313003)(76796001)(87936001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB024; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0022134A87 X-OriginatorOrg: skype.net Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 21:24:04 -0000 Which "non-patent-enumbered" codec did you have in mind? Matthew Kaufman > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Toshio Kuratomi > Sent: Wednesday, November 6, 2013 1:12 PM > To: rtcweb@ietf.org > Subject: [rtcweb] One consuming project's concerns with OpenH264 as a MTI > codec >=20 >=20 > Greetings, >=20 > I serve on the Engineering Steering Committee for the Fedora Project, a > Linux Distribution. A few days ago we were asked if we could give input = on > OpenH264 becoming a MTI codec in the rtcweb standard. We discussed the > issue at our weekly meeting and agreed on this statement: >=20 >=20 > Fedora is a distribution that cares about software freedom and our users > freedom. Firstly, we cannot ship binary-only prebuilt software within Fed= ora. > This rules out inclusion of OpenH264 binaries direct from Cisco, or other > providers. Secondly, we cannot ship software built from source which is n= ot > free for any use, freely distributable, and free from patent restrictions= . > Therefore, Fedora is similarly unable to ship rebuilt OpenH264 code. >=20 > Fedora would be much happier with a non-patent encumbered codec in the > standard as it would relieve us of the burden of caring for a codec > implementation that we cannot fix if it is buggy on our platform, let us = ship > improved or more efficient versions of the codec if that is asked for, an= d > relieve us of the burden of making sure all implementors of the standard > were using a proper technique to retrieve the patent-encumbered portion > from the internet so that we weren't shipping non-free code. >=20 > Acceptance of an insufficiently-free license of the OpenH264 codec would > mean that open-source vendors are not able to implement it on their own > terms. They must rely on the implementation provided by a third party > (Cisco) and create workarounds to have the user download that > implementation after installation, increasing the burden on open-source > users. This creates an unequal environment for open-source vendors. >=20 >=20 > I hope that helps in your decision making. >=20 > Thank you for your time, > Toshio Kuratomi From magnus.westerlund@ericsson.com Wed Nov 6 13:25:03 2013 Return-Path: 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 DA00011E813B for ; Wed, 6 Nov 2013 13:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.534 X-Spam-Level: X-Spam-Status: No, score=-105.534 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 69zSo1hMwEOK for ; Wed, 6 Nov 2013 13:24:58 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA0311E8159 for ; Wed, 6 Nov 2013 13:24:57 -0800 (PST) X-AuditID: c1b4fb30-b7eff8e000006d14-6f-527ab3a8c506 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D5.6B.27924.8A3BA725; Wed, 6 Nov 2013 22:24:56 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.328.9; Wed, 6 Nov 2013 22:24:55 +0100 Message-ID: <527AB408.7040503@ericsson.com> Date: Wed, 6 Nov 2013 13:26:32 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: References: <527AA11B.8090408@ericsson.com> <527AABB3.1040203@alvestrand.no> In-Reply-To: <527AABB3.1040203@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvje6KzVVBBseXqlqs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMldXUwFnfwVPbsvsDUwzuPpYuTkkBAwkbh/9g4ThC0mceHe erYuRi4OIYFDjBInL/1jhnCWMUo8OrKNFaSKV0BbYuvM44wgNouAisSFLx1gNpuAhcTNH41s ILaoQLDE+VeL2SHqBSVOznzCAmKLCIhKvH48DWyOsIClxNEpJ8HqhQR8JPZu3gtWzymgK3F8 8UkgmwPoInGJnsYgkDCzgJ7ElKstjBC2vETz1tnMEK3aEg1NHawTGAVnIdk2C0nLLCQtCxiZ VzGy5yZm5qSXm29iBIbfwS2/DXYwbrovdohRmoNFSZz3w1vnICGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2MHOr8dWo/Cky3JF/TtRY+fEnwhVb3+kJuwZY+tv6d5nZcf/xS7711EM5Uj34b /mni/a1+X7Tdov0crrXy3Fr2tSjjc2LBH8azb6XPBa7k2ZhTHi/VnL+/6u+BJzxa0ls1nxzj Lcq4Hfmu9hxzzjfN3kTHc+dWl7TMW3w4LzzVfO2pVZ8WfbitxFKckWioxVxUnAgAKwNZZw0C AAA= Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 21:25:04 -0000 On 2013-11-06 12:50, Harald Alvestrand wrote: > On 11/06/2013 09:05 PM, Magnus Westerlund wrote: >> WG, >> >> I invite anyone interested to participate Today (Wednesday) at 15.50 in >> an adhoc discussion around the RTP to Media Stream API mapping. > Which parts of which documents do you want to focus discussion on? > > The subject line isn't clear enough that I'm sure what you want to talk > about. This is the followup on the open issue in the RTP usage draft. How does the RTP level entities such as SSRCs and CNAME relate to the W3C MediaStream API. /Magnus > >> >> Lets meet at 15.50 at the level 2 bar. If we are to many to fit we will >> have to find some other spot. I appreciate a heads up through a private >> email that you intended to participate. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From juberti@google.com Wed Nov 6 13:30:22 2013 Return-Path: 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 18CE721E8155 for ; Wed, 6 Nov 2013 13:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 HHu8RGVVGhYf for ; Wed, 6 Nov 2013 13:30:19 -0800 (PST) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id B9D7621E805F for ; Wed, 6 Nov 2013 13:30:15 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id db12so69916veb.37 for ; Wed, 06 Nov 2013 13:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+ydNCEr1y/d+nG/+0010qNjYS58qW1SrQtxj5oUF7q0=; b=XC93sAYLxQkG/uA7ACgwpVKutIYmvyIypjqbl5KksyBjUV7SOgEV+ZHUNePV7fzNK7 m+F+HVZlS7KxQnqFqdcZybYtbVIz5r3PS4HqtuHHGD7ChvKHsDVVbD3LU+Iq/sCGKLdJ S2OZlHpIaWmze/iTRetAtttAfKfPGyQg3qTZ5fly9yQMUAORKjnfWGtQ8qAe2PhK4xZo zsDmRRCABJ8myo5zYQ8JwrTnDNtkucOGwrwr/FLQrqlKSeBiCPdxANLZDsyjSKSoFRCE E0buRDyWUAR9FEzVkoCqPDw0y6Nd1FfN9KLYZ7T2aaLBrCvG2s5u6w/61jNZ4M2MWokn G/wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+ydNCEr1y/d+nG/+0010qNjYS58qW1SrQtxj5oUF7q0=; b=CDcW6T6FSvLrMsvOqOT65Vlwu2e+WvzO/F22Gw8lelP2RBUTro4VA0T+yimuvdHeNL p5sFQdaOqyHPGNLlA9LjIJTN1ihwLZa8hXBMwMRUX7q1mxpmweLtdoHlwZc2degcljTr O880FoWWa58v/XV6QniCqUud+OibyExgC+Aa+ym8vt8p2+12U3JAEyw7VH8sITV6W48a FzhUjv6oUtUrbeoyfV8bAegs/Cp+IsqW5YDloSlzeWmffzJD+YqlGzGV9e/qNPnpoeCd sZ8AmJpfykuvOv6ZTm2uJ51OWMonqgBXNuQCiglxB9FQH1bxPGVUkp6EyA6LhbRQfiP+ 50dg== X-Gm-Message-State: ALoCoQnpX7B2RQgtpZV9aunjV9CuU9wk++pv6iwP5Z7iNgSclLNY+lrf+93LlWcSYRwMF9b2+o4KSF9LWMovq7Mfx4PjxW3jZtQPYeZdyS9PeIZy65MirrtzYjYknjOwDFVwi8VeyAQPnQY9mPAOq1ruI6XilPEdie+XOR7VwaMe+zyeOPphF9I3lygpPAg6T5K5FI3wlUQj X-Received: by 10.52.32.131 with SMTP id j3mr184374vdi.62.1383773412324; Wed, 06 Nov 2013 13:30:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Wed, 6 Nov 2013 13:29:52 -0800 (PST) In-Reply-To: References: <527420FC.3070805@alum.mit.edu> From: Justin Uberti Date: Wed, 6 Nov 2013 13:29:52 -0800 Message-ID: To: Michael Procter Content-Type: multipart/alternative; boundary=bcaec51d204ab10ed404ea88daa0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 21:30:22 -0000 --bcaec51d204ab10ed404ea88daa0 Content-Type: text/plain; charset=UTF-8 Yes, it would. But I think the problem still exists for applications that don't use partial offer/answers. On Wed, Nov 6, 2013 at 12:47 PM, Michael Procter wrote: > On 3 November 2013 22:55, Justin Uberti wrote: > > According to section 5.2.5, it seems that this is only the cases for > offers > > triggered by offerless reINVITEs. I don't think we want to be > re-allocating > > and negotiating codecs every time we want to make a change to the session > > descriptions in use. > > Would the partial offer/answer work address at least part of this? > m-lines that you don't want to change wouldn't need to be advertised > at all, rather than being advertised with a restricted codec set. > > Michael > --bcaec51d204ab10ed404ea88daa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, it would. But I think the problem still exists for ap= plications that don't use partial offer/answers.


On Wed, Nov 6, 2013 at 12:47 P= M, Michael Procter <michael@voip.co.uk> wrote:
On 3 November 2013 22:55, = Justin Uberti <juberti@google.com<= /a>> wrote:
> According to section 5.2.5, it seems that this is only the cases for o= ffers
> triggered by offerless reINVITEs. I don't think we want to be re-a= llocating
> and negotiating codecs every time we want to make a change to the sess= ion
> descriptions in use.

Would the partial offer/answer work address at least part of this? m-lines that you don't want to change wouldn't need to be advertise= d
at all, rather than being advertised with a restricted codec set.

Michael

--bcaec51d204ab10ed404ea88daa0-- From juberti@google.com Wed Nov 6 13:38:13 2013 Return-Path: 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 C8C1F11E812B for ; Wed, 6 Nov 2013 13:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 KKET4p1tZkGF for ; Wed, 6 Nov 2013 13:38:11 -0800 (PST) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8091F21E81A7 for ; Wed, 6 Nov 2013 13:37:47 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id x16so74261vbf.37 for ; Wed, 06 Nov 2013 13:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A3lwPQw5tb8IrFEUYtSN1SHXHjf4DQKN+gHlQhQsFhY=; b=kDZjAP/LkidwENONnsMDLv4ON6u85pUWOR38UlYuPxnUVxkFFQWCylH7Srqa8RyIuJ ZmIFXnE7bV+rwdLZT3KSRAmCnYFqIe5NwhKlknPIz5euk7fZhmuxJAAx059PBx94MuRu +MA+PnT04MnphhxIHmXn7XQB1ikGcS/vi1g7VpHpE3Q1dIk1qtFZPQ19W3xarwaE1P1+ H6c+jXMvIbIO8oVf/uhVty7EmfOD3nbMCuOMYbMVp36wSOlNR3EFKVXOsj/PjTgN+8gj cvv4kP3QhSkWyEGSpUpuiz7ozAhr2SP0Wj/nEvqjeIucAMJbcFTkaCgtaTQtXolLHap2 GowA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=A3lwPQw5tb8IrFEUYtSN1SHXHjf4DQKN+gHlQhQsFhY=; b=gv/3+B7VngIeO6XeYnEVCJvc7bed9rY6eBwTS4nB4KKgrY2pJ6JOhyI9Iy4wLJjzsK 4r9MZT6GDThtsoTUh6aILOeOvN50sNNwYGy8YOpDtRnPt5M8XMImipU6QyuLlMtkGaNT nEybzqY/e7QskGF9o/ZA42zZW7de1mGkd231jd8l2HEE6ozeEYirhRLRLm1+yAd3O2hI vlIe0peniv90ckVzQbMKVeVNng/dgz/GjFVqbvyE47jD6hBimo+0CW2HMYmEWTJ4EOCO usAYDD4cv5TwPl5OWBT9LT/OIOVM9ftBAnG+1H7DnWhEMH7X+S7SoyTMpPe9gfVs9D23 N8xA== X-Gm-Message-State: ALoCoQn39weK42qAT783GR9pSqzx2xAxKLPEhBqdasqfsGEGS4gK2AtroZ0Dg7Rm4qphduDkB2lJFP/GxdSpUCw4iajaiOxrsH1QIDQpQvTovhMBbAe/jtrEE6Q4R1CO9wU35jEh3Kt3AsmVlTdSoKIoVdbEdTzfd6XWYc2d6oK56VVUmtcNqD6dl9qCYjB3KF6hyh83ZDUu X-Received: by 10.220.174.200 with SMTP id u8mr4130319vcz.6.1383773865089; Wed, 06 Nov 2013 13:37:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Wed, 6 Nov 2013 13:37:24 -0800 (PST) In-Reply-To: References: <527420FC.3070805@alum.mit.edu> From: Justin Uberti Date: Wed, 6 Nov 2013 13:37:24 -0800 Message-ID: To: Michael Procter Content-Type: multipart/alternative; boundary=089e0149ca3aadaf8704ea88f55c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 21:38:14 -0000 --089e0149ca3aadaf8704ea88f55c Content-Type: text/plain; charset=UTF-8 >From the room discussion, I sensed 3 possible options to move forward. 1) MUST NOT renegotiate codecs etc. (new PeerConnection if you want to renegotiate) 2) MUST NOT renegotiate codecs etc. by default, but MUST support option to renegotiate (application controls renegotiation through constraint) 3) SHOULD NOT renegotiate codecs etc, but implementation MAY do so if desired (no application logic needed, but non-deterministic API behavior) "etc" here would not include anything that would result in the offer changing from the previously agreed-upon local description, including codecs, RTP header extensions, RTCP feedback mechanisms, BUNDLE groupings, or use of FEC/RTX. I proposed #1 in the room, but see #2 as a reasonable solution. That provides the application with full control over what it wants, as well as deterministic behavior. On Wed, Nov 6, 2013 at 1:29 PM, Justin Uberti wrote: > Yes, it would. But I think the problem still exists for applications that > don't use partial offer/answers. > > > On Wed, Nov 6, 2013 at 12:47 PM, Michael Procter wrote: > >> On 3 November 2013 22:55, Justin Uberti wrote: >> > According to section 5.2.5, it seems that this is only the cases for >> offers >> > triggered by offerless reINVITEs. I don't think we want to be >> re-allocating >> > and negotiating codecs every time we want to make a change to the >> session >> > descriptions in use. >> >> Would the partial offer/answer work address at least part of this? >> m-lines that you don't want to change wouldn't need to be advertised >> at all, rather than being advertised with a restricted codec set. >> >> Michael >> > > --089e0149ca3aadaf8704ea88f55c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From the room discussion, I sensed 3 possible options to m= ove forward.
1) MUST NOT renegotiate codecs etc. (new PeerConnection if= you want to renegotiate)
2) MUST NOT renegotiate codecs etc. by = default, but MUST support option to renegotiate (application controls reneg= otiation through constraint)
3) SHOULD NOT renegotiate codecs etc, but implementation MAY do so if = desired (no application logic needed, but non-deterministic API behavior)

"etc" here would not include anything tha= t would result in the offer changing from the previously agreed-upon local = description, including codecs, RTP header extensions, RTCP feedback mechani= sms, BUNDLE groupings, or use of FEC/RTX.

I proposed #1 in the room, but see #2 as a reasonable s= olution. That provides the application with full control over what it wants= , as well as deterministic behavior.


On Wed, Nov 6, 2013 at 1:29 PM, Justin U= berti <juberti@google.com> wrote:
Yes, it would. But I think the problem still exists for ap= plications that don't use partial offer/answers.


On Wed, Nov 6, 2013 at 12:47 PM, Michael Procter <michael@voip.co.uk&= gt; wrote:
On 3 November 2013 22:55, Justin Uberti= <juberti@google= .com> wrote:
> According to section 5.2.5, it seems that this is only the cases for o= ffers
> triggered by offerless reINVITEs. I don't think we want to be re-a= llocating
> and negotiating codecs every time we want to make a change to the sess= ion
> descriptions in use.

Would the partial offer/answer work address at least part of this? m-lines that you don't want to change wouldn't need to be advertise= d
at all, rather than being advertised with a restricted codec set.

Michael


--089e0149ca3aadaf8704ea88f55c-- From a.badger@gmail.com Wed Nov 6 13:43:37 2013 Return-Path: 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 9AB7521E81C4 for ; Wed, 6 Nov 2013 13:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599] 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 u5TvbAaDt6PX for ; Wed, 6 Nov 2013 13:43:08 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 392CF21E81D2 for ; Wed, 6 Nov 2013 13:41:28 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ld10so278830pab.10 for ; Wed, 06 Nov 2013 13:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=9YCZD6sX3zNn65ABaQMBSw0Mi2r0KNaFx6A7OHe1cx0=; b=SE2CrmdoirKg8Xj9G7442zEc3Zp/HjifNWsmdTvkzoYLNeXpWXdiNJ7+cF+JbUJDuo soUX/KZx6NKSAYfjeT0pLdpv7/M1O8JeoBbzJ1mrZHT4/xo0AharaxyVUP0wiE4kFetF HHZuoxHfEHmKOpvpjBgrcNCb4nNTWfT/hsJj7CIitjtB79oQK6pJJWJitCB2Y/FSvjGn uZ9ZqDjbOvLkPPtyqKVIwxTkGYakp4zS1+jUKP2eOg7lEuTR62pdmYQyS1wcGhsy4lET UMFtn4IxGYFQ+UjHJlNqg7UZq3pKEnBHsut+jmb65h+UoFlQfZVoXQjuCcdD07BVooaa mR4w== X-Received: by 10.67.23.227 with SMTP id id3mr6086143pad.101.1383774084628; Wed, 06 Nov 2013 13:41:24 -0800 (PST) Received: from unaka.lan ([65.78.164.85]) by mx.google.com with ESMTPSA id i6sm232578pbc.1.2013.11.06.13.41.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Nov 2013 13:41:23 -0800 (PST) Date: Wed, 6 Nov 2013 13:41:21 -0800 From: Toshio Kuratomi To: "Matthew Kaufman (SKYPE)" Message-ID: <20131106214121.GB1763@unaka.lan> References: <20131106211149.GA1763@unaka.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZATCr4BkWovzAAkA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 21:43:40 -0000 --ZATCr4BkWovzAAkA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 06, 2013 at 09:23:03PM +0000, Matthew Kaufman (SKYPE) wrote: > Which "non-patent-enumbered" codec did you have in mind? >=20 Fedora currently ships VP8 and would consider it acceptable. -Toshio > Matthew Kaufman >=20 > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Toshio Kuratomi > > Sent: Wednesday, November 6, 2013 1:12 PM > > To: rtcweb@ietf.org > > Subject: [rtcweb] One consuming project's concerns with OpenH264 as a M= TI > > codec > >=20 > >=20 > > Greetings, > >=20 > > I serve on the Engineering Steering Committee for the Fedora Project, a > > Linux Distribution. A few days ago we were asked if we could give inpu= t on > > OpenH264 becoming a MTI codec in the rtcweb standard. We discussed the > > issue at our weekly meeting and agreed on this statement: > >=20 > >=20 > > Fedora is a distribution that cares about software freedom and our users > > freedom. Firstly, we cannot ship binary-only prebuilt software within F= edora. > > This rules out inclusion of OpenH264 binaries direct from Cisco, or oth= er > > providers. Secondly, we cannot ship software built from source which is= not > > free for any use, freely distributable, and free from patent restrictio= ns. > > Therefore, Fedora is similarly unable to ship rebuilt OpenH264 code. > >=20 > > Fedora would be much happier with a non-patent encumbered codec in the > > standard as it would relieve us of the burden of caring for a codec > > implementation that we cannot fix if it is buggy on our platform, let u= s ship > > improved or more efficient versions of the codec if that is asked for, = and > > relieve us of the burden of making sure all implementors of the standard > > were using a proper technique to retrieve the patent-encumbered portion > > from the internet so that we weren't shipping non-free code. > >=20 > > Acceptance of an insufficiently-free license of the OpenH264 codec would > > mean that open-source vendors are not able to implement it on their own > > terms. They must rely on the implementation provided by a third party > > (Cisco) and create workarounds to have the user download that > > implementation after installation, increasing the burden on open-source > > users. This creates an unequal environment for open-source vendors. > >=20 > >=20 > > I hope that helps in your decision making. > >=20 > > Thank you for your time, > > Toshio Kuratomi --ZATCr4BkWovzAAkA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlJ6t4EACgkQX6yAic2E7kgTKQCfWVXKPwA9cdm25Qdyg+C2xnCs cSIAn3FyOqA3MuPr3/upWExuNxEPpLSX =0CbV -----END PGP SIGNATURE----- --ZATCr4BkWovzAAkA-- From andrew.hutton@unify.com Wed Nov 6 14:02:05 2013 Return-Path: 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 500D121F9ED1 for ; Wed, 6 Nov 2013 14:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=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 Xh595orMxbZE for ; Wed, 6 Nov 2013 14:02:00 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id A9E3921F9F19 for ; Wed, 6 Nov 2013 14:01:59 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 26BFA1EB86C9; Wed, 6 Nov 2013 23:01:52 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 23:01:51 +0100 From: "Hutton, Andrew" To: Justin Uberti , Michael Procter Thread-Topic: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers Thread-Index: AQHO2zhhRkimDg8HS1yf9W6X1FrNbJoYwKAg Date: Wed, 6 Nov 2013 22:01:51 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net> References: <527420FC.3070805@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17C337D0MCHP04MSXglobal_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 22:02:05 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17C337D0MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB2b3RlIGZvciBvcHRpb24gMiDigJMgQXBwbGljYXRpb24gY29udHJvbHMgcmVuZWdvdGlhdGlv biB0aHJvdWdoIGNvbnN0cmFpbnQuDQoNCk9wdGlvbiAxIHdvdWxkIGJlIGJhZC4NCg0KT3B0aW9u IDMgd291bGQgYmUgdmVyeSBiYWQuDQoNCkFuZHkNCg0KDQpGcm9tOiBydGN3ZWItYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVz dGluIFViZXJ0aQ0KU2VudDogMDYgTm92ZW1iZXIgMjAxMyAxMzozNw0KVG86IE1pY2hhZWwgUHJv Y3Rlcg0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIGRyYWZ0LWll dGYtcnRjd2ViLWpzZXAtMDUgLSBTdWJzZXF1ZW50IE9mZmVycw0KDQpGcm9tIHRoZSByb29tIGRp c2N1c3Npb24sIEkgc2Vuc2VkIDMgcG9zc2libGUgb3B0aW9ucyB0byBtb3ZlIGZvcndhcmQuDQox KSBNVVNUIE5PVCByZW5lZ290aWF0ZSBjb2RlY3MgZXRjLiAobmV3IFBlZXJDb25uZWN0aW9uIGlm IHlvdSB3YW50IHRvIHJlbmVnb3RpYXRlKQ0KMikgTVVTVCBOT1QgcmVuZWdvdGlhdGUgY29kZWNz IGV0Yy4gYnkgZGVmYXVsdCwgYnV0IE1VU1Qgc3VwcG9ydCBvcHRpb24gdG8gcmVuZWdvdGlhdGUg KGFwcGxpY2F0aW9uIGNvbnRyb2xzIHJlbmVnb3RpYXRpb24gdGhyb3VnaCBjb25zdHJhaW50KQ0K MykgU0hPVUxEIE5PVCByZW5lZ290aWF0ZSBjb2RlY3MgZXRjLCBidXQgaW1wbGVtZW50YXRpb24g TUFZIGRvIHNvIGlmIGRlc2lyZWQgKG5vIGFwcGxpY2F0aW9uIGxvZ2ljIG5lZWRlZCwgYnV0IG5v bi1kZXRlcm1pbmlzdGljIEFQSSBiZWhhdmlvcikNCg0KImV0YyIgaGVyZSB3b3VsZCBub3QgaW5j bHVkZSBhbnl0aGluZyB0aGF0IHdvdWxkIHJlc3VsdCBpbiB0aGUgb2ZmZXIgY2hhbmdpbmcgZnJv bSB0aGUgcHJldmlvdXNseSBhZ3JlZWQtdXBvbiBsb2NhbCBkZXNjcmlwdGlvbiwgaW5jbHVkaW5n IGNvZGVjcywgUlRQIGhlYWRlciBleHRlbnNpb25zLCBSVENQIGZlZWRiYWNrIG1lY2hhbmlzbXMs IEJVTkRMRSBncm91cGluZ3MsIG9yIHVzZSBvZiBGRUMvUlRYLg0KDQpJIHByb3Bvc2VkICMxIGlu IHRoZSByb29tLCBidXQgc2VlICMyIGFzIGEgcmVhc29uYWJsZSBzb2x1dGlvbi4gVGhhdCBwcm92 aWRlcyB0aGUgYXBwbGljYXRpb24gd2l0aCBmdWxsIGNvbnRyb2wgb3ZlciB3aGF0IGl0IHdhbnRz LCBhcyB3ZWxsIGFzIGRldGVybWluaXN0aWMgYmVoYXZpb3IuDQoNCk9uIFdlZCwgTm92IDYsIDIw MTMgYXQgMToyOSBQTSwgSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29tPG1haWx0bzpq dWJlcnRpQGdvb2dsZS5jb20+PiB3cm90ZToNClllcywgaXQgd291bGQuIEJ1dCBJIHRoaW5rIHRo ZSBwcm9ibGVtIHN0aWxsIGV4aXN0cyBmb3IgYXBwbGljYXRpb25zIHRoYXQgZG9uJ3QgdXNlIHBh cnRpYWwgb2ZmZXIvYW5zd2Vycy4NCg0KT24gV2VkLCBOb3YgNiwgMjAxMyBhdCAxMjo0NyBQTSwg TWljaGFlbCBQcm9jdGVyIDxtaWNoYWVsQHZvaXAuY28udWs8bWFpbHRvOm1pY2hhZWxAdm9pcC5j by51az4+IHdyb3RlOg0KT24gMyBOb3ZlbWJlciAyMDEzIDIyOjU1LCBKdXN0aW4gVWJlcnRpIDxq dWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KPiBB Y2NvcmRpbmcgdG8gc2VjdGlvbiA1LjIuNSwgaXQgc2VlbXMgdGhhdCB0aGlzIGlzIG9ubHkgdGhl IGNhc2VzIGZvciBvZmZlcnMNCj4gdHJpZ2dlcmVkIGJ5IG9mZmVybGVzcyByZUlOVklURXMuIEkg ZG9uJ3QgdGhpbmsgd2Ugd2FudCB0byBiZSByZS1hbGxvY2F0aW5nDQo+IGFuZCBuZWdvdGlhdGlu ZyBjb2RlY3MgZXZlcnkgdGltZSB3ZSB3YW50IHRvIG1ha2UgYSBjaGFuZ2UgdG8gdGhlIHNlc3Np b24NCj4gZGVzY3JpcHRpb25zIGluIHVzZS4NCldvdWxkIHRoZSBwYXJ0aWFsIG9mZmVyL2Fuc3dl ciB3b3JrIGFkZHJlc3MgYXQgbGVhc3QgcGFydCBvZiB0aGlzPw0KbS1saW5lcyB0aGF0IHlvdSBk b24ndCB3YW50IHRvIGNoYW5nZSB3b3VsZG4ndCBuZWVkIHRvIGJlIGFkdmVydGlzZWQNCmF0IGFs bCwgcmF0aGVyIHRoYW4gYmVpbmcgYWR2ZXJ0aXNlZCB3aXRoIGEgcmVzdHJpY3RlZCBjb2RlYyBz ZXQuDQoNCk1pY2hhZWwNCg0KDQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF17C337D0MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6MTg0MTk2NTgzMDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6OTk3MDk1NjU4IDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4 NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow Y207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHZvdGUgZm9yIG9w dGlvbiAyIOKAkyBBcHBsaWNhdGlvbiBjb250cm9scyByZW5lZ290aWF0aW9uIHRocm91Z2ggY29u c3RyYWludC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk9wdGlvbiAxIHdvdWxkIGJlIGJhZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9wdGlv biAzIHdvdWxkIGJlIHZlcnkgYmFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9i PiAwNiBOb3ZlbWJlciAyMDEzIDEzOjM3PGJyPg0KPGI+VG86PC9iPiBNaWNoYWVsIFByb2N0ZXI8 YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3J0Y3dlYl0gZHJhZnQtaWV0Zi1ydGN3ZWItanNlcC0wNSAtIFN1YnNlcXVlbnQgT2ZmZXJzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyb20g dGhlIHJvb20gZGlzY3Vzc2lvbiwgSSBzZW5zZWQgMyBwb3NzaWJsZSBvcHRpb25zIHRvIG1vdmUg Zm9yd2FyZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xKSBN VVNUIE5PVCByZW5lZ290aWF0ZSBjb2RlY3MgZXRjLiAobmV3IFBlZXJDb25uZWN0aW9uIGlmIHlv dSB3YW50IHRvIHJlbmVnb3RpYXRlKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+MikgTVVTVCBOT1QgcmVuZWdvdGlhdGUgY29kZWNzIGV0Yy4gYnkg ZGVmYXVsdCwgYnV0IE1VU1Qgc3VwcG9ydCBvcHRpb24gdG8gcmVuZWdvdGlhdGUgKGFwcGxpY2F0 aW9uIGNvbnRyb2xzIHJlbmVnb3RpYXRpb24gdGhyb3VnaCBjb25zdHJhaW50KTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MykgU0hPVUxEIE5PVCBy ZW5lZ290aWF0ZSBjb2RlY3MgZXRjLCBidXQgaW1wbGVtZW50YXRpb24gTUFZIGRvIHNvIGlmIGRl c2lyZWQgKG5vIGFwcGxpY2F0aW9uIGxvZ2ljIG5lZWRlZCwgYnV0IG5vbi1kZXRlcm1pbmlzdGlj IEFQSSBiZWhhdmlvcik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+JnF1b3Q7ZXRjJnF1b3Q7IGhlcmUgd291bGQgbm90IGluY2x1ZGUgYW55dGhp bmcgdGhhdCB3b3VsZCByZXN1bHQgaW4gdGhlIG9mZmVyIGNoYW5naW5nIGZyb20gdGhlIHByZXZp b3VzbHkgYWdyZWVkLXVwb24gbG9jYWwgZGVzY3JpcHRpb24sIGluY2x1ZGluZyBjb2RlY3MsIFJU UCBoZWFkZXIgZXh0ZW5zaW9ucywgUlRDUCBmZWVkYmFjayBtZWNoYW5pc21zLCBCVU5ETEUgZ3Jv dXBpbmdzLCBvciB1c2Ugb2YgRkVDL1JUWC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBwcm9wb3NlZCAjMSBpbiB0aGUgcm9vbSwgYnV0IHNl ZSAjMiBhcyBhIHJlYXNvbmFibGUgc29sdXRpb24uIFRoYXQgcHJvdmlkZXMgdGhlIGFwcGxpY2F0 aW9uIHdpdGggZnVsbCBjb250cm9sIG92ZXIgd2hhdCBpdCB3YW50cywgYXMgd2VsbCBhcyBkZXRl cm1pbmlzdGljIGJlaGF2aW9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTm92 IDYsIDIwMTMgYXQgMToyOSBQTSwgSnVzdGluIFViZXJ0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1 YmVydGlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlll cywgaXQgd291bGQuIEJ1dCBJIHRoaW5rIHRoZSBwcm9ibGVtIHN0aWxsIGV4aXN0cyBmb3IgYXBw bGljYXRpb25zIHRoYXQgZG9uJ3QgdXNlIHBhcnRpYWwgb2ZmZXIvYW5zd2Vycy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE5vdiA2LCAyMDEzIGF0IDEyOjQ3IFBNLCBN aWNoYWVsIFByb2N0ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzptaWNoYWVsQHZvaXAuY28udWsiIHRh cmdldD0iX2JsYW5rIj5taWNoYWVsQHZvaXAuY28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPk9uIDMgTm92ZW1iZXIgMjAxMyAyMjo1NSwgSnVzdGluIFViZXJ0aSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmp1YmVydGlAZ29v Z2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgQWNjb3JkaW5nIHRvIHNlY3Rpb24gNS4y LjUsIGl0IHNlZW1zIHRoYXQgdGhpcyBpcyBvbmx5IHRoZSBjYXNlcyBmb3Igb2ZmZXJzPGJyPg0K Jmd0OyB0cmlnZ2VyZWQgYnkgb2ZmZXJsZXNzIHJlSU5WSVRFcy4gSSBkb24ndCB0aGluayB3ZSB3 YW50IHRvIGJlIHJlLWFsbG9jYXRpbmc8YnI+DQomZ3Q7IGFuZCBuZWdvdGlhdGluZyBjb2RlY3Mg ZXZlcnkgdGltZSB3ZSB3YW50IHRvIG1ha2UgYSBjaGFuZ2UgdG8gdGhlIHNlc3Npb248YnI+DQom Z3Q7IGRlc2NyaXB0aW9ucyBpbiB1c2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldvdWxkIHRoZSBwYXJ0aWFsIG9mZmVyL2Fuc3dlciB3b3JrIGFkZHJlc3Mg YXQgbGVhc3QgcGFydCBvZiB0aGlzPzxicj4NCm0tbGluZXMgdGhhdCB5b3UgZG9uJ3Qgd2FudCB0 byBjaGFuZ2Ugd291bGRuJ3QgbmVlZCB0byBiZSBhZHZlcnRpc2VkPGJyPg0KYXQgYWxsLCByYXRo ZXIgdGhhbiBiZWluZyBhZHZlcnRpc2VkIHdpdGggYSByZXN0cmljdGVkIGNvZGVjIHNldC48YnI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KTWljaGFlbDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_9F33F40F6F2CD847824537F3C4E37DDF17C337D0MCHP04MSXglobal_-- From martin.thomson@gmail.com Wed Nov 6 14:06:42 2013 Return-Path: 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 50ECA21E809E for ; Wed, 6 Nov 2013 14:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, 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 kcPSxjy-e-Rf for ; Wed, 6 Nov 2013 14:06:40 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id D244F21E80FC for ; Wed, 6 Nov 2013 14:06:20 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id n12so133201wgh.17 for ; Wed, 06 Nov 2013 14:06:19 -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:content-transfer-encoding; bh=gjmetUmA/kMHOY9VfMdPN0aGfqTcykBylzgn+PUWSw8=; b=UyiflyjH2YFJfgo2RlA3Bjuk5kj94HXJEKbTLySsLl9yOPNKJwimgKazeybx5b9RCy ItZ887U99p7CrXClV6Y/mk3KSh2FAQMKmlVF60b1PeVYTbJqX5EnuL8aW/V5CDekQ1yE C+CQIXDF4sBwzGDatJZe2+mME2BV3dQuNphjrgYgceEIsSFIUe/ZYw7LIaDMyU6eogXX nl/SMhj1yVo2OfDKCRgxplUXF6AsFNN7kGnhpt1I7JOsAA8LAAg0fE7r3EaUUpwTRBfu vNXnPEg5J7J3k3b9i7D7L1QKNpNrgu+1Q2NdkmJfdQZMs7Pj9fnnjbqD8LUa7siJfHRc FJGw== MIME-Version: 1.0 X-Received: by 10.194.250.6 with SMTP id yy6mr4478875wjc.13.1383775579480; Wed, 06 Nov 2013 14:06:19 -0800 (PST) Received: by 10.227.202.194 with HTTP; Wed, 6 Nov 2013 14:06:19 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net> References: <527420FC.3070805@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net> Date: Wed, 6 Nov 2013 14:06:19 -0800 Message-ID: From: Martin Thomson To: "Hutton, Andrew" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 22:06:42 -0000 The question in the room was: Given a negotiated session with "A, B, and C", is an endpoint permitted to create an offer that includes "D"? A great many people said yes, because that is how SDP is most commonly used= . I agree that not offering A, B or C would be bad. On 6 November 2013 14:01, Hutton, Andrew wrote: > I vote for option 2 =E2=80=93 Application controls renegotiation through = constraint. > > > > Option 1 would be bad. > > > > Option 3 would be very bad. > > > > Andy > > > > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of > Justin Uberti > Sent: 06 November 2013 13:37 > To: Michael Procter > > > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers > > > > From the room discussion, I sensed 3 possible options to move forward. > > 1) MUST NOT renegotiate codecs etc. (new PeerConnection if you want to > renegotiate) > > 2) MUST NOT renegotiate codecs etc. by default, but MUST support option t= o > renegotiate (application controls renegotiation through constraint) > > 3) SHOULD NOT renegotiate codecs etc, but implementation MAY do so if > desired (no application logic needed, but non-deterministic API behavior) > > > > "etc" here would not include anything that would result in the offer > changing from the previously agreed-upon local description, including > codecs, RTP header extensions, RTCP feedback mechanisms, BUNDLE groupings= , > or use of FEC/RTX. > > > > I proposed #1 in the room, but see #2 as a reasonable solution. That > provides the application with full control over what it wants, as well as > deterministic behavior. > > > > On Wed, Nov 6, 2013 at 1:29 PM, Justin Uberti wrote: > > Yes, it would. But I think the problem still exists for applications that > don't use partial offer/answers. > > > > On Wed, Nov 6, 2013 at 12:47 PM, Michael Procter wro= te: > > On 3 November 2013 22:55, Justin Uberti wrote: >> According to section 5.2.5, it seems that this is only the cases for >> offers >> triggered by offerless reINVITEs. I don't think we want to be >> re-allocating >> and negotiating codecs every time we want to make a change to the sessio= n >> descriptions in use. > > Would the partial offer/answer work address at least part of this? > m-lines that you don't want to change wouldn't need to be advertised > at all, rather than being advertised with a restricted codec set. > > Michael > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From andrew.hutton@unify.com Wed Nov 6 14:14:12 2013 Return-Path: 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 1224E21E8095 for ; Wed, 6 Nov 2013 14:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] 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 jHPby8MK5GH0 for ; Wed, 6 Nov 2013 14:14:07 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id DBEF621E8156 for ; Wed, 6 Nov 2013 14:14:06 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 4F3A01EB858C; Wed, 6 Nov 2013 23:14:06 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 23:14:05 +0100 From: "Hutton, Andrew" To: Martin Thomson Thread-Topic: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers Thread-Index: AQHO2zhhRkimDg8HS1yf9W6X1FrNbJoYwKAg///xAoCAABHpQA== Date: Wed, 6 Nov 2013 22:14:05 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C33847@MCHP04MSX.global-ad.net> References: <527420FC.3070805@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 22:14:12 -0000 T246IDA2IE5vdmVtYmVyIDIwMTMgMTQ6MDYgTWFydGluIFRob21zb24gV3JvdGU6DQo+IFRoZSBx dWVzdGlvbiBpbiB0aGUgcm9vbSB3YXM6DQo+IA0KPiBHaXZlbiBhIG5lZ290aWF0ZWQgc2Vzc2lv biB3aXRoICJBLCBCLCBhbmQgQyIsIGlzIGFuIGVuZHBvaW50DQo+IHBlcm1pdHRlZCB0byBjcmVh dGUgYW4gb2ZmZXIgdGhhdCBpbmNsdWRlcyAiRCI/DQo+IA0KPiBBIGdyZWF0IG1hbnkgcGVvcGxl IHNhaWQgeWVzLCBiZWNhdXNlIHRoYXQgaXMgaG93IFNEUCBpcyBtb3N0IGNvbW1vbmx5DQo+IHVz ZWQuDQo+IA0KDQpZZXMgdGhhdCB3YXMgbXkgdW5kZXJzdGFuZGluZyBhcyB3ZWxsIGFuZCB3aGF0 IEkgdGhvdWdodCB3YXMgbWVhbnQgYmUgcmVuZWdvdGlhdGluZyBjb2RlY3MuIFRoZXJlIG11c3Qg YmUgYSB3YXkgZm9yIHRoZSBuZXcgb2ZmZXIgdG8gY29udGFpbiB0aGUgZnVsbCBzZXQgb2YgY2Fw YWJpbGl0aWVzIHdoaWNoIG1pZ2h0IGJlIGdyZWF0ZXIgdGhhbiB0aG9zZSBwcmV2aW91c2x5IG5l Z290aWF0ZWQuDQoNCkFuZHkNCg== From matthew.kaufman@skype.net Wed Nov 6 14:42:08 2013 Return-Path: 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 A0AA621E811F for ; Wed, 6 Nov 2013 14:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Cgg-Rglc+lbl for ; Wed, 6 Nov 2013 14:42:02 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 23CE421E808A for ; Wed, 6 Nov 2013 14:41:49 -0800 (PST) Received: from DM2PR03CA007.namprd03.prod.outlook.com (10.141.52.155) by BY2PR03MB125.namprd03.prod.outlook.com (10.242.36.14) with Microsoft SMTP Server (TLS) id 15.0.800.7; Wed, 6 Nov 2013 22:41:41 +0000 Received: from BL2FFO11FD020.protection.gbl (2a01:111:f400:7c09::106) by DM2PR03CA007.outlook.office365.com (2a01:111:e400:2414::27) with Microsoft SMTP Server (TLS) id 15.0.815.6 via Frontend Transport; Wed, 6 Nov 2013 22:41:41 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD020.mail.protection.outlook.com (10.173.161.38) with Microsoft SMTP Server (TLS) id 15.0.815.5 via Frontend Transport; Wed, 6 Nov 2013 22:41:40 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.187]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0158.002; Wed, 6 Nov 2013 22:40:58 +0000 From: "Matthew Kaufman (SKYPE)" To: Toshio Kuratomi Thread-Topic: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec Thread-Index: AQHO2zj0ovc5QyFwQUmSw9s5Psl/OpoYy/cQ Date: Wed, 6 Nov 2013 22:40:57 +0000 Message-ID: References: <20131106211149.GA1763@unaka.lan> <20131106214121.GB1763@unaka.lan> In-Reply-To: <20131106214121.GB1763@unaka.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454003)(24454002)(189002)(199002)(164054003)(51704005)(13464003)(65816001)(81686001)(76482001)(55846006)(83072001)(85306002)(51856001)(80022001)(2656002)(76796001)(44976005)(87266001)(69226001)(83322001)(19580405001)(33656001)(66066001)(76786001)(46102001)(56816003)(77096001)(19580395003)(56776001)(81816001)(81542001)(31966008)(74502001)(80976001)(74662001)(74706001)(59766001)(77982001)(74366001)(47736001)(49866001)(50466002)(4396001)(53806001)(79102001)(63696002)(47446002)(47776003)(47976001)(20776003)(6806004)(54316002)(54356001)(74876001)(46406003)(50986001)(81342001)(23726002)(87936001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB125; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0022134A87 X-OriginatorOrg: skype.net Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 22:42:08 -0000 X-List-Received-Date: Wed, 06 Nov 2013 22:42:08 -0000 An interesting definition, to be sure. Thanks, Matthew Kaufman > -----Original Message----- > From: Toshio Kuratomi [mailto:a.badger@gmail.com] > Sent: Wednesday, November 6, 2013 1:41 PM > To: Matthew Kaufman (SKYPE) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a > MTI codec >=20 > On Wed, Nov 06, 2013 at 09:23:03PM +0000, Matthew Kaufman (SKYPE) > wrote: > > Which "non-patent-enumbered" codec did you have in mind? > > >=20 > Fedora currently ships VP8 and would consider it acceptable. >=20 > -Toshio From dburnett@voxeo.com Wed Nov 6 14:43:43 2013 Return-Path: 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 4474F21E8095 for ; Wed, 6 Nov 2013 14:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 5J15NG3JX-pn for ; Wed, 6 Nov 2013 14:43:35 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8614221E808A for ; Wed, 6 Nov 2013 14:43:18 -0800 (PST) Received: from [31.133.145.163] (account dburnett@voxeo.com [31.133.145.163] verified) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 138904145; Wed, 06 Nov 2013 22:43:07 +0000 References: <527AA11B.8090408@ericsson.com> <527AABB3.1040203@alvestrand.no> <527AB408.7040503@ericsson.com> In-Reply-To: <527AB408.7040503@ericsson.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> X-Mailer: iPhone Mail (9B176) From: Dan Burnett Date: Wed, 6 Nov 2013 14:43:05 -0800 To: Magnus Westerlund Cc: "" Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 22:43:43 -0000 This is a great idea, but can we do it during the ops plenary rather than du= ring STIR? (sending to the list so other interested parties can chime in on t= iming). -- dan On Nov 6, 2013, at 1:26 PM, Magnus Westerlund wrote: >=20 >=20 > On 2013-11-06 12:50, Harald Alvestrand wrote: >> On 11/06/2013 09:05 PM, Magnus Westerlund wrote: >>> WG, >>>=20 >>> I invite anyone interested to participate Today (Wednesday) at 15.50 in >>> an adhoc discussion around the RTP to Media Stream API mapping. >> Which parts of which documents do you want to focus discussion on? >>=20 >> The subject line isn't clear enough that I'm sure what you want to talk >> about. >=20 > This is the followup on the open issue in the RTP usage draft. How does > the RTP level entities such as SSRCs and CNAME relate to the W3C > MediaStream API. >=20 > /Magnus >=20 >>=20 >>>=20 >>> Lets meet at 15.50 at the level 2 bar. If we are to many to fit we will >>> have to find some other spot. I appreciate a heads up through a private >>> email that you intended to participate. >>>=20 >>> Cheers >>>=20 >>> Magnus Westerlund >>>=20 >>> ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From basilgohar@librevideo.org Wed Nov 6 14:48:05 2013 Return-Path: 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 D332021E818E for ; Wed, 6 Nov 2013 14:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 FJtFSdCljJZn for ; Wed, 6 Nov 2013 14:47:56 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id ACAA821E8170 for ; Wed, 6 Nov 2013 14:47:52 -0800 (PST) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id F283E65A461; Wed, 6 Nov 2013 17:47:50 -0500 (EST) Message-ID: <527AC713.2020606@librevideo.org> Date: Wed, 06 Nov 2013 17:47:47 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Matthew Kaufman (SKYPE)" References: <20131106211149.GA1763@unaka.lan> <20131106214121.GB1763@unaka.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 22:48:05 -0000 On 11/06/2013 05:40 PM, Matthew Kaufman (SKYPE) wrote: > An interesting definition, to be sure. > > Thanks, > > Matthew Kaufman VP8 is not encumbered by patents because that patents that are known about are granted by Google and via Google's deal with MPEG-LA. Nokia's threats have failed in Germany, so there remains no known encumbrance against VP8. The encumbrance of patents is due to their usage to restrict free-and-open-usage of technology, which the patents on VP8 do not. The same cannot be said to any degree for H.264. -- Libre Video http://librevideo.org From suhasietf@gmail.com Wed Nov 6 14:53:53 2013 Return-Path: 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 0F5A421E80FD for ; Wed, 6 Nov 2013 14:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 e-5XtWENfZjS for ; Wed, 6 Nov 2013 14:53:52 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7B621E812A for ; Wed, 6 Nov 2013 14:53:50 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id t61so178995wes.27 for ; Wed, 06 Nov 2013 14:53:46 -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=EtYPHXc+MIzeXTyR8w2PbKtQaKm9vQRoV7p7oMoTePQ=; b=oUKr4gXZWztUbQh/tgiSY/hQR20eKm9SiJmWapXjObhYQDrqs0bKNgV+3YpvushDMw Gp+juYLBEcukFnwMBSG9t/KbFAVvORMPgMksgia8uKyoyBWi9+xHqyJsQzLEFpm4GOZu iYRh99rZKksvpDgR/JLfkMOHBBn0sLiyVu5DoLLPSeeKBScalXlLQwwSr05weQDp4iYt nLrhbvM9UeBLvPRv9hUujTDemVvQfZi/FS0Id4pdsPQWXILlGwaSySb76UNONxjAmep5 kpodV+XjKqHSIoopg4VenAuc1PslKeeQW5jdKeocn31GIB8FpKKDG/M7YvG8UEvNrdLs PQZw== MIME-Version: 1.0 X-Received: by 10.180.90.14 with SMTP id bs14mr40700wib.10.1383778424995; Wed, 06 Nov 2013 14:53:44 -0800 (PST) Received: by 10.194.178.231 with HTTP; Wed, 6 Nov 2013 14:53:44 -0800 (PST) In-Reply-To: <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> References: <527AA11B.8090408@ericsson.com> <527AABB3.1040203@alvestrand.no> <527AB408.7040503@ericsson.com> <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> Date: Wed, 6 Nov 2013 14:53:44 -0800 Message-ID: From: Suhas Nandakumar To: Dan Burnett Content-Type: multipart/alternative; boundary=f46d043c7e0e78482604ea8a053b Cc: "" Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 22:53:53 -0000 --f46d043c7e0e78482604ea8a053b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Works for me On Wednesday, November 6, 2013, Dan Burnett wrote: > This is a great idea, but can we do it during the ops plenary rather than > during STIR? (sending to the list so other interested parties can chime i= n > on timing). > > > -- dan > > On Nov 6, 2013, at 1:26 PM, Magnus Westerlund < > magnus.westerlund@ericsson.com > wrote: > > > > > > > On 2013-11-06 12:50, Harald Alvestrand wrote: > >> On 11/06/2013 09:05 PM, Magnus Westerlund wrote: > >>> WG, > >>> > >>> I invite anyone interested to participate Today (Wednesday) at 15.50 = in > >>> an adhoc discussion around the RTP to Media Stream API mapping. > >> Which parts of which documents do you want to focus discussion on? > >> > >> The subject line isn't clear enough that I'm sure what you want to tal= k > >> about. > > > > This is the followup on the open issue in the RTP usage draft. How does > > the RTP level entities such as SSRCs and CNAME relate to the W3C > > MediaStream API. > > > > /Magnus > > > >> > >>> > >>> Lets meet at 15.50 at the level 2 bar. If we are to many to fit we wi= ll > >>> have to find some other spot. I appreciate a heads up through a priva= te > >>> email that you intended to participate. > >>> > >>> Cheers > >>> > >>> Magnus Westerlund > >>> > >>> ---------------------------------------------------------------------= - > >>> Multimedia Technologies, Ericsson Research EAB/TVM > >>> ---------------------------------------------------------------------= - > >>> Ericsson AB | Phone +46 10 7148287 > >>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >>> ---------------------------------------------------------------------= - > >>> > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >> > >> > > > > > > -- > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > 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 > --f46d043c7e0e78482604ea8a053b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Works for me

On Wednesday, November 6, 2013, Dan Burnet= t wrote:
This is a great idea, but can w= e do it during the ops plenary rather than during STIR? (sending to the lis= t so other interested parties can chime in on timing).


-- dan

On Nov 6, 2013, at 1:26 PM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

>
>
> On 2013-11-06 12:50, Harald Alvestrand wrote:
>> On 11/06/2013 09:05 PM, Magnus Westerlund wrote:
>>> WG,
>>>
>>> I invite anyone interested to participate Today (Wednesday) at= 15.50 in
>>> an adhoc discussion around the RTP to Media Stream API mapping= .
>> Which parts of which documents do you want to focus discussion on?=
>>
>> The subject line isn't clear enough that I'm sure what you= want to talk
>> about.
>
> This is the followup on the open issue in the RTP usage draft. How doe= s
> the RTP level entities such as SSRCs and CNAME relate to the W3C
> MediaStream API.
>
> /Magnus
>
>>
>>>
>>> Lets meet at 15.50 at the level 2 bar. If we are to many to fi= t we will
>>> have to find some other spot. I appreciate a heads up through = a private
>>> email that you intended to participate.
>>>
>>> Cheers
>>>
>>> Magnus Westerlund
>>>
>>> --------------------------------------------------------------= --------
>>> Multimedia Technologies, Ericsson Research EAB/TVM
>>> --------------------------------------------------------------= --------
>>> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7= 148287
>>> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73= 0949079
>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>>> --------------------------------------------------------------= --------
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------=
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------=
> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079=
> SE-164 80 Stockholm, Sweden| mailto: ma= gnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=
>
> _______________________________________________
> 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
--f46d043c7e0e78482604ea8a053b-- From martin.thomson@gmail.com Wed Nov 6 15:00:56 2013 Return-Path: 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 0993411E8162 for ; Wed, 6 Nov 2013 15:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 H5Ug+ydk9xrV for ; Wed, 6 Nov 2013 15:00:55 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 59E9E11E8193 for ; Wed, 6 Nov 2013 15:00:34 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so182451wgg.4 for ; Wed, 06 Nov 2013 15:00:08 -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=MZarFke8FH7YFDRRBcPiU6E9QVNxZFAYxvtfzuPwtog=; b=U+l6howzTOVvc8LkPhEzjQL9vb4IfV/yzgvZuXkoeC6xEPKGdZSEfrgk7NhJDwC2nT lOQ/dfTovAb4p2IeKI5uBBdpRf+orPJs4PdBG7gkU4f0LNnZKdq2c6P1kHuME22NX7G1 rk46pDIS+fDlOgrdhIqN051HTa1HkzD9j1Q6YhibNscgB4kcZHVS81YYpANL1+1zytmb zIC7KTGiGHItfCJDt7JULKUPya9l+sBw1mGHWggZTYHA7XgW12fz8sOhYrbRgxj0chBh Ba2+koGKYjN0OXO50xT0OgNGGBybuSxOiEehMgt8whwEyXoNR41eDEl8bhEsOVBhymd5 ktMQ== MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr2622wic.64.1383778808732; Wed, 06 Nov 2013 15:00:08 -0800 (PST) Received: by 10.227.202.194 with HTTP; Wed, 6 Nov 2013 15:00:08 -0800 (PST) In-Reply-To: <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> References: <527AA11B.8090408@ericsson.com> <527AABB3.1040203@alvestrand.no> <527AB408.7040503@ericsson.com> <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> Date: Wed, 6 Nov 2013 15:00:08 -0800 Message-ID: From: Martin Thomson To: Dan Burnett Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 23:00:56 -0000 On 6 November 2013 14:43, Dan Burnett wrote: > This is a great idea, but can we do it during the ops plenary rather than during STIR? (sending to the list so other interested parties can chime in on timing). I think that you reduce utility by competing with STIR. I don't have strong feelings about the ops plenary, but understand if others do. At risk of reducing the entertainment planned for tomorrow, is there any chance that we might recover some time from the codec bickering to do some productive work? From ted.ietf@gmail.com Wed Nov 6 15:07:13 2013 Return-Path: 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 CD51911E8132 for ; Wed, 6 Nov 2013 15:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 rJSFOAkitjlf for ; Wed, 6 Nov 2013 15:07:12 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 118AC11E8103 for ; Wed, 6 Nov 2013 15:07:11 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id q58so191542wes.3 for ; Wed, 06 Nov 2013 15:07:11 -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=1RxEpYHh/XYUYgFQidB/w6nBwC1zpQ0WMt8lO5aVFqw=; b=HmUqf/orxha3g4fC0YhyCMRisfvEvlM/09ilr2iVv0iwfPpwITrPlUTSMWJfeZIAYg 39cTTY5R1L4e1EdC8lW3+OjlIYcdwwq3E44jIA1vLxunkMo1dXCJfJvH574RAs219N6B YG0pBZVAfaCL3PgsfEDw72aPVeJ6hjBWfrT1ipr17vz54SVEA6+G8gCcLRCHyWs0KKAf frcZJRIctPgb8ZOQ0mIrs4sJxqTeoeEVokbBJ9jRQ4Q9zzGvo6F7X9FMJtejAXkVaQWb ld4b5EoPdU35+24omJDfn5gZ7ocHSXAQ+hUeYJQEKOTIyLwAR4aefcS0qC5lq1G1Zq3E eBTQ== MIME-Version: 1.0 X-Received: by 10.194.185.73 with SMTP id fa9mr4597288wjc.29.1383779231065; Wed, 06 Nov 2013 15:07:11 -0800 (PST) Received: by 10.227.27.73 with HTTP; Wed, 6 Nov 2013 15:07:11 -0800 (PST) In-Reply-To: References: <527AA11B.8090408@ericsson.com> <527AABB3.1040203@alvestrand.no> <527AB408.7040503@ericsson.com> <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> Date: Wed, 6 Nov 2013 15:07:11 -0800 Message-ID: From: Ted Hardie To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bd6b04883ee5f04ea8a35f0 Cc: "" Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 23:07:13 -0000 --047d7bd6b04883ee5f04ea8a35f0 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 6, 2013 at 3:00 PM, Martin ThomsonI think that you reduce utility by competing with STIR. I don't have > s > At risk of reducing the entertainment planned for tomorrow, is there > any chance that we might recover some time from the codec bickering to > do some productive work? > We already have rtp-transports as the overflow topic if the codec discussion moves quickly. regards, Ted Hardie --047d7bd6b04883ee5f04ea8a35f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 6, 2013 at 3:00 PM, Martin ThomsonI think that you reduce utility by competing with STIR. =A0I d= on't have
s
At risk of reducing the entertainment planned for tomorrow, is there
any chance that we might recover some time from the codec bickering to
do some productive work?


We already= have rtp-transports as the overflow topic if the codec discussion moves qu= ickly.

regards,

Ted Hardie
--047d7bd6b04883ee5f04ea8a35f0-- From martin.thomson@gmail.com Wed Nov 6 15:09:13 2013 Return-Path: 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 C3AD011E8156 for ; Wed, 6 Nov 2013 15:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, 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 UFhPCsKRaxqa for ; Wed, 6 Nov 2013 15:09:12 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE8211E8132 for ; Wed, 6 Nov 2013 15:09:10 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so4580838wid.17 for ; Wed, 06 Nov 2013 15:08:59 -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=W+ojUQx/QHatADa27zrP1P3rsm0Sfq6KSDysvq+TQGM=; b=b6qQHQQusK3/wRBg7lbm7qBcn77D43gZ9qPDauDY/OHFYgY4RUBnV6Pg40uGC6YMTj MSNfjk4sWliTXAlXtQRJBWjJnmu6g+KHNY6brir6BTz3ARFgyahJgahmT6nU7GyBlRmO HWtA2dHG+KPcieTKHLrc7h4QIuEp+nQyd2p8wtVc0XZ0KosU6YpT1ETGAKCaCFPzxNrz FGzuShPArxHSKu3bY4z1pNH7cAy+PG7LRdEzoFJdJpI0bOvg9XU2RIIRJSrEeeDnrjtQ q9flO99zF4gXk4d2/ztz8+4sMRJ/5ZVsEyYGjY2LI4vBC6i31mXJXy9bMKVnxAuu4DF/ 8npg== MIME-Version: 1.0 X-Received: by 10.195.13.164 with SMTP id ez4mr4655906wjd.11.1383779339080; Wed, 06 Nov 2013 15:08:59 -0800 (PST) Received: by 10.227.202.194 with HTTP; Wed, 6 Nov 2013 15:08:59 -0800 (PST) In-Reply-To: References: <527AA11B.8090408@ericsson.com> <527AABB3.1040203@alvestrand.no> <527AB408.7040503@ericsson.com> <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> Date: Wed, 6 Nov 2013 15:08:59 -0800 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 23:09:13 -0000 On 6 November 2013 15:07, Ted Hardie wrote: > We already have rtp-transports as the overflow topic if the codec discussion > moves quickly. Fair point, though I don't see any materials. Is there an issue with the draft that needs resolution? From xiphmont@gmail.com Wed Nov 6 15:13:58 2013 Return-Path: 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 99C3911E8132 for ; Wed, 6 Nov 2013 15:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, 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 jxX5ybv4Ri5Z for ; Wed, 6 Nov 2013 15:13:58 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id A2EA811E8123 for ; Wed, 6 Nov 2013 15:13:57 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id w6so293614lbh.24 for ; Wed, 06 Nov 2013 15:13:56 -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=KD0ePyx508+jLXKE8dvE7cVLc/oaWqohoMC4Huz/mJw=; b=Dj0DeHnvyBIgfIXL3ptcOCRpf7e1FjQ3j8XYddLQf7IenhEj+hmuL41S3RrvKcJqFJ gmW7uywyNMuV5Mj/Xj6ruCGBBhfO3bF+6KZpCvoZDQjBLn45aYCtl03Y/ZKb6cbKW8y3 Vr7F3jRiq3GDDp8S4nhjZevU9wkb8glxvCUfMR1ASiYRmX26khXM4vuBCpVIz4AePRXB ieuOeB+FE73LH1KnCt40QQfr1PHs2pmt7tDZdWJjCjKb3dXZgDpwcD7fdDE4qFQwP1Kr K7ZdCE5lr5PlW1EBnmjz81Bq/a5ipm/ejAO5z6/SFe9ayZai8OLPcrbZZq2j1GUgJ9x4 h05Q== MIME-Version: 1.0 X-Received: by 10.152.184.198 with SMTP id ew6mr4070352lac.34.1383779636571; Wed, 06 Nov 2013 15:13:56 -0800 (PST) Received: by 10.112.104.229 with HTTP; Wed, 6 Nov 2013 15:13:56 -0800 (PST) In-Reply-To: <527AC713.2020606@librevideo.org> References: <20131106211149.GA1763@unaka.lan> <20131106214121.GB1763@unaka.lan> <527AC713.2020606@librevideo.org> Date: Wed, 6 Nov 2013 18:13:56 -0500 Message-ID: From: Monty Montgomery To: Basil Mohamed Gohar Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 23:13:58 -0000 Yes. Even the ultra-FOSS codecs (such as Opus) now carry explicit patents along with a license that grants unlimited and unrestricted RF use of those patents. The license also carries an auto-revocation should one party sue another over Opus patents, however we assert 'thou shalt not be a litigious dick' is not a use restriction on the codec. Monty On Wed, Nov 6, 2013 at 5:47 PM, Basil Mohamed Gohar wrote: > On 11/06/2013 05:40 PM, Matthew Kaufman (SKYPE) wrote: >> An interesting definition, to be sure. >> >> Thanks, >> >> Matthew Kaufman > > VP8 is not encumbered by patents because that patents that are known > about are granted by Google and via Google's deal with MPEG-LA. Nokia's > threats have failed in Germany, so there remains no known encumbrance > against VP8. > > The encumbrance of patents is due to their usage to restrict > free-and-open-usage of technology, which the patents on VP8 do not. The > same cannot be said to any degree for H.264. > > -- > Libre Video > http://librevideo.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Wed Nov 6 15:22:08 2013 Return-Path: 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 2F2B621E8170 for ; Wed, 6 Nov 2013 15:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.725 X-Spam-Level: X-Spam-Status: No, score=-103.725 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 7CrM65pP7x7h for ; Wed, 6 Nov 2013 15:21:54 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id B0F3B21E817C for ; Wed, 6 Nov 2013 15:21:36 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-bf-527aceff0461 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id CD.F7.27941.FFECA725; Thu, 7 Nov 2013 00:21:35 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Thu, 7 Nov 2013 00:21:34 +0100 Message-ID: <527ACF60.7080503@ericsson.com> Date: Wed, 6 Nov 2013 15:23:12 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Dan Burnett References: <527AA11B.8090408@ericsson.com> <527AABB3.1040203@alvestrand.no> <527AB408.7040503@ericsson.com> <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> In-Reply-To: <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvje7/c1VBBnuXmFo0f5zOZLH2Xzu7 A5PHkiU/mTwebV/NHMAUxWWTkpqTWZZapG+XwJWx6dofpoJeyYpfh94xNzBOFeli5OSQEDCR uNW0mgXCFpO4cG89WxcjF4eQwBFGicYFpxghnGWMElMObGUCqeIV0JZ40LaCFcRmEVCR2HB7 PZjNJmAhcfNHIxuILSoQLHH+1WJ2iHpBiZMznwBt4OAQAap/sYQDJMwsoCkxYdkusHJhAUuJ o1NOQi2eyyix5t8esASngK3EvYfP2EF6JQTEJXoag2B6W7f/Zoew5SWat85mBrGFgE5raOpg ncAoNAvJ5llIWmYhaVnAyLyKkaM4tTgpN93IYBMjMFgPbvltsYPx8l+bQ4zSHCxK4rwf3zoH CQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBsFjzXnRuo0iWX+/aWLFtLu8G2LZ8nSW+/IbU/ tfq+2xfh/oSjU/nWv1nFVf1dunPPvw/1l1i+2/5qstpyUOLT1hrFzGfCycrGHfvqLx5OtNwx tWXqxIehaUfXiim+yhUpcYlfcNZoTu2al1u5w1/HNf/nn9HMUFXI9GnJEaNZrqXTIhr7VK4p sRRnJBpqMRcVJwIA+u2M2SQCAAA= Cc: "" Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 23:22:08 -0000 On 2013-11-06 14:43, Dan Burnett wrote: > This is a great idea, but can we do it during the ops plenary rather > than during STIR? (sending to the list so other interested parties > can chime in on timing). Okay, I am willing to move this to 1740. If anyone has serious issue with moving it howl. Same meeting place. /Magnus > > > -- dan > > On Nov 6, 2013, at 1:26 PM, Magnus Westerlund > wrote: > >> >> >> On 2013-11-06 12:50, Harald Alvestrand wrote: >>> On 11/06/2013 09:05 PM, Magnus Westerlund wrote: >>>> WG, >>>> >>>> I invite anyone interested to participate Today (Wednesday) at >>>> 15.50 in an adhoc discussion around the RTP to Media Stream API >>>> mapping. >>> Which parts of which documents do you want to focus discussion >>> on? >>> >>> The subject line isn't clear enough that I'm sure what you want >>> to talk about. >> >> This is the followup on the open issue in the RTP usage draft. How >> does the RTP level entities such as SSRCs and CNAME relate to the >> W3C MediaStream API. >> >> /Magnus >> >>> >>>> >>>> Lets meet at 15.50 at the level 2 bar. If we are to many to fit >>>> we will have to find some other spot. I appreciate a heads up >>>> through a private email that you intended to participate. >>>> >>>> Cheers >>>> >>>> Magnus Westerlund >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Multimedia Technologies, Ericsson Research EAB/TVM >>>> ---------------------------------------------------------------------- >>>> >>>> Ericsson AB | Phone +46 10 7148287 >>>> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >>>> Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >> Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> >> _______________________________________________ >> rtcweb mailing list rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From csp@csperkins.org Wed Nov 6 15:29:10 2013 Return-Path: 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 8E57021E8117 for ; Wed, 6 Nov 2013 15:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 7vbMDZEWExCv for ; Wed, 6 Nov 2013 15:29:10 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E4D21E80BD for ; Wed, 6 Nov 2013 15:29:05 -0800 (PST) Received: from [31.133.152.95] (port=59686 helo=dhcp-985f.meeting.ietf.org) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VeCWz-0005Vc-Id; Wed, 06 Nov 2013 23:29:02 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: <527ACF60.7080503@ericsson.com> Date: Wed, 6 Nov 2013 15:28:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <898CBB1F-5964-4939-AF78-9DE3E724073D@csperkins.org> References: <527AA11B.8090408@ericsson.com> <527AABB3.1040203@alvestrand.no> <527AB408.7040503@ericsson.com> <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> <527ACF60.7080503@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "" Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 23:29:10 -0000 On 6 Nov 2013, at 15:23, Magnus Westerlund = wrote: > On 2013-11-06 14:43, Dan Burnett wrote: >> This is a great idea, but can we do it during the ops plenary rather >> than during STIR? (sending to the list so other interested parties >> can chime in on timing). >=20 > Okay, I am willing to move this to 1740. If anyone has serious issue > with moving it howl. Same meeting place. I'd prefer to avoid a conflict with the plenary (or, at least, with the = main body of the plenary...) --=20 Colin Perkins http://csperkins.org/ From adam@nostrum.com Wed Nov 6 15:32:41 2013 Return-Path: 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 C797F11E8193 for ; Wed, 6 Nov 2013 15:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 dR2-lgxTteu5 for ; Wed, 6 Nov 2013 15:32:41 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 430A011E8190 for ; Wed, 6 Nov 2013 15:32:41 -0800 (PST) Received: from dhcp-b74d.meeting.ietf.org (dhcp-b74d.meeting.ietf.org [31.133.183.77]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA6NWZe4030412 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 6 Nov 2013 17:32:36 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <527AD194.1030100@nostrum.com> Date: Wed, 06 Nov 2013 15:32:36 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Magnus Westerlund , Dan Burnett References: <527AA11B.8090408@ericsson.com> <527AABB3.1040203@alvestrand.no> <527AB408.7040503@ericsson.com> <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> <527ACF60.7080503@ericsson.com> In-Reply-To: <527ACF60.7080503@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 31.133.183.77 is authenticated by a trusted mechanism) Cc: "" Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 23:32:41 -0000 On 11/6/13 15:23, Magnus Westerlund wrote: > > On 2013-11-06 14:43, Dan Burnett wrote: >> This is a great idea, but can we do it during the ops plenary rather >> than during STIR? (sending to the list so other interested parties >> can chime in on timing). > Okay, I am willing to move this to 1740. If anyone has serious issue > with moving it howl. Same meeting place. > How long do you expect this to take? I have something else I need to do during the plenary, but might be able to speare 15 to 20 minutes. /a From adam@nostrum.com Wed Nov 6 15:34:12 2013 Return-Path: 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 17A8B11E8190 for ; Wed, 6 Nov 2013 15:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Mk2Bm2SJqNJ6 for ; Wed, 6 Nov 2013 15:34:11 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 934B811E8113 for ; Wed, 6 Nov 2013 15:34:11 -0800 (PST) Received: from dhcp-b74d.meeting.ietf.org (dhcp-b74d.meeting.ietf.org [31.133.183.77]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA6NXwMh030452 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 6 Nov 2013 17:33:59 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <527AD1E7.1070907@nostrum.com> Date: Wed, 06 Nov 2013 15:33:59 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Colin Perkins , Magnus Westerlund References: <527AA11B.8090408@ericsson.com> <527AABB3.1040203@alvestrand.no> <527AB408.7040503@ericsson.com> <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> <527ACF60.7080503@ericsson.com> <898CBB1F-5964-4939-AF78-9DE3E724073D@csperkins.org> In-Reply-To: <898CBB1F-5964-4939-AF78-9DE3E724073D@csperkins.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 31.133.183.77 is authenticated by a trusted mechanism) Cc: "" Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 23:34:12 -0000 On 11/6/13 15:28, Colin Perkins wrote: > On 6 Nov 2013, at 15:23, Magnus Westerlund wrote: >> On 2013-11-06 14:43, Dan Burnett wrote: >>> This is a great idea, but can we do it during the ops plenary rather >>> than during STIR? (sending to the list so other interested parties >>> can chime in on timing). >> Okay, I am willing to move this to 1740. If anyone has serious issue >> with moving it howl. Same meeting place. > > I'd prefer to avoid a conflict with the plenary (or, at least, with the main body of the plenary...) > Could we do 1720 - 1740? /a From Markus.Isomaki@nokia.com Wed Nov 6 15:40:27 2013 Return-Path: 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 3085F21E8103 for ; Wed, 6 Nov 2013 15:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 UBmam3ZSTlmI for ; Wed, 6 Nov 2013 15:40:02 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF4611E81B9 for ; Wed, 6 Nov 2013 15:39:58 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA6Nac0H007423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Nov 2013 01:36:38 +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 23:36:37 +0000 From: To: , Thread-Topic: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec Thread-Index: AQHO20JWIbT68+Y/DEuNarFmw8rj2ZoY1dlw Date: Wed, 6 Nov 2013 23:36:36 +0000 Message-ID: References: <20131106211149.GA1763@unaka.lan> <20131106214121.GB1763@unaka.lan> <527AC713.2020606@librevideo.org> In-Reply-To: <527AC713.2020606@librevideo.org> 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+/nZJb9Kg7Im3cqL96ccwBEtwWlSVV85u6FrWPHWGaUG1Qjbpnza0az3+w4eEAO1cVaGi2i7ri1DSllPyqgiosHdLsrPRC6yd9nHCBPfX2JcKxmcsOWWA7zuONHLxo5cVKkzbxoC/v/s/FHnyEgZO45XS7/gsgc2ZGKm6mk3q5BaXvqk2kslM1hlULySiniEhC8xIdovk5KHdsZMA5nObAOYQr1AycO4EV/aNw+I+0OKbWzHRdZ2LH2Vrhkn+Cc4Vqo5amb287wKszzg7P53ul7Ikg9Mo2u3s= x-originating-ip: [10.163.33.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec X-BeenThere: rtcweb@ietf.org 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: Wed, 06 Nov 2013 23:40:27 -0000 Hi, Basil Mohamed Gohar wrote: >=20 > VP8 is not encumbered by patents because that patents that are known > about are granted by Google and via Google's deal with MPEG-LA. Nokia's > threats have failed in Germany, so there remains no known encumbrance > against VP8. >=20 This is not correct. The Nokia vs. HTC case where three V8 related patents = are included is still very much ongoing. For instance, one of the three cas= es has not even been started. There is some preliminary information about t= he first two e.g. in [1] and [2], but also appeals have been made, so the p= rocesses are far from complete. Note that there are also three other Nokia patents that were declared to th= e IETF which are not covered in the Nokia vs. HTC case.=20 The point is that it is definitely too early to make conclusions (either wa= y).=20 [1] http://www.fosspatents.com/2013/05/german-court-has-apparently-found.ht= ml [2] http://www.fosspatents.com/2013/08/dutch-appeals-court-sides-with-nokia= -in.html Markus=20 From wolfgang.beck01@googlemail.com Wed Nov 6 16:04:47 2013 Return-Path: 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 6A19E21E80D0 for ; Wed, 6 Nov 2013 16:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 calLJLoTWGfG for ; Wed, 6 Nov 2013 16:04:46 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BB03D21E80CE for ; Wed, 6 Nov 2013 16:04:46 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id lh4so167558vcb.4 for ; Wed, 06 Nov 2013 16:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SAkx/FoLZd40aHqm8wO3aO7xlxfXLhDY9678KJHS9wQ=; b=WVw36CEObz2+EsczWcD9PwZKgcfJvJMK+TbE7UJ6MRdz8LKE7K9jd8DEu/Z1DBnKvq 3nR8w8Roh2NlA6Z8fFgaTGp5BA6or+ua/7JLCMT85q2CxFESV83rF5i+E9a3AUU2aIY5 bKMlhXqoVllJugLN9zOYTqWmEWNsfcPf9wDguzhJmXBbY3flgqUkAPU2ntRSscaWjIFa 1VUjJHxzeUXAN3MrLuhP/AlU1OCWxWAe4S4uEh4e2WXL6yGPWf0efTex+Dm2Gaeu60aR tv/bO0ToPH0RCWEjAFRMQPqRcQnA63bEYxVMhzaxRnFX67zeCvNg6xoSQ54RlLaV2H7Q T0Dw== MIME-Version: 1.0 X-Received: by 10.220.10.70 with SMTP id o6mr534524vco.45.1383782685843; Wed, 06 Nov 2013 16:04:45 -0800 (PST) Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 16:04:45 -0800 (PST) Received: by 10.58.45.169 with HTTP; Wed, 6 Nov 2013 16:04:45 -0800 (PST) In-Reply-To: References: <52795BF0.1020207@makk.es> Date: Thu, 7 Nov 2013 01:04:45 +0100 Message-ID: From: Wolfgang Beck To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c3b8786fa5bc04ea8b032b Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 00:04:47 -0000 --001a11c3b8786fa5bc04ea8b032b Content-Type: text/plain; charset=ISO-8859-1 Probably not. It depends on the idp and browser settings. I'd rather fix the problem than limit the frequency of its ocurrence. Maybe it's as easy as having way for the webrtc server to determine what attributes the idp-proxy is going to request, so it could 'prefetch' it. Am 06.11.2013 11:14 schrieb "Martin Thomson" : > On 6 November 2013 05:45, Wolfgang Beck > wrote: > > Let's say the user authenticated with my webrtc service using google > openid. > > The webrtc server asked for the attribute 'display name'. The OpenID > server > > asks the user:'Can I tell webrtc server your display name y/n?'. Now the > > peerconnection object asks the openid server for authentication and the > > attribute 'email address', to get an rfc822 style name it can return to > the > > JS. This is a new permission the user has to grant. And I dont know which > > openid attribute the peerconnection obj is going to use. It can even > change > > dynamically when google changes the .well-known/idp document. > > > This is, overall, correct. However, do you think that you have to > login every time that you load or reload a webpage? > --001a11c3b8786fa5bc04ea8b032b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Probably not. It depends on the idp and browser settings. I&= #39;d rather fix the problem than limit the frequency of its ocurrence. May= be it's as easy as having way for=A0 the webrtc server to determine=A0 = what attributes the idp-proxy is going to request, so it could 'prefetc= h' it.

Am 06.11.2013 11:14 schrieb "Martin Thomson= " <martin.thomson@gmail= .com>:
On 6 November 2013 05:45, Wolfgang Beck <wolfgang.beck01@googlemail.com> wrote:
> Let's say the user authenticated with my webrtc service using goog= le openid.
> The webrtc server asked for the attribute 'display name'. The = OpenID server
> asks the user:'Can I tell webrtc server your display name y/n?'= ;. Now the
> peerconnection object asks the openid server for authentication and th= e
> attribute 'email address', to get an rfc822 style name it can = return to the
> JS. This is a new permission the user has to grant. And I dont know wh= ich
> openid attribute the peerconnection obj is going to use. It can even c= hange
> dynamically when google changes the .well-known/idp document.


This is, overall, correct. =A0However, do you think that you have to
login every time that you load or reload a webpage?
--001a11c3b8786fa5bc04ea8b032b-- From magnus.westerlund@ericsson.com Wed Nov 6 16:05:30 2013 Return-Path: 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 4D60D21E8135 for ; Wed, 6 Nov 2013 16:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.526 X-Spam-Level: X-Spam-Status: No, score=-105.526 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 5z+UVHh-aTEm for ; Wed, 6 Nov 2013 16:05:24 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7965221E80CE for ; Wed, 6 Nov 2013 16:05:23 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-f4-527ad9416090 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A8.AD.23787.149DA725; Thu, 7 Nov 2013 01:05:21 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.328.9; Thu, 7 Nov 2013 01:05:21 +0100 Message-ID: <527AD9A2.1020709@ericsson.com> Date: Wed, 6 Nov 2013 16:06:58 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adam Roach , Dan Burnett References: <527AA11B.8090408@ericsson.com> <527AABB3.1040203@alvestrand.no> <527AB408.7040503@ericsson.com> <055C9557-0995-49EA-A31D-D76EF2F3D187@voxeo.com> <527ACF60.7080503@ericsson.com> <527AD194.1030100@nostrum.com> In-Reply-To: <527AD194.1030100@nostrum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvja7jzaogg4efTS32/F3EbtH8cTqT xdp/7ewOzB5Llvxk8pi18wmLx6Ptq5kDmKO4bFJSczLLUov07RK4Mg7PvcRe0MdVsfXFCsYG xgaOLkZODgkBE4nL31ewQNhiEhfurWfrYuTiEBI4xCjR+nAuM4SzjFHi7dNNzCBVvALaEo+X /WcDsVkEVCRm/dzIBGKzCVhI3PzRCBYXFQiWOP9qMTtEvaDEyZlPwDaICDhLXPxzmBXEZhbQ lJiwbBdYvbCApcTRKSehNt9hlNjbex2sgRNo2a11a4AWcACdJy7R0xgE09u6/Tc7hC0v0bx1 NthtQkDlDU0drBMYhWYhWT0LScssJC0LGJlXMbLnJmbmpJcbbmIEBvDBLb91dzCeOidyiFGa g0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyTo4Xnr1CvX6EjtW/zti1+6lml 9mK+hdy3T/1ZHtQaHb425PexzPcqyqEWO1ce+HX2GZuQdaRhbu6uQDbZNd/XbHjcvNMzje/0 l7vbXRkWa8136778oqf7xvJPk0/+ifHUsp67Y1Ow0ZW9JQF8M08WnOcsl9/1bPkvVr6TOb/Y fldMNl5wImS+EktxRqKhFnNRcSIACskuPS4CAAA= Cc: "" Subject: Re: [rtcweb] Adhoc meeting on RTP to API Mapping X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 00:05:31 -0000 I am sitting in the bar now. People can show up early to get more background. The rest show up 17.20, and we will deal with as much as is possible. But, I think all this takes more than 20 minutes. Cheers Magnus On 2013-11-06 15:32, Adam Roach wrote: > On 11/6/13 15:23, Magnus Westerlund wrote: >> >> On 2013-11-06 14:43, Dan Burnett wrote: >>> This is a great idea, but can we do it during the ops plenary rather >>> than during STIR? (sending to the list so other interested parties >>> can chime in on timing). >> Okay, I am willing to move this to 1740. If anyone has serious issue >> with moving it howl. Same meeting place. >> > > How long do you expect this to take? I have something else I need to do > during the plenary, but might be able to speare 15 to 20 minutes. > > /a > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From martin.thomson@gmail.com Wed Nov 6 16:38:57 2013 Return-Path: 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 82F9A21E81AE for ; Wed, 6 Nov 2013 16:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, 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 59Tis6cBs1EI for ; Wed, 6 Nov 2013 16:38:04 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2774411E8160 for ; Wed, 6 Nov 2013 16:37:53 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id u57so254727wes.32 for ; Wed, 06 Nov 2013 16:37:51 -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=XaZteJXB6qtcwxKwhZFZV4WE/0suD7bUHnDu45gHf9Y=; b=kg6X/Gd0G6R2lKpFB0LmE5IcrHKzvA+vTLfGpM7EtBfu360GBBnD3Cjrkvs/T7pOt0 LQx+u3WxQjP3qCxjUPqyZwqZCEG9L3Qdc3TuXf1n/3NtDXUGkGF340/c0Z7rslv2eR3T lyI2y0RMHANGkLXLvjBqae9nKC8WP04gFWxu+BF95NcluRkXij3eYZKwMTSHj/gx5GiD OxYvh+a0HKTB/xkDV4ZkTJJKDSzvA16LxDPkdEObKRHK365NpVN28bg7wdj7sTtYHTpB nJ59oHsgvCl02SsZz5j3ovP8JmFitjR3YZ5tmv0mhK+sqY3VyfZSNU0edDohP89DLIZQ 28Ow== MIME-Version: 1.0 X-Received: by 10.194.176.163 with SMTP id cj3mr4843260wjc.8.1383784671350; Wed, 06 Nov 2013 16:37:51 -0800 (PST) Received: by 10.227.202.194 with HTTP; Wed, 6 Nov 2013 16:37:51 -0800 (PST) In-Reply-To: References: <52795BF0.1020207@makk.es> Date: Wed, 6 Nov 2013 16:37:51 -0800 Message-ID: From: Martin Thomson To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 00:38:58 -0000 On 6 November 2013 16:04, Wolfgang Beck wrote: > Probably not. It depends on the idp and browser settings. I'd rather fix the > problem than limit the frequency of its ocurrence. Maybe it's as easy as > having way for the webrtc server to determine what attributes the > idp-proxy is going to request, so it could 'prefetch' it. There is always a possibility for prefetching user authentication (with some caveats below). However, it is only possible to acquire the assertion after generating an identity assertion. If you have done the authentication prior to the call, then the call can proceed without bothering the user. The nature of the "log in" experience on the web is highly variable and flexible. The class of IdPs that we are talking about currently use have relatively long-lived authentication cookies, so I would consider it unlikely that these IdP interactions would require user interaction, as long as the last login to the IdP - for any reason - was relatively recent. For example, if you use Facebook as your IdP and you've been to Facebook recently, then I'd expect that the IdP would just proceed maybe after a one-off authorization for the user agent). And, just in case there is any confusion on the subject, validating an assertion does not necessarily require that a user log in. A Facebook IdP could be used to validate an assertion generated by Facebook, regardless of whether the relying user is a Facebook user. The caveat: There is an open question with respect to discovery or configuration of IdPs. For what I hope are obvious reasons, we need to ensure that the identity IdPs are not made public. That means that an application will be unable to guarantee that a user is logged in when the call is initiated. The upshot of that is not so serious as you might think. If I read our current discussions correctly, we are headed toward a situation where calls can be setup without the identity mechanisms being complete. (Note to self, examine trickling identity.) From silviapfeiffer1@gmail.com Wed Nov 6 16:57:04 2013 Return-Path: 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 7BF2011E8169 for ; Wed, 6 Nov 2013 16:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 g4p1xiAl9wyl for ; Wed, 6 Nov 2013 16:57:03 -0800 (PST) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB5D11E8160 for ; Wed, 6 Nov 2013 16:57:02 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id j17so376616oag.9 for ; Wed, 06 Nov 2013 16:57:02 -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=odCVwwd8AksL0EbT3jJSHueyeIu6CF2/qWTY8jpy35Y=; b=OIkX9wEzkfiF+nQW7ix73h53fjh3ntCgHwNDUAye/ahqc03xuljSrgTKyKCjNEtQPA X2aO6BVbzzAgq9xNappQpMdLZCzsmtOQMGoYU6K2SD6MEf9uj5JkZe5q1da1ro5vSKsz O5w8REQSveaxIhBGplLxUpA/YBmg2QnDz78LbjxOtHHn9ww9w7FRd/1mF2sKg9J9Ktd6 LoKqhH8Tk7B8ngz71Y5NNHPwPcPlLd6+zLcejp937AT3RtqYJCqcOoE16ORCWsaxhQaA tlIskqoOVYlC4qt6yQvDyLu2OlR8+TMNP+H+pC58Wup5uAHweHN2fGzE5JhcXR+nqd/b gW7w== MIME-Version: 1.0 X-Received: by 10.60.33.74 with SMTP id p10mr4778949oei.18.1383785820243; Wed, 06 Nov 2013 16:57:00 -0800 (PST) Received: by 10.76.94.40 with HTTP; Wed, 6 Nov 2013 16:57:00 -0800 (PST) Received: by 10.76.94.40 with HTTP; Wed, 6 Nov 2013 16:57:00 -0800 (PST) In-Reply-To: References: <20131106211149.GA1763@unaka.lan> <20131106214121.GB1763@unaka.lan> <527AC713.2020606@librevideo.org> Date: Thu, 7 Nov 2013 11:57:00 +1100 Message-ID: From: Silvia Pfeiffer To: Markus.Isomaki@nokia.com Content-Type: multipart/alternative; boundary=089e0115eef843058e04ea8bbe57 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 00:57:04 -0000 --089e0115eef843058e04ea8bbe57 Content-Type: text/plain; charset=ISO-8859-1 I'm very sad to see Nokia exclude themselves from ever making a business around VP8. It's sad to see a formerly successful technology company being dismantled by lawyers and desperation. Silvia. On 7 Nov 2013 10:41, wrote: > Hi, > > Basil Mohamed Gohar wrote: > > > > VP8 is not encumbered by patents because that patents that are known > > about are granted by Google and via Google's deal with MPEG-LA. Nokia's > > threats have failed in Germany, so there remains no known encumbrance > > against VP8. > > > > This is not correct. The Nokia vs. HTC case where three V8 related patents > are included is still very much ongoing. For instance, one of the three > cases has not even been started. There is some preliminary information > about the first two e.g. in [1] and [2], but also appeals have been made, > so the processes are far from complete. > > Note that there are also three other Nokia patents that were declared to > the IETF which are not covered in the Nokia vs. HTC case. > > The point is that it is definitely too early to make conclusions (either > way). > > [1] > http://www.fosspatents.com/2013/05/german-court-has-apparently-found.html > [2] > http://www.fosspatents.com/2013/08/dutch-appeals-court-sides-with-nokia-in.html > > Markus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e0115eef843058e04ea8bbe57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I'm very sad to see Nokia exclude themselves from ever m= aking a business around VP8. It's sad to see a formerly successful tech= nology company being dismantled by lawyers and desperation.
Silvia.

On 7 Nov 2013 10:41, <Markus.Isomaki@nokia.com> wrote:
Hi,

Basil Mohamed Gohar wrote:
>
> VP8 is not encumbered by patents because that patents that are known > about are granted by Google and via Google's deal with MPEG-LA. = =A0Nokia's
> threats have failed in Germany, so there remains no known encumbrance<= br> > against VP8.
>

This is not correct. The Nokia vs. HTC case where three V8 related patents = are included is still very much ongoing. For instance, one of the three cas= es has not even been started. There is some preliminary information about t= he first two e.g. in [1] and [2], but also appeals have been made, so the p= rocesses are far from complete.

Note that there are also three other Nokia patents that were declared to th= e IETF which are not covered in the Nokia vs. HTC case.

The point is that it is definitely too early to make conclusions (either wa= y).

[1] http://www.fosspatents.com/2013/05/german-= court-has-apparently-found.html
[2] http://www.fosspatents.com/2013/08/d= utch-appeals-court-sides-with-nokia-in.html

Markus
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--089e0115eef843058e04ea8bbe57-- From harald@alvestrand.no Wed Nov 6 18:48:58 2013 Return-Path: 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 E9E9311E8227 for ; Wed, 6 Nov 2013 18:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 CpsVLoSyqWg1 for ; Wed, 6 Nov 2013 18:48:54 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 55F8E11E822B for ; Wed, 6 Nov 2013 18:48:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4FFE139E05D for ; Thu, 7 Nov 2013 03:48:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3dJ-efEMFYR for ; Thu, 7 Nov 2013 03:48:51 +0100 (CET) Received: from [IPv6:2001:67c:370:160:6056:eeee:f72d:1d19] (unknown [IPv6:2001:67c:370:160:6056:eeee:f72d:1d19]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4A8AE39E029 for ; Thu, 7 Nov 2013 03:48:47 +0100 (CET) Message-ID: <527AFF89.3000408@alvestrand.no> Date: Thu, 07 Nov 2013 03:48:41 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <527420FC.3070805@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 02:48:59 -0000 On 11/06/2013 11:06 PM, Martin Thomson wrote: > The question in the room was: > > Given a negotiated session with "A, B, and C", is an endpoint > permitted to create an offer that includes "D"? That's not what I heard. What I heard was: X offers A, B and C (codecs being the canonical example). Y answers A (only). That means we have agreement to use A only. X wants to send a new offer. Three alternatives: 1) X MUST offer A, B and C 2) X MUST offer A (only) if no particular constraint is set, but MUST offer A, B and C if some (to-be-defined) constraint is set. 3) X MAY offer A, and MAY offer A, B and C (nondeterministic behaviour) I like option 2, for the reasons stated (deterministic, seems to do the job). > > A great many people said yes, because that is how SDP is most commonly used. > > I agree that not offering A, B or C would be bad. > > On 6 November 2013 14:01, Hutton, Andrew wrote: >> I vote for option 2 – Application controls renegotiation through constraint. >> >> >> >> Option 1 would be bad. >> >> >> >> Option 3 would be very bad. >> >> >> >> Andy >> >> >> >> >> >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of >> Justin Uberti >> Sent: 06 November 2013 13:37 >> To: Michael Procter >> >> >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers >> >> >> >> From the room discussion, I sensed 3 possible options to move forward. >> >> 1) MUST NOT renegotiate codecs etc. (new PeerConnection if you want to >> renegotiate) >> >> 2) MUST NOT renegotiate codecs etc. by default, but MUST support option to >> renegotiate (application controls renegotiation through constraint) >> >> 3) SHOULD NOT renegotiate codecs etc, but implementation MAY do so if >> desired (no application logic needed, but non-deterministic API behavior) >> >> >> >> "etc" here would not include anything that would result in the offer >> changing from the previously agreed-upon local description, including >> codecs, RTP header extensions, RTCP feedback mechanisms, BUNDLE groupings, >> or use of FEC/RTX. >> >> >> >> I proposed #1 in the room, but see #2 as a reasonable solution. That >> provides the application with full control over what it wants, as well as >> deterministic behavior. >> >> >> >> On Wed, Nov 6, 2013 at 1:29 PM, Justin Uberti wrote: >> >> Yes, it would. But I think the problem still exists for applications that >> don't use partial offer/answers. >> >> >> >> On Wed, Nov 6, 2013 at 12:47 PM, Michael Procter wrote: >> >> On 3 November 2013 22:55, Justin Uberti wrote: >>> According to section 5.2.5, it seems that this is only the cases for >>> offers >>> triggered by offerless reINVITEs. I don't think we want to be >>> re-allocating >>> and negotiating codecs every time we want to make a change to the session >>> descriptions in use. >> Would the partial offer/answer work address at least part of this? >> m-lines that you don't want to change wouldn't need to be advertised >> at all, rather than being advertised with a restricted codec set. >> >> Michael >> >> >> >> >> >> >> _______________________________________________ >> 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 -- Surveillance is pervasive. Go Dark. From martin.thomson@gmail.com Wed Nov 6 19:14:36 2013 Return-Path: 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 D41FD21E80EB for ; Wed, 6 Nov 2013 19:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, 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 KhzRNRw1gMSi for ; Wed, 6 Nov 2013 19:14:36 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D650721E80D5 for ; Wed, 6 Nov 2013 19:14:35 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id t61so351756wes.41 for ; Wed, 06 Nov 2013 19:14:34 -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=yyQntJOEEsxFXgUg69dqK75yi31LEFicMS1qYcHmfO4=; b=p6zlwS9zh5mtUWLFo24T4QjdZtQiGL1KPg3BOMKpG5AUC3BLve4ppF0MWJPK9Scn1B YfJ2IpxIHal1xdo/HWCwut6M6OLgnK68MdHapw9QE+5OcAAQHfi9HvBMPE/s7qLXFI1H pgzJGcy2Ih6YnyPGVOPj7yDN3wrBVArkr/Jf8DZ+AYQifOn6dIBrY9ubMiIn9jcWEcOM 5NVC4SVSPHQanu5/Iga/4Ai/lQoczK1ZA1QQBN3enh4/kTsL7SYz6Uhf1GxbtwYzsGt8 /+bJulhsvvSoGN4XjNNWN0ssib4QMYFtbB0X6DBzI0T5bkqhBkoLOy2CEpCswt48dU4U h0Qw== MIME-Version: 1.0 X-Received: by 10.180.109.75 with SMTP id hq11mr628766wib.30.1383794074740; Wed, 06 Nov 2013 19:14:34 -0800 (PST) Received: by 10.227.202.194 with HTTP; Wed, 6 Nov 2013 19:14:34 -0800 (PST) In-Reply-To: <527AFF89.3000408@alvestrand.no> References: <527420FC.3070805@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net> <527AFF89.3000408@alvestrand.no> Date: Wed, 6 Nov 2013 19:14:34 -0800 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 03:14:36 -0000 On 6 November 2013 18:48, Harald Alvestrand wrote: > 2) X MUST offer A (only) if no particular constraint is set, but MUST > offer A, B and C if some (to-be-defined) constraint is set. ... > > I like option 2, for the reasons stated (deterministic, seems to do the > job). Yes, I didn't precisely describe the issue, but the discussion and disagreement was focused on the sub-options of that point. I'm less concerned about determinism here. It's SDP already, suck it up. The key point of determinism that I consider relevant here is that A remains in the set (if possible). I'm perfectly comfortable with additional codecs appearing in the list. I don't see a need for constraints, in fact, given that there is no need to convey the extra options to the answerer. SDP is mutable. In that sense, having all the options enumerated, every time, is actually highly desirable. (Note that as a browser vendor you can unilaterally determine that B and C are no longer "viable options" and then not include them.) From singer@apple.com Wed Nov 6 22:01:27 2013 Return-Path: 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 5FB0221E8090 for ; Wed, 6 Nov 2013 22:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 LZKgDSO1NmBm for ; Wed, 6 Nov 2013 22:01:21 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) by ietfa.amsl.com (Postfix) with ESMTP id D2A9F21E80C3 for ; Wed, 6 Nov 2013 22:01:12 -0800 (PST) Received: from relay3.asia.apple.com ( [17.82.200.17]) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id AD.FB.21841.A9C2B725; Thu, 7 Nov 2013 14:00:58 +0800 (MYT) X-AuditID: 1152fe11-b7f256d000005551-b3-527b2c9a8d74 Received: from gambooge.asia.apple.com ( [17.82.200.120]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id 49.E8.26194.A9C2B725; Thu, 7 Nov 2013 14:00:58 +0800 (MYT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.83.34.149] (unknown [17.83.34.149]) by mail.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVV00DQKQ1LAA60@mail.asia.apple.com> for rtcweb@ietf.org; Thu, 07 Nov 2013 14:00:58 +0800 (SGT) From: David Singer In-reply-to: <20131106211149.GA1763@unaka.lan> Date: Thu, 07 Nov 2013 15:00:58 +0900 Message-id: <4D994310-2825-497D-8337-70BF37282218@apple.com> References: <20131106211149.GA1763@unaka.lan> To: Toshio Kuratomi X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUiGHRCUHeWTnWQwfFzBhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr483X7+wFLUIVs2e3szYwnuLrYuTkkBAwkeh4c5cNwhaTuHBv PZDNxSEksJtRouvdDxaYouV9zawQiX4miZ/LXoJ18AoISvyYfA+oiIODWUBe4uB5WZAws4CW xPdHrSwQ9QuZJKbvOckOUiMsECpxdaUaSA2bgKrEgznHGEFsTgE9ideN18FGsgDFz/U0M0LM EZb4/hhiPK+AjUT3hDyQsJCArsSbQ5fBSkQENCSmf33DCnGmrMTpc8/B1koIfGWV2Dz/F/ME RuFZSC6dhXDpLCSXLmBkXsUonpuYmaObmWeol1icmaiXWFCQk6qXnJ+7iREczP8EdzBOXWh4 iFGAg1GJh9czqThIiDWxrLgy9xCjBAezkgjvvWdVQUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 f/8tDxISSE8sSc1OTS1ILYLJMnFwSjUw8sosSLO2Fj25sf6fvZrC9KO5l/7ICZgILj2U4LLn 5dUVL6tdherSZMtvTjGJv9UqlvfWNHFt4LQ5uRGn5HiYjxnOXrX0uA7n/WX79uk+eDJPgu9S 8PlVdZJ9wqpZpx39595Nfvng1p/lMduP5q4UcPinrfDbWdBaU3mqm6ut8lunbTWi+WJ+SizF GYmGWsxFxYkAJDKnR2ICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUiGHSiQneWTnWQQfcpXYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8ebrd/aCFqGK2bPbWRsYT/F1MXJySAiYSCzva2aFsMUkLtxb z9bFyMUhJNDPJPFz2Us2kASvgKDEj8n3WLoYOTiYBeQlDp6XBQkzC2hJfH/UygJRv5BJYvqe k+wgNcICoRJXV6qB1LAJqEo8mHOMEcTmFNCTeN14HWwkC1D8XE8zI8QcYYnvjyHG8wrYSHRP yAMJCwnoSrw5dBmsRERAQ2L61zdQZ8pKnD73nGUCo8AsJMfNQjhuFpLjFjAyr2IULUrNSaw0 1ksszkzUSywoyEnVS87P3cQICT7BHYwfphoeYhTgYFTi4WV6XRQkxJpYVlyZe4hRgoNZSYT3 3rOqICHelMTKqtSi/Pii0pzU4kOM0hwsSuK8sv/Kg4QE0hNLUrNTUwtSi2CyTBycUg2MG52d dM0lHF593bB0E4dqxbwFUcWTLlbXf03dWbz+kJGD4z0Nc8H8N2EfZ2fYtExne6rX6MPWN6Xd McShNrr/Vr/O5OONRvvfN9swmjlsX1YpxdrOvMIixvm35aPdB1fv6fjtHOR2mC/Pi/PIIY0g /Zd283icNkz7f3f/TTeFbdb17U97u1YrsRRnJBpqMRcVJwIAoxUS3zoCAAA= Cc: rtcweb@ietf.org Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 06:01:27 -0000 Note that you would not have to include it in your distribution; you could suggest it in your installer, for example, and if the suggestion is taken, facilitate the install. On Nov 7, 2013, at 6:11 , Toshio Kuratomi wrote: > > Greetings, > > I serve on the Engineering Steering Committee for the Fedora Project, a Linux > Distribution. A few days ago we were asked if we could give input on > OpenH264 becoming a MTI codec in the rtcweb standard. We discussed the > issue at our weekly meeting and agreed on this statement: > > > Fedora is a distribution that cares about software freedom and our users > freedom. Firstly, we cannot ship binary-only prebuilt software within Fedora. > This rules out inclusion of OpenH264 binaries direct from Cisco, or other > providers. Secondly, we cannot ship software built from source which is not free > for any use, freely distributable, and free from patent restrictions. > Therefore, Fedora is similarly unable to ship rebuilt OpenH264 code. > > Fedora would be much happier with a non-patent encumbered codec in the standard > as it would relieve us of the burden of caring for a codec implementation that > we cannot fix if it is buggy on our platform, let us ship improved or more > efficient versions of the codec if that is asked for, and relieve us of the > burden of making sure all implementors of the standard were using a proper > technique to retrieve the patent-encumbered portion from the internet so that > we weren't shipping non-free code. > > Acceptance of an insufficiently-free license of the OpenH264 codec would mean > that open-source vendors are not able to implement it on their own terms. They > must rely on the implementation provided by a third party (Cisco) and create > workarounds to have the user download that implementation after installation, > increasing the burden on open-source users. This creates an unequal environment > for open-source vendors. > > > I hope that helps in your decision making. > > Thank you for your time, > Toshio Kuratomi > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb David Singer Multimedia and Software Standards, Apple Inc. From singer@apple.com Wed Nov 6 22:04:13 2013 Return-Path: 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 7DE4F11E813A for ; Wed, 6 Nov 2013 22:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_MEDS=0.842] 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 DiEX8ws80EDb for ; Wed, 6 Nov 2013 22:04:08 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) by ietfa.amsl.com (Postfix) with ESMTP id 86A0411E8151 for ; Wed, 6 Nov 2013 22:04:07 -0800 (PST) Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id E5.1C.21841.65D2B725; Thu, 7 Nov 2013 14:04:06 +0800 (MYT) X-AuditID: 1152fe11-b7f256d000005551-01-527b2d565fd5 Received: from echium.asia.apple.com ( [17.82.200.52]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id F1.34.14371.65D2B725; Thu, 7 Nov 2013 14:04:06 +0800 (MYT) Received: from [17.83.34.149] (unknown [17.83.34.149]) by echium.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVV00EK7Q6TVJ10@echium.asia.apple.com> for rtcweb@ietf.org; Thu, 07 Nov 2013 14:04:06 +0800 (SGT) Content-type: text/plain; charset=iso-8859-1 MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: David Singer In-reply-to: Date: Thu, 07 Nov 2013 15:04:06 +0900 Content-transfer-encoding: quoted-printable Message-id: <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com> References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <527A06EF.2070007@bbs.darktech.org> <527A0C4D.7020707@gmail.com> <527A15A3.2090006@bbs.darktech.org> To: Mohammed Raad X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUiGHRCSDdMtzrIYFarpsXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeDxVvKBdvGLumhbWBsZ9Ql2MnBwSAiYSh488ZoawxSQu3FvP 1sXIxSEksJtR4vP0NWwwRc/2wyR6mCT6Dy1ggXCWMkm82dwM1s4soCPR+/0bmM0roCexc+82 VhBbWMBI4s7GFkYQm01AVeLBnGNgNqdAsETHtNPsIDYLUHxZy2lGiDnCEt8f32OBsLUlnry7 wAox00bi4LpTrBCL/zNLzD53CKxIBGjZ1bfboU6VlTh97jkLhP2SVeLwQosJjMKzkNw3C8l9 s5DsWMDIvIpRPDcxM0c3M89QL7E4M1EvsaAgJ1UvOT93EyM4pP8J7mCcutDwEKMAB6MSD69n UnGQEGtiWXFl7iFGCQ5mJRHee8+qgoR4UxIrq1KL8uOLSnNSiw8xSnOwKInz/v5bHiQkkJ5Y kpqdmlqQWgSTZeLglGpgdOWZvuzg6wfx86Zz5HzsMZ3lL8nyL6D3m5bd++drma/OXPCSIfVW dM+iurCrxmezl5or7yhrmW97RP5y07/jK07lsv1MFvzcf8l5x8wLH/X36WidEb9vK1g/Me5m 0eyFsTuuTU4KPaHRanBkzt0/nJcdBLucnZfwBDy/0LPy+aKND0Wu1nWse6jEUpyRaKjFXFSc CAD/pzpxZQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUiGHTCRDdMtzrI4GCzmsXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeDxVvKBdvGLumhbWBsZ9Ql2MnBwSAiYSz/avZ4OwxSQu3AOx uTiEBHqYJPoPLWCBcJYySbzZ3MwMUsUsoCPR+/0bmM0roCexc+82VhBbWMBI4s7GFkYQm01A VeLBnGNgNqdAsETHtNPsIDYLUHxZy2lGiDnCEt8f32OBsLUlnry7wAox00bi4LpTrBCL/zNL zD53CKxIBGjZ1bfboU6VlTh97jnLBEaBWUhumoXkpllI5i5gZF7FKFqUmpNYaaiXWJyZqJdY UJCTqpecn7uJERKEQjsYP+43OMQowMGoxMN7/UFRkBBrYllxZe4hRgkOZiUR3nvPqoKEeFMS K6tSi/Lji0pzUosPMUpzsCiJ88r+Kw8SEkhPLEnNTk0tSC2CyTJxcEo1MNo0zTu6qvvA7qDI 9Um1c55m5WqZrfsgFu13rEVox1lm6e6GsOQO5p8hT1787X/wfOOpFwIs94Pl+NzLfE3XmmQI LPNgmiz18vyJ7klfXVjOrk5luxmwOm3LvJdiGfdX3hSqZterb67YUvMppsKh/ClDV/GMpa5b bLYwhnI0skaf3npo5ce2mUosxRmJhlrMRcWJAE0+htw+AgAA Cc: rtcweb@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 06:04:13 -0000 On Nov 7, 2013, at 5:33 , Mohammed Raad = wrote: > Hi, >=20 > There isn't much new in the arguments for and against VP8 vs H.264. = Its clear that there are concerns that are beyond how well each codec = performs and whether or not it is free. Although I recognize that the = transcoding option does not address the P2P use case, I do think that = the goal of interoperability can be better achieved through a two phase = approach. The first is enabling end-points to inter-operate through the = availability of transcoding from the service provider. The second is to = make one of the codecs the defacto MTI because of the its higher level = of adoption. Yes, we may never get to a single MTI if we follow this = path but at least we will have endpoints inter-operating. Besides, there = are multiple other difficulties in getting seamless P2P communications = working all the time, so I would suggest focusing on the service = provider centered use case first. You know, you're right. =20 We could suggest or even recommend both, and mandate you must implement = at least one of the two. That would identify precisely two = interoperability points in an otherwise much larger space, at least, and = make it fairly simple for those that can and wish to, to offer = transcoding, since the two ends are now defined. It's not ideal, but it = might be better than saying nothing at all. >=20 > BR, > Mohammed >=20 >=20 > On Wed, Nov 6, 2013 at 9:10 PM, cowwoc = wrote: > On 06/11/2013 4:30 AM, Daniel-Constantin Mierla wrote: > As it stands today, there are well known IPR issues with h264. Cisco's = move doesn't lift them. >=20 > So why to choose it if falls under the rules to remove it? >=20 >=20 > No one says it has to be H.264 and VP8. It could be H.261 and VP8. >=20 >=20 > With both on board, I still expect the majority of the apps will = implement only the most convenient for them, eventually expecting the = other to have both. Then responsibility is getting divided, like "it's = not _only_ my fault", blaming the other end point as well.=20 >=20 > That is a reasonable concern, and one that we need to address. = Implementations that violate these rules will make it harder for us to = replace older MTI codecs without breaking backwards compatibility. >=20 > Gili >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 >=20 > --=20 > Mohammed Raad, PhD. > Partner > RAADTECH CONSULTING > P.O. Box 113 > Warrawong > NSW 2502 Australia > Phone: +61 414451478 > Email: mohammedsraad@raadtech.com > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb David Singer Multimedia and Software Standards, Apple Inc. From singer@apple.com Wed Nov 6 22:10:19 2013 Return-Path: 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 6AE8011E817E for ; Wed, 6 Nov 2013 22:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 49wFnfzfwuvZ for ; Wed, 6 Nov 2013 22:10:11 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9C111E8167 for ; Wed, 6 Nov 2013 22:10:09 -0800 (PST) Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 81.3C.21841.3BE2B725; Thu, 7 Nov 2013 14:09:55 +0800 (MYT) X-AuditID: 1152fe11-b7f256d000005551-e6-527b2eb36181 Received: from echium.asia.apple.com ( [17.82.200.52]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id D7.64.14371.3BE2B725; Thu, 7 Nov 2013 14:09:55 +0800 (MYT) Received: from [17.83.34.149] (unknown [17.83.34.149]) by echium.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVV00EQ1QGIVJ10@echium.asia.apple.com> for rtcweb@ietf.org; Thu, 07 Nov 2013 14:09:55 +0800 (SGT) Content-type: text/plain; charset=iso-8859-1 MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: David Singer In-reply-to: Date: Thu, 07 Nov 2013 15:09:55 +0900 Content-transfer-encoding: quoted-printable Message-id: References: To: Emil Ivov X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUiGHRCSHezXnWQwaU/MhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/ysGewFa5krXs9dxtLAeIOpi5GTQ0LAROJ9zyooW0ziwr31 bF2MXBxCArsZJU7N2coKU7Rm1Q5WiEQPk8TMs7+hnKVMEkf3PmQHqWIW0JHo/f6NGcTmFdCT 2Ll3G1i3sEC0xK+dz8Bq2ARUJR7MOcYIYnMKBEu8n9vLBmKzAMUPTnjECjHHVuLDteMsELa2 xJN3F1ghZtpIXHu6GOq8mYwSmy/vAxskIiAv0d22COoHWYnT556zgBRJCHxklWjcN5NtAqPw LCQHzkJy4CwkSxYwMq9iFM9NzMzRzcwz1EsszkzUSywoyEnVS87P3cQIDut/gjsYpy40PMQo wMGoxMPrmVQcJMSaWFZcmXuIUYKDWUmE996zqiAh3pTEyqrUovz4otKc1OJDjNIcLErivL// lgcJCaQnlqRmp6YWpBbBZJk4OKUaGGdldh+24ziraHd7dzTX1/R5kiE5uld/G/5LvvosJs+f lYFHpTy57Ko3Y9KR0CbmQ076m1qXl5Qkbfm0pLhs+ju+zx2JVfZThVx+zLGf58a6Z8v1BOlt c+ZxHu0uebPqWkD5nvDaed6WuRnVrz95Wbm25PnwBruHHvvR0vn17MxU6762vkvblViKMxIN tZiLihMBuOqpgWcCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUiGHTCRHezXnWQwdKfUhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/ysGewFa5krXs9dxtLAeIOpi5GTQ0LARGLNqh2sELaYxIV7 69m6GLk4hAR6mCRmnv3NCuEsZZI4uvchO0gVs4CORO/3b8wgNq+AnsTOvdvAuoUFoiV+7XwG VsMmoCrxYM4xRhCbUyBY4v3cXjYQmwUofnDCI1aIObYSH64dZ4GwtSWevLvACjHTRuLa08VQ V8xklNh8eR/YIBEBeYnutkVQZ8tKnD73nGUCo8AsJDfNQnLTLCRzFzAyr2IULUrNSaw01Ess zkzUSywoyEnVS87P3cQICUOhHYwf9xscYhTgYFTi4b3+oChIiDWxrLgy9xCjBAezkgjvvWdV QUK8KYmVValF+fFFpTmpxYcYpTlYlMR5Zf+VBwkJpCeWpGanphakFsFkmTg4pRoYg0wiLc47 +j7kUH+TvrT4lnX7nNdvV6WI3uM1iNp9fELNXnZZ/943MjejhPd9r0g+o6d8ViVCMllv+5WA M/uLOnVL+rS8c4QO6fo9nJy6zib6TfC+hXP0j9wsfKb/Z5FWV32ff3XD/E/v9/q1r1tfafEg +91KXa1LiuI11T02G8OfKws9nsmpxFKckWioxVxUnAgAJJXFZD8CAAA= Cc: Harald Tveit Alvestrand , rtcweb@ietf.org Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 06:10:19 -0000 On Nov 2, 2013, at 19:34 , Emil Ivov wrote: > Compared to VP8, H.264 baseline is only marginally better than H.263. = This makes it hard to justify the inconvenience of post-installation = additions. Baseline is better than VP8, I think. But I don't think this debate is = about the codec quality, as previously noted (within reason). David Singer Multimedia and Software Standards, Apple Inc. From hta@google.com Wed Nov 6 22:20:12 2013 Return-Path: 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 A46CF11E817E for ; Wed, 6 Nov 2013 22:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 waI6278COhAW for ; Wed, 6 Nov 2013 22:20:12 -0800 (PST) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CDA9911E8167 for ; Wed, 6 Nov 2013 22:20:10 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id 10so67549vbe.19 for ; Wed, 06 Nov 2013 22:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v5AYBDb16e4NnisXqP23J02lFgACT5j31Adnv3VukR0=; b=MHHBFst8NbSekgMzqZVuHKBzIgN3oPqDGy+v4oa576HteIDB1nBV/ce7NgO2lAHgt1 YzkKI6rp2BkluXQXFz9frtPsk6K6P80YrrR/dtC7L4l3XMRbhulC0GqBtxY+IauocUF6 wy+Y2oHWr8aN6fYQtv467+cGwyN0IsonwOO00VkE0z6yjnWu+Kg9tHUY3wb3gDU1v8kB Edy2CKrx2WnkFG31Bbff3ZXotHkNwnoHchXHIZUeUuYP8sPQMKP/GZjop8OJPczW4XOM U30mBrTvkdLJTV5vTLIJUllg/IslIfT7qLTjD9Bzvpcx38lFbUPWPvqpJW7SKqByUzOO KoCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=v5AYBDb16e4NnisXqP23J02lFgACT5j31Adnv3VukR0=; b=U5EXT8PQjj+CSAKJQTSMkb5SmchGF3082OuWCSjGiZT+YAUrhKaqj6rhYGv3RqOJ15 w8cWIztZuoWwH92htW4GBi+8H8YlxzVVqAya0duEGf3DqhtWHHDuzHGC/WKsjoZ8v/NY f8bD6IQOe9vrUZGXwPRemcYlCPSavDB5FhYP6mKmjvWIQ7fPojfTNeLwx6Cgkm7gGAOS W+++qyqW755Ioqs3/2Ft1ZSnoUu1yYkom8bX4LmqRTjChpe6+KtfmALBCoQG3jipCmEG kyXn5KxtlyPLLgWVkVPJv2cTiNxr8G2plHeFGM6c+Y6sKlVVat4lt1eyrIP4knvtoseI 32dg== X-Gm-Message-State: ALoCoQnnBDyObKQUey2FW/7oM8/4KTtETtST60KZz/LF+oSCTc+kqqIapLF1pq2XzaRn0ov+erAdZxC+65BJ0cidZuQv7Pi//l52R7IRdMCMgYM2Mx85m34c2D+aBoRhuMjyXhmgrEvS3i8V9jXzNNUiD9rZpFmc5fbbI7Lbfop2mPlC9bG3TDKap8TMD9iRdzGiHLHKkzrP X-Received: by 10.220.253.66 with SMTP id mz2mr5395775vcb.10.1383805207523; Wed, 06 Nov 2013 22:20:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.176.8 with HTTP; Wed, 6 Nov 2013 22:19:47 -0800 (PST) In-Reply-To: References: From: Harald Alvestrand Date: Thu, 7 Nov 2013 07:19:47 +0100 Message-ID: To: David Singer Content-Type: multipart/alternative; boundary=089e013c70b8d5569804ea9041d0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 06:20:12 -0000 --089e013c70b8d5569804ea9041d0 Content-Type: text/plain; charset=UTF-8 Re performance, and just so that silence isn't taken as me agreeing with David Singer on this topic: I haven't wanted to distract from the debate at hand by tossing more numbers around, but we do think VP8 is significantly better than Baseline. The exchanges with Ericsson have shown that we need to be meticulously clear in defining what we mean by that and how we measure it, so I won't post more numbers until I feel that our description is precise enough. Harald On Thu, Nov 7, 2013 at 7:09 AM, David Singer wrote: > > On Nov 2, 2013, at 19:34 , Emil Ivov wrote: > > > Compared to VP8, H.264 baseline is only marginally better than H.263. > This makes it hard to justify the inconvenience of post-installation > additions. > > Baseline is better than VP8, I think. But I don't think this debate is > about the codec quality, as previously noted (within reason). > > David Singer > Multimedia and Software Standards, Apple Inc. > > --089e013c70b8d5569804ea9041d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Re performance, and just so that silence isn't taken a= s me agreeing with David Singer on this topic:

I haven't wanted = to distract from the debate at hand by tossing more numbers around, but we = do think VP8 is significantly better than Baseline. The exchanges with Eric= sson have shown that we need to be meticulously clear in defining what we m= ean by that and how we measure it, so I won't post more numbers until I= feel that our description is precise enough.

Harald





On Thu, No= v 7, 2013 at 7:09 AM, David Singer <singer@apple.com> wrote:<= br>

On Nov 2, 2013, at 19:34 , Emil Ivov <emcho@jitsi.org> wrote:

> Compared to VP8, H.264 baseline is only marginally better than H.263. = This makes it hard to justify the inconvenience of post-installation additi= ons.

Baseline is better than VP8, I think. =C2=A0But I don't think thi= s debate is about the codec quality, as previously noted (within reason).
David Singer
Multimedia and Software Standards, Apple Inc.


--089e013c70b8d5569804ea9041d0-- From pkyzivat@alum.mit.edu Wed Nov 6 22:22:07 2013 Return-Path: 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 78B0D21E8090 for ; Wed, 6 Nov 2013 22:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 gT3B83nkPehy for ; Wed, 6 Nov 2013 22:22:01 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 850C821E8064 for ; Wed, 6 Nov 2013 22:22:01 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta15.westchester.pa.mail.comcast.net with comcast id mWK31m0030cZkys5FWN1TY; Thu, 07 Nov 2013 06:22:01 +0000 Received: from dhcp-9448.meeting.ietf.org ([31.133.148.72]) by omta10.westchester.pa.mail.comcast.net with comcast id mWKt1m0031ZxU2f3WWKv0a; Thu, 07 Nov 2013 06:19:59 +0000 Message-ID: <527B3109.7050705@alum.mit.edu> Date: Wed, 06 Nov 2013 22:19:53 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <527420FF.2@alum.mit.edu> <527AA850.3050807@alum.mit.edu> <527AADA1.7060304@alvestrand.no> In-Reply-To: <527AADA1.7060304@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383805321; bh=jMR6A6qbscKfV+Ud0gl0m2Z4evV1y4GcHfFre11s7AY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=A/0Yua6C7iylAT589VLbM6TT+0hJgaPAHL8Hdw+edf8cGHb6S22gnfpb3/LzPTvaE HQTSlzdGrZa2iM4p9tT7px2VX8AUbICApu9T3gL/bls0kAbkpcZ3urVAUn+TfYfjn6 NmXv9+hBphCM1hw1AOoAIfB8RsEU1v4h4sk5ansDXSZvGVcEpFmOuA+R2NujX3Pz+7 icRrlCrOASwr0+S6FXnUpg0Lbyts9JZ0GmFzw57mD681ZuUwiCRCYB7oAck9Za+Vev fkAQuSSL+qC0RQmddbGqCITHBLLi87UdxepxboIHDpdoIMPzzRzEyu8+tcTqwKvfV4 Lmv6HjxNl3F6A== Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Recycling m-lines X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 06:22:07 -0000 On 11/6/13 12:59 PM, Harald Alvestrand wrote: > On 11/06/2013 09:36 PM, Paul Kyzivat wrote: >> On 11/3/13 11:09 PM, Justin Uberti wrote: >>> >>> On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat >> > wrote: >> ... >>> Later in 5.2.2: >>> >>> o If a m= section exists in the current local description, >>> but has >>> its state set to inactive or recvonly, and a new >>> MediaStreamTrack >>> is added, the previously existing m= section MUST be recycled >>> instead of creating a new m= section. [OPEN ISSUE: Nail down >>> exactly what this means. Should the codecs remain the same? >>> (No.) Should ICE restart? (No.) Can the "a=mid" >>> attribute be >>> changed? (Yes?)] >>> >>> This seems to assume that there is no existing MediaStreamTrack for >>> these m-lines. >>> >>> Yes. The text should state that more clearly. >>> >>> If there is, then >>> - the m-line shouldn't be recycled. >>> If there isn't, then >>> - where do its address and port come from? >>> - what is managing the RTCP? >>> >>> >>> The m= section will still have completed ICE negotiation, despite being >>> marked as inactive. So the address/port information should already be >>> present. >> >> *Why* would you do this if there is no MediaStreamTrack and hence no >> possibility of using the port? >> >> IOW, why not use port zero in these cases? >> >>> I don't follow your question about who is managing RTCP. >> >> It may be a misunderstanding on my part. >> >> My thinking is that the MediaStreamTrack is a surrogate for the >> resource that manages the RTP/RTCP for that track. If so, then no >> track -> no RTCP. >> >> Of course, with bundling, that resource gets spread across multiple >> MediaStreamTracks. > > That's why thinking of it in the way you suggest is likely to lead to > misunderstandings and confusion all around. > > I've had greater success thinking of a MediaStreamTrack as an SSRC; the > resource that manages the RTP/RTCP is then a container that contains MSTs. Isn't that container the PeerConnection? Or are you thinking that the PeerConnection contains one of these containers for each distinct RTP-Session? Thanks, Paul From harald@alvestrand.no Wed Nov 6 22:34:18 2013 Return-Path: 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 6D68821E80E0 for ; Wed, 6 Nov 2013 22:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 gxbdEWLEXw85 for ; Wed, 6 Nov 2013 22:34:11 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB3C21E8064 for ; Wed, 6 Nov 2013 22:34:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5740739E05D for ; Thu, 7 Nov 2013 07:34:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngVPj42CtpAZ for ; Thu, 7 Nov 2013 07:34:07 +0100 (CET) Received: from [31.133.161.198] (dhcp-a1c6.meeting.ietf.org [31.133.161.198]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EBCB739E03A for ; Thu, 7 Nov 2013 07:34:06 +0100 (CET) Message-ID: <527B345C.9090901@alvestrand.no> Date: Thu, 07 Nov 2013 07:34:04 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <527420FF.2@alum.mit.edu> <527AA850.3050807@alum.mit.edu> <527AADA1.7060304@alvestrand.no> <527B3109.7050705@alum.mit.edu> In-Reply-To: <527B3109.7050705@alum.mit.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Recycling m-lines X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 06:34:18 -0000 On 11/07/2013 07:19 AM, Paul Kyzivat wrote: > On 11/6/13 12:59 PM, Harald Alvestrand wrote: >> On 11/06/2013 09:36 PM, Paul Kyzivat wrote: >>> On 11/3/13 11:09 PM, Justin Uberti wrote: >>>> >>>> On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat >>> > wrote: >>> ... >>>> Later in 5.2.2: >>>> >>>> o If a m= section exists in the current local description, >>>> but has >>>> its state set to inactive or recvonly, and a new >>>> MediaStreamTrack >>>> is added, the previously existing m= section MUST be >>>> recycled >>>> instead of creating a new m= section. [OPEN ISSUE: >>>> Nail down >>>> exactly what this means. Should the codecs remain the >>>> same? >>>> (No.) Should ICE restart? (No.) Can the "a=mid" >>>> attribute be >>>> changed? (Yes?)] >>>> >>>> This seems to assume that there is no existing >>>> MediaStreamTrack for >>>> these m-lines. >>>> >>>> Yes. The text should state that more clearly. >>>> >>>> If there is, then >>>> - the m-line shouldn't be recycled. >>>> If there isn't, then >>>> - where do its address and port come from? >>>> - what is managing the RTCP? >>>> >>>> >>>> The m= section will still have completed ICE negotiation, despite >>>> being >>>> marked as inactive. So the address/port information should already be >>>> present. >>> >>> *Why* would you do this if there is no MediaStreamTrack and hence no >>> possibility of using the port? >>> >>> IOW, why not use port zero in these cases? >>> >>>> I don't follow your question about who is managing RTCP. >>> >>> It may be a misunderstanding on my part. >>> >>> My thinking is that the MediaStreamTrack is a surrogate for the >>> resource that manages the RTP/RTCP for that track. If so, then no >>> track -> no RTCP. >>> >>> Of course, with bundling, that resource gets spread across multiple >>> MediaStreamTracks. >> >> That's why thinking of it in the way you suggest is likely to lead to >> misunderstandings and confusion all around. >> >> I've had greater success thinking of a MediaStreamTrack as an SSRC; the >> resource that manages the RTP/RTCP is then a container that contains >> MSTs. > > Isn't that container the PeerConnection? Or are you thinking that the > PeerConnection contains one of these containers for each distinct > RTP-Session? The latter. In other contexts, I've tentatively labelled the container "RTP Transport", since the word "RTP Session" encompasses all the endpoints that participate in a session. "RTP Endpoint" might be accurate, too; it's been a few days since I last looked at the terminology docs. From singer@apple.com Wed Nov 6 22:36:06 2013 Return-Path: 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 4629921E80D5 for ; Wed, 6 Nov 2013 22:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Mt3Ih24RHW81 for ; Wed, 6 Nov 2013 22:35:59 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3698E21E80CA for ; Wed, 6 Nov 2013 22:35:59 -0800 (PST) Received: from relay3.asia.apple.com ( [17.82.200.17]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id CC.DC.03695.DC43B725; Thu, 7 Nov 2013 14:35:57 +0800 (MYT) X-AuditID: 1152fe06-b7f5a6d000000e6f-72-527b34cdc511 Received: from gambooge.asia.apple.com ( [17.82.200.120]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id 0A.4A.26194.DC43B725; Thu, 7 Nov 2013 14:35:57 +0800 (MYT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.83.34.149] (unknown [17.83.34.149]) by mail.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVV00DHARNWAA70@mail.asia.apple.com> for rtcweb@ietf.org; Thu, 07 Nov 2013 14:35:57 +0800 (SGT) From: David Singer In-reply-to: Date: Thu, 07 Nov 2013 15:35:57 +0900 Message-id: <6172AAE4-E59B-4B86-8C0F-DAE5BB2CAF2A@apple.com> References: To: Harald Alvestrand X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUiGHRCUPesSXWQQdMmTYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWn5BdaCFo6K22dOMTUwbmHrYuTkkBAwkXjxsosRwhaTuHBv PVCci0NIYDejxJs3b1hhip5OWwmV6GeS+Hf8JxNIgldAUOLH5HssXYwcHMwC8hIHz8uChJkF tCS+P2plgahfyCSxo/skC0hCWCBa4tfOZ+wgNpuAqsSDOccYQXo5BYIlTr92BAmzAIWPdl1n gZjjInHj1CpWiFU2Et93zmKFmDmZSaLxy32whIiAmsTaKV1Qh8pKnD73HGyxhMBXVomW1tvs ExiFZyG5dRbCrbOQ3LqAkXkVo3huYmaObmaekV5icWaiXmJBQU6qXnJ+7iZGcED/Y9vBuOC1 4SFGAQ5GJR7e2W+LgoRYE8uKK3MPMUpwMCuJ8JobVQcJ8aYkVlalFuXHF5XmpBYfYpTmYFES 5/39tzxISCA9sSQ1OzW1ILUIJsvEwSnVwNjioFIa6XHlwnXehzUpB+em93zJeZKca6rLcMHx GIf3lDczDS/9vvmL6a9mms4P4Q1Ki2xTTm3S9H66QzbPICTl6sVTr20v/fhWuqcvvOBexOfj x633zTV5c/G96SO1qgS1uxmS53f2b778p1Jn8sP37wSu7Vvx+NOhqLCLBU/SNkgxTE1YLpKs xFKckWioxVxUnAgAZvbDI2QCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUiGHSiQvesSXWQweZ+dYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWn5BdaCFo6K22dOMTUwbmHrYuTkkBAwkXg6bSWULSZx4d56 IJuLQ0ign0ni3/GfTCAJXgFBiR+T77F0MXJwMAvISxw8LwsSZhbQkvj+qJUFon4hk8SO7pMs IAlhgWiJXzufsYPYbAKqEg/mHGME6eUUCJY4/doRJMwCFD7adZ0FYo6LxI1Tq1ghVtlIfN85 ixVi5mQmicYv98ESIgJqEmundLFCHCorcfrcc5YJjAKzkJw3C+G8WUjOW8DIvIpRtCg1J7HS WC+xODNRL7GgICdVLzk/dxMjJAAFdzB+mGp4iFGAg1GJh5fpdVGQEGtiWXFl7iFGCQ5mJRFe c6PqICHelMTKqtSi/Pii0pzU4kOM0hwsSuK8sv/Kg4QE0hNLUrNTUwtSi2CyTBycUg2M8YKW J6yars391L7LSEzv9IMAh9aT5hWveRJ90wzb487u2aqs15v57NHM7o31Ox981VZfNvHFu1fG 0Tedjuf2b1P/YDo5+kVmAItb8eJPz8/LHhbY/cR1jWzB3W2rF9x557Ams7PohlpF4IEzfJb7 DPYrspXMKX4UecH0QO8i2/q4h+11ndFflViKMxINtZiLihMBleLy8zwCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 06:36:06 -0000 On Nov 7, 2013, at 15:19 , Harald Alvestrand wrote: > Re performance, and just so that silence isn't taken as me agreeing with David Singer on this topic: > > I haven't wanted to distract from the debate at hand by tossing more numbers around, but we do think VP8 is significantly better than Baseline. The exchanges with Ericsson have shown that we need to be meticulously clear in defining what we mean by that and how we measure it, so I won't post more numbers until I feel that our description is precise enough. I also would like to see some tests which tell us where we really are. A lot of us are engineers who like having facts, even if, as many of us realize, the comparative performance is a minor part of the debate. I welcome Ericsson's efforts to get clarity in this area; they seem to have been working very hard to get a level playing field measure, and if you can help that effort, this would be all to the good. David Singer Multimedia and Software Standards, Apple Inc. From pkyzivat@alum.mit.edu Wed Nov 6 22:42:46 2013 Return-Path: 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 66B1A11E8189 for ; Wed, 6 Nov 2013 22:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 TtQKqfAicw82 for ; Wed, 6 Nov 2013 22:42:41 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 9687211E810B for ; Wed, 6 Nov 2013 22:42:41 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta05.westchester.pa.mail.comcast.net with comcast id mWih1m0021vXlb855Wihtj; Thu, 07 Nov 2013 06:42:41 +0000 Received: from dhcp-9448.meeting.ietf.org ([31.133.148.72]) by omta17.westchester.pa.mail.comcast.net with comcast id mWgY1m00K1ZxU2f3dWgapZ; Thu, 07 Nov 2013 06:40:39 +0000 Message-ID: <527B35E0.7010401@alum.mit.edu> Date: Wed, 06 Nov 2013 22:40:32 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <527420FC.3070805@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net> <527AFF89.3000408@alvestrand.no> In-Reply-To: <527AFF89.3000408@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383806561; bh=0roGbWJbtaaFrb7clfj9pqFvmmffyk25iYP74MvwNnA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rmIsO0ChWBqQi60EBe7Wn+LVLnHik849Dxf68exxsxlEu01fXT+joQc6Hn0Edffec RkE8sj373/mKYHn8wXDzA7KIMGjwnVUvoSrKJ8ALhxne6HymBfTTlKi+s6k7KQbivh Ef9SYAVe8mBp59GTpPTBbxZK6dpmSABKcojm/aH7u3WLyLZORleamR2ePVD4KwPhOL aRUlSNxLkH1z7AWCngd6bdOHlCaEJaGJXE7e213sm7jHJCIyUtpMLTi+aI5tBUfNjM sXGjReddRz3FiSgyAFZgmrFXTcHhVkLGSLRbZ8RTn/cYvzmVOSlwm0i/SWM+8Vs1Lr aTrTRovZGnwcw== Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 06:42:46 -0000 On 11/6/13 6:48 PM, Harald Alvestrand wrote: > On 11/06/2013 11:06 PM, Martin Thomson wrote: >> The question in the room was: >> >> Given a negotiated session with "A, B, and C", is an endpoint >> permitted to create an offer that includes "D"? > > That's not what I heard. > > What I heard was: > > X offers A, B and C (codecs being the canonical example). > Y answers A (only). That means we have agreement to use A only. > X wants to send a new offer. This is a subset of the possible cases. But lets stick with it for the moment. > Three alternatives: > > 1) X MUST offer A, B and C > 2) X MUST offer A (only) if no particular constraint is set, but MUST > offer A, B and C if some (to-be-defined) constraint is set. > 3) X MAY offer A, and MAY offer A, B and C (nondeterministic behaviour) > > I like option 2, for the reasons stated (deterministic, seems to do the > job). SDP O/A recommends an offer that contains A, but allows offering B and C (or D) without A. Of course that could cause a great deal of pain, but maybe X has no choice due to some change of situation. If JSEP wants to restrict to (2) then I don't see that as a problem. (But be prepared for the possibility of *receiving* an offer that doesn't contain A.) But I think it also ought to be possible for the non-default offer to contain A plus anything else. A more complex case is: X offers A, B, C Y answers A, B Then X begins using A, and not using B. When doing next offer, 1) X MUST offer A, B, C 2) X MUST offer A, B 3) X MUST offer A 4..N) X MUST offer one of above by default, but may offer more according to some constraint. (Note that audio easily can result in negotiating two codecs, where one of them is telephone-events.) Thanks, Paul >> A great many people said yes, because that is how SDP is most commonly used. >> >> I agree that not offering A, B or C would be bad. >> >> On 6 November 2013 14:01, Hutton, Andrew wrote: >>> I vote for option 2 – Application controls renegotiation through constraint. >>> >>> >>> >>> Option 1 would be bad. >>> >>> >>> >>> Option 3 would be very bad. >>> >>> >>> >>> Andy >>> >>> >>> >>> >>> >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of >>> Justin Uberti >>> Sent: 06 November 2013 13:37 >>> To: Michael Procter >>> >>> >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers >>> >>> >>> >>> From the room discussion, I sensed 3 possible options to move forward. >>> >>> 1) MUST NOT renegotiate codecs etc. (new PeerConnection if you want to >>> renegotiate) >>> >>> 2) MUST NOT renegotiate codecs etc. by default, but MUST support option to >>> renegotiate (application controls renegotiation through constraint) >>> >>> 3) SHOULD NOT renegotiate codecs etc, but implementation MAY do so if >>> desired (no application logic needed, but non-deterministic API behavior) >>> >>> >>> >>> "etc" here would not include anything that would result in the offer >>> changing from the previously agreed-upon local description, including >>> codecs, RTP header extensions, RTCP feedback mechanisms, BUNDLE groupings, >>> or use of FEC/RTX. >>> >>> >>> >>> I proposed #1 in the room, but see #2 as a reasonable solution. That >>> provides the application with full control over what it wants, as well as >>> deterministic behavior. >>> >>> >>> >>> On Wed, Nov 6, 2013 at 1:29 PM, Justin Uberti wrote: >>> >>> Yes, it would. But I think the problem still exists for applications that >>> don't use partial offer/answers. >>> >>> >>> >>> On Wed, Nov 6, 2013 at 12:47 PM, Michael Procter wrote: >>> >>> On 3 November 2013 22:55, Justin Uberti wrote: >>>> According to section 5.2.5, it seems that this is only the cases for >>>> offers >>>> triggered by offerless reINVITEs. I don't think we want to be >>>> re-allocating >>>> and negotiating codecs every time we want to make a change to the session >>>> descriptions in use. >>> Would the partial offer/answer work address at least part of this? >>> m-lines that you don't want to change wouldn't need to be advertised >>> at all, rather than being advertised with a restricted codec set. >>> >>> Michael >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > From harald@alvestrand.no Wed Nov 6 22:44:06 2013 Return-Path: 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 A4F1621E80D4 for ; Wed, 6 Nov 2013 22:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 sounz9zQ6JIP for ; Wed, 6 Nov 2013 22:44:02 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDA021E80A9 for ; Wed, 6 Nov 2013 22:43:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B0A1B39E05D for ; Thu, 7 Nov 2013 07:43:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7s6260aDO9N for ; Thu, 7 Nov 2013 07:43:44 +0100 (CET) Received: from [31.133.161.198] (dhcp-a1c6.meeting.ietf.org [31.133.161.198]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7A40639E03A for ; Thu, 7 Nov 2013 07:43:44 +0100 (CET) Message-ID: <527B369E.2010601@alvestrand.no> Date: Thu, 07 Nov 2013 07:43:42 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6172AAE4-E59B-4B86-8C0F-DAE5BB2CAF2A@apple.com> In-Reply-To: <6172AAE4-E59B-4B86-8C0F-DAE5BB2CAF2A@apple.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 06:44:06 -0000 On 11/07/2013 07:35 AM, David Singer wrote: > On Nov 7, 2013, at 15:19 , Harald Alvestrand wrote: > >> Re performance, and just so that silence isn't taken as me agreeing with David Singer on this topic: >> >> I haven't wanted to distract from the debate at hand by tossing more numbers around, but we do think VP8 is significantly better than Baseline. The exchanges with Ericsson have shown that we need to be meticulously clear in defining what we mean by that and how we measure it, so I won't post more numbers until I feel that our description is precise enough. > I also would like to see some tests which tell us where we really are. A lot of us are engineers who like having facts, even if, as many of us realize, the comparative performance is a minor part of the debate. > > I welcome Ericsson's efforts to get clarity in this area; they seem to have been working very hard to get a level playing field measure, and if you can help that effort, this would be all to the good. Yes, agreeing on what the word "level" means seems to be a difficult undertaking! The code we're working from lives on this repository: http://git.chromium.org/webm/vpx_codec_comparison.git Ericsson's fork has been posted to the list back in July. > > > David Singer > Multimedia and Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From juberti@google.com Wed Nov 6 23:11:23 2013 Return-Path: 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 437C611E81D3 for ; Wed, 6 Nov 2013 23:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.97 X-Spam-Level: X-Spam-Status: No, score=-0.97 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 lJCcffak1uRi for ; Wed, 6 Nov 2013 23:11:22 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 373B211E810B for ; Wed, 6 Nov 2013 23:11:21 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id tp5so211633ieb.17 for ; Wed, 06 Nov 2013 23:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1v82mrF2pvxYdbcmPshISJ7I8MxuFJ90QcnTwDMRHvs=; b=lzydKnEpDwT1wBBC7lSWbMZkwRqoh5+Xu3gNNZSb+6jwWHuhLkpIp+hWD92byTzixy 5Ms5Jom5jJNSUOgoYliChFUlQwsU4JBBO5Ea09g0PhzYnBrrS5A9SahjUh7PR/6s53G9 FC2RMQTFO9farKedVbKLt6GHwQzvmRZpJ91iKEetQkfZUbmRdjOA8bTwQho9LCcJmmev 6k+7GuQzzIj//2jKTG+nFm1a6uR2qcB02X60k3oAZKEH/z1Fh+otqdXFy7oP9EQ4UJnu sqFaMZqA97pRDohAeM8+F98CafljQ/nKUpt7HHx+Pb1oNNDunehHU5yRFGnl8PtOAkfR 6ZsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1v82mrF2pvxYdbcmPshISJ7I8MxuFJ90QcnTwDMRHvs=; b=WNTx6v6/+2xRp6uPOkVs3qfhUDJwHzGzJsJdvT9+rZNovQ2n5FZNYqgf/zs40ycGO2 DW9NdyxhW0PiZ0YJ0G1ZYXlZwtjIGF6WoKbfeZp+KydrUcoBIeR9ir6C6TgmZ4g1YjUB 3zEKSU5RXHknzgg0JHzf50Aep6NkAYnLRw1x/0IuZ6t4QqvJ1NBBIzky3b/UAT//Zh7v jycS/gEAp1AH7A4sP3hrGmXyeInl3AWZ475pF86nbGN5CIDOIoAifeI2Dqzhkif+G7qN Dul4VM5aSvRWHq9ktVvcaiq272efBlJMQkneKv5hthqyJbAgBLygip06NkMdnGBxvGDu GCOA== X-Gm-Message-State: ALoCoQmn/chspSqhFsOTSOwEUQot1qcQlptNCC0lwsql2VPLqJ986O0JdUy5xC6kete1W1a9MiSmoIzlE2StWlKv4v71pVLXsFqLjHB7P7Po9vemW9z/Ndh8AGN/GdxImsoRf2d+Rgc5y65ubwtAbz+pQxjXxQZdbFFV5bB8JcDYKHD0sFArfBtDHBMDRgWhqQHOum1VJqId X-Received: by 10.42.40.83 with SMTP id k19mr4320737ice.3.1383808281450; Wed, 06 Nov 2013 23:11:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.246.106 with HTTP; Wed, 6 Nov 2013 23:11:01 -0800 (PST) In-Reply-To: <527B35E0.7010401@alum.mit.edu> References: <527420FC.3070805@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net> <527AFF89.3000408@alvestrand.no> <527B35E0.7010401@alum.mit.edu> From: Justin Uberti Date: Wed, 6 Nov 2013 23:11:01 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=90e6ba1efbf40e4aa004ea90f964 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 07:11:23 -0000 --90e6ba1efbf40e4aa004ea90f964 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 6, 2013 at 10:40 PM, Paul Kyzivat wrote= : > On 11/6/13 6:48 PM, Harald Alvestrand wrote: > >> On 11/06/2013 11:06 PM, Martin Thomson wrote: >> >>> The question in the room was: >>> >>> Given a negotiated session with "A, B, and C", is an endpoint >>> permitted to create an offer that includes "D"? >>> >> >> That's not what I heard. >> >> What I heard was: >> >> X offers A, B and C (codecs being the canonical example). >> Y answers A (only). That means we have agreement to use A only. >> X wants to send a new offer. >> > > This is a subset of the possible cases. But lets stick with it for the > moment. > > > Three alternatives: >> >> 1) X MUST offer A, B and C >> 2) X MUST offer A (only) if no particular constraint is set, but MUST >> offer A, B and C if some (to-be-defined) constraint is set. >> 3) X MAY offer A, and MAY offer A, B and C (nondeterministic behaviour) >> >> I like option 2, for the reasons stated (deterministic, seems to do the >> job). >> > > SDP O/A recommends an offer that contains A, but allows offering B and C > (or D) without A. Of course that could cause a great deal of pain, but > maybe X has no choice due to some change of situation. > > If JSEP wants to restrict to (2) then I don't see that as a problem. (But > be prepared for the possibility of *receiving* an offer that doesn't > contain A.) But I think it also ought to be possible for the non-default > offer to contain A plus anything else. > > A more complex case is: > X offers A, B, C > Y answers A, B > > Then X begins using A, and not using B. > When doing next offer, > 1) X MUST offer A, B, C > 2) X MUST offer A, B > 3) X MUST offer A > 4..N) X MUST offer one of above by default, but may offer more according > to some constraint. > > X may be using A in this case, but Y may be using B, so #3 would be bad IMO. (Remember, the reason for the new offer is because some other property of the session changed.) #2 would be the default behavior, and #1 would be the optional behavior that the application could choose. > (Note that audio easily can result in negotiating two codecs, where one o= f > them is telephone-events.) > > Thanks, > Paul > > > A great many people said yes, because that is how SDP is most commonly >>> used. >>> >>> I agree that not offering A, B or C would be bad. >>> >>> On 6 November 2013 14:01, Hutton, Andrew >>> wrote: >>> >>>> I vote for option 2 =E2=80=93 Application controls renegotiation throu= gh >>>> constraint. >>>> >>>> >>>> >>>> Option 1 would be bad. >>>> >>>> >>>> >>>> Option 3 would be very bad. >>>> >>>> >>>> >>>> Andy >>>> >>>> >>>> >>>> >>>> >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of >>>> Justin Uberti >>>> Sent: 06 November 2013 13:37 >>>> To: Michael Procter >>>> >>>> >>>> Cc: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers >>>> >>>> >>>> >>>> From the room discussion, I sensed 3 possible options to move forward= . >>>> >>>> 1) MUST NOT renegotiate codecs etc. (new PeerConnection if you want to >>>> renegotiate) >>>> >>>> 2) MUST NOT renegotiate codecs etc. by default, but MUST support optio= n >>>> to >>>> renegotiate (application controls renegotiation through constraint) >>>> >>>> 3) SHOULD NOT renegotiate codecs etc, but implementation MAY do so if >>>> desired (no application logic needed, but non-deterministic API >>>> behavior) >>>> >>>> >>>> >>>> "etc" here would not include anything that would result in the offer >>>> changing from the previously agreed-upon local description, including >>>> codecs, RTP header extensions, RTCP feedback mechanisms, BUNDLE >>>> groupings, >>>> or use of FEC/RTX. >>>> >>>> >>>> >>>> I proposed #1 in the room, but see #2 as a reasonable solution. That >>>> provides the application with full control over what it wants, as well >>>> as >>>> deterministic behavior. >>>> >>>> >>>> >>>> On Wed, Nov 6, 2013 at 1:29 PM, Justin Uberti >>>> wrote: >>>> >>>> Yes, it would. But I think the problem still exists for applications >>>> that >>>> don't use partial offer/answers. >>>> >>>> >>>> >>>> On Wed, Nov 6, 2013 at 12:47 PM, Michael Procter >>>> wrote: >>>> >>>> On 3 November 2013 22:55, Justin Uberti wrote: >>>> >>>>> According to section 5.2.5, it seems that this is only the cases for >>>>> offers >>>>> triggered by offerless reINVITEs. I don't think we want to be >>>>> re-allocating >>>>> and negotiating codecs every time we want to make a change to the >>>>> session >>>>> descriptions in use. >>>>> >>>> Would the partial offer/answer work address at least part of this? >>>> m-lines that you don't want to change wouldn't need to be advertised >>>> at all, rather than being advertised with a restricted codec set. >>>> >>>> Michael >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > --90e6ba1efbf40e4aa004ea90f964 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 6, 2013 at 10:40 PM, Paul Kyzivat <= ;pkyzivat@alum.m= it.edu> wrote:
On 11/6/13 6:48 PM, Harald= Alvestrand wrote:
On 11/06/2013 11:06 PM, Martin Thomson wrote:
The question in the room was:

Given a negotiated session with "A, B, and C", is an endpoint
permitted to create an offer that includes "D"?

That's not what I heard.

What I heard was:

X offers A, B and C (codecs being the canonical example).
Y answers A (only). That means we have agreement to use A only.
X wants to send a new offer.

This is a subset of the possible cases. But lets stick with it for the mome= nt.


Three alternatives:

1) X MUST offer A, B and C
2) X MUST offer A (only) if no particular constraint is set, but MUST
offer A, B and C if some (to-be-defined) constraint is set.
3) X MAY offer A, and MAY offer A, B and C (nondeterministic behaviour)

I like option 2, for the reasons stated (deterministic, seems to do the
job).

SDP O/A recommends an offer that contains A, but allows offering B and C (o= r D) without A. Of course that could cause a great deal of pain, but maybe = X has no choice due to some change of situation.

If JSEP wants to restrict to (2) then I don't see that as a problem. (B= ut be prepared for the possibility of *receiving* an offer that doesn't= contain A.) But I think it also ought to be possible for the non-default o= ffer to contain A plus anything else.

A more complex case is:
=C2=A0 X offers A, B, C
=C2=A0 Y answers A, B

Then X begins using A, and not using B.
When doing next offer,
1) X MUST offer A, B, C
2) X MUST offer A, B
3) X MUST offer A
4..N) X MUST offer one of above by default, but may offer more according to= some constraint.


X may be using A in this case, but Y m= ay be using B, so #3 would be bad IMO. (Remember, the reason for the new of= fer is because some other property of the session changed.)

#2 would be the default behavior, and #1 would be the option= al behavior that the application could choose.
=C2=A0
(Note that audio easily can result in negotiating two codecs, where one of = them is telephone-events.)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

A great many people said yes, because that is how SDP is most commonly used= .

I agree that not offering A, B or C would be bad.

On 6 November 2013 14:01, Hutton, Andrew <andrew.hutton@unify.com> wrote:
I vote for option 2 =E2=80=93 Application controls renegotiation through co= nstraint.



Option 1 would be bad.



Option 3 would be very bad.



Andy





From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Justin Uberti
Sent: 06 November 2013 13:37
To: Michael Procter


Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers



=C2=A0From the room discussion, I sensed 3 possible options to move forward= .

1) MUST NOT renegotiate codecs etc. (new PeerConnection if you want to
renegotiate)

2) MUST NOT renegotiate codecs etc. by default, but MUST support option to<= br> renegotiate (application controls renegotiation through constraint)

3) SHOULD NOT renegotiate codecs etc, but implementation MAY do so if
desired (no application logic needed, but non-deterministic API behavior)


"etc" here would not include anything that would result in the of= fer
changing from the previously agreed-upon local description, including
codecs, RTP header extensions, RTCP feedback mechanisms, BUNDLE groupings,<= br> or use of FEC/RTX.



I proposed #1 in the room, but see #2 as a reasonable solution. That
provides the application with full control over what it wants, as well as deterministic behavior.



On Wed, Nov 6, 2013 at 1:29 PM, Justin Uberti <juberti@google.com> wrote:

Yes, it would. But I think the problem still exists for applications that don't use partial offer/answers.



On Wed, Nov 6, 2013 at 12:47 PM, Michael Procter <michael@voip.co.uk> wrote:

On 3 November 2013 22:55, Justin Uberti <juberti@google.com> wrote:
According to section 5.2.5, it seems that this is only the cases for
offers
triggered by offerless reINVITEs. I don't think we want to be
re-allocating
and negotiating codecs every time we want to make a change to the session descriptions in use.
Would the partial offer/answer work address at least part of this?
m-lines that you don't want to change wouldn't need to be advertise= d
at all, rather than being advertised with a restricted codec set.

Michael






_______________________________________________
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

--90e6ba1efbf40e4aa004ea90f964-- From gmaxwell@gmail.com Thu Nov 7 01:47:06 2013 Return-Path: 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 AD14A21E819D for ; Thu, 7 Nov 2013 01:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 o9D6e2T-NwPw for ; Thu, 7 Nov 2013 01:47:06 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EC52B21E80F7 for ; Thu, 7 Nov 2013 01:47:02 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id x18so223692lbi.16 for ; Thu, 07 Nov 2013 01:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+4CTRs5YzT4zgvB8fzH9dzilPRtCscZiF1ZxiaX1JHU=; b=mQNx7DTLoP9/4m8N2T8e3VnqyhaNPVzqvELZiLYvKS3RXqrGe5Xa2ixV6xPJTDtKo8 5nic4xFXouKba+5zq1GbURObxxDq3kvGsUJHz6CEMBRQZihiBlOHG2VmG2IbQ2VIVKAz uAW4BKvfVc6lBCMhkZQs4fBesba/O2nsyxuFX8WqWb7rgLl1bxKBdb2TCvPFZn6wwWag kNafKncJr3AReF2fNiyWkkzxKKwYf8u1gCywx3+loRjArfNI4HxpJXwMf6BqMeRIC70q Q8hIKbtSWCljD4ps/bZVhJkiOAekTw1VVBwcDwTsLK0YTkzWy20JtFl9w5Cyc/loW0yW 7NDg== MIME-Version: 1.0 X-Received: by 10.112.13.72 with SMTP id f8mr683475lbc.40.1383817620542; Thu, 07 Nov 2013 01:47:00 -0800 (PST) Sender: gmaxwell@gmail.com Received: by 10.112.63.164 with HTTP; Thu, 7 Nov 2013 01:47:00 -0800 (PST) In-Reply-To: <6172AAE4-E59B-4B86-8C0F-DAE5BB2CAF2A@apple.com> References: <6172AAE4-E59B-4B86-8C0F-DAE5BB2CAF2A@apple.com> Date: Thu, 7 Nov 2013 01:47:00 -0800 X-Google-Sender-Auth: tYDoQPiD6YhnkcwS3y4pT_xg5yk Message-ID: From: Gregory Maxwell To: David Singer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 09:47:06 -0000 On Wed, Nov 6, 2013 at 10:35 PM, David Singer wrote: > On Nov 7, 2013, at 15:19 , Harald Alvestrand wrote: >> Re performance, and just so that silence isn't taken as me agreeing with= David Singer on this topic: >> I haven't wanted to distract from the debate at hand by tossing more num= bers around, but we do think VP8 is significantly better than Baseline. The= exchanges with Ericsson have shown that we need to be meticulously clear i= n defining what we mean by that and how we measure it, so I won't post more= numbers until I feel that our description is precise enough. > > I also would like to see some tests which tell us where we really are. A= lot of us are engineers who like having facts, even if, as many of us real= ize, the comparative performance is a minor part of the debate. > > I welcome Ericsson's efforts to get clarity in this area; they seem to ha= ve been working very hard to get a level playing field measure, and if you = can help that effort, this would be all to the good. Hm. Maybe I'm confused: I thought slide 9 from the H.264 "joint presentation" in Atlanta ( http://tools.ietf.org/agenda/85/slides/slides-85-rtcweb-10.pdf ) showed baseline needing 16% more bitrate than VP8 at the same quality, and the debate was more over high profile and the magnitude of VP8's lead wrt baseline. (And, also in agreement: quality isn't the thing to debate in excruciating detail, but I did think at least this point wasn't controversial. Did I miss a post?) From mail@makk.es Thu Nov 7 03:13:00 2013 Return-Path: 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 8EC0211E80E4 for ; Thu, 7 Nov 2013 03:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=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 6bPhNw-U-6-D for ; Thu, 7 Nov 2013 03:12:55 -0800 (PST) Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id D5D4311E80FE for ; Thu, 7 Nov 2013 03:12:54 -0800 (PST) Received: (qmail 24950 invoked from network); 7 Nov 2013 11:12:50 -0000 Received: from unknown (HELO mail-vc0-x236.google.com) (2607:f8b0:400c:c03::236) by lupus.uberspace.de with SMTP; 7 Nov 2013 11:12:50 -0000 Received: by mail-vc0-f182.google.com with SMTP id if17so247087vcb.41 for ; Thu, 07 Nov 2013 03:12:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X7ZwxHIgZT3OCfjnoYh1QGL/8Xy2BksZ6h56KTY7e3w=; b=eyvDc5cP5H/uTVUiUzHtMyvkMfiPUnGTGPQS+C4Pl7Njn2o69Qvz6V2Uz8xra1TG+n b3/+aXMDwaJ0V3t2ZKZWkyIGN03qB8hZ02Pjg+gy4R/thA5lk1os/LYtpAhViAGAwmlk FfFs/2XqIQxxVNCUYPBzlvo3B1zxT61xCLrBfh3DkK6QmPSbsIPplkWS0u+tW0yZEGpH T35LIuWxC2L3kQV4A8suYD3DCNZEU6cwiPqDfiUe3xjt4tZhEv8+Je2uX9psEBOGycLr J3DwXtSecOgXoY3aOjWJOh7qiOKi/+lWdkhUBXfsAOgtAJVJGhCh6H3LoxlL//grsyVm OVhQ== X-Gm-Message-State: ALoCoQnrlcFJY4fKkJ/8CD64ttKegC4JH0oc+BLHebPLRutxeioEGFAx51y1LMlsEkAlYUrZrwUO MIME-Version: 1.0 X-Received: by 10.221.44.136 with SMTP id ug8mr6320877vcb.13.1383822767410; Thu, 07 Nov 2013 03:12:47 -0800 (PST) Received: by 10.58.172.165 with HTTP; Thu, 7 Nov 2013 03:12:47 -0800 (PST) In-Reply-To: References: <52795BF0.1020207@makk.es> Date: Thu, 7 Nov 2013 12:12:47 +0100 Message-ID: From: Max Jonas Werner To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113378d87bea9804ea945853 Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 11:13:00 -0000 --001a113378d87bea9804ea945853 Content-Type: text/plain; charset=UTF-8 On 7 November 2013 01:37, Martin Thomson wrote: > > That means that an application will be unable to guarantee that a user > is logged in when the call is initiated. The upshot of that is not so > serious as you might think. If I read our current discussions > correctly, we are headed toward a situation where calls can be setup > without the identity mechanisms being complete. (Note to self, > examine trickling identity.) > Interesting. Currently the API spec demands that upon creating offers/answers an identity assertion is requested. Trickling this process would mean re-negotiation of the call using updated offers/answers, right? I wonder how that would improve UX because the user would probably see "identity of your peer is not verified" and some seconds/minutes later "now I got the assertion and verified it". Max --001a113378d87bea9804ea945853 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 7= November 2013 01:37, Martin Thomson <martin.thomson@gmail.com&= gt; wrote:

That means that an application will be unable to guarantee that a user
is logged in when the call is initiated. =C2=A0The upshot of that is not so=
serious as you might think. =C2=A0If I read our current discussions
correctly, we are headed toward a situation where calls can be setup
without the identity mechanisms being complete. =C2=A0(Note to self,
examine trickling identity.)

Interestin= g. Currently the API spec demands that upon creating offers/answers an iden= tity assertion is requested. Trickling this process would mean re-negotiati= on of the call using updated offers/answers, right? I wonder how that would= improve UX because the user would probably see "identity of your peer= is not verified" and some seconds/minutes later "now I got the a= ssertion and verified it".

Max
--001a113378d87bea9804ea945853-- From ron@debian.org Thu Nov 7 04:47:24 2013 Return-Path: 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 EB28121E819D for ; Thu, 7 Nov 2013 04:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, SARE_URI_MEDS=0.842] 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 y07TjSqPlxHl for ; Thu, 7 Nov 2013 04:47:17 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id DE72321E81A6 for ; Thu, 7 Nov 2013 04:46:30 -0800 (PST) Received: from ppp121-45-83-213.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.83.213]) by ipmail06.adl6.internode.on.net with ESMTP; 07 Nov 2013 23:16:15 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 6E3A44F8F3 for ; Thu, 7 Nov 2013 21:57:25 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YiapVzhqQaJg for ; Thu, 7 Nov 2013 21:57:24 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 0A9F34F902; Thu, 7 Nov 2013 21:57:24 +1030 (CST) Date: Thu, 7 Nov 2013 21:57:24 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131107112723.GE3245@audi.shelbyville.oz> References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <527A06EF.2070007@bbs.darktech.org> <527A0C4D.7020707@gmail.com> <527A15A3.2090006@bbs.darktech.org> <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 12:47:24 -0000 On Thu, Nov 07, 2013 at 03:04:06PM +0900, David Singer wrote: > > On Nov 7, 2013, at 5:33 , Mohammed Raad wrote: > > > Hi, > > > > There isn't much new in the arguments for and against VP8 vs H.264. Its > > clear that there are concerns that are beyond how well each codec performs > > and whether or not it is free. Although I recognize that the transcoding > > option does not address the P2P use case, I do think that the goal of > > interoperability can be better achieved through a two phase approach. The > > first is enabling end-points to inter-operate through the availability of > > transcoding from the service provider. The second is to make one of the > > codecs the defacto MTI because of the its higher level of adoption. Yes, we > > may never get to a single MTI if we follow this path but at least we will > > have endpoints inter-operating. Besides, there are multiple other > > difficulties in getting seamless P2P communications working all the time, > > so I would suggest focusing on the service provider centered use case > > first. > > You know, you're right. > > We could suggest or even recommend both, and mandate you must implement at > least one of the two. That would identify precisely two interoperability > points in an otherwise much larger space, at least, and make it fairly simple > for those that can and wish to, to offer transcoding, since the two ends are > now defined. It's not ideal, but it might be better than saying nothing at > all. I thought the performance and other problems with forcing _everyone_ through a central relay server were well known? I would have thought David at least would be somewhat aware of them. Adding that to a guaranteed interop failure outcome might be a cunning plan, but I wouldn't call it a good one. http://arstechnica.com/tech-policy/2013/08/report-after-patent-loss-apple-tweaks-facetime-and-logs-500000-complaints/ The whole point of a MTI codec is there will be no "otherwise larger space" if we choose one that all implementors are free to use. Ron From mohammedsraad@raadtech.com Thu Nov 7 06:01:15 2013 Return-Path: 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 9E3B911E8269 for ; Thu, 7 Nov 2013 06:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_URI_MEDS=0.842] 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 onw5tUz87hmx for ; Thu, 7 Nov 2013 06:01:11 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 37F5511E825E for ; Thu, 7 Nov 2013 06:01:08 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id ey11so642658wid.1 for ; Thu, 07 Nov 2013 06:01:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KQl1tPDiLyzkIBpKH9q7AEBmWrDJF4anQDfiTzkQDDQ=; b=P8SWlckpa+Oi+r22YrFEQOo4KQz/egQhQ5GwPWc55R+EtgmAmVXIeWyuuQVU71cGy7 caKVcdqELIinR8SYqSDGsMWhxqS1K+VdhvGEqalfTROEvvXLgVWUNwkJ9bxDHnZJ8wrA hDusZpCOsTFwbRFME9XMSXbWVvVdEml2e54veeJEAm2CHlaCTOcC0s4j0T/IscgXU96r M1EIHJ/8ZC/Rkm/pQobCJCmmE2DVxGGJgvEmLSZoNv1xyIJNk4wc1MOt2CIIi3BKPnQV H3WlkOLPIhDCPCui1knDqtH3wRVUcjH491dxAeG2V9RmsutuQuwdPtORcBO06Z2fyuTG I9Wg== X-Gm-Message-State: ALoCoQkOx1W0wZeGY0qWh3GlZAoPseoK2wR/VGKbmmsuI6y2avlXWaBTune6fxxHxDUoVhJ0pqV4 MIME-Version: 1.0 X-Received: by 10.180.73.239 with SMTP id o15mr2864388wiv.36.1383832867842; Thu, 07 Nov 2013 06:01:07 -0800 (PST) Received: by 10.194.179.166 with HTTP; Thu, 7 Nov 2013 06:01:07 -0800 (PST) In-Reply-To: <20131107112723.GE3245@audi.shelbyville.oz> References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <527A06EF.2070007@bbs.darktech.org> <527A0C4D.7020707@gmail.com> <527A15A3.2090006@bbs.darktech.org> <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com> <20131107112723.GE3245@audi.shelbyville.oz> Date: Fri, 8 Nov 2013 01:01:07 +1100 Message-ID: From: Mohammed Raad To: Ron Content-Type: multipart/alternative; boundary=f46d0435c0088440a804ea96b2cf Cc: rtcweb@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:01:15 -0000 --f46d0435c0088440a804ea96b2cf Content-Type: text/plain; charset=ISO-8859-1 Hi, If I have understood the content of the story at the link you provided correctly, either you run through (what the story calls) "relay servers" or you are exposed to a large patent licensing fee. Is that a correct understanding? Best Regards, Mohammed On Thu, Nov 7, 2013 at 10:27 PM, Ron wrote: > On Thu, Nov 07, 2013 at 03:04:06PM +0900, David Singer wrote: > > > > On Nov 7, 2013, at 5:33 , Mohammed Raad > wrote: > > > > > Hi, > > > > > > There isn't much new in the arguments for and against VP8 vs H.264. Its > > > clear that there are concerns that are beyond how well each codec > performs > > > and whether or not it is free. Although I recognize that the > transcoding > > > option does not address the P2P use case, I do think that the goal of > > > interoperability can be better achieved through a two phase approach. > The > > > first is enabling end-points to inter-operate through the availability > of > > > transcoding from the service provider. The second is to make one of the > > > codecs the defacto MTI because of the its higher level of adoption. > Yes, we > > > may never get to a single MTI if we follow this path but at least we > will > > > have endpoints inter-operating. Besides, there are multiple other > > > difficulties in getting seamless P2P communications working all the > time, > > > so I would suggest focusing on the service provider centered use case > > > first. > > > > You know, you're right. > > > > We could suggest or even recommend both, and mandate you must implement > at > > least one of the two. That would identify precisely two interoperability > > points in an otherwise much larger space, at least, and make it fairly > simple > > for those that can and wish to, to offer transcoding, since the two ends > are > > now defined. It's not ideal, but it might be better than saying nothing > at > > all. > > I thought the performance and other problems with forcing _everyone_ > through > a central relay server were well known? I would have thought David at > least > would be somewhat aware of them. Adding that to a guaranteed interop > failure > outcome might be a cunning plan, but I wouldn't call it a good one. > > > http://arstechnica.com/tech-policy/2013/08/report-after-patent-loss-apple-tweaks-facetime-and-logs-500000-complaints/ > > The whole point of a MTI codec is there will be no "otherwise larger space" > if we choose one that all implementors are free to use. > > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Mohammed Raad, PhD. Partner RAADTECH CONSULTING P.O. Box 113 Warrawong NSW 2502 Australia Phone: +61 414451478 Email: mohammedsraad@raadtech.com --f46d0435c0088440a804ea96b2cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

If I have understood the content of= the story at the link you provided correctly, either you run through (what= the story calls) "relay servers" or you are exposed to a large p= atent licensing fee. Is that a correct understanding?

Best Regards,
Mohammed


On Thu, Nov 7, 2013 at = 10:27 PM, Ron <ron@debian.org> wrote:
On Thu, Nov 07, 2013 at 03= :04:06PM +0900, David Singer wrote:
>
> On Nov 7, 2013, at 5:33 , Mohammed Raad <mohammedsraad@raadtech.com> wrote:
>
> > Hi,
> >
> > There isn't much new in the arguments for and against VP8 vs = H.264. Its
> > clear that there are concerns that are beyond how well each codec= performs
> > and whether or not it is free. Although I recognize that the tran= scoding
> > option does not address the P2P use case, I do think that the goa= l of
> > interoperability can be better achieved through a two phase appro= ach. The
> > first is enabling end-points to inter-operate through the availab= ility of
> > transcoding from the service provider. The second is to make one = of the
> > codecs the defacto MTI because of the its higher level of adoptio= n. Yes, we
> > may never get to a single MTI if we follow this path but at least= we will
> > have endpoints inter-operating. Besides, there are multiple other=
> > difficulties in getting seamless P2P communications working all t= he time,
> > so I would suggest focusing on the service provider centered use = case
> > first.
>
> You know, you're right.
>
> We could suggest or even recommend both, and mandate you must implemen= t at
> least one of the two. That would identify precisely two interoperabili= ty
> points in an otherwise much larger space, at least, and make it fairly= simple
> for those that can and wish to, to offer transcoding, since the two en= ds are
> now defined. =A0It's not ideal, but it might be better than saying= nothing at
> all.

I thought the performance and other problems with forcing _everyone_ = through
a central relay server were well known? =A0I would have thought David at le= ast
would be somewhat aware of them. =A0Adding that to a guaranteed interop fai= lure
outcome might be a cunning plan, but I wouldn't call it a good one.

ht= tp://arstechnica.com/tech-policy/2013/08/report-after-patent-loss-apple-twe= aks-facetime-and-logs-500000-complaints/

The whole point of a MTI codec is there will be no "otherwise larger s= pace"
if we choose one that all implementors are free to use.

=A0 Ron


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb



--
= Mohammed Raad, PhD.
Partner
RAADTECH CONSULTING
P.O. Box 113
Wa= rrawong
NSW 2502 Australia
Phone: +61 414451478
Email: mohammedsraad@raadtech= .com
--f46d0435c0088440a804ea96b2cf-- From a.badger@gmail.com Thu Nov 7 06:40:14 2013 Return-Path: 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 DAA9D21E81DA for ; Thu, 7 Nov 2013 06:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] 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 PpcUZWnj2t1o for ; Thu, 7 Nov 2013 06:40:14 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEDF21E81E7 for ; Thu, 7 Nov 2013 06:39:02 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id jt11so680587pbb.29 for ; Thu, 07 Nov 2013 06:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=mPY8JzcqecZ08neKiNM4amgyfjaj7s/Iuk+xIbBTUd8=; b=EVsygeUYBKCqHgEk5HxS4Er0drgtujfUVfTOTxu/pzA1Yyixj737+O0+MN3VCxIktY Pmt508tJno+5lORdOk/esCXwvui6c/SXB9u2XPth3VTfX60ESSYzbVCBFreysk+cK7O2 PkXiMKvfI15ZcxVjs0Tloj64IUjQeY6XgVcWpy58BqpAlcWz5+xWDl3dA+fUn+238yMz +HdJetgPpR3ReCXMmEj/fzA4EAuaAMIJalBVasBUOgqLH7Iw4WGlvwv7dB11cDzuowJK tQRI7XP2UxdztnlvJlpPfhS/Y8f57aN1tdvXlxbfrmfzp7W9sW/hUVNu7k7fvvoVkQov LR/w== X-Received: by 10.68.125.226 with SMTP id mt2mr9315849pbb.115.1383835139881; Thu, 07 Nov 2013 06:38:59 -0800 (PST) Received: from unaka.lan ([65.78.164.85]) by mx.google.com with ESMTPSA id hu10sm5525152pbc.11.2013.11.07.06.38.57 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Nov 2013 06:38:58 -0800 (PST) Date: Thu, 7 Nov 2013 06:38:56 -0800 From: Toshio Kuratomi To: David Singer Message-ID: <20131107143856.GD1763@unaka.lan> References: <20131106211149.GA1763@unaka.lan> <4D994310-2825-497D-8337-70BF37282218@apple.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a/RL+Md+4nRpYrpt" Content-Disposition: inline In-Reply-To: <4D994310-2825-497D-8337-70BF37282218@apple.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 14:40:15 -0000 --a/RL+Md+4nRpYrpt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 07, 2013 at 03:00:58PM +0900, David Singer wrote: > Note that you would not have to include it in your distribution; you could > suggest it in your installer, for example, and if the suggestion is taken, > facilitate the install. >=20 Yes we could but... Although that specific strategy wasn't mentioned, the general gist of it would fall in line with the final two paragraphs of the statement. We can institute a number of workarounds to retrieve the code, it puts a number of burdens on us and our users that don't exist for a codec that doesn't have patent concerns. Those burdens and workarounds are something that open source developers and users spend long hours implementing, maintaining, and researching how to use when no alternative exists. In this case, though, an alternative does exist and we would be eager to see that alternative be the route taken. -Toshio >=20 > On Nov 7, 2013, at 6:11 , Toshio Kuratomi wrote: >=20 > >=20 > > Greetings, > >=20 > > I serve on the Engineering Steering Committee for the Fedora Project, a= Linux > > Distribution. A few days ago we were asked if we could give input on > > OpenH264 becoming a MTI codec in the rtcweb standard. We discussed the > > issue at our weekly meeting and agreed on this statement: > >=20 > >=20 > > Fedora is a distribution that cares about software freedom and our users > > freedom. Firstly, we cannot ship binary-only prebuilt software within F= edora. > > This rules out inclusion of OpenH264 binaries direct from Cisco, or oth= er > > providers. Secondly, we cannot ship software built from source which is= not free > > for any use, freely distributable, and free from patent restrictions. > > Therefore, Fedora is similarly unable to ship rebuilt OpenH264 code. > >=20 > > Fedora would be much happier with a non-patent encumbered codec in the = standard > > as it would relieve us of the burden of caring for a codec implementati= on that > > we cannot fix if it is buggy on our platform, let us ship improved or m= ore > > efficient versions of the codec if that is asked for, and relieve us of= the > > burden of making sure all implementors of the standard were using a pro= per > > technique to retrieve the patent-encumbered portion from the internet s= o that > > we weren't shipping non-free code. > >=20 > > Acceptance of an insufficiently-free license of the OpenH264 codec woul= d mean > > that open-source vendors are not able to implement it on their own term= s. They > > must rely on the implementation provided by a third party (Cisco) and c= reate > > workarounds to have the user download that implementation after install= ation, > > increasing the burden on open-source users. This creates an unequal env= ironment > > for open-source vendors. > >=20 > >=20 > > I hope that helps in your decision making. > >=20 > > Thank you for your time, > > Toshio Kuratomi > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > David Singer > Multimedia and Software Standards, Apple Inc. >=20 --a/RL+Md+4nRpYrpt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlJ7pgAACgkQX6yAic2E7kiixgCfeSjmNNBp3L1F9zGwr4dsS9N2 Zi0Anju92kQffIzI/UcOmyDtOIuLWmDu =Y9rN -----END PGP SIGNATURE----- --a/RL+Md+4nRpYrpt-- From cowwoc@bbs.darktech.org Thu Nov 7 06:54:35 2013 Return-Path: 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 872E421E80E8 for ; Thu, 7 Nov 2013 06:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.376 X-Spam-Level: X-Spam-Status: No, score=-4.376 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 B3TmLWgSYfwt for ; Thu, 7 Nov 2013 06:54:31 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 172A621E80B4 for ; Thu, 7 Nov 2013 06:54:30 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id qd12so959953ieb.33 for ; Thu, 07 Nov 2013 06:54:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=NMFk2f7XBSdwF7DzZ1S9LWdL0i+6vua0pYsnStsr5Sw=; b=bo+SO6mzDRiAi/lFcgmloK4xzro/QYYsMKJ9XgnCg82gz1D972nbu/G1TiIOO/2KI9 C6p5CCa5EZWtBC1SrUVnVzzLHDn0PUBFgVQZ/uxOQQnCkQBfS4Jnv12uhtFGBy/h/u/4 yfpgp362XDYh58V5Zf/i5YqsGcafHZrpkG6aeex+GHHSbWDAxLf08bDEm/00d2xFXH1u tbNBoWjF3CbpiKZH5poOz2IOhzzgfEJqAvVjD+Rd8h130Wt0Hax4sQbobfLzwqAEEENj nj3+p2wKoxPjQm/+Jazuzfu13cZkSLsN96J8+rEF1wUkrE9C9DMblMQMS9RGGFKkbQA9 Tafw== X-Gm-Message-State: ALoCoQmk/4Bwr6Fw4o8qeaNpL98KD7PQhMC0GaR40s/gfKBf4QkRWkP+RuHvu26uzlLcHj/7lYYS X-Received: by 10.50.7.101 with SMTP id i5mr2269747iga.48.1383836069671; Thu, 07 Nov 2013 06:54:29 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id k6sm4504719igx.8.2013.11.07.06.54.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 06:54:28 -0800 (PST) Message-ID: <527BA9A3.3080705@bbs.darktech.org> Date: Thu, 07 Nov 2013 09:54:27 -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: rtcweb@ietf.org References: <20131106211149.GA1763@unaka.lan> <20131106214121.GB1763@unaka.lan> <527AC713.2020606@librevideo.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030602070900000200060508" Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 14:54:35 -0000 This is a multi-part message in MIME format. --------------030602070900000200060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Anyone else getting the feeling that we're playing a game of good cop, bad cop? :) Gili On 06/11/2013 7:57 PM, Silvia Pfeiffer wrote: > > I'm very sad to see Nokia exclude themselves from ever making a > business around VP8. It's sad to see a formerly successful technology > company being dismantled by lawyers and desperation. > Silvia. > > On 7 Nov 2013 10:41, > wrote: > > Hi, > > Basil Mohamed Gohar wrote: > > > > VP8 is not encumbered by patents because that patents that are known > > about are granted by Google and via Google's deal with MPEG-LA. > Nokia's > > threats have failed in Germany, so there remains no known > encumbrance > > against VP8. > > > > This is not correct. The Nokia vs. HTC case where three V8 related > patents are included is still very much ongoing. For instance, one > of the three cases has not even been started. There is some > preliminary information about the first two e.g. in [1] and [2], > but also appeals have been made, so the processes are far from > complete. > > Note that there are also three other Nokia patents that were > declared to the IETF which are not covered in the Nokia vs. HTC case. > > The point is that it is definitely too early to make conclusions > (either way). > > [1] > http://www.fosspatents.com/2013/05/german-court-has-apparently-found.html > [2] > http://www.fosspatents.com/2013/08/dutch-appeals-court-sides-with-nokia-in.html > > Markus > _______________________________________________ > 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 --------------030602070900000200060508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    Anyone else getting the feeling that we're playing a game of good cop, bad cop? :)

Gili

On 06/11/2013 7:57 PM, Silvia Pfeiffer wrote:

I'm very sad to see Nokia exclude themselves from ever making a business around VP8. It's sad to see a formerly successful technology company being dismantled by lawyers and desperation.
Silvia.

On 7 Nov 2013 10:41, <Markus.Isomaki@nokia.com> wrote:
Hi,

Basil Mohamed Gohar wrote:
>
> VP8 is not encumbered by patents because that patents that are known
> about are granted by Google and via Google's deal with MPEG-LA.  Nokia's
> threats have failed in Germany, so there remains no known encumbrance
> against VP8.
>

This is not correct. The Nokia vs. HTC case where three V8 related patents are included is still very much ongoing. For instance, one of the three cases has not even been started. There is some preliminary information about the first two e.g. in [1] and [2], but also appeals have been made, so the processes are far from complete.

Note that there are also three other Nokia patents that were declared to the IETF which are not covered in the Nokia vs. HTC case.

The point is that it is definitely too early to make conclusions (either way).

[1] http://www.fosspatents.com/2013/05/german-court-has-apparently-found.html
[2] http://www.fosspatents.com/2013/08/dutch-appeals-court-sides-with-nokia-in.html

Markus
_______________________________________________
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

--------------030602070900000200060508-- From cowwoc@bbs.darktech.org Thu Nov 7 06:56:33 2013 Return-Path: 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 5C8C521E80E8 for ; Thu, 7 Nov 2013 06:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.939 X-Spam-Level: X-Spam-Status: No, score=-3.939 tagged_above=-999 required=5 tests=[AWL=-1.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_MEDS=0.842] 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 S1zA97Sncvba for ; Thu, 7 Nov 2013 06:56:27 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5A86A21E8213 for ; Thu, 7 Nov 2013 06:56:27 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id u16so947656iet.21 for ; Thu, 07 Nov 2013 06:56:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ESXasDyqMooCN0t4v88d/d7byrZfMcsp8HeZBv5FuAg=; b=QnmwAKn4n2pugRTCa0uzT9I0ZdRzprl7MPKzM73THsaG67AoA9VRZlf4lrXxdecYNY YTva4pnS8DDOTmRjlkdajP3S4M5Sb9eH1q4GUvytdTUmI+mwH+QUb+USkEuBilmQHd7s svcdGO5g0B0bKcLi/AuDayJQcBOGjlOJ5LIh8W/TQBUOc5FFiiQcOHLz3gHQx0MmydSr 7f2cldfAelpZidZxI53DWsjZlahUbFjPm1QEQMsImnyrOP+ws1FFLZhupiglO8DOhgZZ FtAnuQVaY/OqqK4W10azOoK5GqeT5GrkJZIJI8jbI7sOXgKapXa+QD4Ql4Lc7kdVVqaH Y5cg== X-Gm-Message-State: ALoCoQnKJI3M2snzawBV3ArDmeSOpYAFbpGgbp5FXVT5tZTgih6Qx3BpNkLqHcBXPbnqbUMQdYnW X-Received: by 10.43.11.69 with SMTP id pd5mr520960icb.62.1383836186457; Thu, 07 Nov 2013 06:56:26 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p5sm4501426igj.10.2013.11.07.06.56.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 06:56:25 -0800 (PST) Message-ID: <527BAA17.40705@bbs.darktech.org> Date: Thu, 07 Nov 2013 09:56:23 -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: rtcweb@ietf.org References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <527A06EF.2070007@bbs.darktech.org> <527A0C4D.7020707@gmail.com> <527A15A3.2090006@bbs.darktech.org> <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com> In-Reply-To: <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:56:33 -0000 On 07/11/2013 1:04 AM, David Singer wrote: > On Nov 7, 2013, at 5:33 , Mohammed Raad wrote: > >> Hi, >> >> There isn't much new in the arguments for and against VP8 vs H.264. Its clear that there are concerns that are beyond how well each codec performs and whether or not it is free. Although I recognize that the transcoding option does not address the P2P use case, I do think that the goal of interoperability can be better achieved through a two phase approach. The first is enabling end-points to inter-operate through the availability of transcoding from the service provider. The second is to make one of the codecs the defacto MTI because of the its higher level of adoption. Yes, we may never get to a single MTI if we follow this path but at least we will have endpoints inter-operating. Besides, there are multiple other difficulties in getting seamless P2P communications working all the time, so I would suggest focusing on the service provider centered use case first. > You know, you're right. > > We could suggest or even recommend both, and mandate you must implement at least one of the two. That would identify precisely two interoperability points in an otherwise much larger space, at least, and make it fairly simple for those that can and wish to, to offer transcoding, since the two ends are now defined. It's not ideal, but it might be better than saying nothing at all. I can't believe you guys are actually trying to convince us that being forced to use a transcoder is actually a *good* thing! Any solution that does not address the P2P use-case is a non-starter. Feel free to use this model in your own deployments, just don't force it on us. Gili From martin.thomson@gmail.com Thu Nov 7 08:32:48 2013 Return-Path: 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 9829821F9A6A for ; Thu, 7 Nov 2013 08:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, 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 7f+O2HbwRTSG for ; Thu, 7 Nov 2013 08:32:48 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id D472221F9A44 for ; Thu, 7 Nov 2013 08:32:47 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id q59so796635wes.9 for ; Thu, 07 Nov 2013 08:32:47 -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=TK+PxaxhGHJyXwZ5sprS0MknC2DSswbvSyWkBdGkqi4=; b=tjK66iDWuHAWq7339CaT3Tuc4l3D0aDTjEyncz00OprK/kfTx6Cc8JMyHPgBODm5fD /BqlDnDktHKLnvB7FJgGgbDt88Xk0XVV//oFQGdtmkzasyAS/qINa4h8ISsRMmDZXI7T 7ZjGu7dX71nNLM/92m2IumyvB6WM/+Ou7+NzUIVTZSNLyzvsa+GiSJ0uOmyR6d3Odk1I WAaHR6Q7V8Fl/nM1uaB4/6aldi/gnF8ndcYSkSIM48REPflMeKxHvdepxiZNTgX3Gafk MSrDOG8uIFTPPc0cqhs97AQ1B5lKtr64BqxSDlE4eiT/AuISadvk2QCR1Kmed7br3kjh SRpg== MIME-Version: 1.0 X-Received: by 10.194.20.170 with SMTP id o10mr8204669wje.4.1383841966935; Thu, 07 Nov 2013 08:32:46 -0800 (PST) Received: by 10.227.202.194 with HTTP; Thu, 7 Nov 2013 08:32:46 -0800 (PST) In-Reply-To: References: <52795BF0.1020207@makk.es> Date: Thu, 7 Nov 2013 08:32:46 -0800 Message-ID: From: Martin Thomson To: Max Jonas Werner Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] usability of IdP concepts in draft-ietf-rtcweb-security-arch-07 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 16:32:48 -0000 On 7 November 2013 03:12, Max Jonas Werner wrote: > I wonder how that would improve UX because the user would probably see > "identity of your peer is not verified" and some seconds/minutes later "now > I got the assertion and verified it". The ability to negotiate codecs and complete ICE are pretty useful. The actual user impact is that the caller sees black until the IdP thing completes, information that an application might choose to suppress. What is interesting is that the called party can actually send AND receive media (though sending depends on gUM), because the calling party will likely have generated an identity assertion. Validation is quick. The problem is that the calling party cannot render it. That leads to a race: signaling of the identity assertion vs the first hello. The good news is that identity can be gotten out of the way prior to call establishment with a data channel setup. From mzanaty@cisco.com Thu Nov 7 08:40:30 2013 Return-Path: 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 B550711E80DC for ; Thu, 7 Nov 2013 08:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 dkZFpSrOl4CB for ; Thu, 7 Nov 2013 08:40:24 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F15B111E81AD for ; Thu, 7 Nov 2013 08:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2367; q=dns/txt; s=iport; t=1383842424; x=1385052024; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PizDwRuneBcHVv7N0i98AMa8hmz4LvGuFYss0uMisvc=; b=fa5EiaR16VPyTOkew4G2fRM2ennXCsS4e4OURMNXeuQJEK9v9lA91OzY DxOESSm5o84ap0oBL4BCyfTCXlMwTfZt/zGgNyjXOAJWUcBwyzG0D2PFP IvLxZP9Q9a2OYIqYEiCWkJ7+tLICS4Xv/0mXhptIMkE139EuDQ/Y4V0sf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAIHBe1KtJXHB/2dsb2JhbABagwc4U75ESoElFnSCJQEBAQICAQEBNzEDCxIBCA4KHjcLJQIEAQ0FCYd4Dbx4jg8RgTkCBYQwA5gMgS+QW4FogT6BcTk X-IronPort-AV: E=Sophos;i="4.93,652,1378857600"; d="scan'208";a="282088978" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 07 Nov 2013 16:40:16 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA7GeG5W031654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 16:40:16 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 10:40:16 -0600 From: "Mo Zanaty (mzanaty)" To: Gregory Maxwell , David Singer Thread-Topic: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 Thread-Index: AQHO29gJj5emc/4RUEOTx5kqzaPd1g== Date: Thu, 7 Nov 2013 16:40:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.236.15] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 16:40:30 -0000 The previous comparisons used poor x264 settings and different rate controls. The latest comparisons used better x264 settings: http://www.ietf.org/mail-archive/web/rtcweb/current/msg09064.html ...and then more similar rate controls: http://www.ietf.org/mail-archive/web/rtcweb/current/msg09126.html In the end, it is a draw, with or without rate control. Which was expected since the actual coding tools are virtually identical. We could have saved a lot of time and posturing if the codec experts on both sides would have just admitted this. Performance is a wash (when ignoring high profile). Mo On 11/7/13, 4:47 AM, Gregory Maxwell wrote: On Wed, Nov 6, 2013 at 10:35 PM, David Singer wrote: > On Nov 7, 2013, at 15:19 , Harald Alvestrand wrote: >> Re performance, and just so that silence isn't taken as me agreeing >>with David Singer on this topic: >> I haven't wanted to distract from the debate at hand by tossing more >>numbers around, but we do think VP8 is significantly better than >>Baseline. The exchanges with Ericsson have shown that we need to be >>meticulously clear in defining what we mean by that and how we measure >>it, so I won't post more numbers until I feel that our description is >>precise enough. > > I also would like to see some tests which tell us where we really are. >A lot of us are engineers who like having facts, even if, as many of us >realize, the comparative performance is a minor part of the debate. > > I welcome Ericsson's efforts to get clarity in this area; they seem to >have been working very hard to get a level playing field measure, and if >you can help that effort, this would be all to the good. Hm. Maybe I'm confused: I thought slide 9 from the H.264 "joint presentation" in Atlanta ( http://tools.ietf.org/agenda/85/slides/slides-85-rtcweb-10.pdf ) showed baseline needing 16% more bitrate than VP8 at the same quality, and the debate was more over high profile and the magnitude of VP8's lead wrt baseline. (And, also in agreement: quality isn't the thing to debate in excruciating detail, but I did think at least this point wasn't controversial. Did I miss a post?) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From bo.burman@ericsson.com Thu Nov 7 09:13:12 2013 Return-Path: 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 07A1711E8188 for ; Thu, 7 Nov 2013 09:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.847 X-Spam-Level: X-Spam-Status: No, score=-3.847 tagged_above=-999 required=5 tests=[AWL=-1.248, BAYES_00=-2.599] 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 aNYkt4dVijeF for ; Thu, 7 Nov 2013 09:13:05 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6AC11E81E6 for ; Thu, 7 Nov 2013 09:12:58 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-d5-527bca19f4b5 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 64.28.27941.91ACB725; Thu, 7 Nov 2013 18:12:57 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.4]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Thu, 7 Nov 2013 18:12:56 +0100 From: Bo Burman To: "Mo Zanaty (mzanaty)" , Gregory Maxwell , David Singer Thread-Topic: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 Thread-Index: AQHO17c3PqvqQ+r03EOU8JzVggQ6A5oZP8KAgAACwoCAAASFgIAANWEAgABzdYCAABkcAA== Date: Thu, 7 Nov 2013 17:12:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvja7kqeogg9krTS1W7ZKwOHHjNLPF iwdzmCzW/mtnt5jf/5HFgdVj68kfbB5Tfm9k9ViwqdRjyZKfTB7/zvazBbBGcdmkpOZklqUW 6dslcGXsW7KaqWChQsW6yUoNjIekuhg5OSQETCTeLP3ACGGLSVy4t56ti5GLQ0jgCKPE9pnv mCCchYwSSyffZAGpYhPQkJi/4y5Yh4hAocSx88vZQGxmAW+JvWe+M3cxcnAIC0RL3GjIhiiJ kTh89jkbhB0mcfTMc2YQm0VAReLxy49gY3gFfCVapz4BqxESKJWY/OclE4jNKaAvseHDW7B6 RgFZifvf77FArBKXuPVkPhPE0QISS/acZ4awRSVePv7HCmErSaw9vB2qXkdiwe5PUGdqSyxb +JoZYq+gxMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDIsoqRozi1OCk33chgEyMwtg5u+W2xg/Hy X5tDjNIcLErivB/fOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJR/eiQ5+Oi5PgXVjDNl 3CUMvO9SzAOqmy6kvLpt//n2paSJaa/7X1pEvFb3mDVZ1ePCyc/H8qNSUw8lxwlE/VCUj4k0 eOz7YuPGk/bGe6/lyweZ2hTPWSfZUBddyTopUljQTmOqF8uRHVYFD999UDN2TVbL7fy2xVal mullAq9iJWvpnBMZSizFGYmGWsxFxYkA/A9GkXsCAAA= Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 17:13:12 -0000 Agree. Some previous tests between VP8 and H.264, like the one from the Atlanta pr= esentation, have included a rate controller which does something similar to= QP-toggling for VP8 but not for H.264. About two weeks ago we sent out a m= odified test where both codecs are allowed to QP-toggle, and that resulted = in no difference between H.264 baseline and VP8 (http://www.ietf.org/mail-a= rchive/web/rtcweb/current/msg09126.html). A more detailed analysis on the p= roblems of previous tests can be found in http://www.ietf.org/mail-archive/= web/rtcweb/current/msg09064.html. The result of no difference between H.264= baseline and VP8 is also consistent with the fixed QP test results we had = published earlier (http://www.ietf.org/mail-archive/web/rtcweb/current/msg0= 8052.html). We have long argued that compression efficiency tests are best = made this way, i.e., without a rate controller, since small changes in the = rate control parameters can have a huge impact on the end result, as the ex= ample of QP-toggling shows.=20 But I fully agree to that quality isn't the thing to debate at the moment. /Bo Burman > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Mo Zanaty (mzanaty) > Sent: den 7 november 2013 08:40 > To: Gregory Maxwell; David Singer > Cc: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we = still prefer VP8 >=20 > The previous comparisons used poor x264 settings and different rate contr= ols. > The latest comparisons used better x264 settings: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09064.html > ...and then more similar rate controls: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09126.html >=20 > In the end, it is a draw, with or without rate control. Which was expecte= d since the actual coding tools are virtually > identical. We could have saved a lot of time and posturing if the codec e= xperts on both sides would have just admitted > this. Performance is a wash (when ignoring high profile). >=20 > Mo >=20 >=20 > On 11/7/13, 4:47 AM, Gregory Maxwell wrote: >=20 > On Wed, Nov 6, 2013 at 10:35 PM, David Singer wrote: > > On Nov 7, 2013, at 15:19 , Harald Alvestrand wrote: > >> Re performance, and just so that silence isn't taken as me agreeing > >>with David Singer on this topic: > >> I haven't wanted to distract from the debate at hand by tossing more > >>numbers around, but we do think VP8 is significantly better than > >>Baseline. The exchanges with Ericsson have shown that we need to be > >>meticulously clear in defining what we mean by that and how we measure > >>it, so I won't post more numbers until I feel that our description is > >>precise enough. > > > > I also would like to see some tests which tell us where we really are. > >A lot of us are engineers who like having facts, even if, as many of us > >realize, the comparative performance is a minor part of the debate. > > > > I welcome Ericsson's efforts to get clarity in this area; they seem to > >have been working very hard to get a level playing field measure, and > >if you can help that effort, this would be all to the good. >=20 > Hm. Maybe I'm confused: I thought slide 9 from the H.264 "joint presenta= tion" in Atlanta ( > http://tools.ietf.org/agenda/85/slides/slides-85-rtcweb-10.pdf ) showed b= aseline needing 16% more bitrate than VP8 at > the same quality, and the debate was more over high profile and the magni= tude of VP8's lead wrt baseline. >=20 > (And, also in agreement: quality isn't the thing to debate in excruciatin= g detail, but I did think at least this point wasn't > controversial. Did I miss a post?) ______________________________________= _________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Thu Nov 7 09:52:28 2013 Return-Path: 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 3157411E81B7 for ; Thu, 7 Nov 2013 09:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, 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 JgMVkE4HO+12 for ; Thu, 7 Nov 2013 09:52:27 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 95D1D21E81EA for ; Thu, 7 Nov 2013 09:52:08 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id f4so1019402wiw.4 for ; Thu, 07 Nov 2013 09:52:03 -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=RTUuruzeMR5SMIEtixvzKmIwwzrMWtNeA/yUX9LX0QM=; b=TUGVJW1/bvPFlwGo1PMKoT9uvgQ9BJ8K6oJoQlFNtMWVvEbDIx51wFssHlm9po1Rw6 5VL/RWgJRiLhtas62Y3oD1eferbDGVqdUyiXBuOSgW9Co6uk1OqMwOmja+ycAv1Lamev HT5cBVtgmgnDDHO/l6PJuRTEwMshlIqtTEmKbFQggS07kuSjGG76GOnZlXFEW4SpOfkl p8IzbcVRyleCvujoRxE2FLiqL80SHrLar7JuX2jpPrMgGl62vQCFNR5NKIZQKbQGvgLw E0IvjS5S0L0Shw1x9PoFdDhKBalVelLwJA9N3k6ZrgfzoQZyzuUcT8Ubnt9UPRqEcI2Q YvkQ== MIME-Version: 1.0 X-Received: by 10.194.58.104 with SMTP id p8mr8550718wjq.1.1383846723741; Thu, 07 Nov 2013 09:52:03 -0800 (PST) Received: by 10.227.202.194 with HTTP; Thu, 7 Nov 2013 09:52:03 -0800 (PST) In-Reply-To: References: <527420FC.3070805@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net> <527AFF89.3000408@alvestrand.no> <527B35E0.7010401@alum.mit.edu> Date: Thu, 7 Nov 2013 09:52:03 -0800 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 17:52:28 -0000 On 6 November 2013 23:11, Justin Uberti wrote: >> >> A more complex case is: >> X offers A, B, C >> Y answers A, B >> >> Then X begins using A, and not using B. >> When doing next offer, >> 1) X MUST offer A, B, C >> 2) X MUST offer A, B >> 3) X MUST offer A >> 4..N) X MUST offer one of above by default, but may offer more according >> to some constraint. >> > > X may be using A in this case, but Y may be using B, so #3 would be bad IMO. > (Remember, the reason for the new offer is because some other property of > the session changed.) > > #2 would be the default behavior, and #1 would be the optional behavior that > the application could choose. Thanks to Paul for the example, and I definitely agree with the requirement that the negotiated (not just in-use) parameters MUST remain. That's a given. My suggestion is that we *don't* add a constraint, we just require the inclusion of everything. If you want to constrain codec use, then you can use the mechanisms that we provide for doing that. Currently, that's editing SDP; though we've talked about specific constraints in the form of { video: { disableCodec: 'VP8' } } or something like that. I don't want to create a special new set of constraints that will effectively never get used. (We do need to be careful about overconstraining implementations by using MUST here. Implementations should be encouraged to offer everything that they can do, but circumstances might change such that even negotiated codecs can become unavailable. Any MUST will need to be modulated.) From stefan.lk.hakansson@ericsson.com Thu Nov 7 10:10:43 2013 Return-Path: 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 CFFD321E818A for ; Thu, 7 Nov 2013 10:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 v8lB+RFFHpVX for ; Thu, 7 Nov 2013 10:10:21 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 727C111E8216 for ; Thu, 7 Nov 2013 10:07:14 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-28-527bd6c3e862 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4D.4C.03802.3C6DB725; Thu, 7 Nov 2013 19:06:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Thu, 7 Nov 2013 19:06:59 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Martin Thomson , Justin Uberti Thread-Topic: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers Thread-Index: AQHO10u5+4jB5R0tEke3keLV47NJvZoUll2AgAQNEACAAAvgAIAAAhoAgAAG1YCAAAFAgIAATuSAgABAxwCAAAiFgIAAsxqAgAAEKwA= Date: Thu, 7 Nov 2013 18:06:58 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3D4EF0@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje7ha9VBBovfGVpsnSpkce3MP0aL tf/a2R2YPXbOusvusWBTqceSJT+ZApijuGxSUnMyy1KL9O0SuDKuHt7CWjBPqOLBjJtsDYyn +LoYOTkkBEwkVl/ZzQRhi0lcuLeerYuRi0NI4BCjxLcnl9ghnMWMEo0P9rCDVLEJBEps3beA DcQWEQiWuHX0LjOIzSygLnFn8TmwGmEBZ4mNZ7cwQ9S4SLQcXA9VXybx4M5vFhCbRUBF4unN d4wgNq+Ar0TPnvdgcU6g+SfuNoHNYQS66PupNUwQ88Ulbj2ZD3WpgMSSPeeZIWxRiZeP/7GC 2KICehKdPx+zQMSVJBbd/gzVqydxY+oUNgjbWuLfi11QN2tLLFv4mhniBkGJkzOfsExgFJ+F ZN0sJO2zkLTPQtI+C0n7AkbWVYzsuYmZOenlRpsYgVF2cMtv1R2Md86JHGKU5mBREuf98NY5 SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjno7/UhlBl92C1kbiKz3XvU6b+i/CYUtQRsXu t3fsKtnsbu/hMP4ruo1/W29I2lf1ZIYXzs6vNJq2XHifs67gjcaetaUF8/9XtStzVD9+kRRU 1rTEtus5V/hzJusQVYtY5nq9Izd5axaczJDWsPa1cFxn/zVrhZj+/KRHdfk215mClt1yTFdi Kc5INNRiLipOBACQNc5ygAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 18:10:43 -0000 On 07/11/13 18:52, "Martin Thomson" wrote: >On 6 November 2013 23:11, Justin Uberti wrote: >>> >>> A more complex case is: >>> X offers A, B, C >>> Y answers A, B >>> >>> Then X begins using A, and not using B. >>> When doing next offer, >>> 1) X MUST offer A, B, C >>> 2) X MUST offer A, B >>> 3) X MUST offer A >>> 4..N) X MUST offer one of above by default, but may offer more >>>according >>> to some constraint. >>> >> >> X may be using A in this case, but Y may be using B, so #3 would be bad >>IMO. >> (Remember, the reason for the new offer is because some other property >>of >> the session changed.) >> >> #2 would be the default behavior, and #1 would be the optional behavior >>that >> the application could choose. > >Thanks to Paul for the example, and I definitely agree with the >requirement that the negotiated (not just in-use) parameters MUST >remain. That's a given. > >My suggestion is that we *don't* add a constraint, we just require the >inclusion of everything. If you want to constrain codec use, then you >can use the mechanisms that we provide for doing that. Currently, >that's editing SDP; though we've talked about specific constraints in >the form of { video: { disableCodec: 'VP8' } } or something like that. At the last WebRTC teleconf we discussed what media transmission related constraints we should have for v1, and the consensus at that meeting was clear: codec selection was not one of them. So if you have to remove codec(s) from the offer that would have to be done by SDP mangling. I guess that I=B9m trying to say that your suggestion is in line with consensus at that meeting at least, and also in line with my personal opinion. > >I don't want to create a special new set of constraints that will >effectively never get used. I agree. > >(We do need to be careful about overconstraining implementations by >using MUST here. Implementations should be encouraged to offer >everything that they can do, but circumstances might change such that >even negotiated codecs can become unavailable. Any MUST will need to >be modulated.) >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Thu Nov 7 10:18:28 2013 Return-Path: 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 4886711E821B for ; Thu, 7 Nov 2013 10:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.556 X-Spam-Level: X-Spam-Status: No, score=-105.556 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 qsTHH5F87mdw for ; Thu, 7 Nov 2013 10:18:21 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1C05721E8173 for ; Thu, 7 Nov 2013 10:16:10 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-7d-527bd8e72ac7 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C5.59.23787.7E8DB725; Thu, 7 Nov 2013 19:16:07 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Thu, 7 Nov 2013 19:16:06 +0100 Message-ID: <527BD94C.2070900@ericsson.com> Date: Thu, 7 Nov 2013 10:17:48 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAJMWRmVeSWpSXmKPExsUyM+Jvje7zG9VBBuc/61us/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK428YL9EhVTW/ewNTCuEuli5OSQEDCReLmjkwXCFpO4cG89 WxcjF4eQwCFGiSNd+9khnGWMEpf+/QWr4hXQlvjV+owNxGYRUJG48HobK4jNJmAhcfNHI1hc VCBY4vyrxewQ9YISJ2c+AesVEVCXuPzwAlCcg0NYQFPiyxMXEFNCQFyipzEIpIJZQE9iytUW RghbXqJ562xmEFsIaGtDUwfrBEb+WUiGzkLSMgtJywJG5lWM7LmJmTnp5YabGIGhdHDLb90d jKfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD48yca8LSQn+2Ks2P yeMoT3uvP3uZRGZS7Dmlno06R6pNm4wmSXfc/O0bfDU66HccC4fuLzs2i47y/I/eLywsVvLx taSlWPTPW+EbWRooFn+1YZHVmf3X42R8rV78evvE6obaMYdPC+8urxfw0JlS7R/Q9NNjmXPh mw6nm0tYTd7OD528sHuhEktxRqKhFnNRcSIA59PoqvMBAAA= Subject: [rtcweb] Proposal for API mapping for RTP X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 18:18:28 -0000 WG, (As draft-ietf-rtcweb-rtp-usage Editor) There was discussion yesterday afternoon on the W3C MediaStream to RTP mapping. This did arrive on some conclusions that I here try to word into a proposal for everyones review. A MediaStreamTrack is sent over a source packet stream (one SSRC) and can have additionally redundancy packet streams (SSRCs). These redundnacy streams are RTP retranmission streams or FEC. When multiple MediaStreamTracks have the same Media Source, then the fact that one has creaeted multiple MediaStreamTracks and added these through a MediaStream to the PeerConnection is going to result in that each MediaStreamTrack will have its own source packet stream (one SSRC). This will be true, even if there are no difference in the configuration of the MediaStreamTrack. Thus no optimizations in regards to collapsing or aggregating multiple MediaStreamTrack onto a single source packet stream (SSRC). This is done for keeping things simple and straightforward. When it comes to the use of CNAME, an RTCWEB end-point shall within the context of one origin, i.e. a particular JS creating PeerConnections, use the same CNAME in all these PeerConnections, for all outgoing mediaStreamTracks. However, a end-point MUST be capable of receiving multiple different CNAMEs both within and between different RTP sessions and PeerConnections. This definition comes from the following observations. A MediaStream contains multiple MediaStreamTrack, and different MediaStreams can share the same MediaStreamTrack. MediaStreamTrack within one MediaStream is synchronized. Thus, at any point the JS application can create a new MediaStream that includes MediaStreamTrack from different context. To avoid needing to change all SSRC and put the SSRCs into a single CNAME at that point, we ensure that this can't happen. MediaStreamTracks that are being received in one PeerConnection and then forward by being added to another one will need to be re-synchronzied into the endpoints outgoing. We discussed and came to the agreement on Monday that forwarding would need to be done equivalent of decoding and recoding when forwarding. Implementations may do other things, but must function equivalent to this. The above have some forward interoperability properties. If one like to be able to use multiple CNAMEs that can be added given that W3C API ensures that you don't cause issue with what CNAME a particular SSRC belongs to. In addition if one like to optimize the cases where multiple MediaStreamTrack have a common media source that can be added. Disagreements, requests for clarifications? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fw@deneb.enyo.de Thu Nov 7 11:30:57 2013 Return-Path: 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 9CE9121E814F for ; Thu, 7 Nov 2013 11:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_05=-1.11, HELO_EQ_DE=0.35] 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 lj11vNuWPCaU for ; Thu, 7 Nov 2013 11:30:51 -0800 (PST) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 001D811E826B for ; Thu, 7 Nov 2013 11:30:45 -0800 (PST) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1VeVHk-0006As-2f for rtcweb@ietf.org; Thu, 07 Nov 2013 20:30:32 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1VeVHj-0004pt-VN for rtcweb@ietf.org; Thu, 07 Nov 2013 20:30:31 +0100 From: Florian Weimer To: rtcweb@ietf.org Date: Thu, 07 Nov 2013 20:30:31 +0100 Message-ID: <87haborovc.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [rtcweb] Current H.264 licensing practice X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 19:30:57 -0000 After reviewing the end-user patent licensing statements regarding H.264/AVC of various products (Microsoft Windows, Adobe Flash, a Canon camera, Skype, and some Cisco manuals), I'm puzzled what the net effect of the Cisco licensing effort will be. The most striking aspect of the current licensing regime is that the existing platform codecs are exclusively licensed for "personal, non-commercial activity". As far as I can tell, this means that I cannot use these codecs to develop my own software and distribute it without a separate MPEG LA license. Furthermore, if I engage in commercial activity involving H.264 streams (such as paid teaching or technical support over Skype, to give an example that seems fairly relevant to me), I need a separate license as well, even if I use already existing software for which the vendor has acquired patent licenses. This even applies to professional video (conferencing) equipment. I wonder what this means in the context of WebRTC. Would web application development be covered? What about commercial use of such web applications? Under the existing licensing practice, the answer appears to be that these activities need separate licenses. To me, that suggests that even after the Cisco effort, H.264 is still not a replacement for a royalty-free codec. Freedom from royalties for browser vendors is not sufficient if (web) application developers and end users do not benefit. (I know that the concrete licensing terms are not published yet, but I find it rather unlikely that Cisco has negotiated a better deal for the non-paying general public than for its own paying customers.) From mzanaty@cisco.com Thu Nov 7 12:33:58 2013 Return-Path: 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 2C8CC21E81C2 for ; Thu, 7 Nov 2013 12:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.485 X-Spam-Level: X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 dRLW9cX4w0gq for ; Thu, 7 Nov 2013 12:33:53 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C1D8F21E81D0 for ; Thu, 7 Nov 2013 12:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10793; q=dns/txt; s=iport; t=1383856432; x=1385066032; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Z9MoZgI3Ew0SToOJmmddMMgdQeeXouoIVDYTZMTLVzc=; b=OhpalsGb6zml6o01vUKVwP3ynj/QNfVINihuJMvRAJ0CrdjdP31TB4wM ANm51QH77gC+z2vFSOUGQ/AP9QgDyrKxHemqLDHBAo7+x3PBSpGoySdGl 8dvAyD0yzr46TaJC80D2/vNCQgyDERqjudZS4CQdl9A3eFqtMNXRJYqhi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJ74e1KtJV2Z/2dsb2JhbABagkNEOFO+REqBJhZ0gicBBAEBAWsLEgEIDjEuCxQRAgQBDQUUB4dmDbx2j1UEB4QwA5gMkgqBaIE+gio X-IronPort-AV: E=Sophos;i="4.93,654,1378857600"; d="scan'208,217";a="282164966" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 07 Nov 2013 20:33:42 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA7KXfHG024139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 20:33:42 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 14:33:41 -0600 From: "Mo Zanaty (mzanaty)" To: Gustavo Garcia , Harald Alvestrand Thread-Topic: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 Thread-Index: AQHO2/ikT5QE5z7i406gT9fvB0QDJw== Date: Thu, 7 Nov 2013 20:33:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.241.11] Content-Type: multipart/alternative; boundary="_000_CEA14C7D1C48Amzanatyciscocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 20:33:58 -0000 --_000_CEA14C7D1C48Amzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The blog makes a good point I would like to highlight and address: "If you want us to get 100% serious about H.264 for WebRTC, why not just ma= ke it free? MPEG-LA, you=92ll get our attention if you declare software im= plementations of H.264 codecs for WebRTC free and clear of royalties." Many (of the ~30) member companies in the MPEG-LA AVC pool agree with this = point and pushed for amendments to the license to make constrained baseline= profile royalty-free. There were a few objections. So the supporting membe= rs took this point directly to MPEG itself (all >200 members), to have a ne= w royalty-free standard called WebVC that is H.264 AVC CBP. This has progre= ssed in MPEG to DIS (Draft Intl Std) status, when IPR declarations are typi= cally made. In short, most MPEG members are not evil, and want the same thing as the op= en source and broader communities, including royalty-free licensing. The Cisco announcement is to remove the dependencies on these MPEG and MPEG= -LA efforts (which would, however, remove the redistribution restrictions t= hat people have rightfully criticized). Mo On 11/5/13, 7:23 PM, Gustavo Garcia >= wrote: +1 H.264 licensing as introduced by Cisco is great because it opens the door t= o truly present H.264 as a viable alternative codec for broad implementatio= n in WebRTC endpoints, but Cisco=92s proposal as it stands is not enough to= warrant H.264 being adopted as an MTI for WebRTC. >From TokBox=92s point of view, WebRTC needs to be able to solve two needs i= f true adoption is intended: 1) supporting interoperability with legacy en= d-points and 2) enabling novel and innovative real-world use-cases on a bro= ad range of software-powered end-points (mobile included, not just browsers= ) The option as proposed with H.264 is not really viable in mobile native app= lications (specifically iOS devices as the situation stands today), whether= both endpoints are mobile native or one is browser-based. At TokBox, we ar= e already seeing a wide range of very interesting applications being built = on top of WebRTC using native mobile apps as one of the endpoints, and the = standard must do the right thing by not preventing these scenarios from pla= ying out. As far as MTI codecs go, we still believe VP8 is the right option and belie= ve H.264 should be embraced as an optional alternative video codec.The purp= ose of the WebRTC is not to create a browser compatible with existing solut= ions (many of which are closed systems) but rather to bring the best possib= le experience to application developers, extending the capabilities of the = web for real-time communication. (More of our views here: http://www.tokbox= .com/blog/is-webrtc-ready-for-h-264/) On Thu, Oct 31, 2013 at 11:47 AM, Harald Alvestrand > wrote: We congratulate Cisco on their intention to make an open source H.264 codec= available and usable by the community. We look forward to seeing the resul= t of this effort. Google still believes that VP8 - a freely available, fully open, high-quali= ty video codec that you can download, compile for your platform, include in= your binary, distribute and put into production today - is the best choice= of a Mandatory to Implement video codec for the WebRTC effort. Harald (sending this from my Google address) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CEA14C7D1C48Amzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4A7A0008213C3C4587BF6C58AF86C782@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
The blog makes a good point I would like to highlight and address:
"If you want us to get 100% serio= us about H.264 for WebRTC, why not just make it free?  MPEG-LA, you=92= ll get our attention if you declare software implementations of H.264 codec= s for WebRTC free and clear of royalties."

Many (of the ~30) member companies in the MPEG-LA AVC pool agree with this = point and pushed for amendments to the license to make constrained baseline= profile royalty-free. There were a few objections. So the supporting membe= rs took this point directly to MPEG itself (all >200 members), to have a new royalty-free standard called W= ebVC that is H.264 AVC CBP. This has progressed in MPEG to DIS (Draft Intl = Std) status, when IPR declarations are typically made.

In short, most MPEG members are not evil, and want the same thing as the op= en source and broader communities, including royalty-free licensing.

The Cisco announcement is to remove the dependencies on these MPEG and MPEG= -LA efforts (which would, however, remove the redistribution restrictions t= hat people have rightfully criticized).

Mo


On 11/5/13, 7:23 PM, Gustavo Garcia <g= gb@tokbox.com> wrote:

+1

H.264 licensing as introduced by Cisco is great because it opens the d= oor to truly present H.264 as a viable alternative codec for broad implemen= tation in WebRTC endpoints, but Cisco=92s proposal as it stands is not enou= gh to warrant H.264 being adopted as an MTI for WebRTC. 

From TokBox=92s point of view, WebRTC needs to be able to solve two ne= eds if true adoption is intended:  1) supporting interoperability with= legacy end-points and 2) enabling novel and innovative real-world use-case= s on a broad range of software-powered end-points (mobile included, not just browsers)

The option as proposed with H.264 is not really viable in mobile nativ= e applications (specifically iOS devices as the situation stands today), wh= ether both endpoints are mobile native or one is browser-based. At TokBox, = we are already seeing a wide range of very interesting applications being built on top of WebRTC using native= mobile apps as one of the endpoints, and the standard must do the right th= ing by not preventing these scenarios from playing out.

As far as MTI codecs go, we still believe VP8 is the right option and = believe H.264 should be embraced as an optional alternative video codec.The= purpose of the WebRTC is not to create a browser compatible with existing = solutions (many of which are closed systems) but rather to bring the best possible experience to application d= evelopers, extending the capabilities of the web for real-time communicatio= n. (More of our views here: http://www.tokbox.com/blog/is-webrtc-ready-for-h-264/)



On Thu, Oct 31, 2013 at 11:47 AM, Harald Alvestr= and <hta@google.com&= gt; wrote:

= We congratulate Cisco on their intention to make an open= source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.


= Google still believes that VP8 - a freely available, ful= ly open, high-quality video codec that you can download, compile for your platform, include in your binary, distr= ibute and put into production today - is the best choice of a Mandatory to = Implement video codec for the WebRTC effort.
Harald (sending this from my Google address)


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


 --_000_CEA14C7D1C48Amzanatyciscocom_-- From xiphmont@gmail.com Thu Nov 7 12:36:43 2013 Return-Path: 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 B45DA21E809F for ; Thu, 7 Nov 2013 12:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, 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 8zxb88RyUmTH for ; Thu, 7 Nov 2013 12:36:42 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 49C2221E81AF for ; Thu, 7 Nov 2013 12:36:42 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id er20so902730lab.34 for ; Thu, 07 Nov 2013 12:36:41 -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=5kDoJ5I3KC6zypfbfeUQPHu+34iY0UZ8whCEBTHagwo=; b=OGrp3qtn5+2BvDgw5diYzSuRRz4QG7hE38fIukyoQ3R7roK8RagigDGPCd0llPZcCH I8iDLaORm/H8x1XUtZXZyZIMCJtsEDheqN7moGtjSeqICFGDccu1u5tcOCMcPsVZ741j aj2VjkR/X2zdouejhEXx+5O/HMZsi8Flw64q0h6Bcyhc0vgB9D5mjtRGgcwSkFLerlCO FA26pSaIZT0RGY42i3Jse26K24zxGXEBipW5XSVUmvCOsZuNib4vy34WIWCgEM33zqKl wTuJSrRmBgPsvnxOOD6d+C/YvzMvOJdcGwW7EQFkafM3Z2DSVboLq3a4h/1+xwphZh0L Un7A== MIME-Version: 1.0 X-Received: by 10.152.27.10 with SMTP id p10mr7668875lag.21.1383856601022; Thu, 07 Nov 2013 12:36:41 -0800 (PST) Received: by 10.112.104.229 with HTTP; Thu, 7 Nov 2013 12:36:40 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Nov 2013 15:36:40 -0500 Message-ID: From: Monty Montgomery To: "Mo Zanaty (mzanaty)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 20:36:43 -0000 > In short, most MPEG members are not evil, and want the same thing as the > open source and broader communities, including royalty-free licensing. I agree, but the structure of the MPEG is such that it only takes one (or a handful). We've heard promises of RF baselines stretching back almost 20 years. I agree this would be a wholly positive development, but frankly... call us when it's done. Monty From hta@google.com Thu Nov 7 13:00:37 2013 Return-Path: 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 54C8D11E81A4 for ; Thu, 7 Nov 2013 13:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 wpFteI9e9FZF for ; Thu, 7 Nov 2013 13:00:33 -0800 (PST) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3E04111E81DA for ; Thu, 7 Nov 2013 13:00:16 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id w20so774863vbb.36 for ; Thu, 07 Nov 2013 13:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=V2ru5uM3Ej94Q+xvqEBHE6GCydiMx6G97H9MvXiVnCw=; b=pMN4wJCPIt1edsS+KgjhNxkCrp9PsjOWqqnnfR+8w0Fv657dghp4UL3Jz7CpWrNTSW MV8NVeH6fBNfKvNJmBNPLuEksuCaz/s+HsCnbIkS8U0M8GoxPbWdCQg9sP60YiXX5jjq /WC7l39vllUQOtf4e/avrXjKKl2eXBukKDtcSIxvdhqWSHMu5YzJBhJyW3Cl+Q8+jk9P mIIYAcFxbWtKkgC0ObcN7i3niLCFnsRwXCIYpAwAjM5TSEoMF7eED60rF/AqryHVG37l U+qd7Wyz341NCSMwLCXBqrBY2MJ72zZg4GJSV9NUQpnQ25Z2he2ohP6Rpfc1u2hG96B9 gGhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V2ru5uM3Ej94Q+xvqEBHE6GCydiMx6G97H9MvXiVnCw=; b=EeE78i+rDFi+ZNzsQArbV1L1g5KXxA7euRULuQd4nej2AY73TGPkx9GPkEdRmkq25h Lm9x6QCQSo220avZWutQqEWm6e/3xM9RcDj2VElLyK9m4V/03f+tNofLaE3JOLj6W7RM +Hl9W2zicywbYMTeZJAeQtVxBB0oaLS1IL4qoFM68XZkOqEcn/xrPVqKDrk9tGJGylad 2URlRLSZbMDECriKVbjhvyZcg+aaNwG0HxOxVF27YaHyKvqOT69hV9a/bb9inyzfLheI 2i5L5g7U6ET8r9zN2jLOH8OmzZkjU/YhOaLUfene5HU93Dh8drbCZZvz3ksPwCbzoUA1 H8Bg== X-Gm-Message-State: ALoCoQmjJqdbDfKBhSl8zO1JBKhu6rgb5t506HP/T5JyC7xRqweY4bbs+t6nO5rAq3oouIjQg55yQL1gC/93Ikqbp3D2NUZHDTO6TlNjzREy7C++eg1JRNt7JSL0NkXsezSNuqzTCCdSVL8U9Cab+GuehwLA2E5yD96GLCCNCsLUohNsS3SXczOJzL0lP1g+OJgMizdzII1+ X-Received: by 10.58.54.69 with SMTP id h5mr8363028vep.25.1383858004951; Thu, 07 Nov 2013 13:00:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.176.8 with HTTP; Thu, 7 Nov 2013 12:59:43 -0800 (PST) In-Reply-To: References: From: Harald Alvestrand Date: Thu, 7 Nov 2013 21:59:43 +0100 Message-ID: To: Monty Montgomery Content-Type: multipart/alternative; boundary=089e013cbbb0ce2ad204ea9c8cf0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 21:00:37 -0000 --089e013cbbb0ce2ad204ea9c8cf0 Content-Type: text/plain; charset=UTF-8 The list of declarations made against the proposed baseline document is available at the bottom of this page: http://www.iso.org/iso/home/standards_development/governance_of_technical_work/patents.htm For declarations against the MPEG baseline proposal, look for the number 14496-29. For some of the declarations, the spreadsheet will tell you whether it's a Type 1 (royalty free) or Type 2 (royalty bearing) declaration. For the 3 most recent declarations in the spreadsheet, you will even find a link to the declaration itself. Draw your own conclusions. On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery wrote: > > In short, most MPEG members are not evil, and want the same thing as the > > open source and broader communities, including royalty-free licensing. > > I agree, but the structure of the MPEG is such that it only takes one > (or a handful). We've heard promises of RF baselines stretching back > almost 20 years. > > I agree this would be a wholly positive development, but frankly... > call us when it's done. > > Monty > --089e013cbbb0ce2ad204ea9c8cf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The list of declarations made against the proposed baselin= e document is available at the bottom of this page:


For declarations against the MPEG baseline propos= al, look for the number 14496-29.

For some of the = declarations, the spreadsheet will tell you whether it's a Type 1 (roya= lty free) or Type 2 (royalty bearing) declaration. For the 3 most recent de= clarations in the spreadsheet, you will even find a link to the declaration= itself.

Draw your own conclusions.



On Thu, Nov 7, = 2013 at 9:36 PM, Monty Montgomery <xiphmont@gmail.com> wrot= e:
> In short, most MPEG m= embers are not evil, and want the same thing as the
> open source and broader communities, including royalty-free licensing.=

I agree, but the structure of the MPEG is such that it only takes one=
(or a handful). =C2=A0We've heard promises of RF baselines stretching b= ack
almost 20 years.

I agree this would be a wholly positive development, but frankly...
call us when it's done.

Monty

--089e013cbbb0ce2ad204ea9c8cf0-- From kolarov@apple.com Thu Nov 7 13:10:36 2013 Return-Path: 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 21D6A11E829B for ; Thu, 7 Nov 2013 13:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 kBWjya9Jhw1B for ; Thu, 7 Nov 2013 13:10:29 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4342711E8291 for ; Thu, 7 Nov 2013 13:10:26 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1Rmefr6Xc9ac2WriGPhl6w)" Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MVW00HRKW48UER1@mail-out.apple.com> for rtcweb@ietf.org; Thu, 07 Nov 2013 13:10:18 -0800 (PST) X-AuditID: 1180715a-b7f3c6d00000020e-6b-527c01b993b4 Received: from [17.197.34.232] (Unknown_Domain [17.197.34.232]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id B0.BC.00526.AB10C725; Thu, 07 Nov 2013 13:10:18 -0800 (PST) From: Krasimir Kolarov In-reply-to: Date: Thu, 07 Nov 2013 13:10:19 -0800 Message-id: References: To: Harald Alvestrand , "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1812) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUieFTphe4uxpogg1f3+S1O3DjNbLH2Xzu7 xdvHnxkdmD12zrrL7rFgU6nHkiU/mQKYo7hsUlJzMstSi/TtErgytvW0shT0alS8b9nL2sC4 WKmLkZNDQsBEom3fVkYIW0ziwr31bCC2kEAvk8TsZwVdjBwczAIJEvd+pIGEeQX0JK483s4C YgsLREpcWnWSGcRmE9CS6LjWA9bKKRAo8W5bKzuIzSKgIjHjeAuYzSygKfH3yxEWiDk2EmdO TGDqYuQCWvWXUeLm9ZdgRSICvhIXW+4yguyVEJCV+HTYbAIj3yyEK2YhuWIW2FRtiWULXzND lOhITF7IiCoMYX88f4RpASPbKkaBotScxEozvcSCgpxUveT83E2MoHBtKIzawdiw3OoQowAH oxIPb8GF6iAh1sSy4srcQ4wSHMxKIrx7vwOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/7eWxUk JJCeWJKanZpakFoEk2Xi4JRqYLRimvtxz6EDNc93RMkqMwW71D15mFtfK2IYllYStaf62Jz1 KbcepnGsSI36Kdq/s0xX7HTRDdNMVb03zD8OCN2esW/f/Zpl3f6714lEvrzP8kSkPPyCT7qq 6lS9cK7IGabBtzYX69+odP7H+vPnNHXvmcuWTDvwb94+z6VFJYLbT//1L5P7IqnEUpyRaKjF XFScCABIihdBUwIAAA== Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 21:10:36 -0000 --Boundary_(ID_1Rmefr6Xc9ac2WriGPhl6w) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT One interesting observation from the database is that one of the most recent Type 2 (royalty bearing) declarations on the list is from a major proponent of Royalty Free coding - Motorola Mobility (which is now fully owned by Google). It looks like a compelling strategy - to offer technology that you support for Royalty Free adoption, while blocking a competing technology with a Type 2 declaration. Krasimir On Nov 7, 2013, at 12:59 PM, Harald Alvestrand wrote: > The list of declarations made against the proposed baseline document is available at the bottom of this page: > > http://www.iso.org/iso/home/standards_development/governance_of_technical_work/patents.htm > > For declarations against the MPEG baseline proposal, look for the number 14496-29. > > For some of the declarations, the spreadsheet will tell you whether it's a Type 1 (royalty free) or Type 2 (royalty bearing) declaration. For the 3 most recent declarations in the spreadsheet, you will even find a link to the declaration itself. > > Draw your own conclusions. > > > > On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery wrote: > > In short, most MPEG members are not evil, and want the same thing as the > > open source and broader communities, including royalty-free licensing. > > I agree, but the structure of the MPEG is such that it only takes one > (or a handful). We've heard promises of RF baselines stretching back > almost 20 years. > > I agree this would be a wholly positive development, but frankly... > call us when it's done. > > Monty > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Boundary_(ID_1Rmefr6Xc9ac2WriGPhl6w) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable One = interesting observation from the database is that one of the most recent = Type 2 (royalty bearing) declarations on the list is from a major = proponent of Royalty Free coding - Motorola Mobility (which is now fully = owned by Google).

It looks like a compelling strategy = - to offer technology that you support for Royalty Free adoption, while = blocking a competing technology with a Type 2 = declaration.

Krasimir

On = Nov 7, 2013, at 12:59 PM, Harald Alvestrand <hta@google.com> wrote:

The list of declarations made against the proposed baseline = document is available at the bottom of this page:


For declarations against the MPEG baseline = proposal, look for the number 14496-29.

For = some of the declarations, the spreadsheet will tell you whether it's a = Type 1 (royalty free) or Type 2 (royalty bearing) declaration. For the 3 = most recent declarations in the spreadsheet, you will even find a link = to the declaration itself.

Draw your own = conclusions.



On Thu, Nov 7, = 2013 at 9:36 PM, Monty Montgomery <xiphmont@gmail.com> wrote:
> = In short, most MPEG members are not evil, and want the same thing as = the
> open source and broader communities, including royalty-free = licensing.

I agree, but the structure of the MPEG is such that it only takes = one
(or a handful).  We've heard promises of RF baselines stretching = back
almost 20 years.

I agree this would be a wholly positive development, but frankly...
call us when it's done.

Monty

_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

= --Boundary_(ID_1Rmefr6Xc9ac2WriGPhl6w)-- From cowwoc@bbs.darktech.org Thu Nov 7 13:13:53 2013 Return-Path: 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 0C18221E80FE for ; Thu, 7 Nov 2013 13:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.334 X-Spam-Level: X-Spam-Status: No, score=-4.334 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 hR+XZMtGM8tR for ; Thu, 7 Nov 2013 13:13:48 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE8321E8092 for ; Thu, 7 Nov 2013 13:13:48 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id e14so1805060iej.22 for ; Thu, 07 Nov 2013 13:13:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=ea5w1QsZbCYQlmEEl7uHVcGM2VMRd5nUbx8ylTa11kg=; b=hI1A3zLVxbmZ85dwtr/INB1/MsKDILYGeqykU45rUrEo9tckdnVGDldImMDY0gqTll p2ciHcMrHK3zcjfpAoCul589JtSUkb3YfDqznyKCVLcDA8V/3IETdU1gjAvgW2EzY2Ks B+gyo3gy4eU/meTr84CZFBR0dI0xGdUDlSKHaKD20H+yyVmHnEQOhKTZOYH9y1T0cG8a shU2Hl28yW+toZQ6YRsvl8i2shgBrb1dFfpEeEcv9zWcF4rtYHOtEa2dx2EnJGu54AYt g/ll0GRre+WZBOlyrZGgiLtwCUbGhZRiTrWmwipwsikLkd7kqBuvqjekMIGDhQ7laILs XUYA== X-Gm-Message-State: ALoCoQnlBwMU9E1Vdlf89aLhWgeyXp+U4p4dDU2RAbPl4RF7jRSLnBgZcEPdMugRqrHB+ugIfj7G X-Received: by 10.42.240.133 with SMTP id la5mr17377icb.78.1383858826992; Thu, 07 Nov 2013 13:13:46 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id cl4sm155607igc.1.2013.11.07.13.13.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 13:13:46 -0800 (PST) Message-ID: <527C0287.5080009@bbs.darktech.org> Date: Thu, 07 Nov 2013 16:13:43 -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: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070703080301060407090305" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 21:13:53 -0000 This is a multi-part message in MIME format. --------------070703080301060407090305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Are you implying that Google made this move *after* purchasing Motorola? If not, your statement sounds factually incorrect. Gili On 07/11/2013 4:10 PM, Krasimir Kolarov wrote: > One interesting observation from the database is that one of the most > recent Type 2 (royalty bearing) declarations on the list is from a > major proponent of Royalty Free coding - Motorola Mobility (which is > now fully owned by Google). > > It looks like a compelling strategy - to offer technology that you > support for Royalty Free adoption, while blocking a competing > technology with a Type 2 declaration. > > Krasimir > > On Nov 7, 2013, at 12:59 PM, Harald Alvestrand > wrote: > >> The list of declarations made against the proposed baseline document >> is available at the bottom of this page: >> >> http://www.iso.org/iso/home/standards_development/governance_of_technical_work/patents.htm >> >> For declarations against the MPEG baseline proposal, look for the >> number 14496-29. >> >> For some of the declarations, the spreadsheet will tell you whether >> it's a Type 1 (royalty free) or Type 2 (royalty bearing) declaration. >> For the 3 most recent declarations in the spreadsheet, you will even >> find a link to the declaration itself. >> >> Draw your own conclusions. >> >> >> >> On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery > > wrote: >> >> > In short, most MPEG members are not evil, and want the same >> thing as the >> > open source and broader communities, including royalty-free >> licensing. >> >> I agree, but the structure of the MPEG is such that it only takes one >> (or a handful). We've heard promises of RF baselines stretching back >> almost 20 years. >> >> I agree this would be a wholly positive development, but frankly... >> call us when it's done. >> >> Monty >> >> >> _______________________________________________ >> 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 --------------070703080301060407090305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    Are you implying that Google made this move *after* purchasing Motorola? If not, your statement sounds factually incorrect.

Gili

On 07/11/2013 4:10 PM, Krasimir Kolarov wrote:
One interesting observation from the database is that one of the most recent Type 2 (royalty bearing) declarations on the list is from a major proponent of Royalty Free coding - Motorola Mobility (which is now fully owned by Google).

It looks like a compelling strategy - to offer technology that you support for Royalty Free adoption, while blocking a competing technology with a Type 2 declaration.

Krasimir

On Nov 7, 2013, at 12:59 PM, Harald Alvestrand <hta@google.com> wrote:

The list of declarations made against the proposed baseline document is available at the bottom of this page:


For declarations against the MPEG baseline proposal, look for the number 14496-29.

For some of the declarations, the spreadsheet will tell you whether it's a Type 1 (royalty free) or Type 2 (royalty bearing) declaration. For the 3 most recent declarations in the spreadsheet, you will even find a link to the declaration itself.

Draw your own conclusions.



On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery <xiphmont@gmail.com> wrote:
> In short, most MPEG members are not evil, and want the same thing as the
> open source and broader communities, including royalty-free licensing.

I agree, but the structure of the MPEG is such that it only takes one
(or a handful).  We've heard promises of RF baselines stretching back
almost 20 years.

I agree this would be a wholly positive development, but frankly...
call us when it's done.

Monty

_______________________________________________
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

--------------070703080301060407090305-- From kolarov@apple.com Thu Nov 7 13:16:19 2013 Return-Path: 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 33E1221E81E5 for ; Thu, 7 Nov 2013 13:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Ca0ud3MQnuEO for ; Thu, 7 Nov 2013 13:16:11 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 595C421E8092 for ; Thu, 7 Nov 2013 13:16:10 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gtJbsTSfNCe/YLGfWfUe9g)" Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MVW00C89WCJCJL2@mail-out.apple.com> for rtcweb@ietf.org; Thu, 07 Nov 2013 13:16:06 -0800 (PST) X-AuditID: 11807153-b7f246d000005e2f-e8-527c0315c69d Received: from [17.197.34.232] (Unknown_Domain [17.197.34.232]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 31.26.24111.5130C725; Thu, 07 Nov 2013 13:16:05 -0800 (PST) From: Krasimir Kolarov In-reply-to: <527C0287.5080009@bbs.darktech.org> Date: Thu, 07 Nov 2013 13:16:06 -0800 Message-id: <0D113D9F-4293-4B7C-ADC8-E0DA48929941@apple.com> References: <527C0287.5080009@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1812) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUieFTpha4oc02QwZETOhZnbv5nt1j7r53d gcnjyYTp7B5LlvxkCmCK4rJJSc3JLEst0rdL4MqY8bmBtWCvc0Xfqd3MDYwHjboYOTkkBEwk Ht9qY4WwxSQu3FvPBmILCfQyScx6CVbDLJAgce1+IzOIzSugJ3Hl8XYWEFtYIFLi0qqTYHE2 AS2Jjms9QL0cHJwCBhL3mgRAwiwCKhJzJlxghBgjLPH98T0WiDE2El8vPWDvYuQCWnWJSeLp 9wdgRSJADTeO3WIHmSMhICvx6bDZBEa+WUiumIXkCoi4tsSyha+ZIWw9iZdN79ghbHmJ7W/n QMV1JS6um8S4gJFtFaNAUWpOYqWxXmJBQU6qXnJ+7iZGUIA2FAbvYPyzzOoQowAHoxIPb8GF 6iAh1sSy4srcQ4wSHMxKIrx7vwOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/7aWxUkJJCeWJKa nZpakFoEk2Xi4JRqYNxwcdJuY0alJjuXk8EPl12MW5tcYHZjxwXW308v5y0M4twVUNeZnu18 4d1jaZ9jjcuXCDwUNtV0uRnqa+L79cT9E98jZT4tlN4qfs379OyD39JmSLiuOC0VMaHM7thR TbMd3Vn9ISvUD3I2yL6T3Ji45zrDlkundvyKWXrEIkxIP+1oZ//pmdeUWIozEg21mIuKEwGe qQ0VTAIAAA== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 21:16:19 -0000 --Boundary_(ID_gtJbsTSfNCe/YLGfWfUe9g) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT The date of the declaration can be seen clearly in the database - August 5, 2013 On Nov 7, 2013, at 1:13 PM, cowwoc wrote: > > Are you implying that Google made this move *after* purchasing Motorola? If not, your statement sounds factually incorrect. > > Gili > > On 07/11/2013 4:10 PM, Krasimir Kolarov wrote: >> One interesting observation from the database is that one of the most recent Type 2 (royalty bearing) declarations on the list is from a major proponent of Royalty Free coding - Motorola Mobility (which is now fully owned by Google). >> >> It looks like a compelling strategy - to offer technology that you support for Royalty Free adoption, while blocking a competing technology with a Type 2 declaration. >> >> Krasimir >> >> On Nov 7, 2013, at 12:59 PM, Harald Alvestrand wrote: >> >>> The list of declarations made against the proposed baseline document is available at the bottom of this page: >>> >>> http://www.iso.org/iso/home/standards_development/governance_of_technical_work/patents.htm >>> >>> For declarations against the MPEG baseline proposal, look for the number 14496-29. >>> >>> For some of the declarations, the spreadsheet will tell you whether it's a Type 1 (royalty free) or Type 2 (royalty bearing) declaration. For the 3 most recent declarations in the spreadsheet, you will even find a link to the declaration itself. >>> >>> Draw your own conclusions. >>> >>> >>> >>> On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery wrote: >>> > In short, most MPEG members are not evil, and want the same thing as the >>> > open source and broader communities, including royalty-free licensing. >>> >>> I agree, but the structure of the MPEG is such that it only takes one >>> (or a handful). We've heard promises of RF baselines stretching back >>> almost 20 years. >>> >>> I agree this would be a wholly positive development, but frankly... >>> call us when it's done. >>> >>> Monty >>> >>> _______________________________________________ >>> 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 --Boundary_(ID_gtJbsTSfNCe/YLGfWfUe9g) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT The date of the declaration can be seen clearly in the database - August 5, 2013


On Nov 7, 2013, at 1:13 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:


    Are you implying that Google made this move *after* purchasing Motorola? If not, your statement sounds factually incorrect.

Gili

On 07/11/2013 4:10 PM, Krasimir Kolarov wrote:
One interesting observation from the database is that one of the most recent Type 2 (royalty bearing) declarations on the list is from a major proponent of Royalty Free coding - Motorola Mobility (which is now fully owned by Google).

It looks like a compelling strategy - to offer technology that you support for Royalty Free adoption, while blocking a competing technology with a Type 2 declaration.

Krasimir

On Nov 7, 2013, at 12:59 PM, Harald Alvestrand <hta@google.com> wrote:

The list of declarations made against the proposed baseline document is available at the bottom of this page:


For declarations against the MPEG baseline proposal, look for the number 14496-29.

For some of the declarations, the spreadsheet will tell you whether it's a Type 1 (royalty free) or Type 2 (royalty bearing) declaration. For the 3 most recent declarations in the spreadsheet, you will even find a link to the declaration itself.

Draw your own conclusions.



On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery <xiphmont@gmail.com> wrote:
> In short, most MPEG members are not evil, and want the same thing as the
> open source and broader communities, including royalty-free licensing.

I agree, but the structure of the MPEG is such that it only takes one
(or a handful).  We've heard promises of RF baselines stretching back
almost 20 years.

I agree this would be a wholly positive development, but frankly...
call us when it's done.

Monty

_______________________________________________
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

--Boundary_(ID_gtJbsTSfNCe/YLGfWfUe9g)-- From cowwoc@bbs.darktech.org Thu Nov 7 13:17:45 2013 Return-Path: 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 D286E21E8200 for ; Thu, 7 Nov 2013 13:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 gWXuwyZSF6+U for ; Thu, 7 Nov 2013 13:17:34 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE3B21E8196 for ; Thu, 7 Nov 2013 13:17:11 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so1890082iet.32 for ; Thu, 07 Nov 2013 13:17:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=kR4tUDHJzphQuvipol3hhFYOan/lUnPfObk3jVj6pPM=; b=gx16L/m3qk2/ijOmMxA36mFvYhc1QnL9Un9VdyYdiH4+3YJDKe+aqag/KyDO//Nj9g shBBNtsnZzZMa4+UqZKCmxvq+AUDChrtGSotSuJbjMnE6HKj0pkKLWvAdpKI4/2Sd3+V bJXiVTnewn38o3zKULU+7m91O246ZckcSwonxMhrIyWGaRZ49oc3pff8SAS+I3KArXBA 6ycFqBdKCVzoSuebFNaDt7edC6Z/NgjZAZIUrPRMEC7sMHBR3nCq73ggGZHV26DDEDMy h71mKPVAnU15BcHCc6+edPBG5ejxhwmyjySmTRDuDPcO60oM6RQPYsv0WtDNjYjFFsiG rnFQ== X-Gm-Message-State: ALoCoQnL7g3TFOiUZnai7j3fTe45cKXc5g5iuUwtgXG1ssgFWgT5vQS1cVqx5SpI6kG54JLsn/BP X-Received: by 10.50.56.44 with SMTP id x12mr3571113igp.41.1383859023941; Thu, 07 Nov 2013 13:17:03 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f19sm6258430igz.1.2013.11.07.13.17.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 13:17:03 -0800 (PST) Message-ID: <527C034D.6080204@bbs.darktech.org> Date: Thu, 07 Nov 2013 16:17:01 -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: Krasimir Kolarov References: <527C0287.5080009@bbs.darktech.org> <0D113D9F-4293-4B7C-ADC8-E0DA48929941@apple.com> In-Reply-To: <0D113D9F-4293-4B7C-ADC8-E0DA48929941@apple.com> Content-Type: multipart/alternative; boundary="------------020102000101000402050209" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 21:17:45 -0000 This is a multi-part message in MIME format. --------------020102000101000402050209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I stand corrected. Thanks for pointing this out. Gili On 07/11/2013 4:16 PM, Krasimir Kolarov wrote: > The date of the declaration can be seen clearly in the database - > August 5, 2013 > > > On Nov 7, 2013, at 1:13 PM, cowwoc > wrote: > >> >> Are you implying that Google made this move *after* purchasing >> Motorola? If not, your statement sounds factually incorrect. >> >> Gili >> >> On 07/11/2013 4:10 PM, Krasimir Kolarov wrote: >>> One interesting observation from the database is that one of the >>> most recent Type 2 (royalty bearing) declarations on the list is >>> from a major proponent of Royalty Free coding - Motorola Mobility >>> (which is now fully owned by Google). >>> >>> It looks like a compelling strategy - to offer technology that you >>> support for Royalty Free adoption, while blocking a competing >>> technology with a Type 2 declaration. >>> >>> Krasimir >>> >>> On Nov 7, 2013, at 12:59 PM, Harald Alvestrand >> > wrote: >>> >>>> The list of declarations made against the proposed baseline >>>> document is available at the bottom of this page: >>>> >>>> http://www.iso.org/iso/home/standards_development/governance_of_technical_work/patents.htm >>>> >>>> For declarations against the MPEG baseline proposal, look for the >>>> number 14496-29. >>>> >>>> For some of the declarations, the spreadsheet will tell you whether >>>> it's a Type 1 (royalty free) or Type 2 (royalty bearing) >>>> declaration. For the 3 most recent declarations in the spreadsheet, >>>> you will even find a link to the declaration itself. >>>> >>>> Draw your own conclusions. >>>> >>>> >>>> >>>> On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery >>>> > wrote: >>>> >>>> > In short, most MPEG members are not evil, and want the same >>>> thing as the >>>> > open source and broader communities, including royalty-free >>>> licensing. >>>> >>>> I agree, but the structure of the MPEG is such that it only >>>> takes one >>>> (or a handful). We've heard promises of RF baselines >>>> stretching back >>>> almost 20 years. >>>> >>>> I agree this would be a wholly positive development, but frankly... >>>> call us when it's done. >>>> >>>> Monty >>>> >>>> >>>> _______________________________________________ >>>> 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 > --------------020102000101000402050209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

    I stand corrected. Thanks for pointing this out.

Gili

On 07/11/2013 4:16 PM, Krasimir Kolarov wrote:
The date of the declaration can be seen clearly in the database - August 5, 2013


On Nov 7, 2013, at 1:13 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:


    Are you implying that Google made this move *after* purchasing Motorola? If not, your statement sounds factually incorrect.

Gili

On 07/11/2013 4:10 PM, Krasimir Kolarov wrote:
One interesting observation from the database is that one of the most recent Type 2 (royalty bearing) declarations on the list is from a major proponent of Royalty Free coding - Motorola Mobility (which is now fully owned by Google).

It looks like a compelling strategy - to offer technology that you support for Royalty Free adoption, while blocking a competing technology with a Type 2 declaration.

Krasimir

On Nov 7, 2013, at 12:59 PM, Harald Alvestrand <hta@google.com> wrote:

The list of declarations made against the proposed baseline document is available at the bottom of this page:


For declarations against the MPEG baseline proposal, look for the number 14496-29.

For some of the declarations, the spreadsheet will tell you whether it's a Type 1 (royalty free) or Type 2 (royalty bearing) declaration. For the 3 most recent declarations in the spreadsheet, you will even find a link to the declaration itself.

Draw your own conclusions.



On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery <xiphmont@gmail.com> wrote:
> In short, most MPEG members are not evil, and want the same thing as the
> open source and broader communities, including royalty-free licensing.

I agree, but the structure of the MPEG is such that it only takes one
(or a handful).  We've heard promises of RF baselines stretching back
almost 20 years.

I agree this would be a wholly positive development, but frankly...
call us when it's done.

Monty

_______________________________________________
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


--------------020102000101000402050209-- From hta@google.com Thu Nov 7 13:28:14 2013 Return-Path: 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 11AE211E8238 for ; Thu, 7 Nov 2013 13:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 fUHokktSvIGZ for ; Thu, 7 Nov 2013 13:28:13 -0800 (PST) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1819311E81B3 for ; Thu, 7 Nov 2013 13:28:13 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hu8so820894vcb.0 for ; Thu, 07 Nov 2013 13:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pRzyxhlJTHmymWiOTVmRK6lz/mjuZ6lR3xWwl7/Af5g=; b=Eb3r0N9adMC2g0cJJGL5orJFqsOZvJlD31sc44Qhd2D/YA51tw0NYAt/PLVzZgR831 lYdKITFuPhQKfRbUJO+3gtMXLmh6wl0zDAi5JNmyeKxu0mfipCq556UzPOuSPov4QHWm +aS6MqdeHInggsxpT0pR8zfQ/UM2Ad5h/wE32M/JsM+MOiK1iHR8AHxGqO7W8V4M7tcT goM1xWfr7xHQeNNW29bd//xKAPsnu9b4n5kMDwT4rSVNnQFduNF7YxHGRSicZqHVZ8az cDZs3RaONx9Qi/g/gDmhuPVNS7PzdeOqi+qjkbIeXm2x57FpG1Bh5RCyjyheV2bbj5Yz DJjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pRzyxhlJTHmymWiOTVmRK6lz/mjuZ6lR3xWwl7/Af5g=; b=QoUB15erQ8NSX9Sc9L9OIMsc6CHPTPW013kfxDTzsP2lAN2p/cbrUG6LdpDHlsCp4v aL6Rdf6pnu91BUkGnISqj3e+nVcKcppc5P1to39apEnDNZ4zrMwG5r46ycwdsMbPey+s zB8yQRbz0fBlQAFs2Ely2JrjRYPQq0WSKZRfv9m7gDnRfZWO2s9SbJf22HjbGF3IQl/b t6bpNoa8OJSDQCsf1Nko70MDdyRe+mDzV86V89zsWda0y5DI92DCRUOmfqeFkgzqXNdF AGHd6edrbpmM+i+M3H3/AWaHKfbphZ+Awjsgq9c/+yKABDTCy87FmD7S9pmPXtcEuL41 MPRQ== X-Gm-Message-State: ALoCoQlRgLm7qNU9FlG3hc3ZgKOPRklqbfCb4eF6/fpB3AARtmT/QRbg92ggIJsC/+pWGyNvbJpwNaLkt7StusFGjlcqIRcqRo++ZXtXK1LUNLwFFIR9edP2odwNYHICEgFUle+GkwWMbmXcSvk8q5/XSV4eqMOHeUw/m/8OLngMoOivlxgVpHpZuD6ATI9sOZSXxOKR31fl X-Received: by 10.52.118.73 with SMTP id kk9mr7022973vdb.13.1383859692261; Thu, 07 Nov 2013 13:28:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.176.8 with HTTP; Thu, 7 Nov 2013 13:27:52 -0800 (PST) In-Reply-To: References: From: Harald Alvestrand Date: Thu, 7 Nov 2013 22:27:52 +0100 Message-ID: To: Krasimir Kolarov Content-Type: multipart/alternative; boundary=089e0122f0f2607ae004ea9cf13a Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 21:28:14 -0000 --089e0122f0f2607ae004ea9cf13a Content-Type: text/plain; charset=UTF-8 Krasimir, if you want to discuss licenses with the Motorola Mobility lawyers, the contact details are in the filing. My impression when I asked them to file something was that the status of that project didn't even enter into consideration when they decided how to respond - but I'm not going to speak for them. If you want to know, call them. On Thu, Nov 7, 2013 at 10:10 PM, Krasimir Kolarov wrote: > One interesting observation from the database is that one of the most > recent Type 2 (royalty bearing) declarations on the list is from a major > proponent of Royalty Free coding - Motorola Mobility (which is now fully > owned by Google). > > It looks like a compelling strategy - to offer technology that you support > for Royalty Free adoption, while blocking a competing technology with a > Type 2 declaration. > > Krasimir > > On Nov 7, 2013, at 12:59 PM, Harald Alvestrand wrote: > > The list of declarations made against the proposed baseline document is > available at the bottom of this page: > > > http://www.iso.org/iso/home/standards_development/governance_of_technical_work/patents.htm > > For declarations against the MPEG baseline proposal, look for the number > 14496-29. > > For some of the declarations, the spreadsheet will tell you whether it's a > Type 1 (royalty free) or Type 2 (royalty bearing) declaration. For the 3 > most recent declarations in the spreadsheet, you will even find a link to > the declaration itself. > > Draw your own conclusions. > > > > On Thu, Nov 7, 2013 at 9:36 PM, Monty Montgomery wrote: > >> > In short, most MPEG members are not evil, and want the same thing as the >> > open source and broader communities, including royalty-free licensing. >> >> I agree, but the structure of the MPEG is such that it only takes one >> (or a handful). We've heard promises of RF baselines stretching back >> almost 20 years. >> >> I agree this would be a wholly positive development, but frankly... >> call us when it's done. >> >> Monty >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --089e0122f0f2607ae004ea9cf13a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Krasimir, if you want to discuss licenses with the Motorol= a Mobility lawyers, the contact details are in the filing.

My impression when I asked them to file something was that the status of= that project didn't even enter into consideration when they decided ho= w to respond - but I'm not going to speak for them. If you want to know= , call them.



On Thu, Nov 7, 2013 at 10:10 PM, Krasimir Kolarov <kolarov@apple.c= om> wrote:
One inte= resting observation from the database is that one of the most recent Type 2= (royalty bearing) declarations on the list is from a major proponent of Ro= yalty Free coding - Motorola Mobility (which is now fully owned by Google).=

It looks like a compelling strategy - to offer technology th= at you support for Royalty Free adoption, while blocking a competing techno= logy with a Type 2 declaration.

Krasimir

On Nov 7, 2013, at 12:59 PM, Harald Alvestrand <hta@google.com> wrote:
The list of declarations made against the proposed baseline document is = available at the bottom of this page:


For declarations against the MPEG baseline propos= al, look for the number 14496-29.

For some of the = declarations, the spreadsheet will tell you whether it's a Type 1 (roya= lty free) or Type 2 (royalty bearing) declaration. For the 3 most recent de= clarations in the spreadsheet, you will even find a link to the declaration= itself.

Draw your own conclusions.



On Thu, Nov 7, = 2013 at 9:36 PM, Monty Montgomery <xiphmont@gmail.com> wrot= e:
> In short, most MPEG members are no= t evil, and want the same thing as the
> open source and broader communities, including royalty-free licensing.=

I agree, but the structure of the MPEG is such that it only takes one=
(or a handful). =C2=A0We've heard promises of RF baselines stretching b= ack
almost 20 years.

I agree this would be a wholly positive development, but frankly...
call us when it's done.

Monty

_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb


--089e0122f0f2607ae004ea9cf13a-- From dabenham@gmail.com Thu Nov 7 14:40:40 2013 Return-Path: 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 CD5A721E818D for ; Thu, 7 Nov 2013 14:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 A8Yc6qfq5tc6 for ; Thu, 7 Nov 2013 14:40:20 -0800 (PST) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5895321E8169 for ; Thu, 7 Nov 2013 14:40:20 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id d10so676210eaj.12 for ; Thu, 07 Nov 2013 14:40:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Lashff4HLL7Ds4ofx52JqBDUv18Yo1RehzNqndH8pPM=; b=MGgGNf371K+eVy9aYz+Sl74WBbSp6Z3kUroEm1nJ1mI7zxz8fOFmrlh5H6myZpHT/E 2qhZAOi1XNKBF1gCtSVqMRBN04/ROGYxjdmN/VVponLO5NzbfTr/EeXVogGUgTp8ChJb 7YcthBO4TEfOcXWMySQk2dJ2pjFu/TjZE+a3tDrJ00RCccTYQCTgdRvwUggT0BcNKgA/ IxHiRUx9lw17IpmQaI4GheBX4j7Jcm03Z7OJ4zW79O4GWsWrozFd3ZOWvPi7E9qz7UQp qlNWx3+pg5/50nTRJ9RC3aBpyw3PUvGk7xeKfp8lA6vu26KIGSAHEHSdMgurjhamlYVp fNfA== MIME-Version: 1.0 X-Received: by 10.14.183.2 with SMTP id p2mr12072371eem.44.1383864009063; Thu, 07 Nov 2013 14:40:09 -0800 (PST) Received: by 10.15.75.1 with HTTP; Thu, 7 Nov 2013 14:40:08 -0800 (PST) Date: Thu, 7 Nov 2013 14:40:08 -0800 Message-ID: From: David Benham To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7b343dc4ad852804ea9df24f Subject: Re: [rtcweb] Current H.264 licensing practice X-BeenThere: rtcweb@ietf.org 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: Thu, 07 Nov 2013 22:43:30 -0000 --047d7b343dc4ad852804ea9df24f Content-Type: text/plain; charset=ISO-8859-1 Extrapolating from an EULA what one's rtcweb dev/distribution license rights is likely way off base. You can read the MPEG-LA's FAQ here ... http://www.mpegla.com/main/programs/AVC/Documents/AVC_TermsSummary.pdf Note the graphic and text for "(b) sublicenses" on pages 2 and 3. The commercial royalties described are targeted at Service Providers of on-demand titles and/or broadcast TV over the Internet with greater 100K subscribers and great remuneration (aka, subscription or ad revenue). Think the likes of Netflix, Amazon Prime, etc, using the video tag and *not* the support-desk in your example or commercial, real-time communications. Disclaimer: *IANAL* David Benham Self - *From*: Florian Weimer > - *To*: rtcweb at ietf.org - *Date*: Thu, 07 Nov 2013 20:30:31 +0100 - *List-id*: Real-Time Communication in WEB-browsers working group list < rtcweb.ietf.org> ------------------------------ After reviewing the end-user patent licensing statements regarding H.264/AVC of various products (Microsoft Windows, Adobe Flash, a Canon camera, Skype, and some Cisco manuals), I'm puzzled what the net effect of the Cisco licensing effort will be. The most striking aspect of the current licensing regime is that the existing platform codecs are exclusively licensed for "personal, non-commercial activity". As far as I can tell, this means that I cannot use these codecs to develop my own software and distribute it without a separate MPEG LA license. Furthermore, if I engage in commercial activity involving H.264 streams (such as paid teaching or technical support over Skype, to give an example that seems fairly relevant to me), I need a separate license as well, even if I use already existing software for which the vendor has acquired patent licenses. This even applies to professional video (conferencing) equipment. I wonder what this means in the context of WebRTC. Would web application development be covered? What about commercial use of such web applications? Under the existing licensing practice, the answer appears to be that these activities need separate licenses. To me, that suggests that even after the Cisco effort, H.264 is still not a replacement for a royalty-free codec. Freedom from royalties for browser vendors is not sufficient if (web) application developers and end users do not benefit. (I know that the concrete licensing terms are not published yet, but I find it rather unlikely that Cisco has negotiated a better deal for the non-paying general public than for its own paying customers.) --047d7b343dc4ad852804ea9df24f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Extrapolating from an EULA what one's rtcweb dev/distr= ibution license rights is likely way off base.


= You can read the MPEG-LA's FAQ here ...=A0
Note the graphic and text for "(b) sublicenses" on pag= es 2 and 3.

The commercial royalties described are t= argeted at Service Providers of on-demand titles and/or broadcast TV over t= he Internet with greater 100K subscribers and great remuneration (aka, subs= cription or ad revenue). =A0 Think the likes of Netflix, Amazon Prime, etc,= using the video tag and *not* the support-desk in your example or commerci= al, real-time communications.

Disclaimer:=A0IAN= AL

David Benham
Self

After reviewing the end-user patent licensing statements regarding
H.264/AVC of various products (Microsoft Windows, Adobe Flash, a Canon
camera, Skype, and some Cisco manuals), I'm puzzled what the net
effect of the Cisco licensing effort will be.

The most striking aspect of the current licensing regime is that the
existing platform codecs are exclusively licensed for "personal,
non-commercial activity".  As far as I can tell, this means that I
cannot use these codecs to develop my own software and distribute it
without a separate MPEG LA license.  Furthermore, if I engage in
commercial activity involving H.264 streams (such as paid teaching or
technical support over Skype, to give an example that seems fairly
relevant to me), I need a separate license as well, even if I use
already existing software for which the vendor has acquired patent
licenses.  This even applies to professional video (conferencing)
equipment.

I wonder what this means in the context of WebRTC.  Would web
application development be covered?  What about commercial use of such
web applications?  Under the existing licensing practice, the answer
appears to be that these activities need separate licenses.  To me,
that suggests that even after the Cisco effort, H.264 is still not a
replacement for a royalty-free codec.  Freedom from royalties for
browser vendors is not sufficient if (web) application developers and
end users do not benefit.

(I know that the concrete licensing terms are not published yet, but I
find it rather unlikely that Cisco has negotiated a better deal for
the non-paying general public than for its own paying customers.)
--047d7b343dc4ad852804ea9df24f-- From singer@apple.com Thu Nov 7 16:14:36 2013 Return-Path: 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 30AB321E80E6 for ; Thu, 7 Nov 2013 16:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_MEDS=0.842] 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 6s24f8tkoPo4 for ; Thu, 7 Nov 2013 16:14:29 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1C821E8169 for ; Thu, 7 Nov 2013 16:14:24 -0800 (PST) Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 27.DA.03695.DDC2C725; Fri, 8 Nov 2013 08:14:21 +0800 (MYT) X-AuditID: 1152fe06-b7f5a6d000000e6f-01-527c2cdd97aa Received: from sng-mmpp-sz01.asia.apple.com ( [17.82.200.58]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id D2.74.14371.DDC2C725; Fri, 8 Nov 2013 08:14:21 +0800 (MYT) Received: from [17.83.34.135] (unknown [17.83.34.135]) by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MVX009G14NWIM00@sng-mmpp-sz01.asia.apple.com> for rtcweb@ietf.org; Fri, 08 Nov 2013 08:14:21 +0800 (SGT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: David Singer In-reply-to: <527BAA17.40705@bbs.darktech.org> Date: Fri, 08 Nov 2013 09:14:20 +0900 Content-transfer-encoding: quoted-printable Message-id: <99C1B7D8-7E90-4FF4-9F31-D18F2F4E4D40@apple.com> References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <527A06EF.2070007@bbs.darktech.org> <527A0C4D.7020707@gmail.com> <527A15A3.2090006@bbs.darktech.org> <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com> <527BAA17.40705@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUiGHRCSPeuTk2QwYavKhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/ufPSwFO4Uqzm3ey9jAeJuvi5GTQ0LAROLmk0PsELaYxIV7 69m6GLk4hAR2M0p8uviYGaboyclZUInJTBKflj9hgnA2MUnc3LOPEaSKWUBLYv3O40wgNq+A nsTOvdtYQWxhASOJOxtbwGrYBFQlHsw5BmZzAtV8PnIdaAMHBwtQfG2jIcQYYYnvj++xQNja Ek/eXWCFGGkj8XfLN0aIvddYJPq+nAVLiAioSNw4dgvqBVmJ0+ees4AUSQh8ZJU4d7OPdQKj 8Cwk981Cct8sJEsWMDKvYhTPTczM0c3MM9JLLM5M1EssKMhJ1UvOz93ECA7qf2w7GBe8NjzE KMDBqMTDO/ttUZAQa2JZcWXuIUYJDmYlEd5nijVBQrwpiZVVqUX58UWlOanFhxilOViUxHk/ u1QHCQmkJ5akZqemFqQWwWSZODilGhgXbPqepfcswzRQoEr16+Lea5NP2q5kyUoVU10p+HxO 2wp3pcpLfxa1CXvHTZeYO4ltf9tvIxPn7w6L7jMdzO1yS84NThNk1jv8Se3IZ1XW1NY1Z31P fMrRnd6hu9uV2/DnvLq9Z29Gb7ufY7vLr1hB+cgvxYN/XfkOv3dxFKme/VT1WKu9vq0SS3FG oqEWc1FxIgC6s6mwZgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUiGHTCSveuTk2QwZXNihZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/ufPSwFO4Uqzm3ey9jAeJuvi5GTQ0LAROLJyVlsELaYxIV7 64FsLg4hgclMEp+WP2GCcDYxSdzcs48RpIpZQEti/c7jTCA2r4CexM6921hBbGEBI4k7G1vA atgEVCUezDkGZnMC1Xw+cp25i5GDgwUovrbREGKMsMT3x/dYIGxtiSfvLrBCjLSR+LvlGyPE 3mssEn1fzoIlRARUJG4cu8UOcamsxOlzz1kmMArMQnLSLCQnzUIydwEj8ypG0aLUnMRKQ73E 4sxEvcSCgpxUveT83E2MkCAU2sH4cb/BIUYBDkYlHt7rD4qChFgTy4orcw8xSnAwK4nwPlOs CRLiTUmsrEotyo8vKs1JLT7EKM3BoiTOa+dRHSQkkJ5YkpqdmlqQWgSTZeLglGpgXPzh9/zq EzrvIg7f9bO8oRTNcThjhpV78IoljEd71ngsUWFmYSi+8HZHWt762fUeWvoHuCd8d571xTmw 3yXx5fmIvQee/as4XHSdvfvpy0+sm96dUdnUOSuyfUXW0rOyLwslS8N5BKNU1+zQZVy37NHM usAoV+YWrk/siwVFjmbXp07fLzv7rhJLcUaioRZzUXEiAEuPXjc+AgAA Cc: rtcweb@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:14:36 -0000 On Nov 7, 2013, at 23:56 , cowwoc wrote: > On 07/11/2013 1:04 AM, David Singer wrote: >> On Nov 7, 2013, at 5:33 , Mohammed Raad = wrote: >>=20 >>> Hi, >>>=20 >>> There isn't much new in the arguments for and against VP8 vs H.264. = Its clear that there are concerns that are beyond how well each codec = performs and whether or not it is free. Although I recognize that the = transcoding option does not address the P2P use case, I do think that = the goal of interoperability can be better achieved through a two phase = approach. The first is enabling end-points to inter-operate through the = availability of transcoding from the service provider. The second is to = make one of the codecs the defacto MTI because of the its higher level = of adoption. Yes, we may never get to a single MTI if we follow this = path but at least we will have endpoints inter-operating. Besides, there = are multiple other difficulties in getting seamless P2P communications = working all the time, so I would suggest focusing on the service = provider centered use case first. >> You know, you're right. >>=20 >> We could suggest or even recommend both, and mandate you must = implement at least one of the two. That would identify precisely two = interoperability points in an otherwise much larger space, at least, and = make it fairly simple for those that can and wish to, to offer = transcoding, since the two ends are now defined. It's not ideal, but it = might be better than saying nothing at all. >=20 > I can't believe you guys are actually trying to convince us that = being forced to use a transcoder is actually a *good* thing! Any = solution that does not address the P2P use-case is a non-starter. Feel = free to use this model in your own deployments, just don't force it on = us. For a start, not everyone would have to transcode, only those cases = where there the two ends implement only one, and different, codecs. = Secondly, I didn't say it was ideal, I I said it was better than saying = nothing. Third, if you implement both, you would never need to use a = transcoder for this reason, but you nonetheless might use a bridge or = intermediary for a whole host of other reasons. David Singer Multimedia and Software Standards, Apple Inc. From singer@apple.com Thu Nov 7 16:18:45 2013 Return-Path: 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 D03CC21E816E for ; Thu, 7 Nov 2013 16:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 Xl6-0Zh3Wz7o for ; Thu, 7 Nov 2013 16:18:39 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) by ietfa.amsl.com (Postfix) with ESMTP id BAEB321E80BD for ; Thu, 7 Nov 2013 16:18:38 -0800 (PST) Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 54.EA.03695.DDD2C725; Fri, 8 Nov 2013 08:18:37 +0800 (MYT) X-AuditID: 1152fe06-b7f5a6d000000e6f-4c-527c2ddd6d59 Received: from sng-mmpp-sz01.asia.apple.com ( [17.82.200.58]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id 74.84.14371.DDD2C725; Fri, 8 Nov 2013 08:18:37 +0800 (MYT) Received: from [17.83.34.135] (unknown [17.83.34.135]) by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MVX009II4V0IM00@sng-mmpp-sz01.asia.apple.com> for rtcweb@ietf.org; Fri, 08 Nov 2013 08:18:37 +0800 (SGT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: David Singer In-reply-to: Date: Fri, 08 Nov 2013 09:18:37 +0900 Content-transfer-encoding: quoted-printable Message-id: <024B46F7-8E0D-40B1-8AD0-5ACEDA6F79D4@apple.com> References: To: Harald Alvestrand X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUiGHRCSPeubk2QQc8MY4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcefuIZaCz2wVjftXMzcwHmTtYuTkkBAwkbj5fA4jhC0mceHe erYuRi4OIYHdjBILt/UDORxgRdNeCEPEJzNJHNmxlAXC2cQk8f7JO3aQbmYBLYn1O48zgdi8 AnoSO/duA9sgLBAt8WvnM7AaNgFViQdzjoFt4xQIlvjyYjNYnAUo/v/UUWaIOb4St56/hZqp LfHk3QVWiJk2ErvuvoZa/J9JYvG8GWwgCREBNYm1U7qg3pGVOH3uOViRhMBXVokHU6ewT2AU noXkwFlIDpyFZMkCRuZVjOK5iZk5upl5RnqJxZmJeokFBTmpesn5uZsYwUH9j20H44LXhocY BTgYlXh4Z78tChJiTSwrrsw9xCjBwawkwvtMsSZIiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9n l+ogIYH0xJLU7NTUgtQimCwTB6dUA+M6jqdRd7SOdC+yto3fuSDDI4nztmnebvGCd9K9jp0p N0wTn3Wmq+8+G5Tw64II74atsx3jWJbK9lZv7tu6Zm0mY/PEhf1hMUFW079+153JVsLilXPW S0WS7Sz72je1W641B3RMiPY+crRszvxd0ReWHts97elxlb08qql7T+c7r7x//OvduD4lluKM REMt5qLiRAA8FMhEZgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUiGHTCSveubk2QwdMNBhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr487dQywFn9kqGvevZm5gPMjaxcjBISFgIjHthXAXIyeQKSZx 4d56ti5GLg4hgclMEkd2LGWBcDYxSbx/8o4dpIpZQEti/c7jTCA2r4CexM6921hBbGGBaIlf O5+B1bAJqEo8mHOMEcTmFAiW+PJiM1icBSj+/9RRZog5vhK3nr+Fmqkt8eTdBVaImTYSu+6+ hlr8n0li8bwZbCAJEQE1ibVTulghTpWVOH3uOcsERoFZSG6aheSmWUjmLmBkXsUoWpSak1hp qJdYnJmol1hQkJOql5yfu4kREoRCOxg/7jc4xCjAwajEw3v9QVGQEGtiWXFl7iFGCQ5mJRHe Z4o1QUK8KYmVValF+fFFpTmpxYcYpTlYlMR57Tyqg4QE0hNLUrNTUwtSi2CyTBycUg2MzfUz paZmq/t/5WWsU7BaK7Y5ITLtyfHJRV8P551cfdtY2OX0jD/HdMqfRrJt3BvjqGX8b2oB4wfu g6t+fXBqPKf63uTMD379i+bO6zYXnvr6rtD/h4GKXuGHLGPRpv07d75duVPyktHaXx9fnVke EFl34nnCzieV8YxPfOSTA/5UBKovD5p3TImlOCPRUIu5qDgRAK1p/AU+AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8 X-BeenThere: rtcweb@ietf.org 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 00:18:45 -0000 On Nov 8, 2013, at 6:27 , Harald Alvestrand wrote: > Krasimir, if you want to discuss licenses with the Motorola Mobility = lawyers, the contact details are in the filing. Is there anything ambiguous or unclear that would warrant discussion? = The statement seems fairly straightforward. And generally, in the = standards bodies we work on what is formally said, not what we might = learn in hypothetical side-conversations. > My impression when I asked them to file something was that the status = of that project didn't even enter into consideration when they decided = how to respond - but I'm not going to speak for them. If you want to = know, call them. It's not Krasimir who wants to know, it's all of us. The public = statement is presumed to be your public statement. David Singer Multimedia and Software Standards, Apple Inc. From gmaxwell@gmail.com Thu Nov 7 16:42:31 2013 Return-Path: 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 CF8A721E8177 for ; Thu, 7 Nov 2013 16:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 PzaYgVZIYUKa for ; Thu, 7 Nov 2013 16:42:30 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 06BBD21E8165 for ; Thu, 7 Nov 2013 16:41:45 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id ea20so1091028lab.28 for ; Thu, 07 Nov 2013 16:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=eJ0VSxjS2odmXC8shHjhUt5XM9OpsZ7sKLEaFXe2IHE=; b=i1vMAertNSuqZDnJob4brsMn3EalgpjhIkttSlymgCrJN3gkn6MA7CQclWryjIFvEZ d8u4KdGi6BCP/yz5HVTuM526f/JQjZhCM4DTnTdWm6V2xNmo/LZ3TChYt9gWxnHbog57 biwzj3ZH0mpli/RFaQT2wniHquhuhMrbEr/elbFqZgLjaxLHSdQnBo+5ewUY3jV5BmYQ 7vRoh1qavAlFh113/GVKkXGgz/hhHasenqgJub8s3gJdYTdwNqI/CiSenh9qPqmiU/tZ NlDhFrPqd8WfKW5mQETzE+WXdDX8Rf+A+HYdsXh96N2+GkDFsBTsKz/2+IK1vo21Il6D lmUA== MIME-Version: 1.0 X-Received: by 10.112.198.39 with SMTP id iz7mr8445196lbc.24.1383871302902; Thu, 07 Nov 2013 16:41:42 -0800 (PST) Sender: gmaxwell@gmail.com Received: by 10.112.63.164 with HTTP; Thu, 7 Nov 2013 16:41:42 -0800 (PST) Date: Thu, 7 Nov 2013 16:41:42 -0800 X-Google-Sender-Auth: 0QFoxM34pqDHP18aUvq82eqWMPE Message-ID: From: Gregory Maxwell To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [rtcweb] Alternative consensus and MTI video codecs X-BeenThere: rtcweb@ietf.org 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 00:42:32 -0000 I've always thought the RFC 3929 procedures were more of a threat to encourage a consensus=E2=80=94 if an uncomfortable one=E2=80=94 than someth= ing that ought to be used... but its not much of a threat if its never used, and sometimes it's really important to have a decision. I think we had previously agreed here that an MTI codec is important. That it would break marketplace symmetry and create compatibility. It may be that after the OpenH264 announcement some people believe MTI is less important. I think the question to ask is "Is and MTI video codec important here". Not do I support this codec or that. But is MTI video something important the group should deliver. If not, why not and why wasn't it before? "MTI is hard" isn't a valid answer to that question. "My favorite option didn't win" isn't an answer either. If we still believe from an engineering perspective that WebRTC ought to have one MTI video codec it still can, even though the counts were split: We can invoke RFC 3929 4.4 and _flip a coin_. A coinflip is a simple process which is guaranteed to make a section. (If we don't trust a chair member to perform an actual coinflip, I can suggest a trivial cryptographic protocol we can do in the list with nothing more than the sha256sum tool) I don't see how anyone can argue that for the goal of selecting an MTI that a coinflip between options in a largely split room cannot achieve that goal. Alternatively, =E2=80=94 considering market realities if MUST one of {vp8,h= 264 constrained baseline} is really the closest to MTI-in-practice we could expect full deployment of=E2=80=94 is that preferable? Does it achiev= e the goal of having MTI video in the first place? Does it partially achieve it? I don't think the argument that one-of-either is better than none-at-all is sufficient: We can coinflip so none at all is not a necessary option. I think an argument for one-of-either must argue that market realities make a single MTI (selected via coinflip) a dead letter. And arguments that either single codec as MTI were dead letters have failed to convince the working group already. From hta@google.com Thu Nov 7 17:01:36 2013 Return-Path: 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 D919221E8135 for ; Thu, 7 Nov 2013 17:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 vENbuwOVMl9Q for ; Thu, 7 Nov 2013 17:01:36 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8858221E80E7 for ; Thu, 7 Nov 2013 17:01:30 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id jx11so234863veb.40 for ; Thu, 07 Nov 2013 17:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=FoOYpBeRY063HItWP/7V+4Za/e7ghtBP3xYyh3l0or4=; b=Z9xYk+tAds4LcE9Do2lzODh0C9RG+BPtEg8xQRlAOe5RWeujCLRKHJCmpiONiQR58Y MRYB/mG+SHPcHPpO6Fw1542ls8Fh43BFjdIOm5KtRNb4IEv7Jurlej/roJfcp8kiDcbs tpFFz1IOQP/swu+5GMJWVl1Yf7opNeOBk/me0DK1T3LHC984AcBWDTKR6gBVfRP3aZ9B 7e75QLFac7QJ2lVditCvaE0jGCuO9uJIW6QpO/SO7LFbt7UxTQIGKrU1iloHX/wFEuY8 rjcczmXPcTrAiwNhIMFAUBZH9h+QsKxLby2/SF96YkdrbtT9jpWOw9rSFMK3BBkI8jMy 08/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=FoOYpBeRY063HItWP/7V+4Za/e7ghtBP3xYyh3l0or4=; b=abLciGeSiOHld8NJF8+hy3pvMTYDyRoOEQQeTsog4z6mmlLtR69DmaekR8D4/rhizQ WfZszMr+iKNnqxDpvN/xIuoyDtfEbhNY9YgCpCf3YLTNk9clSoK+GPiqbV0qNkXkPeuG FQCTFh//HZrCGchs1oyCHKcOJ0a5QdTFNbXXTdJxTTsO29aPsK64FoU48RF/dVgJp/jB OkmQCiT/Jac9HwG2n8ZOIqKyJf6j4DNDSfQfmGDnYgnlFh1Iw9xE+f1hx2WpRq+XNj2Z aS0dIEDvoTYipSakBvOkXsrpQZ+RLPXaaYjGz256LlO7GySCbHhWTkGMWsCoDpeR2tKe Y4AQ== X-Gm-Message-State: ALoCoQmcumC26g3nNqfF4Ty8paKD12JnYobtQzvkHhYmBxhDWHuS+hzkTd+V8Wtx/crKSfDeP/K5Kmqdmm/iOdHByIrwEWZWchN2DzW7n2PBsma4vuiLu5FLdhgFYV2cEFAoZwC+MIDbgvd1lYwiOnCUpyEHtRmGK/EGix65SByqq9xRBq27JuUoKkIqleZ5SQxzaSB/a8xI X-Received: by 10.52.32.37 with SMTP id f5mr7607520vdi.17.1383872489691; Thu, 07 Nov 2013 17:01:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.176.8 with HTTP; Thu, 7 Nov 2013 17:01:09 -0800 (PST) From: Harald Alvestrand Date: Fri, 8 Nov 2013 02:01:09 +0100 Message-ID: To: David Singer Content-Type: multipart/alternative; boundary=bcaec51d255229ca2104ea9fecf2 Cc: "rtcweb@ietf.org" Subject: [rtcweb] WebVC licensing issues (Re: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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 01:01:37 -0000 --bcaec51d255229ca2104ea9fecf2 Content-Type: text/plain; charset=UTF-8 Changing the subject, since this is a different topic to where we started the thread. It is also perhaps somewhat irrelevant to the rtcweb mailing list. The public statement is the public statement of Motorola Mobility, just like the Microsoft public statement (also type 2) is the public statement of Microsoft. If you want more information than what's given in the statement, you have to ask the persons who made the statement. Which is not me - that's really all I was saying. (One of the things I've been surprised about in the discussions of WebVC is that the proponents have not seemed to have any plan to resolve the issue of the Type 2 filings they have received. I'm not sure what such a plan would consist of - but my inability to see how we could resolve this issue is a major reason why I don't have a strong belief that this project can actually achieve its stated goals.) Harald On Fri, Nov 8, 2013 at 1:18 AM, David Singer wrote: > > On Nov 8, 2013, at 6:27 , Harald Alvestrand wrote: > > > Krasimir, if you want to discuss licenses with the Motorola Mobility > lawyers, the contact details are in the filing. > > Is there anything ambiguous or unclear that would warrant discussion? The > statement seems fairly straightforward. And generally, in the standards > bodies we work on what is formally said, not what we might learn in > hypothetical side-conversations. > > > My impression when I asked them to file something was that the status of > that project didn't even enter into consideration when they decided how to > respond - but I'm not going to speak for them. If you want to know, call > them. > > It's not Krasimir who wants to know, it's all of us. The public statement > is presumed to be your public statement. > > David Singer > Multimedia and Software Standards, Apple Inc. > > --bcaec51d255229ca2104ea9fecf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Changing the subject, since this is a different topic= to where we started the thread.
It is also perhaps somewhat irre= levant to the rtcweb mailing list.

The public statement= is the public statement of Motorola Mobility, just like the Microsoft publ= ic statement (also type 2) is the public statement of Microsoft.

If you want more information than what's given in the st= atement, you have to ask the persons who made the statement.
Whic= h is not me - that's really all I was saying.

(One of the things I've been surprised about in the discussions of WebV= C is that the proponents have not seemed to have any plan to resolve the is= sue of the Type 2 filings they have received. I'm not sure what such a = plan would consist of - but my inability to see how we could resolve this i= ssue is a major reason why I don't have a strong belief that this proje= ct can actually achieve its stated goals.)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Harald


On Fri, Nov 8, 2013 a= t 1:18 AM, David Singer <singer@apple.com> w= rote:

On Nov 8, 2013, at 6:27 , Harald Alvestrand <hta@google.com> wrote:

> Krasimir, if you want to discuss licenses with the Motorola Mobility l= awyers, the contact details are in the filing.

Is there anything ambiguous or unclear that would warrant discussion?= =C2=A0The statement seems fairly straightforward. =C2=A0And generally, in = the standards bodies we work on what is formally said, not what we might le= arn in hypothetical side-conversations.

> My impression when I asked them to file something was that the status = of that project didn't even enter into consideration when they decided = how to respond - but I'm not going to speak for them. If you want to kn= ow, call them.

It's not Krasimir who wants to know, it's all of us. =C2=A0Th= e public statement is presumed to be your public statement.

David Singer
Multimedia and Software Standards, Apple Inc.


--bcaec51d255229ca2104ea9fecf2-- From adam@nostrum.com Thu Nov 7 17:06:11 2013 Return-Path: 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 D1F9921E817E for ; Thu, 7 Nov 2013 17:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 qnf0+wYYPXVX for ; Thu, 7 Nov 2013 17:06:11 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D626C21E816A for ; Thu, 7 Nov 2013 17:06:08 -0800 (PST) Received: from dhcp-9081.meeting.ietf.org (dhcp-9081.meeting.ietf.org [31.133.144.129]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA8167cm013560 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Nov 2013 19:06:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <527C38FF.6040000@nostrum.com> Date: Thu, 07 Nov 2013 17:06:07 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Gregory Maxwell , "rtcweb@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 31.133.144.129 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] Alternative consensus and MTI video codecs X-BeenThere: rtcweb@ietf.org 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 01:06:11 -0000 On 11/7/13 16:41, Gregory Maxwell wrote: > If we still believe from an engineering perspective that WebRTC ought > to have one MTI video codec it still can, even though the counts were > split: We can invoke RFC 3929 4.4 and_flip a coin_. I do not believe the decision under consideration qualifies for the process in section 4.4. As that section itself notes, random selection is only appropriate for something like deciding a numerical codepoint or a DNS prefix. Our situation is radically different: there are a number of actual arguments to be made for both options. I think an external review team (section 4.1) is a reasonable way forward, as it lets the decision rest on the merits that proponents of each approach have themselves put forth, without allowing partisan or emotional considerations to get in the way of facts. I'll make an even stronger statement: I would contend that any strong push against the use of an external review team amounts to a tacit admission by an individual that the arguments for their preferred position are insufficiently compelling. If anyone believes that their position logically follows from the known facts, then they would necessarily believe that a randomly-selected panel of neutral third parties will agree with them. If such a person thinks that the panel won't, perhaps they should reevaluate whether their arguments are grounded in facts and logic, or their own emotional investment in this decision. /a From singer@apple.com Thu Nov 7 17:08:12 2013 Return-Path: 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 707F711E823D for ; Thu, 7 Nov 2013 17:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 RrXjNYhhlTYt for ; Thu, 7 Nov 2013 17:08:02 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE2E11E80F7 for ; Thu, 7 Nov 2013 17:07:57 -0800 (PST) Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 62.7C.21841.9693C725; Fri, 8 Nov 2013 09:07:53 +0800 (MYT) X-AuditID: 1152fe11-b7f256d000005551-7a-527c396962cc Received: from echium.asia.apple.com ( [17.82.200.52]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id 66.C5.14371.9693C725; Fri, 8 Nov 2013 09:07:53 +0800 (MYT) Received: from [17.83.34.135] (unknown [17.83.34.135]) by echium.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVX00ID47543I10@echium.asia.apple.com> for rtcweb@ietf.org; Fri, 08 Nov 2013 09:07:53 +0800 (SGT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: David Singer In-reply-to: Date: Fri, 08 Nov 2013 10:07:53 +0900 Content-transfer-encoding: quoted-printable Message-id: <3B441C46-2738-495B-93FA-FF63EEA4C54B@apple.com> References: To: Harald Alvestrand X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUiGHRCSDfTsibIoPmYhcXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuLR1PUvBXPGKv43zmRsYFwh1MXJwSAiYSDR/5ehi5AQyxSQu 3FvP1sXIxSEksJtRYuaOx4wQCROJE3MvsEMkepgkFr65xQqSEBJYyiSx9a42iM0soCWxfudx JhCbV0BPYufebWA1wgIVEr8vfGcBsdkEVCUezDkGNpRTIFji1vkdYPUsQPHXRx+wQczxlbj1 /C07hK0t8eTdBVaQQ3kFbCQubUmDWBsgcXDHF7ByEQE1ibVTulgh7pSVOH3uOQvInRICX1kl vp2ZzDKBUXgWkvNmITlvFpIVCxiZVzGK5yZm5uhm5hnqJRZnJuolFhTkpOol5+duYgSH8z/B HYxTFxoeYhTgYFTi4fVMKg4SYk0sK67MPcQowcGsJML7TLEmSIg3JbGyKrUoP76oNCe1+BCj NAeLkjjvZ5fqICGB9MSS1OzU1ILUIpgsEwenVANjONuZj1OlJ+ze66vsOjP9/OIrpjGcRqeO fao69YJNrT9iywS9JNv0/80bHtYcTb32ePayuDJuw2O5CbHXzsX1P5rBzKXzYKuahtXKMqmG ud5hG67N4Yh8+IJl3Yq2H0+K9N+UcGWJJny+KXd5ZeSO8ubNfeviupZJczYZhO7u62ONXdV4 5YWdEktxRqKhFnNRcSIA8pOF1WMCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUiGHTCRDfTsibI4OpyU4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcWnrepaCueIVfxvnMzcwLhDqYuTkkBAwkTgx9wI7hC0mceHe erYuRi4OIYEeJomFb26xgiSEBJYySWy9qw1iMwtoSazfeZwJxOYV0JPYuXcbWI2wQIXE7wvf WUBsNgFViQdzjjGC2JwCwRK3zu8Aq2cBir8++oANYo6vxK3nb9khbG2JJ+8uAM3hAJppI3Fp SxrE2gCJgzu+gJWLCKhJrJ3SxQpxp6zE6XPPWSYwCsxCctEsJBfNQjJ1ASPzKkbRotScxEpD vcTizES9xIKCnFS95PzcTYyQABTawfhxv8EhRgEORiUe3usPioKEWBPLiitzDzFKcDArifA+ U6wJEuJNSaysSi3Kjy8qzUktPsQozcGiJM5r51EdJCSQnliSmp2aWpBaBJNl4uCUamDk2N21 Rlhw9br7+0KnKD7/rXK2eUWgqcMkz0P7lwSfe9nN7ZGsY3o3hWP5nVsnD8s4eM276y2ecPhv n0jY4QWc6tsPXjy95xDXzceek88GWV6OqmnOjBNrnD1hlwjvDJn4dLH3fMzzT2dz/Hru/st/ 1mar6cwq/VfVZVx/x9XY8E3dcDo+wsFKiaU4I9FQi7moOBEAONs/bTwCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebVC licensing issues (Re: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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 01:08:12 -0000 On Nov 8, 2013, at 10:01 , Harald Alvestrand wrote: > Changing the subject, since this is a different topic to where we = started the thread. > It is also perhaps somewhat irrelevant to the rtcweb mailing list. >=20 > The public statement is the public statement of Motorola Mobility, = just like the Microsoft public statement (also type 2) is the public = statement of Microsoft. >=20 > If you want more information than what's given in the statement, you = have to ask the persons who made the statement. > Which is not me - that's really all I was saying. >=20 > (One of the things I've been surprised about in the discussions of = WebVC is that the proponents have not seemed to have any plan to resolve = the issue of the Type 2 filings they have received. I'm not sure what = such a plan would consist of - but my inability to see how we could = resolve this issue is a major reason why I don't have a strong belief = that this project can actually achieve its stated goals.) The plan of record, as of the previous meeting, was to consider filings = made by the close of the DIS ballot, which was just a week or two ago. = Then we try to get the pipeline to deliver us all the statements and = their details (don't ask why that is hard, it beats me), and then we = consider where we are. Plumbers are at work trying to get the data out of the pipeline, into = the database, and so on. Whether the non-type-1 statements can be resolved, how many there are, = and so on, is obviously a question to be answered. That was part of the = plan at inception and has not been discussed since, so you may not have = been around for the discussion. (The Microsoft statement is very similar to a couple of others, which = are formally type-2 but would go to type-1 -- RF -- if all others do the = same). >=20 > Harald >=20 >=20 > On Fri, Nov 8, 2013 at 1:18 AM, David Singer wrote: >=20 > On Nov 8, 2013, at 6:27 , Harald Alvestrand wrote: >=20 > > Krasimir, if you want to discuss licenses with the Motorola Mobility = lawyers, the contact details are in the filing. >=20 > Is there anything ambiguous or unclear that would warrant discussion? = The statement seems fairly straightforward. And generally, in the = standards bodies we work on what is formally said, not what we might = learn in hypothetical side-conversations. >=20 > > My impression when I asked them to file something was that the = status of that project didn't even enter into consideration when they = decided how to respond - but I'm not going to speak for them. If you = want to know, call them. >=20 > It's not Krasimir who wants to know, it's all of us. The public = statement is presumed to be your public statement. >=20 > David Singer > Multimedia and Software Standards, Apple Inc. >=20 >=20 David Singer Multimedia and Software Standards, Apple Inc. From hta@google.com Thu Nov 7 17:15:31 2013 Return-Path: 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 BE6E121F9F8E for ; Thu, 7 Nov 2013 17:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 S1mI6Ob++3d5 for ; Thu, 7 Nov 2013 17:15:31 -0800 (PST) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id C8F5721F9F88 for ; Thu, 7 Nov 2013 17:15:30 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id w5so943531vbf.24 for ; Thu, 07 Nov 2013 17:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YWQdYCeLvux8Ot6CEEf7a4jzWJrmZPey55CuQG4XOMg=; b=H83iN5QioDk9r91fSZHHNiOev0yRzbbOstXfoz7TK8Qq8kaQ8FqqVysoI7ALNQltgA qukpW2N8tY+L0gOAUSI/itQ8k/zDiQSyD7X2UvWSYh+WBebQ+hBQl+sbmtvjG9a+23W7 vsVrFCHVoounxtX53dpGL9teUDcq8VFB6PAh3bEASh6m806fF76ylhLctR7sBiljTmfN 83gWJnmN6wsvIQnoM5nkNi/W8Y40g67lHmWPWxpNLNGNvdoISeOCItLi/VBPZWJX/jaL mKCzCHQNLde+WgrcxeuyqCP4OzCgT3aZf4Va4SUs+n80aXxgK2f99JrpOli8KP5Imebe ervg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YWQdYCeLvux8Ot6CEEf7a4jzWJrmZPey55CuQG4XOMg=; b=h0hpTBFXmwTFblpPU/+r5g/Nd5gf2YMhbGb0VYDnx1B+EvJeAWGkCvraCPTNcbAk8e g7fcziQN8wsl1P3i8Dz3Ge1xH4Lr8pU956x1su9LzX1yK/zILmV6ShImOukUmqsPrq2z 5J9uwYF+mDFk08jNl0pGinCehY7T7g1o3d44x8efcuFMLwgS20GGLXsEVhSokRCDHNzZ 2U6Fs7ASqJ3EBm4EYkKqrC4vSF30Ep//I8i+f15VD6yVj5OViHFgyajGO/5CLKxoBEnp Q7nXcfl1rRlOss0gj8Y4dD+jzTk8AL0QiELWwJ7DWvUjdPXca1a8RNzI02JVpfccB8LO 3r4w== X-Gm-Message-State: ALoCoQnbUH8AF4pPSXLQ1mhF5NJ/+WZc65Da3zgF23weQ3CCqsjswrRzmIUeLlKkvYhBt1HNIsQhSEX9+qFFqzlVaHcm4U7q7NVGOJvYhn2FZUF/BNZSjGN0bJMLCCPJR+lN1FSbAb/SnHz+3B9lUMQxaQX+bJ1M38vmZ+Vd87CT1Ajr99H3HHnMR4D3YdfO9Kpt1FQaCwtt X-Received: by 10.221.27.73 with SMTP id rp9mr3951311vcb.29.1383873329333; Thu, 07 Nov 2013 17:15:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.176.8 with HTTP; Thu, 7 Nov 2013 17:15:09 -0800 (PST) In-Reply-To: <3B441C46-2738-495B-93FA-FF63EEA4C54B@apple.com> References: <3B441C46-2738-495B-93FA-FF63EEA4C54B@apple.com> From: Harald Alvestrand Date: Fri, 8 Nov 2013 02:15:09 +0100 Message-ID: To: David Singer Content-Type: multipart/alternative; boundary=001a1133970635b51204eaa01ed1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebVC licensing issues (Re: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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 01:15:31 -0000 --001a1133970635b51204eaa01ed1 Content-Type: text/plain; charset=UTF-8 Actually I was very happy that ISO had cleaned up the database to the point where they made the actual statements publicly available - I see this as a major step forward. Whether they manage to apply that transparency retroactively remains to be seen. That's how I found that the Microsoft statement doesn't say that it will go to type-1 if all others do the same; it says that it will "reconsider the matter". I assume this is just lawyers being cagy, and that they have given assurance that they really mean "will switch to type 1", but their public statement doesn't say so. Looking forward to seeing the result of the next phase of the work. On Fri, Nov 8, 2013 at 2:07 AM, David Singer wrote: > > On Nov 8, 2013, at 10:01 , Harald Alvestrand wrote: > > > Changing the subject, since this is a different topic to where we > started the thread. > > It is also perhaps somewhat irrelevant to the rtcweb mailing list. > > > > The public statement is the public statement of Motorola Mobility, just > like the Microsoft public statement (also type 2) is the public statement > of Microsoft. > > > > If you want more information than what's given in the statement, you > have to ask the persons who made the statement. > > Which is not me - that's really all I was saying. > > > > (One of the things I've been surprised about in the discussions of WebVC > is that the proponents have not seemed to have any plan to resolve the > issue of the Type 2 filings they have received. I'm not sure what such a > plan would consist of - but my inability to see how we could resolve this > issue is a major reason why I don't have a strong belief that this project > can actually achieve its stated goals.) > > The plan of record, as of the previous meeting, was to consider filings > made by the close of the DIS ballot, which was just a week or two ago. > Then we try to get the pipeline to deliver us all the statements and their > details (don't ask why that is hard, it beats me), and then we consider > where we are. > > Plumbers are at work trying to get the data out of the pipeline, into the > database, and so on. > > Whether the non-type-1 statements can be resolved, how many there are, and > so on, is obviously a question to be answered. That was part of the plan > at inception and has not been discussed since, so you may not have been > around for the discussion. > > (The Microsoft statement is very similar to a couple of others, which are > formally type-2 but would go to type-1 -- RF -- if all others do the same). > > > > > Harald > > > > > > On Fri, Nov 8, 2013 at 1:18 AM, David Singer wrote: > > > > On Nov 8, 2013, at 6:27 , Harald Alvestrand wrote: > > > > > Krasimir, if you want to discuss licenses with the Motorola Mobility > lawyers, the contact details are in the filing. > > > > Is there anything ambiguous or unclear that would warrant discussion? > The statement seems fairly straightforward. And generally, in the > standards bodies we work on what is formally said, not what we might learn > in hypothetical side-conversations. > > > > > My impression when I asked them to file something was that the status > of that project didn't even enter into consideration when they decided how > to respond - but I'm not going to speak for them. If you want to know, call > them. > > > > It's not Krasimir who wants to know, it's all of us. The public > statement is presumed to be your public statement. > > > > David Singer > > Multimedia and Software Standards, Apple Inc. > > > > > > David Singer > Multimedia and Software Standards, Apple Inc. > > --001a1133970635b51204eaa01ed1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --047d7b6d95ee9f7a8d04ebc70965-- From ron@debian.org Fri Nov 22 09:10:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B191ADFF6 for ; Fri, 22 Nov 2013 09:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd0jOyLLSV61 for ; Fri, 22 Nov 2013 09:10:32 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id E2C751ADFE2 for ; Fri, 22 Nov 2013 09:10:31 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 23 Nov 2013 03:40:24 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 32EF24F8F3 for ; Sat, 23 Nov 2013 03:40:22 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UcJztSqP9AI2 for ; Sat, 23 Nov 2013 03:40:20 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 81FF34F902; Sat, 23 Nov 2013 03:40:20 +1030 (CST) Date: Sat, 23 Nov 2013 03:40:20 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131122171020.GY3245@audi.shelbyville.oz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 17:10:33 -0000 On Fri, Nov 22, 2013 at 05:17:45AM +0000, Mo Zanaty (mzanaty) wrote: > On 11/21/13 12:48, Basil Mohamed Gohar > wrote: > Has anyone actually objected to H.261 being the one MTI codec [...] ? > > Assume this wins and all obey. Chrome does H.261+VP8, Firefox does > H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According to > various (incredibly extrapolated, possibly inaccurate and sometimes > conflicting) sources [1] on who uses what browser, the chance of H.261 > fallback is a whopping 30% [2]. Not the minor insignificant case some had > assumed. > > How will these users react to H.261 QCIF/CIF compared to what they use today ... You seem to be forgetting that WebRTC is a communication protocol for PEOPLE, not some one-sided push technology that gives them take it or leave it choices decided by self-interested vendors. So I would assume they'll react the same way they already do. Something along the lines of: "D00d!! Y U use that crap browser!??!111" And then they'll use the amazing text capabilities to paste a download link for firefox or something. 2 minutes later, problem solved. And they'll be watching each other's cats do fun things in full hi-res glory. It's not some accident of fate that the vendor browsers have the poor level of mindshare that they do, even given the solid advantage of incumbency they should otherwise enjoy. If the only way they think they can compete is via lock in and exclusivity using codec patents, then that alone speaks for the irrelevancy of those opinions about what is best for making this standard become ubiquitous. We need to guarantee interoperability between things that claim to implement the standard. Quality of implementation is something that users will judge for themselves, and their mindshare will again gravitate accordingly between the available options. I'd still much prefer a better codec than H.261 as our baseline, but if the proprietary patent holders refuse to let us have that, then we need to work with the technology that is available to us. It doesn't take a doctorate in formal logic to connect those dots. This is our next best option for "making the patents evaporate", are people really now saying they didn't really want that to actually happen after all, despite what they said previously? Ron From roman@telurix.com Fri Nov 22 09:19:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144631AE047 for ; Fri, 22 Nov 2013 09:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6RsvNS8T9GO for ; Fri, 22 Nov 2013 09:19:14 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id E91861AE04C for ; Fri, 22 Nov 2013 09:19:13 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id m15so1405755wgh.13 for ; Fri, 22 Nov 2013 09:19:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=79p60v5xnfsONenyqh/rI+5r9GeSC/uF3hpgvhAhh8M=; b=SaWujiaaNYnJR1FiqlZ4tXTNFGYZ2XZmOcHA1TuPBUNi8eJlL5beU+ukEStVu5UIOY 5sCUpBk06Na9TCEnYyy592jtzN7mT8YPBCon2gfMv2+JQo/ypFEipUBCtq2ubUQ5FHa5 481mJ6ggyC4iskmCInlFhP6e7xjiKSITkNEETWQEd3UKdtWMrs1lhRvrGsbHTI65HUKm MPfcmHsCLEDX/5AK8NigIqNXGIpQjZvcI7eao/Pjz79s0np8aMppJ4EjUsrxDnjcbzIQ /34FNvZSLgvcS+NnfqecGzrCp7cKrG7IV3H+UGVRIcldZdQZibBA2W2lL8H2p1lxx6aJ I8rw== X-Gm-Message-State: ALoCoQni75bEZTDAXVb3fvh9/e04Q96icl5R99EHyTZaP2kZm8RpNYMJW4BLCPKouvjrg/B5b+U2 X-Received: by 10.180.86.102 with SMTP id o6mr3563713wiz.30.1385140746365; Fri, 22 Nov 2013 09:19:06 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by mx.google.com with ESMTPSA id gb1sm17804301wic.0.2013.11.22.09.19.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 09:19:04 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hm6so1879287wib.0 for ; Fri, 22 Nov 2013 09:19:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.198.170 with SMTP id jd10mr3415547wic.65.1385140744413; Fri, 22 Nov 2013 09:19:04 -0800 (PST) Received: by 10.217.88.133 with HTTP; Fri, 22 Nov 2013 09:19:04 -0800 (PST) In-Reply-To: <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com> References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com> <528F30C1.8040208@it.aoyama.ac.jp> <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com> Date: Fri, 22 Nov 2013 12:19:04 -0500 Message-ID: From: Roman Shpount To: tim panton Content-Type: multipart/alternative; boundary=047d7b62509e08ec9504ebc73638 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 17:19:18 -0000 --047d7b62509e08ec9504ebc73638 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually O/A model is asymmetric by default. All you specify in SDP are the codecs you can receive. You are allowed to send a stream in any codec remote side supports. So if both sides state that they support codecs X and Y in SDP, one side can send X in one direction and another side can send Y in opposite. _____________ Roman Shpount On Fri, Nov 22, 2013 at 11:40 AM, tim panton wrote: > Surely this flies in the face of the whole O/A model, which imposes a sor= t > of symmetry on the endpoints ? > (Unless there is some arcane SDP FRACK at play here). > > T. > > > On 22 Nov 2013, at 08:24, Silvia Pfeiffer > wrote: > > I think this has value. It might bring apple and Microsoft to the table, > since decoding-only is often the less patent-affecting part. > > Silvia. > On 22 Nov 2013 02:24, Martin J. D=FCrst wrote: > >> On 2013/11/22 5:02, Stefan Slivinski wrote: >> >>> I in no way intended to suggest a specific implementation of a video >>> codec. My question was around whether we are voting on requiring decod= ers >>> (my assumption) or both encoders and decoders >>> >> >> My understanding is that all the proposals in each instance mean "both >> encoder and decoder". So as an example, a proposal of "MUST implement bo= th >> VP8 and H.264" means "MUST implement both VP8 encoder and decoder, and >> H.264 encoder and decoder". >> >> Your question brings up other choices. For example, interoperability >> would be satisfied by something like "MUST implement both VP8 and H.264 >> decoders, and MUST implement at least one of VP8 and H.264 encoders". >> >> One condition for this to work is the possibility of asymmetric >> communication, i.e. if side A implemented only a VP8 encoder, and side B >> only implemented a H.264 encoder, then traffic A->B would be VP8, wherea= s >> traffic B->A would be H.264. I don't know the in's and out's of the >> negotiation and protocol machinery to confirm or deny that this is possi= ble. >> >> Choices like the one above definitely open new horizons for Eric's >> selection generator. But frankly speaking, except for the specific choic= e >> of "MUST implement both VP8 and H.264 decoders, and MUST implement at le= ast >> one of VP8 and H.264 encoders", which is less onerous than "MUST impleme= nt >> both VP8 and H.264", but still interoperable, I don't see any choices wi= th >> different requirements for encoders and decoders that would make sense. >> >> Regards, Martin. >> >> >> ----- Original Message ----- >>> From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org] >>> Sent: Thursday, November 21, 2013 01:56 PM >>> To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] Proposed Video Selection Process >>> >>> On 11/21/2013 02:31 PM, Stefan Slivinski wrote: >>> >>>> I'm a new comer, so just a brief intro: I have a background developing >>>> real time video codecs for embedded devices so I'm in a position to co= mment >>>> at a technical level within this group >>>> >>>> For clarity purposes the proposed alternatives in Magnus' email on nov >>>> 18th; are we strictly speaking about decoders? Historically mandatory >>>> requirements are they relate to video compatibility define just the >>>> decoders. Obviously if there is only a single mandatory video decoder= this >>>> implies a mandatory encoder, however in the case where there are 2 >>>> mandatory decoders only a single encoder is technically required. >>>> >>>> Clarifying this is fairly important because in the case of both h264 >>>> and vp8 (and in the future vp9 and h265) the decoder complexity is fai= rly >>>> low and hardware acceleration is not critical but in the case of the >>>> encoders where the complexity can be 3x or worse, hardware acceleratio= n >>>> becomes increasingly important >>>> >>>> Stefan >>>> >>> >>> What is being specified as MTI is a format, and not a specific >>> implementation. So, MTI will not take the form of "OpenH264" or >>> "libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8". >>> >>> The same was done for the MTI audio codec, which is Opus, not *libopus*= , >>> which is one specific implementation of the codec. >>> >>> There was a suggestion that the WG also offer a reference implementatio= n >>> of the MTI codec choice, but that seems like it won't happen, nor is it >>> really the purpose of the WG to do so. We are picking from >>> already-existing and implemented formats in the first place. >>> >>> _______________________________________________ >> 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 > > --047d7b62509e08ec9504ebc73638 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Actually O/A model is asymmetric by default. All you speci= fy in SDP are the codecs you can receive. You are allowed to send a stream = in any codec remote side supports. So if both sides state that they support= codecs X and Y in SDP, one side can send X in one direction and another si= de can send Y in opposite.

_____________
Roman Sh= pount


On Fri, Nov 22, 2013 at 11:40 AM, tim pa= nton <tim@phonefromhere.com> wrote:
Surely this flies in the face of the wh= ole O/A model, which imposes a sort of symmetry on the endpoints ?
(Unl= ess there is some arcane SDP FRACK at play here).

T.


O= n 22 Nov 2013, at 08:24, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

I think this has value. It mig= ht bring apple and Microsoft to the table, since decoding-only is often the= less patent-affecting part.

Silvia.

On 22 Nov 2013 02:24, Martin J. D=FCrst <duerst@it.aoyama.ac= .jp> wrote:
On 2013/11/22 5:02, Stefan Slivinski wrote:
I in no way intended to suggest =A0a specific implementation of a video cod= ec. =A0My question was around whether we are voting on requiring decoders (= my assumption) or both encoders and decoders

My understanding is that all the proposals in each instance mean "both= encoder and decoder". So as an example, a proposal of "MUST impl= ement both VP8 and H.264" means "MUST implement both VP8 encoder = and decoder, and H.264 encoder and decoder".

Your question brings up other choices. For example, interoperability would = be satisfied by something like "MUST implement both VP8 and H.264 deco= ders, and MUST implement at least one of VP8 and H.264 encoders".

One condition for this to work is the possibility of asymmetric communicati= on, i.e. if side A implemented only a VP8 encoder, and side B only implemen= ted a H.264 encoder, then traffic A->B would be VP8, whereas traffic B-&= gt;A would be H.264. I don't know the in's and out's of the neg= otiation and protocol machinery to confirm or deny that this is possible.
Choices like the one above definitely open new horizons for Eric's sele= ction generator. But frankly speaking, except for the specific choice of &q= uot;MUST implement both VP8 and H.264 decoders, and MUST implement at least= one of VP8 and H.264 encoders", which is less onerous than "MUST= implement both VP8 and H.264", but still interoperable, I don't s= ee any choices with different requirements for encoders and decoders that w= ould make sense.

Regards, =A0 Martin.


----- Original Message -----
From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
Sent: Thursday, November 21, 2013 01:56 PM
To: rtcweb@ietf.org<rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposed Video Selection Process

On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
I'm a new comer, so just a brief intro: I have a background developing = real time video codecs for embedded devices so I'm in a position to com= ment at a technical level within this group

For clarity purposes the proposed alternatives in Magnus' email on nov = 18th; are we strictly speaking about decoders? =A0Historically mandatory re= quirements are they relate to video compatibility define just the decoders.= =A0Obviously if there is only a single mandatory video decoder this implie= s a mandatory encoder, however in the case where there are 2 mandatory deco= ders only a single encoder is technically required.

Clarifying this is fairly important because in the case of both h264 and vp= 8 (and in the future vp9 and h265) the decoder complexity is fairly low and= hardware acceleration is not critical but in the case of the encoders wher= e the complexity can be 3x or worse, hardware acceleration becomes increasi= ngly important

Stefan

What is being specified as MTI is a format, and not a specific
implementation. =A0So, MTI will not take the form of "OpenH264" o= r
"libvpx", but rather, "H.264 Constrainted Baseline Profile&q= uot; or "VP8".

The same was done for the MTI audio codec, which is Opus, not *libopus*, which is one specific implementation of the codec.

There was a suggestion that the WG also offer a reference implementation of the MTI codec choice, but that seems like it won't happen, nor is it=
really the purpose of the WG to do so. =A0We are picking from
already-existing and implemented formats in the first place.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb


__________________= _____________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b62509e08ec9504ebc73638-- From sslivinski@lifesize.com Fri Nov 22 09:28:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA69D1AE013 for ; Fri, 22 Nov 2013 09:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9JtjQlmDoqO for ; Fri, 22 Nov 2013 09:28:42 -0800 (PST) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id EFC021AE00C for ; Fri, 22 Nov 2013 09:28:41 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUo+UQRl8rlWy/sVqvnet9ujJ0XsN4/XO@postini.com; Fri, 22 Nov 2013 09:28:35 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 11:23:04 -0600 From: Stefan Slivinski To: Ron , "rtcweb@ietf.org" Date: Fri, 22 Nov 2013 11:23:02 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7npb+pQR2J2XT5RmidbwiTgRntYwAAOUBw Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> References: <20131122171020.GY3245@audi.shelbyville.oz> In-Reply-To: <20131122171020.GY3245@audi.shelbyville.oz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 17:28:45 -0000 You are not going to avoid patent issues with H.261. Even if all patents a= ssociated with the H.261 specification have expired you are going to run in= to generic video patents around motion estimation or rate distortion and ma= ny, many other areas that have not. At the end of the day, if a patent tro= ll sees you have money, they are going to find a way to sue you. -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron Sent: Friday, November 22, 2013 9:10 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 On Fri, Nov 22, 2013 at 05:17:45AM +0000, Mo Zanaty (mzanaty) wrote: > On 11/21/13 12:48, Basil Mohamed Gohar > wrote: > Has anyone actually objected to H.261 being the one MTI codec [...] ? >=20 > Assume this wins and all obey. Chrome does H.261+VP8, Firefox does=20 > H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264.=20 > According to various (incredibly extrapolated, possibly inaccurate and=20 > sometimes > conflicting) sources [1] on who uses what browser, the chance of H.261=20 > fallback is a whopping 30% [2]. Not the minor insignificant case some=20 > had assumed. >=20 > How will these users react to H.261 QCIF/CIF compared to what they use to= day ... You seem to be forgetting that WebRTC is a communication protocol for PEOPL= E, not some one-sided push technology that gives them take it or leave it c= hoices decided by self-interested vendors. So I would assume they'll react the same way they already do. Something along the lines of: "D00d!! Y U use that crap browser!??!111" And then they'll use the amazing text capabilities to paste a download link= for firefox or something. 2 minutes later, problem solved. And they'll be watching each other's cats do fun things in full hi-res glor= y. It's not some accident of fate that the vendor browsers have the poor level= of mindshare that they do, even given the solid advantage of incumbency th= ey should otherwise enjoy. If the only way they think they can compete is via lock in and exclusivity = using codec patents, then that alone speaks for the irrelevancy of those op= inions about what is best for making this standard become ubiquitous. We need to guarantee interoperability between things that claim to implemen= t the standard. Quality of implementation is something that users will jud= ge for themselves, and their mindshare will again gravitate accordingly bet= ween the available options. I'd still much prefer a better codec than H.261 as our baseline, but if the= proprietary patent holders refuse to let us have that, then we need to wor= k with the technology that is available to us. It doesn't take a doctorate in formal logic to connect those dots. This is our next best option for "making the patents evaporate", are people= really now saying they didn't really want that to actually happen after al= l, despite what they said previously? Ron _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Fri Nov 22 09:33:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27BB1AE093 for ; Fri, 22 Nov 2013 09:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJFTPi6x6rz8 for ; Fri, 22 Nov 2013 09:33:49 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5411AE089 for ; Fri, 22 Nov 2013 09:33:49 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so1487677wes.12 for ; Fri, 22 Nov 2013 09:33:41 -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=ka91RvWlfGGwaSR093LEo1y0rU5d2XGAER0gZEmp400=; b=IgkU0BYnIiJiyeoayjKgOTp5MDGQRGRjK7U6JR1wpbFbt9XCnok+Em+5AVo++gNMpC kf9Vw8EVDm2NpjFCl7bJmxa8u+0vxCcRWVtjC4SY7EhJb53NcQwm51XQuT+Th02JVO34 ApIZ+wZIG02NhF0dmBJmAiOYryoTK8hrxEAUXddSbL+pOHwTewoWsi56YVJ6EDru4PZb vslsXL7AhD6GtKGKfQoHiufu7L/KC00Q/bS/ZyB4uU+g1ywJrnCPgyEg1rPqk4gmQkXh fEpt/xD9hPeiyfJH6E3bxw7zMDsQ5Pgyd+7zUKr3JXloQFFkwJ9zV4Q4DrASFn30L4TF GMuw== MIME-Version: 1.0 X-Received: by 10.194.121.228 with SMTP id ln4mr2606872wjb.50.1385141621563; Fri, 22 Nov 2013 09:33:41 -0800 (PST) Received: by 10.227.134.195 with HTTP; Fri, 22 Nov 2013 09:33:41 -0800 (PST) In-Reply-To: References: <8AE7D014-DED6-48EB-99C7-CF9952CF4FA6@apple.com> <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> Date: Fri, 22 Nov 2013 09:33:41 -0800 Message-ID: From: Martin Thomson To: Bjoern Hoehrmann Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 17:33:50 -0000 On 21 November 2013 17:38, Bjoern Hoehrmann wrote: > Like animated GIFs, or sending a bunch of > JPEG images in a row at certain frame rates, resolutions, compression > ratios. There's an RFC for that [RFC 2435] :) From martin.thomson@gmail.com Fri Nov 22 09:39:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CB41AE138 for ; Fri, 22 Nov 2013 09:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xbtyKyinmEH for ; Fri, 22 Nov 2013 09:39:47 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id E30341AE089 for ; Fri, 22 Nov 2013 09:39:46 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id b13so1491125wgh.32 for ; Fri, 22 Nov 2013 09:39:39 -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=Ijv4Sn2dWQhTdstcWp/WRGfiac6CJl9wtwTCUxG4GiQ=; b=n1rl0xKw7pKVIvUg2T30Hxc6Q3WooQCR2kjjmD41Ze8VBSwebP5h42+yFdU4fmjUxF DcTpZT1cQh1utcXa9gWqHmajLRhemp9ZjkQVtyMTiL0EgMtTENtGC/yqxMlXbT2TV2Lw MUSdNNG+6ZLSuE88LMbd5+K2+AIopzdoONE97NMnm/kBs+sLY0jChAtFglb9DnNnnI5w 79pwG8f8Pwe21/aC0EIFb5YmrsNUVVvoAytg4uFpVCbwCLJyZ4i3k6FAmOIruouDVMoM HZZu1jrMhrbnB5GBK5kSokdt/C6y3M0jScmR9BVEsNN6zq4MM2o3wwBJUtPTZzaEpv+M +KrQ== MIME-Version: 1.0 X-Received: by 10.194.240.197 with SMTP id wc5mr11743416wjc.23.1385141979429; Fri, 22 Nov 2013 09:39:39 -0800 (PST) Received: by 10.227.134.195 with HTTP; Fri, 22 Nov 2013 09:39:39 -0800 (PST) In-Reply-To: <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com> References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com> <528F30C1.8040208@it.aoyama.ac.jp> <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com> Date: Fri, 22 Nov 2013 09:39:39 -0800 Message-ID: From: Martin Thomson To: tim panton Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 17:39:48 -0000 On 22 November 2013 08:40, tim panton wrote: > Surely this flies in the face of the whole O/A model, which imposes a sort > of symmetry on the endpoints ? > (Unless there is some arcane SDP FRACK at play here). a=sendonly, a=recvonly aren't arcane. In fact, this is already necessary for cases where encoding is done in a camera. From maikmerten@googlemail.com Fri Nov 22 09:43:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E9F1ADFEE for ; Fri, 22 Nov 2013 09:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9ZNkLP_mGAB for ; Fri, 22 Nov 2013 09:43:34 -0800 (PST) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 940611ADBE5 for ; Fri, 22 Nov 2013 09:43:34 -0800 (PST) Received: by mail-ee0-f51.google.com with SMTP id b15so630307eek.24 for ; Fri, 22 Nov 2013 09:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9qkwbwGl/WgyVuCP2zbSZfpSlPvUwwMJvJJOYhgV7WY=; b=Y7lnZblqm/dddh/reuspiPTO/2XurzFYx0aVFJabMOutdCfvLJ6keWfeXLFDguNtP4 WXzl/okYfReACWZAe9C81+n2LbXbtisne3J5pCFGl23B4uD9xEQ91wKu3sARvMiQjehx FgW8FQrmi/s7O0OA83IIPU8Pka08IFcJ4bDkF0pDA52vH/MlnS+yERhAWygAz3LMZct6 +/71ZpKEfGzPSdWYfsEfM5SJBCCYS2Kvwziy+JC6Q1+oz9FNFnzWIu71v7RbyI1RmpD9 SQIZ8blqGYlb1TAGa6lxd3l1poV8CiBf3vaXTvf4/Ax4MSlRlooKTjVK/h1DhC+lysOY c40w== X-Received: by 10.14.179.130 with SMTP id h2mr17945476eem.34.1385142206943; Fri, 22 Nov 2013 09:43:26 -0800 (PST) Received: from [192.168.2.109] (port-92-201-19-228.dynamic.qsc.de. [92.201.19.228]) by mx.google.com with ESMTPSA id i1sm79307885eeg.0.2013.11.22.09.43.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 09:43:25 -0800 (PST) Message-ID: <528F97B9.6030507@googlemail.com> Date: Fri, 22 Nov 2013 18:43:21 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <528E39F4.4010706@ericsson.com> <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com> <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org> <528E8142.1050309@librevideo.org> <8AE7D014-DED6-48EB-99C7-CF9952CF4FA6@apple.com> In-Reply-To: <8AE7D014-DED6-48EB-99C7-CF9952CF4FA6@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 17:43:36 -0000 Am 22.11.2013 01:57, schrieb David Singer: > well, it’s band-limited and hardly compressed, but within those limits it’s OK. Whereas I seem to recall having trouble getting decent quality out of H.261 no matter what I did with it (but it has been *years* since I used H.261 for anything, and it’s only because I am an old geezer that I used it at all). I provided some samples at https://drive.google.com/file/d/0B11N4VzriA21Z2J2ODlxTmFibmM/edit?usp=sharing I'd say H.261 can do pretty okay-ish at around a Mbps (and is already useful, if not pretty, well below that), but pushing to "visually lossless" has unfavorable bitrate implications: I have a "normal users won't see the difference from the original" encoding of that testing sequence (complete with analog noise from the camera preserved), but it weighs in at 5 Mbps. I would love to try out the QuickTime H.261 encoder, btw. Not sure it's still shipped, but I understand a *de*coder is still there? http://support.apple.com/kb/ht3775 Maik From martin.thomson@gmail.com Fri Nov 22 09:44:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7048E1AE138 for ; Fri, 22 Nov 2013 09:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tqj2qsGyTwE for ; Fri, 22 Nov 2013 09:44:04 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 34D1C1ADBE5 for ; Fri, 22 Nov 2013 09:44:04 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id q58so1454559wes.2 for ; Fri, 22 Nov 2013 09:43:56 -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=LBmXT6mG6qzbyCDn+hApDE/6/LZH9hCSwHlRzYTefYY=; b=kzAPFEianXUIDd9X+LhXNQ7BbPKIWsTc54Daw7tLYvychBhetFokWr7L5jCOrGI75x qHzJRWBP00MvrfwgAZXYUunW0Whove9Ovru0KVtFXZFr6FHAnFVhf44dwWJI4VY5U3u3 mXT4KQvtiiIwnVlX01XEl5fZbE8e01F8cudMKiIhjjxZoiC/HeiTzElRYn1W11i83xk6 ftnmMFUHK0/Fzha8whHTYJbtnCZr2jJYm22dOBsFialJQ7PO+mZdMk1Ego4CWtIoLUAP DV48kotjU2oHQUhJD5SrG4QtRkgQQZnBlh7XfL7LrDueyOqKFetmzV38DR5fQZiVq5u4 7CqA== MIME-Version: 1.0 X-Received: by 10.180.206.18 with SMTP id lk18mr3598168wic.64.1385142236729; Fri, 22 Nov 2013 09:43:56 -0800 (PST) Received: by 10.227.134.195 with HTTP; Fri, 22 Nov 2013 09:43:56 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Nov 2013 09:43:56 -0800 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 17:44:05 -0000 On 22 November 2013 08:53, Justin Uberti wrote: > For 1:many with MCU, I don't understand why you wouldn't do #2, i.e. > transcode. As stated earlier, the bandwidth costs of using an inefficient > codec (which any MCU service will incur) exceed the CPU cost of transcode. That ignores the engineering and latency costs. Not to say that it isn't an option, but that's picking the holes in the wrong part of Mo's argument. From martin.thomson@gmail.com Fri Nov 22 09:55:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3891ADF7C for ; Fri, 22 Nov 2013 09:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TIhu0jVN8aU for ; Fri, 22 Nov 2013 09:55:16 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8B66D1AC7F0 for ; Fri, 22 Nov 2013 09:55:16 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id t61so1474730wes.18 for ; Fri, 22 Nov 2013 09:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=KW4uDieBtu9u7L9+JaZMIjvxsCmtwoxtPRP9ecJILgM=; b=EXb2fuCR17ya67jQxydoWNy7rWZCJNkK21fCyUAP97Bt66STyD2DahqT/2jgd3P7k6 mhpD/XaAisPA5mFE9pSW8nw+QBerTHa0CLVyGBL0TJNI3ZMbaOiQwOOufJuqyJsGQxYK P4xGToihWj85fta2zjyUlw0UoizJs5BHXy03++0X5lIbDoSwxGKsigSeC2BXw5rkrD5l Dgdh3Ac01br5k6IERghS28XTMlICrm9HNhBlZcCKFf6bP4fq4LEmsSmg9ZjSiqaPd3Pn BeEwabkZRYab0ODZ0d2FVlyPK5uN+KADGWg3u4twX68QdCXGZuATLfeINQt6kU4Bvhe4 1Jdw== MIME-Version: 1.0 X-Received: by 10.180.20.102 with SMTP id m6mr3675527wie.22.1385142909069; Fri, 22 Nov 2013 09:55:09 -0800 (PST) Received: by 10.227.134.195 with HTTP; Fri, 22 Nov 2013 09:55:09 -0800 (PST) Date: Fri, 22 Nov 2013 09:55:09 -0800 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Cc: Cullen Jennings Subject: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 17:55:18 -0000 I know that I've been a fan of consent via ICE, but with the decision in Berlin to move to DTLS only, several of us have observed that perhaps RFC 6520 might be a better alternative. We've put together an exploration of the idea here: http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00 The best part of this is that it changes the dynamics (for the better, I think). You don't need to send extra packets if you are actively using the flow. That means that 1:1 sessions won't need to spend extra cycles or bytes on keeping the session live. There are some gotchas for multiparty sessions, but I believe those to be manageable. From tim@phonefromhere.com Fri Nov 22 10:08:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7986F1ADBE5 for ; Fri, 22 Nov 2013 10:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ribJ2xWtlNjG for ; Fri, 22 Nov 2013 10:08:30 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id 375F51AD959 for ; Fri, 22 Nov 2013 10:08:30 -0800 (PST) Received: (qmail 98868 invoked from network); 22 Nov 2013 18:08:22 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 11158 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 22 Nov 2013 18:08:22 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id D7E9118A027C; Fri, 22 Nov 2013 18:08:21 +0000 (GMT) Received: from [10.10.5.18] (205.158.164.101.ptr.us.xo.net [205.158.164.101]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id E602118A0A89; Fri, 22 Nov 2013 18:08:19 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: tim panton In-Reply-To: Date: Fri, 22 Nov 2013 10:08:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.1822) Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 18:08:32 -0000 On 22 Nov 2013, at 09:55, Martin Thomson = wrote: > I know that I've been a fan of consent via ICE, but with the decision > in Berlin to move to DTLS only, several of us have observed that > perhaps RFC 6520 might be a better alternative. >=20 > We've put together an exploration of the idea here: >=20 > http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00 >=20 > The best part of this is that it changes the dynamics (for the better, > I think). You don't need to send extra packets if you are actively > using the flow. That means that 1:1 sessions won't need to spend > extra cycles or bytes on keeping the session live. >=20 > There are some gotchas for multiparty sessions, but I believe those to > be manageable. I have misgivings about this - It feels to me to force a mixing of = layers in the=20 packet handling - At the moment in the implementation I=92m familiar = with, the ICE/DTLS/SRTP=20 state machines are almost completely isolated. This proposal seems (at = first glance) to make them intertwine in a quite complex way - consent is generated = (if I understand it correctly) by any of the layers. Likewise each of the layers needs to know if the = others have generated consent=20 granting packets.=20 If we are to blur the boundaries like this, we should go the whole hog = and get some real benefits - like for example remove some round-trips in session establishment by (say) = carrying the DTLS hello in the same STUN packet as has ICE USE-CANDIDATE set - for example. I=92m against including this sort of change at this stage in the = standards process. T. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From maikmerten@googlemail.com Fri Nov 22 10:09:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BFE1AD959 for ; Fri, 22 Nov 2013 10:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SUz34TQ_LE0 for ; Fri, 22 Nov 2013 10:08:57 -0800 (PST) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9361ADFCE for ; Fri, 22 Nov 2013 10:08:57 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id h14so668840eaj.21 for ; Fri, 22 Nov 2013 10:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fXAkyUYQdG/BOZOO1ql+LRlyszZtbZxxGl/1k9ZpijQ=; b=RTzC6YFk1/3Z2lKM7q2pd+MReRZSh3ux5N2GFjqklQCijaUrXwhRz4hQ84uhpm4c8j w8yzd8p9M2ajoRaH2i+BM01KpMC/F4K8VfUzJ4zycGAcsdL2gJUWxWuqn/7ZFUFshmqd 2F8363suH7kjU4PbPCGwDej9wG4WtzRwruCjsWtvY7zL88cf8YppQVvVc1KkVfgDQGIt 1cGdLNOuNQqvcu+P2744GVzQgb0NA0Arvl0z4qP8+IS3uZm1Qvg+7hq4wX7nV7QkLrM5 PCPXd6eah2v0D4FoHmXmWO2Veq9Td8Cavx+dpdJzCxmd2BgeGPUO7RKiFxs7wLe3ois/ HuxQ== X-Received: by 10.14.47.130 with SMTP id t2mr8904526eeb.12.1385143729770; Fri, 22 Nov 2013 10:08:49 -0800 (PST) Received: from [192.168.2.109] (port-92-201-19-228.dynamic.qsc.de. [92.201.19.228]) by mx.google.com with ESMTPSA id e43sm640849eep.7.2013.11.22.10.08.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 10:08:48 -0800 (PST) Message-ID: <528F9DAD.3030300@googlemail.com> Date: Fri, 22 Nov 2013 19:08:45 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 18:09:00 -0000 Disclaimer: IANAL You can get *sued* for anything from anyone at any time. Trolls are not in the business of making sound claims on technology, they're in the business of getting paid to leave you alone. However, you will have as good a defense as you can get if you can point to a 25 years old reference implementation. Such an old reference implementation (including an encoder) exists for H.261, meaning a set of encoder techniques should be identifiable that is "as safe as it can be". Of course, if your encoder introduces encoding techniques beyond that you're not automatically "safe" anymore. However, the existence of spec-compliant H.261 encoders in the late 1980ies clearly means that old techniques exist that are useful for creating valid H.261 streams. In a nutshell: Doing really old stuff *should* actually improve your standing regarding IPR claims. Of course, a troll might have a nice patent like "Method and apparatus for doing real-time bible lessons over a digital network in the context of hypertext-enabled applications" which might or might not read on any WebRTC implementation, no matter what the codec. The fix for that: Don't implement anything, ever. Maik Am 22.11.2013 18:23, schrieb Stefan Slivinski: > You are not going to avoid patent issues with H.261. Even if all patents associated with the H.261 specification have expired you are going to run into generic video patents around motion estimation or rate distortion and many, many other areas that have not. At the end of the day, if a patent troll sees you have money, they are going to find a way to sue you. > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron > Sent: Friday, November 22, 2013 9:10 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > On Fri, Nov 22, 2013 at 05:17:45AM +0000, Mo Zanaty (mzanaty) wrote: >> On 11/21/13 12:48, Basil Mohamed Gohar > wrote: >> Has anyone actually objected to H.261 being the one MTI codec [...] ? >> >> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does >> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. >> According to various (incredibly extrapolated, possibly inaccurate and >> sometimes >> conflicting) sources [1] on who uses what browser, the chance of H.261 >> fallback is a whopping 30% [2]. Not the minor insignificant case some >> had assumed. >> >> How will these users react to H.261 QCIF/CIF compared to what they use today ... > > You seem to be forgetting that WebRTC is a communication protocol for PEOPLE, not some one-sided push technology that gives them take it or leave it choices decided by self-interested vendors. > > So I would assume they'll react the same way they already do. > Something along the lines of: > > "D00d!! Y U use that crap browser!??!111" > > And then they'll use the amazing text capabilities to paste a download link for firefox or something. > > 2 minutes later, problem solved. > > And they'll be watching each other's cats do fun things in full hi-res glory. > > > It's not some accident of fate that the vendor browsers have the poor level of mindshare that they do, even given the solid advantage of incumbency they should otherwise enjoy. > > If the only way they think they can compete is via lock in and exclusivity using codec patents, then that alone speaks for the irrelevancy of those opinions about what is best for making this standard become ubiquitous. > > > We need to guarantee interoperability between things that claim to implement the standard. Quality of implementation is something that users will judge for themselves, and their mindshare will again gravitate accordingly between the available options. > > I'd still much prefer a better codec than H.261 as our baseline, but if the proprietary patent holders refuse to let us have that, then we need to work with the technology that is available to us. > > It doesn't take a doctorate in formal logic to connect those dots. > > > This is our next best option for "making the patents evaporate", are people really now saying they didn't really want that to actually happen after all, despite what they said previously? > > Ron > > > _______________________________________________ > 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 > From bernard_aboba@hotmail.com Fri Nov 22 10:28:26 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1991ADFE8 for ; Fri, 22 Nov 2013 10:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQsKJcnsU7vo for ; Fri, 22 Nov 2013 10:28:16 -0800 (PST) Received: from blu0-omc3-s11.blu0.hotmail.com (blu0-omc3-s11.blu0.hotmail.com [65.55.116.86]) by ietfa.amsl.com (Postfix) with ESMTP id CACB31ADF89 for ; Fri, 22 Nov 2013 10:28:15 -0800 (PST) Received: from BLU169-W84 ([65.55.116.72]) by blu0-omc3-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Nov 2013 10:28:09 -0800 X-TMN: [3OvaVNX3Pm/pnf7k57ZtFAxdjzhAw+ITqWee71XqMAU=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_211aeaf1-6ab4-417e-be3d-9791c7b1b4d8_" From: Bernard Aboba To: tim panton , Martin Thomson Date: Fri, 22 Nov 2013 10:28:08 -0800 Importance: Normal In-Reply-To: <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com> References: , <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Nov 2013 18:28:09.0445 (UTC) FILETIME=[9838E950:01CEE7B0] Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 18:28:26 -0000 --_211aeaf1-6ab4-417e-be3d-9791c7b1b4d8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > This proposal seems (at first glance) to make them intertwine in a quite = complex way=20 [BA] Might I point out that we already have two mechanisms that affect a se= nder's ability to continue to send to a given receiver: consent and circuit= breakers. So the complexity you speak of is already there. For example= =2C the studies we have seen so far raise questions about whether circuit b= reakers are very likely to fire prior to consent loss=2C potentially shutti= ng off the packet flow even in situations where consent would be provided. = In those situations=2C the ICE consent mechanism serves merely to add ove= rhead while providing little or no additional protection.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 = --_211aeaf1-6ab4-417e-be3d-9791c7b1b4d8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B This proposal seems (at f= irst glance) to make them intertwine in a quite complex way

[BA] Mi= ght I point out that we already have two mechanisms that =3Baffect a se= nder's ability to continue to send to a given receiver: =3Bconsent and = circuit breakers. =3B So the complexity you speak of is already there.&= nbsp=3B For example=2C the studies we have seen so far raise questions abou= t whether circuit breakers are very likely to fire prior to consent loss=2C= potentially shutting off the packet flow even in situations where consent = would be provided. =3B =3B In those situations=2C the ICE consent m= echanism serves merely to add overhead while providing little or no additio= nal protection.
 =3B
 =3B
 =3B
 =3B
 = =3B
 =3B
 =3B
 =3B
 =3B
= --_211aeaf1-6ab4-417e-be3d-9791c7b1b4d8_-- From sslivinski@lifesize.com Fri Nov 22 10:35:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0101AE093 for ; Fri, 22 Nov 2013 10:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5fCOvNpKSE4 for ; Fri, 22 Nov 2013 10:35:39 -0800 (PST) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with SMTP id A5CD91AE009 for ; Fri, 22 Nov 2013 10:35:39 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUo+j89l013wF/xS3DLFacINoVxi2Lcz2@postini.com; Fri, 22 Nov 2013 10:35:32 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 12:27:45 -0600 From: Stefan Slivinski To: Maik Merten , "rtcweb@ietf.org" Date: Fri, 22 Nov 2013 12:27:43 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7nrek6hmuclISISEWpspMjm59X8QAALe8Q Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> In-Reply-To: <528F9DAD.3030300@googlemail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 18:35:42 -0000 The whole argument around H.261 came up as a way around potential patent is= sues. My argument is that it is literally impossible and thus we should no= t have that factor into our decision on what technology to use. Your last point is the most critical, if you're worried about litigation fr= om patent trolls don't do anything or if you do, don't be successful at it. -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maik Merten Sent: Friday, November 22, 2013 10:09 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 Disclaimer: IANAL You can get *sued* for anything from anyone at any time. Trolls are not in = the business of making sound claims on technology, they're in the business = of getting paid to leave you alone. However, you will have as good a defense as you can get if you can point to= a 25 years old reference implementation. Such an old reference implementat= ion (including an encoder) exists for H.261, meaning a set of encoder techn= iques should be identifiable that is "as safe as it can be". Of course, if = your encoder introduces encoding techniques beyond that you're not automati= cally "safe" anymore. However, the existence of spec-compliant H.261 encode= rs in the late 1980ies clearly means that old techniques exist that are use= ful for creating valid H.261 streams. In a nutshell: Doing really old stuff *should* actually improve your standi= ng regarding IPR claims. Of course, a troll might have a nice patent like "Method and apparatus for = doing real-time bible lessons over a digital network in the context of hype= rtext-enabled applications" which might or might not read on any WebRTC imp= lementation, no matter what the codec. The fix for that: Don't implement an= ything, ever. Maik Am 22.11.2013 18:23, schrieb Stefan Slivinski: > You are not going to avoid patent issues with H.261. Even if all patents= associated with the H.261 specification have expired you are going to run = into generic video patents around motion estimation or rate distortion and = many, many other areas that have not. At the end of the day, if a patent t= roll sees you have money, they are going to find a way to sue you. > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron > Sent: Friday, November 22, 2013 9:10 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > On Fri, Nov 22, 2013 at 05:17:45AM +0000, Mo Zanaty (mzanaty) wrote: >> On 11/21/13 12:48, Basil Mohamed Gohar > wrote: >> Has anyone actually objected to H.261 being the one MTI codec [...] ? >> >> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does=20 >> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. >> According to various (incredibly extrapolated, possibly inaccurate=20 >> and sometimes >> conflicting) sources [1] on who uses what browser, the chance of=20 >> H.261 fallback is a whopping 30% [2]. Not the minor insignificant=20 >> case some had assumed. >> >> How will these users react to H.261 QCIF/CIF compared to what they use t= oday ... > > You seem to be forgetting that WebRTC is a communication protocol for PEO= PLE, not some one-sided push technology that gives them take it or leave it= choices decided by self-interested vendors. > > So I would assume they'll react the same way they already do. > Something along the lines of: > > "D00d!! Y U use that crap browser!??!111" > > And then they'll use the amazing text capabilities to paste a download li= nk for firefox or something. > > 2 minutes later, problem solved. > > And they'll be watching each other's cats do fun things in full hi-res gl= ory. > > > It's not some accident of fate that the vendor browsers have the poor lev= el of mindshare that they do, even given the solid advantage of incumbency = they should otherwise enjoy. > > If the only way they think they can compete is via lock in and exclusivit= y using codec patents, then that alone speaks for the irrelevancy of those = opinions about what is best for making this standard become ubiquitous. > > > We need to guarantee interoperability between things that claim to implem= ent the standard. Quality of implementation is something that users will j= udge for themselves, and their mindshare will again gravitate accordingly b= etween the available options. > > I'd still much prefer a better codec than H.261 as our baseline, but if t= he proprietary patent holders refuse to let us have that, then we need to w= ork with the technology that is available to us. > > It doesn't take a doctorate in formal logic to connect those dots. > > > This is our next best option for "making the patents evaporate", are peop= le really now saying they didn't really want that to actually happen after = all, despite what they said previously? > > Ron > > > _______________________________________________ > 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 From martin.thomson@gmail.com Fri Nov 22 10:41:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4381AE1C7 for ; Fri, 22 Nov 2013 10:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eD54IF36VAN for ; Fri, 22 Nov 2013 10:41:15 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 31E791AE1C5 for ; Fri, 22 Nov 2013 10:41:15 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id b13so1675264wgh.4 for ; Fri, 22 Nov 2013 10:41:07 -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:content-transfer-encoding; bh=SoC3+/KJaPvlYkWP0aETFXCnBczaKEh1lloKDDnvtGo=; b=PWQSNJQrTWgGVxF1mYdsbJM/U27vc8OLppoB7FH28Ts8vAqbXrCaVcb+JyaMVKI7E2 Ep+tBf84DzPMK2u1QrbhmPLwizulpxhKOrJXzLzqFR5PPmctI79+b5yGKZHE4IkaqvI3 uf1Xkmv6Jqa6Rf0vQ4BIfx2oEjY8PK3qELAcoezUFJoYtV7t5vCvudVNfBqnEE0mLXcU O+oSfc/B5ukaxS2YXnO2QNSQZ5Z/PTJVyx5m2BNrkXbsKFtZ5yh4CbII+AztpH4SKncy ypZEQUG9/XswyPhAPBjRsQaRpYa4B9ltbGil9fDUff7nDyBbwEoIH9X3/78fmSoIpxVf VpOw== MIME-Version: 1.0 X-Received: by 10.194.110.138 with SMTP id ia10mr11852648wjb.3.1385145667519; Fri, 22 Nov 2013 10:41:07 -0800 (PST) Received: by 10.227.134.195 with HTTP; Fri, 22 Nov 2013 10:41:07 -0800 (PST) In-Reply-To: <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com> References: <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com> Date: Fri, 22 Nov 2013 10:41:07 -0800 Message-ID: From: Martin Thomson To: tim panton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 18:41:17 -0000 Actually, this removes some of the complication. At worst, it just moves i= t. This concentrates all of the logic at the DTLS layer. If you choose to treat it so, ICE no longer needs to play any role in determining consent. DTLS already has a consent mechanism in place (that's the function of the cookie in the handshake, a feature we don't tend to use when running ICE). This expands that to include an ongoing process. The only complications come from the interaction between DTLS and SRTP, a relationship that is already complicated somewhat on the keying layer. I don't know whether anyone implementing DTLS-SRTP also implements DTLS renegotiation and EKT at the same time, but those are the areas where things get tricky. Otherwise, you have a DTLS (or DTLS-SRTP) layer that manages consent. On 22 November 2013 10:08, tim panton wrote: > > On 22 Nov 2013, at 09:55, Martin Thomson wrote= : > >> I know that I've been a fan of consent via ICE, but with the decision >> in Berlin to move to DTLS only, several of us have observed that >> perhaps RFC 6520 might be a better alternative. >> >> We've put together an exploration of the idea here: >> >> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00 >> >> The best part of this is that it changes the dynamics (for the better, >> I think). You don't need to send extra packets if you are actively >> using the flow. That means that 1:1 sessions won't need to spend >> extra cycles or bytes on keeping the session live. >> >> There are some gotchas for multiparty sessions, but I believe those to >> be manageable. > > I have misgivings about this - It feels to me to force a mixing of layers= in the > packet handling - At the moment in the implementation I=E2=80=99m familia= r with, the ICE/DTLS/SRTP > state machines are almost completely isolated. This proposal seems (at fi= rst glance) > to make them intertwine in a quite complex way - consent is generated (if= I understand it correctly) > by any of the layers. Likewise each of the layers needs to know if the ot= hers have generated consent > granting packets. > > If we are to blur the boundaries like this, we should go the whole hog an= d get some real benefits - like > for example remove some round-trips in session establishment by (say) car= rying the DTLS hello in the > same STUN packet as has ICE USE-CANDIDATE set - for example. > > I=E2=80=99m against including this sort of change at this stage in the st= andards process. > > T. > > >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From tim@phonefromhere.com Fri Nov 22 10:41:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD2E1AE1C7 for ; Fri, 22 Nov 2013 10:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU01vITeG-w6 for ; Fri, 22 Nov 2013 10:41:52 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id A2A6C1AE206 for ; Fri, 22 Nov 2013 10:41:51 -0800 (PST) Received: (qmail 8690 invoked from network); 22 Nov 2013 18:41:43 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 11343 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 22 Nov 2013 18:41:43 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id CB02C18A046C; Fri, 22 Nov 2013 18:41:43 +0000 (GMT) Received: from [10.10.5.18] (205.158.164.101.ptr.us.xo.net [205.158.164.101]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 05BC318A0461; Fri, 22 Nov 2013 18:41:36 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: tim panton In-Reply-To: Date: Fri, 22 Nov 2013 10:41:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7ACE36C2-EE49-4EBB-999A-71F92430F8E3@phonefromhere.com> References: , <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1822) Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 18:41:53 -0000 On 22 Nov 2013, at 10:28, Bernard Aboba = wrote: > > This proposal seems (at first glance) to make them intertwine in a = quite complex way=20 >=20 > [BA] Might I point out that we already have two mechanisms that affect = a sender's ability to continue to send to a given receiver: consent and = circuit breakers. So the complexity you speak of is already there. For = example, the studies we have seen so far raise questions about whether = circuit breakers are very likely to fire prior to consent loss, = potentially shutting off the packet flow even in situations where = consent would be provided. In those situations, the ICE consent = mechanism serves merely to add overhead while providing little or no = additional protection. I need to think about that some more, but my first feeling is that the = proposal deepens the interdependency because it means each sender has to = notify a central timer to indicate that a consent-requesting packet has = been sent and kill the deadman=92s handle on the DTLS keep-alive. The = ICE mechanism is clearer - you send the packets anyway with no = dependency on whatever else has been sent. I also need to think about how RTCP plays into this (which isn=92t = mentioned in the draft, and probably should be). This whole discussion makes me yearn for a cleaner non-layered protocol = - like RFC 5456 - but if we are to have layers we should keep them apart = as far as possible. T. =20= From martin.thomson@gmail.com Fri Nov 22 10:44:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8238D1AE393 for ; Fri, 22 Nov 2013 10:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mz6lIBrpjVQm for ; Fri, 22 Nov 2013 10:44:10 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3995E1AE0A4 for ; Fri, 22 Nov 2013 10:44:09 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id a1so1544651wgh.0 for ; Fri, 22 Nov 2013 10:44:01 -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:content-transfer-encoding; bh=cGzawFLUjthVTBWeujpFrS4kfDqeAAWpUX/8seZfEt0=; b=Ud3SplrLhnSMyPxN7+qktj/LzEi50MBVBaMaSEy7AnWbOdTgxOIQnzZ6Ieoe0x+7Ah y4G93++m6Sam7MAGZksZAVZKXlYjv1wKGVkSH1QLvwQjIWTrUWF9Gc1ughJ+i+IQAuOK LyinhO+WLqyzc8qR4gISSNq4rFaM2dSybiczfu+WPxjroYbKoo61VchC13Pn+G5VTjaj GpkFkVxerDBP+pkk3IaEoJvKRGu2NwOCSwCIxypqN/zsRow8fWihxixD73neUfxcWzqW gUscs+90VgKuFw5K3K/p9ghjjmgD8XhASY8JhROOf+CBuEuc9UvRaC8awddRaxTJGuoO afCA== MIME-Version: 1.0 X-Received: by 10.180.20.102 with SMTP id m6mr3850482wie.22.1385145841710; Fri, 22 Nov 2013 10:44:01 -0800 (PST) Received: by 10.227.134.195 with HTTP; Fri, 22 Nov 2013 10:44:01 -0800 (PST) In-Reply-To: <7ACE36C2-EE49-4EBB-999A-71F92430F8E3@phonefromhere.com> References: <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com> <7ACE36C2-EE49-4EBB-999A-71F92430F8E3@phonefromhere.com> Date: Fri, 22 Nov 2013 10:44:01 -0800 Message-ID: From: Martin Thomson To: tim panton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 18:44:11 -0000 On 22 November 2013 10:41, tim panton wrote: > The ICE mechanism is clearer - you send the packets anyway with no depend= ency on whatever else has been sent. If you can tolerate the additional overhead, send a heartbeat when your timer pops. We're not prohibiting it. It's just suboptimal. > I also need to think about how RTCP plays into this (which isn=E2=80=99t = mentioned in the draft, and probably should be). Someone already pointed that out to me. RTCP is authenticated just like RTP, so if they are on the same flow, they both refresh consent. If they are on separate flows, consent is independent. From maikmerten@googlemail.com Fri Nov 22 11:04:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722D61ADFEE for ; Fri, 22 Nov 2013 11:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spBqIXYvD6B8 for ; Fri, 22 Nov 2013 11:04:22 -0800 (PST) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 64B311ADF7C for ; Fri, 22 Nov 2013 11:04:22 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id e49so873898eek.21 for ; Fri, 22 Nov 2013 11:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=O0TNG9OCV/y1fj4b2CEROo7C/tHNUOajc42aPwgRy4I=; b=QUaAOT6HEA/SkC/tMCcFLg/T5fnvmOxn7ciibT/l6SApO22Trsepv13U/BmZqbZ0Xz BLHKakgL8cfc52XdPQzc6+TTuTp5DE1TycnQHsZ1rWF6V5X5NdaQJP5C1Mc5274b9TgD mF6PPVk9zNGZWR0XbxE32ySHaiwwygZfKduoLnJIYswbMSKYkwvv0quiDlWUT9SMpYs8 Rl3ljnIGJGDCvPLGnZUTAPjydhDa+b8BJXjDMlY1pJCCLNg3xqBCOxZ/3UiPB8oABnoS z38m48QXbw8HumTixp5BHC9qHva5/95r+snyG+c797rSiANOgvNPPv3ktFBPXYbndvMd K1+g== X-Received: by 10.14.105.200 with SMTP id k48mr18436523eeg.1.1385147054585; Fri, 22 Nov 2013 11:04:14 -0800 (PST) Received: from [192.168.2.109] (port-92-201-19-228.dynamic.qsc.de. [92.201.19.228]) by mx.google.com with ESMTPSA id h48sm23542860eev.3.2013.11.22.11.04.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 11:04:13 -0800 (PST) Message-ID: <528FAAA8.8060807@googlemail.com> Date: Fri, 22 Nov 2013 20:04:08 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 19:04:25 -0000 While it is indeed impossible to reach absolute safety, there are low-risk scenarios. H.261 enables you to go down a "lowest possible risk" route. Given that the codec discussion was mostly centered around whether certain formats are connected to acceptable risks or not, this has value. Maik Am 22.11.2013 19:27, schrieb Stefan Slivinski: > The whole argument around H.261 came up as a way around potential patent issues. My argument is that it is literally impossible and thus we should not have that factor into our decision on what technology to use. > > Your last point is the most critical, if you're worried about litigation from patent trolls don't do anything or if you do, don't be successful at it. > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maik Merten > Sent: Friday, November 22, 2013 10:09 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > Disclaimer: IANAL > > You can get *sued* for anything from anyone at any time. Trolls are not in the business of making sound claims on technology, they're in the business of getting paid to leave you alone. > > However, you will have as good a defense as you can get if you can point to a 25 years old reference implementation. Such an old reference implementation (including an encoder) exists for H.261, meaning a set of encoder techniques should be identifiable that is "as safe as it can be". Of course, if your encoder introduces encoding techniques beyond that you're not automatically "safe" anymore. However, the existence of spec-compliant H.261 encoders in the late 1980ies clearly means that old techniques exist that are useful for creating valid H.261 streams. > > In a nutshell: Doing really old stuff *should* actually improve your standing regarding IPR claims. > > Of course, a troll might have a nice patent like "Method and apparatus for doing real-time bible lessons over a digital network in the context of hypertext-enabled applications" which might or might not read on any WebRTC implementation, no matter what the codec. The fix for that: Don't implement anything, ever. > > > Maik > > > Am 22.11.2013 18:23, schrieb Stefan Slivinski: >> You are not going to avoid patent issues with H.261. Even if all patents associated with the H.261 specification have expired you are going to run into generic video patents around motion estimation or rate distortion and many, many other areas that have not. At the end of the day, if a patent troll sees you have money, they are going to find a way to sue you. >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron >> Sent: Friday, November 22, 2013 9:10 AM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] H.261 >> >> On Fri, Nov 22, 2013 at 05:17:45AM +0000, Mo Zanaty (mzanaty) wrote: >>> On 11/21/13 12:48, Basil Mohamed Gohar > wrote: >>> Has anyone actually objected to H.261 being the one MTI codec [...] ? >>> >>> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does >>> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. >>> According to various (incredibly extrapolated, possibly inaccurate >>> and sometimes >>> conflicting) sources [1] on who uses what browser, the chance of >>> H.261 fallback is a whopping 30% [2]. Not the minor insignificant >>> case some had assumed. >>> >>> How will these users react to H.261 QCIF/CIF compared to what they use today ... >> >> You seem to be forgetting that WebRTC is a communication protocol for PEOPLE, not some one-sided push technology that gives them take it or leave it choices decided by self-interested vendors. >> >> So I would assume they'll react the same way they already do. >> Something along the lines of: >> >> "D00d!! Y U use that crap browser!??!111" >> >> And then they'll use the amazing text capabilities to paste a download link for firefox or something. >> >> 2 minutes later, problem solved. >> >> And they'll be watching each other's cats do fun things in full hi-res glory. >> >> >> It's not some accident of fate that the vendor browsers have the poor level of mindshare that they do, even given the solid advantage of incumbency they should otherwise enjoy. >> >> If the only way they think they can compete is via lock in and exclusivity using codec patents, then that alone speaks for the irrelevancy of those opinions about what is best for making this standard become ubiquitous. >> >> >> We need to guarantee interoperability between things that claim to implement the standard. Quality of implementation is something that users will judge for themselves, and their mindshare will again gravitate accordingly between the available options. >> >> I'd still much prefer a better codec than H.261 as our baseline, but if the proprietary patent holders refuse to let us have that, then we need to work with the technology that is available to us. >> >> It doesn't take a doctorate in formal logic to connect those dots. >> >> >> This is our next best option for "making the patents evaporate", are people really now saying they didn't really want that to actually happen after all, despite what they said previously? >> >> Ron >> >> >> _______________________________________________ >> 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 > From creslin@digium.com Fri Nov 22 11:10:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251EB1AE1C7 for ; Fri, 22 Nov 2013 11:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhSMZrkojzZQ for ; Fri, 22 Nov 2013 11:10:20 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 263221AE06A for ; Fri, 22 Nov 2013 11:10:19 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z5so1304879lbh.31 for ; Fri, 22 Nov 2013 11:10:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yEwDEZq+NIVwWbAYnkPcl1u38lLqUGCrUwHF+nC/1xU=; b=lJwlU4InYMzjRJueYvSk/VOgIXvJB9P0RV0xfRvAcXthVdF66An7GrJi2K3d+LNx6w kNKzN8pJla1rAY0P5/x1ooy9IgRqeRIUBQ8dA9Y87MewNJr7YQ5JA2LTmVxnY2irg9Je sMRdo7vssk0yRO1mJq2nWoDnT9fjh63ZpQdyfMCG/ZqOqjLVFXhvfaYvlQTJ6IDWNjPS gYqvs+cybxpk9dwZfy8n6DIvzaIzB6jE6eaZREqdm5J4kpSQkpkshTJSHCywXBWwyotV 0za0wu/ZrJxeq7/jzZ6X0Uh2VlTZ0YdIfR4aD5YU8UzkeiLTrcTmS1uKJyIt8sgYdv43 AMKQ== X-Gm-Message-State: ALoCoQmbBf0d9wVuUZtCte0k6nGdx/Z1qYUsAYXwhZO3yiBelCUDJbW2T1xToM/kkccfL/FQ4h/L MIME-Version: 1.0 X-Received: by 10.112.55.212 with SMTP id u20mr10427199lbp.4.1385147412272; Fri, 22 Nov 2013 11:10:12 -0800 (PST) Received: by 10.112.132.102 with HTTP; Fri, 22 Nov 2013 11:10:12 -0800 (PST) In-Reply-To: References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com> <528F30C1.8040208@it.aoyama.ac.jp> <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com> Date: Fri, 22 Nov 2013 13:10:12 -0600 Message-ID: From: Matt Fredrickson To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 19:10:24 -0000 That is my understanding of O/A as well (at least last time I had to deal with this in RFC3264 land). Matthew Fredrickson On Fri, Nov 22, 2013 at 11:19 AM, Roman Shpount wrote: > Actually O/A model is asymmetric by default. All you specify in SDP are t= he > codecs you can receive. You are allowed to send a stream in any codec rem= ote > side supports. So if both sides state that they support codecs X and Y in > SDP, one side can send X in one direction and another side can send Y in > opposite. > > _____________ > Roman Shpount > > > On Fri, Nov 22, 2013 at 11:40 AM, tim panton wrot= e: >> >> Surely this flies in the face of the whole O/A model, which imposes a so= rt >> of symmetry on the endpoints ? >> (Unless there is some arcane SDP FRACK at play here). >> >> T. >> >> >> On 22 Nov 2013, at 08:24, Silvia Pfeiffer >> wrote: >> >> I think this has value. It might bring apple and Microsoft to the table, >> since decoding-only is often the less patent-affecting part. >> >> Silvia. >> >> On 22 Nov 2013 02:24, Martin J. D=FCrst wrote: >>> >>> On 2013/11/22 5:02, Stefan Slivinski wrote: >>>> >>>> I in no way intended to suggest a specific implementation of a video >>>> codec. My question was around whether we are voting on requiring deco= ders >>>> (my assumption) or both encoders and decoders >>> >>> >>> My understanding is that all the proposals in each instance mean "both >>> encoder and decoder". So as an example, a proposal of "MUST implement b= oth >>> VP8 and H.264" means "MUST implement both VP8 encoder and decoder, and = H.264 >>> encoder and decoder". >>> >>> Your question brings up other choices. For example, interoperability >>> would be satisfied by something like "MUST implement both VP8 and H.264 >>> decoders, and MUST implement at least one of VP8 and H.264 encoders". >>> >>> One condition for this to work is the possibility of asymmetric >>> communication, i.e. if side A implemented only a VP8 encoder, and side = B >>> only implemented a H.264 encoder, then traffic A->B would be VP8, where= as >>> traffic B->A would be H.264. I don't know the in's and out's of the >>> negotiation and protocol machinery to confirm or deny that this is poss= ible. >>> >>> Choices like the one above definitely open new horizons for Eric's >>> selection generator. But frankly speaking, except for the specific choi= ce of >>> "MUST implement both VP8 and H.264 decoders, and MUST implement at leas= t one >>> of VP8 and H.264 encoders", which is less onerous than "MUST implement = both >>> VP8 and H.264", but still interoperable, I don't see any choices with >>> different requirements for encoders and decoders that would make sense. >>> >>> Regards, Martin. >>> >>> >>>> ----- Original Message ----- >>>> From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org] >>>> Sent: Thursday, November 21, 2013 01:56 PM >>>> To: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Proposed Video Selection Process >>>> >>>> On 11/21/2013 02:31 PM, Stefan Slivinski wrote: >>>>> >>>>> I'm a new comer, so just a brief intro: I have a background developin= g >>>>> real time video codecs for embedded devices so I'm in a position to c= omment >>>>> at a technical level within this group >>>>> >>>>> For clarity purposes the proposed alternatives in Magnus' email on no= v >>>>> 18th; are we strictly speaking about decoders? Historically mandator= y >>>>> requirements are they relate to video compatibility define just the >>>>> decoders. Obviously if there is only a single mandatory video decode= r this >>>>> implies a mandatory encoder, however in the case where there are 2 ma= ndatory >>>>> decoders only a single encoder is technically required. >>>>> >>>>> Clarifying this is fairly important because in the case of both h264 >>>>> and vp8 (and in the future vp9 and h265) the decoder complexity is fa= irly >>>>> low and hardware acceleration is not critical but in the case of the >>>>> encoders where the complexity can be 3x or worse, hardware accelerati= on >>>>> becomes increasingly important >>>>> >>>>> Stefan >>>> >>>> >>>> What is being specified as MTI is a format, and not a specific >>>> implementation. So, MTI will not take the form of "OpenH264" or >>>> "libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8". >>>> >>>> The same was done for the MTI audio codec, which is Opus, not *libopus= *, >>>> which is one specific implementation of the codec. >>>> >>>> There was a suggestion that the WG also offer a reference implementati= on >>>> of the MTI codec choice, but that seems like it won't happen, nor is i= t >>>> really the purpose of the WG to do so. We are picking from >>>> already-existing and implemented formats in the first place. >>>> >>> _______________________________________________ >>> 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 > From ron@debian.org Fri Nov 22 11:26:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A8E1AE26D for ; Fri, 22 Nov 2013 11:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpKP_8tGbQFn for ; Fri, 22 Nov 2013 11:26:55 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id D38271AE1C2 for ; Fri, 22 Nov 2013 11:26:54 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 23 Nov 2013 05:56:45 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 9409D4F8F3 for ; Sat, 23 Nov 2013 05:56:42 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YGSQl0838B40 for ; Sat, 23 Nov 2013 05:56:41 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 85E1F4F902; Sat, 23 Nov 2013 05:56:41 +1030 (CST) Date: Sat, 23 Nov 2013 05:56:41 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131122192641.GZ3245@audi.shelbyville.oz> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 19:26:57 -0000 On Fri, Nov 22, 2013 at 11:23:02AM -0600, Stefan Slivinski wrote: > You are not going to avoid patent issues with H.261. Even if all patents > associated with the H.261 specification have expired you are going to run > into generic video patents around motion estimation or rate distortion and > many, many other areas that have not. At the end of the day, if a patent > troll sees you have money, they are going to find a way to sue you. You keep repeating this, but it's not clear to me what you are actually arguing here? Are you saying that the concerns of the VP8 objectors are irrelevant since the only confirmed relevant IP is freely licenced (just like H.261 now is), and that we should use it instead? For the people who can't use H.264, the problem is intractable, unless the holders of its patents revise their licence terms, or until they also expire. For the people who say they can't use VP8, the problem is much as you describe, "maybe some mugger will spring out of the hedges", despite the protections provided by its licencing. There seems to be general agreement that the patent risk of H.261 is no greater than for *any* other technology that will go into this standard (will you be allowed to establish a connection with one click?) and that its age provides a certain amount of shelter an implementor could cower under should that be their best choice. When was the last time you heard Stephan agree that some technology was fairly sure to be unencumbered ;? I rest my case ... The interesting question that remains is do we have consensus that the patent risk of MPEG1 is equally minimal (or will be by the time there are implementations of WebRTC using it out in the wild and/or this standard is ratified). If we do, then it remains an option for the MTI video codec. If there is consensus that the fear of it is too great to expose people to, then we only have one "safe" choice left for us to consider that addresses the concerns of those objecting to VP8, and has none of the problems of H.264. As I said right after the last meeting, I think we're still a long way from having exhausted the normal IETF consensus procedures on this question - though we do seem to be at the point where most people now realise their most preferred codec option is going to be steadfastly prevented from achieving consensus by the objections of others. And so we again basically only have 2 options: - Those objections are rejected as vexatious by the chairs and we find that we do have consensus on one of the original preferences. [1] - Those objections are upheld as valid consensus blockers by the chairs, and we need to look at other solutions which address them. The latter is what the people proposing H.261 are directly addressing. I'm not sure which part of that you find confusing. Ron [1] - which would seem to be difficult, assuming they both like their role in the IETF and like it to remain uncontroversial, and like the job they have with their present employers :) From sslivinski@lifesize.com Fri Nov 22 11:36:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CCA1AE1C4 for ; Fri, 22 Nov 2013 11:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdvrsDCddA0l for ; Fri, 22 Nov 2013 11:36:45 -0800 (PST) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with SMTP id DF6621AE073 for ; Fri, 22 Nov 2013 11:36:44 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKUo+yRadwUDw1le/bFSdjBoGgoXEqptJr@postini.com; Fri, 22 Nov 2013 11:36:38 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 13:30:35 -0600 From: Stefan Slivinski To: Maik Merten , "rtcweb@ietf.org" Date: Fri, 22 Nov 2013 13:30:34 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7ntaggmRPKLCbAQeSZcwsmfjmJpgAACJXA Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> In-Reply-To: <528FAAA8.8060807@googlemail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 19:36:48 -0000 No, this is taking things to extremes. This codec hasn't been used in any = industry for 15 years. The entire video conferencing industry uses H.264, = the broadcast industry uses H.264, the streaming video industry uses H.264,= facetime, skype both use H.264. The list goes on and on. There is not a = single company is existence today using H.261 over H.264 because of patent = fears. It is asinine that this is even being discussed. -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maik Merten Sent: Friday, November 22, 2013 11:04 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 While it is indeed impossible to reach absolute safety, there are low-risk = scenarios. H.261 enables you to go down a "lowest possible risk" route. Giv= en that the codec discussion was mostly centered around whether certain for= mats are connected to acceptable risks or not, this has value. Maik Am 22.11.2013 19:27, schrieb Stefan Slivinski: > The whole argument around H.261 came up as a way around potential patent = issues. My argument is that it is literally impossible and thus we should = not have that factor into our decision on what technology to use. > > Your last point is the most critical, if you're worried about litigation = from patent trolls don't do anything or if you do, don't be successful at i= t. > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maik Merten > Sent: Friday, November 22, 2013 10:09 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > Disclaimer: IANAL > > You can get *sued* for anything from anyone at any time. Trolls are not i= n the business of making sound claims on technology, they're in the busines= s of getting paid to leave you alone. > > However, you will have as good a defense as you can get if you can point = to a 25 years old reference implementation. Such an old reference implement= ation (including an encoder) exists for H.261, meaning a set of encoder tec= hniques should be identifiable that is "as safe as it can be". Of course, i= f your encoder introduces encoding techniques beyond that you're not automa= tically "safe" anymore. However, the existence of spec-compliant H.261 enco= ders in the late 1980ies clearly means that old techniques exist that are u= seful for creating valid H.261 streams. > > In a nutshell: Doing really old stuff *should* actually improve your stan= ding regarding IPR claims. > > Of course, a troll might have a nice patent like "Method and apparatus fo= r doing real-time bible lessons over a digital network in the context of hy= pertext-enabled applications" which might or might not read on any WebRTC i= mplementation, no matter what the codec. The fix for that: Don't implement = anything, ever. > > > Maik > > > Am 22.11.2013 18:23, schrieb Stefan Slivinski: >> You are not going to avoid patent issues with H.261. Even if all patent= s associated with the H.261 specification have expired you are going to run= into generic video patents around motion estimation or rate distortion and= many, many other areas that have not. At the end of the day, if a patent = troll sees you have money, they are going to find a way to sue you. >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron >> Sent: Friday, November 22, 2013 9:10 AM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] H.261 >> >> On Fri, Nov 22, 2013 at 05:17:45AM +0000, Mo Zanaty (mzanaty) wrote: >>> On 11/21/13 12:48, Basil Mohamed Gohar > wrote: >>> Has anyone actually objected to H.261 being the one MTI codec [...] ? >>> >>> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does=20 >>> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. >>> According to various (incredibly extrapolated, possibly inaccurate=20 >>> and sometimes >>> conflicting) sources [1] on who uses what browser, the chance of >>> H.261 fallback is a whopping 30% [2]. Not the minor insignificant=20 >>> case some had assumed. >>> >>> How will these users react to H.261 QCIF/CIF compared to what they use = today ... >> >> You seem to be forgetting that WebRTC is a communication protocol for PE= OPLE, not some one-sided push technology that gives them take it or leave i= t choices decided by self-interested vendors. >> >> So I would assume they'll react the same way they already do. >> Something along the lines of: >> >> "D00d!! Y U use that crap browser!??!111" >> >> And then they'll use the amazing text capabilities to paste a download l= ink for firefox or something. >> >> 2 minutes later, problem solved. >> >> And they'll be watching each other's cats do fun things in full hi-res g= lory. >> >> >> It's not some accident of fate that the vendor browsers have the poor le= vel of mindshare that they do, even given the solid advantage of incumbency= they should otherwise enjoy. >> >> If the only way they think they can compete is via lock in and exclusivi= ty using codec patents, then that alone speaks for the irrelevancy of those= opinions about what is best for making this standard become ubiquitous. >> >> >> We need to guarantee interoperability between things that claim to imple= ment the standard. Quality of implementation is something that users will = judge for themselves, and their mindshare will again gravitate accordingly = between the available options. >> >> I'd still much prefer a better codec than H.261 as our baseline, but if = the proprietary patent holders refuse to let us have that, then we need to = work with the technology that is available to us. >> >> It doesn't take a doctorate in formal logic to connect those dots. >> >> >> This is our next best option for "making the patents evaporate", are peo= ple really now saying they didn't really want that to actually happen after= all, despite what they said previously? >> >> Ron >> >> >> _______________________________________________ >> 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 From martin.thomson@gmail.com Fri Nov 22 11:51:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3621AE18B for ; Fri, 22 Nov 2013 11:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCUGYepQlGLH for ; Fri, 22 Nov 2013 11:51:10 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC411AE044 for ; Fri, 22 Nov 2013 11:51:10 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so1641055wes.1 for ; Fri, 22 Nov 2013 11:51:02 -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=ZKpe4/NP/CJMktL/GJwQwCW0Y0WAUC8PPRcb0bGBXJs=; b=OBeFdHEbeJZojH12bcrMLxbDaO3Rm+6MrBh6oQwDAi1OZi4MWOMrVNwpmvSHy8h2BK 0wFbLdfgQMXgkGC239ZDI4OIgUn8NIs3fe4dIyfuxhhbOOhKSzqY4PpsD3ccFWcDpGYh t2qmxt2WXAJBrnsZDJxamSrRf9ZbudTYk4i17SUopoWwUFa6FlMoGWIOsWpZgdtkQEm3 Z+AhpNyRN0F8mITJiLtICvyYOSiYRqf1KGLUrtLN3D38S4k+io0XZGffifaiktFfEJ25 MeLAWRod/7ROzzW8Q7t2j+qBeCRMgb8NY51HhT8DGzOY8uomQYXOrusd3gvtb2jYGB5m 0q5Q== MIME-Version: 1.0 X-Received: by 10.180.9.139 with SMTP id z11mr4075311wia.22.1385149862908; Fri, 22 Nov 2013 11:51:02 -0800 (PST) Received: by 10.227.134.195 with HTTP; Fri, 22 Nov 2013 11:51:02 -0800 (PST) In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> Date: Fri, 22 Nov 2013 11:51:02 -0800 Message-ID: From: Martin Thomson To: Stefan Slivinski Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 19:51:12 -0000 On 22 November 2013 11:30, Stefan Slivinski wrote: > It is asinine that this is even being discussed. +1 From pgiralt@cisco.com Fri Nov 22 11:57:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918C91AE01A for ; Fri, 22 Nov 2013 11:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.026 X-Spam-Level: X-Spam-Status: No, score=-15.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlY1EcxVSdaI for ; Fri, 22 Nov 2013 11:57:11 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 27AAD1ACCEA for ; Fri, 22 Nov 2013 11:57:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8863; q=dns/txt; s=iport; t=1385150224; x=1386359824; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=eyeYCDBK7i7FJfmKOKfGN7TN2Z9QxdoKfZ0r/raqiW4=; b=WEkazNn4qDDNnxpAWgl1kBAIcfIukqu3vD8zoZW6PmU6MxzpOyIAnbu2 V5Z2Cj/Xp/OjAVSc8+jLWlK53EvptsN3FDR6PnffSkwWfNFei3qJabqz7 A383ssdk4si08BFjV/6/MzVLgRfm+3LTlCN0ZudsXg+5x6B9QNZ9dJGZR c=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAKi2j1KtJXG9/2dsb2JhbABPCoMHOLwaToEiFnSCJQEBAQMBAQEBJEcLBQcECw4DBAEBAScHIQYfCQgGE4dvAwkGDbh3DYgnEwSMeIEtBgsBUAcGgxqBEgOJQoZvhXiBa4xahTiDRh6BNQ X-IronPort-AV: E=Sophos;i="4.93,753,1378857600"; d="asc'?scan'208";a="286752425" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 22 Nov 2013 19:57:03 +0000 Received: from pgiralt-macpro.cisco.com (pgiralt-macpro.cisco.com [10.81.96.60]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAMJv2Wa020845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 19:57:03 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_157A422D-0369-4B3E-AFA4-711DE2C5CF00"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Paul Giralt In-Reply-To: Date: Fri, 22 Nov 2013 14:57:01 -0500 Message-Id: <5F326533-23A0-41B1-A4E0-657748F9A948@cisco.com> References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com> <528F30C1.8040208@it.aoyama.ac.jp> <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com> To: Matt Fredrickson X-Mailer: Apple Mail (2.1812) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 19:57:13 -0000 --Apple-Mail=_157A422D-0369-4B3E-AFA4-711DE2C5CF00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I may be missing something but I don't know that this is entirely = correct. =46rom 3264:=20 The list of media formats for each media stream conveys two pieces of information, namely the set of formats (codecs and any parameters associated with the codec, in the case of RTP) that the offerer is capable of sending and/or receiving (depending on the direction attributes), and, in the case of RTP, the RTP payload type numbers used to identify those formats. To me, this means that a capability in an offer or answer (with a = direction attribute of sendrecv) means that you are capable of both = sending and receiving for that particular capability. I don't see a way = where you can specify (within a single m=3D line) that you are capable = of receiving on two of the specified payload types, but only capable of = sending on one of the two. In other words, if an offer or answer = specifies both H.264 and VP8 with a sendrecv attribute, this implies = that you are capable of both sending and receiving both.=20 You could, of course, specify two separate m=3D lines where you specify = both codecs as recvonly and the codec you support for sending as = sendonly, but this is very complicated because now you have two separate = m=3D lines for what really should be one bi-directional stream.=20 Someone please correct me if I'm misunderstanding this.=20 -Paul On Nov 22, 2013, at 2:10 PM, Matt Fredrickson = wrote: > That is my understanding of O/A as well (at least last time I had to > deal with this in RFC3264 land). >=20 > Matthew Fredrickson >=20 > On Fri, Nov 22, 2013 at 11:19 AM, Roman Shpount = wrote: >> Actually O/A model is asymmetric by default. All you specify in SDP = are the >> codecs you can receive. You are allowed to send a stream in any codec = remote >> side supports. So if both sides state that they support codecs X and = Y in >> SDP, one side can send X in one direction and another side can send Y = in >> opposite. >>=20 >> _____________ >> Roman Shpount >>=20 >>=20 >> On Fri, Nov 22, 2013 at 11:40 AM, tim panton = wrote: >>>=20 >>> Surely this flies in the face of the whole O/A model, which imposes = a sort >>> of symmetry on the endpoints ? >>> (Unless there is some arcane SDP FRACK at play here). >>>=20 >>> T. >>>=20 >>>=20 >>> On 22 Nov 2013, at 08:24, Silvia Pfeiffer = >>> wrote: >>>=20 >>> I think this has value. It might bring apple and Microsoft to the = table, >>> since decoding-only is often the less patent-affecting part. >>>=20 >>> Silvia. >>>=20 >>> On 22 Nov 2013 02:24, Martin J. D=FCrst = wrote: >>>>=20 >>>> On 2013/11/22 5:02, Stefan Slivinski wrote: >>>>>=20 >>>>> I in no way intended to suggest a specific implementation of a = video >>>>> codec. My question was around whether we are voting on requiring = decoders >>>>> (my assumption) or both encoders and decoders >>>>=20 >>>>=20 >>>> My understanding is that all the proposals in each instance mean = "both >>>> encoder and decoder". So as an example, a proposal of "MUST = implement both >>>> VP8 and H.264" means "MUST implement both VP8 encoder and decoder, = and H.264 >>>> encoder and decoder". >>>>=20 >>>> Your question brings up other choices. For example, = interoperability >>>> would be satisfied by something like "MUST implement both VP8 and = H.264 >>>> decoders, and MUST implement at least one of VP8 and H.264 = encoders". >>>>=20 >>>> One condition for this to work is the possibility of asymmetric >>>> communication, i.e. if side A implemented only a VP8 encoder, and = side B >>>> only implemented a H.264 encoder, then traffic A->B would be VP8, = whereas >>>> traffic B->A would be H.264. I don't know the in's and out's of the >>>> negotiation and protocol machinery to confirm or deny that this is = possible. >>>>=20 >>>> Choices like the one above definitely open new horizons for Eric's >>>> selection generator. But frankly speaking, except for the specific = choice of >>>> "MUST implement both VP8 and H.264 decoders, and MUST implement at = least one >>>> of VP8 and H.264 encoders", which is less onerous than "MUST = implement both >>>> VP8 and H.264", but still interoperable, I don't see any choices = with >>>> different requirements for encoders and decoders that would make = sense. >>>>=20 >>>> Regards, Martin. >>>>=20 >>>>=20 >>>>> ----- Original Message ----- >>>>> From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org] >>>>> Sent: Thursday, November 21, 2013 01:56 PM >>>>> To: rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] Proposed Video Selection Process >>>>>=20 >>>>> On 11/21/2013 02:31 PM, Stefan Slivinski wrote: >>>>>>=20 >>>>>> I'm a new comer, so just a brief intro: I have a background = developing >>>>>> real time video codecs for embedded devices so I'm in a position = to comment >>>>>> at a technical level within this group >>>>>>=20 >>>>>> For clarity purposes the proposed alternatives in Magnus' email = on nov >>>>>> 18th; are we strictly speaking about decoders? Historically = mandatory >>>>>> requirements are they relate to video compatibility define just = the >>>>>> decoders. Obviously if there is only a single mandatory video = decoder this >>>>>> implies a mandatory encoder, however in the case where there are = 2 mandatory >>>>>> decoders only a single encoder is technically required. >>>>>>=20 >>>>>> Clarifying this is fairly important because in the case of both = h264 >>>>>> and vp8 (and in the future vp9 and h265) the decoder complexity = is fairly >>>>>> low and hardware acceleration is not critical but in the case of = the >>>>>> encoders where the complexity can be 3x or worse, hardware = acceleration >>>>>> becomes increasingly important >>>>>>=20 >>>>>> Stefan >>>>>=20 >>>>>=20 >>>>> What is being specified as MTI is a format, and not a specific >>>>> implementation. So, MTI will not take the form of "OpenH264" or >>>>> "libvpx", but rather, "H.264 Constrainted Baseline Profile" or = "VP8". >>>>>=20 >>>>> The same was done for the MTI audio codec, which is Opus, not = *libopus*, >>>>> which is one specific implementation of the codec. >>>>>=20 >>>>> There was a suggestion that the WG also offer a reference = implementation >>>>> of the MTI codec choice, but that seems like it won't happen, nor = is it >>>>> really the purpose of the WG to do so. We are picking from >>>>> already-existing and implemented formats in the first place. >>>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_157A422D-0369-4B3E-AFA4-711DE2C5CF00 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSj7cNAAoJEADWV7cDInKs9PMP/3oEJ1RNmiZEwDXlzH1edESL UzDWOfesmumEj8UQiNI7j3fsSU5SDct0dfRpCiYHJkPvY4tfQdsZxWteZ1NAfxTq Yh3LB1imj4Cj09uBlK39TcpyF0CZx0lOFVVDA3QiWSfA3ksKlO3Ebeh9/8ifNTRY nEUZFinL682vnt61z1QyshM20LnA42Uj8NNKe10e5R1nO8OnyGGKP2QzP90Ny+Mt 2Otuccg/OZlwso8tqZeFCGc8+0aLC/J76CrfZNnWy8TP4GKxZY38HSTr3O0vIxhQ 2Q7mCYP64FKjeUrakq3MOVEecQnYj7enon7FRdtkNQiBQeIJxGW50Bg2f09pqbEX QXPQp3oGVA92t4GANloHHNzR4fZoY9MQdAIUQWxbV/pvXLmzzyaovZrkjNef0owM v9zLLwyNG7krYhu4GPsPC+vEC07GoTkOzhwkl/B6ihTvkYqqLyaJ+lKrtfBmxoc7 01fgJ0qHgkfjNJmOi/70j/XpLEhxvaU5y+vrC3d1XsXqiXyYocvgKrQb5anyhud/ BIaTECtD49gqcTzklfRRifMWzhJ0I+DKzIG3yBndhDQ53bsLSb/8/NAThs0usPWn iM2GZ2jJpi4kxI7VmaeTHhSWunlSeGGa2scOFjjJzdvgH85IhxgdsokH1nJJ5/YI gt/ufRhQz0mE2m6suhHa =Xjea -----END PGP SIGNATURE----- --Apple-Mail=_157A422D-0369-4B3E-AFA4-711DE2C5CF00-- From miconda@gmail.com Fri Nov 22 11:59:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C325D1AE046 for ; Fri, 22 Nov 2013 11:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmcUtKo9MXWt for ; Fri, 22 Nov 2013 11:59:40 -0800 (PST) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id F34451AE01A for ; Fri, 22 Nov 2013 11:59:39 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id r15so714358ead.38 for ; Fri, 22 Nov 2013 11:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hh3yS6XiZqAwbg6m0J9G6KW9oPcKsZ756Vakw6fwbS4=; b=EdKt8gYFfKpksVod140QYiN2rxOqYnyzb/7BUlKZUp3qJvuUVU63dQjM4zqhNpoMWf JqRhHyeiDT+Pp8ennJM85GgQMBMghnwJbjI5UJdQnScX59lzBGmoOezwfasxG600sFe4 5ibHAyaY/MRPQXbextZpa1FntddSo4xZmKHPFfuZ1uSNMGFHKp5pilHn60kLje/C1JYU QkqlvUnW7fuQiWQtB3FrKZ20bX5oqsj/PjXByfG0KUmk+4F4xjF6oZHUfmbv3PT6lo3R FGPZ6cGdCrQbkEeaIuum3AYIyn+8ZmJ5d9tagHt9teNWfn9jOIK52TwjH4b6Voq1DLkQ eWoQ== X-Received: by 10.14.8.136 with SMTP id 8mr10973272eer.25.1385150371667; Fri, 22 Nov 2013 11:59:31 -0800 (PST) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id z1sm80035455eeo.14.2013.11.22.11.59.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 11:59:30 -0800 (PST) Message-ID: <528FB79F.8090405@gmail.com> Date: Fri, 22 Nov 2013 20:59:27 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: Stefan Slivinski , Maik Merten , "rtcweb@ietf.org" References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com 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, 22 Nov 2013 19:59:41 -0000 On 11/22/13 8:30 PM, Stefan Slivinski wrote: > No, this is taking things to extremes. This codec hasn't been used in any industry for 15 years. The entire video conferencing industry uses H.264, the broadcast industry uses H.264, the streaming video industry uses H.264, facetime, skype both use H.264. The list goes on and on. There is not a single company is existence today using H.261 over H.264 because of patent fears. It is asinine that this is even being discussed. You misunderstood the issue. h264 has already an incompatible licensing policy for many situations, especially towards open source. Not using h264 is not about fears of new patents, but because of the conditions imposed by exiting patents. The vp8 vs h261 is actually the case when today none of them has a known/final incompatible license, but of course, the future is not known. Against vp8 there are some claims, but none with a final decision in court (some already dismissed in early stages). Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From singer@apple.com Fri Nov 22 12:01:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4E61AE087 for ; Fri, 22 Nov 2013 12:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.427 X-Spam-Level: X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJC6mXtqzsCd for ; Fri, 22 Nov 2013 12:01:46 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 15EA81AE01A for ; Fri, 22 Nov 2013 12:01:46 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWO008BVKX0UIH0@mail-out.apple.com> for rtcweb@ietf.org; Fri, 22 Nov 2013 12:01:39 -0800 (PST) X-AuditID: 11807153-b7f246d000005e2f-0a-528fb822f0a4 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id C5.24.24111.228BF825; Fri, 22 Nov 2013 12:01:38 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWO00JRYKYQ2N30@spicerack.apple.com> for rtcweb@ietf.org; Fri, 22 Nov 2013 12:01:38 -0800 (PST) From: David Singer In-reply-to: Date: Fri, 22 Nov 2013 12:01:37 -0800 Content-transfer-encoding: quoted-printable Message-id: <02B96CE8-A6D9-4288-B052-FB54B07447FB@apple.com> References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> <528EBAB0.2010906@librevideo.org> <528EBD4C.8070504@librevideo.org> To: Justin Uberti X-Mailer: Apple Mail (2.1822) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FCsoau0oz/IYOJ7E4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8bL/LHPBcc6KE7s0GhivsncxcnJICJhIdN/rYYGwxSQu3FvP 1sXIxSEkMJlJYveFF4wQzmomiffPdzJ3MXJwMAvoSdy/qAXSwAtk3mq+zwxiCwuYSXy43wE2 lE1AVeLBnGOMIDanQLDE8geLwGwWoPi87+/B6pkFXCSWtX5ih7C1JZ68u8AKMdNGYt6+n0wg tpDAFSaJhZPtQGwRATWJh7N2sUIcKiux+/l35gmMArMQLpqF5KJZSKYuYGRexShQlJqTWGms l1hQkJOql5yfu4kRHHSFwTsY/yyzOsQowMGoxMO7w7IvSIg1say4MvcQowQHs5IIr+WC/iAh 3pTEyqrUovz4otKc1OJDjNIcLErivDPmA6UE0hNLUrNTUwtSi2CyTBycUg2Mmo+SSzZXl8Vc SDht9OTWtpfswkx9Lvf2yBTH23IfsH3lUJx34JVlbVXYmafNs+75/dS5LKv4cvfmxLuZGybL 6jxZwOD08EufIVff4RIrnkeHP4SdCT633nVn2eGn/+/6bUoVab5/zFVX4995gfi0TWVh752O 2pz+siz65Um9Z6Gu7Xw/L29dqcRSnJFoqMVcVJwIAKGwN9E2AgAA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 20:01:47 -0000 On Nov 21, 2013, at 18:18 , Justin Uberti wrote: > Stefan Wenger posted a fairly detailed analysis of the H.263 = situation, which I think also applies to MPEG-2. I=92m not sure I=92d call that a detailed analysis; a detailed analysis = would include, for example, opening up the 31/34 patent statements for = each codec, identifying the patents, and seeing whether they had yet = expired. Stephan gave an =91informed opinion=92 that, for him, the = increased performance was balanced by increased risk: On Nov 18, 2013, at 8:35 , Stephan Wenger wrote: > So is it worth evaluating H.263 further? IMO, probably not. It=B9s > doubtless technically better than H.261, but the risk is = inproportionally > higher. And the whole idea of this substandard baseline codec has = been to > be essentially without risk. but given the prevalence of the use of H.263 in existing systems and = standards, I am not at all convinced we should give up on it so quickly. I am not knocking his opinion, you understand, just questioning whether = we should discard H.263 based on just this one opinion. David Singer Multimedia and Software Standards, Apple Inc. From singer@apple.com Fri Nov 22 12:08:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA4F1AE1F4 for ; Fri, 22 Nov 2013 12:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.427 X-Spam-Level: X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eErxMnsOG7oM for ; Fri, 22 Nov 2013 12:08:43 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id A37391AE19D for ; Fri, 22 Nov 2013 12:08:43 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWO00HN4L9M7E71@mail-out.apple.com> for rtcweb@ietf.org; Fri, 22 Nov 2013 12:08:18 -0800 (PST) X-AuditID: 11807165-b7f8e6d000004de8-a6-528fb9b2a94d Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 9E.A4.19944.2B9BF825; Fri, 22 Nov 2013 12:08:18 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWO00J30L9U2N40@spicerack.apple.com> for rtcweb@ietf.org; Fri, 22 Nov 2013 12:08:18 -0800 (PST) From: David Singer In-reply-to: <20131122192641.GZ3245@audi.shelbyville.oz> Date: Fri, 22 Nov 2013 12:08:17 -0800 Content-transfer-encoding: quoted-printable Message-id: <064C9CF2-F291-40C9-B2B8-826AEACFFE5D@apple.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <20131122192641.GZ3245@audi.shelbyville.oz> To: Ron X-Mailer: Apple Mail (2.1822) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FCsobtpZ3+QwdfXvBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9mkEywFF1grfkxPbmDcztLFyMkhIWAi8eNXKzOELSZx4d56 ti5GLg4hgclMErvmPmGGcFYzSXxfcp+9i5GDg1lAT+L+RS2QBl4g81bzfbBmYQFpiS2X7jKC 2GwCqhIP5hwDszkFLCQWLtwAtowFKN5x/AgriM0sICzx/fE9FghbW+LJuwusEDNtJE6u2M4I sfceo8SbE1vAFogISEi8ef8Y6lJZid3PvzNPYBSYhXDSLCQnzUIydgEj8ypGgaLUnMRKc73E goKcVL3k/NxNjOCwK0zdwdi43OoQowAHoxIP7w7LviAh1sSy4srcQ4wSHMxKIryWC/qDhHhT EiurUovy44tKc1KLDzFKc7AoifPq7QBKCaQnlqRmp6YWpBbBZJk4OKUaGKVcpTgjnEtEG9xc 7h9N2LLsS1Aol0biEfvozJjAV8w8hzWjKmoe5Qe93Ttjt/iBLYfvXdLSTLi4XayQd5bVcfOY P6r1l7WXfTJgfj3z1TL1H03CqRHfNs286XNtbWfilqPvPT6Ento3N+67bsqOtYl6flUyLUGx XF4xZVmXrnyNUCq55LlbTImlOCPRUIu5qDgRAFvjQgY3AgAA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 20:08:44 -0000 Um On Nov 22, 2013, at 11:26 , Ron wrote: > For the people who say they can't use VP8, the problem is much as you > describe, "maybe some mugger will spring out of the hedges", despite > the protections provided by its licencing. It=92s much worse than that. The IETF has a formal =93will not license=94= on the table, and there are active lawsuits. For most standards = bodies, a =93will not license=94 statement requires an analysis, and = removal of technology as needed. Now, it may be that the analysis and = lawsuits end up revealing that the patents do not, in fact, read. But = we cannot just assume that. David Singer Multimedia and Software Standards, Apple Inc. From ron@debian.org Fri Nov 22 12:12:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92311AE417 for ; Fri, 22 Nov 2013 12:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3iuYNBFpMyg for ; Fri, 22 Nov 2013 12:12:38 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id EFBAB1AE40A for ; Fri, 22 Nov 2013 12:12:37 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 23 Nov 2013 06:42:30 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id EE3CF4F8F3 for ; Sat, 23 Nov 2013 06:42:28 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id r0jHrGmNqO88 for ; Sat, 23 Nov 2013 06:42:28 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 5CF114F902; Sat, 23 Nov 2013 06:42:28 +1030 (CST) Date: Sat, 23 Nov 2013 06:42:28 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131122201228.GA3245@audi.shelbyville.oz> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 20:12:40 -0000 On Fri, Nov 22, 2013 at 01:30:34PM -0600, Stefan Slivinski wrote: > No, this is taking things to extremes. This codec hasn't been used in any > industry for 15 years. The entire video conferencing industry uses H.264, > the broadcast industry uses H.264, the streaming video industry uses H.264, > facetime, skype both use H.264. The list goes on and on. And this working group exists precisely _because_ the other solutions in existence today all have obvious failings. A solution that depended on technology with a restrictive licence that prevented many potential implementors from being able to deploy it would just be a very long winded way of adding one to the number of failed solutions in this space. So we _can't_ choose H.264 which has exactly that problem. We're also told we can't choose VP8 "because patent fears". One of those problems has a potential solution available to us. > There is not a single company is existence today using H.261 over H.264 > because of patent fears. It is asinine that this is even being discussed. I especially like the irony that obstinate fearmongering of unknown VP8 patents are exactly why we're now resigned to discussing it. Thanks for the giggle. Hee Haw, Ron From sslivinski@lifesize.com Fri Nov 22 12:14:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95091AE25E for ; Fri, 22 Nov 2013 12:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFlWmBl8z_Fm for ; Fri, 22 Nov 2013 12:14:54 -0800 (PST) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with SMTP id 7345B1AE0F6 for ; Fri, 22 Nov 2013 12:14:54 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKUo+7MJIcXPYpfFiqNkGGzflo2ciUU+2A@postini.com; Fri, 22 Nov 2013 12:14:47 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 14:11:02 -0600 From: Stefan Slivinski To: "miconda@gmail.com" , Maik Merten , "rtcweb@ietf.org" Date: Fri, 22 Nov 2013 14:11:00 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7nvV2Os5Pzwy5hRwy2s1xvawJbYQAAJ3hw Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> In-Reply-To: <528FB79F.8090405@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 20:14:57 -0000 As I'm sure everyone in this group is aware, Cisco has provided an open sou= rce implementation of H.264 and they will cover the patent licensing fees. = Seems like this would be a good option for the little guys worried about d= ealing with the mpeg-la -----Original Message----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]=20 Sent: Friday, November 22, 2013 11:59 AM To: Stefan Slivinski; Maik Merten; rtcweb@ietf.org Subject: Re: [rtcweb] H.261 On 11/22/13 8:30 PM, Stefan Slivinski wrote: > No, this is taking things to extremes. This codec hasn't been used in an= y industry for 15 years. The entire video conferencing industry uses H.264= , the broadcast industry uses H.264, the streaming video industry uses H.26= 4, facetime, skype both use H.264. The list goes on and on. There is not = a single company is existence today using H.261 over H.264 because of paten= t fears. It is asinine that this is even being discussed. You misunderstood the issue. h264 has already an incompatible licensing pol= icy for many situations, especially towards open source. Not using h264 is not about fears of new patents, but because of the conditions impos= ed by exiting patents. The vp8 vs h261 is actually the case when today none of them has a known/fi= nal incompatible license, but of course, the future is not known. Against v= p8 there are some claims, but none with a final decision in court (some alr= eady dismissed in early stages). Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/mico= nda - http://www.linkedin.com/in/miconda From ekr@rtfm.com Fri Nov 22 12:18:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5391AE022 for ; Fri, 22 Nov 2013 12:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcU3VviUh1xv for ; Fri, 22 Nov 2013 12:18:15 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id AFBCD1AE25E for ; Fri, 22 Nov 2013 12:18:14 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id ca18so1278494wib.10 for ; Fri, 22 Nov 2013 12:18:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7auH295j4st3vlYQHW58jys/wgLBx+R7tpHAqSKzsxA=; b=DvyoMmhnNFkgWqtd1rL4+SltEo9SS5VG5vWhNLkFLJ0oKuQBWGTMKiL5+xc+xZ4jHN 2eImwoBrgrELrarsQlgYVa0my4bEp18fUmDgBSij32Jyz/jwCfeGxT9FABthyC9HOx49 7QT4GuDbnG92kkVs/Fy1FzSdUwcwXHwyaXc8hdZaVVnjMXCwjtstyzqphKWj//opuHpR uoivTRyBSGOCW6+3e6qolx0K5EBg9luJSFRwcI1JlI7yFlRAZs9ElgizRufWlhfpUefL 7P9kbg+j+eWASRA9w9iEwUEVdsigSM4kA9wSBcYDg2k4V03Cljf5+wE21N1kIedSaQ51 ivHA== X-Gm-Message-State: ALoCoQk2CiFFQC1KfH66gCZ1GilVpmJK1NQ0JaHbK9j11LbK9TY6J167BYmPMBCl1eZUZTIcg5NE X-Received: by 10.180.205.233 with SMTP id lj9mr4153906wic.24.1385151485857; Fri, 22 Nov 2013 12:18:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Fri, 22 Nov 2013 12:17:25 -0800 (PST) X-Originating-IP: [63.245.220.224] In-Reply-To: <20131122201228.GA3245@audi.shelbyville.oz> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <20131122201228.GA3245@audi.shelbyville.oz> From: Eric Rescorla Date: Fri, 22 Nov 2013 12:17:25 -0800 Message-ID: To: Ron Content-Type: multipart/alternative; boundary=001a11c261284667c204ebc9b68d Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 20:18:16 -0000 --001a11c261284667c204ebc9b68d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 22, 2013 at 12:12 PM, Ron wrote: > On Fri, Nov 22, 2013 at 01:30:34PM -0600, Stefan Slivinski wrote: > > No, this is taking things to extremes. This codec hasn't been used in > any > > industry for 15 years. The entire video conferencing industry uses > H.264, > > the broadcast industry uses H.264, the streaming video industry uses > H.264, > > facetime, skype both use H.264. The list goes on and on. > > And this working group exists precisely _because_ the other solutions in > existence today all have obvious failings. > Well, all technologies have failings--generally obvious ones--but it's certainly not correct that RTCWEB exists because of failings in the media codecs used by previous solutions. -Ekr --001a11c261284667c204ebc9b68d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Nov 22, 2013 at 12:12 PM, Ron <ron@debian.org> = wrote:
On Fri, Nov 22, 2013 at 01:30:34PM -060= 0, Stefan Slivinski wrote:
> No, this is taking things to extremes. =A0This codec hasn't been u= sed in any
> industry for 15 years. =A0The entire video conferencing industry uses = H.264,
> the broadcast industry uses H.264, the streaming video industry uses H= .264,
> facetime, skype both use H.264. =A0The list goes on and on.

And this working group exists precisely _because_ the other solutions= in
existence today all have obvious failings.

<= div>Well, all technologies have failings--generally obvious ones--but it= 9;s certainly
not correct that RTCWEB exists because of failings = in the media codecs
used by previous solutions.

-Ekr
--001a11c261284667c204ebc9b68d-- From basilgohar@librevideo.org Fri Nov 22 12:19:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36CA1AE27B for ; Fri, 22 Nov 2013 12:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ladq5Qt6KeAF for ; Fri, 22 Nov 2013 12:19:25 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9941AE022 for ; Fri, 22 Nov 2013 12:19:25 -0800 (PST) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 4A60865985E for ; Fri, 22 Nov 2013 15:19:18 -0500 (EST) Message-ID: <528FBC43.5000409@librevideo.org> Date: Fri, 22 Nov 2013 15:19:15 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 20:19:28 -0000 Stefan, I am not trying to be condescending or put down your comments, but actually, a lot of what you are bringing up now has been discussed on this list earlier, and we still arrived where we're at. The Cisco offer, if and when it actual reaches fruition, solves some but not all problems with using H.264 as an MTI codec. It definitely widens the audience that can use H.264 in some cases, but there are definitely use cases it does not cover, because H.264 *itself* is not licensed in a way that is usable. I'd like to point you to this posting [1] I made years ago after a long interview process with a representative from MPEG-LA, which reaches some interesting conclusions. [1] http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/ On 11/22/2013 03:11 PM, Stefan Slivinski wrote: > As I'm sure everyone in this group is aware, Cisco has provided an open source implementation of H.264 and they will cover the patent licensing fees. Seems like this would be a good option for the little guys worried about dealing with the mpeg-la > > -----Original Message----- > From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] > Sent: Friday, November 22, 2013 11:59 AM > To: Stefan Slivinski; Maik Merten; rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > > On 11/22/13 8:30 PM, Stefan Slivinski wrote: >> No, this is taking things to extremes. This codec hasn't been used in any industry for 15 years. The entire video conferencing industry uses H.264, the broadcast industry uses H.264, the streaming video industry uses H.264, facetime, skype both use H.264. The list goes on and on. There is not a single company is existence today using H.261 over H.264 because of patent fears. It is asinine that this is even being discussed. > > You misunderstood the issue. h264 has already an incompatible licensing policy for many situations, especially towards open source. Not using > h264 is not about fears of new patents, but because of the conditions imposed by exiting patents. > > The vp8 vs h261 is actually the case when today none of them has a known/final incompatible license, but of course, the future is not known. Against vp8 there are some claims, but none with a final decision in court (some already dismissed in early stages). > > Daniel > > -- > Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Libre Video http://librevideo.org From miconda@gmail.com Fri Nov 22 12:22:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47201AE28D for ; Fri, 22 Nov 2013 12:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPq0x7q8VCiU for ; Fri, 22 Nov 2013 12:22:54 -0800 (PST) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id BE6341AE022 for ; Fri, 22 Nov 2013 12:22:53 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id o10so932770eaj.41 for ; Fri, 22 Nov 2013 12:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uYc9dYbfROG/tKtImWrvktQuRIvKS7eFGL17FbwmSsc=; b=qLI9Lgfq9WPf9K8zc8jKl3uwFrrGmPt3FwrmESKNAb/04SxwiskWtroI182fpQRIw3 Du8n3TMq4N/vbKdv71A/j2GXjEQq6yL17Vs46RwM3fdL5+iK9ilsMi/+dSzTk7fx90a6 xar1eGPZ4cK8kE6VtzOuyJyTswG/46UTHz6cICuOUQnybCkQJtCTo4d4GIHhYLW1UTDx 55CDjAT/E+HPo1PcE0GWfTpHQAdrWSp1hLq77B8sDp4H15sd6Y5A3P3FKlA5UhsjSjyJ Ij/CzAHwebrLFZIOoz4gYAD0vSxue+Z2ZIgR+rCc5B67jBkAZ+wJHcMDto8H8b59gmVx rQhQ== X-Received: by 10.15.74.193 with SMTP id j41mr3969906eey.41.1385151766235; Fri, 22 Nov 2013 12:22:46 -0800 (PST) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id x4sm80039619eef.1.2013.11.22.12.22.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 12:22:45 -0800 (PST) Message-ID: <528FBD13.5040801@gmail.com> Date: Fri, 22 Nov 2013 21:22:43 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: Stefan Slivinski , Maik Merten , "rtcweb@ietf.org" References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com 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, 22 Nov 2013 20:22:56 -0000 On 11/22/13 9:11 PM, Stefan Slivinski wrote: > As I'm sure everyone in this group is aware, Cisco has provided an open source implementation of H.264 and they will cover the patent licensing fees. Seems like this would be a good option for the little guys worried about dealing with the mpeg-la Maybe you haven't understood the Cisco deal either -- they are not covering the license for the open source version, only for the binary version that one has to always download from cisco. They plan to release the sources under BSD, but who wants to use them directly, they have to deal with mpeg-la. I am sure if you go back to archive and read the discussion, you will find all these (and even more) aspects that makes Cisco offer unfeasible in many situations. Daniel > > -----Original Message----- > From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] > Sent: Friday, November 22, 2013 11:59 AM > To: Stefan Slivinski; Maik Merten; rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > > On 11/22/13 8:30 PM, Stefan Slivinski wrote: >> No, this is taking things to extremes. This codec hasn't been used in any industry for 15 years. The entire video conferencing industry uses H.264, the broadcast industry uses H.264, the streaming video industry uses H.264, facetime, skype both use H.264. The list goes on and on. There is not a single company is existence today using H.261 over H.264 because of patent fears. It is asinine that this is even being discussed. > You misunderstood the issue. h264 has already an incompatible licensing policy for many situations, especially towards open source. Not using > h264 is not about fears of new patents, but because of the conditions imposed by exiting patents. > > The vp8 vs h261 is actually the case when today none of them has a known/final incompatible license, but of course, the future is not known. Against vp8 there are some claims, but none with a final decision in court (some already dismissed in early stages). > > Daniel > > -- > Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From sslivinski@lifesize.com Fri Nov 22 12:51:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85EF1AE18E for ; Fri, 22 Nov 2013 12:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cBwE8QNCLZV for ; Fri, 22 Nov 2013 12:51:20 -0800 (PST) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id 5C5BA1AE0D5 for ; Fri, 22 Nov 2013 12:51:20 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUo/DwPeMc+4a1z86mXC4bNPA3weaX/fx@postini.com; Fri, 22 Nov 2013 12:51:13 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 14:44:42 -0600 From: Stefan Slivinski To: Basil Mohamed Gohar , "rtcweb@ietf.org" Date: Fri, 22 Nov 2013 14:44:39 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7nwCMec+58AEIQTsGsDfNO4ItgbQAAZ0Gw Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E671A@ausmsex00.austin.kmvtechnologies.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> In-Reply-To: <528FBC43.5000409@librevideo.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 20:51:22 -0000 Thank you for the link. The point I'm trying to make is H.261 will harm the proliferation of webrtc= far more than it will help. This is purely a technical argument speaking = to quality and error resiliency. Has anyone listed the concerns surrounding H.264 and have these been raised= with mpeg-la to see if they can make adjustments to the license agreement.= They have certainly done so in the past. -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Basil Mohamed Go= har Sent: Friday, November 22, 2013 12:19 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 Stefan, I am not trying to be condescending or put down your comments, but actually= , a lot of what you are bringing up now has been discussed on this list ear= lier, and we still arrived where we're at. The Cisco offer, if and when it actual reaches fruition, solves some but no= t all problems with using H.264 as an MTI codec. It definitely widens the = audience that can use H.264 in some cases, but there are definitely use cas= es it does not cover, because H.264 *itself* is not licensed in a way that = is usable. I'd like to point you to this posting [1] I made years ago afte= r a long interview process with a representative from MPEG-LA, which reache= s some interesting conclusions. [1] http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-ab= out-avch-264-licensing/ On 11/22/2013 03:11 PM, Stefan Slivinski wrote: > As I'm sure everyone in this group is aware, Cisco has provided an=20 > open source implementation of H.264 and they will cover the patent=20 > licensing fees. Seems like this would be a good option for the little=20 > guys worried about dealing with the mpeg-la >=20 > -----Original Message----- > From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] > Sent: Friday, November 22, 2013 11:59 AM > To: Stefan Slivinski; Maik Merten; rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 >=20 >=20 > On 11/22/13 8:30 PM, Stefan Slivinski wrote: >> No, this is taking things to extremes. This codec hasn't been used in a= ny industry for 15 years. The entire video conferencing industry uses H.26= 4, the broadcast industry uses H.264, the streaming video industry uses H.2= 64, facetime, skype both use H.264. The list goes on and on. There is not= a single company is existence today using H.261 over H.264 because of pate= nt fears. It is asinine that this is even being discussed. >=20 > You misunderstood the issue. h264 has already an incompatible=20 > licensing policy for many situations, especially towards open source.=20 > Not using > h264 is not about fears of new patents, but because of the conditions imp= osed by exiting patents. >=20 > The vp8 vs h261 is actually the case when today none of them has a known/= final incompatible license, but of course, the future is not known. Against= vp8 there are some claims, but none with a final decision in court (some a= lready dismissed in early stages). >=20 > Daniel >=20 > -- > Daniel-Constantin Mierla - http://www.asipto.com=20 > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 -- Libre Video http://librevideo.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From maikmerten@googlemail.com Fri Nov 22 12:55:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721601AE18E for ; Fri, 22 Nov 2013 12:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xemf2kAD2K1Z for ; Fri, 22 Nov 2013 12:55:00 -0800 (PST) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id D9F781AE0D5 for ; Fri, 22 Nov 2013 12:54:59 -0800 (PST) Received: by mail-ee0-f51.google.com with SMTP id b15so729417eek.24 for ; Fri, 22 Nov 2013 12:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=55+kQSuxz/8HcTQ3ZiZcGQdxbf7d4dVJUFMUOGsueUw=; b=AxCriqdARjJSJqylEkQdqou6Wfqi7noTAlku6MkhJ86UW8yupiZE2oFM9hltxMZ54o E5d6lcgrRB5eXAZB8mazn+OO82n3KUw8xfu6g4gfN9MI0c5vhnZBILX4zOu5omgDlfGL gUvIB+VRrEWbTgM1uYwEW+Jgpw2Frz1oJm4iDRxcGb9yYI+lGTs5bV7CN9IizF7sT3v9 j4zfJDoVUlnTFHy4El1oL/YTGTG4eojev4X3c6Es32hUuv7WdGlSUx012ZRZxGhGHxp/ ExqK6JNUMmUq3GXpTKMwt+w5LOmCNSO3uXUdkH46oQcLDQAwtP65VvDGJqHpNkMvx79o CiQA== X-Received: by 10.14.179.130 with SMTP id h2mr19031127eem.34.1385153692322; Fri, 22 Nov 2013 12:54:52 -0800 (PST) Received: from [192.168.2.109] (port-92-201-19-228.dynamic.qsc.de. [92.201.19.228]) by mx.google.com with ESMTPSA id i1sm80164106eeg.0.2013.11.22.12.54.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 12:54:51 -0800 (PST) Message-ID: <528FC497.2080804@googlemail.com> Date: Fri, 22 Nov 2013 21:54:47 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 20:55:02 -0000 Numerous parties have elaborated on why they cannot deploy H.264 due to its licensing terms. In short: Some business or operating models simply cannot be aligned with H.264's licensing terms. It's all in the mailing list archive. And again, H.261 is only considered as fallback option to establish basic video interoperability as no single high-performance video codec can be agreed on. It would only kick into action in situations when the alternative would be "no video at all". This fallback option has to be implementable without relevant restrictions. Of course, if consensus can be reached that more modern codecs such as MPEG-1 Part 2 or H.263 can be implemented and deployed with acceptable risk and without restrictions that would be preferable. Maik Am 22.11.2013 20:30, schrieb Stefan Slivinski: > No, this is taking things to extremes. This codec hasn't been used in any industry for 15 years. The entire video conferencing industry uses H.264, the broadcast industry uses H.264, the streaming video industry uses H.264, facetime, skype both use H.264. The list goes on and on. There is not a single company is existence today using H.261 over H.264 because of patent fears. It is asinine that this is even being discussed. > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maik Merten > Sent: Friday, November 22, 2013 11:04 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > While it is indeed impossible to reach absolute safety, there are low-risk scenarios. H.261 enables you to go down a "lowest possible risk" route. Given that the codec discussion was mostly centered around whether certain formats are connected to acceptable risks or not, this has value. > > Maik > > Am 22.11.2013 19:27, schrieb Stefan Slivinski: >> The whole argument around H.261 came up as a way around potential patent issues. My argument is that it is literally impossible and thus we should not have that factor into our decision on what technology to use. >> >> Your last point is the most critical, if you're worried about litigation from patent trolls don't do anything or if you do, don't be successful at it. >> >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maik Merten >> Sent: Friday, November 22, 2013 10:09 AM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] H.261 >> >> Disclaimer: IANAL >> >> You can get *sued* for anything from anyone at any time. Trolls are not in the business of making sound claims on technology, they're in the business of getting paid to leave you alone. >> >> However, you will have as good a defense as you can get if you can point to a 25 years old reference implementation. Such an old reference implementation (including an encoder) exists for H.261, meaning a set of encoder techniques should be identifiable that is "as safe as it can be". Of course, if your encoder introduces encoding techniques beyond that you're not automatically "safe" anymore. However, the existence of spec-compliant H.261 encoders in the late 1980ies clearly means that old techniques exist that are useful for creating valid H.261 streams. >> >> In a nutshell: Doing really old stuff *should* actually improve your standing regarding IPR claims. >> >> Of course, a troll might have a nice patent like "Method and apparatus for doing real-time bible lessons over a digital network in the context of hypertext-enabled applications" which might or might not read on any WebRTC implementation, no matter what the codec. The fix for that: Don't implement anything, ever. >> >> >> Maik >> >> >> Am 22.11.2013 18:23, schrieb Stefan Slivinski: >>> You are not going to avoid patent issues with H.261. Even if all patents associated with the H.261 specification have expired you are going to run into generic video patents around motion estimation or rate distortion and many, many other areas that have not. At the end of the day, if a patent troll sees you have money, they are going to find a way to sue you. >>> >>> -----Original Message----- >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron >>> Sent: Friday, November 22, 2013 9:10 AM >>> To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] H.261 >>> >>> On Fri, Nov 22, 2013 at 05:17:45AM +0000, Mo Zanaty (mzanaty) wrote: >>>> On 11/21/13 12:48, Basil Mohamed Gohar > wrote: >>>> Has anyone actually objected to H.261 being the one MTI codec [...] ? >>>> >>>> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does >>>> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. >>>> According to various (incredibly extrapolated, possibly inaccurate >>>> and sometimes >>>> conflicting) sources [1] on who uses what browser, the chance of >>>> H.261 fallback is a whopping 30% [2]. Not the minor insignificant >>>> case some had assumed. >>>> >>>> How will these users react to H.261 QCIF/CIF compared to what they use today ... >>> >>> You seem to be forgetting that WebRTC is a communication protocol for PEOPLE, not some one-sided push technology that gives them take it or leave it choices decided by self-interested vendors. >>> >>> So I would assume they'll react the same way they already do. >>> Something along the lines of: >>> >>> "D00d!! Y U use that crap browser!??!111" >>> >>> And then they'll use the amazing text capabilities to paste a download link for firefox or something. >>> >>> 2 minutes later, problem solved. >>> >>> And they'll be watching each other's cats do fun things in full hi-res glory. >>> >>> >>> It's not some accident of fate that the vendor browsers have the poor level of mindshare that they do, even given the solid advantage of incumbency they should otherwise enjoy. >>> >>> If the only way they think they can compete is via lock in and exclusivity using codec patents, then that alone speaks for the irrelevancy of those opinions about what is best for making this standard become ubiquitous. >>> >>> >>> We need to guarantee interoperability between things that claim to implement the standard. Quality of implementation is something that users will judge for themselves, and their mindshare will again gravitate accordingly between the available options. >>> >>> I'd still much prefer a better codec than H.261 as our baseline, but if the proprietary patent holders refuse to let us have that, then we need to work with the technology that is available to us. >>> >>> It doesn't take a doctorate in formal logic to connect those dots. >>> >>> >>> This is our next best option for "making the patents evaporate", are people really now saying they didn't really want that to actually happen after all, despite what they said previously? >>> >>> Ron >>> >>> >>> _______________________________________________ >>> 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 > From basilgohar@librevideo.org Fri Nov 22 12:57:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268A31AE2AE for ; Fri, 22 Nov 2013 12:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csS-x_KUltpi for ; Fri, 22 Nov 2013 12:57:04 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0291AE2A0 for ; Fri, 22 Nov 2013 12:57:04 -0800 (PST) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id B96B0659959 for ; Fri, 22 Nov 2013 15:56:56 -0500 (EST) Message-ID: <528FC513.4020903@librevideo.org> Date: Fri, 22 Nov 2013 15:56:51 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E671A@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E671A@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 20:57:05 -0000 On 11/22/2013 03:44 PM, Stefan Slivinski wrote: > Thank you for the link. > > The point I'm trying to make is H.261 will harm the proliferation of webrtc far more than it will help. This is purely a technical argument speaking to quality and error resiliency. > > Has anyone listed the concerns surrounding H.264 and have these been raised with mpeg-la to see if they can make adjustments to the license agreement. They have certainly done so in the past. Believe it or not, the MPEG-LA is currently trying to establish a royalty-free subset of H.264 called "Constrained Baseline Profile", which is very similar to the most commonly-used subset of H.264 features out there. The problem is, it's not done yet, and there's no indication whether or not it will be successful or not. This would require all existing stakeholders in H.264 licensing to agree to this royalty-free variant for it to matter. There's another effort to do the same with one using MPEG-1 as a base. The problem is, none of these formally exist in royalty-free forms as of yet. Everything else we've discussed, though, does, including H.261. And, for what it's worth, I disagree about H.261. Yes, H.264 and/or VP8 (and a whole list of other codecs) will look *better*, but I think being able to communicate via video over H.261 is better than not being able to all. And we are at a point where "not at all" is going to happen because the WG is effectively split over using VP8 and H.264. -- Libre Video http://librevideo.org From ron@debian.org Fri Nov 22 13:01:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B22F1AE0C2 for ; Fri, 22 Nov 2013 13:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZXpMKMONv9G for ; Fri, 22 Nov 2013 13:01:25 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADFE1AE073 for ; Fri, 22 Nov 2013 13:01:25 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 23 Nov 2013 07:31:16 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 51A3E4F8F3 for ; Sat, 23 Nov 2013 07:31:14 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eqB12UwljqYa for ; Sat, 23 Nov 2013 07:31:13 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 1ADA84F902; Sat, 23 Nov 2013 07:31:13 +1030 (CST) Date: Sat, 23 Nov 2013 07:31:13 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131122210113.GB3245@audi.shelbyville.oz> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <20131122192641.GZ3245@audi.shelbyville.oz> <064C9CF2-F291-40C9-B2B8-826AEACFFE5D@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <064C9CF2-F291-40C9-B2B8-826AEACFFE5D@apple.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 21:01:27 -0000 On Fri, Nov 22, 2013 at 12:08:17PM -0800, David Singer wrote: > Um > > On Nov 22, 2013, at 11:26 , Ron wrote: > > > For the people who say they can't use VP8, the problem is much as you > > describe, "maybe some mugger will spring out of the hedges", despite > > the protections provided by its licencing. > > It’s much worse than that. The IETF has a formal “will not license†on the > table, and there are active lawsuits. For most standards bodies, a “will not > license†statement requires an analysis, and removal of technology as needed. > Now, it may be that the analysis and lawsuits end up revealing that the > patents do not, in fact, read. But we cannot just assume that. As you said yourself just a few minutes ago: > I’m not sure I’d call that a detailed analysis; a detailed analysis would > include, for example, opening up the 31/34 patent statements for each codec, > identifying the patents, and seeing whether they had yet expired. except s/had yet expired/were even remotely relevant/ It is indeed most unfortunate that the IETF disclosure policy allows anyone to make even the most blatantly bogus claim and places no onus on them to correct or retract it even once proven so. I'm yet to see anyone take down their existing support for VP8, or point to a particular section of code that any of that IPR core dump is relevant to in any way. At least one claim has already been dismissed by the court that heard it. And the MTI audio codec has similar bogus claims made for it too (that have since been conclusively refuted but are still up). The timing of the particular mugger you refer to springing from the hedges here will in itself be an interesting point for historians of the future. And maybe for anti-trust lawyers too. I'd also note those patents *still* aren't declared against H.264, despite that being their origin, and that neither the Cisco offer, nor MPEG LA, do licence them. The deafening silence on this is itself a notable concern. People are actively trying to find a workable solution to the concerns that you profess here. Mounting a bipolar argument about which side of the question the onus of proof belongs to depending on what you are arguing for or against makes it a bit tricky to take that professed concern seriously and address it as anything more than simple sophistry. I'm pretty sure that if you can point to which part of the VP8 technology concerns you, people would be very interested in examining that and as you say, removing or reimplementing it as needed. There's surely more scope for fixing it than for fixing H.263 where the patents were designed into it from the outset. Unless you show us the proof where it does, we can only address your claimed concerns as the generic handwaving that they are - with a generically 'accepted as safe' solution. And if we accept that handwaving, then we really can't accept the "implement any 2" solution either. Since that would still have the risk of of the sets becoming disjoint should your vague fear actually ever really play out. Woof, Ron From maikmerten@googlemail.com Fri Nov 22 13:19:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ED31AE265 for ; Fri, 22 Nov 2013 13:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9FEqrpnGrEx for ; Fri, 22 Nov 2013 13:19:48 -0800 (PST) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id EECA11AE23A for ; Fri, 22 Nov 2013 13:19:47 -0800 (PST) Received: by mail-ee0-f51.google.com with SMTP id b15so769349eek.10 for ; Fri, 22 Nov 2013 13:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oSqc4GyqJaiGzGRiAj6VSM0K9ey6NAvayl5o7uwcV0Y=; b=WDT8UkfV0oqxg/jlVVRunL5WoPrYn++uBaaF5nCPa4Ro9J8kWl2A0SwVAH0qWyMYUM 183kJL1YGOPH4X/I/xNWcVY3S0WssFDHJOC/ReXbQH1teXapOptjAc0QoNjy9vbLcbnG MJK7htD1C4Awrd+6N+ntzfhzrIshyQJ3oynR4p+hX3AVs+rh0Z9uQIfDer+KMLzroVPu IRuvEtEyO1eTKgVlDfGOckLGgfuGekzElonCMYzbanosIHpiymUwQ9pHosuCKaMGdTm9 aVgPV1jJrNA97VtSX/ScakWFFEeUZnNHoyBe01z6dbUE5fldWySCHVyZao/ZoQcdad3k RLJA== X-Received: by 10.14.212.72 with SMTP id x48mr19336629eeo.0.1385155180413; Fri, 22 Nov 2013 13:19:40 -0800 (PST) Received: from [192.168.2.109] (port-92-201-19-228.dynamic.qsc.de. [92.201.19.228]) by mx.google.com with ESMTPSA id 1sm80274403eeg.4.2013.11.22.13.19.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 13:19:39 -0800 (PST) Message-ID: <528FCA68.2070309@googlemail.com> Date: Fri, 22 Nov 2013 22:19:36 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> <528EBAB0.2010906@librevideo.org> <528EBD4C.8070504@librevideo.org> <02B96CE8-A6D9-4288-B052-FB54B07447FB@apple.com> In-Reply-To: <02B96CE8-A6D9-4288-B052-FB54B07447FB@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 21:19:49 -0000 Am 22.11.2013 21:01, schrieb David Singer: > I am not knocking his opinion, you understand, just questioning whether we should discard H.263 based on just this one opinion. The overall notion of H.261 being implementable without restrictions is easy to grasp: The technology is over 25 years old, which puts it into the "comfy zone" of patent expiration. It is hard to come up with a scenario where patents covering the original standard and original reference implementation would still be enforceable. H.263 would be vastly preferable in terms of technology level and deployment, but it isn't yet old enough to *automatically* be in the same "comfy zone". It is quite old, but not *that* old. This doesn't mean there actually *are* unavoidable H.263 patents. However, the IPR and licensing situation surrounding H.263 would need to be analyzed thoroughly by professionals and the findings would need to be shared. Does anybody here have the resources to conduct such an analysis? If a credible analysis reveals that H.263 (or MPEG-1 Part 2, that one is also clearly superior to H.261) is actually carrying low risk this would be quite something. Maik From sslivinski@lifesize.com Fri Nov 22 13:20:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E7F1AE265 for ; Fri, 22 Nov 2013 13:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZjOSxl5zq9i for ; Fri, 22 Nov 2013 13:20:37 -0800 (PST) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id 3046F1AE0E5 for ; Fri, 22 Nov 2013 13:20:37 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUo/KnZu0qrlG9c8okfhpxiAsstYOZKbx@postini.com; Fri, 22 Nov 2013 13:20:30 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 15:14:07 -0600 From: Stefan Slivinski To: Basil Mohamed Gohar , "rtcweb@ietf.org" Date: Fri, 22 Nov 2013 15:14:05 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7nxWRRSQF7DzXhQqSnP8XnwIp+JQAAdJrg Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E6731@ausmsex00.austin.kmvtechnologies.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E671A@ausmsex00.austin.kmvtechnologies.com> <528FC513.4020903@librevideo.org> In-Reply-To: <528FC513.4020903@librevideo.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 21:20:41 -0000 Why don't we add the "must support both H.264 and VP8 decode and must suppo= rt at least one of H.264 or VP8 encode" to the list of options and ask for = a show of hands as to what people are in favor of. This would be non-bindi= ng, simply a status check. Maybe no one is in favor of H.261 except for a = vocal minority in which case we're wasting time arguing about it. -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Basil Mohamed Go= har Sent: Friday, November 22, 2013 12:57 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 On 11/22/2013 03:44 PM, Stefan Slivinski wrote: > Thank you for the link. >=20 > The point I'm trying to make is H.261 will harm the proliferation of webr= tc far more than it will help. This is purely a technical argument speakin= g to quality and error resiliency. >=20 > Has anyone listed the concerns surrounding H.264 and have these been rais= ed with mpeg-la to see if they can make adjustments to the license agreemen= t. They have certainly done so in the past. Believe it or not, the MPEG-LA is currently trying to establish a royalty-f= ree subset of H.264 called "Constrained Baseline Profile", which is very si= milar to the most commonly-used subset of H.264 features out there. The problem is, it's not done yet, and there's no indication whether or not= it will be successful or not. This would require all existing stakeholder= s in H.264 licensing to agree to this royalty-free variant for it to matter= . There's another effort to do the same with one using MPEG-1 as a base. The problem is, none of these formally exist in royalty-free forms as of ye= t. Everything else we've discussed, though, does, including H.261. And, for what it's worth, I disagree about H.261. Yes, H.264 and/or VP8 (a= nd a whole list of other codecs) will look *better*, but I think being able= to communicate via video over H.261 is better than not being able to all. And we are at a point where "not at all" is going to happen because the WG = is effectively split over using VP8 and H.264. -- Libre Video http://librevideo.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From quavtum@gmail.com Fri Nov 22 13:54:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206EE1AE241 for ; Fri, 22 Nov 2013 13:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRXQPl0XWmQX for ; Fri, 22 Nov 2013 13:54:08 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9521AE1BA for ; Fri, 22 Nov 2013 13:54:08 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so1695488wgg.4 for ; Fri, 22 Nov 2013 13:54:00 -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=/hSkL6t6Dl8BfbfFP2F7GPBDNZqvLsIVqNq33vuO00A=; b=tQZIacjIP+1WpuRsGyOrL8+Kb990nnQ8utm/H7hu+dS96VaLY7wtv2EyINbXiD+p7x gaB6e93Jbct+bqb0e3L2Qx2VBFH0TdT7ZDSNwguPf3kzqPeIItOGfr6TWkeKEcEzVjJu sXdQVDLZ5wZ8gT6QIDBZtrqmz3FOh9M7skwWZWqCxGigLAZ4RVxLosQCRIreJGlih7Nc AqexqCO2b0dx7uTbChLx2xhGVASs7RG3B/747DjOKdigTN5uOiPp7mOoM4n9W6fF/+QR OF+B7K3O/zMWyGTanudR1zsvx8dH45pBD3cgSx5Dndos4qnds8CeoVPIpn40QwuYmcM6 mW2Q== MIME-Version: 1.0 X-Received: by 10.180.206.18 with SMTP id lk18mr4413306wic.64.1385157240496; Fri, 22 Nov 2013 13:54:00 -0800 (PST) Received: by 10.194.151.6 with HTTP; Fri, 22 Nov 2013 13:54:00 -0800 (PST) In-Reply-To: <528E39F4.4010706@ericsson.com> References: <528E39F4.4010706@ericsson.com> Date: Fri, 22 Nov 2013 13:54:00 -0800 Message-ID: From: "Ashish V. Thapliyal" To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a11c3876a47290004ebcb0d68 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 21:54:10 -0000 --001a11c3876a47290004ebcb0d68 Content-Type: text/plain; charset=ISO-8859-1 Dear Chairs, I have participated in a face-to-face interim meeting in 2012 and have been closely following the discussions on this list. I appreciate your heroic efforts to get to consensus on a mandatory-to-implement video codec. I am against the proposal to put this issue to vote. It will be hard to get it right and it will generate a lot of complaints about who gets to vote and who does not. In my opinion, a fair coin toss, or allowing "either H.264 or VP8" would be preferable. Another interesting proposal, mentioned later in this email thread, is the decoupling of encoder and decoder requirements. In particular, the idea of making both VP8 and H.264 decoders mandatory to implement, while allowing a choice of either VP8 or H.264 encoders, is very interesting. It may provide a good avenue for compromise while giving us most of the benefits of choosing one of the codecs. It may also discourage patent trolling because if one of the encoders gets hit by an unforeseen intellectual property issue, vendors could switch to the other, without waiting for a change in the standards. Thanks, Ashish. --001a11c3876a47290004ebcb0d68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Chairs,
=A0=A0=A0=A0=A0=A0=A0=A0 I have parti= cipated in a face-to-face interim meeting in 2012 and have been closely fol= lowing the discussions on this list.=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0= I appreciate your heroic efforts to get to consensus on a mandatory-to-imp= lement video codec.=A0 I am against the proposal to put this issue to vote.= =A0 It will be hard to get it right and it will generate a lot of complaint= s about who gets to vote and who does not.=A0 In my opinion, a fair coin to= ss, or allowing "either H.264 or VP8" would be preferable.=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0 Another interesting proposal, mentioned later in t= his email thread, is the decoupling of encoder and decoder requirements.=A0= In particular, the idea of making both VP8 and H.264 decoders mandatory to= implement, while allowing a choice of either VP8 or H.264 encoders, is ver= y interesting.=A0 It may provide a good avenue for compromise while giving = us most of the benefits of choosing one of the codecs.=A0 It may also disco= urage patent trolling because if one of the encoders gets hit by an unfores= een intellectual property issue,=A0 vendors could switch to the other, with= out waiting for a change in the standards.=A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0

Thanks,Ashish. =A0 =A0
--001a11c3876a47290004ebcb0d68-- From adam@nostrum.com Fri Nov 22 14:01:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D301AE28E for ; Fri, 22 Nov 2013 14:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwCz3S3TctWL for ; Fri, 22 Nov 2013 14:01:33 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 38F111AE334 for ; Fri, 22 Nov 2013 14:01:33 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAMM1ItJ045188 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Nov 2013 16:01:18 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <528FD429.7090002@nostrum.com> Date: Fri, 22 Nov 2013 16:01:13 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: miconda@gmail.com, Stefan Slivinski , Maik Merten , "rtcweb@ietf.org" References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> In-Reply-To: <528FBD13.5040801@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 22:01:34 -0000 On 11/22/13 14:22, Daniel-Constantin Mierla wrote: > They plan to release the sources under BSD, but who wants to use them > directly, they have to deal with mpeg-la. Every time this kind of statement is made without also including "if they distribute more than 100,000 copies a year", it's a bald misrepresentation of the situation. I'm not saying the 100,000-copy exemption is a silver bullet. But it sure does cut down the number of people who have to deal with MPEG-LA, and completely addresses the "what if I want to have a enterprise disk image?" question. And ignoring it to exaggerate your case doesn't do anyone any favors. /a From keith.drage@alcatel-lucent.com Fri Nov 22 14:08:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4940B1AE15B for ; Fri, 22 Nov 2013 14:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qTgz8R2Oyei for ; Fri, 22 Nov 2013 14:08:20 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 51DFA1ADF50 for ; Fri, 22 Nov 2013 14:08:20 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rAMM863o002170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Nov 2013 16:08:07 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rAMM86SX001702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 23:08:06 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 22 Nov 2013 23:08:06 +0100 From: "DRAGE, Keith (Keith)" To: Silvia Pfeiffer , Adam Roach Thread-Topic: [rtcweb] Proposed Video Selection Process Thread-Index: AQHO5tnjQ/uRvvW18UuSyXVNQo17lJov6xSAgAACNwCAAAr+gIAABK+AgAAG6YCAAXMMwA== Date: Fri, 22 Nov 2013 22:08:05 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0EC014@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <528E39F4.4010706@ericsson.com> <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com> <528E5B47.70702@nostrum.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 22:08:22 -0000 Perhaps we should also add all those that have been active in ITU or ISO/IE= C on the codec discussions. Perhaps we should also add both my grandmothers - I claim they will have in= sight into this issue as they are both dead. Seriously, I don't see how any ballot process will not be open to claims (e= ither real or imagined) that the ballot was compromised in some way. I do n= ot think this is the way to go. Regards Keith=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Silvia Pfeiffer > Sent: 21 November 2013 19:38 > To: Adam Roach > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Proposed Video Selection Process >=20 > On Thu, Nov 21, 2013 at 11:13 AM, Adam Roach wrote: > > On 11/21/13 10:56, Justin Uberti wrote: > >> > >> Following an IETF meeting on Jabber doesn't count as participating? > >> > >> The "big guy vs little guy" narrative continues... > > > > > > I think that's a bit specious. If someone is following the issue at=20 > > such a distance that they haven't expressed an opinion on=20 > the mailing=20 > > list, I can't see how taking a vote from them counts as=20 > anything other=20 > > than simple, old-fashioned ballot stuffing. >=20 > They might have just been active on the W3C webrtc list and=20 > watched here to see what is happening with codecs, but=20 > haven't expressed their position. >=20 >=20 > > I'll take it one step further. I find the prospect that=20 > we're allowing=20 > > blue sheets to stand in for participation to be highly=20 > questionable:=20 > > letting the tourists vote is weighting the opinion of demonstrably=20 > > uninvolved (or > > less-involved) parties at the same level as those who have actually=20 > > been working on the topic. I do not think that a blue-sheet sign in=20 > > without any on-list participation should be sufficient to=20 > participate=20 > > in the kind of process the chairs are proposing. >=20 > We could add that participation on the W3C webrtc list also qualifies. >=20 >=20 > > Or perhaps I'm missing something. Is there something about the=20 > > capabilities of "the little guy" that makes sending an email an=20 > > unrealistically high barrier to entry? >=20 > To address the little guys even more, we could also add that=20 > participation on the discuss-webrtc list also qualifies. >=20 > Just my 2c worth. >=20 > Cheers, > Silvia. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From keith.drage@alcatel-lucent.com Fri Nov 22 14:08:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7F01AE1F5 for ; Fri, 22 Nov 2013 14:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7CHzsW1V_gz for ; Fri, 22 Nov 2013 14:08:22 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A01D41ADF50 for ; Fri, 22 Nov 2013 14:08:22 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rAMM8A24002199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Nov 2013 16:08:11 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rAMM89fe001155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 23:08:09 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 22 Nov 2013 23:08:10 +0100 From: "DRAGE, Keith (Keith)" To: Justin Uberti , Cullen Jennings Thread-Topic: [rtcweb] Proposed Video Selection Process Thread-Index: AQHO5tnjQ/uRvvW18UuSyXVNQo17lJov+PgAgAAJAYCAAAcbgIAAAbSAgAADmgCAAAOpAIAAAjOAgAAbQ4CAAAUBAIABbqLA Date: Fri, 22 Nov 2013 22:08:06 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0EC023@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <528E69E2.9020208@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA8AD7E0@ausmsex00.austin.kmvtechnologies.com> <3249225E-6709-4022-88CF-75020C1A4CEC@iii.ca> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0EC023FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 22:08:24 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B0EC023FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No. Some people, including myself, also want interoperability without transcodi= ng with the existing deployed terminals for video codecs, i.e. so the gatew= ay does not have to implement a transcoder. Those existing deployed termina= ls are essentially H.264. Therefore from my viewpoint on the current proposals, any MTI decision that= makes VP8 a sole MTI does nothing to support this. That I assume is a technical viewpoint? regards Keith ________________________________ From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 21 November 2013 22:32 To: Cullen Jennings Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposed Video Selection Process Even the proposal that recommended H.264 as MTI indicated that the technica= l merit of the currently proposed codecs is equivalent, and the fundamental= question is IPR. http://tools.ietf.org/agenda/88/slides/slides-88-rtcweb-8.pdf Put another way, if the alleged IPR issues associated with either H.264 or = VP8 disappeared overnight, this discussion would be instantly over. On Thu, Nov 21, 2013 at 2:14 PM, Cullen Jennings > wrote: On Nov 21, 2013, at 12:36 PM, Justin Uberti > wrote: > That said, I think the general understanding here is that this is no long= er a technical decision. > I'll note that some people strongly disagree with this is not a technical d= ecision but there are others who do think it is is no longer a technical de= cision. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_949EF20990823C4C85C18D59AA11AD8B0EC023FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
No.
 
Some people, including myself, al= so want interoperability without transcoding with the existing deployed ter= minals for video codecs, i.e. so the gateway does not have to implement a transcoder. Those existing deployed terminals= are essentially H.264.
 
Therefore from my viewpoint on th= e current proposals, any MTI decision that makes VP8 a sole MTI does nothin= g to support this.
 
That I assume is a technical view= point?
 
regards
 
Keith

From: rtcweb [mailto:rtcweb-bounces= @ietf.org] On Behalf Of Justin Uberti
Sent: 21 November 2013 22:32
To: Cullen Jennings
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process

Even the proposal that recommended H.264 as MTI indicated = that the technical merit of the currently proposed codecs is equivalent, an= d the fundamental question is IPR.

Put another way, if the alleged IPR issues associated with either H.26= 4 or VP8 disappeared overnight, this discussion would be instantly over.


On Thu, Nov 21, 2013 at 2:14 PM, Cullen Jennings= <fluffy@iii.ca>= ; wrote:

On Nov 21, 2013, at 12:36 PM, Justin Uberti <juberti@google.com> wrote:

> That said, I think the general understanding here is that this is no l= onger a technical decision.
>

I'll note that some people strongly disagree with this is not a technical d= ecision but there are others who do think it is is no longer a technical de= cision.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--_000_949EF20990823C4C85C18D59AA11AD8B0EC023FR712WXCHMBA11zeu_-- From juberti@google.com Fri Nov 22 14:11:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBB21AE06E for ; Fri, 22 Nov 2013 14:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPiOj3jEB8rs for ; Fri, 22 Nov 2013 14:11:46 -0800 (PST) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E15091ADF50 for ; Fri, 22 Nov 2013 14:11:45 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id oy12so1423528veb.1 for ; Fri, 22 Nov 2013 14:11:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=EFHD1Vxf3wC/kJ9TmC9SD/xgBP/aKlQfowuDP2mJQIY=; b=DXxluRphqvnJzFm4G5PEyqAtYDstMoc5bdJsL42ComBHkt/yZNSycLyhJg1Laohz8l VuJBsdnW414vWzqoPPwt05LrcUJgrM6zX13Wte40PUzc6wrRDnAwHQPOqkS24ygQ7rB9 pTfltmrVeeAB5cO4VDK6EuitIA3rXIo1TYzw2rY8+wgYpAi8L9WE1K0FyGpjMYCJp7Qf YW+X3mt9J9YBk8k35RRxZdEVnMLLK8K/rTJvrctC71go5HBmJPSEexcwWVvvox9JZf6/ vBq/fiygYGYc/7F9UkaRg8POSIauwEIItPW1+H7n8AR51tqESnDYLhoIJb7F168w+4ck 5vkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=EFHD1Vxf3wC/kJ9TmC9SD/xgBP/aKlQfowuDP2mJQIY=; b=LuUL+dCJpPGkEkpmPHcoAaKfqJ1rlPiTAIdynoLEb6k0+f56EX/X2//zXwYmC1uBrj s19fqA0ZELH1jhi9KpD0SxMGZc5AuI6nS+u2WwnMgYNWIoZiS8mAqdPbMU7kIoiu+8x2 9f/RCjuJCTSlTg5g2upWEQfrHaP1cEXqE+5PsPHEpbAFXFiZEUMLr9c9WXO3jAMzXAt7 bQW1Z4NS2IcEHR0Rf+Be753iOuDmNbQPZN+U3NizCN74RwoGVFg5eKuxeHLG3Bv/dTha nmSLpVJKR8KL0Smg5G/QwlX35aaNu57jAGQuDTU/9TvCQcO1ssSBiaxoyQX6whLgfer2 Xmhw== X-Gm-Message-State: ALoCoQlEEf2ziktp5cdNZLZq3MU8oHFSAIQvWVuWD6YMvwH3bWwKOh1/aBjmYFF00TYQbmvcyvj6L0QHIkGrBKFE9ENensB5TCNriklaSZLHrY2ujhmN1NDFG0760w3ivWSyipCFztyy98tkjevwfZ+IgxWdsXIO4JHujWpQSGLmZhP4Sd6eeVGSlNVE4ufy+Ym0Xvl/ahZP X-Received: by 10.52.32.37 with SMTP id f5mr11065232vdi.17.1385158298455; Fri, 22 Nov 2013 14:11:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Fri, 22 Nov 2013 14:11:18 -0800 (PST) From: Justin Uberti Date: Fri, 22 Nov 2013 14:11:18 -0800 Message-ID: To: Paul Giralt Content-Type: multipart/alternative; boundary=bcaec51d2552566a4204ebcb4c98 Cc: "rtcweb@ietf.org" Subject: [rtcweb] Offer/answer for heterogeneous encode/decode X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 22:11:48 -0000 --bcaec51d2552566a4204ebcb4c98 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 22, 2013 at 11:57 AM, Paul Giralt wrote: > I may be missing something but I don't know that this is entirely correct. > From 3264: > > The list of media formats for each media stream conveys two pieces of > information, namely the set of formats (codecs and any parameters > associated with the codec, in the case of RTP) that the offerer is > capable of sending and/or receiving (depending on the direction > attributes), and, in the case of RTP, the RTP payload type numbers > used to identify those formats. > > To me, this means that a capability in an offer or answer (with a > direction attribute of sendrecv) means that you are capable of both sending > and receiving for that particular capability. I don't see a way where you > can specify (within a single m= line) that you are capable of receiving on > two of the specified payload types, but only capable of sending on one of > the two. In other words, if an offer or answer specifies both H.264 and VP8 > with a sendrecv attribute, this implies that you are capable of both > sending and receiving both. > > You could, of course, specify two separate m= lines where you specify both > codecs as recvonly and the codec you support for sending as sendonly, but > this is very complicated because now you have two separate m= lines for > what really should be one bi-directional stream. > > Someone please correct me if I'm misunderstanding this. > > The sender has full discretion of which codec to actually use. Assuming the remote side has offered both codec A and codec B (indicating that they are willing to receive either), the local side can choose to send either A or B, and can switch at any time. >From later on in the paragraph from 3264 that you quoted: If multiple formats are listed, it means that the offerer is capable of making use of any of those formats during the session. In other words, the answerer MAY change formats in the middle of the session, making use of any of the formats listed, without sending a new offer. and later: In all cases, the formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the recipient of the offer SHOULD use the format with the highest preference that is acceptable to it. I certainly think that "is acceptable to it" covers "has an encoder for it". --bcaec51d2552566a4204ebcb4c98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 22, 2013 at 11:57 AM, Paul Giralt <pgiralt@cisco.com> wrote:
I may be missing something but I don't know that this = is entirely correct. From 3264:

=C2=A0 =C2=A0The list of media formats for each media stream conveys two pi= eces of
=C2=A0 =C2=A0information, namely the set of formats (codecs and any paramet= ers
=C2=A0 =C2=A0associated with the codec, in the case of RTP) that the offere= r is
=C2=A0 =C2=A0capable of sending and/or receiving (depending on the directio= n
=C2=A0 =C2=A0attributes), and, in the case of RTP, the RTP payload type num= bers
=C2=A0 =C2=A0used to identify those formats.

To me, this means that a capability in an offer or answer (with a direction= attribute of sendrecv) means that you are capable of both sending and rece= iving for that particular capability. I don't see a way where you can s= pecify (within a single m=3D line) that you are capable of receiving on two= of the specified payload types, but only capable of sending on one of the = two. In other words, if an offer or answer specifies both H.264 and VP8 wit= h a sendrecv attribute, this implies that you are capable of both sending a= nd receiving both.

You could, of course, specify two separate m=3D lines where you specify bot= h codecs as recvonly and the codec you support for sending as sendonly, but= this is very complicated because now you have two separate m=3D lines for = what really should be one bi-directional stream.

Someone please correct me if I'm misunderstanding this.


Th= e sender has full discretion of which codec to actually use. Assuming the r= emote side has offered both codec A and codec B (indicating that they are w= illing to receive either), the local side can choose to send either A or B,= and can switch at any time.

From later on in the paragraph from 3264 that you quote= d:
   If multiple formats are listed, it
   means that the offerer is capable of making use of any of those
   formats during the session.  In other words, the answerer MAY change
   formats in the middle of the session, making use of any of the
   formats listed, without sending a new offer.
and later:


   In all cases, t=
he formats in the "m=3D" line MUST be listed in order of
   preference, with the first format listed being preferred.  In this
   case, preferred means that the recipient of the offer SHOULD use the
   format with the highest preference that is acceptable to it.
I certainly think that &qu=
ot;is acceptable to it" covers "has an encoder for it".
--bcaec51d2552566a4204ebcb4c98-- From gsalguei@cisco.com Fri Nov 22 14:35:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E1A1AE33E; Fri, 22 Nov 2013 14:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hapHW19bnCj0; Fri, 22 Nov 2013 14:35:11 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id D592F1AE307; Fri, 22 Nov 2013 14:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2858; q=dns/txt; s=iport; t=1385159704; x=1386369304; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=F0VBGrCMKpW2W8DV69dFuf9qzwbN80vFvS6OvXtuGbo=; b=F+MlqRQ2GsPPsqgEu0Ap5dmARQ9eIdXz47UJmQ99nD0RHiJN/N/3L4r8 WjoYRHrlokXyeg6ubCjHhLDeafGuVEOfr+xauGBlcJ82i1vtqWkXTAMof 1K+o/gnLIEi4URRVzbKTrM0MOblCGFpHFyhufL06/8HZHruUfz3gVQcdW g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAPjaj1KtJXG9/2dsb2JhbAA/GoMHOFO8FYEfFnSCJQEBAQMBAQEBNxQgEAsCARkDAQINEhAnCgEbAggCBAESCQsHAgSHWgYNNsB4F440VQuDGoESA5gUgTCLI4U/gWqBPoFxOQ X-IronPort-AV: E=Sophos;i="4.93,754,1378857600"; d="scan'208";a="1632156" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-1.cisco.com with ESMTP; 22 Nov 2013 22:35:03 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAMMZ3bZ000320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 22:35:03 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 16:35:02 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "rtcweb@ietf.org" , "public-webrtc@w3.org" , "pntaw@ietf.org" , "tram@ietf.org" Thread-Topic: [rfc-dist] RFC 7064 on URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol Thread-Index: AQHO57KYv93N3ug+fESuZUXbnGRBSA== Date: Fri, 22 Nov 2013 22:35:02 +0000 Message-ID: <09DDE5BA-2A28-4031-AB42-5083F3C6290A@cisco.com> References: <20131122183155.C61FD75E001@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.83] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Fwd: [rfc-dist] RFC 7064 on URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 22:35:12 -0000 [Excuse the cross-post, but I think this is relevant and/or has normative d= ependence.] The STUN URI scheme has been published as RFC. Cheers, Gonzalo Begin forwarded message: > From: > Subject: [rfc-dist] RFC 7064 on URI Scheme for the Session Traversal Util= ities for NAT (STUN) Protocol > Date: November 22, 2013 at 12:31:55 PM CST > To: , > Cc: , >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7064 >=20 > Title: URI Scheme for the Session=20 > Traversal Utilities for NAT (STUN) Protocol=20 > Author: S. Nandakumar, G. Salgueiro, > P. Jones, M. Petit-Huguenin > Status: Standards Track > Stream: IETF > Date: November 2013 > Mailbox: snandaku@cisco.com,=20 > gsalguei@cisco.com,=20 > paulej@packetizer.com, > petithug@acm.org > Pages: 9 > Characters: 15045 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-nandakumar-rtcweb-stun-uri-08.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc7064.txt >=20 > This document specifies the syntax and semantics of the Uniform > Resource Identifier (URI) scheme for the Session Traversal Utilities > for NAT (STUN) protocol. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestio= ns > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see http://www.rfc-editor.org/search/rfc_se= arch.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > rfc-dist mailing list > rfc-dist@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-dist > http://www.rfc-editor.org From basilgohar@librevideo.org Fri Nov 22 14:44:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4931C1AE2D8 for ; Fri, 22 Nov 2013 14:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6vTMSJ_0FMy for ; Fri, 22 Nov 2013 14:44:57 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 50BEF1AE24B for ; Fri, 22 Nov 2013 14:44:57 -0800 (PST) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id CB84E659B48 for ; Fri, 22 Nov 2013 17:44:49 -0500 (EST) Message-ID: <528FDE5E.5080301@librevideo.org> Date: Fri, 22 Nov 2013 17:44:46 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> In-Reply-To: <528FD429.7090002@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 22:44:59 -0000 On 11/22/2013 05:01 PM, Adam Roach wrote: > On 11/22/13 14:22, Daniel-Constantin Mierla wrote: >> They plan to release the sources under BSD, but who wants to use them >> directly, they have to deal with mpeg-la. > > > Every time this kind of statement is made without also including "if > they distribute more than 100,000 copies a year", it's a bald > misrepresentation of the situation. > > I'm not saying the 100,000-copy exemption is a silver bullet. But it > sure does cut down the number of people who have to deal with MPEG-LA, > and completely addresses the "what if I want to have a enterprise disk > image?" question. And ignoring it to exaggerate your case doesn't do > anyone any favors. > > /a Free software projects do not have a reliable mechanism by which to count their distribution, since it is sent out through many means, not the least of which can include direct downloads, SCM code checks (e.g., Github), GNU/Linux and *BSD distibutions (which can easily exceed 100,000 for the most popular ones), to name a few. Where does the liability for counting lie in each of these cases? The licensing restrictions that MPEG-LA has placed on H.264 is very free-software unfriendly for any cases where you want rights to be transitive - which is a key, fundamental aspect of software freedom. -- Libre Video http://librevideo.org From adam@nostrum.com Fri Nov 22 14:54:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE9B1AE0B3 for ; Fri, 22 Nov 2013 14:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, LOTS_OF_MONEY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkpSYTd_Aif3 for ; Fri, 22 Nov 2013 14:54:19 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6991AE1F8 for ; Fri, 22 Nov 2013 14:54:19 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAMMs8tE047393 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Nov 2013 16:54:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <528FE08B.1020908@nostrum.com> Date: Fri, 22 Nov 2013 16:54:03 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Maik Merten , rtcweb@ietf.org References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> <528EBAB0.2010906@librevideo.org> <528EBD4C.8070504@librevideo.org> <02B96CE8-A6D9-4288-B052-FB54B07447FB@apple.com> <528FCA68.2070309@googlemail.com> In-Reply-To: <528FCA68.2070309@googlemail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 22:54:20 -0000 On 11/22/13 15:19, Maik Merten wrote: > It is hard to come up with a scenario where patents covering the > original standard and original reference implementation would still be > enforceable. As a specific example of such a scenario -- one that is tantalizingly close to the subject at hand -- look here: http://www.google.com/patents/US7376184 Read the first paragraph of the description. In layman's terms, it says "even though this patent is being issued in 2008, we claim that it was invented in January of 1992." And with a priority date prior to 1995, this means that they have protection for seventeen years from the date of issuance (i.e., until 2025). Yes, this means that they have patent protection on this specific technique for 33 years after its invention. In US courts, this is 100% legal and fully enforceable, since they started the process prior to 1995. And "prior to 1995" is exactly when we're talking about. /a From ron@debian.org Fri Nov 22 15:31:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F691AE19F for ; Fri, 22 Nov 2013 15:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42YRV11c_WKE for ; Fri, 22 Nov 2013 15:31:41 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id CB0F51AE19E for ; Fri, 22 Nov 2013 15:31:40 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 23 Nov 2013 10:01:33 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id AA9964F8F3 for ; Sat, 23 Nov 2013 09:58:02 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ORT0S9soXBvu for ; Sat, 23 Nov 2013 09:58:01 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 7B5344F902; Sat, 23 Nov 2013 09:58:01 +1030 (CST) Date: Sat, 23 Nov 2013 09:58:01 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131122232801.GC3245@audi.shelbyville.oz> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <528FD429.7090002@nostrum.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 23:31:42 -0000 On Fri, Nov 22, 2013 at 04:01:13PM -0600, Adam Roach wrote: > On 11/22/13 14:22, Daniel-Constantin Mierla wrote: > >They plan to release the sources under BSD, but who wants to use > >them directly, they have to deal with mpeg-la. > > > Every time this kind of statement is made without also including "if > they distribute more than 100,000 copies a year", it's a bald > misrepresentation of the situation. > > I'm not saying the 100,000-copy exemption is a silver bullet. But it > sure does cut down the number of people who have to deal with > MPEG-LA, and completely addresses the "what if I want to have a > enterprise disk image?" question. And ignoring it to exaggerate your > case doesn't do anyone any favors. So to put this into perspective ... If you wrote a piece of software, and made it Free (as in libre) and it got picked up by one or more of the (even moderately popular) distros, then you'd quite likely blow your 100,000 copy limit within just a few days of mirror pushes. Even before anyone may have actually used it at all. And before you deal with the non-MPEG-LA patent holders. Understating the degree to which this is a problem does nobody any favours either. Ron From singer@apple.com Fri Nov 22 15:42:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEC11AE1FE for ; Fri, 22 Nov 2013 15:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.427 X-Spam-Level: X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XeFyxyFZeSH for ; Fri, 22 Nov 2013 15:42:31 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9ED1AE1FD for ; Fri, 22 Nov 2013 15:42:31 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWO0085UV58UI11@mail-out.apple.com> for rtcweb@ietf.org; Fri, 22 Nov 2013 15:42:24 -0800 (PST) X-AuditID: 11807157-b7ff46d000001540-42-528febe05d97 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id D7.B6.05440.0EBEF825; Fri, 22 Nov 2013 15:42:24 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWO000YJV6OFO50@spicerack.apple.com> for rtcweb@ietf.org; Fri, 22 Nov 2013 15:42:24 -0800 (PST) From: David Singer In-reply-to: <528FC497.2080804@googlemail.com> Date: Fri, 22 Nov 2013 15:42:24 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FC497.2080804@googlemail.com> To: Maik Merten X-Mailer: Apple Mail (2.1822) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FCsofvgdX+QwedT6hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/LFF2wFx9grtn3eyNzA2MnWxcjBISFgIrHyblIXIyeQKSZx 4d56oDAXh5DAZCaJrRPbWSCc1UwST05tYgJpYBbQk7h/UQukgRfIvNV8nxnEFhaQlthy6S4j iM0moCrxYM4xMJsTpGbfc1YQmwUofuvCPzYQm1lAXWLp5AYoW1viybsLrBAzbSRmts1kh9h7 hFni85X9YAkRoKLWU8fYIS6Vldj9/DvzBEaBWQgnzUJy0iwkYxcwMq9iFChKzUmsNNFLLCjI SdVLzs/dxAgOu8LwHYz/llkdYhTgYFTiAdreFyTEmlhWXJl7iFGCg1lJhFf5YH+QEG9KYmVV alF+fFFpTmrxIUZpDhYlcd63L4BSAumJJanZqakFqUUwWSYOTqkGRvN/d49Vh8TN2CaSePBd 6rvXSWZsXzpu7q7/sv5gr6sEaytfzrmzXzMXHnnQsWr9psVLkm6KcT23vqWpULUj9gMv5wrh b4vMY7PvfXopyWnOunnuk+mC074cafR4xNRcO0u++0h+gepqB9M2vcM/4uT23g8vmCkue2j/ t1RlezWrGTnXF2b9uafEUpyRaKjFXFScCADJE8DLNwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 23:42:33 -0000 On Nov 22, 2013, at 12:54 , Maik Merten = wrote: > And again, H.261 is only considered as fallback option to establish = basic video interoperability as no single high-performance video codec = can be agreed on. It would only kick into action in situations when the = alternative would be "no video at all". This fallback option has to be = implementable without relevant restrictions. I rather suspect that many, given a choice between: a) deliver crappy video using H.261, with the unstated implication to = the users at the two ends that they really need to find something that = will interoperate on something better and b) tell the users directly that they don=92t have a video codec in = common, and to get video they need to find something that will = interoperate would actually prefer (b). It=92s less work, more direct, and more = honest. David Singer Multimedia and Software Standards, Apple Inc. From pgiralt@cisco.com Fri Nov 22 15:44:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B83B1AE117 for ; Fri, 22 Nov 2013 15:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHBmPjuJfMMr for ; Fri, 22 Nov 2013 15:44:16 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3781AE14B for ; Fri, 22 Nov 2013 15:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9479; q=dns/txt; s=iport; t=1385163849; x=1386373449; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TB8papLWCshZ36n0RxDHDljP0tmivyThznsS5Hcga4Y=; b=NJa+e6WjXjvWotOSNh8SxFxeNMkGB4NYn0YG7U1y0Ik1NSbpkN9waslQ 8QY2pHe8ChsY2Pn+gmbc5bdnthMKQTkweEQqvySDe7wsJQkQdstc/ofZl ctBzxiQsdJLEqLTeYvn8NJMunLxemEXlZY0bWcgV3BrknqyGagvtUgV2P s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAFrrj1KtJXG+/2dsb2JhbABPCoMHgQu8FIEfFnSCJgEBBHkQAgEIDjEHMhQRAgQOBYgBwT+OK1wHgyCBEgOUMYNjkhKDKIFoBQI7 X-IronPort-AV: E=Sophos;i="4.93,755,1378857600"; d="scan'208,217";a="286973602" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 22 Nov 2013 23:44:09 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAMNi88f007708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 23:44:08 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.54]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 17:44:08 -0600 From: "Paul Giralt (pgiralt)" To: Justin Uberti Thread-Topic: Offer/answer for heterogeneous encode/decode Thread-Index: AQHO58/XQlURsOaoj0uaxvupayfvnZoyTmqA Date: Fri, 22 Nov 2013 23:44:07 +0000 Message-ID: <59A91D84-3D29-47C4-8688-CB60844B15D3@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.101.35] Content-Type: multipart/alternative; boundary="_000_59A91D843D2947C48688CB60844B15D3ciscocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 23:44:19 -0000 --_000_59A91D843D2947C48688CB60844B15D3ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Nov 22, 2013, at 5:11 PM, Justin Uberti > wrote: On Fri, Nov 22, 2013 at 11:57 AM, Paul Giralt > wrote: I may be missing something but I don't know that this is entirely correct. = >From 3264: The list of media formats for each media stream conveys two pieces of information, namely the set of formats (codecs and any parameters associated with the codec, in the case of RTP) that the offerer is capable of sending and/or receiving (depending on the direction attributes), and, in the case of RTP, the RTP payload type numbers used to identify those formats. To me, this means that a capability in an offer or answer (with a direction= attribute of sendrecv) means that you are capable of both sending and rece= iving for that particular capability. I don't see a way where you can speci= fy (within a single m=3D line) that you are capable of receiving on two of = the specified payload types, but only capable of sending on one of the two.= In other words, if an offer or answer specifies both H.264 and VP8 with a = sendrecv attribute, this implies that you are capable of both sending and r= eceiving both. You could, of course, specify two separate m=3D lines where you specify bot= h codecs as recvonly and the codec you support for sending as sendonly, but= this is very complicated because now you have two separate m=3D lines for = what really should be one bi-directional stream. Someone please correct me if I'm misunderstanding this. The sender has full discretion of which codec to actually use. Assuming the= remote side has offered both codec A and codec B (indicating that they are= willing to receive either), the local side can choose to send either A or = B, and can switch at any time. >From later on in the paragraph from 3264 that you quoted: If multiple formats are listed, it means that the offerer is capable of making use of any of those formats during the session. In other words, the answerer MAY change formats in the middle of the session, making use of any of the formats listed, without sending a new offer. and later: In all cases, the formats in the "m=3D" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the recipient of the offer SHOULD use the format with the highest preference that is acceptable to it. I certainly think that "is acceptable to it" covers "has an encoder for it"= . While you=92re right that it would work for this scenario, my point was rea= lly that Offer/Answer is not really asymmetric as implied earlier. Take for= example the hypothetical case where you are only able to decode VP8 but on= ly able to encode H.264. If I offer VP8 as my only codec (because it=92s th= e only thing I=92m able to decode therefore I never want anyone to send me = anything other than VP8) I cannot send H.264 in the offer because that impl= ies I=92m able to decode it. The other side then wants to say it can only r= eceive H.264 so it would have to send back an answer with only H.264. I gue= ss there=92s nothing really inherently stopping you from doing this because= as far as I can tell, 3264 only says the answer has to be a subset of the = offer for multicast streams, however how would the answering side know that= the offering side is even capable to receiving H.264? Perhaps Offer/Answer= can technically be asymmetric, but it doesn=92t seem practical to use it t= his way because you cannot really indicate your send and receive capabiliti= es independent of each other. -Paul --_000_59A91D843D2947C48688CB60844B15D3ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <47ED6A102DEFB349A20FBF63D4119A93@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On Nov 22, 2013, at 5:11 PM, Justin Uberti <juberti@google.com> wrote:

On Fri, Nov 22, 2013 at 11:57 AM, Paul Giralt <pgiralt@cisco.co= m> wrote:
I may be missing something but I don't know that this is entirely correct. = >From 3264:

   The list of media formats for each media stream conveys two pi= eces of
   information, namely the set of formats (codecs and any paramet= ers
   associated with the codec, in the case of RTP) that the offere= r is
   capable of sending and/or receiving (depending on the directio= n
   attributes), and, in the case of RTP, the RTP payload type num= bers
   used to identify those formats.

To me, this means that a capability in an offer or answer (with a direction= attribute of sendrecv) means that you are capable of both sending and rece= iving for that particular capability. I don't see a way where you can speci= fy (within a single m=3D line) that you are capable of receiving on two of the specified payload types, but on= ly capable of sending on one of the two. In other words, if an offer or ans= wer specifies both H.264 and VP8 with a sendrecv attribute, this implies th= at you are capable of both sending and receiving both.

You could, of course, specify two separate m=3D lines where you specify bot= h codecs as recvonly and the codec you support for sending as sendonly, but= this is very complicated because now you have two separate m=3D lines for = what really should be one bi-directional stream.

Someone please correct me if I'm misunderstanding this.


The sender has full discretion of which codec to actually use. Assumin= g the remote side has offered both codec A and codec B (indicating that the= y are willing to receive either), the local side can choose to send either = A or B, and can switch at any time.

From later on in the paragraph from 3264 that you quoted:
   If multiple=
 formats are listed, it
   means that the offerer is capable of making use of any of those
   formats during the session.  In other words, the answerer MAY change
   formats in the middle of the session, making use of any of the
   formats listed, without sending a new offer.
and later:
   In all cases, t=
he formats in the "m=3D" line MUST be listed in order of
   preference, with the first format listed being preferred.  In this
   case, preferred means that the recipient of the offer SHOULD use the
   format with the highest preference that is acceptable to it.
I certainly think that &qu=
ot;is acceptable to it" covers "has an encoder for it".

While you=92re right that it would work for this scenario, my point wa= s really that Offer/Answer is not really asymmetric as implied earlier. Tak= e for example the hypothetical case where you are only able to decode VP8 b= ut only able to encode H.264. If I offer VP8 as my only codec (because it=92s the only thing I=92m able to de= code therefore I never want anyone to send me anything other than VP8) I ca= nnot send H.264 in the offer because that implies I=92m able to decode it. = The other side then wants to say it can only receive H.264 so it would have to send back an answer with only H.264= . I guess there=92s nothing really inherently stopping you from doing this = because as far as I can tell, 3264 only says the answer has to be a subset = of the offer for multicast streams, however how would the answering side know that the offering side is even c= apable to receiving H.264? Perhaps Offer/Answer can technically be asymmetr= ic, but it doesn=92t seem practical to use it this way because you cannot r= eally indicate your send and receive capabilities independent of each other. 

-Paul


--_000_59A91D843D2947C48688CB60844B15D3ciscocom_-- From basilgohar@librevideo.org Fri Nov 22 15:44:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7021AE253 for ; Fri, 22 Nov 2013 15:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZVuvqNAH76j for ; Fri, 22 Nov 2013 15:44:36 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 75E551AE14B for ; Fri, 22 Nov 2013 15:44:36 -0800 (PST) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 367ED659C68 for ; Fri, 22 Nov 2013 18:44:29 -0500 (EST) Message-ID: <528FEC5A.8060701@librevideo.org> Date: Fri, 22 Nov 2013 18:44:26 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FC497.2080804@googlemail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 23:44:38 -0000 On 11/22/2013 06:42 PM, David Singer wrote: > > On Nov 22, 2013, at 12:54 , Maik Merten wrote: > >> And again, H.261 is only considered as fallback option to establish basic video interoperability as no single high-performance video codec can be agreed on. It would only kick into action in situations when the alternative would be "no video at all". This fallback option has to be implementable without relevant restrictions. > > I rather suspect that many, given a choice between: > a) deliver crappy video using H.261, with the unstated implication to the users at the two ends that they really need to find something that will interoperate on something better > and > b) tell the users directly that they don’t have a video codec in common, and to get video they need to find something that will interoperate > > would actually prefer (b). It’s less work, more direct, and more honest. > > David Singer > Multimedia and Software Standards, Apple Inc. > Then we need to restate one of the goals of this WG if we're not going to have an MTI. However, I personally disagree with that change. -- Libre Video http://librevideo.org From singer@apple.com Fri Nov 22 15:45:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B551AE253 for ; Fri, 22 Nov 2013 15:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.427 X-Spam-Level: X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gr501HQNsQM6 for ; Fri, 22 Nov 2013 15:45:10 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6375E1AE117 for ; Fri, 22 Nov 2013 15:45:10 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWO00H47VAB7EP1@mail-out.apple.com> for rtcweb@ietf.org; Fri, 22 Nov 2013 15:45:03 -0800 (PST) X-AuditID: 1180715a-b7f3c6d00000020e-8c-528fec7f206e Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 33.1B.00526.F7CEF825; Fri, 22 Nov 2013 15:45:03 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWO0002QVB3FO60@spicerack.apple.com> for rtcweb@ietf.org; Fri, 22 Nov 2013 15:45:03 -0800 (PST) From: David Singer In-reply-to: <528FDE5E.5080301@librevideo.org> Date: Fri, 22 Nov 2013 15:45:02 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> To: Basil Mohamed Gohar X-Mailer: Apple Mail (2.1822) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FCsoVv/pj/I4P1fHou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8ez6BOaCnXwVa+bcY2lgPMLdxcjJISFgIrG34ykjhC0mceHe ejYQW0hgMpPElCX8XYxcQPZqJomva7uZuxg5OJgF9CTuX9QCqeEFMm8132cGsYUFpCW2XLoL NodNQFXiwZxjYDYnUM3mvdPYQVpZgOLbzimDhJkFhCW+P77HAmFrSzx5d4EVYqSNxL1/K9kg 1n5lkfjSshfsHhEBY4nPh+YwQ9wpK7H7+XfmCYwCsxAumoXkollIxi5gZF7FKFCUmpNYaaaX WFCQk6qXnJ+7iREcdIVROxgbllsdYhTgYFTiAdreFyTEmlhWXJl7iFGCg1lJhFf5YH+QEG9K YmVValF+fFFpTmrxIUZpDhYlcd4PL4BSAumJJanZqakFqUUwWSYOTqkGxpkXzqssyk1qXZPL 9cYm8zrPDWe3KgOxde/jGljbCuvkVN5KChR+Wn72HvPBi/tmKXyaNZN91WffJ8z3JR1PPam9 +u90YHGHoz+DnqDwzS0TkiIKJniuiXk009/TSqBluteMowFLuvyZxTZ0/bd7qt54I+9W/KXU Dp3F0t+c1rq1xQe0nLs3QYmlOCPRUIu5qDgRAJ93o3s2AgAA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 23:45:12 -0000 On Nov 22, 2013, at 14:44 , Basil Mohamed Gohar = wrote: > On 11/22/2013 05:01 PM, Adam Roach wrote: >> On 11/22/13 14:22, Daniel-Constantin Mierla wrote: >>> They plan to release the sources under BSD, but who wants to use = them >>> directly, they have to deal with mpeg-la.=20 >>=20 >>=20 >> Every time this kind of statement is made without also including "if >> they distribute more than 100,000 copies a year", it's a bald >> misrepresentation of the situation. >>=20 >> I'm not saying the 100,000-copy exemption is a silver bullet. But it >> sure does cut down the number of people who have to deal with = MPEG-LA, >> and completely addresses the "what if I want to have a enterprise = disk >> image?" question. And ignoring it to exaggerate your case doesn't do >> anyone any favors. >>=20 >> /a >=20 > Free software projects do not have a reliable mechanism by which to > count their distribution, since it is sent out through many means, not > the least of which can include direct downloads, SCM code checks = (e.g., > Github), GNU/Linux and *BSD distibutions (which can easily exceed > 100,000 for the most popular ones), to name a few. >=20 > Where does the liability for counting lie in each of these cases? The > licensing restrictions that MPEG-LA has placed on H.264 is very > free-software unfriendly for any cases where you want rights to be > transitive - which is a key, fundamental aspect of software freedom. Curiously, I think that the position is that if you distribute source = (e.g. of FFMPeg, X264) then the person who compiles it is making the = final product, so if everyone builds it themselves, they are in a = product distribution group size of 1. Don=92t rely on me, IANAL. David Singer Multimedia and Software Standards, Apple Inc. From singer@apple.com Fri Nov 22 15:46:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2D11AE268 for ; Fri, 22 Nov 2013 15:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.427 X-Spam-Level: X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_Od54glKb2G for ; Fri, 22 Nov 2013 15:46:27 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 844C41AE117 for ; Fri, 22 Nov 2013 15:46:27 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWO008GNVCMUI11@mail-out.apple.com> for rtcweb@ietf.org; Fri, 22 Nov 2013 15:46:14 -0800 (PST) X-AuditID: 11807157-b7ff46d000001540-2f-528fecc6182f Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 08.28.05440.6CCEF825; Fri, 22 Nov 2013 15:46:14 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWO0004HVD2FO60@spicerack.apple.com> for rtcweb@ietf.org; Fri, 22 Nov 2013 15:46:14 -0800 (PST) From: David Singer In-reply-to: <528FEC5A.8060701@librevideo.org> Date: Fri, 22 Nov 2013 15:46:14 -0800 Content-transfer-encoding: quoted-printable Message-id: <7C4C4F47-1F9B-4A69-AE68-122DE394E203@apple.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FC497.2080804@googlemail.com> <528FEC5A.8060701@librevideo.org> To: Basil Mohamed Gohar X-Mailer: Apple Mail (2.1822) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FCsoXvsTX+QwfyH2hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro3PFV9aCt9wVPUd2MjUw7uLsYuTkkBAwkehYfIoVwhaTuHBv PVsXIxeHkMBkJonTd3qhnNVMEp3TPjJ3MXJwMAvoSdy/qAXSwAtk3mq+zwxiCwtIS2y5dJcR xGYTUJV4MOcYmM0JVPPmyy5WkFYWoPjkXrBdzALCEt8f32OBsLUlnry7wAox0kbizru9TBBr Z7NIzNy/iR0kISJgLPH50BxmiENlJXY//848gVFgFsJFs5BcNAvJ2AWMzKsYBYpScxIrTfQS CwpyUvWS83M3MYLDrjB8B+O/ZVaHGAU4GJV4gLb3BQmxJpYVV+YeYpTgYFYS4Z3/uj9IiDcl sbIqtSg/vqg0J7X4EKM0B4uSOO/bF0ApgfTEktTs1NSC1CKYLBMHp1QDo87NAz7nudd90srr T3dcs+JIOWtE7W7hWYfE39h9VPzM8/rSkeNvk8TPTrFWN5GOWnO5l+fyzFldGx/8q1/Uc4Vj e1vYzW+W5c7MEw/d3jVrvf0d3ZM+ynIxxVuuBqVEPGR7fSS7JO+XfXpl7Pa33Kp8l77vfVL+ 7LWxbyFT+JdLLodkNrseslViKc5INNRiLipOBAAz65usNwIAAA== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Fri, 22 Nov 2013 23:46:29 -0000 On Nov 22, 2013, at 15:44 , Basil Mohamed Gohar = wrote: > On 11/22/2013 06:42 PM, David Singer wrote: >>=20 >> On Nov 22, 2013, at 12:54 , Maik Merten = wrote: >>=20 >>> And again, H.261 is only considered as fallback option to establish = basic video interoperability as no single high-performance video codec = can be agreed on. It would only kick into action in situations when the = alternative would be "no video at all". This fallback option has to be = implementable without relevant restrictions. >>=20 >> I rather suspect that many, given a choice between: >> a) deliver crappy video using H.261, with the unstated implication to = the users at the two ends that they really need to find something that = will interoperate on something better >> and >> b) tell the users directly that they don=92t have a video codec in = common, and to get video they need to find something that will = interoperate >>=20 >> would actually prefer (b). It=92s less work, more direct, and more = honest. >>=20 >> David Singer >> Multimedia and Software Standards, Apple Inc. >>=20 >=20 > Then we need to restate one of the goals of this WG if we're not going > to have an MTI. However, I personally disagree with that change. No, I think we all want an MTI codec. But not at any price in terms of = quality degradation, and H.261 may be simply off the bottom end. David Singer Multimedia and Software Standards, Apple Inc. From martin.thomson@gmail.com Fri Nov 22 16:06:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6C01AE2D8 for ; Fri, 22 Nov 2013 16:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olMLmoQ0AHks for ; Fri, 22 Nov 2013 16:06:45 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id A64311AE271 for ; Fri, 22 Nov 2013 16:06:44 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id z12so1782005wgg.3 for ; Fri, 22 Nov 2013 16:06:36 -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:content-transfer-encoding; bh=wY+8y1MtIPRgbo4LDf4L7VVzdpgbPZd4lf2AmPtfOTM=; b=b6Ar9OvFStY2ATJT91Mkr87OWSNogESUgA9gV2ckZkn/1vMp3mAQCZQdiyDLvx47nK YpzGCcNSwEo4UxisqdVnCIh4ktK3SDZpyqa3j9xiLBeCl+lnMUhCam1HYT1TNrchdGS0 vIT7Q0a1/ijgnYHbX5vQrZp99rq3K5Z+A1j28fThj0vEDmFanQ3J/DSbLQeyUQwLF2aG QnxyewJLNIQiXkXBdCLTrZwi4k11rKVlgdV+uBQzG/N7OBqlboyiZ0BZK+NKl9/08y/O ff3jrO0wuZhYQ0y93kU1HAdfcFYePxWURMaMSmV5Ks5c9XhdKnaY5skgMRJoQiZ/+GtP wiEg== MIME-Version: 1.0 X-Received: by 10.180.86.102 with SMTP id o6mr4753546wiz.30.1385165196905; Fri, 22 Nov 2013 16:06:36 -0800 (PST) Received: by 10.227.134.195 with HTTP; Fri, 22 Nov 2013 16:06:36 -0800 (PST) In-Reply-To: <59A91D84-3D29-47C4-8688-CB60844B15D3@cisco.com> References: <59A91D84-3D29-47C4-8688-CB60844B15D3@cisco.com> Date: Fri, 22 Nov 2013 16:06:36 -0800 Message-ID: From: Martin Thomson To: "Paul Giralt (pgiralt)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 00:06:46 -0000 On 22 November 2013 15:44, Paul Giralt (pgiralt) wrote: > While you=E2=80=99re right that it would work for this scenario, my point= was really > that Offer/Answer is not really asymmetric as implied earlier. Take for > example the hypothetical case where you are only able to decode VP8 but o= nly > able to encode H.264. If I offer VP8 as my only codec (because it=E2=80= =99s the only > thing I=E2=80=99m able to decode therefore I never want anyone to send me= anything > other than VP8) I cannot send H.264 in the offer because that implies I= =E2=80=99m > able to decode it. The other side then wants to say it can only receive > H.264 so it would have to send back an answer with only H.264. I guess > there=E2=80=99s nothing really inherently stopping you from doing this be= cause as > far as I can tell, 3264 only says the answer has to be a subset of the of= fer > for multicast streams, however how would the answering side know that the > offering side is even capable to receiving H.264? Perhaps Offer/Answer ca= n > technically be asymmetric, but it doesn=E2=80=99t seem practical to use i= t this way > because you cannot really indicate your send and receive capabilities > independent of each other. Judicious application of a=3Dsendonly or a=3Drecvonly avoids this issue. If you want to send H.264, try a=3Dsendonly on a line with H.264. If you want to receive VP8, try a=3Drecvonly on a line with VP8. From pgiralt@cisco.com Fri Nov 22 16:20:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2DE1AE228 for ; Fri, 22 Nov 2013 16:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.426 X-Spam-Level: X-Spam-Status: No, score=-14.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbjztlD15qTP for ; Fri, 22 Nov 2013 16:20:40 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B68B91AE206 for ; Fri, 22 Nov 2013 16:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1818; q=dns/txt; s=iport; t=1385166034; x=1386375634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jxu3DthlFS+HtxQ4u7+Nks1YuGRl0IWKg3/8Dg2RMQE=; b=eyUPVvdI/x+3b0n/6ptIa6jWWI0Oh9t1tkhKOuu/Kob0eAAMDEpJLJx2 R+NoVtwk5EWEBOW7loaY231oo442o3kXLX6icFoJ6uUMZGFhKIZTTmWA1 0tdjHdumahuOscQTi0ceWwH0JZpWoEUzHlU8hCapYwuHJwQu1yqUNFjo5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAIP0j1KtJXG9/2dsb2JhbABZgweBC7wUgR8WdIIlAQEBAwF5BQsCAQgYLiERJQIEDgWHbwMJBrhuDYgnF4x4gVwzB4MggRMDlimBa4xahTiDKIFoBQI7 X-IronPort-AV: E=Sophos;i="4.93,755,1378857600"; d="scan'208";a="286991674" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 23 Nov 2013 00:20:19 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAN0KIFL007830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Nov 2013 00:20:18 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.54]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 18:20:18 -0600 From: "Paul Giralt (pgiralt)" To: Martin Thomson Thread-Topic: [rtcweb] Offer/answer for heterogeneous encode/decode Thread-Index: AQHO58/XQlURsOaoj0uaxvupayfvnZoyTmqAgAAGSwCAAAPRAA== Date: Sat, 23 Nov 2013 00:20:18 +0000 Message-ID: <24B2A6DE-958C-445C-BE77-8BD1661DC33D@cisco.com> References: <59A91D84-3D29-47C4-8688-CB60844B15D3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.101.35] Content-Type: text/plain; charset="Windows-1252" Content-ID: <02E42B849CF6E54ABB5518B5FCDC2953@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 00:20:42 -0000 On Nov 22, 2013, at 7:06 PM, Martin Thomson wrot= e: > On 22 November 2013 15:44, Paul Giralt (pgiralt) wrot= e: >> While you=92re right that it would work for this scenario, my point was = really >> that Offer/Answer is not really asymmetric as implied earlier. Take for >> example the hypothetical case where you are only able to decode VP8 but = only >> able to encode H.264. If I offer VP8 as my only codec (because it=92s th= e only >> thing I=92m able to decode therefore I never want anyone to send me anyt= hing >> other than VP8) I cannot send H.264 in the offer because that implies I= =92m >> able to decode it. The other side then wants to say it can only receive >> H.264 so it would have to send back an answer with only H.264. I guess >> there=92s nothing really inherently stopping you from doing this because= as >> far as I can tell, 3264 only says the answer has to be a subset of the o= ffer >> for multicast streams, however how would the answering side know that th= e >> offering side is even capable to receiving H.264? Perhaps Offer/Answer c= an >> technically be asymmetric, but it doesn=92t seem practical to use it thi= s way >> because you cannot really indicate your send and receive capabilities >> independent of each other. >=20 > Judicious application of a=3Dsendonly or a=3Drecvonly avoids this issue. > If you want to send H.264, try a=3Dsendonly on a line with H.264. If > you want to receive VP8, try a=3Drecvonly on a line with VP8. I gave this as an example of a possible way to do it, but that means you ne= ed two separate m=3D lines - one for send and one for receive. Seems strang= e to do this for something that you really want to be a single bi-direction= al stream.=20 -Paul From ron@debian.org Fri Nov 22 16:36:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732BB1AE21A for ; Fri, 22 Nov 2013 16:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUMJlDebLCpd for ; Fri, 22 Nov 2013 16:36:48 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 15B8E1AE1CB for ; Fri, 22 Nov 2013 16:36:47 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 23 Nov 2013 11:06:39 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 881644F8F3 for ; Sat, 23 Nov 2013 11:05:49 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2P4HmIVfB+Ap for ; Sat, 23 Nov 2013 11:05:48 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 706C14F902; Sat, 23 Nov 2013 11:05:48 +1030 (CST) Date: Sat, 23 Nov 2013 11:05:48 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131123003548.GD3245@audi.shelbyville.oz> References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 00:36:50 -0000 On Fri, Nov 22, 2013 at 03:45:02PM -0800, David Singer wrote: > > On Nov 22, 2013, at 14:44 , Basil Mohamed Gohar wrote: > > > On 11/22/2013 05:01 PM, Adam Roach wrote: > >> On 11/22/13 14:22, Daniel-Constantin Mierla wrote: > >>> They plan to release the sources under BSD, but who wants to use them > >>> directly, they have to deal with mpeg-la. > >> > >> > >> Every time this kind of statement is made without also including "if > >> they distribute more than 100,000 copies a year", it's a bald > >> misrepresentation of the situation. > >> > >> I'm not saying the 100,000-copy exemption is a silver bullet. But it > >> sure does cut down the number of people who have to deal with MPEG-LA, > >> and completely addresses the "what if I want to have a enterprise disk > >> image?" question. And ignoring it to exaggerate your case doesn't do > >> anyone any favors. > >> > >> /a > > > > Free software projects do not have a reliable mechanism by which to > > count their distribution, since it is sent out through many means, not > > the least of which can include direct downloads, SCM code checks (e.g., > > Github), GNU/Linux and *BSD distibutions (which can easily exceed > > 100,000 for the most popular ones), to name a few. > > > > Where does the liability for counting lie in each of these cases? The > > licensing restrictions that MPEG-LA has placed on H.264 is very > > free-software unfriendly for any cases where you want rights to be > > transitive - which is a key, fundamental aspect of software freedom. > > Curiously, I think that the position is that if you distribute source (e.g. > of FFMPeg, X264) then the person who compiles it is making the final product, > so if everyone builds it themselves, they are in a product distribution group > size of 1. The whole point of many distros is to supply binaries, often built many times for many different system architectures. So even when source copies are also distributed there's a large multiplier for binaries, which is then multiplied again by uncountable tiers of (both public and private) distribution mirrors. And many projects available as source also produce binary releases, in particular for systems where people aren't used to building binaries for themselves (like Windows and OSX). These also are often mirrored by other services that specialise in this (but provide no auditable account of downloads) - often without the knowledge of, and almost always without asking the permission of, the original binary creator, as is their right for any freely licenced software. Then maybe you've heard of this newfangled thing called CDN ... The problem is quite simply intractable without a major change to the H.264 licencing scheme. No amount of saying "well my homepage never gets 100k hits", and "my appstore app only had 20 downloads" is really going to change that a 100,000 download limit is effectively the same as a Zero download limit on an internet that wasn't designed to count every copy of every thing made by every user. Once you publish it anywhere you have no idea how short a time it will take to exceed that. And you can't even take it back down again, even if you wanted to. And if somebody claims you have made X copies, based on some fuzzy math, you have no way to dispute that except with more fuzzy guesswork. If H.264 is really this important to you, for reasons other than vendor exclusivity and lock-in, then do what Google did, go and buy out the licence holders and put it under a useable licence. If "nobody is making any money out of this" as they all claim, then it should even be pretty cheap, right? People might actually Really Genuinely thank you for that :) Ron From lorenzo@meetecho.com Fri Nov 22 16:39:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEEA1AE276 for ; Fri, 22 Nov 2013 16:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VghN4Wwo_gEL for ; Fri, 22 Nov 2013 16:39:46 -0800 (PST) Received: from smtpdg3.aruba.it (smtpdg1.aruba.it [62.149.158.231]) by ietfa.amsl.com (Postfix) with ESMTP id 367261AE21A for ; Fri, 22 Nov 2013 16:39:45 -0800 (PST) Received: from rainpc ([87.6.118.125]) by smtpcmd01.ad.aruba.it with bizsmtp id sofb1m00E2iQqnr01ofbch; Sat, 23 Nov 2013 01:39:37 +0100 Date: Sat, 23 Nov 2013 01:39:35 +0100 From: Lorenzo Miniero To: Adam Roach Message-ID: <20131123013935.6690a07a@rainpc> In-Reply-To: <528FD429.7090002@nostrum.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 00:39:49 -0000 On Fri, 22 Nov 2013 16:01:13 -0600 Adam Roach wrote: > On 11/22/13 14:22, Daniel-Constantin Mierla wrote: > > They plan to release the sources under BSD, but who wants to use them > > directly, they have to deal with mpeg-la. > > > Every time this kind of statement is made without also including "if > they distribute more than 100,000 copies a year", it's a bald > misrepresentation of the situation. > > I'm not saying the 100,000-copy exemption is a silver bullet. But it > sure does cut down the number of people who have to deal with MPEG-LA, > and completely addresses the "what if I want to have a enterprise disk > image?" question. And ignoring it to exaggerate your case doesn't do > anyone any favors. > This 100k again... Apart from the fact that, even for the free 100k units, you still have to track them, which apparently is an all but simple task: as I asked repeatedly on the list (without ever getting an answer), what makes a unit? what counts in the famous 100k list? if I install a transcoding mixer application on a server, does that count as 1 unit? or do I have to count a unit each time I attach a user to the mixer, i.e., whenever I allocate an encoder/decoder? or anything else? any answer, which I still haven't received, would put that 100k in a different perspective. The only info I could find around was related to an even more obscure subscription vs. title-by-title distinction that confused me even more. Lorenzo > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From derhoermi@gmx.net Fri Nov 22 16:45:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A3B1AE2D9 for ; Fri, 22 Nov 2013 16:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UctRT2GipTu for ; Fri, 22 Nov 2013 16:45:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3BB1AE1C3 for ; Fri, 22 Nov 2013 16:45:16 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.33.117]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MSHax-1W7HXL13MJ-00TTt7 for ; Sat, 23 Nov 2013 01:45:08 +0100 From: Bjoern Hoehrmann To: David Singer Date: Sat, 23 Nov 2013 01:45:10 +0100 Message-ID: References: <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:e6QGR+z1YNzY0OZGmP+PY6qqNYIqikRnTPlmkTigJjiOWYmkEDx yP6zObAiB7Enb+qv4MkJjf4BnLw9g6tvxNsZcpVNAO9/Lmx9bjXpSPFg5n8tjETlMEpj16f p5qmpvgNFsUzh0vctg0ByK6FXKeKce7LQMly7ncPHMYBYy1aK+bTTaiJbEK5/gody4e9rsj YE5r4xOF+sYp2IX323odg== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 00:45:18 -0000 * David Singer wrote: >Curiously, I think that the position is that if you distribute source >(e.g. of FFMPeg, X264) then the person who compiles it is making the >final product, so if everyone builds it themselves, they are in a >product distribution group size of 1. I trust MPEG-LA just HATES this one weird trick... -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From partha@parthasarathi.co.in Fri Nov 22 17:01:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56CA1AE09E for ; Fri, 22 Nov 2013 17:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7XVCvH5CLHN for ; Fri, 22 Nov 2013 17:01:40 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id 570EA1AE058 for ; Fri, 22 Nov 2013 17:01:40 -0800 (PST) Received: from userPC (unknown [122.179.28.193]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id EACD81908001; Sat, 23 Nov 2013 01:01:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1385168492; bh=wzDaHyh0iVv6kqhAaVVOVcRo+RoHgZ+kg/obFSzrrSU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=AN5hqLPkErCwxAcBGm20/Mtca3jFtm7VbBnKy/zPM64UC/02o4SY5K9yTiAod3dYC EmI9YZDFBEbOFKNsZ5CZLPSuxjlkz1kExe/FyLy5lBb1C2MfD+erAxYbjDIcTCuaZt 13phmo+QU/mtY94U++8FhoXHRqX0MYq2z+crkZ8Y= From: "Parthasarathi R" To: "'Emil Ivov'" , "'Peter St Andre, \(stpeter\)'" References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im> In-Reply-To: Date: Sat, 23 Nov 2013 06:31:20 +0530 Message-ID: <01c101cee7e7$88f12610$9ad37230$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C2_01CEE815.A2A96210" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7m/6doUpl81HLyRgarcXZ/lBHz1QA2+3eg Content-Language: en-us X-CTCH-RefID: str=0001.0A020202.528FFE6C.0093, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.100 X-CTCH-Rules: SUBJECT_NEEDS_ENCODING, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: rtcweb@ietf.org Subject: [rtcweb] IETF will fail to implement Video codec MTI after election? [was RE: Proposed Video Selection Process] X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 01:01:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C2_01CEE815.A2A96210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree with Emil & Peter that voting will not help to achieve Video codec MTI in the industry. Let us assume that codec x is selected as per the election result. Why should the opposite camp browser vendor or WebRTC gateway/conference vendor *MUST* implement the specified codec x for the sake IETF compliance? As the multiple codec alternative (candidate) exists and kind of implicit coalition[1] allowed by IRV election mechanism, it is possible for less than 50% folks supported codec alternative as a first preference will be selected as point in http://en.wikipedia.org/wiki/Instant-runoff_voting first example. How this mechanism helps to achieve the better interop in the internet which is our ultimate aim? I'm worried that this election may results in situation of "the operation was a success but the patient died." Thanks Partha Note 1: Implicit coalition - 2nd preference will become the voters choice after the 1st preference is eliminated From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Emil Ivov Sent: Friday, November 22, 2013 2:51 AM To: Peter St Andre, (stpeter) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposed Video Selection Process The IETF does not vote! This is not a democracy! We reach consensus based on technical arguments or we declare lack thereof. The fact that I could afford a plane ticket to this meeting, had the time to post on that mailing list or sent a +1 message on an XMPP MUC does not make me more or less qualified to cast a vote on this topic than anyone else. The criteria that is being suggested for picking a voter's base here is so desperately arbitrary that it makes a coin flip pale in comparison. It also shows how ill suited the IETF is for such things. In other words, +1 to what Peter said and let's stick to what we actually can do. --sent from my mobile On 21 Nov 2013 19:26, "Peter Saint-Andre" wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/21/13 9:51 AM, Magnus Westerlund wrote: > The method we propose is based on Instant-runoff voting, > http://en.wikipedia.org/wiki/Instant-runoff_voting, with the > understanding that the choice will be the winner according to the > Instant-runoff voting process. I have the greatest respect for the chairs, but this is an engraved invitation for people to appeal whatever decision might be reached. More fundamentally: Voting? At the IETF?? Really?!? I sincerely hope we can figure out a better process... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSjlBXAAoJEOoGpJErxa2pxmoP/2cCm8UEteJlhNkpV+kTrgYc epj1s0LHlQYS/XBWvTpa6d/DeBS0N/mWUAHg+QDj1J5kXiCol3PVpZB7yp2YP4p+ OcsF/y4KTJCZz+Qs/SBj6o68eX4Cuk68FZ5nrSK6/jSuRFLH6LYTbXW7jvF/Y4pX ER5kUg14c+s+NFo575ru3PjYJy2NoSUHVJfB/pLtmlFSH+WKZXw7RFR+Sivlyw3p RSJ2fsGldRRa/5aLFajDXxVmViwOtDbuoIFpKKfSSw76a3Q4IbPPX+gezQi7p0ky cJCED5/U6IR4wtyWxsfQTV7XDvebYtWTXk2smzKPmQCdRnUiHmT5fmtR6bxDVbSu h7xrLCTJeW8qx4IN9zvXCg6QUKUzPdtJuhRF/HouCiZQs9v+d0jmSaR/ZUiZ0Ho9 1uXHkiUezkksDKjxB9hsJDmMj24BMzu8TmkndZd3Q4lSg0PI+R1ALd6MgXupBCif L8lwYm+JG4cT548O1AfFrBmYcqKnNuTilAA7ZwwJtk6eLcpzpwbLFvRq0LVhsmJC dDiNKGSFmgj8wTgT7Z3SQ+km++gecDILGvnJU5hXo6RmnErcjzkis7YMootreSUi qCA1fJm7s1TZMn18X79XzHRF6run0C9UaYZORSPwlpmTzAdjRKN5WimstXO2yIQJ IZFFqvSNutklVl36Limg =G59C -----END PGP SIGNATURE----- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_000_01C2_01CEE815.A2A96210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Emil & Peter that voting will not help = to achieve Video codec MTI in the industry. Let us assume that codec x is = selected as per the election result. Why should the opposite camp browser vendor = or WebRTC gateway/conference vendor *MUST* implement the specified = codec x for the sake IETF compliance?

 

As the multiple codec alternative (candidate) exists and = kind of implicit coalition[1] allowed by IRV election mechanism, it is possible = for less than 50% folks supported codec alternative as a first preference will be selected as point in http://en.wik= ipedia.org/wiki/Instant-runoff_voting first example. How this mechanism helps to achieve the better interop in = the internet which is our ultimate aim?

 

I’m worried that this election may results in = situation of “the operation was a success but the patient = died.”

 

Thanks

Partha

 

Note 1:  Implicit coalition – 2nd preference will become the voters choice after the 1st = preference is eliminated

 

From:= rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Emil Ivov
Sent: Friday, November 22, 2013 2:51 AM
To: Peter St Andre, (stpeter)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection = Process

 

The IETF does not vote!

This is not a democracy!

We reach consensus based on technical arguments or we declare lack = thereof.

The fact that I could afford a plane ticket to this meeting, had the = time to post on that mailing list or sent a +1 message on an XMPP MUC does not = make me more or less qualified to cast a vote on this topic than anyone = else.

The criteria that is being suggested for picking a voter's base here = is so desperately arbitrary that it makes a coin flip pale in comparison. It = also shows how ill suited the IETF is for such things.

In other words, +1 to what Peter said and let's stick to what we = actually can do.

--sent from my mobile

On 21 Nov 2013 19:26, "Peter Saint-Andre" = <stpeter@stpeter.im> = wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/21/13 9:51 AM, Magnus Westerlund wrote:

> The method we propose is based on Instant-runoff voting,
> http://en.wikipedia.org/wiki/Instant-runoff_voting,= with the
> understanding that the choice will be the winner according to = the
> Instant-runoff voting process.

I have the greatest respect for the chairs, but this is an engraved
invitation for people to appeal whatever decision might be reached.

More fundamentally: Voting? At the IETF?? Really?!?

I sincerely hope we can figure out a better process...

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSjlBXAAoJEOoGpJErxa2pxmoP/2cCm8UEteJlhNkpV+kTrgYc
epj1s0LHlQYS/XBWvTpa6d/DeBS0N/mWUAHg+QDj1J5kXiCol3PVpZB7yp2YP4p+
OcsF/y4KTJCZz+Qs/SBj6o68eX4Cuk68FZ5nrSK6/jSuRFLH6LYTbXW7jvF/Y4pX
ER5kUg14c+s+NFo575ru3PjYJy2NoSUHVJfB/pLtmlFSH+WKZXw7RFR+Sivlyw3p
RSJ2fsGldRRa/5aLFajDXxVmViwOtDbuoIFpKKfSSw76a3Q4IbPPX+gezQi7p0ky
cJCED5/U6IR4wtyWxsfQTV7XDvebYtWTXk2smzKPmQCdRnUiHmT5fmtR6bxDVbSu
h7xrLCTJeW8qx4IN9zvXCg6QUKUzPdtJuhRF/HouCiZQs9v+d0jmSaR/ZUiZ0Ho9
1uXHkiUezkksDKjxB9hsJDmMj24BMzu8TmkndZd3Q4lSg0PI+R1ALd6MgXupBCif
L8lwYm+JG4cT548O1AfFrBmYcqKnNuTilAA7ZwwJtk6eLcpzpwbLFvRq0LVhsmJC
dDiNKGSFmgj8wTgT7Z3SQ+km++gecDILGvnJU5hXo6RmnErcjzkis7YMootreSUi
qCA1fJm7s1TZMn18X79XzHRF6run0C9UaYZORSPwlpmTzAdjRKN5WimstXO2yIQJ
IZFFqvSNutklVl36Limg
=3DG59C
-----END PGP SIGNATURE-----
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

------=_NextPart_000_01C2_01CEE815.A2A96210-- From martin.thomson@gmail.com Fri Nov 22 17:03:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402A61AE058 for ; Fri, 22 Nov 2013 17:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-NUFzAc6pVi for ; Fri, 22 Nov 2013 17:03:39 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B391B1A1F4A for ; Fri, 22 Nov 2013 17:03:38 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so1815414wes.24 for ; Fri, 22 Nov 2013 17:03:31 -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=O8uJkL9mug8yjiyh71qVrOWIVLhlJcru+OUpP+E4tjs=; b=wweZTI0fkkwvgcnIORkL/MBn1sTlnDly+4xXn+a2fQ0zIX/4KM6XntGgLUERFsvkew y3A1L5cSIQzWJQyKDSbtYgLgLnrwQ5k8kqFIr2smE1RdvP5ZWNh/1NUVpEiPScncygC7 YN/IXXyo0sCR7ijch6pWas0amNIMZ/xj+x8eVfD5c3Bf2Vd4AnJ9dUBtsCXwPKMcHoUT QVdhE90vIbS0fOzWEQh+I0Kd8Ed9eegUXQ7HKFtUuNrpv/Ix55HtTNgeIh/ztrBoG436 4193fGyXfKZoLUyrIFurY+TxOLZyAxzXn+hJLluz2RxLE/a3ZO6KE8YE2Gqx3RxfxNs5 3jCw== MIME-Version: 1.0 X-Received: by 10.180.20.102 with SMTP id m6mr4859573wie.22.1385168611095; Fri, 22 Nov 2013 17:03:31 -0800 (PST) Received: by 10.227.134.195 with HTTP; Fri, 22 Nov 2013 17:03:31 -0800 (PST) In-Reply-To: <24B2A6DE-958C-445C-BE77-8BD1661DC33D@cisco.com> References: <59A91D84-3D29-47C4-8688-CB60844B15D3@cisco.com> <24B2A6DE-958C-445C-BE77-8BD1661DC33D@cisco.com> Date: Fri, 22 Nov 2013 17:03:31 -0800 Message-ID: From: Martin Thomson To: "Paul Giralt (pgiralt)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 01:03:40 -0000 On 22 November 2013 16:20, Paul Giralt (pgiralt) wrote: > I gave this as an example of a possible way to do it, but that means you need two separate m= lines - one for send and one for receive. Seems strange to do this for something that you really want to be a single bi-directional stream The bidirectional thing in O/A is the strange way to do things. Two lines is pretty intuitive. From stevek@stevek.com Fri Nov 22 17:09:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7C01AE2C3 for ; Fri, 22 Nov 2013 17:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1sZ1JV2xPWl for ; Fri, 22 Nov 2013 17:09:48 -0800 (PST) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id C62E41AE2B1 for ; Fri, 22 Nov 2013 17:09:48 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id a11so1588638qen.33 for ; Fri, 22 Nov 2013 17:09:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Wk0Yj4Or0j9kQX2+aG05YoQ4HM3wkat8QhcUUnqmNLY=; b=iqv2wPNMpswhixXt8G1fJvsdHXJL1NjzC8lAUfyd6JBvkVgGA+8a0T9lUQ/wHY1H6m B9t+ftP4SDBhBtShbRzCVWf1Fewd/3lXRfEkeOQidbDTILg3YrcPYzokQdwaOtWnWo40 4XsDoYjbz4gKPwEHDppgHnqK0BIV+4zmvEFJwvcW+a/WOnZbRESJR6bZeLLWM89Jygtx HKk7zbDjIyudDA1hMfoOLYI0gkqkn/3Ci33DKDmtu1JOJNq5a+HaP8Rvl1EQnZkx2XBg dbtAfxnTTBsZlR2HQE98qhhhxoVZjHwHI+9hGaF/5MTZF4RoZdZdYihxlUETpf0M4QAO gCbQ== X-Gm-Message-State: ALoCoQmgIacJa0dJD3pmg4r2ITkWD/DLZspywsPLuDcvktEC6qRmE9TaVTjMFQRJGUDbfZjcuRjH X-Received: by 10.49.27.8 with SMTP id p8mr913709qeg.64.1385168981121; Fri, 22 Nov 2013 17:09:41 -0800 (PST) Received: from [10.19.53.130] (mobile-198-228-195-139.mycingular.net. [198.228.195.139]) by mx.google.com with ESMTPSA id b10sm3340599qeg.7.2013.11.22.17.09.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 17:09:40 -0800 (PST) References: <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <35BA0144-C4F5-4E1A-B791-C6C1511F0B88@stevek.com> X-Mailer: iPhone Mail (11B554a) From: Steve Kann Date: Fri, 22 Nov 2013 20:09:40 -0500 To: Bjoern Hoehrmann Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 01:09:51 -0000 We keep tailing about this 100k cap as if there are no additional obligation= s on folks: - they still need to define what units mean and count them (problem well des= cribed in recent posts) - even in the situation below (compile by user, etc) In order to be covered b= y the 100k minimum, you still need to count and also submit to a quarterly r= eporting requirement. So this sounds great: =20 - you distribute your product in source form.=20 - you ask your users to compile it on their own ( I'm guessing automating th= is might be problematic) - you ask your users to request and complete paperwork with MPEG-LA, and sub= mit to quarterly reporting requirements.=20 Sounds fantastic for those guys. Imagine that this was required for tcp-Reno= ? Anyway, I think we should establish a consensus call requesting we don't tal= k about h.264-only or vp8-only MTI options. I think we can find consensus th= at unless something significant changes (and Cisco's openh264 action was sig= nificant but insufficient), that we will not get consensus there. I don't k= now how procedure works, but I think we all just need to accept and move on.= =20 -Sent from an iOS mobile device > On Nov 22, 2013, at 7:45 PM, Bjoern Hoehrmann wrote: >=20 > * David Singer wrote: >> Curiously, I think that the position is that if you distribute source=20 >> (e.g. of FFMPeg, X264) then the person who compiles it is making the=20 >> final product, so if everyone builds it themselves, they are in a=20 >> product distribution group size of 1. >=20 > I trust MPEG-LA just HATES this one weird trick... > --=20 > Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://b= joern.hoehrmann.de > Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoerns= world.de > 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.we= bsitedev.de/=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From gmaxwell@gmail.com Fri Nov 22 17:19:26 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9F41AE2D4 for ; Fri, 22 Nov 2013 17:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7qKry80bACM for ; Fri, 22 Nov 2013 17:19:25 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 14DBA1AE2CF for ; Fri, 22 Nov 2013 17:19:24 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z5so1619077lbh.3 for ; Fri, 22 Nov 2013 17:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=aRIyLmQ/YEMsGUAMePUp9Wlv5tV/Pihh9HZvvvIspPE=; b=Hr7N60rCXoegGKTkSZR/Y0gy3lSuwJ5La0CNT97qx93TXvOOw38RGunlhofYEEBNjX 5yBStLcsUBlQLDhTqYix63ToNsl/LaF85kFSKL2gG4w0B6x1qffUwBy7Lc3JCO7NoCL5 0edn5pdqVXWzPSXbZcNiCWMSGp83iAkz64pXm+9y+K11+0CKoev1u0URQFHZXqml56ca seaZWVO4+1Bohl5TJUJJwjsKX0oxbN3xCPDvj996Qh9yaGs9NkV1V+VYpSWaws0J3PVB xuPYraVVUxaTHCizUHToXGnSx22hzNaZMyZO2O/ori3OpK96dVrMBGY2dNuvvIQaLpva ozzA== MIME-Version: 1.0 X-Received: by 10.152.6.201 with SMTP id d9mr8675057laa.25.1385169557215; Fri, 22 Nov 2013 17:19:17 -0800 (PST) Sender: gmaxwell@gmail.com Received: by 10.112.63.166 with HTTP; Fri, 22 Nov 2013 17:19:17 -0800 (PST) Date: Fri, 22 Nov 2013 17:19:17 -0800 X-Google-Sender-Auth: 7WoA_EpD0PjZvHmbY1AFPCcLxaA Message-ID: From: Gregory Maxwell To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] IETF will fail to implement Video codec MTI after election? [was RE: Proposed Video Selection Process] X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 01:19:26 -0000 On Fri, Nov 22, 2013 at 5:01 PM, Parthasarathi R wrote: > I agree with Emil & Peter that voting will not help to achieve Video code= c > MTI in the industry. Let us assume that codec x is selected as per the > election result. Why should the opposite camp browser vendor or WebRTC > gateway/conference vendor *MUST* implement the specified codec x for the > sake IETF compliance? In some markets being able to respond "Complies" to an RFP requirement for a particular RFC is commercially significant. It is also not unlikely that there is a great swath of "will do the minimum necessary" implementers=E2=80=94 outside of the big name vendors=E2= =80=94 who will tend to just do as the spec requires. So the decision here determines what code licensing/exposure will be required to interop with those parties. There are also a number of other reasons parties may care. And, as you can observe, many people do care. If it really was irrelevant you wouldn't see all of this noise. From adam@nostrum.com Fri Nov 22 17:38:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2026C1AE19B for ; Fri, 22 Nov 2013 17:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3j54W1A64Sg for ; Fri, 22 Nov 2013 17:38:31 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCF91AE0E7 for ; Fri, 22 Nov 2013 17:38:31 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAN1b4MM053280 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Nov 2013 19:37:05 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <529006BB.609@nostrum.com> Date: Fri, 22 Nov 2013 19:36:59 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ron , rtcweb@ietf.org References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> In-Reply-To: <20131123003548.GD3245@audi.shelbyville.oz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 01:38:32 -0000 On 11/22/13 18:35, Ron wrote: > The whole point of many distros is to supply binaries, often built > many times for many different system architectures. And the overwhelming majority of these do so by including a list of repositories from which the binaries can be downloaded. I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, and whatever else is needed for these distros, targeting whatever platforms are required. Now, whether we can get the distro maintainers to add a single line to their list of repos -- because that's all it would take -- is a different issue. But at that point, it's just a matter of the distro maintainers being intransigent rather than any real technical or legal barrier. /a From sslivinski@lifesize.com Fri Nov 22 17:41:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77851AE091 for ; Fri, 22 Nov 2013 17:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POlXZfPBWfbg for ; Fri, 22 Nov 2013 17:41:01 -0800 (PST) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with SMTP id 970701ADFAE for ; Fri, 22 Nov 2013 17:41:01 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKUpAHpmtlsywbp9wfuuMz+VG6ww9HoxpI@postini.com; Fri, 22 Nov 2013 17:40:54 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 19:38:38 -0600 From: Stefan Slivinski To: "rtcweb@ietf.org" Date: Fri, 22 Nov 2013 19:38:35 -0600 Thread-Topic: [rtcweb] Proposed Video Selection Process Thread-Index: Ac7n1cWK5Cp3vV3qRCWURD7ff3/loQAFthPA Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E675F@ausmsex00.austin.kmvtechnologies.com> References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> <528EBAB0.2010906@librevideo.org> <528EBD4C.8070504@librevideo.org> <02B96CE8-A6D9-4288-B052-FB54B07447FB@apple.com> <528FCA68.2070309@googlemail.com> <528FE08B.1020908@nostrum.com> In-Reply-To: <528FE08B.1020908@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 01:41:04 -0000 Magnus Westerlund: please add the following proposal to the list: "must support both H.264 and VP8 decode and must support at least one of H.= 264 or VP8 encode" to the list of options -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach Sent: Friday, November 22, 2013 2:54 PM To: Maik Merten; rtcweb@ietf.org Subject: Re: [rtcweb] Proposed Video Selection Process On 11/22/13 15:19, Maik Merten wrote: > It is hard to come up with a scenario where patents covering the=20 > original standard and original reference implementation would still be=20 > enforceable. As a specific example of such a scenario -- one that is tantalizingly close= to the subject at hand -- look here: http://www.google.com/patents/US7376184 Read the first paragraph of the description. In layman's terms, it says "ev= en though this patent is being issued in 2008, we claim that it was invente= d in January of 1992." And with a priority date prior to 1995, this means t= hat they have protection for seventeen years from the date of issuance (i.e= ., until 2025). Yes, this means that they have patent protection on this specific technique= for 33 years after its invention. In US courts, this is 100% legal and fully enforceable, since they started = the process prior to 1995. And "prior to 1995" is exactly when we're talkin= g about. /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Fri Nov 22 17:44:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4F1AE16B for ; Fri, 22 Nov 2013 17:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XyWm3sLUMBo for ; Fri, 22 Nov 2013 17:44:29 -0800 (PST) Received: from blu0-omc3-s11.blu0.hotmail.com (blu0-omc3-s11.blu0.hotmail.com [65.55.116.86]) by ietfa.amsl.com (Postfix) with ESMTP id BD5FB1AE0E2 for ; Fri, 22 Nov 2013 17:44:29 -0800 (PST) Received: from BLU403-EAS326 ([65.55.116.72]) by blu0-omc3-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Nov 2013 17:44:23 -0800 X-TMN: [q34Xo1GMFVrS6VFfkZWT/e3U+OUBDrnt] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im> <528E7033.2090502@gmail.com> <528F68CC.40106@usdonovans.com> <8uru89ha1p0cccvq5qr8mtcnl4mvmkelhk@hive.bjoern.hoehrmann.de> <528F7E21.7010803@librevideo.org> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Fri, 22 Nov 2013 17:44:18 -0800 To: Emil Ivov X-OriginalArrivalTime: 23 Nov 2013 01:44:23.0050 (UTC) FILETIME=[88E816A0:01CEE7ED] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 01:44:31 -0000 > On Nov 22, 2013, at 8:20 AM, "Emil Ivov" said: >=20 > If we can't reach consensus then we are in no position to mandate. [BA] It strikes me that once we venture beyond consensus and running code in= to voting, we have left our home behind for someplace else whose principles s= hould at the least be articulated. For example, it would be helpful to understand whether we are now endorsing K= ings and if so, whether the model is that of a constitutional monarchy, or m= ore along the Absolutist line.=20 we could decide to emulate Louis XIV (a defender of The Divine Right of King= s). From sslivinski@lifesize.com Fri Nov 22 17:47:26 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CCB1AE1E8 for ; Fri, 22 Nov 2013 17:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN1NhuGzAIHP for ; Fri, 22 Nov 2013 17:47:24 -0800 (PST) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with SMTP id 3BFD71AE1E6 for ; Fri, 22 Nov 2013 17:47:24 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKUpAJJc6S41xVns1DXqD6Dqnga6/OaAVV@postini.com; Fri, 22 Nov 2013 17:47:17 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 19:42:47 -0600 From: Stefan Slivinski To: "rtcweb@ietf.org" Date: Fri, 22 Nov 2013 19:42:45 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7n7LVNloYMpb4+Sb6txwPc2SuobQAADMwQ Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> In-Reply-To: <529006BB.609@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 01:47:26 -0000 Just for fun, let's play out the H.261 scenario as the great savior of webr= tc that some claim it is: Let's say through some divine miracle we manage to all agree to make H.261 = the one and only MTI codec. The rationale being of course that no one will= ever use it because it is of course terrible, but we need it to get around= those pesky patent/license terms with VP8/H.264 respectively. Alright fast forward, Chrome adds H.261 but continues to use VP8. IE uses = H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, H.264 = and VP8. So far so good. Chrome can talk using VP8 to Firefox, Safari can= talk H.264 to IE, Firefox can either H.264 or VP8 to everyone. As long as= Chrome users don't try to call IE or Safari, we're in good shape, otherwis= e we need to transcode using some undefined cloud based transcoder service = or just use H.261. So we're still in good shape. Now let's consider the multiway case. I hea= rd a use case at the conference on Tuesday where a university was using web= rtc to enable video online classes. So let's assume there are 20 people in= the class. 19 people in the class love Chrome, so they join the class fro= m chrome and are all sending each other VP8. But of course there's always = one person that has to be difficult and they decide they prefer IE. So wha= t now? Well the IE person doesn't understand any of the 19 VP8 streams an= d the 19 chrome users don't understand the 1 H.264 stream. So we can now u= tilize that same undefined cloud transcoding service to convert each of the= 19 VP8 streams to H.264 and the 1 H.264 stream to VP8....or we can use H.2= 61. My guess is H.261 is going to get used a lot more than anyone thinks. -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach Sent: Friday, November 22, 2013 5:37 PM To: Ron; rtcweb@ietf.org Subject: Re: [rtcweb] H.261 On 11/22/13 18:35, Ron wrote: > The whole point of many distros is to supply binaries, often built=20 > many times for many different system architectures. And the overwhelming majority of these do so by including a list of reposit= ories from which the binaries can be downloaded. I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, an= d whatever else is needed for these distros, targeting whatever platforms a= re required. Now, whether we can get the distro maintainers to add a single= line to their list of repos -- because that's all it would take -- is a di= fferent issue. But at that point, it's just a matter of the distro maintain= ers being intransigent rather than any real technical or legal barrier. /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From adam@nostrum.com Fri Nov 22 17:49:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E9E1AE28D for ; Fri, 22 Nov 2013 17:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n522N7H6KGxS for ; Fri, 22 Nov 2013 17:49:38 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A505F1AE27C for ; Fri, 22 Nov 2013 17:49:38 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAN1nPPU053742 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Nov 2013 19:49:25 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <529009A0.5050708@nostrum.com> Date: Fri, 22 Nov 2013 19:49:20 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Lorenzo Miniero References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <20131123013935.6690a07a@rainpc> In-Reply-To: <20131123013935.6690a07a@rainpc> Content-Type: multipart/alternative; boundary="------------000803000203090309010201" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 01:49:39 -0000 This is a multi-part message in MIME format. --------------000803000203090309010201 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/22/13 18:39, Lorenzo Miniero wrote: > as I asked repeatedly on the list (without ever getting an answer), what makes a unit? Of course you're not getting an answer from the list. We're not the right people to answer that question. I think the address you want is . /a --------------000803000203090309010201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 11/22/13 18:39, Lorenzo Miniero wrote:
as I asked repeatedly on the list (without ever getting an answer), what makes a unit?

Of course you're not getting an answer from the list. We're not the right people to answer that question. I think the address you want is <Licensing-web@mpegla.com>.

/a
--------------000803000203090309010201-- From adam@nostrum.com Fri Nov 22 18:16:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375161AE21E for ; Fri, 22 Nov 2013 18:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGlzj6h-SutI for ; Fri, 22 Nov 2013 18:16:08 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 49E9C1AD8DB for ; Fri, 22 Nov 2013 18:16:08 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAN2G0br054698 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Nov 2013 20:16:01 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52900FDB.3030803@nostrum.com> Date: Fri, 22 Nov 2013 20:15:55 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stefan Slivinski , "rtcweb@ietf.org" References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 02:16:09 -0000 On 11/22/13 19:42, Stefan Slivinski wrote: > Just for fun, let's play out the H.261 scenario as the great savior of webrtc that some claim it is... > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach > ... > I'm 100% confident that we could convince Cisco to serve up RPMs... Stefan: This is the second completely non-sequitur response you've sent to my emails over the course of five minutes. I'm not sure what you're trying to accomplish, but I don't think it's productive. /a From ron@debian.org Fri Nov 22 18:28:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D251A1F77 for ; Fri, 22 Nov 2013 18:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEGI8-mHlxcq for ; Fri, 22 Nov 2013 18:28:02 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5D11A1F74 for ; Fri, 22 Nov 2013 18:28:01 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 23 Nov 2013 12:57:54 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 6EDC04F8F3 for ; Sat, 23 Nov 2013 12:57:51 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Tbjs-H5ECkuU for ; Sat, 23 Nov 2013 12:57:50 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id AD39D4F902; Sat, 23 Nov 2013 12:57:50 +1030 (CST) Date: Sat, 23 Nov 2013 12:57:50 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131123022750.GE3245@audi.shelbyville.oz> References: <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <529006BB.609@nostrum.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 02:28:04 -0000 On Fri, Nov 22, 2013 at 07:36:59PM -0600, Adam Roach wrote: > On 11/22/13 18:35, Ron wrote: > >The whole point of many distros is to supply binaries, often built > >many times for many different system architectures. > > And the overwhelming majority of these do so by including a list of > repositories from which the binaries can be downloaded. > > I'm 100% confident that we could convince Cisco to serve up RPMs, > DPKGs, and whatever else is needed for these distros, targeting > whatever platforms are required. Now, whether we can get the distro > maintainers to add a single line to their list of repos -- because > that's all it would take -- is a different issue. But at that point, > it's just a matter of the distro maintainers being intransigent > rather than any real technical or legal barrier. So, now you want people to give Cisco not only the ability to install binary blobs on their machine -- but a root shell to do it as well? What could possibly go wrong. I'd laugh but my intransigence gland doesn't appear to be secreting the necessary humors ... Moving along, nothing technical or legal to see here, just a mirror, a single line, and a razor blade ... Snort, Ron From gsalguei@cisco.com Fri Nov 22 18:40:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCF11A1F72; Fri, 22 Nov 2013 18:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zErRyc7NxCzx; Fri, 22 Nov 2013 18:40:31 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 89D291AC3DD; Fri, 22 Nov 2013 18:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10366; q=dns/txt; s=iport; t=1385174424; x=1386384024; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kfq1cGrEG1y7VQ6/pQ73aMNazONfXPuSqSMoZL/Ycz4=; b=I8rMe4tSSfyjdTSYdz53bbtLIe6sb7SkmCzR370RAaiKrAwddeWniWEC bG/gdbcCJwttXkoufBLkvp6rIjjOWVonz+Cs2i1yDItVXbI9MtVPG+o5P 1PJR6UVw61oLoowvtJs/HlOF8Q1M74EhKzPjL7qBIAQFeQ3ZDuxgO5R/c o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwGAFQVkFKtJXHB/2dsb2JhbAA/GoMHOLQdiEyBIBZ0giUBAQEEAQEBSyAbAgEZAwECDRsHJwoBFAcCCAIEARIJCwcCBIdgDTbAUReONEINCgEGgxqBEwOYFIEwiyOFP4FqgT6BcQ X-IronPort-AV: E=Sophos;i="4.93,756,1378857600"; d="scan'208,217";a="286966847" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 23 Nov 2013 02:40:19 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAN2eJOT027615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Nov 2013 02:40:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 20:40:18 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "rtcweb@ietf.org" , "pntaw@ietf.org" , "public-webrtc@w3.org" , "tram@ietf.org" Thread-Topic: [rfc-dist] RFC 7065 on Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers Thread-Index: AQHO5+pEXQhXjFTbG0WqzojKCtYKrZoyGt30 Date: Sat, 23 Nov 2013 02:40:18 +0000 Message-ID: References: <20131123011025.1B70275E001@rfc-editor.org> In-Reply-To: <20131123011025.1B70275E001@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C0E6C8D2EDC64CCC98C56A942D1239FBciscocom_" MIME-Version: 1.0 Subject: [rtcweb] Fwd: [rfc-dist] RFC 7065 on Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 02:40:34 -0000 --_000_C0E6C8D2EDC64CCC98C56A942D1239FBciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Excuse the cross-post, but I think this is relevant and/or has normative d= ependence.] The TURN URI scheme has been published as an RFC. Regards, Gonzalo Begin forwarded message: From: > Date: November 22, 2013 at 8:10:25 PM EST To: >, > Cc: >, > Subject: [rfc-dist] RFC 7065 on Traversal Using Relays around NAT (TURN) Un= iform Resource Identifiers A new Request for Comments is now available in online RFC libraries. RFC 7065 Title: Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers Author: M. Petit-Huguenin, S. Nandakumar, G. Salgueiro, P. Jones Status: Standards Track Stream: IETF Date: November 2013 Mailbox: petithug@acm.org, snandaku@cisco.com, gsalguei@cisco.com, paulej@packetizer.com Pages: 9 Characters: 16143 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-petithuguenin-behave-turn-uris-08.txt URL: http://www.rfc-editor.org/rfc/rfc7065.txt This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928). This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_sear= ch.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ rfc-dist mailing list rfc-dist@rfc-editor.org https://www.rfc-editor.org/mailman/listinfo/rfc-dist http://www.rfc-editor.org --_000_C0E6C8D2EDC64CCC98C56A942D1239FBciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
[Excuse the cross-post, but I think this is relevant an= d/or has normative dependence.]

The TURN URI scheme has been published as an RFC.

Regards,

Gonzalo


Begin forwarded message:

From: <rfc-edit= or@rfc-editor.org>
Date: November 22, 2013 at 8:10:25 PM EST
To: <ietf-announce@ietf= .org>, <rfc-dist@rfc-e= ditor.org>
Cc: <drafts-update-= ref@iana.org>, <rfc-= editor@rfc-editor.org>
Subject: [rfc-dist] RFC 7065 on Traversal Using Relays around NAT= (TURN) Uniform Resource Identifiers

A new Request for Comments is now available in online RFC librar= ies.


       RFC 7065

       Title:    &n= bsp; Traversal Using Relays around NAT
           &nb= sp;       (TURN) Uniform Resource Identi= fiers
       Author:    &= nbsp;M. Petit-Huguenin, S. Nandakumar,
           &nb= sp;       G. Salgueiro, P. Jones<= br>        Status:    &= nbsp;Standards Track
       Stream:    &= nbsp;IETF
       Date:    &nb= sp;  November 2013
       Mailbox:    = petithug@acm.org,
           &nb= sp;       snandaku@cisco.com,
           &nb= sp;       gsalguei@cisco.com,
           &nb= sp;       paulej@packetizer.com
       Pages:    &n= bsp; 9
       Characters: 16143        Updates/Obsoletes/SeeAlso: =   None

       I-D Tag:    = draft-petithuguenin-behave-turn-uris-08.txt

       URL:    &nbs= p;   h= ttp://www.rfc-editor.org/rfc/rfc7065.txt

This document specifies the syntax of Uniform Resource Identifier
(URI) schemes for the Traversal Using Relays around NAT (TURN)=
protocol.  It defines two URI schemes to provision the TURN
Resolution Mechanism (RFC 5928).

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track<= /span>
protocol for the Internet community,and requests discussion and sugge= stions
for improvements.  Please refer to the current edition of the In= ternet
Official Protocol Standards (STD 1) for the standardization state and=
status of this protocol.  Distribution of this memo is unlimited= .

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
 = http://www.ietf.org/mailman/listinfo/ietf-announce
 http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
rfc-dist mailing list
rfc-dist@rfc-editor.org
http= s://www.rfc-editor.org/mailman/listinfo/rfc-dist
http://www.rfc-editor.org
--_000_C0E6C8D2EDC64CCC98C56A942D1239FBciscocom_-- From sslivinski@lifesize.com Fri Nov 22 18:48:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE26D1AC499 for ; Fri, 22 Nov 2013 18:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5AkFoC47Wjq for ; Fri, 22 Nov 2013 18:48:44 -0800 (PST) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with SMTP id A8F9B1AC448 for ; Fri, 22 Nov 2013 18:48:44 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKUpAXhOTyhNtmDNkf6N4JsMuIpcwQBfpI@postini.com; Fri, 22 Nov 2013 18:48:37 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 20:40:12 -0600 From: Stefan Slivinski To: Adam Roach , "rtcweb@ietf.org" Date: Fri, 22 Nov 2013 20:40:11 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7n8fVWUD+fxfRFRNGaGRX5W+QD+QAAuNSw Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E6769@ausmsex00.austin.kmvtechnologies.com> References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> <52900FDB.3030803@nostrum.com> In-Reply-To: <52900FDB.3030803@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 02:48:47 -0000 VGhpcyBpc24ndCBzcGVjaWZpY2FsbHkgaW4gcmVzcG9uc2UgdG8gYW55dGhpbmcgeW91IGhhdmUg c2FpZCwgdGhpcyB0aHJlYWQgaXMgYWJvdXQgSC4yNjEsIEknbSBzaW1wbHkgYWRkcmVzc2luZyBh cmd1bWVudHMgbWFkZSBpbiBmYXZvciBvZiBILjI2MSBhcyB0aGUgc2luZ2xlIE1USSBhbmQgdGhl IHByb2JsZW1zIHRoYXQgd2lsbCBhcmlzZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dIA0KU2VudDogRnJpZGF5 LCBOb3ZlbWJlciAyMiwgMjAxMyA2OjE2IFBNDQpUbzogU3RlZmFuIFNsaXZpbnNraTsgcnRjd2Vi QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gSC4yNjENCg0KT24gMTEvMjIvMTMgMTk6 NDIsIFN0ZWZhbiBTbGl2aW5za2kgd3JvdGU6DQo+IEp1c3QgZm9yIGZ1biwgbGV0J3MgcGxheSBv dXQgdGhlIEguMjYxIHNjZW5hcmlvIGFzIHRoZSBncmVhdCBzYXZpb3Igb2Ygd2VicnRjIHRoYXQg c29tZSBjbGFpbSBpdCBpcy4uLg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEFkYW0gUm9hY2ggDQo+IC4uLg0KPiBJJ20gMTAwJSBjb25maWRlbnQgdGhhdCB3ZSBjb3VsZCBj b252aW5jZSBDaXNjbyB0byBzZXJ2ZSB1cCBSUE1zLi4uDQoNCg0KU3RlZmFuOiBUaGlzIGlzIHRo ZSBzZWNvbmQgY29tcGxldGVseSBub24tc2VxdWl0dXIgcmVzcG9uc2UgeW91J3ZlIHNlbnQgdG8g bXkgZW1haWxzIG92ZXIgdGhlIGNvdXJzZSBvZiBmaXZlIG1pbnV0ZXMuIEknbSBub3Qgc3VyZSB3 aGF0IHlvdSdyZSB0cnlpbmcgdG8gYWNjb21wbGlzaCwgYnV0IEkgZG9uJ3QgdGhpbmsgaXQncyBw cm9kdWN0aXZlLg0KDQovYQ0K From adam@nostrum.com Fri Nov 22 19:38:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F1C1AD6B9 for ; Fri, 22 Nov 2013 19:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GKuoh1ZDXCK for ; Fri, 22 Nov 2013 19:38:32 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 10AC71AD66E for ; Fri, 22 Nov 2013 19:38:32 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAN3cHRH057310 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Nov 2013 21:38:18 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52902324.1050401@nostrum.com> Date: Fri, 22 Nov 2013 21:38:12 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ron , rtcweb@ietf.org References: <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <20131123022750.GE3245@audi.shelbyville.oz> In-Reply-To: <20131123022750.GE3245@audi.shelbyville.oz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 03:38:33 -0000 On 11/22/13 20:27, Ron wrote: > So, now you want people to give Cisco not only the ability to > install binary blobs on their machine -- but a root shell to do > it as well? What could possibly go wrong. It's... uh... um... I'm a bit incredulous. Look, it's *Cisco*. If they *wanted* to attack you, this would be possibly the least worrisome vector. /a From sslivinski@lifesize.com Fri Nov 22 20:05:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0901AD8F9 for ; Fri, 22 Nov 2013 20:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7kLU-2rPTMi for ; Fri, 22 Nov 2013 20:05:26 -0800 (PST) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with SMTP id 237621AD939 for ; Fri, 22 Nov 2013 20:05:26 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKUpApfhQjVHh9r74xrcNgDiiO4ZJEFw33@postini.com; Fri, 22 Nov 2013 20:05:19 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 21:58:41 -0600 From: Stefan Slivinski To: =?iso-8859-1?Q?Herv=E9_W=2E?= , "rtcweb@ietf.org" Date: Fri, 22 Nov 2013 21:58:39 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7n+cohOgYLaem6T+62nsqP+AkzeAABcH2Q Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E676A@ausmsex00.austin.kmvtechnologies.com> References: <528F9DAD.3030300@googlemail.com>, <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com>, <528FAAA8.8060807@googlemail.com>, <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com>, <528FB79F.8090405@gmail.com>, <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com>, <528FBD13.5040801@gmail.com>, <528FD429.7090002@nostrum.com>, <528FDE5E.5080301@librevideo.org>, , <20131123003548.GD3245@audi.shelbyville.oz>, <529006BB.609@nostrum.com>, <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 04:05:29 -0000 yes, it appears I missed that....Byran Donnovan's point is exactly in line = with my comment here, even a small sized multiway conferences has a high li= kelihood of dissimilar browsers and will either require a transcoding MCU o= r they will be forced down to a common codec. -----Original Message----- From: Herv=E9 W. [mailto:h_o_w_@hotmail.com]=20 Sent: Friday, November 22, 2013 7:12 PM To: Stefan Slivinski; rtcweb@ietf.org Subject: RE: [rtcweb] H.261 ---------------------------------------- > From: sslivinski@lifesize.com > Just for fun, let's play out the H.261 scenario as the great savior of we= brtc that some claim it is: > Let's say through some divine miracle we manage to all agree to make H.26= 1 the one and only MTI codec. The rationale being of course that no one wil= l ever use it because it is of course terrible, but we need it to get aroun= d those pesky patent/license terms with VP8/H.264 respectively. Either you need the fallback codec or no one will ever use it. They can't b= oth be right. I realise that you're illustrating that exact point below, bu= t you're misrepresenting the rationale behind h.261, I think. > Alright fast forward, Chrome adds H.261 but continues to use VP8. IE uses= H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, H.264= and VP8. So far so good. Chrome can talk using VP8 to Firefox, Safari can = talk H.264 to IE, Firefox can either H.264 or VP8 to everyone. As long as C= hrome users don't try to call IE or Safari, we're in good shape, otherwise = we need to transcode using some undefined cloud based transcoder service or= just use H.261. > > So we're still in good shape. Now let's consider the multiway case. I hea= rd a use case at the conference on Tuesday where a university was using web= rtc to enable video online classes. So let's assume there are 20 people in = the class. 19 people in the class love Chrome, so they join the class from = chrome and are all sending each other VP8. But of course there's always one= person that has to be difficult and they decide they prefer IE. So what no= w? Well the IE person doesn't understand any of the 19 VP8 streams and the = 19 chrome users don't understand the 1 H.264 stream. So we can now utilize = that same undefined cloud transcoding service to convert each of the 19 VP8= streams to H.264 and the 1 H.264 stream to VP8....or we can use H.261. Yes, they can offer an extra H.261 stream to that IE user and receive a H.2= 61 stream from them. And then watch H.261 play about as well as the 18 othe= r P2P streams, while they clog up their Wifi and overheat their laptops ? I think you've found a scenario that might benefit from No MTI; audio only = or no streams to/from the IE user can't hurt network performance. > My guess is H.261 is going to get used a lot more than anyone thinks. related to that: http://www.ietf.org/mail-archive/web/rtcweb/current/msg100= 58.html - Herv=E9 =20 From ekr@rtfm.com Fri Nov 22 20:24:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C57A1ADBD5 for ; Fri, 22 Nov 2013 20:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY1KB_zvNf93 for ; Fri, 22 Nov 2013 20:24:20 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 518B61ADBD3 for ; Fri, 22 Nov 2013 20:24:20 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hq4so1580021wib.15 for ; Fri, 22 Nov 2013 20:24:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XdMItdCaG4Ijriw24ON/EwD/nssVYhFDeIOFxn0/LPk=; b=B1MbpEcqmfzbZpYrGId75/tfcTE1J0eaQ8z3b2czfO5cY3soIr9+vM/M4kUL02fFmP TWoc9SsrRpP+2RKVoJb+C6nzxQb9tiULHQX5/+mMfw0Y+Rgx6GOAQCcNpZPPGoKUVZhG l7USxO2xrefkfQib55WQU01Fbmmz/QnLLlzyl9EDkxF84Gss5XQ7IekV/LHb+IKVPWUP G0+H3cssFffrHAvzdlj7yp58DC9Yw9DE6gFGccoEUaiSwTb31sZqm5YBn3DKUff5UR2K UJquIY4ikmSFGE3x/P9E338QuVkNZpuUnc17+4yHItIiw6KGN+hSc0Fp3o5GEHbipxY5 FWoA== X-Gm-Message-State: ALoCoQlqigO/1v4oQwYhYpOrIv9Dwn8BZxeIuzQjx8EghBlkD77EklFEfkQe8cXIuchO0oDLT9Dj X-Received: by 10.180.75.202 with SMTP id e10mr5261035wiw.8.1385180652546; Fri, 22 Nov 2013 20:24:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Fri, 22 Nov 2013 20:23:32 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: <52902324.1050401@nostrum.com> References: <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <20131123022750.GE3245@audi.shelbyville.oz> <52902324.1050401@nostrum.com> From: Eric Rescorla Date: Fri, 22 Nov 2013 20:23:32 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=f46d04389569bec14704ebd080e7 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 04:24:22 -0000 --f46d04389569bec14704ebd080e7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 22, 2013 at 7:38 PM, Adam Roach wrote: > On 11/22/13 20:27, Ron wrote: > >> So, now you want people to give Cisco not only the ability to >> install binary blobs on their machine -- but a root shell to do >> it as well? What could possibly go wrong. >> > > It's... uh... um... I'm a bit incredulous. > > Look, it's *Cisco*. If they *wanted* to attack you, this would be possibly > the least worrisome vector. And of course the binaries would be digitally signed and one could do verifiable builds. -Ekr --f46d04389569bec14704ebd080e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Nov 22, 2013 at 7:38 PM, Adam Roach <<= a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g= t; wrote:
On 11/22/13 20:27, Ron wro= te:
So, now you want people to give Cisco not only the ability to
install binary blobs on their machine -- but a root shell to do
it as well? =A0What could possibly go wrong.

It's... uh... um... I'm a bit incredulous.

Look, it's *Cisco*. If they *wanted* to attack you, this would be possi= bly the least worrisome vector.

And of cour= se the binaries would be digitally signed and one could do
verifi= able builds.

-Ekr
=A0
--f46d04389569bec14704ebd080e7-- From mzanaty@cisco.com Fri Nov 22 20:45:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487E51ADEC0 for ; Fri, 22 Nov 2013 20:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.026 X-Spam-Level: X-Spam-Status: No, score=-15.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VSho_McwBHq for ; Fri, 22 Nov 2013 20:45:34 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B46991ADEA7 for ; Fri, 22 Nov 2013 20:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1397; q=dns/txt; s=iport; t=1385181927; x=1386391527; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eY5SYQOtxqMhuGmS+f/Ljq1cLiNPS7zUzLJs5aliSMQ=; b=QdcpO/oVOyDEkddnlF4XHilvon9I+7iZ5il8KdOMWPdLW4QUrVyqN39H 2aXKOCbOfpWPC/qStAr6sb6smNuGf8GmZc0P3/rpQ95gJrDp0POMKzm2R GqVCjiisuoTYrM0JEWPPYrtkmflKj77NjzpZxj15VuQFlt/FSf6N8Bi8C I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAK8xkFKtJXG+/2dsb2JhbABZgwc4U7tLToEYFnSCJQEBAQQBAQFrGwIBCBguJwslAgQBEhSHbQ3BARePDoQzA4kKjwqBMJBigyiCKg X-IronPort-AV: E=Sophos;i="4.93,757,1378857600"; d="scan'208";a="284013324" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 23 Nov 2013 04:45:27 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAN4jRFL004889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Nov 2013 04:45:27 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 22:45:27 -0600 From: "Mo Zanaty (mzanaty)" To: Adam Roach , Ron , "rtcweb@ietf.org" Thread-Topic: [rtcweb] H.261 Thread-Index: AQHO6AbUdnbX26j7lEitdW8mVk/1iA== Date: Sat, 23 Nov 2013 04:45:26 +0000 Message-ID: References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> In-Reply-To: <529006BB.609@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.212.195] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2A8F8DC0A7E14742AC416501820A11BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 04:45:36 -0000 All major distros including Debian already include x264, ffmpeg, etc. http://packages.debian.org/wheezy/x264 Those packages offer no patent license at all. What is the perceived unique risk of Cisco=B9s H.264? It attempts to license the patents legally instead of leaving users bare naked. If the FOSS community sees this as worse than the current situation, and feels its users are better off naked, it would be good to understand why. Mo On 11/22/13, 8:36 PM, Adam Roach wrote: On 11/22/13 18:35, Ron wrote: > The whole point of many distros is to supply binaries, often built > many times for many different system architectures. And the overwhelming majority of these do so by including a list of repositories from which the binaries can be downloaded. I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, and whatever else is needed for these distros, targeting whatever platforms are required. Now, whether we can get the distro maintainers to add a single line to their list of repos -- because that's all it would take -- is a different issue. But at that point, it's just a matter of the distro maintainers being intransigent rather than any real technical or legal barrier. /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From cowwoc@bbs.darktech.org Fri Nov 22 23:00:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5660D1AE0DE for ; Fri, 22 Nov 2013 23:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk_7Y2QyS11Z for ; Fri, 22 Nov 2013 23:00:17 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4B41AE0E9 for ; Fri, 22 Nov 2013 23:00:16 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so3659281iec.5 for ; Fri, 22 Nov 2013 23:00:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yo+gQxeCW1j7KRfiTAvlSbMOVpgI9vFTPfCwVXFw3TA=; b=bAJTVtCXQlYsFqfRiIPOJ4SZ2+irJtMqRxtnNKu/s/lE7wmYXh4eTkU4WhhiaqHzmk 6MMBgWVS2iudeZX0MOGy+ABDD2UYOddEPhgoOfyOM5T5sBPFyhHGUBaZIIa3DLs8VWG+ vmeBdxcgYsewJzyjZ3BCTxPu+gRwoNsiW3AR4+MyzX8/GZalIQxUD90yUC1egDlr3sRD 73mUMiin/I9b8TFV1NrUqhptbK8aKyggVQn/YHMMDQQ+qHYm1xLNuarO5KOJZEDOfWl9 qDnicj7va2RJ8tnZHVwR35jKkrDs4q05oij9UB9jNLOtRZmSKdwFy8SVV47rPYvFFy3x FbVQ== X-Gm-Message-State: ALoCoQkAvpIMwfiC7N0TmbDzsPecTOmLNRU5ngVonFK3v8SBBr1BFI0TnxEa2i9mbrC+kBKuXP++ X-Received: by 10.50.92.8 with SMTP id ci8mr5403918igb.23.1385190008965; Fri, 22 Nov 2013 23:00:08 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id a17sm13235172ign.2.2013.11.22.23.00.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 23:00:08 -0800 (PST) Message-ID: <52905257.1060209@bbs.darktech.org> Date: Sat, 23 Nov 2013 01:59:35 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E671A@ausmsex00.austin.kmvtechnologies.com> <528FC513.4020903@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E6731@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E6731@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Opinions are fine, bypassing a vote is not (was: H.261) X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 07:00:19 -0000 This post is not meant to target Stefan specifically. It is a general statement based on what I've noticed over the past 200+ posts on this topic. I am ... concerned ... by the apparently attempt by certain individuals to have options removed ahead of a possible vote. It is one thing to explain your opinion in order to encourage/discourage people from voting for it. It is another matter to imply that an option is a "waste of time" because only a "vocal minority" seems to care about it or that "given the choice between what you are proposing and X, most developers would prefer X". If no one is in favor of H.261 "except for a vocal minority" or "most developers would prefer X" then you have nothing to worry about. Let the community vote and see where the chips land. I don't think it's safe to rely on "vocal minorities" to gauge what the community at large prefers. The only way to find out is to ask them (and that's what the vote is all about). Everyone should be free to express their opinion for/against an option, but no option should be removed ahead of a vote. Just my 2 cents. Gili On 22/11/2013 4:14 PM, Stefan Slivinski wrote: > Why don't we add the "must support both H.264 and VP8 decode and must support at least one of H.264 or VP8 encode" to the list of options and ask for a show of hands as to what people are in favor of. This would be non-binding, simply a status check. Maybe no one is in favor of H.261 except for a vocal minority in which case we're wasting time arguing about it. > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Basil Mohamed Gohar > Sent: Friday, November 22, 2013 12:57 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > On 11/22/2013 03:44 PM, Stefan Slivinski wrote: >> Thank you for the link. >> >> The point I'm trying to make is H.261 will harm the proliferation of webrtc far more than it will help. This is purely a technical argument speaking to quality and error resiliency. >> >> Has anyone listed the concerns surrounding H.264 and have these been raised with mpeg-la to see if they can make adjustments to the license agreement. They have certainly done so in the past. > Believe it or not, the MPEG-LA is currently trying to establish a royalty-free subset of H.264 called "Constrained Baseline Profile", which is very similar to the most commonly-used subset of H.264 features out there. > > The problem is, it's not done yet, and there's no indication whether or not it will be successful or not. This would require all existing stakeholders in H.264 licensing to agree to this royalty-free variant for it to matter. > > There's another effort to do the same with one using MPEG-1 as a base. > > The problem is, none of these formally exist in royalty-free forms as of yet. Everything else we've discussed, though, does, including H.261. > > And, for what it's worth, I disagree about H.261. Yes, H.264 and/or VP8 (and a whole list of other codecs) will look *better*, but I think being able to communicate via video over H.261 is better than not being able to all. > > And we are at a point where "not at all" is going to happen because the WG is effectively split over using VP8 and H.264. > > -- > Libre Video > http://librevideo.org > _______________________________________________ > 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 From cowwoc@bbs.darktech.org Fri Nov 22 23:24:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99C21AE135 for ; Fri, 22 Nov 2013 23:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6QyBpyVAKek for ; Fri, 22 Nov 2013 23:24:03 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id CC2D61AE0EB for ; Fri, 22 Nov 2013 23:24:03 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id e14so3736079iej.14 for ; Fri, 22 Nov 2013 23:23:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QjH4LLsYFxrUz6qQ/Cmvqt3WKCvxW5XgyVKGpc72eak=; b=N9CLgCgL/C0MlAjWuG84hW+UYp4bA+xTChiMeaK/oSAzDxxjFbXo7dHw3nL/qEjL2p 3uQzgsRDuOyz+MnvExLvjzeeVn+YM7ukIgRuJB7HdoNGzdEpNiQP4yrnAhDlKcCsfdj/ gXSGsKmpyUEENOYC4PMBoCzv3cOMzyiMDw7o8arZjQpBrsWd5ZK/iklFnB1mcpP+w5AI xoCg+Sq9yvmxXrZ1O3OKroEhSiuLsK1MpBekOC7jrOsk5W0ct5OCo54LRYi9tarbhlKx 6H8N7Cs7e0nCYFc6OkORzH5J/nnWPjanWH7kYT6+JYbJ3rmptDH1jF+zOY13UV/Epo4g UXHw== X-Gm-Message-State: ALoCoQnbYl2jmWaSuxhObQyvLjnlaqbBynv7wgAvUX6byyBAXhNbxpaqN8AuY6TRZ65ZTivyL0Eo X-Received: by 10.50.4.105 with SMTP id j9mr5401728igj.52.1385191436277; Fri, 22 Nov 2013 23:23:56 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id qi3sm13282204igc.8.2013.11.22.23.23.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 23:23:55 -0800 (PST) Message-ID: <529057EB.3060704@bbs.darktech.org> Date: Sat, 23 Nov 2013 02:23:23 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 07:24:06 -0000 Stefan, At the conference, they mentioned that you cannot implement online video classes (with 20+ participants) unless you reduce the resolution and frame rate of non-speakering participants. Meaning, even without having to do any transcoding (they use VP8 across the board) there is insufficient bandwidth and CPU to handle 20 incoming video streams at HD resolutions. So what you do is host non-speakers at tiny resolutions and 3 fps. H.261 could handle those non-speakers just fine (in fact, it would be preferable as it reduces CPU usage). Furthermore, if you chose to transcode, you'd be dealing with tiny resolutions and 3fps. In both cases, the use of H.261 or transcoding is not the bottleneck. Gili On 22/11/2013 8:42 PM, Stefan Slivinski wrote: > Just for fun, let's play out the H.261 scenario as the great savior of webrtc that some claim it is: > > Let's say through some divine miracle we manage to all agree to make H.261 the one and only MTI codec. The rationale being of course that no one will ever use it because it is of course terrible, but we need it to get around those pesky patent/license terms with VP8/H.264 respectively. > > Alright fast forward, Chrome adds H.261 but continues to use VP8. IE uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, H.264 and VP8. So far so good. Chrome can talk using VP8 to Firefox, Safari can talk H.264 to IE, Firefox can either H.264 or VP8 to everyone. As long as Chrome users don't try to call IE or Safari, we're in good shape, otherwise we need to transcode using some undefined cloud based transcoder service or just use H.261. > > So we're still in good shape. Now let's consider the multiway case. I heard a use case at the conference on Tuesday where a university was using webrtc to enable video online classes. So let's assume there are 20 people in the class. 19 people in the class love Chrome, so they join the class from chrome and are all sending each other VP8. But of course there's always one person that has to be difficult and they decide they prefer IE. So what now? Well the IE person doesn't understand any of the 19 VP8 streams and the 19 chrome users don't understand the 1 H.264 stream. So we can now utilize that same undefined cloud transcoding service to convert each of the 19 VP8 streams to H.264 and the 1 H.264 stream to VP8....or we can use H.261. > > My guess is H.261 is going to get used a lot more than anyone thinks. > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Friday, November 22, 2013 5:37 PM > To: Ron; rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > On 11/22/13 18:35, Ron wrote: >> The whole point of many distros is to supply binaries, often built >> many times for many different system architectures. > And the overwhelming majority of these do so by including a list of repositories from which the binaries can be downloaded. > > I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, and whatever else is needed for these distros, targeting whatever platforms are required. Now, whether we can get the distro maintainers to add a single line to their list of repos -- because that's all it would take -- is a different issue. But at that point, it's just a matter of the distro maintainers being intransigent rather than any real technical or legal barrier. > > /a > _______________________________________________ > 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 From cowwoc@bbs.darktech.org Fri Nov 22 23:31:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF181AE154 for ; Fri, 22 Nov 2013 23:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObFqeengVeKP for ; Fri, 22 Nov 2013 23:31:06 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id 54B881ADFAF for ; Fri, 22 Nov 2013 23:31:06 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at1so3591734iec.7 for ; Fri, 22 Nov 2013 23:30:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cQjbmj4bt8mWhoP54ueydCQteIngkzPBZeLc63A4RHU=; b=GoRL7jpINN78+DiKQH5peGNDAKGxqhwPmsLoM9mJ9UOmDYyoXHo8xmRRzhyX426/Sg E6vnkQFJOnxLCUk6kgsRogZCXtqgsB75YmPpaYAQb4gaGDCi7UvyEtXHrhPm3+/KNm89 pl9eh7zQgx3u1ytOe1fNgmrePZH3OFeZBv+yb70dw/hoWN4PZ/6OEuPzvGIvQAPwGCQp ztdy6DHz6IKck/j+hcgYhxM8BXzZK6IjT0B6QH/VmB3jr1qMlg10ePwD3+rEjw5EFzSR APYxPSF6phqvYki8t+0RExawegODQmYWXHA49I2TvIqM/QvdLbMzurGf8UEOVbZm8Q8T zmCA== X-Gm-Message-State: ALoCoQkBLksLwFwb0pbHccDoLM3FTT8MNv4dUkuqVEcB+c9CLfzSWGyPSNUoXSmG1YjQAkvpDro1 X-Received: by 10.50.1.102 with SMTP id 6mr5634709igl.0.1385191857901; Fri, 22 Nov 2013 23:30:57 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id hv5sm13973062igb.9.2013.11.22.23.30.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 23:30:57 -0800 (PST) Message-ID: <52905990.8070207@bbs.darktech.org> Date: Sat, 23 Nov 2013 02:30:24 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52891EDB.2050607@googlemail.com> <528B2ABE.4040701@googlemail.com> <528C79AD.10608@googlemail.com> <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com> <528E5E89.8040706@googlemail.com> In-Reply-To: <528E5E89.8040706@googlemail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [rtcweb] H.264 CBP (was: Video codec selection - way forward) X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 07:31:08 -0000 +1 In the original VP8 vs H.264 discussion, what H.264 profile was under discussion? If it was not H.264 CBP, do we need to revisit the comparison? Do the two profiles use the same bandwidth, CPU and produce the same quality? Thanks, Gili On 21/11/2013 2:27 PM, Maik Merten wrote: > Btw, should any occurrence of "H.264" in the current list of options > be substituted with "H.264 CBP"? Perhaps it is best to be very clear > on the profile which should be implemented. > > Thanks, > > Maik > > Am 21.11.2013 20:20, schrieb David Singer: >> Chairs >> >> can we add this as an option to the formal list, so we get formal >> feedback on its acceptability, please? >> >> “Like option ??, pick at least two of {VP8, H.264 CBP, H.263}” >> >> >> I think this may be the best (maybe only) way to tease out how much >> risk people perceive. >> >> Many thanks >> >> On Nov 21, 2013, at 9:22 , Maik Merten >> wrote: >> >>> Cleary H.263 is preferable from an engineering standpoint (as is, >>> e.g., MPEG-1 Part 2): better performance, more deployments. The >>> central question is, however, if those can actually be implemented >>> without some sort of licensing. >>> >>> If they can: Aweseome! However, this may not be determinable without >>> a review by people who are knowledgeable in the field of IPR, i.e., >>> "actual lawyers". I understand that H.263 is not yet old enough to >>> automatically be considered "safe" (and neither is MPEG-1 Part 2, >>> although it is closer). >>> >>> Best regards, >>> >>> Maik >>> >>> Am 20.11.2013 20:42, schrieb David Singer: >>>> I think we should think hard about H.263 instead of H.261 as the >>>> third fallback. Why? >>>> >>>> http://www.itu.int/rec/T-REC-H.263/ >>>> >>>> >>>> >>>> H.263 was first published in March 1996, so it's 17 years old. The >>>> restrictions (e.g. on picture size) are no WORSE than H.261. Yes, >>>> more recent amendments deal with this (and a plethora of other >>>> issues), so we’d need to settle on which of those are mandatory >>>> (the usual profiling discussion). >>>> >>>> There are 34 records in the patent database against H.261, mostly >>>> from 1989 but one as recent as 2005 (though that is a re-file). >>>> That's 2.2 (reciprocity), as was one other I checked. >>>> >>>> Rather surprisingly, there are only 31 against H.263! The most >>>> recent is 2011, and is also option 2. Most are 1997-2001. >>>> >>>> >>>> On this quick glance, H.263 appears no worse than H.261. IANAL (as >>>> I am sure you have all noticed). >>>> >>>> >>>> H.263 is much more widely supported and mandated. It has been >>>> mandated in the 3GPP specs for years (for lots of services, >>>> including videoconf), and is effectively the fallback codec today >>>> in the industry, as I understand. It was ubiquitous in video >>>> telephony for years, and I suspect many of those systems still ship >>>> it. >>>> >>>> So, would “MUST implement at least two of (H.264, VP8, H.263)” work? >>>> >>>> (I am asking the question, not even answering on behalf of my >>>> company, yet. Let’s get the issues on the table.) >>>> >>>> >>>> David Singer >>>> Multimedia and Software Standards, Apple Inc. >>>> >>>> _______________________________________________ >>>> 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 >> >> David Singer >> Multimedia and Software Standards, Apple Inc. >> >> _______________________________________________ >> 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 From cowwoc@bbs.darktech.org Sat Nov 23 00:34:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F701AE1C9 for ; Sat, 23 Nov 2013 00:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmkS4sXXu9kX for ; Sat, 23 Nov 2013 00:34:39 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46F061AE1BE for ; Sat, 23 Nov 2013 00:34:39 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id qd12so3778809ieb.31 for ; Sat, 23 Nov 2013 00:34:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=QvYBFhN9DcNotCvi6w/oNlpOpRjg/o1f7H2eZ1RVEdA=; b=TxZk6XhSuhZxu+i4gO3RQtsekjOW/b4KhL4Yul8S0J7xS5J0+7s3wTZzIFF6CPG9Wo upokfAJ3IHgbsNRzRaGf4ByIfK5HpnxmNt8jgo1HiKgDMd+yK9SkxXDjZsm935vosktT wP1swk+YRxg8z86GV1lFsQkUWe6sqUhnPf0tIReARt4hNIcbYnei9SSKuud6eSsBWXZ2 5eqMSth6sTDIZrAeIcij6pAGZKNdEzlIkAQRlR0pbtqgmgTC2giiR2EaouUJqlspZe+T RPi+PKg5Zjf9lJ5QP9pIH1rdK28ThPG16ZaTrGF/RF5zJC6cEf0xBqak0UC8LHyWUigX PKpg== X-Gm-Message-State: ALoCoQlzTGvO9Qh19b9SabtnuIgNCcwbPZTi09yBrVW/+LWbdS1WjxnEJpyPucLNi7pE0fxqx3NL X-Received: by 10.50.134.99 with SMTP id pj3mr5722258igb.14.1385195671719; Sat, 23 Nov 2013 00:34:31 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id q6sm13541275igi.0.2013.11.23.00.34.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 00:34:30 -0800 (PST) Message-ID: <52906876.4000509@bbs.darktech.org> Date: Sat, 23 Nov 2013 03:33:58 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <528E39F4.4010706@ericsson.com> In-Reply-To: <528E39F4.4010706@ericsson.com> Content-Type: multipart/alternative; boundary="------------020707070204000505010902" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 08:34:43 -0000 This is a multi-part message in MIME format. --------------020707070204000505010902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Here is a condensed response to the past 200+ posts :) * Instant run-off voting o I don't think that voting will solve all of the problems mentioned below, but if all other options fail (which we're close to) then I'm in favor of going ahead with the proposed process. o Whatever process we agree to should end with a binding decision at the end (as opposed to more endless debate). * People objecting to the very idea of voting (versus making the decision on a technical merit) miss the fact that this is no longer a technical debate. o We have already agreed that both VP8 and H.264 are technically "good enough". The only remaining differences are of a political and licensing in nature. * Voting will not solve (legitimate) licensing/IPR issues o For example, mandating H.264 as MTI won't help Debian because they cannot count license units. o We should brainstorm on how to remove these show-stoppers for all stakeholders (browsers, non-browsers, FOSS, Commercial). The "MUST implement 2 out of 3" approach is an example of how this can be done. * Who should participate o Either we should include anyone who posted on WebRTC mailing lists (rtcweb, public-webrtc, public-media-capture) or we should be try to be more inclusive by including anyone who merely subscribed to said lists. o As was suggested, publishing the full list of all voters along with their votes should remove any doubt of fraud. If we notice that 5000 voters came from the same company, we can legitimately question whether they are all active or whether they attempted to stuff the ballot. * Removing voting options o I think it is vital that we leave all options on the table (however silly some might think they are) and see where the chips drop. o I understand that some people object to a long list of options, but I'd rather err on the side of inclusivity than censorship. :) * Non-browsers are equally important o Most of the debate on this mailing list have centered around what the browsers will do, but if you've attended the WebRTC World conference over the past couple of years you will have noticed that a great number of demos are based on native applications (even more so as mobile adoption increases). There is a very strong interest in using WebRTC outside of the browser and any decision we make here should reflect that reality. * Endless debates aren't free o One thing that was evident at the conference is that many of companies are "moving beyond the specification". o The longer we debate these issues, the more likely we are to end up with a specification that simply documents the de-facto standard laid out by early adopters. * We need a higher-level Native API that mirrors the Javascript API o It's become evident that many companies in the conference are re-inventing the same wheel: namely, they are reimplementing features found in the Javascript API on top of the Native API. o Imagine how many developer years could be saved if the Native API provided some of these higher-level constructs. This ties into my earlier point that "non-browsers are equally important" to take into consideration. Thank you for the interesting conversation. It was nice meeting many of you at the conference! :) Gili On 21/11/2013 8:51 AM, Magnus Westerlund wrote: > WG, > > The WebRTC ecosystem needs to avoid interoperability failure to grow > optimally. The RTCWEB working group took on the task of establish Audio > and Video MTI codecs as part of meeting that need. We have not succeeded > in finishing that task for video using normal IETF process, but it is > still important. > > We (WG chairs) are proposing that the working group consent to a method > that will establish an MTI, even if the MTI chosen does not have rough > consensus. We would far prefer the normal IETF process, but it is not > proving workable for this selection. > > We initially proposed a method from RFC 3929 (external review team), but > now believe that the working group would not consent to that method. > Instead we are proposing a method that leaves the decision in the hands > of the WG. > > The method we propose is based on Instant-runoff voting, > http://en.wikipedia.org/wiki/Instant-runoff_voting, with the > understanding that the choice will be the winner according to the > Instant-runoff voting process. > > The steps in the proposed process are these (1-5): > > 1) Establish a final list of alternatives, based on the WG's input to > Gonzalo's email on the 13th of November that requires any additions to > provided by end of the 27th of November. > > 2) Establish those eligible to vote. Any participant in the > working group process either electronically or in-person as of yesterday > (20th of November). Who has participated in the Working group process > will be anyone that can be identified from: > - The Blue Sheets for any RTCWEB WG session during an IETF meeting or > an interim meeting since the WG's creation. > - posting of at least one email to the RTCWEB mailing list > > The voter must at time of voting prove their eligibility, by pointing to > the mail archive or a particular blue sheet/meeting. Please verify your > own eligibility. > > 3) Start the the voting period. Those eligible and willing to vote send > their ballot to a vote collector (Matt Lepinski, former Nomcom chair) > within two weeks using email. The vote collector will check when > receiving a ballot the that the voter is eligible and send a > confirmation email on receiving the ballot. During the balloting period > the vote collector will keep all ballots secret. > > Balloting: > - The voter MUST rank ALL alternatives in their ballot from the most > preferred, marked with rank 1, the second most with 2, all the way > to the least preferred marked with rank N. > > > 4) When the voting period is over the ballot collector will publish the > results as well as all ballots, including the voters name to the RTCWEB > WG mailing list. This enables all voting individuals to verify that > their ballot is unmodified. And allows anyone to verify the result of > the vote. > > 5) The selection is recorded in the drafts. > > > --- End of Process Proposal --- > > This message initiates the first step in the working group consensus > call process. Namely a one week comment and discussion period for the > above process. > > After that week the WG chairs will update, if necessary, the proposal. > Then using the normal IETF process in which anyone is eligible to > participate, the chairs will ask for (rough) consensus to adopt this > extraordinary process to achieve the working group's stated goals. The > end date for this consensus call is 2-weeks after the announcement of > the consensus call. > > If the working group does not consent to using this extraordinary > process, we will hold a consensus call if the WG can accept > "WebRTC entities MUST support at least one of H.264 or VP8.". > > If there is failure to establish consensus even for this statement, the > chairs conclude that the WG can't establish what to say about a MTI > video codec. > > The WG Chairs > > Magnus Westerlund > Cullen Jennings > Ted Hardie > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020707070204000505010902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

Here is a condensed response to the past 200+ posts :)
  • Instant run-off voting
    • I don't think that voting will solve all of the problems mentioned below, but if all other options fail (which we're close to) then I'm in favor of going ahead with the proposed process.
    • Whatever process we agree to should end with a binding decision at the end (as opposed to more endless debate).
  • People objecting to the very idea of voting (versus making the decision on a technical merit) miss the fact that this is no longer a technical debate.
    • We have already agreed that both VP8 and H.264 are technically "good enough". The only remaining differences are of a political and licensing in nature.
  • Voting will not solve (legitimate) licensing/IPR issues
    • For example, mandating H.264 as MTI won't help Debian because they cannot count license units.
    • We should brainstorm on how to remove these show-stoppers for all stakeholders (browsers, non-browsers, FOSS, Commercial). The "MUST implement 2 out of 3" approach is an example of how this can be done.
  • Who should participate
    • Either we should include anyone who posted on WebRTC mailing lists (rtcweb, public-webrtc, public-media-capture) or we should be try to be more inclusive by including anyone who merely subscribed to said lists.
    • As was suggested, publishing the full list of all voters along with their votes should remove any doubt of fraud. If we notice that 5000 voters came from the same company, we can legitimately question whether they are all active or whether they attempted to stuff the ballot.
  • Removing voting options
    • I think it is vital that we leave all options on the table (however silly some might think they are) and see where the chips drop.
    • I understand that some people object to a long list of options, but I'd rather err on the side of inclusivity than censorship. :)
  • Non-browsers are equally important
    • Most of the debate on this mailing list have centered around what the browsers will do, but if you've attended the WebRTC World conference over the past couple of years you will have noticed that a great number of demos are based on native applications (even more so as mobile adoption increases). There is a very strong interest in using WebRTC outside of the browser and any decision we make here should reflect that reality.
  • Endless debates aren't free
    • One thing that was evident at the conference is that many of companies are "moving beyond the specification".
    • The longer we debate these issues, the more likely we are to end up with a specification that simply documents the de-facto standard laid out by early adopters.
  • We need a higher-level Native API that mirrors the Javascript API
    • It's become evident that many companies in the conference are re-inventing the same wheel: namely, they are reimplementing features found in the Javascript API on top of the Native API.
    • Imagine how many developer years could be saved if the Native API provided some of these higher-level constructs. This ties into my earlier point that "non-browsers are equally important" to take into consideration.

    Thank you for the interesting conversation. It was nice meeting many of you at the conference! :)

Gili

On 21/11/2013 8:51 AM, Magnus Westerlund wrote:
WG,

The WebRTC ecosystem needs to avoid interoperability failure to grow
optimally.  The RTCWEB working group took on the task of establish Audio
and Video MTI codecs as part of meeting that need. We have not succeeded
in finishing that task for video using normal IETF process, but it is
still important.

We (WG chairs) are proposing that the working group consent to a method
that will establish an MTI, even if the MTI chosen does not have rough
consensus.  We would far prefer the normal IETF process, but it is not
proving workable for this selection.

We initially proposed a method from RFC 3929 (external review team), but
now believe that the working group would not consent to that method.
Instead we are proposing a method that leaves the decision in the hands
of the WG.

The method we propose is based on Instant-runoff voting,
http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
understanding that the choice will be the winner according to the
Instant-runoff voting process.

The steps in the proposed process are these (1-5):

1) Establish a final list of alternatives, based on the WG's input to
Gonzalo's email on the 13th of November that requires any additions to
provided by end of the 27th of November.

2) Establish those eligible to vote.  Any participant in the
working group process either electronically or in-person as of yesterday
(20th of November). Who has participated in the Working group process
will be anyone that can be identified from:
 - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
   an interim meeting since the WG's creation.
 - posting of at least one email to the RTCWEB mailing list

The voter must at time of voting prove their eligibility, by pointing to
the mail archive or a particular blue sheet/meeting. Please verify your
own eligibility.

3) Start the the voting period. Those eligible and willing to vote send
their ballot to a vote collector (Matt Lepinski, former Nomcom chair)
within two weeks using email. The vote collector will check when
receiving a ballot the that the voter is eligible and send a
confirmation email on receiving the ballot. During the balloting period
the vote collector will keep all ballots secret.

Balloting:
 - The voter MUST rank ALL alternatives in their ballot from the most
   preferred, marked with rank 1, the second most with 2, all the way
   to the least preferred marked with rank N.


4) When the voting period is over the ballot collector will publish the
results as well as all ballots, including the voters name to the RTCWEB
WG mailing list. This enables all voting individuals to verify that
their ballot is unmodified. And allows anyone to verify the result of
the vote.

5) The selection is recorded in the drafts.


--- End of Process Proposal ---

This message initiates the first step in the working group consensus
call process. Namely a one week comment and discussion period for the
above process.

After that week the WG chairs will update, if necessary, the proposal.
Then using the normal IETF process in which anyone is eligible to
participate, the chairs will ask for (rough) consensus to adopt this
extraordinary process to achieve the working group's stated goals.  The
end date for this consensus call is 2-weeks after the announcement of
the consensus call.

If the working group does not consent to using this extraordinary
process, we will hold a consensus call if the WG can accept
"WebRTC entities MUST support at least one of H.264 or VP8.".

If there is failure to establish consensus even for this statement, the
chairs conclude that the WG can't establish what to say about a MTI
video codec.

The WG Chairs

Magnus Westerlund
Cullen Jennings
Ted Hardie


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------020707070204000505010902-- From maikmerten@googlemail.com Sat Nov 23 01:20:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A691AE226 for ; Sat, 23 Nov 2013 01:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGRCbvupmYNp for ; Sat, 23 Nov 2013 01:20:48 -0800 (PST) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 358261AE175 for ; Sat, 23 Nov 2013 01:20:47 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id h14so1002254eaj.21 for ; Sat, 23 Nov 2013 01:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=mDb/91kjHgoMsxVBCIt1UOJ0j/ekNr7w3e9ESRQGHtw=; b=wC68OFtEb/9pkOpXKI7OXL7r+/LiDuCfLyA1NktX4y986qXWpocK+7OFU78/kI/cH6 6mINJTRPyNWAAIfnZIqtg0mNV209IUbn0timS0mN4pAcEnA/gVM7pWxM58020pV7tRHi GktIhyXSnJpB1/1UjN7Yw7G6BMsUu5XGAO31nIFHf3GKKHPprX/pIvEcFqtZzl4wrwpJ LVamnLIp6MuNBgHYDqvYgqTUUKGMyjHXRm5UHsA8L8e6DfrJe3OVmrT3T+rdm0rINAqq J4fXhKoSqp95qDsGRnYW8clh68+DunAj4OzUBXdFj/sJI2DfAEUCWFQEc27+LA83G8L+ NzUA== X-Received: by 10.14.149.139 with SMTP id x11mr3213751eej.35.1385198439708; Sat, 23 Nov 2013 01:20:39 -0800 (PST) Received: from [192.168.2.109] (port-92-201-35-71.dynamic.qsc.de. [92.201.35.71]) by mx.google.com with ESMTPSA id o47sm83720623eem.21.2013.11.23.01.20.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 01:20:38 -0800 (PST) Message-ID: <52907363.4090003@googlemail.com> Date: Sat, 23 Nov 2013 10:20:35 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> <528EBAB0.2010906@librevideo.org> <528EBD4C.8070504@librevideo.org> <02B96CE8-A6D9-4288-B052-FB54B07447FB@apple.com> <528FCA68.2070309@googlemail.com> <528FE08B.1020908@nostrum.com> In-Reply-To: <528FE08B.1020908@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 09:20:49 -0000 Am 22.11.2013 23:54, schrieb Adam Roach: > Read the first paragraph of the description. In layman's terms, it says > "even though this patent is being issued in 2008, we claim that it was > invented in January of 1992." And with a priority date prior to 1995, > this means that they have protection for seventeen years from the date > of issuance (i.e., until 2025). As far as I can see the priority date for such filings does matter, too. How would such a patent apply to a set of algorithms described in a ca. 1988 reference implementation? I for sure see how this refiling mechanism could be trouble for MPEG-1 Part 2 and H.263. We won't get a reliable answer on an engineering mailing list and I feel that actual legal resources may need to be employed to get a decent risk-assessment. Maik From duerst@it.aoyama.ac.jp Sat Nov 23 01:37:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C331AE24C for ; Sat, 23 Nov 2013 01:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWhBDycOanbw for ; Sat, 23 Nov 2013 01:37:47 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id C99411AE175 for ; Sat, 23 Nov 2013 01:37:46 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAN9bXqv012639; Sat, 23 Nov 2013 18:37:33 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2091_76a8_e13627f6_5422_11e3_a6e0_001e6722eec2; Sat, 23 Nov 2013 18:37:33 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id B890BBF548; Sat, 23 Nov 2013 18:37:32 +0900 (JST) Message-ID: <5290774A.3050009@it.aoyama.ac.jp> Date: Sat, 23 Nov 2013 18:37:14 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Bernard Aboba References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im> <528E7033.2090502@gmail.com> <528F68CC.40106@usdonovans.com> <8uru89ha1p0cccvq5qr8mtcnl4mvmkelhk@hive.bjoern.hoehrmann.de> <528F7E21.7010803@librevideo.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 09:37:49 -0000 On 2013/11/23 10:44, Bernard Aboba wrote: >> On Nov 22, 2013, at 8:20 AM, "Emil Ivov" said: >> >> If we can't reach consensus then we are in no position to mandate. > > [BA] It strikes me that once we venture beyond consensus and running code into voting, we have left our home behind for someplace else whose principles should at the least be articulated. > > For example, it would be helpful to understand whether we are now endorsing Kings and if so, whether the model is that of a constitutional monarchy, or more along the Absolutist line. Voting and kings don't necessarily go together. There's for example a lot of voting in Switzerland, but no kings. But seriously, I think one consequence of the IETF trying voting in this case might be that in other, potentially less disputed, cases, the people "in the rough" might cling to their position longer and demand voting too. So starting voting may turn out to be a first step onto a slippery slope. Regards, Martin. > we could decide to emulate Louis XIV (a defender of The Divine Right of Kings). > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From lorenzo@meetecho.com Sat Nov 23 03:08:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24921AE29D for ; Sat, 23 Nov 2013 03:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_OvGjE66nRJ for ; Sat, 23 Nov 2013 03:08:27 -0800 (PST) Received: from smtpdb6.aruba.it (smtpdb6.aruba.it [62.149.158.248]) by ietfa.amsl.com (Postfix) with ESMTP id 822391AE299 for ; Sat, 23 Nov 2013 03:08:26 -0800 (PST) Received: from rainpc ([87.6.118.125]) by smtpcmd02.ad.aruba.it with bizsmtp id sz8H1m0072iQqnr01z8HmL; Sat, 23 Nov 2013 12:08:18 +0100 Date: Sat, 23 Nov 2013 12:08:16 +0100 From: Lorenzo Miniero To: Adam Roach Message-ID: <20131123120816.0bc16a75@rainpc> In-Reply-To: <529009A0.5050708@nostrum.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <20131123013935.6690a07a@rainpc> <529009A0.5050708@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 11:08:29 -0000 On Fri, 22 Nov 2013 19:49:20 -0600 Adam Roach wrote: > On 11/22/13 18:39, Lorenzo Miniero wrote: > > as I asked repeatedly on the list (without ever getting an answer), what makes a unit? > > Of course you're not getting an answer from the list. We're not the > right people to answer that question. I think the address you want is > . > > /a If no one has a clue either, then, why make the 100k point in the first place? Because as I said, a different answer can describe a completely different scenario, and have your 100k units potentially consumed by a single app. Lorenzo -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From christer.holmberg@ericsson.com Sat Nov 23 06:09:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7171ADEB5 for ; Sat, 23 Nov 2013 06:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKxggems44o9 for ; Sat, 23 Nov 2013 06:09:26 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BC9B11ADE88 for ; Sat, 23 Nov 2013 06:09:25 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-ab-5290b70d2f68 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 30.33.15980.D07B0925; Sat, 23 Nov 2013 15:09:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Sat, 23 Nov 2013 15:09:16 +0100 From: Christer Holmberg To: Martin Thomson , "Paul Giralt (pgiralt)" Thread-Topic: [rtcweb] Offer/answer for heterogeneous encode/decode Thread-Index: AQHO59zCEI0MVwit1k+uXBoi6v2abpox30IAgAAD1ACAAAwTgIAA5cSigAAGiS0= Date: Sat, 23 Nov 2013 14:09:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C552FCE@ESESSMB209.ericsson.se> References: <59A91D84-3D29-47C4-8688-CB60844B15D3@cisco.com> <24B2A6DE-958C-445C-BE77-8BD1661DC33D@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C552FCEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvrS7v9glBBkt6BSyunfnHaHGz4TGj xdp/7ewOzB5Tfm9k9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4MlY+uMJesNShYta2h2wN jBtNuhg5OSQETCQONL1lhrDFJC7cW88GYgsJHGKUONzn08XIBWQvZpT437aHpYuRg4NNwEKi +582SI2IQIzE0gO7mEBsZgF1iTuLz7GD2MICThLTWr8wQ9Q4Syz7vIwFwvaTmNk5hR1kDIuA qsStfcUgYV4BX4l3hy4wQqw6xCSx+fctsHpOgUCJFzu3gd3DCHTb91NroHaJS9x6Mp8J4mYB iSV7zkPdLyrx8vE/VpD5EgJKEtO2pkGU50v0npvNCLFLUOLkzCcsExhFZyGZNAtJ2SwkZRBx PYkbU6ewQdjaEssWvmaGsHUlZvw7BFVjLXFj404mZDULGDlWMbLnJmbmpJebb2IExt7BLb8N djBuui92iFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYysn/8J/I64d6ZD YLOSecfNA5x+352+WIVIfrBdtt7HYnZz0Bvdr027Z36d9e50RmH8h2NzX4v0qrv5GrGqnug5 zhH+VyPO6+I8tfZUjTu153dYbLpn+FPW6ovv5KlzxX6WBHee/HD2/UyFFVnGV7MN1gt4MthI pqtMWrbQ+DLHrP+MTL+Nt69XYinOSDTUYi4qTgQATEM7oIsCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 14:09:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C552FCEESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Like some others, I think the must-decode-both-must-endcode-one alternative= as such sounds interesting (whether it has any impact on the licence/IPR i= ssues I'll leave to others to speak for). However, I have big concerns over the proposal to indicate sendrecv for a c= odec even if an entity is only able to receive/decode it. As Justin said, for the "base case" we could probably make it work, as we w= ould know than an rtcweb endpoint must be able to send/encode one of the co= decs. But, what when we add more codecs? Assume Alice sends an offer with H264, V= P8 and the new fancy codec X. Bob supports codec X, but he has no clue whet= her Alice can actually encode it. So, in addition to X Bob will also have t= o include, and reservce resources for, H264 and VP8 in the answer - just i= n case. And, when Alice receives the answer, she can not send a new offer a= nd remove H264 and VP8, because she doesn't know whether Bob can encode X. = It will not be possible to negotiate down to a single common codec X - even= if both Alice and Bob are able to both encode and decode X. ...and, a legacy answerer which supports X may include only X in the answer= , which means Alice has to send a new Offer, without X, in case she can onl= y decode it. Also, in case there is a gateway/transcoder, even if both endpoints indicat= e support of the same codec(s), it may still have to insert a transcoder, j= ust in case - as it doesn't know which codecs the endpoints are able to enc= ode. So, I would STRONLGY RECOMMEND AGAINST allowing to indicate sendrecv for de= code-only codecs. I think it would backfire very soon. Usage of unidirectional, sendonly/recvonly, m- line would of course solve t= his, and you might know that it is one option we are discussing in CLUE (fo= r other reasons than MTI codec, though). Another alternative is to perform some kind of capability exchange before t= he actual offer is sent. But, that would of course increase the number of m= essages etc. Regards, Christer ________________________________ From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Martin Thomson [martin.= thomson@gmail.com] Sent: Saturday, 23 November 2013 3:03 AM To: Paul Giralt (pgiralt) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode On 22 November 2013 16:20, Paul Giralt (pgiralt) wrote: > I gave this as an example of a possible way to do it, but that means you = need two separate m=3D lines - one for send and one for receive. Seems stra= nge to do this for something that you really want to be a single bi-directi= onal stream The bidirectional thing in O/A is the strange way to do things. Two lines is pretty intuitive. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1C552FCEESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <8DBB692158AF0049BC946C89E3EB8A4E@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

Like some others, I think the must-decode-both-must-endcode-one alt= ernative as such sounds interesting (whether it has any impact on the licen= ce/IPR issues I'll leave to others to speak for).

 

However, I have big concerns over the proposal to indicate sendrecv for = a codec even if an entity is only able to receive/decode it.

 

As Justin said, for the "base case" we could probably make it = work, as we would know than an rtcweb endpoint must be able to send/encode = one of the codecs.

 

But, what when we add more codecs? Assume Alice sends an offer with H264= , VP8 and the new fancy codec X. Bob supports codec X, but he has no clue w= hether Alice can actually encode it. So, in addition to X Bob will also hav= e to include, and reservce resources for,  H264 and VP8 in the answer - just in case. And, when = Alice receives the answer, she can not send a new offer and remove H264 and= VP8, because she doesn't know whether Bob can encode X. It will not b= e possible to negotiate down to a single common codec X - even if both Alice and Bob are able to both encode and decode X.

 

...and, a legacy answerer which supports X may include only X = in the answer, which means Alice has to send a new Offer, without X, in cas= e she can only decode it.

 

Also, in case there is a gateway/transcoder, even if both endpoints indi= cate support of the same codec(s), it may still have to insert a trans= coder, just in case - as it doesn't know which codecs the endpoints are abl= e to encode.

 

So, I would STRONLGY RECOMMEND AGAINST allowing to indica= te sendrecv for decode-only codecs. I think it would backfire very soon.

 

Usage of unidirectional, sendonly/recvonly, m- line would of course solv= e this, and you might know that it is one option we are discussing in CLUE = (for other reasons than MTI codec, though).

 

Another alternative is to perform some kind of capability exchange befor= e the actual offer is sent. But, that would of course increase the num= ber of messages etc.

 

Regards,

 

Christer

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Martin Thoms= on [martin.thomson@gmail.com]
Sent: Saturday, 23 November 2013 3:03 AM
To: Paul Giralt (pgiralt)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode
On 22 November 2013 16:20, Paul Giralt (pgiralt) &= lt;pgiralt@cisco.com> wrote:
> I gave this as an example of a possible way to do it, but that means y= ou need two separate m=3D lines - one for send and one for receive. Seems s= trange to do this for something that you really want to be a single bi-dire= ctional stream

The bidirectional thing in O/A is the strange way to do things.  Two lines is pretty intuitive.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--_000_7594FB04B1934943A5C02806D1A2204B1C552FCEESESSMB209erics_-- From emil@sip-communicator.org Sat Nov 23 06:40:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4961AE136 for ; Sat, 23 Nov 2013 06:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JOGs70_D4UN for ; Sat, 23 Nov 2013 06:40:57 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF1D1AE0A3 for ; Sat, 23 Nov 2013 06:40:57 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id ca18so1902831wib.10 for ; Sat, 23 Nov 2013 06:40:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=widwuLhwnz/qhmzfX1lif0JxcHbTtoclnUen5jzJT2E=; b=G7Rvx+bE6+nvr/CfYcSkVDAgLgtKKvd29PcAHZJa9tbQNloF5NKo/tQjvYNF3hbDpZ OLgo3jtgD3CQ5gsXeSAZJHbMxL7Fw805mm810Bcvdf62WvDPOhzIrOdW1UM57qLJtcZG H6Ql3qGPXmMSsVca/xeMjhTofG/WoMYCv6s2Ye37wpaiXxPZQ+6Az18sMEQjsopf+tkF ugc1jiTaxvJtoKsmza4itk5HkfnZAMNOcxqorAL4O4qCboRVgiOJ7Ok3vU3WhjAcJpfd AFGChBjkiGWUp2eedDiLJAcz5fmZpmVyyCHoWk8/5iItHWiro57p0jlD1Tj1amYn2vpI 1y+Q== X-Gm-Message-State: ALoCoQkDtTr9Rf+M12WWTEnyEqP7tb0LGIzmxppzrN33elzb/8Z1Cj0YT6aC0LH9agNBdHy3ATIz X-Received: by 10.180.198.109 with SMTP id jb13mr6838560wic.55.1385217649659; Sat, 23 Nov 2013 06:40:49 -0800 (PST) Received: from camionet.local ([2a01:e35:8a04:14f0:313a:136a:ba2:be0a]) by mx.google.com with ESMTPSA id fu1sm26661089wib.8.2013.11.23.06.40.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 06:40:48 -0800 (PST) Message-ID: <5290BE6E.9030304@jitsi.org> Date: Sat, 23 Nov 2013 15:40:46 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cowwoc References: <528E39F4.4010706@ericsson.com> <52906876.4000509@bbs.darktech.org> In-Reply-To: <52906876.4000509@bbs.darktech.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 14:41:00 -0000 On 23.11.13, 09:33, cowwoc wrote: > # People objecting to the very idea of voting (versus making the decision > on a technical merit) miss the fact that this is no longer a technical > debate. > > * We have already agreed that both VP8 and H.264 are technically "good > enough". The only remaining differences are of a political and > licensing in nature. Indeed they are and the IETF is not an organisation that can resolve political and licensing issues *through voting*. Imagine you have disease A and you consult a doctor. You get all necessary examinations then a week later you go back and she says: "I can't tell you what the best cure for you is. There is no consensus on the subject. There were two candidates that could do the job but one requires killing a 1000 puppies and one little piggy to produce a single pill while the other one hasn't passed FDA approval yet and it might just end up killing you" "That said," she goes on, "we took a vote with my beer buddies and every one who had ever sent me a mail containing the words 'disease A'. That vote said you MUST take the puppy/piggy slaughtering pill." "I MUST?," you say barely believing. "Yup," she confirms, "You MUST! Otherwise you are not getting reimbursed for your medical expenses and your medical insurance contract is being annulled." ... This has nothing to do with exactly how important an MTI is. It's about what the IETF can and cannot do. If we can reach consensus on a solution (e.g. some combination of MTI encoders/decoders) then great. Otherwise someone else will have to do the choice. It could be the W3C It could be some WebRTC Alliance/Forum. That decision can just as easily be referenced in RFP requirements. Emil -- https://jitsi.org From ekr@rtfm.com Sat Nov 23 07:00:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4901ADF59 for ; Sat, 23 Nov 2013 07:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5vtkEzqhwEu for ; Sat, 23 Nov 2013 07:00:03 -0800 (PST) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4D41ADF10 for ; Sat, 23 Nov 2013 07:00:02 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id q58so2224709wes.19 for ; Sat, 23 Nov 2013 06:59:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rbXVI5SWTg3FZ+QOZtnFQPk7OLjTmBGYbDSZbeCgyCA=; b=AFjgPrUP27r1SDMM+7TxbrhAonSvpAXIjBrYUHWiIC5HQtg23rKkaAuXOPpTo5o9Po SJblEEp27dbQCcfXG17KNAs776D9iu1jFyQdq0IUKbs+WI7KxpEurQLLVRNPjpmk/Top +LxJ6yD6Clp+6UoKTxSj0+ezMhx/UAW3Ojw6ojFKa+tNimWdGWryxawPUExUUeo3omm6 WWaJ117raDgwEbwNW04ICKOL4I1thCCyunnUp41scU+94CdbdnpAxAe/9gIV79wbEQT6 8f7Tclc9xsSVmX95SUMYKEJiHzv2NQOuLzHMatK3vwB9jeTzP3Sww6bl9PmEJ8sRsHtl GiUw== X-Gm-Message-State: ALoCoQlOi4aZX9EnmdA82n3jAKiOG+sBIklWfJzGAjinAW93F8vVJXpS/nUu+hOS//gLmsr50xK+ X-Received: by 10.180.24.137 with SMTP id u9mr7037739wif.5.1385218795104; Sat, 23 Nov 2013 06:59:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Sat, 23 Nov 2013 06:59:14 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: <52905257.1060209@bbs.darktech.org> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E671A@ausmsex00.austin.kmvtechnologies.com> <528FC513.4020903@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E6731@ausmsex00.austin.kmvtechnologies.com> <52905257.1060209@bbs.darktech.org> From: Eric Rescorla Date: Sat, 23 Nov 2013 06:59:14 -0800 Message-ID: To: cowwoc Content-Type: multipart/alternative; boundary=f46d04447f673801b004ebd9620d Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Opinions are fine, bypassing a vote is not (was: H.261) X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 15:00:06 -0000 --f46d04447f673801b004ebd9620d Content-Type: text/plain; charset=ISO-8859-1 Gili, I would like to push back on this a bit. Say that we had general consensus that Theora was strictly better than H.261. I think it would be OK to remove H.261. Obviously, if there's any significant dissent, we shouldn't, but I'm already pretty sad about all the options, and I don't think it's bad to winnow the field if there is near-unanimity on something.... -Ekr On Fri, Nov 22, 2013 at 10:59 PM, cowwoc wrote: > > This post is not meant to target Stefan specifically. It is a general > statement based on what I've noticed over the past 200+ posts on this topic. > > I am ... concerned ... by the apparently attempt by certain individuals to > have options removed ahead of a possible vote. It is one thing to explain > your opinion in order to encourage/discourage people from voting for it. It > is another matter to imply that an option is a "waste of time" because only > a "vocal minority" seems to care about it or that "given the choice between > what you are proposing and X, most developers would prefer X". If no one is > in favor of H.261 "except for a vocal minority" or "most developers would > prefer X" then you have nothing to worry about. Let the community vote and > see where the chips land. I don't think it's safe to rely on "vocal > minorities" to gauge what the community at large prefers. The only way to > find out is to ask them (and that's what the vote is all about). > > Everyone should be free to express their opinion for/against an option, > but no option should be removed ahead of a vote. > > Just my 2 cents. > > Gili > > On 22/11/2013 4:14 PM, Stefan Slivinski wrote: > >> Why don't we add the "must support both H.264 and VP8 decode and must >> support at least one of H.264 or VP8 encode" to the list of options and ask >> for a show of hands as to what people are in favor of. This would be >> non-binding, simply a status check. Maybe no one is in favor of H.261 >> except for a vocal minority in which case we're wasting time arguing about >> it. >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Basil Mohamed >> Gohar >> Sent: Friday, November 22, 2013 12:57 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] H.261 >> >> On 11/22/2013 03:44 PM, Stefan Slivinski wrote: >> >>> Thank you for the link. >>> >>> The point I'm trying to make is H.261 will harm the proliferation of >>> webrtc far more than it will help. This is purely a technical argument >>> speaking to quality and error resiliency. >>> >>> Has anyone listed the concerns surrounding H.264 and have these been >>> raised with mpeg-la to see if they can make adjustments to the license >>> agreement. They have certainly done so in the past. >>> >> Believe it or not, the MPEG-LA is currently trying to establish a >> royalty-free subset of H.264 called "Constrained Baseline Profile", which >> is very similar to the most commonly-used subset of H.264 features out >> there. >> >> The problem is, it's not done yet, and there's no indication whether or >> not it will be successful or not. This would require all existing >> stakeholders in H.264 licensing to agree to this royalty-free variant for >> it to matter. >> >> There's another effort to do the same with one using MPEG-1 as a base. >> >> The problem is, none of these formally exist in royalty-free forms as of >> yet. Everything else we've discussed, though, does, including H.261. >> >> And, for what it's worth, I disagree about H.261. Yes, H.264 and/or VP8 >> (and a whole list of other codecs) will look *better*, but I think being >> able to communicate via video over H.261 is better than not being able to >> all. >> >> And we are at a point where "not at all" is going to happen because the >> WG is effectively split over using VP8 and H.264. >> >> -- >> Libre Video >> http://librevideo.org >> _______________________________________________ >> 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 > --f46d04447f673801b004ebd9620d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Gili,

I would like to push back on this= a bit. Say that we had general consensus
that Theora was strictl= y better than H.261. I think it would be OK to remove
H.261. Obvi= ously, if there's any significant dissent, we shouldn't, but I'= m
already pretty sad about all the options, and I don't think it'= ;s bad to winnow
the field if there is near-unanimity on somethin= g....

-Ekr



On Fri, Nov 22, 2013 at 10:59 PM, cowwoc= <cowwoc@bbs.darktech.org> wrote:

This post is not meant to target Stefan specifically. It is a general state= ment based on what I've noticed over the past 200+ posts on this topic.=

I am ... concerned ... by the apparently attempt by certain individuals to = have options removed ahead of a possible vote. It is one thing to explain y= our opinion in order to encourage/discourage people from voting for it. It = is another matter to imply that an option is a "waste of time" be= cause only a "vocal minority" seems to care about it or that &quo= t;given the choice between what you are proposing and X, most developers wo= uld prefer X". If no one is in favor of H.261 "except for a vocal= minority" or "most developers would prefer X" then you have= nothing to worry about. Let the community vote and see where the chips lan= d. I don't think it's safe to rely on "vocal minorities" = to gauge what the community at large prefers. The only way to find out is t= o ask them (and that's what the vote is all about).

Everyone should be free to express their opinion for/against an option, but= no option should be removed ahead of a vote.

Just my 2 cents.

Gili

On 22/11/2013 4:14 PM, Stefan Slivinski wrote:
Why don't we add the "must support both H.264 and VP8 decode and m= ust support at least one of H.264 or VP8 encode" to the list of option= s and ask for a show of hands as to what people are in favor of. =A0This wo= uld be non-binding, simply a status check. =A0Maybe no one is in favor of H= .261 except for a vocal minority in which case we're wasting time argui= ng about it.

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Basil Mohamed Gohar=
Sent: Friday, November 22, 2013 12:57 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] H.261

On 11/22/2013 03:44 PM, Stefan Slivinski wrote:
Thank you for the link.

The point I'm trying to make is H.261 will harm the proliferation of we= brtc far more than it will help. =A0This is purely a technical argument spe= aking to quality and error resiliency.

Has anyone listed the concerns surrounding H.264 and have these been raised= with mpeg-la to see if they can make adjustments to the license agreement.= =A0They have certainly done so in the past.
Believe it or not, the MPEG-LA is currently trying to establish a royalty-f= ree subset of H.264 called "Constrained Baseline Profile", which = is very similar to the most commonly-used subset of H.264 features out ther= e.

The problem is, it's not done yet, and there's no indication whethe= r or not it will be successful or not. =A0This would require all existing s= takeholders in H.264 licensing to agree to this royalty-free variant for it= to matter.

There's another effort to do the same with one using MPEG-1 as a base.<= br>
The problem is, none of these formally exist in royalty-free forms as of ye= t. =A0Everything else we've discussed, though, does, including H.261.
And, for what it's worth, I disagree about H.261. =A0Yes, H.264 and/or = VP8 (and a whole list of other codecs) will look *better*, but I think bein= g able to communicate via video over H.261 is better than not being able to= all.

And we are at a point where "not at all" is going to happen becau= se the WG is effectively split over using VP8 and H.264.

--
Libre Video
http://librevideo.org
_______________________________________________
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

--f46d04447f673801b004ebd9620d-- From bryandonnovan@gmail.com Sat Nov 23 07:00:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32EC1ADF10 for ; Sat, 23 Nov 2013 07:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwPnhr2sd_sP for ; Sat, 23 Nov 2013 07:00:54 -0800 (PST) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 04E6E1ADEBA for ; Sat, 23 Nov 2013 07:00:53 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id ht10so1713325vcb.29 for ; Sat, 23 Nov 2013 07:00:46 -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=97vAgmupEqi9Myle555W1eT0zcpfq8ceYBljKAShlg4=; b=zzHTzj6mQhxld7k6YFd9Mgl3jOnHxlvskCU4uny2S1i5RmcDU8XNXEWRcOE/IapTP8 8Pjqbhs3RmCpdB66tDInUcrQPg6HPr1gxa0qVxY0UzkwkitQts40OGhsiWvh+OoJgyK7 0aQlAIK9Y5l8NCoidVkdj0m+Shm2CMWvE2Vj+Fs17wcT6soTV8TL4SDB5w82PhwFWfzj QNObX4SP3SK728NblTOGeF6sBm5B9I8u6YFYOD/hFhsCJ/6xgC1xnVFFkQRkc/AIrEac Gs3FWI3LTsA1NShgNCiGZN+9REMvK2QLf8xsq25c2i9Q+q21X4hPGaLLENXkjMSdTkja J06g== MIME-Version: 1.0 X-Received: by 10.220.196.66 with SMTP id ef2mr17212968vcb.7.1385218846214; Sat, 23 Nov 2013 07:00:46 -0800 (PST) Received: by 10.52.231.233 with HTTP; Sat, 23 Nov 2013 07:00:46 -0800 (PST) In-Reply-To: <529057EB.3060704@bbs.darktech.org> References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> <529057EB.3060704@bbs.darktech.org> Date: Sat, 23 Nov 2013 07:00:46 -0800 Message-ID: From: bryandonnovan@gmail.com To: cowwoc Content-Type: multipart/alternative; boundary=001a1132e6e243cded04ebd96564 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 15:00:57 -0000 --001a1132e6e243cded04ebd96564 Content-Type: text/plain; charset=UTF-8 Gili, Large group conferences, classes, seminars, etc., typically have 1 person sending and N persons receiving -- at least where my product is concerned. This is 1:N, not mesh conferencing. My original point, the one that Stefan said he was agreeing with, was to do with the fact that you would always be using the common codec when you have multiple people receiving the same video stream on different browsers, unless you wanted to transcode the video. Granted, this would be 1 transcode for each sending stream, not 1 transcode for each receiver, so the cost is not terrible. On Fri, Nov 22, 2013 at 11:23 PM, cowwoc wrote: > Stefan, > > At the conference, they mentioned that you cannot implement online video > classes (with 20+ participants) unless you reduce the resolution and frame > rate of non-speakering participants. Meaning, even without having to do any > transcoding (they use VP8 across the board) there is insufficient bandwidth > and CPU to handle 20 incoming video streams at HD resolutions. So what you > do is host non-speakers at tiny resolutions and 3 fps. > > H.261 could handle those non-speakers just fine (in fact, it would be > preferable as it reduces CPU usage). Furthermore, if you chose to > transcode, you'd be dealing with tiny resolutions and 3fps. In both cases, > the use of H.261 or transcoding is not the bottleneck. > > Gili > > > On 22/11/2013 8:42 PM, Stefan Slivinski wrote: > >> Just for fun, let's play out the H.261 scenario as the great savior of >> webrtc that some claim it is: >> >> Let's say through some divine miracle we manage to all agree to make >> H.261 the one and only MTI codec. The rationale being of course that no >> one will ever use it because it is of course terrible, but we need it to >> get around those pesky patent/license terms with VP8/H.264 respectively. >> >> Alright fast forward, Chrome adds H.261 but continues to use VP8. IE >> uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, >> H.264 and VP8. So far so good. Chrome can talk using VP8 to Firefox, >> Safari can talk H.264 to IE, Firefox can either H.264 or VP8 to everyone. >> As long as Chrome users don't try to call IE or Safari, we're in good >> shape, otherwise we need to transcode using some undefined cloud based >> transcoder service or just use H.261. >> >> So we're still in good shape. Now let's consider the multiway case. I >> heard a use case at the conference on Tuesday where a university was using >> webrtc to enable video online classes. So let's assume there are 20 people >> in the class. 19 people in the class love Chrome, so they join the class >> from chrome and are all sending each other VP8. But of course there's >> always one person that has to be difficult and they decide they prefer IE. >> So what now? Well the IE person doesn't understand any of the 19 VP8 >> streams and the 19 chrome users don't understand the 1 H.264 stream. So we >> can now utilize that same undefined cloud transcoding service to convert >> each of the 19 VP8 streams to H.264 and the 1 H.264 stream to VP8....or we >> can use H.261. >> >> My guess is H.261 is going to get used a lot more than anyone thinks. >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach >> Sent: Friday, November 22, 2013 5:37 PM >> To: Ron; rtcweb@ietf.org >> Subject: Re: [rtcweb] H.261 >> >> On 11/22/13 18:35, Ron wrote: >> >>> The whole point of many distros is to supply binaries, often built >>> many times for many different system architectures. >>> >> And the overwhelming majority of these do so by including a list of >> repositories from which the binaries can be downloaded. >> >> I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, >> and whatever else is needed for these distros, targeting whatever platforms >> are required. Now, whether we can get the distro maintainers to add a >> single line to their list of repos -- because that's all it would take -- >> is a different issue. But at that point, it's just a matter of the distro >> maintainers being intransigent rather than any real technical or legal >> barrier. >> >> /a >> _______________________________________________ >> 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 > --001a1132e6e243cded04ebd96564 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gili,

Large group conferences, classes,= seminars, etc., typically have 1 person sending and N persons receiving --= at least where my product is concerned. =C2=A0This is 1:N, not mesh confer= encing. =C2=A0My original point, the one that Stefan said he was agreeing w= ith, was to do with the fact that you would always be using the common code= c when you have multiple people receiving the same video stream on differen= t browsers, unless you wanted to transcode the video. =C2=A0Granted, this w= ould be 1 transcode for each sending stream, not 1 transcode for each recei= ver, so the cost is not terrible.


On Fri, Nov 2= 2, 2013 at 11:23 PM, cowwoc <cowwoc@bbs.darktech.org> = wrote:
Stefan,

At the conference, they mentioned that you cannot implement online video cl= asses (with 20+ participants) unless you reduce the resolution and frame ra= te of non-speakering participants. Meaning, even without having to do any t= ranscoding (they use VP8 across the board) there is insufficient bandwidth = and CPU to handle 20 incoming video streams at HD resolutions. So what you = do is host non-speakers at tiny resolutions and 3 fps.

H.261 could handle those non-speakers just fine (in fact, it would be prefe= rable as it reduces CPU usage). Furthermore, if you chose to transcode, you= 'd be dealing with tiny resolutions and 3fps. In both cases, the use of= H.261 or transcoding is not the bottleneck.

Gili


On 22/11/2013 8:42 PM, Stefan Slivinski wrote:
Just for fun, let's play out the H.261 scenario as the great savior of = webrtc that some claim it is:

Let's say through some divine miracle we manage to all agree to make H.= 261 the one and only MTI codec. =C2=A0The rationale being of course that no= one will ever use it because it is of course terrible, but we need it to g= et around those pesky patent/license terms with VP8/H.264 respectively.

Alright fast forward, Chrome adds H.261 but continues to use VP8. =C2=A0IE = uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, H= .264 and VP8. =C2=A0So far so good. =C2=A0Chrome can talk using VP8 to Fire= fox, Safari can talk H.264 to IE, Firefox can either H.264 or VP8 to everyo= ne. =C2=A0As long as Chrome users don't try to call IE or Safari, we= 9;re in good shape, otherwise we need to transcode using some undefined clo= ud based transcoder service or just use H.261.

So we're still in good shape. =C2=A0Now let's consider the multiway= case. =C2=A0I heard a use case at the conference on Tuesday where a univer= sity was using webrtc to enable video online classes. =C2=A0So let's as= sume there are 20 people in the class. =C2=A019 people in the class love Ch= rome, so they join the class from chrome and are all sending each other VP8= . =C2=A0But of course there's always one person that has to be difficul= t and they decide they prefer IE. =C2=A0So what now? =C2=A0 Well the IE per= son doesn't understand any of the 19 VP8 streams and the 19 chrome user= s don't understand the 1 H.264 stream. =C2=A0So we can now utilize that= same undefined cloud transcoding service to convert each of the 19 VP8 str= eams to H.264 and the 1 H.264 stream to VP8....or we can use H.261.

My guess is H.261 is going to get used a lot more than anyone thinks.

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Friday, November 22, 2013 5:37 PM
To: Ron; rtcweb@ietf.o= rg
Subject: Re: [rtcweb] H.261

On 11/22/13 18:35, Ron wrote:
The whole point of many distros is to supply binaries, often built
many times for many different system architectures.
And the overwhelming majority of these do so by including a list of reposit= ories from which the binaries can be downloaded.

I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs= , and whatever else is needed for these distros, targeting whatever platfor= ms are required. Now, whether we can get the distro maintainers to add a si= ngle line to their list of repos -- because that's all it would take --= is a different issue. But at that point, it's just a matter of the dis= tro maintainers being intransigent rather than any real technical or legal = barrier.

/a
_______________________________________________
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

--001a1132e6e243cded04ebd96564-- From ekr@rtfm.com Sat Nov 23 07:01:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20B71AE13C for ; Sat, 23 Nov 2013 07:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM0lBywtmNOd for ; Sat, 23 Nov 2013 07:01:08 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 155F21AE139 for ; Sat, 23 Nov 2013 07:01:07 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so2209532wes.24 for ; Sat, 23 Nov 2013 07:01:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UC5+zgc4tACZMy6Un0QBIRSAFyHEDFDgrnHIoiMORTA=; b=ZFndGqVKbPDuOyR8YqUZTYbzqdXhjtO1rm9yVWDe/3/0nuP+oQP5vpaxpIOfP17Dfg RA6+VRuG1O54B4VROa45SjH4Ylji6bhtS5u1RkvTVAyOnLdkp1cg9wWCsbg5jT3lyhqv C6osc8IHVPTjRp0cKunvXEtMDTzU8OR+Mc3QvMr2jJYN9u8M3oVZCE+8F66cGIUlfw49 HWK5dC9dhqewVU0QT0sI2wmBb3sv/t4iN/+izVWUqCBCl6QjkrMCxFiCqmiqliqFbfFD O79Gwsu4MBAQ1djPdLPOvuFMHUB8NRf28TsUbFfZBvdi67/aGsxXiA+AsjtU6kPa0L/y M06A== X-Gm-Message-State: ALoCoQlnjpX8jWWY97QNQ6ugGndO0M7BsamKNxxNiSPgAK8cB/ZkVa16oYdSss7rRZHHnhViXjMd X-Received: by 10.194.93.3 with SMTP id cq3mr15196635wjb.26.1385218860229; Sat, 23 Nov 2013 07:01:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Sat, 23 Nov 2013 07:00:20 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: <52905990.8070207@bbs.darktech.org> References: <52891EDB.2050607@googlemail.com> <528B2ABE.4040701@googlemail.com> <528C79AD.10608@googlemail.com> <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com> <528E5E89.8040706@googlemail.com> <52905990.8070207@bbs.darktech.org> From: Eric Rescorla Date: Sat, 23 Nov 2013 07:00:20 -0800 Message-ID: To: cowwoc Content-Type: multipart/alternative; boundary=047d7bb0482219bb0504ebd96625 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 CBP (was: Video codec selection - way forward) X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 15:01:11 -0000 --047d7bb0482219bb0504ebd96625 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It was CBP. I think there's some debate about the relative performance characteristics, with general agreement that H.264 CBP and VP8 are in the same neighborhood and also general agreement that performance is not the important factor. -Ekr On Fri, Nov 22, 2013 at 11:30 PM, cowwoc wrote: > > +1 > > In the original VP8 vs H.264 discussion, what H.264 profile was under > discussion? > > If it was not H.264 CBP, do we need to revisit the comparison? Do the two > profiles use the same bandwidth, CPU and produce the same quality? > > Thanks, > Gili > > On 21/11/2013 2:27 PM, Maik Merten wrote: > >> Btw, should any occurrence of "H.264" in the current list of options be >> substituted with "H.264 CBP"? Perhaps it is best to be very clear on the >> profile which should be implemented. >> >> Thanks, >> >> Maik >> >> Am 21.11.2013 20:20, schrieb David Singer: >> >>> Chairs >>> >>> can we add this as an option to the formal list, so we get formal >>> feedback on its acceptability, please? >>> >>> =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94 >>> >>> >>> I think this may be the best (maybe only) way to tease out how much ris= k >>> people perceive. >>> >>> Many thanks >>> >>> On Nov 21, 2013, at 9:22 , Maik Merten >>> wrote: >>> >>> Cleary H.263 is preferable from an engineering standpoint (as is, e.g.= , >>>> MPEG-1 Part 2): better performance, more deployments. The central ques= tion >>>> is, however, if those can actually be implemented without some sort of >>>> licensing. >>>> >>>> If they can: Aweseome! However, this may not be determinable without a >>>> review by people who are knowledgeable in the field of IPR, i.e., "act= ual >>>> lawyers". I understand that H.263 is not yet old enough to automatical= ly be >>>> considered "safe" (and neither is MPEG-1 Part 2, although it is closer= ). >>>> >>>> Best regards, >>>> >>>> Maik >>>> >>>> Am 20.11.2013 20:42, schrieb David Singer: >>>> >>>>> I think we should think hard about H.263 instead of H.261 as the thir= d >>>>> fallback. Why? >>>>> >>>>> http://www.itu.int/rec/T-REC-H.263/ >>>>> >>>>> >>>>> >>>>> H.263 was first published in March 1996, so it's 17 years old. The >>>>> restrictions (e.g. on picture size) are no WORSE than H.261. Yes, mo= re >>>>> recent amendments deal with this (and a plethora of other issues), so= we=92d >>>>> need to settle on which of those are mandatory (the usual profiling >>>>> discussion). >>>>> >>>>> There are 34 records in the patent database against H.261, mostly fro= m >>>>> 1989 but one as recent as 2005 (though that is a re-file). That's 2.= 2 >>>>> (reciprocity), as was one other I checked. >>>>> >>>>> Rather surprisingly, there are only 31 against H.263! The most recen= t >>>>> is 2011, and is also option 2. Most are 1997-2001. >>>>> >>>>> >>>>> On this quick glance, H.263 appears no worse than H.261. IANAL (as I >>>>> am sure you have all noticed). >>>>> >>>>> >>>>> H.263 is much more widely supported and mandated. It has been >>>>> mandated in the 3GPP specs for years (for lots of services, including >>>>> videoconf), and is effectively the fallback codec today in the indust= ry, as >>>>> I understand. It was ubiquitous in video telephony for years, and I >>>>> suspect many of those systems still ship it. >>>>> >>>>> So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 wo= rk? >>>>> >>>>> (I am asking the question, not even answering on behalf of my company= , >>>>> yet. Let=92s get the issues on the table.) >>>>> >>>>> >>>>> David Singer >>>>> Multimedia and Software Standards, Apple Inc. >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> David Singer >>> Multimedia and Software Standards, Apple Inc. >>> >>> _______________________________________________ >>> 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 > --047d7bb0482219bb0504ebd96625 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
It was CBP.

I think there's some de= bate about the relative performance characteristics, with
general= agreement that H.264 CBP and VP8 are in the same neighborhood
an= d also general agreement that performance is not the important factor.

-Ekr



On Fri, Nov 22, 2013 at 11:30 PM, cow= woc <cowwoc@bbs.darktech.org> wrote:

+1

In the original VP8 vs H.264 discussion, what H.264 profile was under discu= ssion?

If it was not H.264 CBP, do we need to revisit the comparison? Do the two p= rofiles use the same bandwidth, CPU and produce the same quality?

Thanks,
Gili

On 21/11/2013 2:27 PM, Maik Merten wrote:
Btw, should any occurrence of "H.264" in the current list of opti= ons be substituted with "H.264 CBP"? Perhaps it is best to be ver= y clear on the profile which should be implemented.

Thanks,

Maik

Am 21.11.2013 20:20, schrieb David Singer:
Chairs

can we add this as an option to the formal list, so we get formal feedback = on its acceptability, please?

=93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94


I think this may be the best (maybe only) way to tease out how much risk pe= ople perceive.

Many thanks

On Nov 21, 2013, at 9:22 , Maik Merten <maikmerten@googlemail.com> wrote:

Cleary H.263 is preferable from an engineering standpoint (as is, e.g., MPE= G-1 Part 2): better performance, more deployments. The central question is,= however, if those can actually be implemented without some sort of licensi= ng.

If they can: Aweseome! However, this may not be determinable without a revi= ew by people who are knowledgeable in the field of IPR, i.e., "actual = lawyers". I understand that H.263 is not yet old enough to automatical= ly be considered "safe" (and neither is MPEG-1 Part 2, although i= t is closer).

Best regards,

Maik

Am 20.11.2013 20:42, schrieb David Singer:
I think we should think hard about H.263 instead of H.261 as the third fall= back. =A0Why?

http://ww= w.itu.int/rec/T-REC-H.263/



H.263 was first published in March 1996, so it's 17 years old. =A0The r= estrictions (e.g. on picture size) are no WORSE than H.261. =A0Yes, more re= cent amendments deal with this (and a plethora of other issues), so we=92d = need to settle on which of those are mandatory (the usual profiling discuss= ion).

There are 34 records in the patent database against H.261, mostly from 1989= but one as recent as 2005 (though that is a re-file). =A0That's 2.2 (r= eciprocity), as was one other I checked.

Rather surprisingly, there are only 31 against H.263! =A0The most recent is= 2011, and is also option 2. =A0Most are 1997-2001.


On this quick glance, H.263 appears no worse than H.261. IANAL (as I am sur= e you have all noticed).


H.263 is much more widely supported and mandated. =A0It has been mandated i= n the 3GPP specs for years (for lots of services, including videoconf), and= is effectively the fallback codec today in the industry, as I understand. = =A0It was ubiquitous in video telephony for years, and I suspect many of th= ose systems still ship it.

So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 work?
(I am asking the question, not even answering on behalf of my company, yet.= =A0Let=92s get the issues on the table.)


David Singer
Multimedia and Software Standards, Apple Inc.

_______________________________________________
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

David Singer
Multimedia and Software Standards, Apple Inc.

_______________________________________________
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

--047d7bb0482219bb0504ebd96625-- From marc@mocet.com Sat Nov 23 08:49:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7991AE02E for ; Sat, 23 Nov 2013 08:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qyp3NlGML0X for ; Sat, 23 Nov 2013 08:49:51 -0800 (PST) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id C2FCA1ADF90 for ; Sat, 23 Nov 2013 08:49:50 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id un15so2928982pbc.41 for ; Sat, 23 Nov 2013 08:49:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=OR1icsFgf/lkAtaC5RkMkjRGO5JN36VNVSHy4ST2qmM=; b=LMX2BtzBVSOTAKC79gAH9hgtKPjsh8T3Fd47hd0UNHhfLCLq3BG1x13jYIBlA73cTK M6o/x3rrxCPIOIJGMM8kyXEOP831TLjDicDDCNmLB7wSV6lUHYtb2wnhFT3Ja1sIsNMd Yzsu067wEI3g6sl3Av+EjczOKeRmEYCFCL0EcjF8V6c16WITi45qyHSn8kk5N7zxh0kz Rn9HCRdaCTBfjqo9ZclxRHgQDk7VHpP1uDcu4Ji/q2ozrVJihHCzlTjKkWhXwvtSzW4M pZD1TAX9quv3ywAJcffwBSWyzubRcibxxmnHlBgFhYBrNskgAf80ht5tmfgZpPR4W676 L15w== X-Gm-Message-State: ALoCoQlTLNUt8Ndoy0m3EVDD80kSp1pcjVzUa1wI9GotPovnNaATjA0iJ+7mKJe2fafPhXAHG+pf X-Received: by 10.66.231.42 with SMTP id td10mr1992728pac.144.1385225383168; Sat, 23 Nov 2013 08:49:43 -0800 (PST) Received: from [10.0.1.20] (cpe-76-90-18-6.socal.res.rr.com. [76.90.18.6]) by mx.google.com with ESMTPSA id m2sm61251805pbn.19.2013.11.23.08.49.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 08:49:42 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DE3ADCC7-F82E-4D51-95BA-43FC664D131A" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Marc Abrams In-Reply-To: <52906876.4000509@bbs.darktech.org> Date: Sat, 23 Nov 2013 08:50:43 -0800 Message-Id: <32E15D8E-642B-40B9-BBA3-9D5353B4E969@mocet.com> References: <528E39F4.4010706@ericsson.com> <52906876.4000509@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1827) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 16:49:54 -0000 --Apple-Mail=_DE3ADCC7-F82E-4D51-95BA-43FC664D131A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Really great points about non-browsers and native APIs.=20 As much as we want to live in our browsers, native app support on mobile = devices are the best way to distribute, monetize and enable app = discovery for marketing and sales. If we truly want to encourage mass = adoption of WebRTC technologies, this has to be a priority.=20 As to native APIs, it would be much better for non-browser development = and support to not have to reinvent the wheel in likely slightly = incompatible versions of homegrown APIs. A native API would minimize = interoperability problems and accelerate adoption as well. marc ________________ Marc Abrams +1-949-873-0501 marc@mocet.com On Nov 23, 2013, at 12:33 AM, cowwoc wrote: > Hi, >=20 > Here is a condensed response to the past 200+ posts :) > Instant run-off voting > I don't think that voting will solve all of the problems mentioned = below, but if all other options fail (which we're close to) then I'm in = favor of going ahead with the proposed process. > Whatever process we agree to should end with a binding decision at the = end (as opposed to more endless debate). > People objecting to the very idea of voting (versus making the = decision on a technical merit) miss the fact that this is no longer a = technical debate. > We have already agreed that both VP8 and H.264 are technically "good = enough". The only remaining differences are of a political and licensing = in nature. > Voting will not solve (legitimate) licensing/IPR issues > For example, mandating H.264 as MTI won't help Debian because they = cannot count license units. > We should brainstorm on how to remove these show-stoppers for all = stakeholders (browsers, non-browsers, FOSS, Commercial). The "MUST = implement 2 out of 3" approach is an example of how this can be done. > Who should participate > Either we should include anyone who posted on WebRTC mailing lists = (rtcweb, public-webrtc, public-media-capture) or we should be try to be = more inclusive by including anyone who merely subscribed to said lists. > As was suggested, publishing the full list of all voters along with = their votes should remove any doubt of fraud. If we notice that 5000 = voters came from the same company, we can legitimately question whether = they are all active or whether they attempted to stuff the ballot. > Removing voting options > I think it is vital that we leave all options on the table (however = silly some might think they are) and see where the chips drop. > I understand that some people object to a long list of options, but = I'd rather err on the side of inclusivity than censorship. :) > Non-browsers are equally important > Most of the debate on this mailing list have centered around what the = browsers will do, but if you've attended the WebRTC World conference = over the past couple of years you will have noticed that a great number = of demos are based on native applications (even more so as mobile = adoption increases). There is a very strong interest in using WebRTC = outside of the browser and any decision we make here should reflect that = reality. > Endless debates aren't free > One thing that was evident at the conference is that many of companies = are "moving beyond the specification". > The longer we debate these issues, the more likely we are to end up = with a specification that simply documents the de-facto standard laid = out by early adopters. > We need a higher-level Native API that mirrors the Javascript API > It's become evident that many companies in the conference are = re-inventing the same wheel: namely, they are reimplementing features = found in the Javascript API on top of the Native API. > Imagine how many developer years could be saved if the Native API = provided some of these higher-level constructs. This ties into my = earlier point that "non-browsers are equally important" to take into = consideration. > Thank you for the interesting conversation. It was nice meeting = many of you at the conference! :) > Gili > On 21/11/2013 8:51 AM, Magnus Westerlund wrote: >> WG, >>=20 >> The WebRTC ecosystem needs to avoid interoperability failure to grow >> optimally. The RTCWEB working group took on the task of establish = Audio >> and Video MTI codecs as part of meeting that need. We have not = succeeded >> in finishing that task for video using normal IETF process, but it is >> still important. >>=20 >> We (WG chairs) are proposing that the working group consent to a = method >> that will establish an MTI, even if the MTI chosen does not have = rough >> consensus. We would far prefer the normal IETF process, but it is = not >> proving workable for this selection. >>=20 >> We initially proposed a method from RFC 3929 (external review team), = but >> now believe that the working group would not consent to that method. >> Instead we are proposing a method that leaves the decision in the = hands >> of the WG. >>=20 >> The method we propose is based on Instant-runoff voting, >> http://en.wikipedia.org/wiki/Instant-runoff_voting, with the >> understanding that the choice will be the winner according to the >> Instant-runoff voting process. >>=20 >> The steps in the proposed process are these (1-5): >>=20 >> 1) Establish a final list of alternatives, based on the WG's input to >> Gonzalo's email on the 13th of November that requires any additions = to >> provided by end of the 27th of November. >>=20 >> 2) Establish those eligible to vote. Any participant in the >> working group process either electronically or in-person as of = yesterday >> (20th of November). Who has participated in the Working group process >> will be anyone that can be identified from: >> - The Blue Sheets for any RTCWEB WG session during an IETF meeting = or >> an interim meeting since the WG's creation. >> - posting of at least one email to the RTCWEB mailing list >>=20 >> The voter must at time of voting prove their eligibility, by pointing = to >> the mail archive or a particular blue sheet/meeting. Please verify = your >> own eligibility. >>=20 >> 3) Start the the voting period. Those eligible and willing to vote = send >> their ballot to a vote collector (Matt Lepinski, former Nomcom chair) >> within two weeks using email. The vote collector will check when >> receiving a ballot the that the voter is eligible and send a >> confirmation email on receiving the ballot. During the balloting = period >> the vote collector will keep all ballots secret. >>=20 >> Balloting: >> - The voter MUST rank ALL alternatives in their ballot from the most >> preferred, marked with rank 1, the second most with 2, all the way >> to the least preferred marked with rank N. >>=20 >>=20 >> 4) When the voting period is over the ballot collector will publish = the >> results as well as all ballots, including the voters name to the = RTCWEB >> WG mailing list. This enables all voting individuals to verify that >> their ballot is unmodified. And allows anyone to verify the result of >> the vote. >>=20 >> 5) The selection is recorded in the drafts. >>=20 >>=20 >> --- End of Process Proposal --- >>=20 >> This message initiates the first step in the working group consensus >> call process. Namely a one week comment and discussion period for the >> above process. >>=20 >> After that week the WG chairs will update, if necessary, the = proposal. >> Then using the normal IETF process in which anyone is eligible to >> participate, the chairs will ask for (rough) consensus to adopt this >> extraordinary process to achieve the working group's stated goals. = The >> end date for this consensus call is 2-weeks after the announcement of >> the consensus call. >>=20 >> If the working group does not consent to using this extraordinary >> process, we will hold a consensus call if the WG can accept >> "WebRTC entities MUST support at least one of H.264 or VP8.". >>=20 >> If there is failure to establish consensus even for this statement, = the >> chairs conclude that the WG can't establish what to say about a MTI >> video codec. >>=20 >> The WG Chairs >>=20 >> Magnus Westerlund >> Cullen Jennings >> Ted Hardie >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_DE3ADCC7-F82E-4D51-95BA-43FC664D131A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Really great points about non-browsers and native APIs. 

As much as we want to live in our browsers, native app support on mobile devices are the best way to distribute, monetize and enable app discovery for marketing and sales. If we truly want to encourage mass adoption of WebRTC technologies, this has to be a priority. 

As to native APIs, it would be much better for non-browser development and support to not have to reinvent the wheel in likely slightly incompatible versions of homegrown APIs. A native API would minimize interoperability problems and accelerate adoption as well.

marc
________________
Marc Abrams
+1-949-873-0501
marc@mocet.com


On Nov 23, 2013, at 12:33 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

Hi,

Here is a condensed response to the past 200+ posts :)
  • Instant run-off voting
    • I don't think that voting will solve all of the problems mentioned below, but if all other options fail (which we're close to) then I'm in favor of going ahead with the proposed process.
    • Whatever process we agree to should end with a binding decision at the end (as opposed to more endless debate).
  • People objecting to the very idea of voting (versus making the decision on a technical merit) miss the fact that this is no longer a technical debate.
    • We have already agreed that both VP8 and H.264 are technically "good enough". The only remaining differences are of a political and licensing in nature.
  • Voting will not solve (legitimate) licensing/IPR issues
    • For example, mandating H.264 as MTI won't help Debian because they cannot count license units.
    • We should brainstorm on how to remove these show-stoppers for all stakeholders (browsers, non-browsers, FOSS, Commercial). The "MUST implement 2 out of 3" approach is an example of how this can be done.
  • Who should participate
    • Either we should include anyone who posted on WebRTC mailing lists (rtcweb, public-webrtc, public-media-capture) or we should be try to be more inclusive by including anyone who merely subscribed to said lists.
    • As was suggested, publishing the full list of all voters along with their votes should remove any doubt of fraud. If we notice that 5000 voters came from the same company, we can legitimately question whether they are all active or whether they attempted to stuff the ballot.
  • Removing voting options
    • I think it is vital that we leave all options on the table (however silly some might think they are) and see where the chips drop.
    • I understand that some people object to a long list of options, but I'd rather err on the side of inclusivity than censorship. :)
  • Non-browsers are equally important
    • Most of the debate on this mailing list have centered around what the browsers will do, but if you've attended the WebRTC World conference over the past couple of years you will have noticed that a great number of demos are based on native applications (even more so as mobile adoption increases). There is a very strong interest in using WebRTC outside of the browser and any decision we make here should reflect that reality.
  • Endless debates aren't free
    • One thing that was evident at the conference is that many of companies are "moving beyond the specification".
    • The longer we debate these issues, the more likely we are to end up with a specification that simply documents the de-facto standard laid out by early adopters.
  • We need a higher-level Native API that mirrors the Javascript API
    • It's become evident that many companies in the conference are re-inventing the same wheel: namely, they are reimplementing features found in the Javascript API on top of the Native API.
    • Imagine how many developer years could be saved if the Native API provided some of these higher-level constructs. This ties into my earlier point that "non-browsers are equally important" to take into consideration.

    Thank you for the interesting conversation. It was nice meeting many of you at the conference! :)

Gili

On 21/11/2013 8:51 AM, Magnus Westerlund wrote:
WG,

The WebRTC ecosystem needs to avoid interoperability failure to grow
optimally.  The RTCWEB working group took on the task of establish Audio
and Video MTI codecs as part of meeting that need. We have not succeeded
in finishing that task for video using normal IETF process, but it is
still important.

We (WG chairs) are proposing that the working group consent to a method
that will establish an MTI, even if the MTI chosen does not have rough
consensus.  We would far prefer the normal IETF process, but it is not
proving workable for this selection.

We initially proposed a method from RFC 3929 (external review team), but
now believe that the working group would not consent to that method.
Instead we are proposing a method that leaves the decision in the hands
of the WG.

The method we propose is based on Instant-runoff voting,
http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
understanding that the choice will be the winner according to the
Instant-runoff voting process.

The steps in the proposed process are these (1-5):

1) Establish a final list of alternatives, based on the WG's input to
Gonzalo's email on the 13th of November that requires any additions to
provided by end of the 27th of November.

2) Establish those eligible to vote.  Any participant in the
working group process either electronically or in-person as of yesterday
(20th of November). Who has participated in the Working group process
will be anyone that can be identified from:
 - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
   an interim meeting since the WG's creation.
 - posting of at least one email to the RTCWEB mailing list

The voter must at time of voting prove their eligibility, by pointing to
the mail archive or a particular blue sheet/meeting. Please verify your
own eligibility.

3) Start the the voting period. Those eligible and willing to vote send
their ballot to a vote collector (Matt Lepinski, former Nomcom chair)
within two weeks using email. The vote collector will check when
receiving a ballot the that the voter is eligible and send a
confirmation email on receiving the ballot. During the balloting period
the vote collector will keep all ballots secret.

Balloting:
 - The voter MUST rank ALL alternatives in their ballot from the most
   preferred, marked with rank 1, the second most with 2, all the way
   to the least preferred marked with rank N.


4) When the voting period is over the ballot collector will publish the
results as well as all ballots, including the voters name to the RTCWEB
WG mailing list. This enables all voting individuals to verify that
their ballot is unmodified. And allows anyone to verify the result of
the vote.

5) The selection is recorded in the drafts.


--- End of Process Proposal ---

This message initiates the first step in the working group consensus
call process. Namely a one week comment and discussion period for the
above process.

After that week the WG chairs will update, if necessary, the proposal.
Then using the normal IETF process in which anyone is eligible to
participate, the chairs will ask for (rough) consensus to adopt this
extraordinary process to achieve the working group's stated goals.  The
end date for this consensus call is 2-weeks after the announcement of
the consensus call.

If the working group does not consent to using this extraordinary
process, we will hold a consensus call if the WG can accept
"WebRTC entities MUST support at least one of H.264 or VP8.".

If there is failure to establish consensus even for this statement, the
chairs conclude that the WG can't establish what to say about a MTI
video codec.

The WG Chairs

Magnus Westerlund
Cullen Jennings
Ted Hardie


_______________________________________________
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

 --Apple-Mail=_DE3ADCC7-F82E-4D51-95BA-43FC664D131A-- From sslivinski@lifesize.com Sat Nov 23 08:58:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060D11AE153 for ; Sat, 23 Nov 2013 08:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJX5kThcow9j for ; Sat, 23 Nov 2013 08:58:41 -0800 (PST) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with SMTP id 14B021ADFA5 for ; Sat, 23 Nov 2013 08:58:41 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKUpDeuM1O8Qputk1hZa5PaEofHEQx71NH@postini.com; Sat, 23 Nov 2013 08:58:34 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Sat, 23 Nov 2013 10:50:04 -0600 From: Stefan Slivinski To: cowwoc , "rtcweb@ietf.org" Date: Sat, 23 Nov 2013 10:50:02 -0600 Thread-Topic: [rtcweb] Opinions are fine, bypassing a vote is not (was: H.261) Thread-Index: Ac7oGcqtVdyBwyEaT0KVJsznvnTYPAAUKJTw Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E6777@ausmsex00.austin.kmvtechnologies.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E671A@ausmsex00.austin.kmvtechnologies.com> <528FC513.4020903@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E6731@ausmsex00.austin.kmvtechnologies.com> <52905257.1060209@bbs.darktech.org> In-Reply-To: <52905257.1060209@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Opinions are fine, bypassing a vote is not (was: H.261) X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 16:58:44 -0000 As an individual with a deep background in video compress and someone who w= orks for a company that builds products across a wide variety of architectu= res that do indeed incorporate H.261, I am in a good position to voice my t= echnical knowledge as it relates to H.261. I have nothing personal against= H.261, it was a great technology when it was ratified and for many years a= fter but it is no longer. I don't think anyone wants H.261, they are simpl= y pushing for it out of frustration about the lack of consensus regarding H= .264/VP8. =20 The reality is the concerns raise over the license terms with H.264 are val= id, some people might be taking things to the extreme but regardless they n= eed to be addressed. There is IMO a lot of FUD floating around here, most = of it is probably unintentional but in any event we need more accurate info= rmation. I have setup a meeting with our patent attorney's to get their pe= rspective on some of the licensing concerns raise as they relate to H.264 i= n the hopes of getting a more accurate analysis. -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc Sent: Friday, November 22, 2013 11:00 PM To: rtcweb@ietf.org Subject: [rtcweb] Opinions are fine, bypassing a vote is not (was: H.261) This post is not meant to target Stefan specifically. It is a general state= ment based on what I've noticed over the past 200+ posts on this topic. I am ... concerned ... by the apparently attempt by certain individuals to = have options removed ahead of a possible vote. It is one thing to explain y= our opinion in order to encourage/discourage people from voting for it. It = is another matter to imply that an option is a "waste of time" because only= a "vocal minority" seems to care about it or that "given the choice betwee= n what you are proposing and X, most developers would prefer X". If no one = is in favor of H.261 "except for a vocal minority" or "most developers woul= d prefer X" then you have nothing to worry about. Let the community vote an= d see where the chips land. I don't think it's safe to rely on "vocal minor= ities" to gauge what the community at large prefers. The only way to find o= ut is to ask them (and that's what the vote is all about). Everyone should be free to express their opinion for/against an option, but= no option should be removed ahead of a vote. Just my 2 cents. Gili On 22/11/2013 4:14 PM, Stefan Slivinski wrote: > Why don't we add the "must support both H.264 and VP8 decode and must sup= port at least one of H.264 or VP8 encode" to the list of options and ask fo= r a show of hands as to what people are in favor of. This would be non-bin= ding, simply a status check. Maybe no one is in favor of H.261 except for = a vocal minority in which case we're wasting time arguing about it. > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Basil=20 > Mohamed Gohar > Sent: Friday, November 22, 2013 12:57 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > On 11/22/2013 03:44 PM, Stefan Slivinski wrote: >> Thank you for the link. >> >> The point I'm trying to make is H.261 will harm the proliferation of web= rtc far more than it will help. This is purely a technical argument speaki= ng to quality and error resiliency. >> >> Has anyone listed the concerns surrounding H.264 and have these been rai= sed with mpeg-la to see if they can make adjustments to the license agreeme= nt. They have certainly done so in the past. > Believe it or not, the MPEG-LA is currently trying to establish a royalty= -free subset of H.264 called "Constrained Baseline Profile", which is very = similar to the most commonly-used subset of H.264 features out there. > > The problem is, it's not done yet, and there's no indication whether or n= ot it will be successful or not. This would require all existing stakehold= ers in H.264 licensing to agree to this royalty-free variant for it to matt= er. > > There's another effort to do the same with one using MPEG-1 as a base. > > The problem is, none of these formally exist in royalty-free forms as of = yet. Everything else we've discussed, though, does, including H.261. > > And, for what it's worth, I disagree about H.261. Yes, H.264 and/or VP8 = (and a whole list of other codecs) will look *better*, but I think being ab= le to communicate via video over H.261 is better than not being able to all= . > > And we are at a point where "not at all" is going to happen because the W= G is effectively split over using VP8 and H.264. > > -- > Libre Video > http://librevideo.org > _______________________________________________ > 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 From ron@debian.org Sat Nov 23 10:49:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665CF1AE20C for ; Sat, 23 Nov 2013 10:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqWrA4V2xp4d for ; Sat, 23 Nov 2013 10:49:46 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE991AE163 for ; Sat, 23 Nov 2013 10:49:45 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail06.adl2.internode.on.net with ESMTP; 24 Nov 2013 05:19:35 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id B37314F8F3 for ; Sun, 24 Nov 2013 05:19:34 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ukycvNUJuZnv for ; Sun, 24 Nov 2013 05:19:34 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 20D9C4F902; Sun, 24 Nov 2013 05:19:34 +1030 (CST) Date: Sun, 24 Nov 2013 05:19:34 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131123184934.GF3245@audi.shelbyville.oz> References: <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 18:49:48 -0000 On Sat, Nov 23, 2013 at 04:45:26AM +0000, Mo Zanaty (mzanaty) wrote: > All major distros including Debian already include x264, ffmpeg, etc. > http://packages.debian.org/wheezy/x264 > > Those packages offer no patent license at all. What is the perceived > unique risk of Cisco¹s H.264? It attempts to license the patents legally > instead of leaving users bare naked. If the FOSS community sees this as > worse than the current situation, and feels its users are better off > naked, it would be good to understand why. That's not a package which I maintain, or have had anything to do with, so if you're looking for an explanation of what the people who do might be thinking, then I'll have to disappoint you, sorry. [1] If you're looking for legal advice, then I'm doubly not your man, I'm just a software guy, you'll want to address that to the role address that Debian has for such things, patents@debian.org. Ron [1] - So I shouldn't need to clarify this here, of all places, but since there's talk of voting, ramming through a mandate for things which have strong objections and a single unguaranteed supplier, cabbages and kings, and other clear nonsense like having unknown and unaccountable sysadmins at random companies install "DPKGs" on everyone's machines - and people making summaries that talk about "Debian's opinion", I guess I need to restate the obvious ... if only for the people who actually know nothing at all about what Debian is and how it works. I do not, and indeed cannot, speak _for_ Debian. I don't hide my significant affiliations, but since I'm not a Chair or AD, or hold any other role in the IETF, I can only, ever, speak solely as an individual contributor. And only ever have. There have been people here who have sought to express "their employer's opinion", but since that's just obviously irrelevant extra baggage here, that's not a hammer I've ever swung in any working group. Debian as an organisation, is actually similar to the IETF in many ways. Aside from a small handful of people endowed with delegations for various tasks (of which I'm not one), contributors are all volunteer individuals, who are essentially responsible for only their own contributions. If you want the "Opinion of Debian", you're going to need to have a shit fight on another list, to draft a position statement (or several dozen options for one), and then hold a General Resolution, where 1000-odd people will vote to see if we can 'agree' on any of them. And there you'll again face many people who (like me), think voting is a useless way to determine anything more important than whether our logo should be the chicken or the swirl - and from past experience know that trying this for actually significant contentious issues, is typically intensely damaging and divisive, leaving scars that take years to heal, if they ever finally do. I would strongly, as an individual, recommend the Chairs of this WG learn from our mistakes there and not seek to repeat them here too. [2] Whatever the result of the vote may be, it _will_ escalate through every level of protest available, and possibly invent several new ones too. People who wanted nothing more than for this group to fail spectacularly, will laugh their asses off at the havoc wreaked beyond their wildest imagination. [2] - Since as every pilot knows, you won't live long enough to make them all yourself :) From ron@debian.org Sat Nov 23 11:05:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E013B1AE20B for ; Sat, 23 Nov 2013 11:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf6zyBmYIunI for ; Sat, 23 Nov 2013 11:05:08 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2B71AE193 for ; Sat, 23 Nov 2013 11:05:08 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail06.adl2.internode.on.net with ESMTP; 24 Nov 2013 05:35:00 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 887EE4F8F3 for ; Sun, 24 Nov 2013 05:34:58 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ds9vU1Ap5M1i for ; Sun, 24 Nov 2013 05:34:58 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id F24ED4F902; Sun, 24 Nov 2013 05:34:57 +1030 (CST) Date: Sun, 24 Nov 2013 05:34:57 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131123190457.GG3245@audi.shelbyville.oz> References: <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E671A@ausmsex00.austin.kmvtechnologies.com> <528FC513.4020903@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E6731@ausmsex00.austin.kmvtechnologies.com> <52905257.1060209@bbs.darktech.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] Opinions are fine, bypassing a vote is not (was: H.261) X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 19:05:10 -0000 On Sat, Nov 23, 2013 at 06:59:14AM -0800, Eric Rescorla wrote: > I would like to push back on this a bit. Say that we had general consensus > that Theora was strictly better than H.261. Do you think that such a consensus might actually exist? It seems fairly obvious to me that Theora would be a better choice than H.261, but I haven't seen any indication that it wouldn't be subject to exactly the same FUD that VP8 has. Is my impression wrong about that? If it's not, then H.261 _does_ have the advantage of its IPR and licencing situation being far less controversial - dare I say near to irrefutable? I'd be willing to entertain a consensus call on the idea that Theora was considered _strictly_ better than H.261 here. And happy to be proven wrong in this case. > I'm already pretty sad about all the options amen. > and I don't think it's bad to winnow the field if there is near-unanimity > on something.... I agree. I'm likewise disappointed that your repeated hints about the troubles of voting for a field filled with many questionable options seems to have been lost in the noise. Ron From adam@nostrum.com Sat Nov 23 11:39:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D76A1AE213 for ; Sat, 23 Nov 2013 11:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8ss-5fxmUot for ; Sat, 23 Nov 2013 11:39:36 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 392DC1AE18C for ; Sat, 23 Nov 2013 11:39:36 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rANJdMj9003078 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 23 Nov 2013 13:39:23 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52910465.8010205@nostrum.com> Date: Sat, 23 Nov 2013 13:39:17 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Lorenzo Miniero References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <20131123013935.6690a07a@rainpc> <529009A0.5050708@nostrum.com> <20131123120816.0bc16a75@rainpc> In-Reply-To: <20131123120816.0bc16a75@rainpc> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 19:39:37 -0000 On 11/23/13 05:08, Lorenzo Miniero wrote: > If no one has a clue either, then, why make the 100k point in the first place? Because the situation you're describing is applicable to only a tiny sliver of the people involved in this space. If you have a question about the corner cases, you need to ask experts. I'm sorry we can't optimize your corner cases to the detriment of the normal ones, but that's just good engineering practice. /a From lorenzo@meetecho.com Sat Nov 23 12:53:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365241AE0AA for ; Sat, 23 Nov 2013 12:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD1fin3yoICB for ; Sat, 23 Nov 2013 12:53:12 -0800 (PST) Received: from smtpdg5.aruba.it (smtpdg223.aruba.it [62.149.158.223]) by ietfa.amsl.com (Postfix) with ESMTP id D1F4D1AE357 for ; Sat, 23 Nov 2013 12:53:11 -0800 (PST) Received: from rainpc ([95.239.158.221]) by smtpcmd02.ad.aruba.it with bizsmtp id t8t01m00Z4mtnyP018t0cA; Sat, 23 Nov 2013 21:53:02 +0100 Date: Sat, 23 Nov 2013 21:53:00 +0100 From: Lorenzo Miniero To: Adam Roach Message-ID: <20131123215300.4fd6e2c3@rainpc> In-Reply-To: <52910465.8010205@nostrum.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <20131123013935.6690a07a@rainpc> <529009A0.5050708@nostrum.com> <20131123120816.0bc16a75@rainpc> <52910465.8010205@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 20:53:14 -0000 On Sat, 23 Nov 2013 13:39:17 -0600 Adam Roach wrote: > On 11/23/13 05:08, Lorenzo Miniero wrote: > > If no one has a clue either, then, why make the 100k point in the first place? > > Because the situation you're describing is applicable to only a tiny > sliver of the people involved in this space. If you have a question > about the corner cases, you need to ask experts. I'm sorry we can't > optimize your corner cases to the detriment of the normal ones, but > that's just good engineering practice. > > /a The example I made, maybe, not the applicability of the question. The same could apply to a browser, mobile app or whatever: am I consuming a unit installing the browser which includes an encoder/decoder, or each time I start a call? Too bad I have no lawyer or expert to ask to. L. -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From miconda@gmail.com Sat Nov 23 13:06:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDD41AE37E for ; Sat, 23 Nov 2013 13:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRbbb9BZw32F for ; Sat, 23 Nov 2013 13:06:06 -0800 (PST) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCD41AE294 for ; Sat, 23 Nov 2013 13:06:06 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id b10so1351400eae.5 for ; Sat, 23 Nov 2013 13:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ITFcuDeB6aKl+s3k+bQtt31nQf7nxYDItK06Nd/Lqc0=; b=rggY/+1uLiylWiTjCfj6Mb+m7YoGnEnzA0R2/cF92TFwfE33YyJpVVfWiw5B3ypHKY FEwtka69skFBeVMd7Ky2bjP/vFdJNWRj1/AlygtT77E4lejouMuKMnmSfpUBm5T20zug h+t24Qd/0+ro14/ayaA3f+ERndIIGt9rmFjXIRzRx1GoYe1Z4h0KE+EYf4fcE9TlKtxL JTVuf/MlFQUIZfKqi5othWjqPBmSs05SbrFamVPCLNSbCsOrFIrzDYH1voRoGKGYLQpt M2O896ech3NktOb+hnTVUKZ4ETcpCAhjK34emhe0ViX4LfrNo06ASiTLDE1hJbUJDGMY kzFw== X-Received: by 10.15.56.137 with SMTP id y9mr46668eew.58.1385240758268; Sat, 23 Nov 2013 13:05:58 -0800 (PST) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id w6sm87438090eeo.12.2013.11.23.13.05.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 13:05:57 -0800 (PST) Message-ID: <529118B2.1000204@gmail.com> Date: Sat, 23 Nov 2013 22:05:54 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: Adam Roach , Lorenzo Miniero References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <20131123013935.6690a07a@rainpc> <529009A0.5050708@nostrum.com> <20131123120816.0bc16a75@rainpc> <52910465.8010205@nostrum.com> In-Reply-To: <52910465.8010205@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com 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: Sat, 23 Nov 2013 21:06:08 -0000 On 11/23/13 8:39 PM, Adam Roach wrote: > On 11/23/13 05:08, Lorenzo Miniero wrote: >> If no one has a clue either, then, why make the 100k point in the >> first place? > > Because the situation you're describing is applicable to only a tiny > sliver of the people involved in this space. If you have a question > about the corner cases, you need to ask experts. I'm sorry we can't > optimize your corner cases to the detriment of the normal ones, but > that's just good engineering practice. Why is open source distributing model a corner case? Or can you detail who are you counting in this tiny sliver? Afaik, you are now working for Mozilla Foundation, thus Firefox, the open source browser. Without a call home (or to Cisco in this case), would you be able to count how many copies of Firefox are distributed out there? For sake of clarification, 100 000 or higher/lower makes no difference from my point of view, it is exposing everything to more troubles that what it solves. It keeps all the things trapped, so if something is getting popular or competing with cisco (or mpeg-la), it can be screwed easily. And this can go beyond the financial matter. Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From adam@nostrum.com Sat Nov 23 13:08:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111621AE04D for ; Sat, 23 Nov 2013 13:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxnIDWK60157 for ; Sat, 23 Nov 2013 13:08:12 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 349E41AE315 for ; Sat, 23 Nov 2013 13:08:12 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rANL7w5r006517 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 23 Nov 2013 15:07:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52911928.3060700@nostrum.com> Date: Sat, 23 Nov 2013 15:07:52 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: miconda@gmail.com, Lorenzo Miniero References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <20131123013935.6690a07a@rainpc> <529009A0.5050708@nostrum.com> <20131123120816.0bc16a75@rainpc> <52910465.8010205@nostrum.com> <529118B2.1000204@gmail.com> In-Reply-To: <529118B2.1000204@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 21:08:13 -0000 On 11/23/13 15:05, Daniel-Constantin Mierla wrote: > Why is open source distributing model a corner case? Or can you detail > who are you counting in this tiny sliver? Conference mixers. /a From miconda@gmail.com Sat Nov 23 13:11:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69E61AE35B for ; Sat, 23 Nov 2013 13:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADaiipYjWo6p for ; Sat, 23 Nov 2013 13:11:40 -0800 (PST) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5E21AE04D for ; Sat, 23 Nov 2013 13:11:40 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id g15so1364087eak.4 for ; Sat, 23 Nov 2013 13:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QgB2U3MlziGjkkOJn74BBC9PE5b5byL250ca6+MQGOQ=; b=D+qdNNSODYRo/ZUw1YtcTogpsBB0Z7KGCwwSuMbN9DfBNf4XOaz4WpoHg45Sc3sZst eWWRYLcPtLM6PU6colghLx1gOf36HpfGr82Suwt+Gt7xO/fGxXP6YVk0SCF0B5VenAyU cMIBewVEt/SGqAOdxTHVKljPoWYqn/JgTh4ryzvv6FfpNYZgxQMSP1bhjINAzT49Uriz ki7n3cVBW4TCRPAFwqaF03y9/EuyI+GPryl+Y9gmz7O/DmhxXv0720CCe8E+5Ebq6yqR XMvVdUgnd84DjhTKGfKCRHliyu/veP4Sf3fQNO2z0xSj09ECBqU8jbtgwzrZeb5Iwx0x f9Rw== X-Received: by 10.14.207.194 with SMTP id n42mr51515eeo.76.1385241092617; Sat, 23 Nov 2013 13:11:32 -0800 (PST) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id g8sm87601652eep.20.2013.11.23.13.11.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 13:11:31 -0800 (PST) Message-ID: <52911A02.6020209@gmail.com> Date: Sat, 23 Nov 2013 22:11:30 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: David Singer , Basil Mohamed Gohar References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com 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: Sat, 23 Nov 2013 21:11:45 -0000 On 11/23/13 12:45 AM, David Singer wrote: > On Nov 22, 2013, at 14:44 , Basil Mohamed Gohar wrote: > >> On 11/22/2013 05:01 PM, Adam Roach wrote: >>> On 11/22/13 14:22, Daniel-Constantin Mierla wrote: >>>> They plan to release the sources under BSD, but who wants to use them >>>> directly, they have to deal with mpeg-la. >>> >>> Every time this kind of statement is made without also including "if >>> they distribute more than 100,000 copies a year", it's a bald >>> misrepresentation of the situation. >>> >>> I'm not saying the 100,000-copy exemption is a silver bullet. But it >>> sure does cut down the number of people who have to deal with MPEG-LA, >>> and completely addresses the "what if I want to have a enterprise disk >>> image?" question. And ignoring it to exaggerate your case doesn't do >>> anyone any favors. >>> >>> /a >> Free software projects do not have a reliable mechanism by which to >> count their distribution, since it is sent out through many means, not >> the least of which can include direct downloads, SCM code checks (e.g., >> Github), GNU/Linux and *BSD distibutions (which can easily exceed >> 100,000 for the most popular ones), to name a few. >> >> Where does the liability for counting lie in each of these cases? The >> licensing restrictions that MPEG-LA has placed on H.264 is very >> free-software unfriendly for any cases where you want rights to be >> transitive - which is a key, fundamental aspect of software freedom. > Curiously, I think that the position is that if you distribute source (e.g. of FFMPeg, X264) then the person who compiles it is making the final product, so if everyone builds it themselves, they are in a product distribution group size of 1. > > Don’t rely on me, IANAL. That would require to have also smart phones shipped with a compiler and all build dependencies/libraries. Anyhow, most of distros ship binary packages. Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From ekr@rtfm.com Sat Nov 23 13:13:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2E01AE387 for ; Sat, 23 Nov 2013 13:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC47gtdWLLnM for ; Sat, 23 Nov 2013 13:13:07 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id A0F961AE315 for ; Sat, 23 Nov 2013 13:13:07 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so2487157wes.10 for ; Sat, 23 Nov 2013 13:12:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QKWvJ2UgcUT7h8YHUfGNYKWqsche9GqaT7HsRzN98ko=; b=hfMIu5CUks2IPxjjWV3JL7fXpToGxD4itq1UUIMkAFwpvtCpfxU0zNq9EV3gdEwHRW h01NzA2bQNpmh3xUshnjAwk+TOtoH1AvQV1txtDPg2cfRe72wV1uQL95RoHQ6MHTMwPP mDO5FJE0HJx0ua98H/iOSfo7I86AU7m2zmaclZ2weVcIlXIq0Bdj1UGFO1qI24m83ai5 2cVjbPzba3/80ywa45AjBPOF9lx0ujC78dcg/UNqSI4Z2kv99DxuH8CmZSMfUFvnvOrS v1uzWIE/9hjB2ANVJIueyUE3NgNm5s/wIn6GdpbiuhnpR8UN4dgfUQMtNfsDPwc8D8ie 1OdQ== X-Gm-Message-State: ALoCoQltPWj578pXlRdq9gkMEVXb5wKjLWlDma7lr9sv1fJGqIIvGD0L3Q0hRPqfeSSFw+WImuyk X-Received: by 10.194.216.225 with SMTP id ot1mr42265wjc.80.1385241179672; Sat, 23 Nov 2013 13:12:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Sat, 23 Nov 2013 13:12:19 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: <20131123215300.4fd6e2c3@rainpc> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <20131123013935.6690a07a@rainpc> <529009A0.5050708@nostrum.com> <20131123120816.0bc16a75@rainpc> <52910465.8010205@nostrum.com> <20131123215300.4fd6e2c3@rainpc> From: Eric Rescorla Date: Sat, 23 Nov 2013 13:12:19 -0800 Message-ID: To: Lorenzo Miniero Content-Type: multipart/alternative; boundary=001a11c283b8716f9004ebde9838 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sat, 23 Nov 2013 21:13:10 -0000 --001a11c283b8716f9004ebde9838 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sat, Nov 23, 2013 at 12:53 PM, Lorenzo Miniero wro= te: > On Sat, 23 Nov 2013 13:39:17 -0600 > Adam Roach wrote: > > > On 11/23/13 05:08, Lorenzo Miniero wrote: > > > If no one has a clue either, then, why make the 100k point in the > first place? > > > > Because the situation you're describing is applicable to only a tiny > > sliver of the people involved in this space. If you have a question > > about the corner cases, you need to ask experts. I'm sorry we can't > > optimize your corner cases to the detriment of the normal ones, but > > that's just good engineering practice. > > > > /a > > The example I made, maybe, not the applicability of the question. The sam= e > could apply to a browser, mobile app or whatever: am I consuming a unit > installing the browser which includes an encoder/decoder, or each time I > start a call? Too bad I have no lawyer or expert to ask to. Seriously? May I ask whether you have read the summary terms at: http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf They seem relatively clear on this point: "(a decoder, encoder, or product consisting of one decoder and one encoder =3D =93unit=94)" More importantly, do you seriously think anyone would license H.264 for a product if you had to pay $.10 every time the product started up. -Ekr --001a11c283b8716f9004ebde9838 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Sat, Nov 23, 2013 at 12:53 PM, Lorenzo Miniero <lorenzo@meet= echo.com> wrote:
On Sat, 23 Nov 2013 13:39:17 -0600
Adam Roach <adam@nostrum.com>= wrote:

> On 11/23/13 05:08, Lorenzo Miniero wrote:
> > If no one has a clue either, then, why make the 100k point in the= first place?
>
> Because the situation you're describing is applicable to only a ti= ny
> sliver of the people involved in this space. If you have a question > about the corner cases, you need to ask experts. I'm sorry we can&= #39;t
> optimize your corner cases to the detriment of the normal ones, but > that's just good engineering practice.
>
> /a

The example I made, maybe, not the applicability of the question. The= same could apply to a browser, mobile app or whatever: am I consuming a un= it installing the browser which includes an encoder/decoder, or each time I= start a call? Too bad I have no lawyer or expert to ask to.

Seriously? May I ask whether you have read the summary = terms at:

They seem relatively clear on this point:
"(a decoder, encoder, or product consisting of one decoder and one = encoder =3D =93unit=94)"

More importantly, do= you seriously think anyone would license H.264 for
a product if you had to pay $.10 every time the product started up.

-Ekr
=A0
--001a11c283b8716f9004ebde9838-- From miconda@gmail.com Sat Nov 23 13:14:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2001AE35B for ; Sat, 23 Nov 2013 13:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojQNi3a99pEV for ; Sat, 23 Nov 2013 13:14:56 -0800 (PST) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 059E81AE04D for ; Sat, 23 Nov 2013 13:14:55 -0800 (PST) Received: by mail-ea0-f170.google.com with SMTP id k10so1412308eaj.1 for ; Sat, 23 Nov 2013 13:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FFTBdTo0d/ri/MLHpeg6LbfK0O6xLk3nuVqsiTA8B20=; b=dVIMwoHK24qHSZTzfwuf6LnugG3Lyy/1VAo126QsGAbk0XgJvy6xTGe5Bi8RtqprH1 2EDtCregi54nABAEWMzmSvIzDzB8jBzm8l9LseI6coTl9D+ljzU4Hz7aB7zBKMpNdJp+ DWj6PieaApJF3fCfBezAHCj0wqR3ZX9G37ujxM+cUH0yM1eQaoLtRKq4k4pJyV5i+1Bv g4hmTvc+LX1toF/baSU7rfSMEtGiMt0U+OvXyKWLSEZ/dQQriSjumNhNYma6xJHqBB+l WqRK2p/vwvnl5q3zL9N/AK84jyLnHFYspymnvZ7nRrglm8cH1eb/M1lePY5+60OZC0Hc E3eg== X-Received: by 10.14.199.197 with SMTP id x45mr25929040een.8.1385241288112; Sat, 23 Nov 2013 13:14:48 -0800 (PST) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id g8sm87622199eep.20.2013.11.23.13.14.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 13:14:47 -0800 (PST) Message-ID: <52911AC5.3090408@gmail.com> Date: Sat, 23 Nov 2013 22:14:45 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: David Singer , Basil Mohamed Gohar References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FC497.2080804@googlemail.com> <528FEC5A.8060701@librevideo.org> <7C4C4F47-1F9B-4A69-AE68-122DE394E203@apple.com> In-Reply-To: <7C4C4F47-1F9B-4A69-AE68-122DE394E203@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com 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: Sat, 23 Nov 2013 21:14:58 -0000 On 11/23/13 12:46 AM, David Singer wrote: > On Nov 22, 2013, at 15:44 , Basil Mohamed Gohar wrote: > >> On 11/22/2013 06:42 PM, David Singer wrote: >>> On Nov 22, 2013, at 12:54 , Maik Merten wrote: >>> >>>> And again, H.261 is only considered as fallback option to establish basic video interoperability as no single high-performance video codec can be agreed on. It would only kick into action in situations when the alternative would be "no video at all". This fallback option has to be implementable without relevant restrictions. >>> I rather suspect that many, given a choice between: >>> a) deliver crappy video using H.261, with the unstated implication to the users at the two ends that they really need to find something that will interoperate on something better >>> and >>> b) tell the users directly that they don’t have a video codec in common, and to get video they need to find something that will interoperate >>> >>> would actually prefer (b). It’s less work, more direct, and more honest. >>> >>> David Singer >>> Multimedia and Software Standards, Apple Inc. >>> >> Then we need to restate one of the goals of this WG if we're not going >> to have an MTI. However, I personally disagree with that change. > No, I think we all want an MTI codec. But not at any price in terms of quality degradation, and H.261 may be simply off the bottom end. This is the last resort if one doesn't have a better alternative. I doubt people that really like wide band audio codecs don't use mobile phones on 2G/GSM which is quite poor audio experience, but when you are on top of mountains or remote locations is the only option. Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From ron@debian.org Sat Nov 23 17:34:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0873F1AE267 for ; Sat, 23 Nov 2013 17:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1TgonBPelPn for ; Sat, 23 Nov 2013 17:34:13 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6BA1AE1BF for ; Sat, 23 Nov 2013 17:34:12 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 24 Nov 2013 12:04:04 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id E99E04F8F3 for ; Sun, 24 Nov 2013 12:04:01 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qQ77bzey5qlJ for ; Sun, 24 Nov 2013 12:04:00 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id CB66C4F902; Sun, 24 Nov 2013 12:04:00 +1030 (CST) Date: Sun, 24 Nov 2013 12:04:00 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131124013400.GI3245@audi.shelbyville.oz> References: <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FC497.2080804@googlemail.com> <528FEC5A.8060701@librevideo.org> <7C4C4F47-1F9B-4A69-AE68-122DE394E203@apple.com> <52911AC5.3090408@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52911AC5.3090408@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 - taking a longer view of things X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 01:34:15 -0000 On Sat, Nov 23, 2013 at 10:14:45PM +0100, Daniel-Constantin Mierla wrote: > > On 11/23/13 12:46 AM, David Singer wrote: > > No, I think we all want an MTI codec. But not at any price in terms > > of quality degradation, and H.261 may be simply off the bottom end. > > This is the last resort if one doesn't have a better alternative. I > doubt people that really like wide band audio codecs don't use > mobile phones on 2G/GSM which is quite poor audio experience, but > when you are on top of mountains or remote locations is the only > option. Actually, it's much more than that. This is going to be the codec of last resort "forever". Think about that. Think hard. I'll wait. Unless we are going to resign ourselves to this whole standard being a bad joke, that will be discarded in a few short years time, with all the work that has gone into it needing to be repeated *again*, then this specification is going to vastly outlive any codec that happens to be flavour of the month today. Which means long after H.264 has fallen out of favour and stopped being included in hardware and "legacy devices", and possibly during that fun period where people screw up the royalty rates hard to get people to move on to H.265 or whatever the next revenue raiser will be, implementations of this standard would still need to carry that dead baggage. Forever. Let's take a quick look at how that might compare: For the RM8 implementation of H.261: p64dir$ sloccount . Total Physical Source Lines of Code (SLOC) = 6,707 For x264 (from git a few minutes ago): x264$ sloccount . Total Physical Source Lines of Code (SLOC) = 89,663 One of these has been 'stable' since 1995. The other is still fixing several bugs a month, even as we speak. One of these will still be a standard applicable to the PSTN for as long as it continues to be around (just like G.711). The other will be consigned to the dusts of history with H.262 and H.263, probably well before vinyl records are. H.265 is already out. VP9 is nearly already out. Daala is going to kick all of their asses like Opus did ... These are the codecs that people are _actually_ going to use by the time this standard is actually completed and well established. So remind me again why we want to take all of the obvious pain today to mandate a codec that will also be orders of magnitude more pain in perpetuity? Who wants to still be fixing security bugs in H.264 in 2020? When people have long since stopped actually using or testing it. Yes, H.261 is not quite as trivial as G.711, but compared to H.264 it's near enough. It was designed to run on 'computers' made of snot and matchsticks and rubber bands. If we are going to burden ourselves with having to carry an obsolete codec forever, whatever we do -- then maybe there actually is a genuine argument that H.261 is not just a compromise we'll all hate, but it could in fact be, when all things are considered, a clearly superior choice in its own right for the MTI fallback of last resort. Shocking I know. But I guess that's what happens when you take a step back from short sighted, short term, "best for me today" considerations and look at the big picture here. I cordially invite everyone else to do the same :) Ron From martin.thomson@gmail.com Sat Nov 23 20:12:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE9D1AD8F5 for ; Sat, 23 Nov 2013 20:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaMzOyRiQqrS for ; Sat, 23 Nov 2013 20:12:31 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id D79251AD7C0 for ; Sat, 23 Nov 2013 20:12:30 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hm4so4151290wib.13 for ; Sat, 23 Nov 2013 20:12:22 -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=tISYUhXgySkEyoTQs+U77it3hastpGvZAU+BRYXOoBY=; b=CPmvvK9qo9xnFwTMx5p+8PktGcvjL4yvyoHDLBhWHM4gA5Xkb7K40kNR3RhCVRZGkV rqwxTECHyUuw9088RdAiSOo757vnJKBDONNCCO6NoXs2Cpg4wBKn8CPZLaY8ulT/0SVd CbYc6Pd9rlJMfSckc7rZ9L95bGS71Bm7Ns6HmdzWUJoVcMG3tism2KVfgfVeW62HHmeF 8lQBYX3R8Sy1Lgb1Y8e22ORXz8F2yU4Ma/gXmWZGmGoZsbY3yGnlsImOTZjxtSKK9Mps k5d1ypKGKs7UwT+GfEXi1dlsZgfVmvKbkhjSb3NZxAOvC+vOr6i386iAaMBooUlUuiBx XEWQ== MIME-Version: 1.0 X-Received: by 10.180.77.49 with SMTP id p17mr8626081wiw.30.1385266342842; Sat, 23 Nov 2013 20:12:22 -0800 (PST) Received: by 10.227.134.195 with HTTP; Sat, 23 Nov 2013 20:12:22 -0800 (PST) In-Reply-To: <20131124013400.GI3245@audi.shelbyville.oz> References: <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FC497.2080804@googlemail.com> <528FEC5A.8060701@librevideo.org> <7C4C4F47-1F9B-4A69-AE68-122DE394E203@apple.com> <52911AC5.3090408@gmail.com> <20131124013400.GI3245@audi.shelbyville.oz> Date: Sat, 23 Nov 2013 20:12:22 -0800 Message-ID: From: Martin Thomson To: Ron Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 - taking a longer view of things X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 04:12:32 -0000 On 23 November 2013 17:34, Ron wrote: > Forever. Just like DVI4 [RFC3551]. Oh wait [RFC7007]. From sslivinski@lifesize.com Sat Nov 23 20:34:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EA01AD942 for ; Sat, 23 Nov 2013 20:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwscjykYr1dA for ; Sat, 23 Nov 2013 20:34:02 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with SMTP id C0B5E1AD939 for ; Sat, 23 Nov 2013 20:34:02 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUpGBsf8yvRlSwcMF2C0CBmXmCFiE+3Sc@postini.com; Sat, 23 Nov 2013 20:33:55 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Sat, 23 Nov 2013 22:29:42 -0600 From: Stefan Slivinski To: cowwoc , "rtcweb@ietf.org" Date: Sat, 23 Nov 2013 22:29:39 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7oHPx3wpNzlAGkTV2LmwG1ru8OlgAq6Nvw Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com> References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> <529057EB.3060704@bbs.darktech.org> In-Reply-To: <529057EB.3060704@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 04:34:05 -0000 I don't want to make any assumptions as to why their particular use case fa= iled at 20+ participants. Maybe it was bandwidth related, maybe it was bec= ause intel quicksync doesn't support VP8. I don't know and I'm not going t= o speculate. What I do know is intel quicksync is capable of decoding H.26= 4 at 4K without breaking a sweat. 4K is more than 80x (yes, eighty times) = the resolution of H.261. So H.261 isn't likely to have helped them here. What few seem to acknowledge is that companies like intel, TI, qualcomm, br= oadcom (just to name a few) have spent hundreds of millions (if not billion= s) of dollars adding hardware accelerate for H.264 to their chips. Purpose= designed hardware will always be faster and require less power than softwa= re implementations and no one is spending anything supporting H.261 hardwar= e acceleration. =20 H.261 does not have any technical advantage whether it be bitrate, performa= nce, power consumption or otherwise over H.264 on any modern media processo= r -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc Sent: Friday, November 22, 2013 11:23 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 Stefan, At the conference, they mentioned that you cannot implement online video cl= asses (with 20+ participants) unless you reduce the resolution and frame ra= te of non-speakering participants. Meaning, even without having to do any t= ranscoding (they use VP8 across the board) there is insufficient bandwidth = and CPU to handle 20 incoming video streams at HD resolutions. So what you = do is host non-speakers at tiny resolutions and 3 fps. H.261 could handle those non-speakers just fine (in fact, it would be prefe= rable as it reduces CPU usage). Furthermore, if you chose to transcode, you= 'd be dealing with tiny resolutions and 3fps. In both cases, the use of H.2= 61 or transcoding is not the bottleneck. Gili On 22/11/2013 8:42 PM, Stefan Slivinski wrote: > Just for fun, let's play out the H.261 scenario as the great savior of we= brtc that some claim it is: > > Let's say through some divine miracle we manage to all agree to make H.26= 1 the one and only MTI codec. The rationale being of course that no one wi= ll ever use it because it is of course terrible, but we need it to get arou= nd those pesky patent/license terms with VP8/H.264 respectively. > > Alright fast forward, Chrome adds H.261 but continues to use VP8. IE use= s H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, H.26= 4 and VP8. So far so good. Chrome can talk using VP8 to Firefox, Safari c= an talk H.264 to IE, Firefox can either H.264 or VP8 to everyone. As long = as Chrome users don't try to call IE or Safari, we're in good shape, otherw= ise we need to transcode using some undefined cloud based transcoder servic= e or just use H.261. > > So we're still in good shape. Now let's consider the multiway case. I h= eard a use case at the conference on Tuesday where a university was using w= ebrtc to enable video online classes. So let's assume there are 20 people = in the class. 19 people in the class love Chrome, so they join the class f= rom chrome and are all sending each other VP8. But of course there's alway= s one person that has to be difficult and they decide they prefer IE. So w= hat now? Well the IE person doesn't understand any of the 19 VP8 streams = and the 19 chrome users don't understand the 1 H.264 stream. So we can now= utilize that same undefined cloud transcoding service to convert each of t= he 19 VP8 streams to H.264 and the 1 H.264 stream to VP8....or we can use H= .261. > > My guess is H.261 is going to get used a lot more than anyone thinks. > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Friday, November 22, 2013 5:37 PM > To: Ron; rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > On 11/22/13 18:35, Ron wrote: >> The whole point of many distros is to supply binaries, often built=20 >> many times for many different system architectures. > And the overwhelming majority of these do so by including a list of repos= itories from which the binaries can be downloaded. > > I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, = and whatever else is needed for these distros, targeting whatever platforms= are required. Now, whether we can get the distro maintainers to add a sing= le line to their list of repos -- because that's all it would take -- is a = different issue. But at that point, it's just a matter of the distro mainta= iners being intransigent rather than any real technical or legal barrier. > > /a > _______________________________________________ > 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 From sslivinski@lifesize.com Sat Nov 23 20:43:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04241AD948 for ; Sat, 23 Nov 2013 20:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RjqTYZnWM5G for ; Sat, 23 Nov 2013 20:43:33 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with SMTP id 0209C1AE3B6 for ; Sat, 23 Nov 2013 20:43:32 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUpGD7NezZEfehp54VEntkpark7K1jAS8@postini.com; Sat, 23 Nov 2013 20:43:25 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Sat, 23 Nov 2013 22:39:34 -0600 From: Stefan Slivinski To: cowwoc , "rtcweb@ietf.org" Date: Sat, 23 Nov 2013 22:39:32 -0600 Thread-Topic: [rtcweb] H.264 CBP (was: Video codec selection - way forward) Thread-Index: Ac7oHffBBXway9eJR8qi0y95/5KZpgAsAx+A Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E677B@ausmsex00.austin.kmvtechnologies.com> References: <52891EDB.2050607@googlemail.com> <528B2ABE.4040701@googlemail.com> <528C79AD.10608@googlemail.com> <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com> <528E5E89.8040706@googlemail.com> <52905990.8070207@bbs.darktech.org> In-Reply-To: <52905990.8070207@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.264 CBP (was: Video codec selection - way forward) X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 04:43:35 -0000 I don't know which profile was under discussion but constrained baseline pr= ofile (CBP) removes tools like FMO and ASO from baseline profile which have= been unpopular because of their complexity and quality tradeoffs. In realtime video communications High profile typically just adds cabac and= 8x8 transform which in general reduce the bitrate for video communications= type content (talking heads, no high action movies) by about 20-25% as com= pared to CBP. Cabac in particular adds a fair amount of complexity but mos= t modern hardware acceleration supports it meaning there is no performance = hit to the CPU. -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc Sent: Friday, November 22, 2013 11:30 PM To: rtcweb@ietf.org Subject: [rtcweb] H.264 CBP (was: Video codec selection - way forward) +1 In the original VP8 vs H.264 discussion, what H.264 profile was under discu= ssion? If it was not H.264 CBP, do we need to revisit the comparison? Do the two p= rofiles use the same bandwidth, CPU and produce the same quality? Thanks, Gili On 21/11/2013 2:27 PM, Maik Merten wrote: > Btw, should any occurrence of "H.264" in the current list of options=20 > be substituted with "H.264 CBP"? Perhaps it is best to be very clear=20 > on the profile which should be implemented. > > Thanks, > > Maik > > Am 21.11.2013 20:20, schrieb David Singer: >> Chairs >> >> can we add this as an option to the formal list, so we get formal=20 >> feedback on its acceptability, please? >> >> "Like option ??, pick at least two of {VP8, H.264 CBP, H.263}" >> >> >> I think this may be the best (maybe only) way to tease out how much=20 >> risk people perceive. >> >> Many thanks >> >> On Nov 21, 2013, at 9:22 , Maik Merten >> wrote: >> >>> Cleary H.263 is preferable from an engineering standpoint (as is,=20 >>> e.g., MPEG-1 Part 2): better performance, more deployments. The=20 >>> central question is, however, if those can actually be implemented=20 >>> without some sort of licensing. >>> >>> If they can: Aweseome! However, this may not be determinable without=20 >>> a review by people who are knowledgeable in the field of IPR, i.e.,=20 >>> "actual lawyers". I understand that H.263 is not yet old enough to=20 >>> automatically be considered "safe" (and neither is MPEG-1 Part 2,=20 >>> although it is closer). >>> >>> Best regards, >>> >>> Maik >>> >>> Am 20.11.2013 20:42, schrieb David Singer: >>>> I think we should think hard about H.263 instead of H.261 as the=20 >>>> third fallback. Why? >>>> >>>> http://www.itu.int/rec/T-REC-H.263/ >>>> >>>> >>>> >>>> H.263 was first published in March 1996, so it's 17 years old. The=20 >>>> restrictions (e.g. on picture size) are no WORSE than H.261. Yes,=20 >>>> more recent amendments deal with this (and a plethora of other=20 >>>> issues), so we'd need to settle on which of those are mandatory=20 >>>> (the usual profiling discussion). >>>> >>>> There are 34 records in the patent database against H.261, mostly=20 >>>> from 1989 but one as recent as 2005 (though that is a re-file). >>>> That's 2.2 (reciprocity), as was one other I checked. >>>> >>>> Rather surprisingly, there are only 31 against H.263! The most=20 >>>> recent is 2011, and is also option 2. Most are 1997-2001. >>>> >>>> >>>> On this quick glance, H.263 appears no worse than H.261. IANAL (as=20 >>>> I am sure you have all noticed). >>>> >>>> >>>> H.263 is much more widely supported and mandated. It has been=20 >>>> mandated in the 3GPP specs for years (for lots of services,=20 >>>> including videoconf), and is effectively the fallback codec today=20 >>>> in the industry, as I understand. It was ubiquitous in video=20 >>>> telephony for years, and I suspect many of those systems still ship=20 >>>> it. >>>> >>>> So, would "MUST implement at least two of (H.264, VP8, H.263)" work? >>>> >>>> (I am asking the question, not even answering on behalf of my=20 >>>> company, yet. Let's get the issues on the table.) >>>> >>>> >>>> David Singer >>>> Multimedia and Software Standards, Apple Inc. >>>> >>>> _______________________________________________ >>>> 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 >> >> David Singer >> Multimedia and Software Standards, Apple Inc. >> >> _______________________________________________ >> 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 From ron@debian.org Sat Nov 23 22:01:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA511ADF8C for ; Sat, 23 Nov 2013 22:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXSfdWI5GIFJ for ; Sat, 23 Nov 2013 22:01:42 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id D6F981ADF7E for ; Sat, 23 Nov 2013 22:01:41 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail06.adl6.internode.on.net with ESMTP; 24 Nov 2013 16:31:33 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id B6E684F8F3 for ; Sun, 24 Nov 2013 16:31:30 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id h1DpvNLWnz3B for ; Sun, 24 Nov 2013 16:31:28 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 569574F902; Sun, 24 Nov 2013 16:31:28 +1030 (CST) Date: Sun, 24 Nov 2013 16:31:28 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131124060128.GJ3245@audi.shelbyville.oz> References: <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FC497.2080804@googlemail.com> <528FEC5A.8060701@librevideo.org> <7C4C4F47-1F9B-4A69-AE68-122DE394E203@apple.com> <52911AC5.3090408@gmail.com> <20131124013400.GI3245@audi.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 - taking a longer view of things X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 06:01:43 -0000 On Sat, Nov 23, 2013 at 08:12:22PM -0800, Martin Thomson wrote: > On 23 November 2013 17:34, Ron wrote: > > Forever. > > Just like DVI4 [RFC3551]. Oh wait [RFC7007]. Are you suggesting that two interoperable implementations of H.264 will not be found, or just confusing the difference between recommended and mandatory to implement? If H.264 and/or VP8 and anything else that people fancy are simply given SHOULD or MAY status "Just like DVI4", then we can indeed update the recommendations in the spec at a later date easily just like this. That's _exactly_ what I'm suggesting. That we seriously consider the future burden that MANDATORY will impose. Since changing that will break the interoperability guarantee. Choosing something that actually is trivial to maintain over that sort of timespan is a decision that people in the (not too distant) future might actually look back on as having some forethought. If you'd like to think about it a bit more, I'll keep waiting ;p Ron From lgeyser@gmail.com Sat Nov 23 22:02:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C4C1ADF7D for ; Sat, 23 Nov 2013 22:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgTR9outm8SO for ; Sat, 23 Nov 2013 22:02:45 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1B06A1ADF6B for ; Sat, 23 Nov 2013 22:02:44 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id eo20so2046168lab.14 for ; Sat, 23 Nov 2013 22:02:36 -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=aT4acpXts/hwtkVedLp1J5nHOiguO9qhHb4eyI+0Nds=; b=Hp6GAnKkB7Bd889oqRGlnI7Lrg4WxaVAX1JoLGqH2CfCnRPlaAjbQqwSnQHJM7CEkr 8MIQ5dq3Qxy0BHvJdpntTeptB/q3kBg6YtdCmf+lgv3bn2mGX/4G6W6LFqGB7OOA9Qjx 6SSmdnilo4feF8Ghtwr9ct1IDcF1Od706CPlCyZgAe2RAMVfQqpXhx8hSBvY75oaICZa 5t9FZseF37NJkWGliA1/AruwrpQi8/PWFfOb1a+3sdP9sCo5VPqXWEG3wKbLBfEQtzcT QjtpbjRrO4wW+mpWHj/K5vrSUE79RAX7RywI6qcix4zGHFvdUqEqQpTtUIw37UB7j9kN R6bw== MIME-Version: 1.0 X-Received: by 10.112.154.129 with SMTP id vo1mr131332lbb.31.1385272956693; Sat, 23 Nov 2013 22:02:36 -0800 (PST) Received: by 10.114.168.70 with HTTP; Sat, 23 Nov 2013 22:02:36 -0800 (PST) In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com> References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> <529057EB.3060704@bbs.darktech.org> <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com> Date: Sun, 24 Nov 2013 08:02:36 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e0115fb0880332004ebe5fe76 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 06:02:48 -0000 --089e0115fb0880332004ebe5fe76 Content-Type: text/plain; charset=ISO-8859-1 If we fallback to a software H.261 encoder/decoder then will it really use so much CPU that devices will be unusable or the battery will deplete early? I didn't know that H.261 was so CPU intensive... I also agree with Ron that we shouldn't make a codec like H.264 mandatory that will anyway be obsoleted by the next best thing in the future. On 24 November 2013 06:29, Stefan Slivinski wrote: > I don't want to make any assumptions as to why their particular use case > failed at 20+ participants. Maybe it was bandwidth related, maybe it was > because intel quicksync doesn't support VP8. I don't know and I'm not > going to speculate. What I do know is intel quicksync is capable of > decoding H.264 at 4K without breaking a sweat. 4K is more than 80x (yes, > eighty times) the resolution of H.261. So H.261 isn't likely to have > helped them here. > > What few seem to acknowledge is that companies like intel, TI, qualcomm, > broadcom (just to name a few) have spent hundreds of millions (if not > billions) of dollars adding hardware accelerate for H.264 to their chips. > Purpose designed hardware will always be faster and require less power > than software implementations and no one is spending anything supporting > H.261 hardware acceleration. > > H.261 does not have any technical advantage whether it be bitrate, > performance, power consumption or otherwise over H.264 on any modern media > processor > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc > Sent: Friday, November 22, 2013 11:23 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > Stefan, > > At the conference, they mentioned that you cannot implement online video > classes (with 20+ participants) unless you reduce the resolution and frame > rate of non-speakering participants. Meaning, even without having to do any > transcoding (they use VP8 across the board) there is insufficient bandwidth > and CPU to handle 20 incoming video streams at HD resolutions. So what you > do is host non-speakers at tiny resolutions and > 3 fps. > > H.261 could handle those non-speakers just fine (in fact, it would be > preferable as it reduces CPU usage). Furthermore, if you chose to > transcode, you'd be dealing with tiny resolutions and 3fps. In both cases, > the use of H.261 or transcoding is not the bottleneck. > > Gili > > On 22/11/2013 8:42 PM, Stefan Slivinski wrote: > > Just for fun, let's play out the H.261 scenario as the great savior of > webrtc that some claim it is: > > > > Let's say through some divine miracle we manage to all agree to make > H.261 the one and only MTI codec. The rationale being of course that no > one will ever use it because it is of course terrible, but we need it to > get around those pesky patent/license terms with VP8/H.264 respectively. > > > > Alright fast forward, Chrome adds H.261 but continues to use VP8. IE > uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, > H.264 and VP8. So far so good. Chrome can talk using VP8 to Firefox, > Safari can talk H.264 to IE, Firefox can either H.264 or VP8 to everyone. > As long as Chrome users don't try to call IE or Safari, we're in good > shape, otherwise we need to transcode using some undefined cloud based > transcoder service or just use H.261. > > > > So we're still in good shape. Now let's consider the multiway case. I > heard a use case at the conference on Tuesday where a university was using > webrtc to enable video online classes. So let's assume there are 20 people > in the class. 19 people in the class love Chrome, so they join the class > from chrome and are all sending each other VP8. But of course there's > always one person that has to be difficult and they decide they prefer IE. > So what now? Well the IE person doesn't understand any of the 19 VP8 > streams and the 19 chrome users don't understand the 1 H.264 stream. So we > can now utilize that same undefined cloud transcoding service to convert > each of the 19 VP8 streams to H.264 and the 1 H.264 stream to VP8....or we > can use H.261. > > > > My guess is H.261 is going to get used a lot more than anyone thinks. > > > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach > > Sent: Friday, November 22, 2013 5:37 PM > > To: Ron; rtcweb@ietf.org > > Subject: Re: [rtcweb] H.261 > > > > On 11/22/13 18:35, Ron wrote: > >> The whole point of many distros is to supply binaries, often built > >> many times for many different system architectures. > > And the overwhelming majority of these do so by including a list of > repositories from which the binaries can be downloaded. > > > > I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, > and whatever else is needed for these distros, targeting whatever platforms > are required. Now, whether we can get the distro maintainers to add a > single line to their list of repos -- because that's all it would take -- > is a different issue. But at that point, it's just a matter of the distro > maintainers being intransigent rather than any real technical or legal > barrier. > > > > /a > > _______________________________________________ > > 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 > --089e0115fb0880332004ebe5fe76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If we fallback to a software H.261 encoder/decoder th= en will it really use so much CPU that devices will be unusable or the batt= ery will deplete early? I didn't know that H.261 was so CPU intensive..= .
I also agree with Ron that we shouldn't make a codec like H.264 m= andatory that will anyway be obsoleted by the next best thing in the future= .


On= 24 November 2013 06:29, Stefan Slivinski <sslivinski@lifesize.com> wrote:
I don't want to make any assumptions as = to why their particular use case failed at 20+ participants. =A0Maybe it wa= s bandwidth related, maybe it was because intel quicksync doesn't suppo= rt VP8. =A0I don't know and I'm not going to speculate. =A0What I d= o know is intel quicksync is capable of decoding H.264 at 4K without breaki= ng a sweat. =A04K is more than 80x (yes, eighty times) the resolution of H.= 261. =A0So H.261 isn't likely to have helped them here.

What few seem to acknowledge is that companies like intel, TI, qualcomm, br= oadcom (just to name a few) have spent hundreds of millions (if not billion= s) of dollars adding hardware accelerate for H.264 to their chips. =A0Purpo= se designed hardware will always be faster and require less power than soft= ware implementations and no one is spending anything supporting H.261 hardw= are acceleration.

H.261 does not have any technical advantage whether it be bitrate, performa= nce, power consumption or otherwise over H.264 on any modern media processo= r

-----Original Message-----
From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of cowwoc
Sent: Friday, November 22, 2013 11:23 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] H.261

Stefan,

At the conference, they mentioned that you cannot implement online video cl= asses (with 20+ participants) unless you reduce the resolution and frame ra= te of non-speakering participants. Meaning, even without having to do any t= ranscoding (they use VP8 across the board) there is insufficient bandwidth = and CPU to handle 20 incoming video streams at HD resolutions. So what you = do is host non-speakers at tiny resolutions and
3 fps.

H.261 could handle those non-speakers just fine (in fact, it would be prefe= rable as it reduces CPU usage). Furthermore, if you chose to transcode, you= 'd be dealing with tiny resolutions and 3fps. In both cases, the use of= H.261 or transcoding is not the bottleneck.

Gili

On 22/11/2013 8:42 PM, Stefan Slivinski wrote:
> Just for fun, let's play out the H.261 scenario as the great savio= r of webrtc that some claim it is:
>
> Let's say through some divine miracle we manage to all agree to ma= ke H.261 the one and only MTI codec. =A0The rationale being of course that = no one will ever use it because it is of course terrible, but we need it to= get around those pesky patent/license terms with VP8/H.264 respectively. >
> Alright fast forward, Chrome adds H.261 but continues to use VP8. =A0I= E uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261,= H.264 and VP8. =A0So far so good. =A0Chrome can talk using VP8 to Firefox,= Safari can talk H.264 to IE, Firefox can either H.264 or VP8 to everyone. = =A0As long as Chrome users don't try to call IE or Safari, we're in= good shape, otherwise we need to transcode using some undefined cloud base= d transcoder service or just use H.261.
>
> So we're still in good shape. =A0Now let's consider the multiw= ay case. =A0I heard a use case at the conference on Tuesday where a univers= ity was using webrtc to enable video online classes. =A0So let's assume= there are 20 people in the class. =A019 people in the class love Chrome, s= o they join the class from chrome and are all sending each other VP8. =A0Bu= t of course there's always one person that has to be difficult and they= decide they prefer IE. =A0So what now? =A0 Well the IE person doesn't = understand any of the 19 VP8 streams and the 19 chrome users don't unde= rstand the 1 H.264 stream. =A0So we can now utilize that same undefined clo= ud transcoding service to convert each of the 19 VP8 streams to H.264 and t= he 1 H.264 stream to VP8....or we can use H.261.
>
> My guess is H.261 is going to get used a lot more than anyone thinks.<= br> >
> -----Original Message-----
> From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Adam Roach
> Sent: Friday, November 22, 2013 5:37 PM
> To: Ron; rtcweb@ietf.org
> Subject: Re: [rtcweb] H.261
>
> On 11/22/13 18:35, Ron wrote:
>> The whole point of many distros is to supply binaries, often built=
>> many times for many different system architectures.
> And the overwhelming majority of these do so by including a list of re= positories from which the binaries can be downloaded.
>
> I'm 100% confident that we could convince Cisco to serve up RPMs, = DPKGs, and whatever else is needed for these distros, targeting whatever pl= atforms are required. Now, whether we can get the distro maintainers to add= a single line to their list of repos -- because that's all it would ta= ke -- is a different issue. But at that point, it's just a matter of th= e distro maintainers being intransigent rather than any real technical or l= egal barrier.
>
> /a
> _______________________________________________
> 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

--089e0115fb0880332004ebe5fe76-- From ron@debian.org Sat Nov 23 22:40:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A537C1AE00B for ; Sat, 23 Nov 2013 22:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE3NZf1GPmwI for ; Sat, 23 Nov 2013 22:40:46 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 11A4D1ADFE3 for ; Sat, 23 Nov 2013 22:40:45 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail06.adl6.internode.on.net with ESMTP; 24 Nov 2013 17:10:15 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 015634F8F3 for ; Sun, 24 Nov 2013 17:10:13 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id E9D1tRaFd8ih for ; Sun, 24 Nov 2013 17:10:11 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 5C0084F902; Sun, 24 Nov 2013 17:10:11 +1030 (CST) Date: Sun, 24 Nov 2013 17:10:11 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131124064011.GK3245@audi.shelbyville.oz> References: <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> <529057EB.3060704@bbs.darktech.org> <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 06:40:47 -0000 On Sun, Nov 24, 2013 at 08:02:36AM +0200, Leon Geyser wrote: > If we fallback to a software H.261 encoder/decoder then will it really use > so much CPU that devices will be unusable or the battery will deplete > early? No, it won't. You're pretty much certain to get better battery life doing software H.261 than hardware H.264 on all but the most retarded of architectures (ie. something with _no_ powersaving ability at all). And both of them pale into insignificance against the power your display will use. http://www.yosefk.com/blog/its-done-in-hardware-so-its-cheap.html tldr; something that take 100x more operations to perform _still_ takes ~100x more operations to perform, and about the same amount of power, regardless of whether it's run on a "custom processor" (aka 'hardware acceleration') or a general purpose processor (aka CPU). If you want it to actually go faster too, that will generally use MORE power, not less. Ye cannae change the laws o' physics. Nobody who has actually measured this, or understands anything about the details of it peddles this kind of snake oil about hardware accel. > I didn't know that H.261 was so CPU intensive... It's so CPU intensive that it ran on phones from 25 years ago ... So I guess we can add "power saving and longer battery life" to the list of pros for H.261, and reasons someone might deliberately choose to use it, even if other options are available! If we keep thinking, the list just keeps growing :) Ron From sslivinski@lifesize.com Sun Nov 24 00:18:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404A91AE03B for ; Sun, 24 Nov 2013 00:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bVytohbLa81 for ; Sun, 24 Nov 2013 00:18:06 -0800 (PST) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with SMTP id E76FB1ADFEC for ; Sun, 24 Nov 2013 00:18:05 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKUpG2NCFqdNp50LEEQq2BIKQ/YHoyN00G@postini.com; Sun, 24 Nov 2013 00:17:58 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Sun, 24 Nov 2013 02:10:32 -0600 From: Stefan Slivinski To: Ron , "rtcweb@ietf.org" Date: Sun, 24 Nov 2013 02:10:30 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7o4BmbvmEFNmkISO2UMCfmUphuHQACcv3Q Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E677C@ausmsex00.austin.kmvtechnologies.com> References: <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> <529057EB.3060704@bbs.darktech.org> <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com> <20131124064011.GK3245@audi.shelbyville.oz> In-Reply-To: <20131124064011.GK3245@audi.shelbyville.oz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 08:18:08 -0000 I'm not suggesting H.261 in software is going to consume less power than H.= 264 720p in hardware but apples to apples in terms of resolution it's unlik= ely software is going to come out ahead in very many architectures. It's not about changing the laws of physics, it's about cutting out what yo= u don't need. General purpose instruction sets don't necessarily map well = to every algorithm, not to mention these hardware acceleration engines can = put lots of on chip memory to limit how often they need to go to external m= emory, and generally speaking hardware acceleration engines run at much low= er clock speeds than their host processors. But don't take my word for it, intel and apple seem to think they saved pow= er: Comparison on hardware codec vs software codec http://software.intel.com/en-us/articles/power-benefits-using-intel-quick-s= ync-video-h264-codec-with-sorenson-squeeze apple: see: 'Fourth, there's battery life' http://www.apple.com/hotnews/thoughts-= on-flash/ -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron Sent: Saturday, November 23, 2013 10:40 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 On Sun, Nov 24, 2013 at 08:02:36AM +0200, Leon Geyser wrote: > If we fallback to a software H.261 encoder/decoder then will it really=20 > use so much CPU that devices will be unusable or the battery will=20 > deplete early? No, it won't. You're pretty much certain to get better battery life doing = software H.261 than hardware H.264 on all but the most retarded of architec= tures (ie. something with _no_ powersaving ability at all). And both of them pale into insignificance against the power your display wi= ll use. http://www.yosefk.com/blog/its-done-in-hardware-so-its-cheap.html tldr; something that take 100x more operations to perform _still_ takes ~1= 00x more operations to perform, and about the same amount of power, regardl= ess of whether it's run on a "custom processor" (aka 'hardware acceleration= ') or a general purpose processor (aka CPU). If you want it to actually go faster too, that will generally use MORE powe= r, not less. Ye cannae change the laws o' physics. Nobody who has actually measured this, or understands anything about the de= tails of it peddles this kind of snake oil about hardware accel. > I didn't know that H.261 was so CPU intensive... It's so CPU intensive that it ran on phones from 25 years ago ... So I guess we can add "power saving and longer battery life" to the list of= pros for H.261, and reasons someone might deliberately choose to use it, e= ven if other options are available! If we keep thinking, the list just keeps growing :) Ron _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From maikmerten@googlemail.com Sun Nov 24 01:12:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADE31AE108 for ; Sun, 24 Nov 2013 01:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7hZ1mtI4HkW for ; Sun, 24 Nov 2013 01:12:50 -0800 (PST) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 92AC11AE0D0 for ; Sun, 24 Nov 2013 01:12:50 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id m10so1631891eaj.12 for ; Sun, 24 Nov 2013 01:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ke2mFACgCh9HVI3u7T5ZQ5ExUd/PDUAhWOuOZLx+4MY=; b=P0POFjwbQ/YTB2jiLGnFoD2fZs5c4fm45p4TEpMyM1ljKvSpy5CDPvc4vtDysNUn0J M0ifTBrStN7SrK7hDjc80YWdZisjL7psFAhfq8yFkxw8plMkVqqJ4ZUijN3Yc6Xz25HS GVY872bu8h1g5xJG31e5QAZYhwccNpNyEhZUw6+xmwagUCBiZW0BnX1VVLMfagl616+4 3XYooGEt9heFKV8eR2Zj49yI/yz7kpHwrSpurQPwj8DwIPWlR8X6tRonx9M8zvfBCCwh Fa06ZmWS3YRdevWXwvx/trpT6mo0e5S7zBjV5ozd+H3HlT7AnX9prhhPcYrsqf+AGqVU aHwg== X-Received: by 10.14.119.136 with SMTP id n8mr41978eeh.82.1385284362217; Sun, 24 Nov 2013 01:12:42 -0800 (PST) Received: from [192.168.2.109] (port-92-201-154-215.dynamic.qsc.de. [92.201.154.215]) by mx.google.com with ESMTPSA id s3sm4012088ees.2.2013.11.24.01.12.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Nov 2013 01:12:40 -0800 (PST) Message-ID: <5291C305.1090302@googlemail.com> Date: Sun, 24 Nov 2013 10:12:37 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> <529057EB.3060704@bbs.darktech.org> <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 09:12:52 -0000 Am 24.11.2013 05:29, schrieb Stefan Slivinski: > What few seem to acknowledge is that companies like intel, TI, qualcomm, broadcom (just to name a few) have spent hundreds of millions (if not billions) of dollars adding hardware accelerate for H.264 to their chips. Purpose designed hardware will always be faster and require less power than software implementations and no one is spending anything supporting H.261 hardware acceleration. It appears that these hardware accelerators are usually not accessible to 3rd-party applications on mobile platforms (as has been discussed before). Even if they are they may not be consistent regarding available settings and performance. Can hardware accelerators, e.g., decode several incoming streams in parallel (honest question, I really don't know)? How does bitrate control of the embedded encoders behave? Do they offer options for error resilience etc. etc.? IIRC it has been confirmed on this list that Skype deploys H.264 in software across all platforms for such reasons. So clearly, the theoretical advantages of H.264 hardware support (which works nicely in media playback, no doubt) do clearly not transfer quite easily to real-time communication on consumer devices. Given that older codecs currently in discussion are much more frugal in terms of overall computation, deployments in software don't look especially intimidating. Maik From harald@alvestrand.no Sun Nov 24 08:39:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065C01AE2FD for ; Sun, 24 Nov 2013 08:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.825 X-Spam-Level: X-Spam-Status: No, score=-6.825 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3vRoSRJzQOO for ; Sun, 24 Nov 2013 08:39:41 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 71D0F1ADF46 for ; Sun, 24 Nov 2013 08:39:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF69A39E0E1 for ; Sun, 24 Nov 2013 17:39:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVYWu8673KJc for ; Sun, 24 Nov 2013 17:39:02 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AEAB939E070 for ; Sun, 24 Nov 2013 17:39:02 +0100 (CET) Message-ID: <52922BA1.6070805@alvestrand.no> Date: Sun, 24 Nov 2013 17:38:57 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <59A91D84-3D29-47C4-8688-CB60844B15D3@cisco.com> <24B2A6DE-958C-445C-BE77-8BD1661DC33D@cisco.com> In-Reply-To: <24B2A6DE-958C-445C-BE77-8BD1661DC33D@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 16:39:44 -0000 On 11/23/2013 01:20 AM, Paul Giralt (pgiralt) wrote: > On Nov 22, 2013, at 7:06 PM, Martin Thomson wrote: > >> On 22 November 2013 15:44, Paul Giralt (pgiralt) wrote: >>> While you’re right that it would work for this scenario, my point was really >>> that Offer/Answer is not really asymmetric as implied earlier. Take for >>> example the hypothetical case where you are only able to decode VP8 but only >>> able to encode H.264. If I offer VP8 as my only codec (because it’s the only >>> thing I’m able to decode therefore I never want anyone to send me anything >>> other than VP8) I cannot send H.264 in the offer because that implies I’m >>> able to decode it. The other side then wants to say it can only receive >>> H.264 so it would have to send back an answer with only H.264. I guess >>> there’s nothing really inherently stopping you from doing this because as >>> far as I can tell, 3264 only says the answer has to be a subset of the offer >>> for multicast streams, however how would the answering side know that the >>> offering side is even capable to receiving H.264? Perhaps Offer/Answer can >>> technically be asymmetric, but it doesn’t seem practical to use it this way >>> because you cannot really indicate your send and receive capabilities >>> independent of each other. >> Judicious application of a=sendonly or a=recvonly avoids this issue. >> If you want to send H.264, try a=sendonly on a line with H.264. If >> you want to receive VP8, try a=recvonly on a line with VP8. > I gave this as an example of a possible way to do it, but that means you need two separate m= lines - one for send and one for receive. Seems strange to do this for something that you really want to be a single bi-directional stream. An application that can't talk to itself is kind of bizarre too. I think this is a corner case. From fw@deneb.enyo.de Sun Nov 24 08:47:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7531AE2FD for ; Sun, 24 Nov 2013 08:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXg2ctppuMzM for ; Sun, 24 Nov 2013 08:47:09 -0800 (PST) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8EACA1AE3D5 for ; Sun, 24 Nov 2013 08:47:09 -0800 (PST) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1Vkcpo-0001cB-0m; Sun, 24 Nov 2013 17:47:00 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1Vkcpn-0001nQ-Lo; Sun, 24 Nov 2013 17:46:59 +0100 From: Florian Weimer To: Stefan Slivinski References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> Date: Sun, 24 Nov 2013 17:46:59 +0100 In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> (Stefan Slivinski's message of "Fri, 22 Nov 2013 19:42:45 -0600") Message-ID: <87zjot927w.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 16:47:12 -0000 * Stefan Slivinski: > Alright fast forward, Chrome adds H.261 but continues to use VP8. > IE uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox > does H.261, H.264 and VP8. So far so good. Chrome can talk using > VP8 to Firefox, Safari can talk H.264 to IE, Firefox can either > H.264 or VP8 to everyone. As long as Chrome users don't try to call > IE or Safari, we're in good shape, otherwise we need to transcode > using some undefined cloud based transcoder service or just use > H.261. Or use a WebRTC implementation which is written in Actionscript and thus has access to Chrome's existing H.264 support: I don't think availability of licensed H.264 implementations is a problem. It's just that the MPEG LA licensing conditions date back to the early 2000s and it's totally unclear how they'll translate to WebRTC application developers and commercial end users. (If you don't believe me, go and read Adobe's Flash Player 11 licensing agreement.) From harald@alvestrand.no Sun Nov 24 08:53:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D021ADFD0 for ; Sun, 24 Nov 2013 08:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.425 X-Spam-Level: X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y68tFX5urtUd for ; Sun, 24 Nov 2013 08:53:15 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3181ADFCB for ; Sun, 24 Nov 2013 08:53:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2B99539E09F for ; Sun, 24 Nov 2013 17:52:38 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DVKTX2IhjD1 for ; Sun, 24 Nov 2013 17:52:37 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1F41439E070 for ; Sun, 24 Nov 2013 17:52:37 +0100 (CET) Message-ID: <52922ED3.7070908@alvestrand.no> Date: Sun, 24 Nov 2013 17:52:35 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <528E39F4.4010706@ericsson.com> <528E5AF7.5080403@alvestrand.no> In-Reply-To: <528E5AF7.5080403@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video Selection Process) X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 16:53:17 -0000 On 11/21/2013 08:11 PM, Harald Alvestrand wrote: > Forking this thread, and leaving aside all consideration of whether > the IETF should do voting, whether the electorate is the right > electorate for the decision and so on: > > I wonder if Instant Runoff is the right choice for this situation. > Instant Runoff means that when you don't get a majority for anything, > you drop the lowest-ranked candidate and distribute the ballots that > had this as their #1 across the other candidates. > > This has the property that in a polarized situation, compromises may > get dropped out of the running before the alternatives that they might > serve as a compromise between. > > In this case, I'd favour a Condorcet-compatible method, such as > Schulze; it provides the guarantee that if a choice is preferred by a > majority of the participants over every other choice, it will always > be chosen. > > http://en.wikipedia.org/wiki/Condorcet_method#Schulze_method I haven't seen much response to this - except pointing out that no voting method is perfect - but I really think the issue of Condorcet vs IRV matters in this case. We have two strong camps who have a clear preferred choice, and we have some possible compromises. Me being the compromising type, I think we might be better off with a compromise than one of the strong camps' preferences. Let's imagine, for a moment, that the options are: A: Codec A B: Codec B C: At least one of Codec A and B If the distribution is like this: A proponents (40%): A C B B proponents (40%): B C A Compromisers group 1 (5%): C A B Compromisers group 2 (15%): C B A Then under IRV, the first round will go 40/40/20, alternative C will be eliminated, and B will be chosen. Under Condorcet, the outcomes will be: - A outranks B on 55% - C outranks A on 60% - C outranks B on 60% Therefore, C is a Condorcet winner. IRV is less likely to lead to a second-ranked compromise that everyone can live with than Condorcet. From fw@deneb.enyo.de Sun Nov 24 09:04:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222BB1ADFAC for ; Sun, 24 Nov 2013 09:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiAvyH9UuSmt for ; Sun, 24 Nov 2013 09:04:55 -0800 (PST) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7A36A1ADF0F for ; Sun, 24 Nov 2013 09:04:55 -0800 (PST) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1Vkd6x-0001gJ-Jq; Sun, 24 Nov 2013 18:04:43 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1Vkd6x-0001uG-Fv; Sun, 24 Nov 2013 18:04:43 +0100 From: Florian Weimer To: Eric Rescorla References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <20131123013935.6690a07a@rainpc> <529009A0.5050708@nostrum.com> <20131123120816.0bc16a75@rainpc> <52910465.8010205@nostrum.com> <20131123215300.4fd6e2c3@rainpc> Date: Sun, 24 Nov 2013 18:04:43 +0100 In-Reply-To: (Eric Rescorla's message of "Sat, 23 Nov 2013 13:12:19 -0800") Message-ID: <87pppp91ec.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 17:04:57 -0000 * Eric Rescorla: > Seriously? May I ask whether you have read the summary terms at: > http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf > > They seem relatively clear on this point: > "(a decoder, encoder, or product consisting of one decoder and one encoder > =3D =E2=80=9Cunit=E2=80=9D)" > > More importantly, do you seriously think anyone would license H.264 for > a product if you had to pay $.10 every time the product started up. It's unclear if a WebRTC application that is distributed on demand would fall into that category if it is capable of using H.264. The MPEG LA licensing scheme was devised when this kind of use was not common. Also note the lack of reference to mobile devices. It's also not clear what kind of license commercial use of H.264-based WebRTC applications by end users would need. They don't fall into either of the top-level category. (The fact that MPEG LA is apparently not structured in a way that enables it to grant clearcut licenses to commercial users of videoconferencing solutions doesn't mean they are exempted from obtaining licenses.) From partha@parthasarathi.co.in Sun Nov 24 11:14:05 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3141AE3DE for ; Sun, 24 Nov 2013 11:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.803 X-Spam-Level: * X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91hN6wtr8J29 for ; Sun, 24 Nov 2013 11:14:03 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.233]) by ietfa.amsl.com (Postfix) with ESMTP id 853081AE1E4 for ; Sun, 24 Nov 2013 11:14:03 -0800 (PST) Received: from userPC (unknown [122.179.42.105]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 51CCB63900B; Sun, 24 Nov 2013 19:13:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1385320435; bh=RjnIF98IT01qROIt634JBuzec7iqaYv59P88Mf9EE2c=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ll35kp5SuoXlp3H0adXd8rJQKA/L97nSzwPIR0g/yNeHwOvqQqWIQB0Xvw8BDdMDE 6Fia9YYZe5X/cd35bV6jqzcwOEjy5yiR5h+rmDJFufqkODi3PmVidJOY/AjuASpgCq IXI2ARaDTZk5i2SnRyd5cZr2reQbOxQOjVf1AvKo= From: "Parthasarathi R" To: "'Harald Alvestrand'" , References: <528E39F4.4010706@ericsson.com> <528E5AF7.5080403@alvestrand.no> <52922ED3.7070908@alvestrand.no> In-Reply-To: <52922ED3.7070908@alvestrand.no> Date: Mon, 25 Nov 2013 00:43:50 +0530 Message-ID: <002d01cee949$51a4c3c0$f4ee4b40$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7pNarl0lwzuXaFTfmrWqEuKd8p9QACLErA Content-Language: en-us X-CTCH-RefID: str=0001.0A020208.52924FF3.00EA, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.100 X-CTCH-Rules: SUBJECT_NEEDS_ENCODING, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video Selection Process) X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 19:14:05 -0000 Hi Harald & all, IMO, The fundamental problem with these methods (Condorcet & IRV) is that they are designed to find the winner out of the discrete candidates (A, B, C) in mind whereas the candidates in this voting is of combination of discrete and set nature (A, B, (A & B), (A | B)). I like to see the proof whether the above methods (Condorcet & IRV) are really designed to bring the correct winner in these set of candidates as well. I can show how your example of Condorcet fail with (A|B) is as follows: The candidates are A,B, (A|B) A: Codec A B: Codec B A|B: At least one of Codec A and B If the distribution is like this: A proponents (40%): A A|B B proponents (40%): B A|B Compromisers group 1 (5%): A|B A Compromisers group 2 (15%): A|B B Then under IRV, the first round will go 40/40/20, alternative A|B will be eliminated, and B will be chosen with 55 as A has 45 only in the second round. Under Condorcet, the outcomes will be: - A outranks B on 55% - B outranks A on 45% - A|B outranks A on 60% - A|B outranks B on 60% Therefore, A|B is a Condorcet winner and election is successful. In reality, the original winner is B and compromisers group 2 which is interested only in implementing B which has 55% supporter. Also, A and Compromisers group 1 is interested only in implementing A which is 45%. So, Condorcet winner is not required to be correct in case A|B, A&B candidates exists in the election. Having said that, I agree with you that IVR is also not required to yield correct election result in case A&B, A|B candidates exists. As of now as I mentioned in http://www.ietf.org/mail-archive/web/rtcweb/current/msg10113.html, the election result may leads to the situation of "the operation was a success but the patient died". Please let me know your opinion on the same. Thanks Partha > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > Alvestrand > Sent: Sunday, November 24, 2013 10:23 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video > Selection Process) > > On 11/21/2013 08:11 PM, Harald Alvestrand wrote: > > Forking this thread, and leaving aside all consideration of whether > > the IETF should do voting, whether the electorate is the right > > electorate for the decision and so on: > > > > I wonder if Instant Runoff is the right choice for this situation. > > Instant Runoff means that when you don't get a majority for anything, > > you drop the lowest-ranked candidate and distribute the ballots that > > had this as their #1 across the other candidates. > > > > This has the property that in a polarized situation, compromises may > > get dropped out of the running before the alternatives that they > might > > serve as a compromise between. > > > > In this case, I'd favour a Condorcet-compatible method, such as > > Schulze; it provides the guarantee that if a choice is preferred by a > > majority of the participants over every other choice, it will always > > be chosen. > > > > http://en.wikipedia.org/wiki/Condorcet_method#Schulze_method > > I haven't seen much response to this - except pointing out that no > voting method is perfect - but I really think the issue of Condorcet vs > IRV matters in this case. > > We have two strong camps who have a clear preferred choice, and we have > some possible compromises. Me being the compromising type, I think we > might be better off with a compromise than one of the strong camps' > preferences. > > Let's imagine, for a moment, that the options are: > > A: Codec A > B: Codec B > C: At least one of Codec A and B > > If the distribution is like this: > > A proponents (40%): A C B > B proponents (40%): B C A > Compromisers group 1 (5%): C A B > Compromisers group 2 (15%): C B A > > Then under IRV, the first round will go 40/40/20, alternative C will be > eliminated, and B will be chosen. > Under Condorcet, the outcomes will be: > > - A outranks B on 55% > - C outranks A on 60% > - C outranks B on 60% > > Therefore, C is a Condorcet winner. > > IRV is less likely to lead to a second-ranked compromise that everyone > can live with than Condorcet. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From partha@parthasarathi.co.in Sun Nov 24 11:18:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BA41AE1D7 for ; Sun, 24 Nov 2013 11:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.103 X-Spam-Level: ** X-Spam-Status: No, score=2.103 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zH78j3VSe2Z for ; Sun, 24 Nov 2013 11:18:29 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCE81AE1C1 for ; Sun, 24 Nov 2013 11:18:28 -0800 (PST) Received: from userPC (unknown [122.179.42.105]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 5E91E638FF1; Sun, 24 Nov 2013 19:18:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1385320700; bh=CJ6OmD1HxcZkIMLB4Y+8vw7jPax0U+wgeGPXisysYis=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cHyJQHka9CggC5ksZH812/ob7YuxCunVYfVVR3jGmVx5kTegQjkHCSfgNrwDA0hgD 3ishfspg3ZohT9GU4yUW93rgNc4XFxdanjyouheQ1sv8DVmNhrr9kTI/ZP0TH6mhVA /LilxsBN2U25WnxEc2jr3ELeEPIDHASl3rrbecQ8= From: "Parthasarathi R" To: =?iso-8859-1?Q?'Herv=E9_W.'?= , "'Emil Ivov'" , "'Peter St Andre, \(stpeter\)'" References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>, , <01c101cee7e7$88f12610$9ad37230$@co.in> In-Reply-To: Date: Mon, 25 Nov 2013 00:48:13 +0530 Message-ID: <002f01cee949$ef6967f0$ce3c37d0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7n6sL8Tc1ouiH/TOCvMapu8hA3WwBXrwuQ Content-Language: en-us X-CTCH-RefID: str=0001.0A020208.529250FC.005D, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.100 X-CTCH-Rules: SUBJECT_NEEDS_ENCODING, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 2 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] IETF will fail to implement Video codec MTI after election? [was RE: Proposed Video Selection Process] X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 19:18:30 -0000 Herve, I mailed in the another mail thread why Condorset fails for the given candidates with detailed example. Please let me know your opinion on the same. Thanks Partha > -----Original Message----- > From: Herv=E9 W. [mailto:h_o_w_@hotmail.com] > Sent: Saturday, November 23, 2013 6:55 AM > To: Parthasarathi R; 'Emil Ivov'; 'Peter St Andre, (stpeter)' > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] IETF will fail to implement Video codec MTI = after > election? [was RE: Proposed Video Selection Process] >=20 > ________________________________ > > From: partha@parthasarathi.co.in >=20 >=20 > > As the multiple codec alternative (candidate) exists and kind of > > implicit coalition[1] allowed by IRV election mechanism, it is > possible > > for less than 50% folks supported codec alternative as a first > > preference will be selected as point in > > http://en.wikipedia.org/wiki/Instant-runoff_voting first example. = How > > this mechanism helps to achieve the better interop in the internet > > which is our ultimate aim? >=20 > Would you find a Condorset method more acceptable? Harald Alvestrand > suggested that. > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09928.html >=20 > > Note 1: Implicit coalition =96 2nd preference will become the = voters > > choice after the 1st preference is eliminated >=20 >=20 > - Herv=E9 =3D From cowwoc@bbs.darktech.org Sun Nov 24 11:24:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C711AE1E4 for ; Sun, 24 Nov 2013 11:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtfWZe37YVGF for ; Sun, 24 Nov 2013 11:24:19 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAC01AE070 for ; Sun, 24 Nov 2013 11:24:19 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so5436137iec.5 for ; Sun, 24 Nov 2013 11:24:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=z0OQ43PIpQsu5XwXwuTMiDJvleeqgiph2toh6jT63mU=; b=XpHInjMNJDnRGN2nMYoc2zttF9g32dF2ExQ+D5+onNIlf5WPzHW1PWiv08b9JT7D/L dacrxU6IjCFgTz5jpXAYGVTWkl/m8blX1SvfBp2IS81NANVuWC4FfIY96o0xQ7AYtBUe 8rr7L+nfuK1EDuabmgqdRbjGY15jWDU1oT6XtSeqJymi/6AwHWxWE/lut7QMLUE/IBX9 I7t8XqeKkg5k2YoFWhdFFXaQVyrlPl+wIA8sKBjLPyMTTH29RO2lvQermJvJeD/F/9Yn r4xTd3vpdFHx6sxKJxhvNF+icTReoFFXCBLcwFfSOUJw3apg49TBJ1nHUNMq3OdPvmSc if2w== X-Gm-Message-State: ALoCoQnFLHbP2KQcL3L1V3Di6ZKllBlStXqUQWyNanXrxUxi5bL1WW/2KgUdc8mdMHb0Yq+X08oW X-Received: by 10.43.17.196 with SMTP id qd4mr40000icb.44.1385321051148; Sun, 24 Nov 2013 11:24:11 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id i11sm21446938igh.0.2013.11.24.11.24.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Nov 2013 11:24:10 -0800 (PST) Message-ID: <52925239.1000807@bbs.darktech.org> Date: Sun, 24 Nov 2013 14:23:37 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FC497.2080804@googlemail.com> <528FEC5A.8060701@librevideo.org> <7C4C4F47-1F9B-4A69-AE68-122DE394E203@apple.com> <52911AC5.3090408@gmail.com> <20131124013400.GI3245@audi.shelbyville.oz> In-Reply-To: <20131124013400.GI3245@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 - taking a longer view of things X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 19:24:21 -0000 While I am in favor of most of your arguments, I disagree that anything we mandate should be forever. It might make sense to maintain backwards compatibility for 5 years or so, but past that point all bets are off (I'd drop the deprecated codecs). Backwards-compatibility should not last forever, especially now that most applications auto-update themselves. Practically speaking that means that WebRTC 2.0 would be backwards compatible with 1.0, but 3.0 would not be. Gili On 23/11/2013 8:34 PM, Ron wrote: > On Sat, Nov 23, 2013 at 10:14:45PM +0100, Daniel-Constantin Mierla wrote: >> On 11/23/13 12:46 AM, David Singer wrote: >>> No, I think we all want an MTI codec. But not at any price in terms >>> of quality degradation, and H.261 may be simply off the bottom end. >> This is the last resort if one doesn't have a better alternative. I >> doubt people that really like wide band audio codecs don't use >> mobile phones on 2G/GSM which is quite poor audio experience, but >> when you are on top of mountains or remote locations is the only >> option. > Actually, it's much more than that. This is going to be the codec > of last resort "forever". Think about that. Think hard. I'll wait. > > Unless we are going to resign ourselves to this whole standard being > a bad joke, that will be discarded in a few short years time, with > all the work that has gone into it needing to be repeated *again*, > then this specification is going to vastly outlive any codec that > happens to be flavour of the month today. > > Which means long after H.264 has fallen out of favour and stopped > being included in hardware and "legacy devices", and possibly during > that fun period where people screw up the royalty rates hard to get > people to move on to H.265 or whatever the next revenue raiser will > be, implementations of this standard would still need to carry that > dead baggage. Forever. > > Let's take a quick look at how that might compare: > > > For the RM8 implementation of H.261: > > p64dir$ sloccount . > Total Physical Source Lines of Code (SLOC) = 6,707 > > For x264 (from git a few minutes ago): > > x264$ sloccount . > Total Physical Source Lines of Code (SLOC) = 89,663 > > > One of these has been 'stable' since 1995. The other is still fixing > several bugs a month, even as we speak. > > One of these will still be a standard applicable to the PSTN for as > long as it continues to be around (just like G.711). The other will > be consigned to the dusts of history with H.262 and H.263, probably > well before vinyl records are. > > > H.265 is already out. VP9 is nearly already out. Daala is going > to kick all of their asses like Opus did ... > > These are the codecs that people are _actually_ going to use by the > time this standard is actually completed and well established. > > > So remind me again why we want to take all of the obvious pain today > to mandate a codec that will also be orders of magnitude more pain > in perpetuity? Who wants to still be fixing security bugs in H.264 > in 2020? When people have long since stopped actually using or > testing it. > > Yes, H.261 is not quite as trivial as G.711, but compared to H.264 > it's near enough. It was designed to run on 'computers' made of > snot and matchsticks and rubber bands. If we are going to burden > ourselves with having to carry an obsolete codec forever, whatever > we do -- then maybe there actually is a genuine argument that H.261 > is not just a compromise we'll all hate, but it could in fact be, > when all things are considered, a clearly superior choice in its > own right for the MTI fallback of last resort. > > Shocking I know. > > But I guess that's what happens when you take a step back from > short sighted, short term, "best for me today" considerations > and look at the big picture here. > > > I cordially invite everyone else to do the same :) > > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From partha@parthasarathi.co.in Sun Nov 24 11:29:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC831AE031 for ; Sun, 24 Nov 2013 11:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.803 X-Spam-Level: * X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZJ_BEr4vCij for ; Sun, 24 Nov 2013 11:29:38 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8091ADF6A for ; Sun, 24 Nov 2013 11:29:38 -0800 (PST) Received: from userPC (unknown [122.179.42.105]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 57B616381AC; Sun, 24 Nov 2013 19:29:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1385321370; bh=YmM5+i9LJFGdcZZwktWmvqaqw4hvNrz1ovoe3lvzGxE=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ASTi30fFqoQ7JVXfSgYmfwJas/ksQQUonjA3zIwP/gvBkIe8W76L50WcSgnZQ5y38 /dhVxMEDn+3FInF6XCMNgKmp7P8brYDuZ3ROmS0qwI9gOP+xxWm2gqnp7uiH2vT/ZO I9xyMwVuBiXa6oVToPWPusvYJXZ3aALwOAAq84kY= From: "Parthasarathi R" To: "'Gregory Maxwell'" , References: In-Reply-To: Date: Mon, 25 Nov 2013 00:59:26 +0530 Message-ID: <003101cee94b$7ef72c30$7ce58490$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7n6gyYeJVMEIV/Qb2sysYF5iwLZQBYCjcg Content-Language: en-us X-CTCH-RefID: str=0001.0A020208.5292539A.0062, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.100 X-CTCH-Rules: SUBJECT_NEEDS_ENCODING, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Subject: Re: [rtcweb] IETF will fail to implement Video codec MTI after election? [was RE: Proposed Video Selection Process] X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 19:29:39 -0000 Gregory, Please consider the situation like couple of browser vendors don't = complies with MTI or delay the chosen MTI for 3-5 years. Thanks Partha > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Gregory > Maxwell > Sent: Saturday, November 23, 2013 6:49 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] IETF will fail to implement Video codec MTI = after > election? [was RE: Proposed Video Selection Process] >=20 > On Fri, Nov 22, 2013 at 5:01 PM, Parthasarathi R > wrote: > > I agree with Emil & Peter that voting will not help to achieve Video > codec > > MTI in the industry. Let us assume that codec x is selected as per > the > > election result. Why should the opposite camp browser vendor or > WebRTC > > gateway/conference vendor *MUST* implement the specified codec x for > the > > sake IETF compliance? >=20 > In some markets being able to respond "Complies" to an RFP requirement > for a particular RFC is commercially significant. >=20 > It is also not unlikely that there is a great swath of "will do the > minimum necessary" implementers=E2=80=94 outside of the big name = vendors=E2=80=94 who > will tend to just do as the spec requires. So the decision here > determines what code licensing/exposure will be required to interop > with those parties. >=20 > There are also a number of other reasons parties may care. >=20 > And, as you can observe, many people do care. If it really was > irrelevant you wouldn't see all of this noise. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cowwoc@bbs.darktech.org Sun Nov 24 11:32:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084651AE081 for ; Sun, 24 Nov 2013 11:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo4UgTt7m09O for ; Sun, 24 Nov 2013 11:32:11 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0351ADF6A for ; Sun, 24 Nov 2013 11:32:11 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar20so5352421iec.2 for ; Sun, 24 Nov 2013 11:32:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+4d1l1/iDMb4n2XPZdbJQJ/JW492DSjK1XsEPQAvO/E=; b=bOzeRyK4XAQQVDJ8nyRZUvGcQoHHiEqjD5TUUtPh+6FHhwhwG+Bo/AzCtDhRoonyJW Ru8u2sZ81AwLrE0peWLIaMa42wIK8OGQGnIVbkDQmIbpzRxZZM/MmRIuuH0RiyDttTGr SzWL996Sl4Ik5QRW2DTCR25/tdotq1G5WvKXesrRFdb09hPbpaDcAv0vRRDG5ipEtC4p T4mZb3K/hOh8b7uhODSaGoKZOQHuYCqiX5FWWe+t4n+GvM1XA1Vq5bo9d1X+0nIzWjk5 JJsL2D2u82Ysu7Gd/tQBdOKW3WK/j2en+kHu1EVG0m6cYF6s7n+0X+GdP7Oe39FhVUrD pH3g== X-Gm-Message-State: ALoCoQnguJSxI6qs7kfijhh579PAHZ5Ac8NVcbiw8abBxzby49C87vC21X3c0Sy55wJKL0LwUvlL X-Received: by 10.50.85.115 with SMTP id g19mr10334055igz.1.1385321523631; Sun, 24 Nov 2013 11:32:03 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id m1sm21433288igj.10.2013.11.24.11.32.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Nov 2013 11:32:02 -0800 (PST) Message-ID: <52925412.8030006@bbs.darktech.org> Date: Sun, 24 Nov 2013 14:31:30 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E671A@ausmsex00.austin.kmvtechnologies.com> <528FC513.4020903@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E6731@ausmsex00.austin.kmvtechnologies.com> <52905257.1060209@bbs.darktech.org> <20131123190457.GG3245@audi.shelbyville.oz> In-Reply-To: <20131123190457.GG3245@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Opinions are fine, bypassing a vote is not X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 19:32:13 -0000 Eric, Just so there is no confusion: if you manage to convince us that X is "strictly better" than H.261 then I'd jump on board. I was trying to explain that many people are trying to remove H.261 as an option by explaining how bad it is. Going down this road won't change our minds because we already agree that it is a shitty codec. The only way to convince us that X is "strictly better" than H.261 is to talk about X (not H.261) and demonstrate that it meets our IPR requirements. Do that, and you will have my vote (and probably that of others). Kind regards, Gili On 23/11/2013 2:04 PM, Ron wrote: > On Sat, Nov 23, 2013 at 06:59:14AM -0800, Eric Rescorla wrote: >> I would like to push back on this a bit. Say that we had general consensus >> that Theora was strictly better than H.261. > Do you think that such a consensus might actually exist? > > It seems fairly obvious to me that Theora would be a better choice than > H.261, but I haven't seen any indication that it wouldn't be subject to > exactly the same FUD that VP8 has. Is my impression wrong about that? > > If it's not, then H.261 _does_ have the advantage of its IPR and licencing > situation being far less controversial - dare I say near to irrefutable? > > I'd be willing to entertain a consensus call on the idea that Theora was > considered _strictly_ better than H.261 here. And happy to be proven > wrong in this case. > > >> I'm already pretty sad about all the options > amen. > >> and I don't think it's bad to winnow the field if there is near-unanimity >> on something.... > I agree. I'm likewise disappointed that your repeated hints about the > troubles of voting for a field filled with many questionable options > seems to have been lost in the noise. > > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cowwoc@bbs.darktech.org Sun Nov 24 11:43:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0C41AE116 for ; Sun, 24 Nov 2013 11:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh2coqyQUQQb for ; Sun, 24 Nov 2013 11:43:25 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id D7D041ADFF5 for ; Sun, 24 Nov 2013 11:43:24 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so5329772ieb.8 for ; Sun, 24 Nov 2013 11:43:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=e0OsGsFGNcYUbRq1SD5qrGxKmhR4PczzjzYPbLXmBP0=; b=E6yy8ZvxSg1la+VgqSMIYCokFDSSuAzowJpqKP0duAf7k1S2DoqK/AAUaknUnimOAm q4CbmLzr8mc04Rci7fM2Ct8qXXjibvWV9V0/mM11kVtvqgAjvYTpk3UNlytpJutconQ5 KmC7bKaG6PpsDc3yh0kRJq/WkhVOphxt3t8E0CxgBxHkIK6MVWnUyreZAOAyYFcjI0qn +UxgQoqO0z+A+kBAuJyczUNsqDd25Jju+XmxEMiRaLZMB6NmUOKPRdtf9sHCgtiqwklI Orlvu8lfR33GGxgvAZX8FqvYQFTXK+yEXqGre8jr4/+Mm8sia3CWZajfmFW5lOee5tQF cWmA== X-Gm-Message-State: ALoCoQkyBMrZNcHZlI/DMm/Y+4v49/G+bg2A73j84fL5QwP7/2Td+UMnnMnPSYAo2NLYURxuv1Xv X-Received: by 10.50.17.100 with SMTP id n4mr10321370igd.11.1385322196925; Sun, 24 Nov 2013 11:43:16 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ft2sm22174432igb.5.2013.11.24.11.43.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Nov 2013 11:43:16 -0800 (PST) Message-ID: <529256B3.7000202@bbs.darktech.org> Date: Sun, 24 Nov 2013 14:42:43 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stefan Slivinski , "rtcweb@ietf.org" References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> <529057EB.3060704@bbs.darktech.org> <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 19:43:27 -0000 Stefan, You are beating a dead horse. No one is arguing that H.261 is technically superior to H.264. I'll repeat what I just posted on another thread: Just so there is no confusion: if you manage to convince us that X is "strictly better" than H.261 then I'd jump on board. I was trying to explain that many people are trying to remove H.261 as an option by explaining how bad it is. Going down this road won't change our minds because we already agree that it is a shitty codec. The only way to convince us that X is "strictly better" than H.261 is to talk about X (not H.261) and demonstrate that it meets our IPR requirements. Do that, and you will have my vote (and probably that of others). Gili On 23/11/2013 11:29 PM, Stefan Slivinski wrote: > I don't want to make any assumptions as to why their particular use case failed at 20+ participants. Maybe it was bandwidth related, maybe it was because intel quicksync doesn't support VP8. I don't know and I'm not going to speculate. What I do know is intel quicksync is capable of decoding H.264 at 4K without breaking a sweat. 4K is more than 80x (yes, eighty times) the resolution of H.261. So H.261 isn't likely to have helped them here. > > What few seem to acknowledge is that companies like intel, TI, qualcomm, broadcom (just to name a few) have spent hundreds of millions (if not billions) of dollars adding hardware accelerate for H.264 to their chips. Purpose designed hardware will always be faster and require less power than software implementations and no one is spending anything supporting H.261 hardware acceleration. > > H.261 does not have any technical advantage whether it be bitrate, performance, power consumption or otherwise over H.264 on any modern media processor > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc > Sent: Friday, November 22, 2013 11:23 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > Stefan, > > At the conference, they mentioned that you cannot implement online video classes (with 20+ participants) unless you reduce the resolution and frame rate of non-speakering participants. Meaning, even without having to do any transcoding (they use VP8 across the board) there is insufficient bandwidth and CPU to handle 20 incoming video streams at HD resolutions. So what you do is host non-speakers at tiny resolutions and > 3 fps. > > H.261 could handle those non-speakers just fine (in fact, it would be preferable as it reduces CPU usage). Furthermore, if you chose to transcode, you'd be dealing with tiny resolutions and 3fps. In both cases, the use of H.261 or transcoding is not the bottleneck. > > Gili > > On 22/11/2013 8:42 PM, Stefan Slivinski wrote: >> Just for fun, let's play out the H.261 scenario as the great savior of webrtc that some claim it is: >> >> Let's say through some divine miracle we manage to all agree to make H.261 the one and only MTI codec. The rationale being of course that no one will ever use it because it is of course terrible, but we need it to get around those pesky patent/license terms with VP8/H.264 respectively. >> >> Alright fast forward, Chrome adds H.261 but continues to use VP8. IE uses H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, H.264 and VP8. So far so good. Chrome can talk using VP8 to Firefox, Safari can talk H.264 to IE, Firefox can either H.264 or VP8 to everyone. As long as Chrome users don't try to call IE or Safari, we're in good shape, otherwise we need to transcode using some undefined cloud based transcoder service or just use H.261. >> >> So we're still in good shape. Now let's consider the multiway case. I heard a use case at the conference on Tuesday where a university was using webrtc to enable video online classes. So let's assume there are 20 people in the class. 19 people in the class love Chrome, so they join the class from chrome and are all sending each other VP8. But of course there's always one person that has to be difficult and they decide they prefer IE. So what now? Well the IE person doesn't understand any of the 19 VP8 streams and the 19 chrome users don't understand the 1 H.264 stream. So we can now utilize that same undefined cloud transcoding service to convert each of the 19 VP8 streams to H.264 and the 1 H.264 stream to VP8....or we can use H.261. >> >> My guess is H.261 is going to get used a lot more than anyone thinks. >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach >> Sent: Friday, November 22, 2013 5:37 PM >> To: Ron; rtcweb@ietf.org >> Subject: Re: [rtcweb] H.261 >> >> On 11/22/13 18:35, Ron wrote: >>> The whole point of many distros is to supply binaries, often built >>> many times for many different system architectures. >> And the overwhelming majority of these do so by including a list of repositories from which the binaries can be downloaded. >> >> I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, and whatever else is needed for these distros, targeting whatever platforms are required. Now, whether we can get the distro maintainers to add a single line to their list of repos -- because that's all it would take -- is a different issue. But at that point, it's just a matter of the distro maintainers being intransigent rather than any real technical or legal barrier. >> >> /a >> _______________________________________________ >> 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 From harald@alvestrand.no Sun Nov 24 14:02:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6291AE374 for ; Sun, 24 Nov 2013 14:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.425 X-Spam-Level: X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMaqPWpNiAry for ; Sun, 24 Nov 2013 14:02:16 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE221AE1B8 for ; Sun, 24 Nov 2013 14:02:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4397639E562; Sun, 24 Nov 2013 23:02:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZw7be2bxK3E; Sun, 24 Nov 2013 23:02:08 +0100 (CET) Received: from [172.30.42.84] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A8F5039E3C2; Sun, 24 Nov 2013 23:02:08 +0100 (CET) Message-ID: <5292775F.6020600@alvestrand.no> Date: Sun, 24 Nov 2013 23:02:07 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Parthasarathi R , rtcweb@ietf.org References: <528E39F4.4010706@ericsson.com> <528E5AF7.5080403@alvestrand.no> <52922ED3.7070908@alvestrand.no> <002d01cee949$51a4c3c0$f4ee4b40$@co.in> In-Reply-To: <002d01cee949$51a4c3c0$f4ee4b40$@co.in> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video Selection Process) X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 22:02:17 -0000 On 11/24/2013 08:13 PM, Parthasarathi R wrote: > Hi Harald & all, > > IMO, The fundamental problem with these methods (Condorcet & IRV) is that > they are designed to find the winner out of the discrete candidates (A, B, > C) in mind whereas the candidates in this voting is of combination of > discrete and set nature (A, B, (A & B), (A | B)). I like to see the proof > whether the above methods (Condorcet & IRV) are really designed to bring the > correct winner in these set of candidates as well. > > I can show how your example of Condorcet fail with (A|B) is as follows: The > candidates are A,B, (A|B) Question: Why do you consider choosing A|B a fail, given that you give exactly the same preference numbers under which I consider this position a reasonable outcome? The Condorcet winner will always beat each other candidate if no other candidate is present (except in the case of a loop). With your numbers, A|B is preferred over A, and A|B is preferred over B, so why is choosing A|B a fail? -- Surveillance is pervasive. Go Dark. From singer@apple.com Sun Nov 24 15:29:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218271AE256 for ; Sun, 24 Nov 2013 15:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.427 X-Spam-Level: X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz_Uoom5aAxO for ; Sun, 24 Nov 2013 15:28:58 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id BA3941AE242 for ; Sun, 24 Nov 2013 15:28:58 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWS00GPJJVDPUM0@mail-out.apple.com> for rtcweb@ietf.org; Sun, 24 Nov 2013 15:28:40 -0800 (PST) X-AuditID: 11807158-b7efa6d000002d28-e4-52928ba8c8cf Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id EC.40.11560.8AB82925; Sun, 24 Nov 2013 15:28:40 -0800 (PST) Received: from [17.153.22.142] (unknown [17.153.22.142]) by chive.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWS00FKFJVRYW30@chive.apple.com> for rtcweb@ietf.org; Sun, 24 Nov 2013 15:28:40 -0800 (PST) From: David Singer In-reply-to: <52911A02.6020209@gmail.com> Date: Sun, 24 Nov 2013 15:28:39 -0800 Content-transfer-encoding: quoted-printable Message-id: <95BC0BDD-AEE1-4C57-8D0C-38FB0C70A903@apple.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <52911A02.6020209@gmail.com> To: miconda@gmail.com X-Mailer: Apple Mail (2.1822) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FDMr7uie1KQwZQTEhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9/1L4wF21kq1r2dzNjAeJS5i5GTQ0LAROLEjv9QtpjEhXvr 2boYuTiEBLqZJN5OWMQE4cxmklj0rgMow8HBLKAncf+iFkgDL5B5q/k+WLOwgLTElkt3GUFs NgFViQdzjoHZnAKaErd/3mcDsVmA4n9OzGABsZkFXCSWtX5ih7C1JZ68u8AKMdNG4uSM72C2 kMBRVonZP21AbBEBUYnX72czQRwqK7H7+XfmCYwCsxAumoXkollIpi5gZF7FKFCUmpNYaaqX WFCQk6qXnJ+7iREcdoUROxj/L7M6xCjAwajEw2tROSlIiDWxrLgy9xCjBAezkgjvnjqgEG9K YmVValF+fFFpTmrxIUZpDhYlcV7++AlBQgLpiSWp2ampBalFMFkmDk6pBsY182/x922SnVL0 cdd+k6wJ7W+kZsydnDl15qPtKVp/nGYVG+t3BU3el1R8VEL6l1eYvqQC06arz+dl/vLXU1ns V/tXvv1hxMVH2122rDyQ0Mj17NQznai6Fa571ifvE86V3JZRyMLh/OfKZOmc2hOxPIZxEq4s PN2nfXlborU0bpmdVzFrn67EUpyRaKjFXFScCABB120XNwIAAA== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Sun, 24 Nov 2013 23:29:00 -0000 On Nov 23, 2013, at 13:11 , Daniel-Constantin Mierla = wrote: > That would require to have also smart phones shipped with a compiler = and all build dependencies/libraries. Anyhow, most of distros ship = binary packages. >=20 If you want a binary package, then Cisco is supplying. If you want to = compile it yourself, you=92re not required by any license I know to = compile on the same platform as use=85and as you note, that would be = unusual for some platforms. David Singer Multimedia and Software Standards, Apple Inc. From ron@debian.org Sun Nov 24 16:45:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220FB1AE308 for ; Sun, 24 Nov 2013 16:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li3TBySvNTlc for ; Sun, 24 Nov 2013 16:45:08 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7781AE2EC for ; Sun, 24 Nov 2013 16:45:07 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail05.adl6.internode.on.net with ESMTP; 25 Nov 2013 11:14:58 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 62AA24F8F3 for ; Mon, 25 Nov 2013 11:14:55 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rYDjWiYfCaQf for ; Mon, 25 Nov 2013 11:14:54 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 8C0C54F902; Mon, 25 Nov 2013 11:14:54 +1030 (CST) Date: Mon, 25 Nov 2013 11:14:54 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131125004454.GL3245@audi.shelbyville.oz> References: <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FC497.2080804@googlemail.com> <528FEC5A.8060701@librevideo.org> <7C4C4F47-1F9B-4A69-AE68-122DE394E203@apple.com> <52911AC5.3090408@gmail.com> <20131124013400.GI3245@audi.shelbyville.oz> <52925239.1000807@bbs.darktech.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52925239.1000807@bbs.darktech.org> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 - taking a longer view of things X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 00:45:10 -0000 On Sun, Nov 24, 2013 at 02:23:37PM -0500, cowwoc wrote: > While I am in favor of most of your arguments, I disagree that > anything we mandate should be forever. I'm not arguing that it _should_ be. I'm explaining that, empirically, unless this standard is a complete and utter failure, it absolutely _will_ be. Successful standards are forever. RFC 791 is a diamond. It occasionally gets polished, but never deliberately thrown away or broken. For people who invested in it a long time ago, their investment is still valuable today. > It might make sense to maintain backwards compatibility for 5 years > or so, but past that point all bets are off That would guarantee the failure of this standard. Who is going to invest all that effort in something doomed to be obsolete before they've even finished debugging it? Before it ever even has a chance to become, as we hope, ubiquitous. > Backwards-compatibility should not last forever, especially now that > most applications auto-update themselves. The PSTN is perfectly capable of carrying full-band Opus in the 64kbs timeslots that carry G.711. Yet we mandated G.711 here as important for interop with it, because nobody realistically expects that successful standard is going to change. No matter how crappy or ancient its MTI codec may be. > Practically speaking that means that WebRTC 2.0 would be backwards > compatible with 1.0, but 3.0 would not be. ... only if we completely fail to get the foundations correct. I have no objection to varying the recommended codecs over time as better recommendations become available and apparent. This is what codec negotiation is for. This is exactly why those codecs should be no stronger than recommended, if even that strong. But the MANDATORY aspects of this standard are its cornerstones. If you remove those, you no longer have the structure called WebRTC, you have a collapsed pile of rubble, that _maybe_ you can build some other thing out of from scratch, with a huge amount of new effort. And maybe, if you're lucky, that new thing will get adopted not long after IPv6 actually becomes widely usable and ubiquitous ... but don't hold your breath for it. We're not defining a widget library, or toy scripting language here, where it's ok to tell everybody their old stuff won't work anymore next year and they'll need to completely rewrite it. We're proposing a new internet standard. If people see that it has no enduring or expected lifetime, they're just going to ignore it and we're completely wasting our time. In that case we might as well just let Google and Mozilla work it out between themselves. That would be a lot less work and get it deployed a whole lot quicker. Ron > On 23/11/2013 8:34 PM, Ron wrote: > >On Sat, Nov 23, 2013 at 10:14:45PM +0100, Daniel-Constantin Mierla wrote: > >>On 11/23/13 12:46 AM, David Singer wrote: > >>>No, I think we all want an MTI codec. But not at any price in terms > >>>of quality degradation, and H.261 may be simply off the bottom end. > >>This is the last resort if one doesn't have a better alternative. I > >>doubt people that really like wide band audio codecs don't use > >>mobile phones on 2G/GSM which is quite poor audio experience, but > >>when you are on top of mountains or remote locations is the only > >>option. > >Actually, it's much more than that. This is going to be the codec > >of last resort "forever". Think about that. Think hard. I'll wait. > > > >Unless we are going to resign ourselves to this whole standard being > >a bad joke, that will be discarded in a few short years time, with > >all the work that has gone into it needing to be repeated *again*, > >then this specification is going to vastly outlive any codec that > >happens to be flavour of the month today. > > > >Which means long after H.264 has fallen out of favour and stopped > >being included in hardware and "legacy devices", and possibly during > >that fun period where people screw up the royalty rates hard to get > >people to move on to H.265 or whatever the next revenue raiser will > >be, implementations of this standard would still need to carry that > >dead baggage. Forever. > > > >Let's take a quick look at how that might compare: > > > > > > For the RM8 implementation of H.261: > > > > p64dir$ sloccount . > > Total Physical Source Lines of Code (SLOC) = 6,707 > > > > For x264 (from git a few minutes ago): > > > > x264$ sloccount . > > Total Physical Source Lines of Code (SLOC) = 89,663 > > > > > >One of these has been 'stable' since 1995. The other is still fixing > >several bugs a month, even as we speak. > > > >One of these will still be a standard applicable to the PSTN for as > >long as it continues to be around (just like G.711). The other will > >be consigned to the dusts of history with H.262 and H.263, probably > >well before vinyl records are. > > > > > >H.265 is already out. VP9 is nearly already out. Daala is going > >to kick all of their asses like Opus did ... > > > >These are the codecs that people are _actually_ going to use by the > >time this standard is actually completed and well established. > > > > > >So remind me again why we want to take all of the obvious pain today > >to mandate a codec that will also be orders of magnitude more pain > >in perpetuity? Who wants to still be fixing security bugs in H.264 > >in 2020? When people have long since stopped actually using or > >testing it. > > > >Yes, H.261 is not quite as trivial as G.711, but compared to H.264 > >it's near enough. It was designed to run on 'computers' made of > >snot and matchsticks and rubber bands. If we are going to burden > >ourselves with having to carry an obsolete codec forever, whatever > >we do -- then maybe there actually is a genuine argument that H.261 > >is not just a compromise we'll all hate, but it could in fact be, > >when all things are considered, a clearly superior choice in its > >own right for the MTI fallback of last resort. > > > >Shocking I know. > > > >But I guess that's what happens when you take a step back from > >short sighted, short term, "best for me today" considerations > >and look at the big picture here. > > > > > >I cordially invite everyone else to do the same :) > > > > Ron From cowwoc@bbs.darktech.org Sun Nov 24 17:51:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C241AE1BF for ; Sun, 24 Nov 2013 17:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJOr11E-zWkx for ; Sun, 24 Nov 2013 17:51:23 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id D02DD1A1F3D for ; Sun, 24 Nov 2013 17:51:22 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so5699144ief.6 for ; Sun, 24 Nov 2013 17:51:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U3YhbVkyyaRmOmLbvLIfvI4D9dsdgU4hf5ud/qnks94=; b=QmfMl2E7r+YB43AUwV8RXzqWqmzHDU/sD4XUP4yzKm2LADBoP+/IOmy+JWMjkI7NGG RewfEJoT8mfUIBK/QYAbxBLrBb5Is7TQP0IswBfOWhAEc5P0XnaWsMeFRvXdw9bfFemK B6bYXqbx5QyFs9sAOI90SMkpzCczDS8b9Em/elbq+ciNekm3/YF+g76qXGADsmYKGwYR gXJTuC+1QKSOgMhBE0E32YN28jEk4+drSVLVJPc4HBGoOOVCEgT48gG72bH9fAu1aOV/ JBlQCaKWrMfO63M1bkK5pGoJj0PKHvSwroGvUHrc/PACS30qJa65QL2UElu3jseeU4mC TvTQ== X-Gm-Message-State: ALoCoQlJO4ShtOuAVlqh6tqXJ7KeW7RXSed9DpEOziSuV/uzYC+zBPtct2cPpGA5MHdm+eTR08LB X-Received: by 10.50.16.45 with SMTP id c13mr10795244igd.55.1385344282338; Sun, 24 Nov 2013 17:51:22 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id i11sm23111187igh.0.2013.11.24.17.51.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Nov 2013 17:51:21 -0800 (PST) Message-ID: <5292ACF8.4050704@bbs.darktech.org> Date: Sun, 24 Nov 2013 20:50:48 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FC497.2080804@googlemail.com> <528FEC5A.8060701@librevideo.org> <7C4C4F47-1F9B-4A69-AE68-122DE394E203@apple.com> <52911AC5.3090408@gmail.com> <20131124013400.GI3245@audi.shelbyville.oz> <52925239.1000807@bbs.darktech.org> <20131125004454.GL3245@audi.shelbyville.oz> In-Reply-To: <20131125004454.GL3245@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 - taking a longer view of things X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 01:51:24 -0000 On 24/11/2013 7:44 PM, Ron wrote: > We're not defining a widget library, or toy scripting language here, > where it's ok to tell everybody their old stuff won't work anymore > next year and they'll need to completely rewrite it. We're proposing a > new internet standard. If people see that it has no enduring or > expected lifetime, they're just going to ignore it and we're > completely wasting our time. i think you are being a bit over-dramatic. Say one day we discover that codec X is strictly-better than H.261 and decide to replace it. We would add X as MTI, alongside H.261 as part of WebRTC 2.0 and announce that H.261 is deprecated. Fast forward a few years, and WebRTC 3.0 is about to roll out. If we find that 95% [1] of users are using WebRTC 2.0 and higher then we can safely remove H.261 as MTI from version 3.0. I see no benefit in supporting deprecated features forever, nor do I see how removing them will cause WebRTC to fail. Take a look at http://developer.android.com/about/dashboards/index.html ... Will Android lose value if they drop support for version 2.2? I think not. It has 1.7% market share in spite of the fact it was released 3.5 years ago. Mobile platforms and auto-updating applications make it easier and easier to drop deprecated features. [1] 95% is an arbitrary figure, you can use 99% if it makes you happier. Gili From mzanaty@cisco.com Sun Nov 24 18:11:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AB91AE3F3 for ; Sun, 24 Nov 2013 18:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.601 X-Spam-Level: X-Spam-Status: No, score=-12.601 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shNYlHlP-aGp for ; Sun, 24 Nov 2013 18:11:00 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id EDB0A1AE3E3 for ; Sun, 24 Nov 2013 18:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8737; q=dns/txt; s=iport; t=1385345439; x=1386555039; h=from:to:cc:subject:date:message-id:mime-version; bh=DljxyfHLBX2eO52qi+KlkJk0fj2UwSItb4g5zaAsdqU=; b=DrnJjXT4mRTnXEyeHTvjpa+cKs6HzjmbEphp6t4brmRCkSQoYPbys68K eYnETM21n+gBv7Bs+0bM4wy7jrM3ELg49K0s+Sti3YY82VqYUBllcSj50 3mdT+6kMeKZdmZYLr4GsEuf0vK4Elli89zUaqLJrDio5wWy4XZ1I2Jmud E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4GAEexklKtJXHB/2dsb2JhbABZgwc4U7NRiEyBHhZ0gix5EgFvEScEAQ0FCRKHVAMPDbQUDYgkjHiBPgEBT4Q6A5YpgWuBMIsqhTiDKIFxOQ X-IronPort-AV: E=Sophos;i="4.93,765,1378857600"; d="scan'208,217";a="287213775" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 25 Nov 2013 02:10:38 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAP2Actc028056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 02:10:38 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Sun, 24 Nov 2013 20:10:37 -0600 From: "Mo Zanaty (mzanaty)" To: Christer Holmberg , Martin Thomson , "Paul Giralt (pgiralt)" Thread-Topic: Asymmetric codecs Thread-Index: AQHO6YOHQHY8Un59WEC1K24yFUskgQ== Date: Mon, 25 Nov 2013 02:10:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.214.231] Content-Type: multipart/alternative; boundary="_000_CEB676E01ED44mzanatyciscocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: [rtcweb] Asymmetric codecs X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 02:11:02 -0000 --_000_CEB676E01ED44mzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I started a draft on how to standardize support for asymmetric codecs back = in September. The primary motivation was decoding H.264 and H.265 while onl= y encoding H.264. A secondary motivation, for rtcweb, was decoding H.264 an= d VP8 while only encoding one of them, as Stefan mentioned. I thought it wo= uld be a trivial thing to write up by the Oct. 6 deadline for MTI proposals= . The draft is still incomplete and unpublished because all solutions are u= gly and overly complex for something so seemingly trivial, just like bundle= and unified plan. I now sympathize with Christer and Adam for how they arr= ived at those (not exactly elegant) solutions, and agree with Martin that a= pair of (bundled) m-lines is the most viable (although not exactly elegant= ) solution for asymmetric codecs. RFC 4317 drafts originally included asymmetric codecs until they were remov= ed in draft 02: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-mmusic-= offer-answer-examples-02.txt They were removed for fear of issues with shared ports: http://www.ietf.org/mail-archive/text/mmusic/2003-09.mail Now that we (almost) have bundle, can we resurrect asymmetric codecs with s= eparate sendonly and recvonly m-lines? Are folks ok with a dependency on bu= ndle? I would be happy to complete a draft in that direction. (That is, a g= eneral mmusic draft on asymmetric codecs, not a rtcweb draft on MTI asymmet= ric codecs. I will move the discussion to mmusic after getting rtcweb opini= ons first.) Some may consider this a bizarre corner case. However, for hardware codecs,= it is the norm not the exception to have asymmetric encoder and decoder fo= rmats. Especially for new formats, which usually appear in hardware decoder= s well before hardware encoders are available. This happened for H.264, H.2= 65, VP8, and virtually every popular codec format in virtually every popula= r chipset. Mo On 11/23/13, 9:09 AM, Christer Holmberg wr= ote: Like some others, I think the must-decode-both-must-endcode-one alternative= as such sounds interesting (whether it has any impact on the licence/IPR i= ssues I'll leave to others to speak for). However, I have big concerns over= the proposal to indicate sendrecv for a codec even if an entity is only ab= le to receive/decode it. =85 Usage of unidirectional, sendonly/recvonly, m-= line would of course solve this, and you might know that it is one option = we are discussing in CLUE (for other reasons than MTI codec, though). On 22 November 2013 16:20, Paul Giralt (pgiralt) wrote: I gave this as an example of a possible way to do it, but that means you ne= ed two separate m=3D lines - one for send and one for receive. Seems strang= e to do this for something that you really want to be a single bi-direction= al stream. On 11/22/13, 8:03 PM, Martin Thomson wrote: The bidirectional thing in O/A is the strange way to do things. Two lines = is pretty intuitive. --_000_CEB676E01ED44mzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <63D84E4265F11A4A8BD80E0E6A296A05@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I started a draft on how to standardize support for asymmetric codecs = back in September. The primary motivation was decoding H.264 and H.265 whil= e only encoding H.264. A secondary motivation, for rtcweb, was decoding H.2= 64 and VP8 while only encoding one of them, as Stefan mentioned. I thought it would be a trivial thing to wri= te up by the Oct. 6 deadline for MTI proposals. The draft is still incomple= te and unpublished because all solutions are ugly and overly complex for so= mething so seemingly trivial, just like bundle and unified plan. I now sympathize with Christer and Adam for = how they arrived at those (not exactly elegant) solutions, and agree with M= artin that a pair of (bundled) m-lines is the most viable (although not exa= ctly elegant) solution for asymmetric codecs.

RFC 431= 7 drafts originally included asymmetric codecs until they were removed in d= raft 02:
http://tools.ietf.org/rfcdiff?difftyp= e=3D--hwdiff&url2=3Ddraft-ietf-mmusic-offer-answer-examples-02.txt<= /div>

They we= re removed for fear of issues with shared ports:

Now that we (almost) have bundle, can = we resurrect asymmetric codecs with separate sendonly and recvonly m-lines?= Are folks ok with a dependency on bundle? I would be happy to complete a d= raft in that direction. (That is, a general mmusic draft on asymmetric codecs, not a rtcweb draft on MTI asy= mmetric codecs. I will move the discussion to mmusic after getting rtc= web opinions first.)

Some ma= y consider this a bizarre corner case. However, for hardware codecs, it is = the norm not the exception to have asymmetric encoder and decoder formats. = Especially for new formats, which usually appear in hardware decoders well before hardware encoders are avai= lable. This happened for H.264, H.265, VP8, and virtually every popular cod= ec format in virtually every popular chipset.

Mo

On 11/23/13, 9:09 AM, Christer Holmber= g <christer.holmberg@ericsson.com> wrote:
Like some others, I think the must-dec= ode-both-must-endcode-one alternative as such sounds interesting (whether i= t has any impact on the licence/IPR issues I'll leave to others to speak fo= r). However, I have big concerns over the proposal to indicate sendrecv for a codec even if an entity is only ab= le to receive/decode it. =85 Usage of unidirectional, sendonly/recvonly, m-= line would of course solve this, and you might know that it is one option = we are discussing in CLUE (for other reasons than MTI codec, though).
 
On 22 November 2013 16:20, Paul Giralt= (pgiralt) <pgiralt@cisco.com> wrote:
I gave this as an example of a possibl= e way to do it, but that means you need two separate m=3D lines - one for s= end and one for receive. Seems strange to do this for something that you re= ally want to be a single bi-directional stream.

On 11/22/13, 8:03 PM, Martin Thomson &= lt;martin.thomson@gmail.com> wrote:
The bidirectional thing in O/A is the = strange way to do things.  Two lines is pretty intuitive.

--_000_CEB676E01ED44mzanatyciscocom_-- From sslivinski@lifesize.com Sun Nov 24 18:17:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E821AE271 for ; Sun, 24 Nov 2013 18:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m1el_GNE9LM for ; Sun, 24 Nov 2013 18:17:12 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id 38F081AE3A3 for ; Sun, 24 Nov 2013 18:17:04 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUpKzGgvCP2OfXgBG8EKbGWDiUSG5cDEU@postini.com; Sun, 24 Nov 2013 18:17:05 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Sun, 24 Nov 2013 20:04:57 -0600 From: Stefan Slivinski To: cowwoc , "rtcweb@ietf.org" Date: Sun, 24 Nov 2013 20:04:54 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7pTWyFXJ+9EU4BQb6FKZ0Fo35FxwANT5aQ Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E6798@ausmsex00.austin.kmvtechnologies.com> References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> <529057EB.3060704@bbs.darktech.org> <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com> <529256B3.7000202@bbs.darktech.org> In-Reply-To: <529256B3.7000202@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 02:17:15 -0000 Every time I think the horse is dead, it gets back up -----Original Message----- From: cowwoc [mailto:cowwoc@bbs.darktech.org]=20 Sent: Sunday, November 24, 2013 11:43 AM To: Stefan Slivinski; rtcweb@ietf.org Subject: Re: [rtcweb] H.261 Stefan, You are beating a dead horse. No one is arguing that H.261 is technically s= uperior to H.264. I'll repeat what I just posted on another thread: Just so there is no confusion: if you manage to convince us that X is "stri= ctly better" than H.261 then I'd jump on board. I was trying to explain tha= t many people are trying to remove H.261 as an option by explaining how bad= it is. Going down this road won't change our minds because we already agre= e that it is a shitty codec. The only way to convince us that X is "strictly better" than H.261 is to ta= lk about X (not H.261) and demonstrate that it meets our IPR requirements. = Do that, and you will have my vote (and probably that of others). Gili On 23/11/2013 11:29 PM, Stefan Slivinski wrote: > I don't want to make any assumptions as to why their particular use case = failed at 20+ participants. Maybe it was bandwidth related, maybe it was b= ecause intel quicksync doesn't support VP8. I don't know and I'm not going= to speculate. What I do know is intel quicksync is capable of decoding H.= 264 at 4K without breaking a sweat. 4K is more than 80x (yes, eighty times= ) the resolution of H.261. So H.261 isn't likely to have helped them here. > > What few seem to acknowledge is that companies like intel, TI, qualcomm, = broadcom (just to name a few) have spent hundreds of millions (if not billi= ons) of dollars adding hardware accelerate for H.264 to their chips. Purpo= se designed hardware will always be faster and require less power than soft= ware implementations and no one is spending anything supporting H.261 hardw= are acceleration. > > H.261 does not have any technical advantage whether it be bitrate,=20 > performance, power consumption or otherwise over H.264 on any modern=20 > media processor > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc > Sent: Friday, November 22, 2013 11:23 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] H.261 > > Stefan, > > At the conference, they mentioned that you cannot implement online=20 > video classes (with 20+ participants) unless you reduce the resolution=20 > and frame rate of non-speakering participants. Meaning, even without=20 > having to do any transcoding (they use VP8 across the board) there is=20 > insufficient bandwidth and CPU to handle 20 incoming video streams at=20 > HD resolutions. So what you do is host non-speakers at tiny=20 > resolutions and > 3 fps. > > H.261 could handle those non-speakers just fine (in fact, it would be pre= ferable as it reduces CPU usage). Furthermore, if you chose to transcode, y= ou'd be dealing with tiny resolutions and 3fps. In both cases, the use of H= .261 or transcoding is not the bottleneck. > > Gili > > On 22/11/2013 8:42 PM, Stefan Slivinski wrote: >> Just for fun, let's play out the H.261 scenario as the great savior of w= ebrtc that some claim it is: >> >> Let's say through some divine miracle we manage to all agree to make H.2= 61 the one and only MTI codec. The rationale being of course that no one w= ill ever use it because it is of course terrible, but we need it to get aro= und those pesky patent/license terms with VP8/H.264 respectively. >> >> Alright fast forward, Chrome adds H.261 but continues to use VP8. IE us= es H.261 and H.264, Safari uses H.261 and H.264 and Firefox does H.261, H.2= 64 and VP8. So far so good. Chrome can talk using VP8 to Firefox, Safari = can talk H.264 to IE, Firefox can either H.264 or VP8 to everyone. As long= as Chrome users don't try to call IE or Safari, we're in good shape, other= wise we need to transcode using some undefined cloud based transcoder servi= ce or just use H.261. >> >> So we're still in good shape. Now let's consider the multiway case. I = heard a use case at the conference on Tuesday where a university was using = webrtc to enable video online classes. So let's assume there are 20 people= in the class. 19 people in the class love Chrome, so they join the class = from chrome and are all sending each other VP8. But of course there's alwa= ys one person that has to be difficult and they decide they prefer IE. So = what now? Well the IE person doesn't understand any of the 19 VP8 streams= and the 19 chrome users don't understand the 1 H.264 stream. So we can no= w utilize that same undefined cloud transcoding service to convert each of = the 19 VP8 streams to H.264 and the 1 H.264 stream to VP8....or we can use = H.261. >> >> My guess is H.261 is going to get used a lot more than anyone thinks. >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach >> Sent: Friday, November 22, 2013 5:37 PM >> To: Ron; rtcweb@ietf.org >> Subject: Re: [rtcweb] H.261 >> >> On 11/22/13 18:35, Ron wrote: >>> The whole point of many distros is to supply binaries, often built=20 >>> many times for many different system architectures. >> And the overwhelming majority of these do so by including a list of repo= sitories from which the binaries can be downloaded. >> >> I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs,= and whatever else is needed for these distros, targeting whatever platform= s are required. Now, whether we can get the distro maintainers to add a sin= gle line to their list of repos -- because that's all it would take -- is a= different issue. But at that point, it's just a matter of the distro maint= ainers being intransigent rather than any real technical or legal barrier. >> >> /a >> _______________________________________________ >> 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 From sslivinski@lifesize.com Sun Nov 24 18:28:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D4B1A1DFA for ; Sun, 24 Nov 2013 18:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5Uu__n6PEbo for ; Sun, 24 Nov 2013 18:28:40 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id 004741A1F1B for ; Sun, 24 Nov 2013 18:28:39 -0800 (PST) Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUpK11+zLpQi8iTOJvA/8HK+1Z2y1e6Sx@postini.com; Sun, 24 Nov 2013 18:28:40 PST Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Sun, 24 Nov 2013 20:21:49 -0600 From: Stefan Slivinski To: Maik Merten , "rtcweb@ietf.org" Date: Sun, 24 Nov 2013 20:21:46 -0600 Thread-Topic: [rtcweb] H.261 Thread-Index: Ac7o9VigiG9QHbpBQw68m1ooDQMzOwAjWd1Q Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E679A@ausmsex00.austin.kmvtechnologies.com> References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E6760@ausmsex00.austin.kmvtechnologies.com> <529057EB.3060704@bbs.darktech.org> <7949EED078736C4881C92F656DC6F6C130EA9E677A@ausmsex00.austin.kmvtechnologies.com> <5291C305.1090302@googlemail.com> In-Reply-To: <5291C305.1090302@googlemail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 02:28:42 -0000 All good points. 3rd party support is inconsistent, there are platforms th= at play nice and others that don't. It's definitely a problem but in theor= y everyone could support exposing an API to hardware acceleration. Typical= ly error resiliency is half-hearted, generally these engines were designed = for playing movies or recording videos where packet loss is impossible. Mo= st of the time issues can be fixed with a firmware upgrade. As for decodin= g several streams in parallel, the short answer is no. some architectures = have multiple hardware acceleration engines (TI omap as an example) where t= his is possible, otherwise it's serial but if you are decoding say 720p30 o= n a hardware acceleration engine that can do up to 4Kp30 then you can do 9 = 720p30 streams by decoding one frame for each stream as they arrive. Manag= ing all the 9 independent streams will usually have some hit to performance= in order to page context information in/out of memory so maybe 8 streams i= s more realistic. I don't know about skype on every platform, I know one of our products supp= orts skype and we do all the encode/decode in hardware but that's just once= example. But one thing skype didn't do was use H.261. -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maik Merten Sent: Sunday, November 24, 2013 1:13 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 Am 24.11.2013 05:29, schrieb Stefan Slivinski: > What few seem to acknowledge is that companies like intel, TI, qualcomm, = broadcom (just to name a few) have spent hundreds of millions (if not billi= ons) of dollars adding hardware accelerate for H.264 to their chips. Purpo= se designed hardware will always be faster and require less power than soft= ware implementations and no one is spending anything supporting H.261 hardw= are acceleration. It appears that these hardware accelerators are usually not accessible to 3= rd-party applications on mobile platforms (as has been discussed before). E= ven if they are they may not be consistent regarding available settings and= performance. Can hardware accelerators, e.g., decode several incoming stre= ams in parallel (honest question, I really don't know)? How does bitrate co= ntrol of the embedded encoders behave? Do they offer options for error resi= lience etc. etc.? IIRC it has been confirmed on this list that Skype deploys H.264 in softwar= e across all platforms for such reasons. So clearly, the theoretical advant= ages of H.264 hardware support (which works nicely in media playback, no do= ubt) do clearly not transfer quite easily to real-time communication on con= sumer devices. Given that older codecs currently in discussion are much mor= e frugal in terms of overall computation, deployments in software don't loo= k especially intimidating. Maik _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Sun Nov 24 23:25:16 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A20D1AC7F2 for ; Sun, 24 Nov 2013 23:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JAqsvBTFGTE for ; Sun, 24 Nov 2013 23:25:13 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF9F1AC43E for ; Sun, 24 Nov 2013 23:25:11 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-75-5292fb4002aa Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E9.6A.15980.14BF2925; Mon, 25 Nov 2013 08:24:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Mon, 25 Nov 2013 08:24:01 +0100 From: Christer Holmberg To: "Mo Zanaty (mzanaty)" , Martin Thomson , "Paul Giralt (pgiralt)" Thread-Topic: Asymmetric codecs Thread-Index: AQHO6YOHQHY8Un59WEC1K24yFUskgZo1iRZw Date: Mon, 25 Nov 2013 07:24:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C55441BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvra7j70lBBlP3m1tcO/OP0eLFgzlM FjcbHjNarP3Xzu7A4jHl90ZWj52z7rJ7LFnykymAOYrLJiU1J7MstUjfLoErY3FjaMHx2opT N68yNjC25nUxcnJICJhItH3ZywJhi0lcuLeerYuRi0NI4BCjxJ0dp5ghnMWMEn/2XADKcHCw CVhIdP/TBomLCLQzSsw51sIO0s0soC5xZ/E5MFtYQE6i8fMiRhBbREBe4vaNO6wQtpHElw+n wLaxCKhKLJi6AGwmr4CvxLtFOiBhIQE9iQnTHzKB2JwC+hLLV6wFK2cEOu77qTVMEKvEJW49 mc8EcbSAxJI955khbFGJl4//sULYihIfX+1jhKjPl3i39AcbiM0rIChxcuYTlgmMorOQjJqF pGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipE9NzEzJ73cfBMjMN4ObvltsINx 032xQ4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCUuyRdfHlFcM7iM7f0 G5jlNllZhtxi5tX5pWZ5MzG98HJ2UrpUauDSQ0qade9ivt3Qyqn+ezjl7pqbTPPsW4xO7vba 5P9UL//U6QdmMSc4r19bVFz3Ml62YVb/wV0XG+v2TlvdUrTOdOPGS/9XryntYFywZdaXN1L2 D2pf3mfuLVwYJ17dvklIiaU4I9FQi7moOBEAYl8IyoUCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asymmetric codecs X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 07:25:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C55441BESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, First, from a pure MTI codec perspective, the question is whether usage of = asymmetric codecs would solve the issues that people have. Second, from an SDP OA/BUNDLE perspective, I don't think we can mandate usa= ge of BUNDLE. And, even if we did, in the initial Offer you still need to a= ssign unique port values for each m- line (as agreed in Vancouver). ...unless, of course, you assign an SDP 'bundle-only' attribute to all m- l= ines with asymmetric codecs. Regards, Christer From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] Sent: 25. marraskuuta 2013 4:11 To: Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt) Cc: rtcweb@ietf.org Subject: Asymmetric codecs I started a draft on how to standardize support for asymmetric codecs back = in September. The primary motivation was decoding H.264 and H.265 while onl= y encoding H.264. A secondary motivation, for rtcweb, was decoding H.264 an= d VP8 while only encoding one of them, as Stefan mentioned. I thought it wo= uld be a trivial thing to write up by the Oct. 6 deadline for MTI proposals= . The draft is still incomplete and unpublished because all solutions are u= gly and overly complex for something so seemingly trivial, just like bundle= and unified plan. I now sympathize with Christer and Adam for how they arr= ived at those (not exactly elegant) solutions, and agree with Martin that a= pair of (bundled) m-lines is the most viable (although not exactly elegant= ) solution for asymmetric codecs. RFC 4317 drafts originally included asymmetric codecs until they were remov= ed in draft 02: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-mmusic-= offer-answer-examples-02.txt They were removed for fear of issues with shared ports: http://www.ietf.org/mail-archive/text/mmusic/2003-09.mail Now that we (almost) have bundle, can we resurrect asymmetric codecs with s= eparate sendonly and recvonly m-lines? Are folks ok with a dependency on bu= ndle? I would be happy to complete a draft in that direction. (That is, a g= eneral mmusic draft on asymmetric codecs, not a rtcweb draft on MTI asymmet= ric codecs. I will move the discussion to mmusic after getting rtcweb opini= ons first.) Some may consider this a bizarre corner case. However, for hardware codecs,= it is the norm not the exception to have asymmetric encoder and decoder fo= rmats. Especially for new formats, which usually appear in hardware decoder= s well before hardware encoders are available. This happened for H.264, H.2= 65, VP8, and virtually every popular codec format in virtually every popula= r chipset. Mo On 11/23/13, 9:09 AM, Christer Holmberg > wrote: Like some others, I think the must-decode-both-must-endcode-one alternative= as such sounds interesting (whether it has any impact on the licence/IPR i= ssues I'll leave to others to speak for). However, I have big concerns over= the proposal to indicate sendrecv for a codec even if an entity is only ab= le to receive/decode it. ... Usage of unidirectional, sendonly/recvonly, m-= line would of course solve this, and you might know that it is one option = we are discussing in CLUE (for other reasons than MTI codec, though). On 22 November 2013 16:20, Paul Giralt (pgiralt) > wrote: I gave this as an example of a possible way to do it, but that means you ne= ed two separate m=3D lines - one for send and one for receive. Seems strang= e to do this for something that you really want to be a single bi-direction= al stream. On 11/22/13, 8:03 PM, Martin Thomson > wrote: The bidirectional thing in O/A is the strange way to do things. Two lines = is pretty intuitive. --_000_7594FB04B1934943A5C02806D1A2204B1C55441BESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

First, from a pure MTI co= dec perspective, the question is whether usage of asymmetric codecs would s= olve the issues that people have.

 <= /p>

Second, from an SDP OA/BU= NDLE perspective, I don’t think we can mandate usage of BUNDLE. And, even if we did, in the initial Offer you still= need to assign unique port values for each m- line (as agreed in Vancouver= ).

 <= /p>

…unless, of course,= you assign an SDP ‘bundle-only’ attribute to all m- lines with= asymmetric codecs.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Mo Zanat= y (mzanaty) [mailto:mzanaty@cisco.com]
Sent: 25. marraskuuta 2013 4:11
To: Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
Cc: rtcweb@ietf.org
Subject: Asymmetric codecs

 

I started a draft on how to standardize suppor= t for asymmetric codecs back in September. The primary motivation was decod= ing H.264 and H.265 while only encoding H.264. A secondary motivation, for rtcweb, was decoding H.264 and VP8 while only encoding one= of them, as Stefan mentioned. I thought it would be a trivial thing to wri= te up by the Oct. 6 deadline for MTI proposals. The draft is still incomple= te and unpublished because all solutions are ugly and overly complex for something so seemingly trivial, just like = bundle and unified plan. I now sympathize with Christer and Adam for how th= ey arrived at those (not exactly elegant) solutions, and agree with Martin = that a pair of (bundled) m-lines is the most viable (although not exactly elegant) solution for asymmetric = codecs.

 

RFC 4317 drafts originally included asymmetric= codecs until they were removed in draft 02:

 

They were removed for fear of issues with shar= ed ports:

 

Now that we (almost) have bundle, can we resurrect asymmet= ric codecs with separate sendonly and recvonly m-lines? Are folks ok with a= dependency on bundle? I would be happy to complete a draft in that direction. (That is, a general mmusic draft on asymmetric codecs, = not a rtcweb draft on MTI asymmetric codecs. I will move the discussio= n to mmusic after getting rtcweb opinions first.)

 

Some may consider this a bizarre corner case. = However, for hardware codecs, it is the norm not the exception to have asym= metric encoder and decoder formats. Especially for new formats, which usually appear in hardware decoders well before hardware encoders ar= e available. This happened for H.264, H.265, VP8, and virtually every popul= ar codec format in virtually every popular chipset.

 

Mo

 

On 11/23/13, 9:09 AM, Christer Holmberg <christer.holmberg@ericsson.com> = wrote:

Like some others, I think the must-decode-both-must-endcod= e-one alternative as such sounds interesting (whether it has any impact on = the licence/IPR issues I'll leave to others to speak for). However, I have big concerns over the proposal to indicate sendrecv for a = codec even if an entity is only able to receive/decode it. … Usage of= unidirectional, sendonly/recvonly, m- line would of course solve this, and= you might know that it is one option we are discussing in CLUE (for other reasons than MTI codec, though).

 

On 22 November 2013 16:20, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:

I gave this as an example of a possible way to do it, but = that means you need two separate m=3D lines - one for send and one for rece= ive. Seems strange to do this for something that you really want to be a single bi-directional stream.

 

On 11/22/13, 8:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

The bidirectional thing in O/A is the strange way to do th= ings.  Two lines is pretty intuitive.

 

--_000_7594FB04B1934943A5C02806D1A2204B1C55441BESESSMB209erics_-- From cowwoc@bbs.darktech.org Sun Nov 24 23:35:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6AA1AC7F2 for ; Sun, 24 Nov 2013 23:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfu95vqerz8J for ; Sun, 24 Nov 2013 23:35:27 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 207B41AC43E for ; Sun, 24 Nov 2013 23:35:27 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id to1so6112734ieb.4 for ; Sun, 24 Nov 2013 23:35:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=aNTo9sdOBbBlx6f+i3e8wfTrtsi2g11tX9fyTR0GR8I=; b=lS6KWY+4ycBoU4wFm0PHCPQEWtskOa9huvE/uouSigJTv5XbugQmzmhN5ToEkqOY3s 5tI73OtHi+5IGCydFrY/hO8dt3cGSbQjUagn/HN6Dd5gIkuQd3lC52TymEfbr/s+ohZi tJ8zvt4uLYZ6TPOc26zc6DnRqsD4BKnZjb7LZdGCJB7dUBSj16Qdcrm2e/0b30Ge0FNR b0monC9uliqI5DIi2k7qGAQ/BEqmJZ5T1Aq3bH18/ejnoK8JL0NBm+ZJjUq9LHrL6cb+ Bi9OTMn9jpXqh0CKySA+pV3ahMaBTpmK8v0eyh5BblkrvtswXPXzz3PkZol5WKYrEt+a loBA== X-Gm-Message-State: ALoCoQmSCYDw4sMeyAg/bvpQMWfI4U70857IIFhM6mo109JXRUjcm/v7FGcuDakI6sycU3WFOqJE X-Received: by 10.50.85.115 with SMTP id g19mr11891100igz.1.1385364927255; Sun, 24 Nov 2013 23:35:27 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ft2sm25081579igb.5.2013.11.24.23.35.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Nov 2013 23:35:26 -0800 (PST) Message-ID: <5292FD9D.3020207@bbs.darktech.org> Date: Mon, 25 Nov 2013 02:34:53 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------060208090805040304010607" Subject: Re: [rtcweb] Asymmetric codecs X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 07:35:30 -0000 This is a multi-part message in MIME format. --------------060208090805040304010607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit SDP is supposed to be an implementation detail. Let's figure out whether asymmetric codecs solve our problems and wedge it into SDP later. I suspect that this approach reduces the IPR risk, but H.264 royalties still apply, do they not? Sadly this means we're stuck with: "MUST decode at least two of [VP8, H.264, H.261] and MUST encode at least one of them". Gili On 25/11/2013 2:24 AM, Christer Holmberg wrote: > > Hi, > > First, from a pure MTI codec perspective, the question is whether > usage of asymmetric codecs would solve the issues that people have. > > Second, from an SDP OA/BUNDLE perspective, I don't think we can > mandate *usage* of BUNDLE. And, even if we did, in the initial Offer > you still need to assign unique port values for each m- line (as > agreed in Vancouver). > > ...unless, of course, you assign an SDP 'bundle-only' attribute to all > m- lines with asymmetric codecs. > > Regards, > > Christer > > *From:*Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] > *Sent:* 25. marraskuuta 2013 4:11 > *To:* Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt) > *Cc:* rtcweb@ietf.org > *Subject:* Asymmetric codecs > > I started a draft on how to standardize support for asymmetric codecs > back in September. The primary motivation was decoding H.264 and H.265 > while only encoding H.264. A secondary motivation, for rtcweb, was > decoding H.264 and VP8 while only encoding one of them, as Stefan > mentioned. I thought it would be a trivial thing to write up by the > Oct. 6 deadline for MTI proposals. The draft is still incomplete and > unpublished because all solutions are ugly and overly complex for > something so seemingly trivial, just like bundle and unified plan. I > now sympathize with Christer and Adam for how they arrived at those > (not exactly elegant) solutions, and agree with Martin that a pair of > (bundled) m-lines is the most viable (although not exactly elegant) > solution for asymmetric codecs. > > RFC 4317 drafts originally included asymmetric codecs until they were > removed in draft 02: > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-mmusic-offer-answer-examples-02.txt > > They were removed for fear of issues with shared ports: > > http://www.ietf.org/mail-archive/text/mmusic/2003-09.mail > > Now that we (almost) have bundle, can we resurrect asymmetric codecs > with separate sendonly and recvonly m-lines? Are folks ok with a > dependency on bundle? I would be happy to complete a draft in that > direction. (That is, a general mmusic draft on asymmetric codecs, not > a rtcweb draft on MTI asymmetric codecs. I will move the discussion to > mmusic after getting rtcweb opinions first.) > > Some may consider this a bizarre corner case. However, for hardware > codecs, it is the norm not the exception to have asymmetric encoder > and decoder formats. Especially for new formats, which usually appear > in hardware decoders well before hardware encoders are available. This > happened for H.264, H.265, VP8, and virtually every popular codec > format in virtually every popular chipset. > > Mo > > On 11/23/13, 9:09 AM, Christer Holmberg > > wrote: > > Like some others, I think the must-decode-both-must-endcode-one > alternative as such sounds interesting (whether it has any impact on > the licence/IPR issues I'll leave to others to speak for). However, I > have big concerns over the proposal to indicate sendrecv for a codec > even if an entity is only able to receive/decode it. ... Usage of > unidirectional, sendonly/recvonly, m- line would of course solve this, > and you might know that it is one option we are discussing in CLUE > (for other reasons than MTI codec, though). > > On 22 November 2013 16:20, Paul Giralt (pgiralt) > wrote: > > I gave this as an example of a possible way to do it, but that means > you need two separate m= lines - one for send and one for receive. > Seems strange to do this for something that you really want to be a > single bi-directional stream. > > On 11/22/13, 8:03 PM, Martin Thomson > wrote: > > The bidirectional thing in O/A is the strange way to do things. Two > lines is pretty intuitive. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060208090805040304010607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

SDP is supposed to be an implementation detail. Let's figure out whether asymmetric codecs solve our problems and wedge it into SDP later.

I suspect that this approach reduces the IPR risk, but H.264 royalties still apply, do they not?

Sadly this means we're stuck with: "MUST decode at least two of [VP8, H.264, H.261] and MUST encode at least one of them".

Gili

On 25/11/2013 2:24 AM, Christer Holmberg wrote:

Hi,

 

First, from a pure MTI codec perspective, the question is whether usage of asymmetric codecs would solve the issues that people have.

 

Second, from an SDP OA/BUNDLE perspective, I don’t think we can mandate usage of BUNDLE. And, even if we did, in the initial Offer you still need to assign unique port values for each m- line (as agreed in Vancouver).

 

…unless, of course, you assign an SDP ‘bundle-only’ attribute to all m- lines with asymmetric codecs.

 

Regards,

 

Christer

 

From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
Sent: 25. marraskuuta 2013 4:11
To: Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
Cc: rtcweb@ietf.org
Subject: Asymmetric codecs

 

I started a draft on how to standardize support for asymmetric codecs back in September. The primary motivation was decoding H.264 and H.265 while only encoding H.264. A secondary motivation, for rtcweb, was decoding H.264 and VP8 while only encoding one of them, as Stefan mentioned. I thought it would be a trivial thing to write up by the Oct. 6 deadline for MTI proposals. The draft is still incomplete and unpublished because all solutions are ugly and overly complex for something so seemingly trivial, just like bundle and unified plan. I now sympathize with Christer and Adam for how they arrived at those (not exactly elegant) solutions, and agree with Martin that a pair of (bundled) m-lines is the most viable (although not exactly elegant) solution for asymmetric codecs.

 

RFC 4317 drafts originally included asymmetric codecs until they were removed in draft 02:

 

They were removed for fear of issues with shared ports:

 

Now that we (almost) have bundle, can we resurrect asymmetric codecs with separate sendonly and recvonly m-lines? Are folks ok with a dependency on bundle? I would be happy to complete a draft in that direction. (That is, a general mmusic draft on asymmetric codecs, not a rtcweb draft on MTI asymmetric codecs. I will move the discussion to mmusic after getting rtcweb opinions first.)

 

Some may consider this a bizarre corner case. However, for hardware codecs, it is the norm not the exception to have asymmetric encoder and decoder formats. Especially for new formats, which usually appear in hardware decoders well before hardware encoders are available. This happened for H.264, H.265, VP8, and virtually every popular codec format in virtually every popular chipset.

 

Mo

 

On 11/23/13, 9:09 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Like some others, I think the must-decode-both-must-endcode-one alternative as such sounds interesting (whether it has any impact on the licence/IPR issues I'll leave to others to speak for). However, I have big concerns over the proposal to indicate sendrecv for a codec even if an entity is only able to receive/decode it. … Usage of unidirectional, sendonly/recvonly, m- line would of course solve this, and you might know that it is one option we are discussing in CLUE (for other reasons than MTI codec, though).

 

On 22 November 2013 16:20, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:

I gave this as an example of a possible way to do it, but that means you need two separate m= lines - one for send and one for receive. Seems strange to do this for something that you really want to be a single bi-directional stream.

 

On 11/22/13, 8:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

The bidirectional thing in O/A is the strange way to do things.  Two lines is pretty intuitive.

 



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------060208090805040304010607-- From christer.holmberg@ericsson.com Sun Nov 24 23:45:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FA21AC82A for ; Sun, 24 Nov 2013 23:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5ZOq11pGn-U for ; Sun, 24 Nov 2013 23:45:35 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF551AC828 for ; Sun, 24 Nov 2013 23:45:33 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-9c-5292ffe8102b Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 95.ED.15980.9EFF2925; Mon, 25 Nov 2013 08:44:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Mon, 25 Nov 2013 08:43:51 +0100 From: Christer Holmberg To: cowwoc , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Asymmetric codecs Thread-Index: AQHO6YOHQHY8Un59WEC1K24yFUskgZo1iRZw///0yICAABJm0A== Date: Mon, 25 Nov 2013 07:43:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C554536@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> <5292FD9D.3020207@bbs.darktech.org> In-Reply-To: <5292FD9D.3020207@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C554536ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre7H/5OCDL79Zbc4c/M/u8Xaf+3s DkweTyZMZ/dYsuQnUwBTFJdNSmpOZllqkb5dAlfGg2X32Qr2Lmas+LIpuIHxSD9jFyMnh4SA icSb/p0sELaYxIV769m6GLk4hAQOMUo8ad3IBOEsZpSYe/05cxcjBwebgIVE9z9tkAYRAU+J v9Pfs4HYwgLqEu8f3WOFiGtILOu/wQZSLiLgJHFkXzSIySKgKvHxqwhIBa+Ar8T2+ZuZIabP YJT4sXcHWCungIFE7/33YLcxAt3z/dQaJhCbWUBc4taT+UwQdwpILNlznhnCFpV4+fgfK4St KPHx1T5GiPp8oF2zmCCWCUqcnPmEZQKjyCwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZ A4+ZkMUXMLKvYmTPTczMSS8338QIjJ2DW34b7GDcdF/sEKM0B4uSOO+Ht85BQgLpiSWp2amp BalF8UWlOanFhxiZODilGhh3Tz5/okd2yQS1b69ulxxR3hRrtjj83PXo3/6Xrm+xawuPTD43 3T0utbz0mnvqm62Tty7pdcp2KE0wLIueUyp+/6y27fqijQEd3pPc3tsUHrszie2NS3Lkyjfn fsyv0+nt2bB/bsb3CVM/mO3jefF1o/zf5xsPHQxRPv5VfjNr773mn6+idvL/V2Ipzkg01GIu Kk4EADrcORdrAgAA Subject: Re: [rtcweb] Asymmetric codecs X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 07:45:38 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C554536ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'm afraid that SDP has become is a little more than an implementation deta= il :) Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc Sent: 25. marraskuuta 2013 9:35 To: rtcweb@ietf.org Subject: Re: [rtcweb] Asymmetric codecs SDP is supposed to be an implementation detail. Let's figure out whether as= ymmetric codecs solve our problems and wedge it into SDP later. I suspect that this approach reduces the IPR risk, but H.264 royalties stil= l apply, do they not? Sadly this means we're stuck with: "MUST decode at least two of [VP8, H.264= , H.261] and MUST encode at least one of them". Gili On 25/11/2013 2:24 AM, Christer Holmberg wrote: Hi, First, from a pure MTI codec perspective, the question is whether usage of = asymmetric codecs would solve the issues that people have. Second, from an SDP OA/BUNDLE perspective, I don't think we can mandate usa= ge of BUNDLE. And, even if we did, in the initial Offer you still need to a= ssign unique port values for each m- line (as agreed in Vancouver). ...unless, of course, you assign an SDP 'bundle-only' attribute to all m- l= ines with asymmetric codecs. Regards, Christer From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] Sent: 25. marraskuuta 2013 4:11 To: Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt) Cc: rtcweb@ietf.org Subject: Asymmetric codecs I started a draft on how to standardize support for asymmetric codecs back = in September. The primary motivation was decoding H.264 and H.265 while onl= y encoding H.264. A secondary motivation, for rtcweb, was decoding H.264 an= d VP8 while only encoding one of them, as Stefan mentioned. I thought it wo= uld be a trivial thing to write up by the Oct. 6 deadline for MTI proposals= . The draft is still incomplete and unpublished because all solutions are u= gly and overly complex for something so seemingly trivial, just like bundle= and unified plan. I now sympathize with Christer and Adam for how they arr= ived at those (not exactly elegant) solutions, and agree with Martin that a= pair of (bundled) m-lines is the most viable (although not exactly elegant= ) solution for asymmetric codecs. RFC 4317 drafts originally included asymmetric codecs until they were remov= ed in draft 02: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-mmusic-= offer-answer-examples-02.txt They were removed for fear of issues with shared ports: http://www.ietf.org/mail-archive/text/mmusic/2003-09.mail Now that we (almost) have bundle, can we resurrect asymmetric codecs with s= eparate sendonly and recvonly m-lines? Are folks ok with a dependency on bu= ndle? I would be happy to complete a draft in that direction. (That is, a g= eneral mmusic draft on asymmetric codecs, not a rtcweb draft on MTI asymmet= ric codecs. I will move the discussion to mmusic after getting rtcweb opini= ons first.) Some may consider this a bizarre corner case. However, for hardware codecs,= it is the norm not the exception to have asymmetric encoder and decoder fo= rmats. Especially for new formats, which usually appear in hardware decoder= s well before hardware encoders are available. This happened for H.264, H.2= 65, VP8, and virtually every popular codec format in virtually every popula= r chipset. Mo On 11/23/13, 9:09 AM, Christer Holmberg > wrote: Like some others, I think the must-decode-both-must-endcode-one alternative= as such sounds interesting (whether it has any impact on the licence/IPR i= ssues I'll leave to others to speak for). However, I have big concerns over= the proposal to indicate sendrecv for a codec even if an entity is only ab= le to receive/decode it. ... Usage of unidirectional, sendonly/recvonly, m-= line would of course solve this, and you might know that it is one option = we are discussing in CLUE (for other reasons than MTI codec, though). On 22 November 2013 16:20, Paul Giralt (pgiralt) > wrote: I gave this as an example of a possible way to do it, but that means you ne= ed two separate m=3D lines - one for send and one for receive. Seems strang= e to do this for something that you really want to be a single bi-direction= al stream. On 11/22/13, 8:03 PM, Martin Thomson > wrote: The bidirectional thing in O/A is the strange way to do things. Two lines = is pretty intuitive. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1C554536ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I’m afraid that SDP= has become is a little more than an implementation detail :)

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
Sent: 25. marraskuuta 2013 9:35
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Asymmetric codecs

 


SDP is supposed to be an implementation detail. Let's figure out whether as= ymmetric codecs solve our problems and wedge it into SDP later.

I suspect that this approach reduces the IPR risk, but H.264 royalties stil= l apply, do they not?

Sadly this means we're stuck with: "MUST decode at least two of [VP8, = H.264, H.261] and MUST encode at least one of them".

Gili

On 25/11/2013 2:24 AM, Christer Holmberg wrote:

Hi,

 <= /p>

First, from a pure MTI co= dec perspective, the question is whether usage of asymmetric codecs would s= olve the issues that people have.

 <= /p>

Second, from an SDP OA/BU= NDLE perspective, I don’t think we can mandate usage of BUNDLE. And, even if we did, in the initial Offer you still= need to assign unique port values for each m- line (as agreed in Vancouver= ).

 <= /p>

…unless, of course,= you assign an SDP ‘bundle-only’ attribute to all m- lines with= asymmetric codecs.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 

I started a draft on how to standardize support for asymme= tric codecs back in September. The primary motivation was decoding H.264 an= d H.265 while only encoding H.264. A secondary motivation, for rtcweb, was decoding H.264 and VP8 while only encoding one of them, as= Stefan mentioned. I thought it would be a trivial thing to write up by the= Oct. 6 deadline for MTI proposals. The draft is still incomplete and unpub= lished because all solutions are ugly and overly complex for something so seemingly trivial, just like bund= le and unified plan. I now sympathize with Christer and Adam for how they a= rrived at those (not exactly elegant) solutions, and agree with Martin that= a pair of (bundled) m-lines is the most viable (although not exactly elegant) solution for asymmetric cod= ecs.

 

RFC 4317 drafts originally included asymmetric codecs unti= l they were removed in draft 02:

 

They were removed for fear of issues with shared ports:

 

Now that we (almost) have bundle, can we resurrect asymmet= ric codecs with separate sendonly and recvonly m-lines? Are folks ok with a= dependency on bundle? I would be happy to complete a draft in that direction. (That is, a general mmusic draft on asymmetric codecs, = not a rtcweb draft on MTI asymmetric codecs. I will move the discussio= n to mmusic after getting rtcweb opinions first.)

 

Some may consider this a bizarre corner case. However, for= hardware codecs, it is the norm not the exception to have asymmetric encod= er and decoder formats. Especially for new formats, which usually appear in hardware decoders well before hardware encoders are avai= lable. This happened for H.264, H.265, VP8, and virtually every popular cod= ec format in virtually every popular chipset.

 

Mo

 

On 11/23/13, 9:09 AM, Christer Holmberg <christer.holmberg@ericsson.com> = wrote:

Like some others, I think the must-decode-both-must-endcod= e-one alternative as such sounds interesting (whether it has any impact on = the licence/IPR issues I'll leave to others to speak for). However, I have big concerns over the proposal to indicate sendrecv for a = codec even if an entity is only able to receive/decode it. … Usage of= unidirectional, sendonly/recvonly, m- line would of course solve this, and= you might know that it is one option we are discussing in CLUE (for other reasons than MTI codec, though).

 

On 22 November 2013 16:20, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:

I gave this as an example of a possible way to do it, but = that means you need two separate m=3D lines - one for send and one for rece= ive. Seems strange to do this for something that you really want to be a single bi-directional stream.

 

On 11/22/13, 8:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

The bidirectional thing in O/A is the strange way to do th= ings.  Two lines is pretty intuitive.

 




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtcweb

 

--_000_7594FB04B1934943A5C02806D1A2204B1C554536ESESSMB209erics_-- From magnus.westerlund@ericsson.com Mon Nov 25 00:57:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296F91ACCD8 for ; Mon, 25 Nov 2013 00:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Nmuloe1PfcK for ; Mon, 25 Nov 2013 00:57:20 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BEB201ACC91 for ; Mon, 25 Nov 2013 00:57:19 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-d5-529310ee0377 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7F.46.03802.EE013925; Mon, 25 Nov 2013 09:57:18 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.328.9; Mon, 25 Nov 2013 09:57:17 +0100 Message-ID: <529310E0.80802@ericsson.com> Date: Mon, 25 Nov 2013 09:57:04 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20131122183155.C61FD75E001@rfc-editor.org> In-Reply-To: <20131122183155.C61FD75E001@rfc-editor.org> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20131122183155.C61FD75E001@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------050907020304000906010904" X-Brightmail-Tracker: H4sIAAAAAAAAA1VSfSzUYRzfc7+7n59r6vGWb7KZa1Qs0Wr8EVnY2uoPqZVZpZPfOB3ZeUlt FnXt7DrNonCsEpbX6GXJ1phDwpGdTtlR5FZGXpqX4obufo81/fd5vs/nbd/nYSi7IYEzI0lM YWWJYqmIFvKLIlYz9s3gvHCfEe0h/7o1hVUQOlZevswLQ5HCwzGsVJLGyvYHXhTGlVaN0km5 V9LH27oFmUgTpUTWDOCDsPZRxSd4O/R/qaeVSMjYYQ2CvkYNIoenCKpmVcjCssF7YczYwlMi huFjdxiYum4Z09gfhv5k0RbsiE+BPucZRei20FVk5AIc8G4YGOu3smB7HA1NnL+12d8Pxudz Ob612Wfpp4ay2AN2AlVWOOkWDFN3JjkphcOgJGeBR6RekHkzW5CLbNWb0tSbaAR7Q75ejgh2 hcbpEorgDDAantD/z4VmXIBgVKXixIC3gaJHywns8HMErXJf9cbumkqHkZpbUROCtrc/aHLI Q9BUpOBu+FhLwZq8mSISL+itmed68LEndI0oqH/ymltzG3l7oLCq30xiuOw6zS4ydoDBkvIN ig305HdyaYDLEDR8figgRkMIfncO0qTsewQTnZEEJ0Dj97tWau4d/GDG0Mxx7PF5qP26RFvC aOwGHWOhZJF+8FrfR5Oi7vCp2MBRKBwAk+vxpMMuMJV9EBC8A7QDvegxulCNrBLEEmns1QMv kPl7tr4yub9Bw30OGrST4YucbOamg8PtcKw4hb3MskmsLEqWKmWTNYjHWDtnonMV0TbFsBz5 a1ZcsdIqqczrqNRtEZk8qhcXHHUvXdYXi/V9Lt7KB9TZM/LwAmP/tLvhnvKR5IbP0MrRaw2u cyu1ktCgvKx33auBp7uPZ4ecmI4IyNdNsEeE3uknq7+l3o4pvO/ffsmteKleGt9ua9JVBobo QnPTWrayHlqVNlPET44T+3pSsmTxX340MyRsAwAA Subject: [rtcweb] Fwd: RFC 7064 on URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 08:57:23 -0000 --------------050907020304000906010904 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit For Your Information, Now both STUN (RFC7064) and TURN URI (7065) specification RFCs have been published. /Magnus Westerlund --------------050907020304000906010904 Content-Type: message/rfc822; name="RFC 7064 on URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="RFC 7064 on URI Scheme for the Session Traversal Utilities f"; filename*1="or NAT (STUN) Protocol.eml" X-Mozilla-Keys: Received: from sesbmg10.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.28) with Microsoft SMTP Server id 14.2.328.9; Fri, 22 Nov 2013 19:42:47 +0100 X-AuditID: c1b4fb3c-b7ff28e000000735-c6-528fa5a6cd26 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by sesbmg10.ericsson.net (Symantec Mail Security) with SMTP id 97.3E.01845.7A5AF825; Fri, 22 Nov 2013 19:42:47 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5941AE201; Fri, 22 Nov 2013 10:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1385145754; bh=twGU0Y8ofp6wGDogEn5WCKN/kOZ4d/MXdeYFZTfUtAU=; h=To:Subject:From:Message-Id:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Sender; b=crqQjXjMNWhTt2r8DvnyumsxBx1znmHB9IAkU1FnU2yuXFVibTKeWxRNEWC+P6wHh W3L36cxe3La+Bt7BHhv7/UrXdTQMe4NFGZDvl8HvU3Jgj/cVfwf1u+7doYKHXu83QV PFFKkQgujsH8Lx0TAfsphbt9cGLHdHXEiEx3vhoU= X-Original-To: ietf-announce@ietfa.amsl.com Delivered-To: ietf-announce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CF91AE1C7 for ; Fri, 22 Nov 2013 10:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoFGTZFhyPRo for ; Fri, 22 Nov 2013 10:42:28 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D17FA1AE1F7 for ; Fri, 22 Nov 2013 10:42:28 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C61FD75E001; Fri, 22 Nov 2013 10:31:55 -0800 (PST) To: , Subject: RFC 7064 on URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol From: Message-ID: <20131122183155.C61FD75E001@rfc-editor.org> Date: Fri, 22 Nov 2013 10:31:55 -0800 CC: , X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org Sender: IETF-Announce X-Brightmail-Tracker: H4sIAAAAAAAAA1VSaUgUYRj2m5mdHW1HP9etfbVCGonssqzASaQE+5FaUdaPSDrWHN2ldbSd VQyK7FTKXAsMI9FExbzLArOT7LLaUDusKE0rwtTIMq1MspkdS/ozvO9zvQ/Dx5D6atqPEdLt gk00WTnag6L8786bX17miFnY1xnEHx7o0vC3H5ZR/L7X7wj+Snudlj/xMJavL68g+Md1nfLn 2luSb3/+leDLcz4R/IeTozSfX/BTG65bOTL0jF6LNnmExQtWS5pgW7Bsm4fZMVipTen1Sne2 1dMZ6OmkI8idAbwEGotfI3WeAq2ddfQR5MHocQOC2sNHNeqShyCnpkirLBR2kvD74HVStcyF R1WDLjuF58D9jkxSdTQiyDp/bDw3EPIrWuWZkWcvqGkKUGEDtBeUEursCW09PwjFC7gEwbkX heOnXyHo+1qrVZdmBG0v97ksepwE95yDlJJqwIvBWb1GgX3wZqh+M0wrMI39IavYU4FZHAJP 2ke0atG58KB3gFAkJF4KeTc81Q4B8KukRaPOvuB88shVH2MMhaWN40eN4Hia5cJ1OBrO5p1y ddbhQwiyvzXTKhEBYx/7tUq+Tv4pH+/EqvBy6Lt2R6Pq9yMoGujQ5CLuDHKrRJMlQYpLSgxe GCTYLNslKVkMEgV7PZKfxc2Lv8Iuoe73wU3IlyG4yWx/gSNG7xmXHL/LbJLMW22pVkFqQlMZ ijOyIYHOdXqcaLILOwQhRbD9ZacxDAfs3RLZ6W0TEoX0BIvVPkETjHsTAkbHGdjZioaVUkxJ kiVR5R+g+czl/oFhpKfEZFHwM7IzFBFWROZU8V/O30f8GE3382GRm5ubXid3SLLY/+d7kZFB nA9rUFJ0FtH+71KvXIKQS2h9jyol7KYJyi8DRXUG9eyxiItWLmi51TUaujyaSgAmbG3N1ead n+OnZoqBQ3vL1kflsBH+Pzt6hty/GIpXeXklDMeWYXpm6OqNudnhyNsYUrGiqruylDNG3zRs mJXxJuKVo6HLeDr3QmYrSR7Xb2rZ0hzXUR2ZMjJvPbl7jLWOpNWuqbIJkZ+/H+AoyWwKnkPa JNMfmrj/rb8DAAA= Content-Type: text/plain Return-Path: ietf-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC003.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 A new Request for Comments is now available in online RFC libraries. RFC 7064 Title: URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol Author: S. Nandakumar, G. Salgueiro, P. Jones, M. Petit-Huguenin Status: Standards Track Stream: IETF Date: November 2013 Mailbox: snandaku@cisco.com, gsalguei@cisco.com, paulej@packetizer.com, petithug@acm.org Pages: 9 Characters: 15045 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-nandakumar-rtcweb-stun-uri-08.txt URL: http://www.rfc-editor.org/rfc/rfc7064.txt This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC --------------050907020304000906010904 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Mozilla-Keys: Received: from sessmg10.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.67) with Microsoft SMTP Server id 14.2.328.9; Sat, 23 Nov 2013 02:21:13 +0100 X-AuditID: c1b4fb3e-b7fe08e000001b5c-e3-52900308af39 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by sessmg10.ericsson.net (Symantec Mail Security) with SMTP id F5.37.07004.80300925; Sat, 23 Nov 2013 02:21:13 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D5A1AE356; Fri, 22 Nov 2013 17:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1385169664; bh=vnf6Zzw4+JUGlWxSkjGHkBR5jGCNTEYBQHocTU4vPjY=; h=To:Subject:From:Message-Id:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Sender; b=zUSurQT/z8fyg8Xc6EW/wpzckviDXPbbcNUCisdiJi0UyITPE0vi16sc9OzIYmtFy wPvqAaF4m5f3bcK4aKsiHsqh/pJX4ccko+PIpjef4NNMCpQBppVKynfmHmgAJQdbKg hs9e4c+8PdKGQBzsXlM7NfZUetH4ByrOepGlcvUU= X-Original-To: ietf-announce@ietfa.amsl.com Delivered-To: ietf-announce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AA91AE33F for ; Fri, 22 Nov 2013 17:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypRWH5LI6mzb for ; Fri, 22 Nov 2013 17:20:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1301AE2D4 for ; Fri, 22 Nov 2013 17:20:59 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1B70275E001; Fri, 22 Nov 2013 17:10:25 -0800 (PST) To: , Subject: RFC 7065 on Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers From: Message-ID: <20131123011025.1B70275E001@rfc-editor.org> Date: Fri, 22 Nov 2013 17:10:25 -0800 CC: , X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org Sender: IETF-Announce X-Brightmail-Tracker: H4sIAAAAAAAAA1VSa1BMYRje7+zZs6ecsz6nTW+5NJYfjTY0zHQMg3EZDGPojyjD4miXbTd7 NvIDyXWUamKVJpTNJJfWuBaTy5JJbXRThmpchlFCyv0ynNNB4883z/c+z/e8z/vNS6u5EiqE FpKdgsNmshoof5IMvWOM8FNnRY+7cnYQv6v7iYa/XXOc5Le1Pif4q80eLZ9dE8ufKy4h+AZP u3RUPFPzzS09BF+c8YbgXx78QfG5+V+105g53z4+oBaipf6TVwtWywbBMXbKCn9ze08qSizF yW0XMzQpKIPZi/xowBOgIKeVUvBgqGv3SNif5vBlBNcyrmmUiwtBXo8LyRcS+9Sw880NjfIk HGpP9SIZk3g03G3brZYxh8sRfCy1K5owyC2pkzS0hAfCGe9IpayH5vwiQsE6qH/1hZD9AbsR nH145E/nxwi+tmaTimkVgpzDdgUnQE7q7j5TPR4PvtMLZBiA4yA7f5MMKRwKewp1spjFUbCj azulpAyHS515pCxR44nguq5TEoyE7+77f4YKBl9jbd9QGGM4UlROKD2DILNpT1+dwfPghOtQ X2IG70SQ/qGKUogZ8KujSyv7M9KPdFTGKuWp8LqiUqPoUxEc7W7TZCFDAVKdRIGiIIoJ8ZHj xggOyypRtNvG2ATnOSTtxM0L36eUoeankV4UTBOGQNb1KzOa0620r95kNonm5Y4kqyB60RCa NASxfJhvEYfjTU5hnSAkCo6/7FCaNgBbgbKiuUEOIV5IXmOxOvtpgvbzIqAZg569JWtYMdGU IFriFb4aRdBXuro/IY602W1CSBBbIIuwLDIn2f75/N3gBjQsJIBFKpWKY6QMCRbn/3wnCqKR IYCtkV0Yi835r1OnFIKQQmiD0+QQTlM/FZKC9i2um/Z5c9atF4eXTfoZ9eUeBxetbvWBmcb6 phONy2/o5nagFMtGDxPBe19/0q+P/hZ4rFBTsdXbazrfbmGG62P4t4Jq/+ThibPWzi97F5Z7 3phTZGsMc7bkja2uvh8XPnt6+paHEUvMCy67i4z5A96nrXpcTG33xYzaanTHPho4wkCKZlPk aLVDNP0GTuRQB7wDAAA= Content-Type: text/plain Return-Path: ietf-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC016.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 A new Request for Comments is now available in online RFC libraries. RFC 7065 Title: Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers Author: M. Petit-Huguenin, S. Nandakumar, G. Salgueiro, P. Jones Status: Standards Track Stream: IETF Date: November 2013 Mailbox: petithug@acm.org, snandaku@cisco.com, gsalguei@cisco.com, paulej@packetizer.com Pages: 9 Characters: 16143 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-petithuguenin-behave-turn-uris-08.txt URL: http://www.rfc-editor.org/rfc/rfc7065.txt This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928). This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC --------------050907020304000906010904-- From magnus.westerlund@ericsson.com Mon Nov 25 04:34:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7446A1AD8F5 for ; Mon, 25 Nov 2013 04:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8Mdd2ZwSn6u for ; Mon, 25 Nov 2013 04:34:51 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CA78F1AD8E1 for ; Mon, 25 Nov 2013 04:34:50 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-2c-529343ea8e1c Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AE.A3.03802.AE343925; Mon, 25 Nov 2013 13:34:50 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.328.9; Mon, 25 Nov 2013 13:34:50 +0100 Message-ID: <529343DC.2070405@ericsson.com> Date: Mon, 25 Nov 2013 13:34:36 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stefan Slivinski , "rtcweb@ietf.org" References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> <528EBAB0.2010906@librevideo.org> <528EBD4C.8070504@librevideo.org> <02B96CE8-A6D9-4288-B052-FB54B07447FB@apple.com> <528FCA68.2070309@googlemail.com> <528FE08B.1020908@nostrum.com> <7949EED078736C4881C92F656DC6F6C130EA9E675F@ausmsex00.austin.kmvtechnologies.com> In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E675F@ausmsex00.austin.kmvtechnologies.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3VveV8+Qgg7+TVSzW/mtnt+jc+ZnZ gcljyZKfTB7XDzxmCmCK4rJJSc3JLEst0rdL4Mp4dO4Ja8Fe9oq53Y+YGxg72boYOTkkBEwk PvYvYISwxSQu3FsPFOfiEBI4xChxYPYGFghnOaPEnQ1rmUGqeAW0JXqvvWEBsVkEVCUary9l ArHZBCwkbv5oBJsqKhAscbV3HVS9oMTJmU/A6kUEQiUunLoEViMsYCbx4X4HO8SCHhaJfdPW gRVxCsRJ7N26HWgoB9BJ4hI9jUEgYWYBPYkpV1sYIWx5ieats8HmCwHd09DUwTqBUXAWknWz kLTMQtKygJF5FSN7bmJmTnq50SZGYFAe3PJbdQfjnXMihxilOViUxHk/vHUOEhJITyxJzU5N LUgtii8qzUktPsTIxMEp1cDoYVLLefKAjP7qiP9nJCx+ThTccMd/58qneQGPrJ6ebhf1q4zs XFhw8unm+XxSwgExXnnL7GQTZxkq95kF229V+br96F4HgylrrKNeTFB1PpSsxPJ4zbbaizZa yryLNoZs2VLKvUvv9EOu+L2G63+YJVw8VtBf/F/ddatbUPS7W13TXD3+HVujxFKckWioxVxU nAgABDPMVRgCAAA= Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 12:34:52 -0000 On 2013-11-23 02:38, Stefan Slivinski wrote: > Magnus Westerlund: please add the following proposal to the list: > > "must support both H.264 and VP8 decode and must support at least one of H.264 or VP8 encode" to the list of options > I have added the following to the Wiki. I hope you don't mind me slightly changing your proposal for clear wording: 12. MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8 Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stefan.lk.hakansson@ericsson.com Mon Nov 25 06:09:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB30A1ADD02 for ; Mon, 25 Nov 2013 06:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGM4g7ndfXHF for ; Mon, 25 Nov 2013 06:09:16 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7731ADBFF for ; Mon, 25 Nov 2013 06:09:16 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-ed-52935a0b70ee Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 08.75.23787.B0A53925; Mon, 25 Nov 2013 15:09:16 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Mon, 25 Nov 2013 15:09:15 +0100 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: "Mo Zanaty (mzanaty)" , Christer Holmberg , Martin Thomson , "Paul Giralt (pgiralt)" Thread-Topic: [rtcweb] Asymmetric codecs Thread-Index: AQHO6YOHQHY8Un59WEC1K24yFUskgQ== Date: Mon, 25 Nov 2013 14:09:15 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3F5B06@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+JvrS5P1OQgg97LLBbXzvxjtHjxYA6T xc2Gx4wWa/+1szuweEz5vZHVY+esu+weS5b8ZApgjuKySUnNySxLLdK3S+DK2PttKUvBV7mK F/cfsTcwbpDsYuTkkBAwkVhyeD0LhC0mceHeejYQW0jgEKPEofkmXYxcQPZiRomv374zdzFy cLAJBEs0/XUDiYsI7GWU+D2tmRGkgVlAXeLO4nPsILYwkH19xUVmEFtEQENiWf8NNghbT+Jl 11ewGhYBVYl1s5aALeYV8JVY2dLNDrFYT2LC9IdMIDYj0EHfT61hgpgvLnHryXwmiEMFJJbs Oc8MYYtKvHz8jxXCVpS4On05VL2BxPtz85khbG2JZQtfM0PsEpQ4OfMJywRG0VlIxs5C0jIL ScssJC0LGFlWMbLnJmbmpJcbbmIERsrBLb91dzCeOidyiFGag0VJnPfDW+cgIYH0xJLU7NTU gtSi+KLSnNTiQ4xMHJxSDYzJWxUv2ZV07t+1c6bJv045W2Xb0B+5Hf07WJYVFBx96frwp1zw 0oI7PK2vLQtvnLj5xvbT8ayZRnLs4Z25lv57pgglzOZtsD0x83RN+p8LV3by8a/aMCV1walD Qi6fWxv3rreV1vmdFKkcduWU3Y81rRfbp+ttilT60/Q9oHGD/CUDsQDRdy5KLMUZiYZazEXF iQBQBnn2YgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asymmetric codecs X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 14:09:19 -0000 On 2013-11-25 03:11, Mo Zanaty (mzanaty) wrote:=0A= > I started a draft on how to standardize support for asymmetric codecs=0A= > back in September. The primary motivation was decoding H.264 and H.265=0A= > while only encoding H.264. A secondary motivation, for rtcweb, was=0A= > decoding H.264 and VP8 while only encoding one of them, as Stefan=0A= > mentioned. I thought it would be a trivial thing to write up by the Oct.= =0A= > 6 deadline for MTI proposals. The draft is still incomplete and=0A= > unpublished because all solutions are ugly and overly complex for=0A= > something so seemingly trivial, just like bundle and unified plan. I now= =0A= > sympathize with Christer and Adam for how they arrived at those (not=0A= > exactly elegant) solutions, and agree with Martin that a pair of=0A= > (bundled) m-lines is the most viable (although not exactly elegant)=0A= > solution for asymmetric codecs.=0A= >=0A= > RFC 4317 drafts originally included asymmetric codecs until they were=0A= > removed in draft 02:=0A= > http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-mmusi= c-offer-answer-examples-02.txt=0A= >=0A= > They were removed for fear of issues with shared ports:=0A= > http://www.ietf.org/mail-archive/text/mmusic/2003-09.mail=0A= >=0A= > Now that we (almost) have bundle, can we resurrect asymmetric codecs=0A= > with separate sendonly and recvonly m-lines? Are folks ok with a=0A= > dependency on bundle? I would be happy to complete a draft in that=0A= > direction. (That is, a general mmusic draft on asymmetric codecs, not a= =0A= > rtcweb draft on MTI asymmetric codecs. I will move the discussion to=0A= > mmusic after getting rtcweb opinions first.)=0A= =0A= I've in the past been arguing that the WebRTC API, which is geared =0A= towards sending tracks, fits best with separate m-lines per direction. =0A= So I'm all for this (naturally the browser must be able to understand a =0A= sendrecv m-line if some legacy equipment signals that).=0A= =0A= I'm not sure what you mean by the dependency on bundle. Do you mean that = =0A= if bundle is not used the result would be that twice the number of ports = =0A= would be needed for a symmetrical session?=0A= =0A= >=0A= > Some may consider this a bizarre corner case. However, for hardware=0A= > codecs, it is the norm not the exception to have asymmetric encoder and= =0A= > decoder formats. Especially for new formats, which usually appear in=0A= > hardware decoders well before hardware encoders are available. This=0A= > happened for H.264, H.265, VP8, and virtually every popular codec format= =0A= > in virtually every popular chipset.=0A= >=0A= > Mo=0A= >=0A= > On 11/23/13, 9:09 AM, Christer Holmberg = =0A= > wrote:=0A= > Like some others, I think the must-decode-both-must-endcode-one=0A= > alternative as such sounds interesting (whether it has any impact on the= =0A= > licence/IPR issues I'll leave to others to speak for). However, I have=0A= > big concerns over the proposal to indicate sendrecv for a codec even if= =0A= > an entity is only able to receive/decode it. =85 Usage of unidirectional,= =0A= > sendonly/recvonly, m- line would of course solve this, and you might=0A= > know that it is one option we are discussing in CLUE (for other reasons= =0A= > than MTI codec, though).=0A= > On 22 November 2013 16:20, Paul Giralt (pgiralt) wrot= e:=0A= > I gave this as an example of a possible way to do it, but that means you= =0A= > need two separate m=3D lines - one for send and one for receive. Seems=0A= > strange to do this for something that you really want to be a single=0A= > bi-directional stream.=0A= >=0A= > On 11/22/13, 8:03 PM, Martin Thomson wrote:=0A= > The bidirectional thing in O/A is the strange way to do things. Two=0A= > lines is pretty intuitive.=0A= >=0A= =0A= From magnus.westerlund@ericsson.com Mon Nov 25 06:20:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16431AD9AD for ; Mon, 25 Nov 2013 06:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTS5OlO7ItNP for ; Mon, 25 Nov 2013 06:20:08 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA9C1AD9AC for ; Mon, 25 Nov 2013 06:20:07 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-f7-52935c9760f0 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9A.E6.23787.79C53925; Mon, 25 Nov 2013 15:20:07 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.328.9; Mon, 25 Nov 2013 15:20:06 +0100 Message-ID: <52935C89.5040408@ericsson.com> Date: Mon, 25 Nov 2013 15:19:53 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvre70mMlBBut+mFms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJdNDWwFZ7gqvi05xt7AeIiji5GTQ0LAROLg3HssELaYxIV7 69m6GLk4hAQOMUqsXbedHcJZzihx+Pc6RpAqXgFtiYfne5lAbBYBVYm9V66BdbMJWEjc/NHI BmKLCgRLXO1dxwxRLyhxcuYTsBoRAXWJyw8vsIPYwgK2En8X7WLtYuQA2iwu0dMYBBJmFtCT mHK1hRHClpdo3jobbIwQ0NqGpg7WCYz8s5BMnYWkZRaSlgWMzKsY2XMTM3PSyw03MQLD6eCW 37o7GE+dEznEKM3BoiTO++Gtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtL2pG+qk4wc H+mGL9vBqFG5YvGeO477ObSe++5V+r31ikzmTekTTmeftRc+4Z30XvXFgVcFXT5Jr/RT6lsE j32986931XahjdudQvsYxO7Eer/yvGl85Nq6/rliTVwHrLp+q2utfB0QNXHLlNWKdVfMrO+k Ok7ddK82Rm/1zys5Vy/JMUb/yVFiKc5INNRiLipOBAA5FAqE9QEAAA== Subject: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 14:20:09 -0000 Hi, I would like to draw your attention to the following two alternative: 10. All entities SHOULD support both H.264 and VP8. All entities MUST at least implement one of those. Entities that do not support both H.264 and VP8 MUST implement H.261. 11. MUST implement at least two of {VP8, H.264 CBP, H.263} I would note that 10 and 11 are equivalent on the MUST level. The only thing that separates 10 out is the SHOULD implement both H.264 and VP8. Thus my question to the WG and especially the ones proposing 10 and 11. Would anyone disagree with removing alternative 10. in favor of 11.? Just trying to avoid having two alternatives that are extremely close to each other. My thinking is that if we manage to select any MTI, i.e. MUST statements, we can discuss what SHOULDs and RECOMMENDATIONs that we want to make in addition. Cheers Magnus Westerlund (As WG chair) ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From derhoermi@gmx.net Mon Nov 25 06:29:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6BB1ADE86 for ; Mon, 25 Nov 2013 06:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKWK12ib64Ar for ; Mon, 25 Nov 2013 06:29:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id A1C5F1ADDCA for ; Mon, 25 Nov 2013 06:29:48 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.22.235]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0LeBPM-1VJb2V3zzQ-00pwCw for ; Mon, 25 Nov 2013 15:29:48 +0100 From: Bjoern Hoehrmann To: Magnus Westerlund Date: Mon, 25 Nov 2013 15:29:49 +0100 Message-ID: References: <52935C89.5040408@ericsson.com> In-Reply-To: <52935C89.5040408@ericsson.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ALUa8xBKcjS1MtmoXkVBT6A48IVeYI8P9rcBtM3fgh46ygC6YXQ EsofuLGypH0/ggoC8vu/8y+9BTCMT+Eb6sxbBaRFk0oTGpLJ09AOIOmFhazxIV6o9j1AyiV mOCu0/RRZrK8V1jod272nUE7F8mwDQyUPgOhZdViYxuE9HZYPr8Hxm0jkZf+sGj7ljjEuqt Ya1uxCy7LEUBD16sInSGw== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 14:29:52 -0000 * Magnus Westerlund wrote: >I would like to draw your attention to the following two alternative: > >10. All entities SHOULD support both H.264 and VP8. All entities MUST > at least implement one of those. Entities that do not support both > H.264 and VP8 MUST implement H.261. > >11. MUST implement at least two of {VP8, H.264 CBP, H.263} > >I would note that 10 and 11 are equivalent on the MUST level. The only >thing that separates 10 out is the SHOULD implement both H.264 and VP8. No, 10 has H.261 as a MUST in a certain circumstance, 11 does not. >Just trying to avoid having two alternatives that are extremely close to >each other. My thinking is that if we manage to select any MTI, i.e. >MUST statements, we can discuss what SHOULDs and RECOMMENDATIONs that we >want to make in addition. If the Working Group decides to conduct a vote on this matter, I think questions about "SHOULD"-level requirements should be left out of it. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From lgeyser@gmail.com Mon Nov 25 06:30:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03441AD9AD for ; Mon, 25 Nov 2013 06:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaTOmZpuKbVA for ; Mon, 25 Nov 2013 06:30:11 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5C11ADDBF for ; Mon, 25 Nov 2013 06:30:11 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id x18so3196691lbi.7 for ; Mon, 25 Nov 2013 06:30:10 -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=KbmeZh2x29iB5rYd7+SqkHDSOYECCs2jsuIHqPUSMnE=; b=miJ3Tzq8p1c4hOukLizHs1Hua27UuNhBx6PonHHn8W+TgZ4w8aZdGYfpcOteB7Kc+H Vg6OFZr2eVlqL4+sKnajtjar73J/l44USd5Sm/4dVeXnNPzNibjUXr52QB6wa7sCmlny p1enbuf/xPbPUVc+tYTeT+kPnznXZWE1k2LqHD1G13tQqB151rfISJ0y9UcbMExddLq9 5Ba/IUbz0Zixro2MJLOK/jecSnTwzW89rmJx21+3QcYulMY+aGWpdqsMkKvgWde6TewK vL6ECEIedaZWzm0hhKn20/kR/OM87CFZQyCLI26S8mQoY9cbZfX5yhex/HcPWfdLFdv/ HJow== MIME-Version: 1.0 X-Received: by 10.152.3.10 with SMTP id 10mr1698198lay.35.1385389810779; Mon, 25 Nov 2013 06:30:10 -0800 (PST) Received: by 10.114.168.70 with HTTP; Mon, 25 Nov 2013 06:30:10 -0800 (PST) In-Reply-To: <52935C89.5040408@ericsson.com> References: <52935C89.5040408@ericsson.com> Date: Mon, 25 Nov 2013 16:30:10 +0200 Message-ID: From: Leon Geyser To: Magnus Westerlund Content-Type: multipart/alternative; boundary=089e014941f48c0ac004ec01333a Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 14:30:14 -0000 --089e014941f48c0ac004ec01333a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Magnus, Was H.263 a typo? I agree that 10 can be changed to: 10. MUST implement at least two of {VP8, H.264 CBP, H.261} On 25 November 2013 16:19, Magnus Westerlund wrote: > Hi, > > I would like to draw your attention to the following two alternative: > > 10. All entities SHOULD support both H.264 and VP8. All entities MUST > at least implement one of those. Entities that do not support both > H.264 and VP8 MUST implement H.261. > > 11. MUST implement at least two of {VP8, H.264 CBP, H.263} > > I would note that 10 and 11 are equivalent on the MUST level. The only > thing that separates 10 out is the SHOULD implement both H.264 and VP8. > > Thus my question to the WG and especially the ones proposing 10 and 11. > Would anyone disagree with removing alternative 10. in favor of 11.? > > Just trying to avoid having two alternatives that are extremely close to > each other. My thinking is that if we manage to select any MTI, i.e. > MUST statements, we can discuss what SHOULDs and RECOMMENDATIONs that we > want to make in addition. > > Cheers > > Magnus Westerlund > (As WG chair) > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e014941f48c0ac004ec01333a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Magnus,

Was H.263 a typo?
I agree that 10 can be changed to:
10. MUST implement at least two of= {VP8, H.264 CBP, H.261}



On 25 N= ovember 2013 16:19, Magnus Westerlund <magnus.westerlund@eric= sson.com> wrote:
Hi,

I would like to draw your attention to the following two alternative:

10. All entities SHOULD support both H.264 and VP8. All entities MUST
=A0 =A0 at least implement one of those. Entities that do not support both<= br> =A0 =A0 H.264 and VP8 MUST implement H.261.

11. MUST implement at least two of {VP8, H.264 CBP, H.263}

I would note that 10 and 11 are equivalent on the MUST level. The only
thing that separates 10 out is the SHOULD implement both H.264 and VP8.

Thus my question to the WG and especially the ones proposing 10 and 11.
Would anyone disagree with removing alternative 10. in favor of 11.?

Just trying to avoid having two alternatives that are extremely close to each other. My thinking is that if we manage to select any MTI, i.e.
MUST statements, we can discuss what SHOULDs and RECOMMENDATIONs that we want to make in addition.

Cheers

Magnus Westerlund
(As WG chair)

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e014941f48c0ac004ec01333a-- From christer.holmberg@ericsson.com Mon Nov 25 06:30:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F021ADDCA for ; Mon, 25 Nov 2013 06:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecOfTUopq04O for ; Mon, 25 Nov 2013 06:30:51 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6121ADDBD for ; Mon, 25 Nov 2013 06:30:51 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-d3-52935f1adb9c Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 71.B2.03802.A1F53925; Mon, 25 Nov 2013 15:30:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Mon, 25 Nov 2013 15:30:50 +0100 From: Christer Holmberg To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? Thread-Index: AQHO6el1mz3gk3A5REugikqA/hVWTJo2AUSQ Date: Mon, 25 Nov 2013 14:30:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C555F8A@ESESSMB209.ericsson.se> References: <52935C89.5040408@ericsson.com> In-Reply-To: <52935C89.5040408@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvra5U/OQgg9v/zSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpzbV9gLevkr/t1+ydLAuJCni5GDQ0LAROLkn+guRk4gU0zi wr31bF2MXBxCAocYJbZNecIC4SxmlPjb3sYK0sAmYCHR/U8bpEFEIFbi/eyrrCC2sICXxJ0V D5gg4t4Sf77PgrKNJJrnbwBrZRFQldgyBaycV8BXYsunFrASIQFtibbNLewgNqeAjsT3ZQ+Z QWxGoHu+n1oDVsMsIC5x68l8Jog7BSSW7DnPDGGLSrx8/I8VwlaU+PhqHyNEvZ7EjalT2CBs bYllC18zQ+wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxsucmZuaklxttYgSG/MEtv1V3 MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjGmqhXGeTCztmp7H 363tkfuofDLm0j79SP51c2V0b/yv/XDc1f9D/3FNQeUu29bODaarn+j8VLfxDQjTWzu9tr1j 2uxVh/cmXIvpDSt4GMJQ/+aZk5OIivR88z0FxzqOXQvkOZ4Y8mZ/ifq+yCoGFkXRtKWGDrU8 az1eWe2InjJVwX6H1PEpSizFGYmGWsxFxYkAg9eNz0cCAAA= Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 14:30:53 -0000 Hi, I guess it's a spelling error, but based on your text below another thing t= hat separates 10 and 11 is that 10 talks about H.261 while 11 talks about H= .263. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlun= d Sent: 25. marraskuuta 2013 16:20 To: rtcweb@ietf.org Subject: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? Hi, I would like to draw your attention to the following two alternative: 10. All entities SHOULD support both H.264 and VP8. All entities MUST at least implement one of those. Entities that do not support both H.264 and VP8 MUST implement H.261. 11. MUST implement at least two of {VP8, H.264 CBP, H.263} I would note that 10 and 11 are equivalent on the MUST level. The only thin= g that separates 10 out is the SHOULD implement both H.264 and VP8. Thus my question to the WG and especially the ones proposing 10 and 11. Would anyone disagree with removing alternative 10. in favor of 11.? Just trying to avoid having two alternatives that are extremely close to ea= ch other. My thinking is that if we manage to select any MTI, i.e. MUST statements, we can discuss what SHOULDs and RECOMMENDATIONs that we wa= nt to make in addition. Cheers Magnus Westerlund (As WG chair) ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Mon Nov 25 06:43:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9401ADE87 for ; Mon, 25 Nov 2013 06:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhzUyuIgUCzl for ; Mon, 25 Nov 2013 06:43:33 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 635F51AD947 for ; Mon, 25 Nov 2013 06:43:33 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-fc-5293621425a2 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 83.34.03802.41263925; Mon, 25 Nov 2013 15:43:33 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Mon, 25 Nov 2013 15:43:32 +0100 Message-ID: <52936207.5040704@ericsson.com> Date: Mon, 25 Nov 2013 15:43:19 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Leon Geyser References: <52935C89.5040408@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvra5o0uQgg5nHOS26V89is1j7r53d gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4/fAzS8Ev0YrNzQcZGxhfC3QxcnJICJhI PPvxmgXCFpO4cG89WxcjF4eQwCFGia+vdjNDOMsZJXZNvsoMUsUroC3xcdVKMJtFQFVia991 VhCbTcBC4uaPRjYQW1QgWOJq7zqoekGJkzOfgG0QEVCW+PhtC1gNs4C6xJ3F59hBbGEBL4kl D+eA2UICBRLX/q8Cm8kpECjx/McNoF4OoOvEJXoagyBa9SSmXG1hhLDlJZq3zmaGaNWWaGjq YJ3AKDQLyeZZSFpmIWlZwMi8ipE9NzEzJ73caBMjMFQPbvmtuoPxzjmRQ4zSHCxK4rwf3joH CQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAUCw9Y+lot4QF/13KfqRmV7Q01thYl7nPmM/7c /sch79L6O7Whn4Kfpc2Sui4qr7riYFNO05bJWXkBJQznHOu3R3XZ1DxeW3/lq/FH7ucuysa1 5e9XsPLb3F79Z3V5pd925u0fZolsW+L0ZA6/xyOX9TVFl+p0fk+bd+1Hj/5ar4LG5xcLZecq sRRnJBpqMRcVJwIA4445MyMCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 14:43:36 -0000 On 2013-11-25 15:30, Leon Geyser wrote: > Hi Magnus, > > Was H.263 a typo? > I agree that 10 can be changed to: > 10. MUST implement at least two of {VP8, H.264 CBP, H.261} Sorry, I did a mistake in this call. I missed that 10 and 11 talked about H.261 and H.263 respectively. I think the above question of writing 10 in the above proposed format is then the relevant question to the WG. Cheers Magnus > > > > On 25 November 2013 16:19, Magnus Westerlund > > > wrote: > > Hi, > > I would like to draw your attention to the following two alternative: > > 10. All entities SHOULD support both H.264 and VP8. All entities MUST > at least implement one of those. Entities that do not support both > H.264 and VP8 MUST implement H.261. > > 11. MUST implement at least two of {VP8, H.264 CBP, H.263} > > I would note that 10 and 11 are equivalent on the MUST level. The only > thing that separates 10 out is the SHOULD implement both H.264 and VP8. > > Thus my question to the WG and especially the ones proposing 10 and 11. > Would anyone disagree with removing alternative 10. in favor of 11.? > > Just trying to avoid having two alternatives that are extremely close to > each other. My thinking is that if we manage to select any MTI, i.e. > MUST statements, we can discuss what SHOULDs and RECOMMENDATIONs that we > want to make in addition. > > Cheers > > Magnus Westerlund > (As WG chair) > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lorenzo@meetecho.com Mon Nov 25 06:43:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693EF1ADEA6 for ; Mon, 25 Nov 2013 06:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbA6c_ujdjD4 for ; Mon, 25 Nov 2013 06:43:55 -0800 (PST) Received: from smtpdg12.aruba.it (smtpdg4.aruba.it [62.149.158.234]) by ietfa.amsl.com (Postfix) with ESMTP id A8CE01ADC03 for ; Mon, 25 Nov 2013 06:43:54 -0800 (PST) Received: from lminiero ([143.225.229.166]) by smtpcmd04.ad.aruba.it with bizsmtp id tqjs1m0153c3Lvj01qjsxz; Mon, 25 Nov 2013 15:43:53 +0100 Date: Mon, 25 Nov 2013 15:43:52 +0100 From: Lorenzo Miniero To: Martin Thomson Message-ID: <20131125154352.054e60cd@lminiero> In-Reply-To: References: <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 14:43:57 -0000 Il giorno Fri, 22 Nov 2013 10:41:07 -0800 Martin Thomson ha scritto: > Actually, this removes some of the complication. At worst, it just > moves it. >=20 > This concentrates all of the logic at the DTLS layer. If you choose > to treat it so, ICE no longer needs to play any role in determining > consent. >=20 Apologies for this late comment, but I only now read the draft. I agree with you that it makes more sense to handle content freshness in DTLS, especially since, as the draft says, you wouldn't send data until the DTLS handshake has completed anyway, and this would remove the need for all those connectivity checks. The only doubt I have is sec.3: is specifying an ALPN really necessary, if "any DTLS message is sufficient to refresh consent"? are you envisaging a scenario where it's the DTLS stack that filters unwanted incoming packets (e.g., SCTP where you only want RTP), or would it be there for a different reason? Thanks, Lorenzo > DTLS already has a consent mechanism in place (that's the function of > the cookie in the handshake, a feature we don't tend to use when > running ICE). This expands that to include an ongoing process. The > only complications come from the interaction between DTLS and SRTP, a > relationship that is already complicated somewhat on the keying layer. >=20 > I don't know whether anyone implementing DTLS-SRTP also implements > DTLS renegotiation and EKT at the same time, but those are the areas > where things get tricky. Otherwise, you have a DTLS (or DTLS-SRTP) > layer that manages consent. >=20 > On 22 November 2013 10:08, tim panton wrote: > > > > On 22 Nov 2013, at 09:55, Martin Thomson > > wrote: > > > >> I know that I've been a fan of consent via ICE, but with the > >> decision in Berlin to move to DTLS only, several of us have > >> observed that perhaps RFC 6520 might be a better alternative. > >> > >> We've put together an exploration of the idea here: > >> > >> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00 > >> > >> The best part of this is that it changes the dynamics (for the > >> better, I think). You don't need to send extra packets if you are > >> actively using the flow. That means that 1:1 sessions won't need > >> to spend extra cycles or bytes on keeping the session live. > >> > >> There are some gotchas for multiparty sessions, but I believe > >> those to be manageable. > > > > I have misgivings about this - It feels to me to force a mixing of > > layers in the packet handling - At the moment in the implementation > > I=E2=80=99m familiar with, the ICE/DTLS/SRTP state machines are almost > > completely isolated. This proposal seems (at first glance) to make > > them intertwine in a quite complex way - consent is generated (if I > > understand it correctly) by any of the layers. Likewise each of the > > layers needs to know if the others have generated consent granting > > packets. > > > > If we are to blur the boundaries like this, we should go the whole > > hog and get some real benefits - like for example remove some > > round-trips in session establishment by (say) carrying the DTLS > > hello in the same STUN packet as has ICE USE-CANDIDATE set - for > > example. > > > > I=E2=80=99m against including this sort of change at this stage in the > > standards process. > > > > T. > > > > > >> _______________________________________________ > >> 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 From mzanaty@cisco.com Mon Nov 25 08:13:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E871ADF77 for ; Mon, 25 Nov 2013 08:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dpHa8dGe-Dq for ; Mon, 25 Nov 2013 08:13:05 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9DD1ADF50 for ; Mon, 25 Nov 2013 08:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17241; q=dns/txt; s=iport; t=1385395985; x=1386605585; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SRzoKkHnVRCjN7SI0Rt66mIP2+u41sxaZ3GCJuPqfSQ=; b=F+zFMHVFElOdakjxEw9wlJAUKI3VmbbzBe8CiTJHsSuBgcJvudQ8PcAN Gk3R62Nz9woUQw8PGa1hi4HI2N2fI0xiGIRFU713uvQXVP5hffSFjBZGg MzTVPDrov4FLNJ/0R6bsIffNJhVlc2jEdGDF3QzrA5zjxkgvhyFkmVoOt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8GAFB2k1KtJXG8/2dsb2JhbABZgkNEOFOzV4hPgSoWdIIlAQEBBC1MEAIBCBEEAQEoByERFAkIAgQBDQUJEodUAw8NtV8NiAkXjHiBPgEBTwYBhDMDlimBa4EwiyqFOIMogXE5 X-IronPort-AV: E=Sophos;i="4.93,768,1378857600"; d="scan'208,217";a="2066396" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 25 Nov 2013 16:13:05 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAPGD5dm002247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 16:13:05 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 25 Nov 2013 10:13:04 -0600 From: "Mo Zanaty (mzanaty)" To: Christer Holmberg , Martin Thomson , "Paul Giralt (pgiralt)" Thread-Topic: Asymmetric codecs Thread-Index: AQHO6fk4srko9WvZvkKiVv6I72CdiA== Date: Mon, 25 Nov 2013 16:13:04 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.150.30.48] Content-Type: multipart/alternative; boundary="_000_CEB8D9AC1F15Emzanatyciscocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asymmetric codecs X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 16:13:08 -0000 --_000_CEB8D9AC1F15Emzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Re: MTI, I don=92t think asymmetric codecs will solve all the MTI issues. H= owever, it may solve some practical deployment issues regardless of MTI dec= isions. If products have a decoder but no encoder, it may help to express t= hat. For example, Chrome can expose its H.264 decoder for webrtc despite no= encoder. Hardware products can expose their VP8 decoder for webrtc despite= no encoder. Re: SDP, if you want asymmetric codecs over the same port, is it ok to mand= ate bundle to achieve this? I started with a single sendrecv m-line with al= l payload types that can be decoded but not necessarily encoded, as Justin = suggested. That would not require bundle. However, it gets ugly when adding= extra signaling for which payload types can=92t be encoded and multiple O/= A rounds for interop with arbitrary peers. The complexity approached bundle= , so I ended up with separate sendonly/recvonly m-lines, as Martin suggeste= d. On 11/25/13, 2:24 AM, Christer Holmberg > wrote: Hi, First, from a pure MTI codec perspective, the question is whether usage of = asymmetric codecs would solve the issues that people have. Second, from an SDP OA/BUNDLE perspective, I don=92t think we can mandate u= sage of BUNDLE. And, even if we did, in the initial Offer you still need to= assign unique port values for each m- line (as agreed in Vancouver). =85unless, of course, you assign an SDP =91bundle-only=92 attribute to all = m- lines with asymmetric codecs. Regards, Christer From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] Sent: 25. marraskuuta 2013 4:11 To: Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt) Cc: rtcweb@ietf.org Subject: Asymmetric codecs I started a draft on how to standardize support for asymmetric codecs back = in September. The primary motivation was decoding H.264 and H.265 while onl= y encoding H.264. A secondary motivation, for rtcweb, was decoding H.264 an= d VP8 while only encoding one of them, as Stefan mentioned. I thought it wo= uld be a trivial thing to write up by the Oct. 6 deadline for MTI proposals= . The draft is still incomplete and unpublished because all solutions are u= gly and overly complex for something so seemingly trivial, just like bundle= and unified plan. I now sympathize with Christer and Adam for how they arr= ived at those (not exactly elegant) solutions, and agree with Martin that a= pair of (bundled) m-lines is the most viable (although not exactly elegant= ) solution for asymmetric codecs. RFC 4317 drafts originally included asymmetric codecs until they were remov= ed in draft 02: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-mmusic-= offer-answer-examples-02.txt They were removed for fear of issues with shared ports: http://www.ietf.org/mail-archive/text/mmusic/2003-09.mail Now that we (almost) have bundle, can we resurrect asymmetric codecs with s= eparate sendonly and recvonly m-lines? Are folks ok with a dependency on bu= ndle? I would be happy to complete a draft in that direction. (That is, a g= eneral mmusic draft on asymmetric codecs, not a rtcweb draft on MTI asymmet= ric codecs. I will move the discussion to mmusic after getting rtcweb opini= ons first.) Some may consider this a bizarre corner case. However, for hardware codecs,= it is the norm not the exception to have asymmetric encoder and decoder fo= rmats. Especially for new formats, which usually appear in hardware decoder= s well before hardware encoders are available. This happened for H.264, H.2= 65, VP8, and virtually every popular codec format in virtually every popula= r chipset. Mo On 11/23/13, 9:09 AM, Christer Holmberg > wrote: Like some others, I think the must-decode-both-must-endcode-one alternative= as such sounds interesting (whether it has any impact on the licence/IPR i= ssues I'll leave to others to speak for). However, I have big concerns over= the proposal to indicate sendrecv for a codec even if an entity is only ab= le to receive/decode it. =85 Usage of unidirectional, sendonly/recvonly, m-= line would of course solve this, and you might know that it is one option = we are discussing in CLUE (for other reasons than MTI codec, though). On 22 November 2013 16:20, Paul Giralt (pgiralt) > wrote: I gave this as an example of a possible way to do it, but that means you ne= ed two separate m=3D lines - one for send and one for receive. Seems strang= e to do this for something that you really want to be a single bi-direction= al stream. On 11/22/13, 8:03 PM, Martin Thomson > wrote: The bidirectional thing in O/A is the strange way to do things. Two lines = is pretty intuitive. --_000_CEB8D9AC1F15Emzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Re: MTI, I don=92t think asymmetric codecs will solve all the MTI issu= es. However, it may solve some practical deployment issues regardless of MT= I decisions. If products have a decoder but no encoder, it may help to expr= ess that. For example, Chrome can expose its H.264 decoder for webrtc despite no encoder. Hardware products = can expose their VP8 decoder for webrtc despite no encoder.

Re: SDP, if you want asymmetric codecs over the same port, is it ok to= mandate bundle to achieve this? I started with a single sendrecv m-line wi= th all payload types that can be decoded but not necessarily encoded, as Ju= stin suggested. That would not require bundle. However, it gets ugly when adding extra signaling for which payloa= d types can=92t be encoded and multiple O/A rounds for interop with arbitra= ry peers. The complexity approached bundle, so I ended up with separate sen= donly/recvonly m-lines, as Martin suggested.

On 11/25/13, 2:24 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

First, from a pure MTI codec perspe= ctive, the question is whether usage of asymmetric codecs would solve the i= ssues that people have.

Second, from an SDP OA/BUNDLE persp= ective, I don=92t think we can mandate usage of BUNDLE. And, even if we did, in the initial Offer you still= need to assign unique port values for each m- line (as agreed in Vancouver= ).

=85unless, of course, you assign an= SDP =91bundle-only=92 attribute to all m- lines with asymmetric codecs.

Regards,

Christer

 

From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
Sent: 25. marraskuuta 2013 4:11
To: Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
Cc: rtcweb@ietf.org
Subject: Asymmetric codecs

 

I started a draft on how to standardize support for asymmetric co= decs back in September. The primary motivation was decoding H.264 and H.265= while only encoding H.264. A secondary motivation, for rtcweb, was decoding H.264 and VP8 while only encoding one= of them, as Stefan mentioned. I thought it would be a trivial thing to wri= te up by the Oct. 6 deadline for MTI proposals. The draft is still incomple= te and unpublished because all solutions are ugly and overly complex for something so seemingly trivial, just like = bundle and unified plan. I now sympathize with Christer and Adam for how th= ey arrived at those (not exactly elegant) solutions, and agree with Martin = that a pair of (bundled) m-lines is the most viable (although not exactly elegant) solution for asymmetric = codecs.

 

RFC 4317 drafts originally included asymmetric codecs until they = were removed in draft 02:

 

They were removed for fear of issues with shared ports:

 

Now = that we (almost) have bundle, can we resurrect asymmetric codecs with separ= ate sendonly and recvonly m-lines? Are folks ok with a dependency on bundle= ? I would be happy to complete a draft in that direction. (That is, a general mmusic draft on asymmetric codecs, = not a rtcweb draft on MTI asymmetric codecs. I will move the discussio= n to mmusic after getting rtcweb opinions first.)

 

Some may consider this a bizarre corner case. However, for hardwa= re codecs, it is the norm not the exception to have asymmetric encoder and = decoder formats. Especially for new formats, which usually appear in hardware decoders well before hardware en= coders are available. This happened for H.264, H.265, VP8, and virtually ev= ery popular codec format in virtually every popular chipset.

 

Mo

 

On 1= 1/23/13, 9:09 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Like= some others, I think the must-decode-both-must-endcode-one alternative as = such sounds interesting (whether it has any impact on the licence/IPR issue= s I'll leave to others to speak for). However, I have big concerns over the proposal to indicate sendrecv for a = codec even if an entity is only able to receive/decode it. =85 Usage of uni= directional, sendonly/recvonly, m- line would of course solve this, and you= might know that it is one option we are discussing in CLUE (for other reasons than MTI codec, though).

&nbs= p;

On 2= 2 November 2013 16:20, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:

I ga= ve this as an example of a possible way to do it, but that means you need t= wo separate m=3D lines - one for send and one for receive. Seems strange to= do this for something that you really want to be a single bi-directional stream.

 

On 1= 1/22/13, 8:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

The = bidirectional thing in O/A is the strange way to do things.  Two lines= is pretty intuitive.

 

 --_000_CEB8D9AC1F15Emzanatyciscocom_-- From mzanaty@cisco.com Mon Nov 25 08:14:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363131ADF8C for ; Mon, 25 Nov 2013 08:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnzV96R1XUEw for ; Mon, 25 Nov 2013 08:14:32 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37E1ADF88 for ; Mon, 25 Nov 2013 08:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=288; q=dns/txt; s=iport; t=1385396072; x=1386605672; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GT0P1QhQExBkwUor4ypVgjsI1WX3sFQ5hT1l8BN7Wh8=; b=HukcvUux+RjYdcypnkYwMiHtQZVRT5qFYXotmlhlt1Swl5W5nA+CA7tO Hy7yiAD8Js1SRrqvhWllCP4q5C62aL06N6RLUM/aV7Aoef/kyaSOSoU75 +yKEY2Sfqw1MUYYJpgTMaZhFkrEyt+vFyRqZmja3XddTryYNiEIInYdbE I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAAR3k1KtJXG//2dsb2JhbABZgweBC7wmgSoWdIImAQEEeRACAQhGMiUCBAENBYgBvgQXjwcHhDMDiQqPCpISgyiCKg X-IronPort-AV: E=Sophos;i="4.93,768,1378857600"; d="scan'208";a="2063856" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-4.cisco.com with ESMTP; 25 Nov 2013 16:14:32 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAPGEWwF000417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 16:14:32 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 25 Nov 2013 10:14:32 -0600 From: "Mo Zanaty (mzanaty)" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Christer Holmberg , Martin Thomson , "Paul Giralt (pgiralt)" Thread-Topic: [rtcweb] Asymmetric codecs Thread-Index: AQHO6flsKdvHgHey70mbUw906FaQwA== Date: Mon, 25 Nov 2013 16:14:31 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C3F5B06@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C3F5B06@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.150.30.48] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8553C67CCF5A0B4880C50753626889FC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asymmetric codecs X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 16:14:33 -0000 On 11/25/13, 9:09 AM, Stefan H=E5kansson LK wrote: I'm not sure what you mean by the dependency on bundle. Do you mean that if bundle is not used the result would be that twice the number of ports would be needed for a symmetrical session? Yes. From martin.thomson@gmail.com Mon Nov 25 09:21:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545061ADF64 for ; Mon, 25 Nov 2013 09:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TGNx3qAN_Lt for ; Mon, 25 Nov 2013 09:21:15 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1FA1ADF4F for ; Mon, 25 Nov 2013 09:21:06 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so2314342wgh.5 for ; Mon, 25 Nov 2013 09:21:06 -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=6taQvWF0H37wkg7cqKrWJvSG38Sg6QNNdcbyTstdKL0=; b=fwjZ+iloNhn/218TPY+J9UtKykdt1kfUsl0uB5XQk2vU+6JRkHsOmCsw7paUrDr+pN YhWGIpW9klSToIekUgSkE3Oe36iknYuf5DnDX/MfO4IguwkRBw+RHhg5Mt2WzmEtJSGi sImh5+ODDpLJQN3je7yE2KtEANOun8LcC28wa2yOTjqO0he+Yziy42xPV/kqthb1UBfi KUDBEP6g4gHcAmihfci+vu0T4H6obZtoWoRtYV/ot1jHQy5BSfmx6b30I8mSlx/TE2ST bNkZpqyXmu4cEaUovQ9d5ymTSWH2VDkA0MsMCXuZTxFR65M33L0lBT/ZmndxswW5E++v FJ6A== MIME-Version: 1.0 X-Received: by 10.180.105.232 with SMTP id gp8mr10417522wib.22.1385400066030; Mon, 25 Nov 2013 09:21:06 -0800 (PST) Received: by 10.227.134.195 with HTTP; Mon, 25 Nov 2013 09:21:05 -0800 (PST) In-Reply-To: <20131125154352.054e60cd@lminiero> References: <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com> <20131125154352.054e60cd@lminiero> Date: Mon, 25 Nov 2013 09:21:05 -0800 Message-ID: From: Martin Thomson To: Lorenzo Miniero Content-Type: text/plain; charset=UTF-8 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 17:21:17 -0000 On 25 November 2013 06:43, Lorenzo Miniero wrote: > The only doubt I have is sec.3: is > specifying an ALPN really necessary, if "any DTLS message is > sufficient to refresh consent"? are you envisaging a scenario where it's > the DTLS stack that filters unwanted incoming packets (e.g., SCTP where > you only want RTP), or would it be there for a different reason? The reason that this section is there is to place some constraints around to consent to limit its scope. As more and more protocols enable (D)TLS, there is an increasing chance that the endpoint you are talking to speaks (D)TLS, but isn't actually willing to converse with the protocol you expect. Rather than provide carte blanche consent, this allows a data channels-only server to indicate that it's not interested in SRTP, or your database server from being put on the other end of a data channel firehose. From cowwoc@bbs.darktech.org Mon Nov 25 09:27:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A9E1ADF76 for ; Mon, 25 Nov 2013 09:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ohy2J6PMnnU for ; Mon, 25 Nov 2013 09:27:03 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id B0FB01ADF46 for ; Mon, 25 Nov 2013 09:27:03 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id to1so7382040ieb.18 for ; Mon, 25 Nov 2013 09:27:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=R/U/spDXstCjNZK4HZAg24V0igtYrX6JCuSHwqIQy/Q=; b=AaZ+UInCSaxO/zz9OjZBS8lhb2/VNqURjdMJiADL9P9YBRWVFohjm2KATopq4jJJTs 49LCBfsWkmWsexW8nqmUrcn+pPQMckO2Gx/9LT3v67jXmoK6Etff21q8ryysdenxUCoz rIP7h6yP6Avvbn421slKGgQiwQfmtWHcGMEI1xvkVIbfI126jo6d3WzOa2AEOdEbVDWj ykQFrojP4uFTunSjKZ8pC/ItVpGobRXWuTJflgGeHgLLJdj9QKiJIQx7D04ssNQZVrou bCBaWxpqxPNWSTlzoxaPxSuwpr3Jajq80qMKywbAy6w5mUCQNZ71XCJHLfPMcV5bfRjV I4Rw== X-Gm-Message-State: ALoCoQn2Pi1lg/6+dDtfpg89hzt1fANmMUY/mFDeEwlVVXtNgcokEqs1g3/o9fkO+p6oABtpH11D X-Received: by 10.50.4.9 with SMTP id g9mr13858238igg.22.1385400423719; Mon, 25 Nov 2013 09:27:03 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id k6sm27338421igx.8.2013.11.25.09.27.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 09:27:03 -0800 (PST) Message-ID: <52938846.3040803@bbs.darktech.org> Date: Mon, 25 Nov 2013 12:26:30 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> <5292FD9D.3020207@bbs.darktech.org> <7594FB04B1934943A5C02806D1A2204B1C554536@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C554536@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------050702050202000000020105" Subject: Re: [rtcweb] Asymmetric codecs X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 17:27:07 -0000 This is a multi-part message in MIME format. --------------050702050202000000020105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit told you so :) So folks, what happens when we try removing any mention of SDP from the 2.0 spec? :) Are you saying this is no longer possible? Gili On 25/11/2013 2:43 AM, Christer Holmberg wrote: > > Hi, > > I'm afraid that SDP has become is a little more than an implementation > detail :) > > Regards, > > Christer > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *cowwoc > *Sent:* 25. marraskuuta 2013 9:35 > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Asymmetric codecs > > > SDP is supposed to be an implementation detail. Let's figure out > whether asymmetric codecs solve our problems and wedge it into SDP later. > > I suspect that this approach reduces the IPR risk, but H.264 royalties > still apply, do they not? > > Sadly this means we're stuck with: "MUST decode at least two of [VP8, > H.264, H.261] and MUST encode at least one of them". > > Gili > > On 25/11/2013 2:24 AM, Christer Holmberg wrote: > > Hi, > > First, from a pure MTI codec perspective, the question is whether > usage of asymmetric codecs would solve the issues that people have. > > Second, from an SDP OA/BUNDLE perspective, I don't think we can > mandate *usage* of BUNDLE. And, even if we did, in the initial > Offer you still need to assign unique port values for each m- line > (as agreed in Vancouver). > > ...unless, of course, you assign an SDP 'bundle-only' attribute to > all m- lines with asymmetric codecs. > > Regards, > > Christer > > *From:*Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] > *Sent:* 25. marraskuuta 2013 4:11 > *To:* Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt) > *Cc:* rtcweb@ietf.org > *Subject:* Asymmetric codecs > > I started a draft on how to standardize support for asymmetric > codecs back in September. The primary motivation was decoding > H.264 and H.265 while only encoding H.264. A secondary motivation, > for rtcweb, was decoding H.264 and VP8 while only encoding one of > them, as Stefan mentioned. I thought it would be a trivial thing > to write up by the Oct. 6 deadline for MTI proposals. The draft is > still incomplete and unpublished because all solutions are ugly > and overly complex for something so seemingly trivial, just like > bundle and unified plan. I now sympathize with Christer and Adam > for how they arrived at those (not exactly elegant) solutions, and > agree with Martin that a pair of (bundled) m-lines is the most > viable (although not exactly elegant) solution for asymmetric codecs. > > RFC 4317 drafts originally included asymmetric codecs until they > were removed in draft 02: > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-mmusic-offer-answer-examples-02.txt > > They were removed for fear of issues with shared ports: > > http://www.ietf.org/mail-archive/text/mmusic/2003-09.mail > > Now that we (almost) have bundle, can we resurrect asymmetric > codecs with separate sendonly and recvonly m-lines? Are folks ok > with a dependency on bundle? I would be happy to complete a draft > in that direction. (That is, a general mmusic draft on asymmetric > codecs, not a rtcweb draft on MTI asymmetric codecs. I will move > the discussion to mmusic after getting rtcweb opinions first.) > > Some may consider this a bizarre corner case. However, for > hardware codecs, it is the norm not the exception to have > asymmetric encoder and decoder formats. Especially for new > formats, which usually appear in hardware decoders well before > hardware encoders are available. This happened for H.264, H.265, > VP8, and virtually every popular codec format in virtually every > popular chipset. > > Mo > > On 11/23/13, 9:09 AM, Christer Holmberg > > wrote: > > Like some others, I think the must-decode-both-must-endcode-one > alternative as such sounds interesting (whether it has any impact > on the licence/IPR issues I'll leave to others to speak for). > However, I have big concerns over the proposal to indicate > sendrecv for a codec even if an entity is only able to > receive/decode it. ... Usage of unidirectional, sendonly/recvonly, > m- line would of course solve this, and you might know that it is > one option we are discussing in CLUE (for other reasons than MTI > codec, though). > > On 22 November 2013 16:20, Paul Giralt (pgiralt) > > wrote: > > I gave this as an example of a possible way to do it, but that > means you need two separate m= lines - one for send and one for > receive. Seems strange to do this for something that you really > want to be a single bi-directional stream. > > On 11/22/13, 8:03 PM, Martin Thomson > wrote: > > The bidirectional thing in O/A is the strange way to do things. > Two lines is pretty intuitive. > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > --------------050702050202000000020105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

<cough> told you so <cough> :)

So folks, what happens when we try removing any mention of SDP from the 2.0 spec? :) Are you saying this is no longer possible?

Gili

On 25/11/2013 2:43 AM, Christer Holmberg wrote:

Hi,

 

I’m afraid that SDP has become is a little more than an implementation detail :)

 

Regards,

 

Christer

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
Sent: 25. marraskuuta 2013 9:35
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Asymmetric codecs

 


SDP is supposed to be an implementation detail. Let's figure out whether asymmetric codecs solve our problems and wedge it into SDP later.

I suspect that this approach reduces the IPR risk, but H.264 royalties still apply, do they not?

Sadly this means we're stuck with: "MUST decode at least two of [VP8, H.264, H.261] and MUST encode at least one of them".

Gili

On 25/11/2013 2:24 AM, Christer Holmberg wrote:

Hi,

 

First, from a pure MTI codec perspective, the question is whether usage of asymmetric codecs would solve the issues that people have.

 

Second, from an SDP OA/BUNDLE perspective, I don’t think we can mandate usage of BUNDLE. And, even if we did, in the initial Offer you still need to assign unique port values for each m- line (as agreed in Vancouver).

 

…unless, of course, you assign an SDP ‘bundle-only’ attribute to all m- lines with asymmetric codecs.

 

Regards,

 

Christer

 

From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
Sent: 25. marraskuuta 2013 4:11
To: Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
Cc: rtcweb@ietf.org
Subject: Asymmetric codecs

 

I started a draft on how to standardize support for asymmetric codecs back in September. The primary motivation was decoding H.264 and H.265 while only encoding H.264. A secondary motivation, for rtcweb, was decoding H.264 and VP8 while only encoding one of them, as Stefan mentioned. I thought it would be a trivial thing to write up by the Oct. 6 deadline for MTI proposals. The draft is still incomplete and unpublished because all solutions are ugly and overly complex for something so seemingly trivial, just like bundle and unified plan. I now sympathize with Christer and Adam for how they arrived at those (not exactly elegant) solutions, and agree with Martin that a pair of (bundled) m-lines is the most viable (although not exactly elegant) solution for asymmetric codecs.

 

RFC 4317 drafts originally included asymmetric codecs until they were removed in draft 02:

 

They were removed for fear of issues with shared ports:

 

Now that we (almost) have bundle, can we resurrect asymmetric codecs with separate sendonly and recvonly m-lines? Are folks ok with a dependency on bundle? I would be happy to complete a draft in that direction. (That is, a general mmusic draft on asymmetric codecs, not a rtcweb draft on MTI asymmetric codecs. I will move the discussion to mmusic after getting rtcweb opinions first.)

 

Some may consider this a bizarre corner case. However, for hardware codecs, it is the norm not the exception to have asymmetric encoder and decoder formats. Especially for new formats, which usually appear in hardware decoders well before hardware encoders are available. This happened for H.264, H.265, VP8, and virtually every popular codec format in virtually every popular chipset.

 

Mo

 

On 11/23/13, 9:09 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Like some others, I think the must-decode-both-must-endcode-one alternative as such sounds interesting (whether it has any impact on the licence/IPR issues I'll leave to others to speak for). However, I have big concerns over the proposal to indicate sendrecv for a codec even if an entity is only able to receive/decode it. … Usage of unidirectional, sendonly/recvonly, m- line would of course solve this, and you might know that it is one option we are discussing in CLUE (for other reasons than MTI codec, though).

 

On 22 November 2013 16:20, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:

I gave this as an example of a possible way to do it, but that means you need two separate m= lines - one for send and one for receive. Seems strange to do this for something that you really want to be a single bi-directional stream.

 

On 11/22/13, 8:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

The bidirectional thing in O/A is the strange way to do things.  Two lines is pretty intuitive.

 




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 


--------------050702050202000000020105-- From partha@parthasarathi.co.in Mon Nov 25 09:52:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42761ADFCB for ; Mon, 25 Nov 2013 09:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgjlKiAvt5G4 for ; Mon, 25 Nov 2013 09:52:38 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.156]) by ietfa.amsl.com (Postfix) with ESMTP id 8170C1ADFC7 for ; Mon, 25 Nov 2013 09:52:38 -0800 (PST) Received: from userPC (unknown [122.166.141.171]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 4399314D8B8B; Mon, 25 Nov 2013 17:52:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1385401957; bh=VUidsFNVIQtxK+QjBCByTvPfrVrE8Sqdxs2S2F0IsXg=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=e8arITsctyNPiLUpSKDOTdfADtZdySW/0mPU28wo11lpMn1jl79CMQUP3nPklBCus x5IVn5PV1rqrL5MYFrLXEmviG6NC2Wt978TOlutUrl26TQMv17XjXaPSdswYyHmOyi lq+rpJtiHzR/meot7YbF/FaHJR2fECxeuAWwqxb4= From: "Parthasarathi R" To: "'Harald Alvestrand'" , References: <528E39F4.4010706@ericsson.com> <528E5AF7.5080403@alvestrand.no> <52922ED3.7070908@alvestrand.no> <002d01cee949$51a4c3c0$f4ee4b40$@co.in> <5292775F.6020600@alvestrand.no> In-Reply-To: <5292775F.6020600@alvestrand.no> Date: Mon, 25 Nov 2013 23:22:30 +0530 Message-ID: <004b01ceea07$1f9ee220$5edca660$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7pYNWYKlKEh5u8SSiLm1dnPbd++AAm8xSQ Content-Language: en-us X-CTCH-RefID: str=0001.0A02020A.52938E65.010D, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.100 X-CTCH-Rules: SUBJECT_NEEDS_ENCODING, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.157 Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video Selection Process) X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 17:52:41 -0000 Hi Harald, The difference between your distribution and my distribution is that all voters select all the possible combination in your distribution whereas in my distribution, voters selected their specific choice. A proponents (40%): A A|B B proponents (40%): B A|B Compromisers group 1 (5%): A|B A Compromisers group 2 (15%): A|B B In my case, A proponents and Compromisers group 1 treats A|B as A only (45%) and which is logically correct. OTOH, B proponents and Compromisers group 2 treat A|B as B only (55%). Condorcet mechanism does not bring out the truth that A has 45% implementation only whereas B has 55% implementation preference. For my given distribution, IRV brings the truth perfectly as A has 45% and B has 55% as explained in the previous mail and it reflects the actual intention of voters. In current situation of Video codec MTI, my distribution looks more relevant as most of the folks does not want the opposite camp codec. Thanks Partha > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Monday, November 25, 2013 3:32 AM > To: Parthasarathi R; rtcweb@ietf.org > Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video > Selection Process) > > On 11/24/2013 08:13 PM, Parthasarathi R wrote: > > Hi Harald & all, > > > > IMO, The fundamental problem with these methods (Condorcet & IRV) is > that > > they are designed to find the winner out of the discrete candidates > (A, B, > > C) in mind whereas the candidates in this voting is of combination of > > discrete and set nature (A, B, (A & B), (A | B)). I like to see the > proof > > whether the above methods (Condorcet & IRV) are really designed to > bring the > > correct winner in these set of candidates as well. > > > > I can show how your example of Condorcet fail with (A|B) is as > follows: The > > candidates are A,B, (A|B) > > Question: Why do you consider choosing A|B a fail, given that you give > exactly the same preference numbers under which I consider this > position > a reasonable outcome? > > The Condorcet winner will always beat each other candidate if no other > candidate is present (except in the case of a loop). With your numbers, > A|B is preferred over A, and A|B is preferred over B, so why is > choosing > A|B a fail? > > > -- > Surveillance is pervasive. Go Dark. From basilgohar@librevideo.org Mon Nov 25 09:54:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393881ADFCB for ; Mon, 25 Nov 2013 09:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDPptTZzfJ_l for ; Mon, 25 Nov 2013 09:53:59 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id B9A771ACB4E for ; Mon, 25 Nov 2013 09:53:59 -0800 (PST) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id BB3A665A988 for ; Mon, 25 Nov 2013 12:53:59 -0500 (EST) Message-ID: <52938EB4.8010004@librevideo.org> Date: Mon, 25 Nov 2013 12:53:56 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Asymmetric codecs X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 17:54:02 -0000 On 11/25/2013 11:13 AM, Mo Zanaty (mzanaty) wrote: > Re: MTI, I don’t think asymmetric codecs will solve all the MTI issues. > However, it may solve some practical deployment issues regardless of MTI > decisions. If products have a decoder but no encoder, it may help to > express that. For example, Chrome can expose its H.264 decoder for > webrtc despite no encoder. Hardware products can expose their VP8 > decoder for webrtc despite no encoder. > > Re: SDP, if you want asymmetric codecs over the same port, is it ok to > mandate bundle to achieve this? I started with a single sendrecv m-line > with all payload types that can be decoded but not necessarily encoded, > as Justin suggested. That would not require bundle. However, it gets > ugly when adding extra signaling for which payload types can’t be > encoded and multiple O/A rounds for interop with arbitrary peers. The > complexity approached bundle, so I ended up with separate > sendonly/recvonly m-lines, as Martin suggested. For what it's worth, if it doesn't muddy things up, having *support* for a different codec being sent from both sides, doesn't sound like a terribly bad idea. Maybe a lower-end device, say, a watch or something, can encode to a simpler codec but decode a more advanced one. However, this should be weighed on its own merits, and really shouldn't factor in at all to the MTI discussion in my opinion. -- Libre Video http://librevideo.org From partha@parthasarathi.co.in Mon Nov 25 10:23:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF6B1AD8F4 for ; Mon, 25 Nov 2013 10:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No-aP4ZpHcSG for ; Mon, 25 Nov 2013 10:23:20 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.153]) by ietfa.amsl.com (Postfix) with ESMTP id F0C511AD8D5 for ; Mon, 25 Nov 2013 10:23:19 -0800 (PST) Received: from userPC (unknown [122.166.141.171]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 8B7AC14D8BBB; Mon, 25 Nov 2013 18:23:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1385403799; bh=AMAP7Ec0j/W1EFK2RDUNZdmUT/DjIELu1l07KwUxSoc=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=kQLXFfEVemi7J/awHmFq1bLwE46cOGCM341saUXc3w2AuUiuyrGvK2Lg9FiGVb72N tm4pSiv7tMIMXFuuY9FaP14qohanw6PtK6vUVGfWN/ZvhTsoqtcssiqvyysAsIxksZ g445exBi7Tec5sQGVD0kDGbN8BuyMHnrNHfrKW2E= From: "Parthasarathi R" To: =?iso-8859-1?Q?'Herv=E9'?= , "'Harald Alvestrand'" , References: <528E39F4.4010706@ericsson.com> <528E5AF7.5080403@alvestrand.no>, <52922ED3.7070908@alvestrand.no>, <002d01cee949$51a4c3c0$f4ee4b40$@co.in> In-Reply-To: Date: Mon, 25 Nov 2013 23:53:11 +0530 Message-ID: <004d01ceea0b$6951a020$3bf4e060$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7paDqj3wJNFCkBQG+jjg0MhBjAfQAoaxeA Content-Language: en-us X-CTCH-RefID: str=0001.0A02020A.52939597.006B, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.100 X-CTCH-Rules: SUBJECT_NEEDS_ENCODING, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.157 Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video Selection Process) X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 18:23:22 -0000 Please read inline. > -----Original Message----- > From: Herv=E9 [mailto:h_o_w_@hotmail.com] > Sent: Monday, November 25, 2013 4:25 AM > To: Parthasarathi R; 'Harald Alvestrand'; rtcweb@ietf.org > Subject: RE: [rtcweb] Voting method choice (Re: Proposed Video > Selection Process) >=20 > ---------------------------------------- > > From: partha@parthasarathi.co.in >=20 > > IMO, The fundamental problem with these methods (Condorcet & IRV) is > that > > they are designed to find the winner out of the discrete candidates > (A, B, > > C) in mind whereas the candidates in this voting is of combination = of > > discrete and set nature (A, B, (A & B), (A | B)). I like to see the > proof > > whether the above methods (Condorcet & IRV) are really designed to > bring the > > correct winner in these set of candidates as well. > > > > I can show how your example of Condorcet fail with (A|B) is as > follows: The > > candidates are A,B, (A|B) > > > > A: Codec A > > B: Codec B > > A|B: At least one of Codec A and B > > > > If the distribution is like this: > > > > A proponents (40%): A A|B > > B proponents (40%): B A|B > > Compromisers group 1 (5%): A|B A > > Compromisers group 2 (15%): A|B B > > > > Then under IRV, the first round will go 40/40/20, alternative A|B > will be > > eliminated, and B will be chosen with 55 as A has 45 only in the > second > > round. > > > > Under Condorcet, the outcomes will be: > > > > - A outranks B on 55% > > - B outranks A on 45% >=20 > I think your commentary below agrees that you swapped the numbers > there. >=20 >=20 > > - A|B outranks A on 60% > > - A|B outranks B on 60% > > > > Therefore, A|B is a Condorcet winner and election is successful. In > reality, > > the original winner is B and compromisers group 2 which is = interested > only > > in implementing B which has 55% supporter. Also, A and Compromisers > group 1 > > is interested only in implementing A which is 45%. So, Condorcet > winner is > > not required to be correct in case A|B, A&B candidates exists in the > > election. >=20 > What would you say is the correct winner? >=20 In the given example, B is actual winner as it will results in = 55% implementation. As I explained in Harald mail thread, it is not coming = out by Condorcet mechanism. > One that avoids negotiation failure completely? A|B does not do that. > (But might reduce the chance a little compared to no MTI.) >=20 Agreed > One that the most people find acceptable? A|B is that. If your statement is true, there should be rough consensus for = A|B before taking voting (alternative) process. Currently, the proposed = video selection process is going for vote and then asking for regular rough consensus mechanism for A|B if vote (alternative) fail > The voters in the condorcet hypothetical all get their wish and can > comply with rtcweb without implementing the codec they do not want. >=20 >=20 > From the examples I've seen, I think condorcet would be preferable to > IRV. >=20 > There is the argument 'The IETF does not vote' to contend with. I = don't > know about that. I think VP8 as the only MTI or H.264 as the only MTI > is unlikely to find consensus, but I also agree that the "or could = live > with" crowd might have been masked during the meeting. It should come out through the rough consensus > I think it's good to look into some alternative proposals and would be > good to see which are least objectionable. And a vote could be just = the > tool to do that. > Is consensus not an acceptable resolution, if not the favourite? and > condorcet seems like a method to find it. >=20 > Another tool, a list of pros and cons, > https://etherpad.mozilla.org/RSbHIuSOgn . > Good information. I agree with the information which exists as = of now =20 >=20 > > Having said that, I agree with you that IVR is also not required to > yield > > correct election result in case A&B, A|B candidates exists. > > > > As of now as I mentioned in > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg10113.html, > the > > election result may leads to the situation of "the operation was a > success > > but the patient died". Please let me know your opinion on the same. >=20 >=20 > - Herv=E9 =3D From john@jlc.net Mon Nov 25 11:22:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FC11ADFC0 for ; Mon, 25 Nov 2013 11:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6mT8utjKuO6 for ; Mon, 25 Nov 2013 11:22:05 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B74431ADFBB for ; Mon, 25 Nov 2013 11:22:05 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id BF473C94C4; Mon, 25 Nov 2013 14:22:03 -0500 (EST) Date: Mon, 25 Nov 2013 14:22:03 -0500 From: John Leslie To: Magnus Westerlund Message-ID: <20131125192203.GB95346@verdi> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52936207.5040704@ericsson.com> User-Agent: Mutt/1.4.1i Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 19:22:08 -0000 Magnus Westerlund wrote: > On 2013-11-25 15:30, Leon Geyser wrote: >>... >> I agree that 10 can be changed to: >> 10. MUST implement at least two of {VP8, H.264 CBP, H.261} > > I did a mistake in this call. I missed that 10 and 11 talked about H.261 > and H.263 respectively. > > I think the above question of writing 10 in the above proposed format is > then the relevant question to the WG. To me, that wording is void for vagueness... Per http://en.wikipedia.org/wiki/CPB ] ] CPB may refer to: ] Companies[edit] ] ] Campbell Soup Company, stock symbol CPB ] Campbell Brothers, an Australian laboratory and manufacturing company ] Crispin Porter + Bogusky, an advertising agency ] Corporate Express (airline), a defunct Canadian airline ] Organizations[edit] ] ] The Corporation for Public Broadcasting, a publicly funded non-profit corporation in the United States ] The CPB (Netherlands), a government agency in the Netherlands ] The Crown Property Bureau, a quasi-government agency in Thailand ] The École nationale supérieure de chimie et de physique de Bordeaux, one of the French grandes écoles ] Political parties[edit] ] ] Communist Party of Bangladesh ] Communist Party of Britain ] Communist Party of Burma ] Technology[edit] ] ] Cardiopulmonary bypass, also known as a "heart-lung machine" ] Charged particle beam of electrically charged particles ] CREB-binding protein, a transcription coregulator ] Cycles per byte, a unit of measurement related to microprocessors ] Coded Picture Buffer, a buffer for encoded video frames used in video decoding ] Other[edit] ] ] The Citizens Protection Bureau, a fictional police organization in the Total Recall 2070 television series ] Camilla Parker Bowles ] Central Planning Board, term used in market socialism theory ] Crippled Black Phoenix, a British post-rock supergroup (10) as it stands is quite clear: I don't think it deserves to be changed at all. (And if we are to start changing entries, what is the process? Does someone call consensus for the change?) -- John Leslie From Markus.Isomaki@nokia.com Mon Nov 25 11:52:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315391ADF8F for ; Mon, 25 Nov 2013 11:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_vwgqkFKIZr for ; Mon, 25 Nov 2013 11:52:31 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9361ADF8B for ; Mon, 25 Nov 2013 11:52:31 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.60]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rAPJpgpB026611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 25 Nov 2013 21:51:43 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.177]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.03.0158.002; Mon, 25 Nov 2013 19:51:42 +0000 From: To: , Thread-Topic: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? Thread-Index: AQHO6el3zh0x+Oo+JEKGxZr6eIAkvpo2Ad0AgAADrYCAAFLU4A== Date: Mon, 25 Nov 2013 19:51:41 +0000 Message-ID: References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> In-Reply-To: <52936207.5040704@ericsson.com> 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; x-titus-version: 3.5.9.3 x-headerinfofordlp: x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IsMYwYvlwi0oDC9KWeaffsyIqSM6i1RvMWxEVWdTMAiDuLl4R2XRL+W/F+Rptl0GQyNem2vlgPR5spFae1YB2IoUNlHEGP9qsaa4wSKZBFF5xlAhEPuBjETMgvK6bzwQhofhWsILbGqK4SftpgbtePOYEgA5eTAX+hFl0NKm6dIgUS8h2lTQZ4ND5gd6eN7TFM5MywMoTFONrOlJOA7HQx5+7e2LzSm9fYlyNV5G1P91sc6CPdGepWRoj74WBlJWag== x-originating-ip: [10.163.30.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 19:52:33 -0000 Hi, magnus.westerlund@ericsson.com wrote: >=20 > On 2013-11-25 15:30, Leon Geyser wrote: > > Hi Magnus, > > > > Was H.263 a typo? > > I agree that 10 can be changed to: > > 10. MUST implement at least two of {VP8, H.264 CBP, H.261} >=20 > Sorry, >=20 > I did a mistake in this call. I missed that 10 and 11 talked about H.261 = and > H.263 respectively. >=20 > I think the above question of writing 10 in the above proposed format is = then > the relevant question to the WG. >=20 I agree that alternatives 10. and 11. are better to be written in the same = format: 10. MUST implement at least two of {VP8, H.264 CBP, H.261} 11. MUST implement at least two of {VP8, H.264, H.263} I assume H.264 CBP =3D Constrained Baseline Profile as proposed in draft-bu= rman-rtcweb-h264-proposal. For H.263 we would need to define if it means H.263 Baseline or something b= eyond that. I have seen at least Stephan Wenger arguing that H.263 Baseline= is not suitable for WebRTC.=20 Markus From juberti@google.com Mon Nov 25 12:21:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46511ADFCF for ; Mon, 25 Nov 2013 12:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15iP4m3Auqhs for ; Mon, 25 Nov 2013 12:21:35 -0800 (PST) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A377D1ADFC8 for ; Mon, 25 Nov 2013 12:21:35 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id jw12so3389730veb.31 for ; Mon, 25 Nov 2013 12:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KQHPNvej4QzclJ84FUWlUpkhAjYCexDIJWBTCsDzFBI=; b=my4SD7xi3W3+wVTtSUAUA9rSPCvEIjrIy+vGCh3gmUzAOfE8LqftNqpGHxP4p4dvJd jttZ3NLlubdBznmaDV+qdDyzVmUg8PUXdvobTP3UNlF2lAg1NnVP9G6BIERNm1FQnN7M qzD+crPjZj7eBohCCZHfmv2WtjN1hf9YlFMDj6AdNzTz68u5BziMehABwM/f2t9fgf6a 2cyzTdzjJLyrNdKKlCWITsaD++Q9dM7rP7c3TUH+RkRs3UqmJQc2/unkKOUw+nUQ88EY 5MrC7SdNVy/jN2UbYK13+5JXI8LwwvcqjONam5MftZjkwUj/awU7DKYAlqXjD3c8n+Ro uzTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KQHPNvej4QzclJ84FUWlUpkhAjYCexDIJWBTCsDzFBI=; b=Vquap2/RlZ8uAdLNCqJ+zF7mK6mWp3pEde2Oml1FIXmhQ6iyvwhxhOf/Nr3zj4Peaq pA99I7cbwuvXL5JBarTyp4kYUi6455znHzOFuoKSeeChVq1Jgj583GMGmo8A/5Qt7xFa EgIhUxRPeHbLq3/E4RrlBXiPBJXNHHoI2ey/pADkk/Tp7df2rXCqHb9wcSogUJHcKGdg e6V2H71Q8FI/0pNcbOn9GzpYdCJNbIN5IaZ+R/NyXr2YQ7MbbtX6rigP0M1XZj1JcUUU IusMN+3UQwOdkWZ83C4e0p6jJ/J3pi0Crt4ZpqloxUY0I397Our/2HcCghpEjhOwj1E2 WE3Q== X-Gm-Message-State: ALoCoQmF29V+16Bu3QRvym5uTO+7voLpT25e97tmNkKSPvgUfz/N/3pYTiFIeXGyJKN6bpUxQsa8iOxNks+YrPlnrRmQjL9i6TmuEzRYttOp+GAIQEApjvYuGmPOiwizBo7JItbXYABV838MFT7khDtkXRhutFhjWeCWrSJ3KQDh1baM4+3E7TR6ySoT9ic0kzARviY+XTCi X-Received: by 10.220.123.6 with SMTP id n6mr1820933vcr.28.1385410895398; Mon, 25 Nov 2013 12:21:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Mon, 25 Nov 2013 12:21:15 -0800 (PST) In-Reply-To: <52938846.3040803@bbs.darktech.org> References: <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> <5292FD9D.3020207@bbs.darktech.org> <7594FB04B1934943A5C02806D1A2204B1C554536@ESESSMB209.ericsson.se> <52938846.3040803@bbs.darktech.org> From: Justin Uberti Date: Mon, 25 Nov 2013 12:21:15 -0800 Message-ID: To: cowwoc Content-Type: multipart/alternative; boundary=089e011770f149e2c704ec061c36 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asymmetric codecs X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 20:21:39 -0000 --089e011770f149e2c704ec061c36 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable SDP is just a serialization format, a clumsy yet somehow popular one. Nothing we decide here on codecs will impose any mandate on what serialization format is used in WebRTC 2.0. On Mon, Nov 25, 2013 at 9:26 AM, cowwoc wrote: > > told you so :) > > So folks, what happens when we try removing any mention of SDP from the > 2.0 spec? :) Are you saying this is no longer possible? > > Gili > > > On 25/11/2013 2:43 AM, Christer Holmberg wrote: > > Hi, > > > > I=E2=80=99m afraid that SDP has become is a little more than an implement= ation > detail :) > > > > Regards, > > > > Christer > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *cowwoc > *Sent:* 25. marraskuuta 2013 9:35 > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Asymmetric codecs > > > > > SDP is supposed to be an implementation detail. Let's figure out whether > asymmetric codecs solve our problems and wedge it into SDP later. > > I suspect that this approach reduces the IPR risk, but H.264 royalties > still apply, do they not? > > Sadly this means we're stuck with: "MUST decode at least two of [VP8, > H.264, H.261] and MUST encode at least one of them". > > Gili > > On 25/11/2013 2:24 AM, Christer Holmberg wrote: > > Hi, > > > > First, from a pure MTI codec perspective, the question is whether usage o= f > asymmetric codecs would solve the issues that people have. > > > > Second, from an SDP OA/BUNDLE perspective, I don=E2=80=99t think we can m= andate > *usage* of BUNDLE. And, even if we did, in the initial Offer you still > need to assign unique port values for each m- line (as agreed in Vancouve= r). > > > > =E2=80=A6unless, of course, you assign an SDP =E2=80=98bundle-only=E2=80= =99 attribute to all m- > lines with asymmetric codecs. > > > > Regards, > > > > Christer > > > > *From:* Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com = ] > > *Sent:* 25. marraskuuta 2013 4:11 > *To:* Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt) > *Cc:* rtcweb@ietf.org > *Subject:* Asymmetric codecs > > > > I started a draft on how to standardize support for asymmetric codecs bac= k > in September. The primary motivation was decoding H.264 and H.265 while > only encoding H.264. A secondary motivation, for rtcweb, was decoding H.2= 64 > and VP8 while only encoding one of them, as Stefan mentioned. I thought i= t > would be a trivial thing to write up by the Oct. 6 deadline for MTI > proposals. The draft is still incomplete and unpublished because all > solutions are ugly and overly complex for something so seemingly trivial, > just like bundle and unified plan. I now sympathize with Christer and Ada= m > for how they arrived at those (not exactly elegant) solutions, and agree > with Martin that a pair of (bundled) m-lines is the most viable (although > not exactly elegant) solution for asymmetric codecs. > > > > RFC 4317 drafts originally included asymmetric codecs until they were > removed in draft 02: > > > http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-mmusi= c-offer-answer-examples-02.txt > > > > They were removed for fear of issues with shared ports: > > http://www.ietf.org/mail-archive/text/mmusic/2003-09.mail > > > > Now that we (almost) have bundle, can we resurrect asymmetric codecs with > separate sendonly and recvonly m-lines? Are folks ok with a dependency on > bundle? I would be happy to complete a draft in that direction. (That is,= a > general mmusic draft on asymmetric codecs, not a rtcweb draft on MTI > asymmetric codecs. I will move the discussion to mmusic after getting > rtcweb opinions first.) > > > > Some may consider this a bizarre corner case. However, for hardware > codecs, it is the norm not the exception to have asymmetric encoder and > decoder formats. Especially for new formats, which usually appear in > hardware decoders well before hardware encoders are available. This > happened for H.264, H.265, VP8, and virtually every popular codec format = in > virtually every popular chipset. > > > > Mo > > > > On 11/23/13, 9:09 AM, Christer Holmberg > wrote: > > Like some others, I think the must-decode-both-must-endcode-one > alternative as such sounds interesting (whether it has any impact on the > licence/IPR issues I'll leave to others to speak for). However, I have bi= g > concerns over the proposal to indicate sendrecv for a codec even if an > entity is only able to receive/decode it. =E2=80=A6 Usage of unidirection= al, > sendonly/recvonly, m- line would of course solve this, and you might know > that it is one option we are discussing in CLUE (for other reasons than M= TI > codec, though). > > > > On 22 November 2013 16:20, Paul Giralt (pgiralt) > wrote: > > I gave this as an example of a possible way to do it, but that means you > need two separate m=3D lines - one for send and one for receive. Seems > strange to do this for something that you really want to be a single > bi-directional stream. > > > > On 11/22/13, 8:03 PM, Martin Thomson wrote: > > The bidirectional thing in O/A is the strange way to do things. Two line= s > is pretty intuitive. > > > > > > > _______________________________________________ > > 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 > > --089e011770f149e2c704ec061c36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SDP is just a serialization format, a clumsy yet somehow p= opular one.

Nothing we decide here on codecs will impose= any mandate on what serialization format is used in WebRTC 2.0.


On Mon, Nov 25, 2013 at 9:26 AM, cowwoc <cowwoc@bbs.darktech.org= > wrote:
=20 =20 =20

<cough> told you so <cough> :)

So folks, what happens when we try removing any mention of SDP from the 2.0 spec? :) Are you saying this is no longer possible?

Gili


On 25/11/2013 2:43 AM, Christer Holmberg wrote:
=20 =20 =20

Hi,=

=C2=A0<= /u>

I=E2=80=99m afraid that SDP has become is a little more than an implementation detail :)

=C2=A0<= /u>

Regards,

=C2=A0<= /u>

Christer

=C2=A0<= /u>

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
Sent: 25. marraskuuta 2013 9:35
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Asymmetric codecs

=C2=A0


SDP is supposed to be an implementation detail. Let's figur= e out whether asymmetric codecs solve our problems and wedge it into SDP later.

I suspect that this approach reduces the IPR risk, but H.264 royalties still apply, do they not?

Sadly this means we're stuck with: "MUST decode at lea= st two of [VP8, H.264, H.261] and MUST encode at least one of them".

Gili

On 25/11/2013 2:24 AM, Christer Holmberg wrote:

Hi,

=C2=A0

First, from a pure MTI codec perspective, the question is whether usage of asymmetric codecs would solve the issues that people have.

=C2=A0

Second, from an SDP OA/BUNDLE perspective, I don=E2=80=99t think we c= an mandate usage of BUNDLE. And, even if we did, in the initial Offer you still need to assign unique port values for each m- line (as agreed in Vancouver).

=C2=A0

=E2=80=A6unless= , of course, you assign an SDP =E2=80=98bundle-only=E2=80=99 at= tribute to all m- lines with asymmetric codecs.

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
Sent: 25. marraskuuta 2013 4:11
To: Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
Cc: rtcweb@ietf.org
Subject: Asymmetric codecs

=C2=A0

I started a draft on how to standardize support for asymmetric codecs back in September. The primary motivation was decoding H.264 and H.265 while only encoding H.264. A secondary motivation, for rtcweb, was decoding H.264 and VP8 while only encoding one of them, as Stefan mentioned. I thought it would be a trivial thing to write up by the Oct. 6 deadline for MTI proposals. The draft is still incomplete and unpublished because all solutions are ugly and overly complex for something so seemingly trivial, just like bundle and unified plan. I now sympathize with Christer and Adam for how they arrived at those (not exactly elegant) solutions, and agree with Martin that a pair of (bundled) m-lines is the most viable (although not exactly elegant) solution for asymmetric codecs.

=C2=A0

RFC 4317 drafts originally included asymmetric codecs until they were removed in draft 02:

=C2=A0

They were removed for fear of issues with shared ports:

=C2=A0

Now that we (almost) have bundle, can we resurrect asymmetric codecs with separate sendonly and recvonly m-lines? Are folks ok with a dependency on bundle? I would be happy to complete a draft in that direction. (That is, a general mmusic draft on asymmetric codecs, not a rtcweb draft on MTI asymmetric codecs.=C2=A0I will mo= ve the discussion to mmusic after getting rtcweb opinions first.)

=C2=A0

Some may consider this a bizarre corner case. However, for hardware codecs, it is the norm not the exception to have asymmetric encoder and decoder formats. Especially for new formats, which usually appear in hardware decoders well before hardware encoders are available. This happened for H.264, H.265, VP8, and virtually every popular codec format in virtually every popular chipset.

=C2=A0

Mo

=C2=A0

On 11/23/13, 9:09 AM, Christer Holmberg <christer.holmberg@erics= son.com> wrote:

Like some others, I think the must-decode-both-must-endcode-one alternative as such sounds interesting (whether it has any impact on the licence/IPR issues I'll leave to others to speak for)= . However, I have big concerns over the proposal to indicate sendrecv for a codec even if an entity is only able to receive/decode it. =E2=80=A6 Usage of unidirectional, sendonly/recvonly, m- line would of course solve this, and you might know that it is one option we are discussing in CLUE (for other reasons than MTI codec, though).

=C2=A0

On 22 November 2013 16:20, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:

I gave this as an example of a possible way to do it, but that means you need two separate m=3D lines - one for send and one for receive. Seems strange to do this for something that you really want to be a single bi-directional stream.

=C2=A0

On 11/22/13, 8:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

The bidirectional thing in O/A is the strange way to do things. =C2=A0Two lines is pretty intuitive.

=C2=A0




_______________________________________________
rtcweb mailing list
rtcweb@=
ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

=C2=A0



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


--089e011770f149e2c704ec061c36-- From Markus.Isomaki@nokia.com Mon Nov 25 12:23:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECF11AE01F for ; Mon, 25 Nov 2013 12:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzN_04pGGucf for ; Mon, 25 Nov 2013 12:23:48 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 80C2C1ADFC8 for ; Mon, 25 Nov 2013 12:23:48 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.58]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rAPKEm1H001593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 25 Nov 2013 22:14:49 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.177]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.03.0158.002; Mon, 25 Nov 2013 20:14:48 +0000 From: To: , Thread-Topic: H.263 Baseline vs. H.261? (Was: H.263 licensing situation) Thread-Index: Ac7qF/g0TVuw5j/ATR+VbdFvC7rEOQ== Date: Mon, 25 Nov 2013 20:14:47 +0000 Message-ID: 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; x-titus-version: 3.5.9.3 x-headerinfofordlp: x-tituslabs-classificationhash-30: /l7IPXixAhc7RTUH/zCwpm2SDxFGrd9DcC9axWnwtNqyJi1p2pwdLI0jWuwM+IFxp1IDPfCvVpLGJBB81NXr9vDqN7YiYd/swCg2uwHtgwA95XftqYAjyRiKuaA1H/3L4aUm/9GOFQrgFXuVAcDdmHW6SSonaOZQcwVyig8ZIMnJ60c4OsjLVAEcPXckKGkan5p/IMKxuORjEJE2yavQkWTRLIqpcrLd5WyuTHSRxOqDr15ZFbdL8eMltvSxkQ4+ x-originating-ip: [10.163.30.186] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Subject: [rtcweb] H.263 Baseline vs. H.261? (Was: H.263 licensing situation) X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 20:23:51 -0000 Hi Stephan, all, Stephan Wenger wrote: > > H.263 baseline is insufficient for rtcweb=B9s purposes, as it does not al= low > arbitrary picture sizes. You want to have at least the PLUSPTYPE picture > header extension which allows arbitrary picture sizes. You also probably > want a few of the optional modes, especially the bug-fixes (improved VLC) > and the deblocking filter. Patents related to this technologies are not > covered under the MPEG-LA MPEG-4 part 2 license. > How would you compare H.263 Baseline to H.261? Or H.263 Baseline with PLUST= YPE extension to H.261? Based on the list discussion it seems quite clear t= hat none of the main browser vendors is really interested in including H.26= 1, even if it was IPR-free. Would H.263 Baseline suck more or less? I have = gotten an(other) educated opinion that the H.263 Baseline IPR risk was "vir= tually non-existent" already a few years back. In any case we need to define what "H.263" actually means within the altern= atives. Does it stand for the H.263 Baseline, or do we want to add some of = the features listed in Stephan's mail to make it usable?=20 I'm currently thinking that "MUST implement any two of {VP8, H.264 CBP, H.2= 63}" is the only sensible outcome for the WG apart from the "MUST implement= either one of {VP8, H.264 CBP}, that I assume everyone will anyway be comp= liant with. But that would require: 1.) Define what exactly "H.263" is in this context: Baseline or Baseline pl= us a set of extensions 2.) People consider it better than H.261, and actually usable for WebRTC 3.) People can live with the IPR risk. (I don't think we can conduct a comp= rehensive study within the WG, but people need to draw their own conclusion= s.) Markus > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of ext Stephan Wenger > Sent: 18 November, 2013 18:36 > To: rtcweb@ietf.org > Subject: [rtcweb] H.263 licensing situation >=20 > Hi, >=20 > Here is what I know or suspect regarding H.263 licensing: >=20 > Know: >=20 > Leon is correct, there are type 2 patent declarations in the ITU against = H.263. >=20 > Maik is also correct, H.263 baseline is a subset of MPEG-4 part 2. MPEG-= 4 > part 2 is generally considered royalty bearing and the license has been > enforced. However, very few (no one?) is using strict H.263 baseline, an= d > even for an only slightly more advanced use of H.263 (no need to go to > H.263+, for example), the MPEG-4 portfolio license would not apply. >=20 > H.263 has been the predominant codec in the video conferencing industry > for close to a decade (ca. 1996 through ca. 2005). In all this time, I h= ave heard > of one single instance of patent assertion by a non-troll against several= of the > large video conferencing vendors. However, since those vendors all used = a > chip produced by the non-troll, they had enough commercial leverage to > fend off those assertions without the dispute ever going to trial and, so= I > hear, without paying any premium for the use of > the patent. The patent in question has now expired. >=20 > H.263 baseline is insufficient for rtcweb=B9s purposes, as it does not al= low > arbitrary picture sizes. You want to have at least the PLUSPTYPE picture > header extension which allows arbitrary picture sizes. You also probably > want a few of the optional modes, especially the bug-fixes (improved VLC) > and the deblocking filter. Patents related to this technologies are not > covered under the MPEG-LA MPEG-4 part 2 license. >=20 > Suspect: >=20 > Since we would most likely not use strict H.263 baseline, the war-chest o= f the > MPEG-LA pool cannot be used to enforce a patent against our hypothetical > H.263 implementation because it is not MPEG-4 part 2 compliant. Which, i= n > turn, means that the MPEG-4 part 2 rightholders would be on their own in > asserting their patents. Which, in turn, means that there is no differen= ce > between H.263 and other non-pooled video codecs from an MPEG-LA > related risk assessment. >=20 >=20 > There have been patent assertions by trolls allegedly related to video > compression in general and H.263 in particular, but those happen all the = time > and there is not much one can do about them. Once you are a juicy enough > target (based on the troll=B9s perception of relationship between your le= gal > competence versus your size) the troll will find you. > Technicalities such as whether the patent is actually infringed or relate= d to > standards are secondary at best in the eye of a troll. Their business, a= t least > when going against smaller companies, is to settle for a few hundreds of > thousands--an amount the alleged infringer can pay without excessive hurt= -- > thereby filling their war chest and then go to the next =B3customer=B2. = When > they meet determined opposition (based on a combination of legal and > technical competence), they often move on to greener pastures. >=20 > As H.263 is fairly widely deployed, and I have not heard about patent > assertions except the cases mentioned above, the risk of a successful pat= ent > assertion is probably manageable for almost everyone with sufficient lega= l > resources. At least in countries that allow equitable defenses (implied > license, laches, estoppel). >=20 > So is it worth evaluating H.263 further? IMO, probably not. It=B9s doub= tless > technically better than H.261, but the risk is inproportionally higher. = And the > whole idea of this substandard baseline codec has been to be essentially > without risk. >=20 > Stephan >=20 >=20 > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cowwoc@bbs.darktech.org Mon Nov 25 12:30:20 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D901ADFC8 for ; Mon, 25 Nov 2013 12:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOOKeS8UjCJq for ; Mon, 25 Nov 2013 12:30:17 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7392E1AE043 for ; Mon, 25 Nov 2013 12:30:17 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar20so7761953iec.16 for ; Mon, 25 Nov 2013 12:30:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=lUVSYVTIzhqPnZ5ofrPwZSjjFZMPlmOFWp0aFPy5gwA=; b=NbAu8qn2nsdg9128FmrH8aCCUCVKplV3CHG340MK/+HMW/ty+qjSLM1Wmhc/8mPrRQ VaN0w0uK2z3cBoxMlXIkbUGDsOJIAcKMm7t3oTT7/c8d3thnFORepG3FHN8/QIifyCDA M2I6+EO+FEWqRIOuxd9HakicUjLJSpnitKCkwxFCnRxFpRfiWtxYOcWK1kAOmF9RdECm 9pChI7RGXAmJgPD0ngsx/FRYmUcyRCiXHZhDTnF7w8ahi9M5CuzGyDvfJlv0YUu7x/PS 0ojMbul2IXxiEY416yL8DqquATsL+U34RbJdX1FcuowOXIQepo1TUrFivq8VlSZh7XAL dhcA== X-Gm-Message-State: ALoCoQmzzDkSTRhthhaA8qEg0hJ+mMFqyxTORUiZVMf02cdMCjqJsvmfQH2rtAEAnFcWWnWpl0SC X-Received: by 10.50.25.227 with SMTP id f3mr14497171igg.16.1385411417478; Mon, 25 Nov 2013 12:30:17 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id a17sm27538456ign.2.2013.11.25.12.30.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 12:30:16 -0800 (PST) Message-ID: <5293B337.8020009@bbs.darktech.org> Date: Mon, 25 Nov 2013 15:29:43 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Justin Uberti References: <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> <5292FD9D.3020207@bbs.darktech.org> <7594FB04B1934943A5C02806D1A2204B1C554536@ESESSMB209.ericsson.se> <52938846.3040803@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040003050309040805020507" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asymmetric codecs X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 20:30:21 -0000 This is a multi-part message in MIME format. --------------040003050309040805020507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Okay, glad to hear it :) Thanks, Gili On 25/11/2013 3:21 PM, Justin Uberti wrote: > SDP is just a serialization format, a clumsy yet somehow popular one. > > Nothing we decide here on codecs will impose any mandate on what > serialization format is used in WebRTC 2.0. > > > On Mon, Nov 25, 2013 at 9:26 AM, cowwoc > wrote: > > > told you so :) > > So folks, what happens when we try removing any mention of SDP > from the 2.0 spec? :) Are you saying this is no longer possible? > > Gili > > > On 25/11/2013 2:43 AM, Christer Holmberg wrote: >> >> Hi, >> >> I’m afraid that SDP has become is a little more than an >> implementation detail :) >> >> Regards, >> >> Christer >> >> *From:*rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *cowwoc >> *Sent:* 25. marraskuuta 2013 9:35 >> *To:* rtcweb@ietf.org >> *Subject:* Re: [rtcweb] Asymmetric codecs >> >> >> SDP is supposed to be an implementation detail. Let's figure out >> whether asymmetric codecs solve our problems and wedge it into >> SDP later. >> >> I suspect that this approach reduces the IPR risk, but H.264 >> royalties still apply, do they not? >> >> Sadly this means we're stuck with: "MUST decode at least two of >> [VP8, H.264, H.261] and MUST encode at least one of them". >> >> Gili >> >> On 25/11/2013 2:24 AM, Christer Holmberg wrote: >> >> Hi, >> >> First, from a pure MTI codec perspective, the question is >> whether usage of asymmetric codecs would solve the issues >> that people have. >> >> Second, from an SDP OA/BUNDLE perspective, I don’t think we >> can mandate *usage* of BUNDLE. And, even if we did, in the >> initial Offer you still need to assign unique port values for >> each m- line (as agreed in Vancouver). >> >> …unless, of course, you assign an SDP ‘bundle-only’ attribute >> to all m- lines with asymmetric codecs. >> >> Regards, >> >> Christer >> >> *From:*Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] >> *Sent:* 25. marraskuuta 2013 4:11 >> *To:* Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt) >> *Cc:* rtcweb@ietf.org >> *Subject:* Asymmetric codecs >> >> I started a draft on how to standardize support for >> asymmetric codecs back in September. The primary motivation >> was decoding H.264 and H.265 while only encoding H.264. A >> secondary motivation, for rtcweb, was decoding H.264 and VP8 >> while only encoding one of them, as Stefan mentioned. I >> thought it would be a trivial thing to write up by the Oct. 6 >> deadline for MTI proposals. The draft is still incomplete and >> unpublished because all solutions are ugly and overly complex >> for something so seemingly trivial, just like bundle and >> unified plan. I now sympathize with Christer and Adam for how >> they arrived at those (not exactly elegant) solutions, and >> agree with Martin that a pair of (bundled) m-lines is the >> most viable (although not exactly elegant) solution for >> asymmetric codecs. >> >> RFC 4317 drafts originally included asymmetric codecs until >> they were removed in draft 02: >> >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-mmusic-offer-answer-examples-02.txt >> >> They were removed for fear of issues with shared ports: >> >> http://www.ietf.org/mail-archive/text/mmusic/2003-09.mail >> >> Now that we (almost) have bundle, can we resurrect asymmetric >> codecs with separate sendonly and recvonly m-lines? Are folks >> ok with a dependency on bundle? I would be happy to complete >> a draft in that direction. (That is, a general mmusic draft >> on asymmetric codecs, not a rtcweb draft on MTI asymmetric >> codecs. I will move the discussion to mmusic after getting >> rtcweb opinions first.) >> >> Some may consider this a bizarre corner case. However, for >> hardware codecs, it is the norm not the exception to have >> asymmetric encoder and decoder formats. Especially for new >> formats, which usually appear in hardware decoders well >> before hardware encoders are available. This happened for >> H.264, H.265, VP8, and virtually every popular codec format >> in virtually every popular chipset. >> >> Mo >> >> On 11/23/13, 9:09 AM, Christer Holmberg >> > > wrote: >> >> Like some others, I think the >> must-decode-both-must-endcode-one alternative as such sounds >> interesting (whether it has any impact on the licence/IPR >> issues I'll leave to others to speak for). However, I have >> big concerns over the proposal to indicate sendrecv for a >> codec even if an entity is only able to receive/decode it. … >> Usage of unidirectional, sendonly/recvonly, m- line would of >> course solve this, and you might know that it is one option >> we are discussing in CLUE (for other reasons than MTI codec, >> though). >> >> On 22 November 2013 16:20, Paul Giralt (pgiralt) >> > wrote: >> >> I gave this as an example of a possible way to do it, but >> that means you need two separate m= lines - one for send and >> one for receive. Seems strange to do this for something that >> you really want to be a single bi-directional stream. >> >> On 11/22/13, 8:03 PM, Martin Thomson >> > >> wrote: >> >> The bidirectional thing in O/A is the strange way to do >> things. Two lines is pretty intuitive. >> >> >> >> >> _______________________________________________ >> >> 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 > > --------------040003050309040805020507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Okay, glad to hear it :)

Thanks,
Gili

On 25/11/2013 3:21 PM, Justin Uberti wrote:
SDP is just a serialization format, a clumsy yet somehow popular one.

Nothing we decide here on codecs will impose any mandate on what serialization format is used in WebRTC 2.0.


On Mon, Nov 25, 2013 at 9:26 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

<cough> told you so <cough> :)

So folks, what happens when we try removing any mention of SDP from the 2.0 spec? :) Are you saying this is no longer possible?

Gili


On 25/11/2013 2:43 AM, Christer Holmberg wrote:

Hi,

 

I’m afraid that SDP has become is a little more than an implementation detail :)

 

Regards,

 

Christer

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
Sent: 25. marraskuuta 2013 9:35
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Asymmetric codecs

 


SDP is supposed to be an implementation detail. Let's figure out whether asymmetric codecs solve our problems and wedge it into SDP later.

I suspect that this approach reduces the IPR risk, but H.264 royalties still apply, do they not?

Sadly this means we're stuck with: "MUST decode at least two of [VP8, H.264, H.261] and MUST encode at least one of them".

Gili

On 25/11/2013 2:24 AM, Christer Holmberg wrote:

Hi,

 

First, from a pure MTI codec perspective, the question is whether usage of asymmetric codecs would solve the issues that people have.

 

Second, from an SDP OA/BUNDLE perspective, I don’t think we can mandate usage of BUNDLE. And, even if we did, in the initial Offer you still need to assign unique port values for each m- line (as agreed in Vancouver).

 

…unless, of course, you assign an SDP ‘bundle-only’ attribute to all m- lines with asymmetric codecs.

 

Regards,

 

Christer

 

From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
Sent: 25. marraskuuta 2013 4:11
To: Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
Cc: rtcweb@ietf.org
Subject: Asymmetric codecs

 

I started a draft on how to standardize support for asymmetric codecs back in September. The primary motivation was decoding H.264 and H.265 while only encoding H.264. A secondary motivation, for rtcweb, was decoding H.264 and VP8 while only encoding one of them, as Stefan mentioned. I thought it would be a trivial thing to write up by the Oct. 6 deadline for MTI proposals. The draft is still incomplete and unpublished because all solutions are ugly and overly complex for something so seemingly trivial, just like bundle and unified plan. I now sympathize with Christer and Adam for how they arrived at those (not exactly elegant) solutions, and agree with Martin that a pair of (bundled) m-lines is the most viable (although not exactly elegant) solution for asymmetric codecs.

 

RFC 4317 drafts originally included asymmetric codecs until they were removed in draft 02:

 

They were removed for fear of issues with shared ports:

 

Now that we (almost) have bundle, can we resurrect asymmetric codecs with separate sendonly and recvonly m-lines? Are folks ok with a dependency on bundle? I would be happy to complete a draft in that direction. (That is, a general mmusic draft on asymmetric codecs, not a rtcweb draft on MTI asymmetric codecs. I will move the discussion to mmusic after getting rtcweb opinions first.)

 

Some may consider this a bizarre corner case. However, for hardware codecs, it is the norm not the exception to have asymmetric encoder and decoder formats. Especially for new formats, which usually appear in hardware decoders well before hardware encoders are available. This happened for H.264, H.265, VP8, and virtually every popular codec format in virtually every popular chipset.

 

Mo

 

On 11/23/13, 9:09 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Like some others, I think the must-decode-both-must-endcode-one alternative as such sounds interesting (whether it has any impact on the licence/IPR issues I'll leave to others to speak for). However, I have big concerns over the proposal to indicate sendrecv for a codec even if an entity is only able to receive/decode it. … Usage of unidirectional, sendonly/recvonly, m- line would of course solve this, and you might know that it is one option we are discussing in CLUE (for other reasons than MTI codec, though).

 

On 22 November 2013 16:20, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:

I gave this as an example of a possible way to do it, but that means you need two separate m= lines - one for send and one for receive. Seems strange to do this for something that you really want to be a single bi-directional stream.

 

On 11/22/13, 8:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

The bidirectional thing in O/A is the strange way to do things.  Two lines is pretty intuitive.

 




_______________________________________________
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



--------------040003050309040805020507-- From lgeyser@gmail.com Mon Nov 25 12:54:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EA31ADFF3 for ; Mon, 25 Nov 2013 12:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-2FYsZ7ZnX5 for ; Mon, 25 Nov 2013 12:54:25 -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 DC6E71ADFE6 for ; Mon, 25 Nov 2013 12:54:24 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id c11so3630394lbj.19 for ; Mon, 25 Nov 2013 12:54:24 -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=YghruF8G8xvU33/MOyZQrvhhCP5S5+fYOU5knd1D0ug=; b=PNB6yRRBjJ9A5nzc2l1Q7XWx2wlNcf8yQc3EVl6J25bqoJIAGWBuGQ1BsEeohbpN9D LWVrUo6MGMn7XGsTA67d6rcgFJAztRVFfD8NLLiWW15JWNI1IB/SUXPfap9wUItbMta9 kzoGQgblLjjo/cU9AtgVbU7apLw3kgfgqHuHET65WvoppXkRY3fXcwZP1iA/mJMvuRtX 9Uud4uM1tOqwbjhNJk8QAgnXY/iGMYJERK/zs0SPbCPmSSsBLEpmnJdAbTjUkbrqytpY DkqAKofJEAGxB/hQ/L/beGTtHkJ5lw+IasACAJjqTiHDHDsIYpHRxO6vWYZqfHRiTG1X 9nBw== MIME-Version: 1.0 X-Received: by 10.152.219.133 with SMTP id po5mr2708060lac.34.1385412864278; Mon, 25 Nov 2013 12:54:24 -0800 (PST) Received: by 10.114.168.70 with HTTP; Mon, 25 Nov 2013 12:54:24 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Nov 2013 22:54:24 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113429c0a4857d04ec069170 Subject: Re: [rtcweb] H.263 Baseline vs. H.261? (Was: H.263 licensing situation) X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 20:54:27 -0000 --001a113429c0a4857d04ec069170 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>3.) People can live with the IPR risk. (I don't think we can conduct a comprehensive study within the WG, but people need to >>draw their own conclusions.) H.263 sounds risky to me since it is only 17 years old. I would feel more comfortable with H.261. Even Theora feels less risky than H.263. On 25 November 2013 22:14, wrote: > Hi Stephan, all, > > Stephan Wenger wrote: > > > > H.263 baseline is insufficient for rtcweb=B9s purposes, as it does not > allow > > arbitrary picture sizes. You want to have at least the PLUSPTYPE pictu= re > > header extension which allows arbitrary picture sizes. You also probab= ly > > want a few of the optional modes, especially the bug-fixes (improved VL= C) > > and the deblocking filter. Patents related to this technologies are no= t > > covered under the MPEG-LA MPEG-4 part 2 license. > > > > How would you compare H.263 Baseline to H.261? Or H.263 Baseline with > PLUSTYPE extension to H.261? Based on the list discussion it seems quite > clear that none of the main browser vendors is really interested in > including H.261, even if it was IPR-free. Would H.263 Baseline suck more = or > less? I have gotten an(other) educated opinion that the H.263 Baseline IP= R > risk was "virtually non-existent" already a few years back. > > In any case we need to define what "H.263" actually means within the > alternatives. Does it stand for the H.263 Baseline, or do we want to add > some of the features listed in Stephan's mail to make it usable? > > I'm currently thinking that "MUST implement any two of {VP8, H.264 CBP, > H.263}" is the only sensible outcome for the WG apart from the "MUST > implement either one of {VP8, H.264 CBP}, that I assume everyone will > anyway be compliant with. But that would require: > 1.) Define what exactly "H.263" is in this context: Baseline or Baseline > plus a set of extensions > 2.) People consider it better than H.261, and actually usable for WebRTC > 3.) People can live with the IPR risk. (I don't think we can conduct a > comprehensive study within the WG, but people need to draw their own > conclusions.) > > Markus > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of ext Stephan Wenger > > Sent: 18 November, 2013 18:36 > > To: rtcweb@ietf.org > > Subject: [rtcweb] H.263 licensing situation > > > > Hi, > > > > Here is what I know or suspect regarding H.263 licensing: > > > > Know: > > > > Leon is correct, there are type 2 patent declarations in the ITU agains= t > H.263. > > > > Maik is also correct, H.263 baseline is a subset of MPEG-4 part 2. > MPEG-4 > > part 2 is generally considered royalty bearing and the license has been > > enforced. However, very few (no one?) is using strict H.263 baseline, > and > > even for an only slightly more advanced use of H.263 (no need to go to > > H.263+, for example), the MPEG-4 portfolio license would not apply. > > > > H.263 has been the predominant codec in the video conferencing industry > > for close to a decade (ca. 1996 through ca. 2005). In all this time, I > have heard > > of one single instance of patent assertion by a non-troll against > several of the > > large video conferencing vendors. However, since those vendors all use= d > a > > chip produced by the non-troll, they had enough commercial leverage to > > fend off those assertions without the dispute ever going to trial and, > so I > > hear, without paying any premium for the use of > > the patent. The patent in question has now expired. > > > > H.263 baseline is insufficient for rtcweb=B9s purposes, as it does not > allow > > arbitrary picture sizes. You want to have at least the PLUSPTYPE pictu= re > > header extension which allows arbitrary picture sizes. You also probab= ly > > want a few of the optional modes, especially the bug-fixes (improved VL= C) > > and the deblocking filter. Patents related to this technologies are no= t > > covered under the MPEG-LA MPEG-4 part 2 license. > > > > Suspect: > > > > Since we would most likely not use strict H.263 baseline, the war-chest > of the > > MPEG-LA pool cannot be used to enforce a patent against our hypothetica= l > > H.263 implementation because it is not MPEG-4 part 2 compliant. Which, > in > > turn, means that the MPEG-4 part 2 rightholders would be on their own i= n > > asserting their patents. Which, in turn, means that there is no > difference > > between H.263 and other non-pooled video codecs from an MPEG-LA > > related risk assessment. > > > > > > There have been patent assertions by trolls allegedly related to video > > compression in general and H.263 in particular, but those happen all th= e > time > > and there is not much one can do about them. Once you are a juicy enou= gh > > target (based on the troll=B9s perception of relationship between your > legal > > competence versus your size) the troll will find you. > > Technicalities such as whether the patent is actually infringed or > related to > > standards are secondary at best in the eye of a troll. Their business, > at least > > when going against smaller companies, is to settle for a few hundreds o= f > > thousands--an amount the alleged infringer can pay without excessive > hurt-- > > thereby filling their war chest and then go to the next =B3customer=B2.= When > > they meet determined opposition (based on a combination of legal and > > technical competence), they often move on to greener pastures. > > > > As H.263 is fairly widely deployed, and I have not heard about patent > > assertions except the cases mentioned above, the risk of a successful > patent > > assertion is probably manageable for almost everyone with sufficient > legal > > resources. At least in countries that allow equitable defenses (implie= d > > license, laches, estoppel). > > > > So is it worth evaluating H.263 further? IMO, probably not. It=B9s > doubtless > > technically better than H.261, but the risk is inproportionally higher. > And the > > whole idea of this substandard baseline codec has been to be essentiall= y > > without risk. > > > > Stephan > > > > > > > > > > > _______________________________________________ > > 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 > --001a113429c0a4857d04ec069170 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>3.) People can live with the IPR risk. (= I don't think we can conduct a=20 comprehensive study within the WG, but people need to >>draw their ow= n=20 conclusions.)
H.263 sounds risky to me since it is only 17 years o= ld. I would feel more comfortable with H.261.
Even Theora feels le= ss risky than H.263.


On 25 November 2013 22:14, <Markus.Isomaki@nokia.com> wrote:
Hi Stephan, all,

Stephan Wenger wrote:
>
> H.263 baseline is insufficient for rtcweb=B9s purposes, as it does not= allow
> arbitrary picture sizes. =A0You want to have at least the PLUSPTYPE pi= cture
> header extension which allows arbitrary picture sizes. =A0You also pro= bably
> want a few of the optional modes, especially the bug-fixes (improved V= LC)
> and the deblocking filter. =A0Patents related to this technologies are= not
> covered under the MPEG-LA MPEG-4 part 2 license.
>

How would you compare H.263 Baseline to H.261? Or H.263 Baseline with PLUST= YPE extension to H.261? Based on the list discussion it seems quite clear t= hat none of the main browser vendors is really interested in including H.26= 1, even if it was IPR-free. Would H.263 Baseline suck more or less? I have = gotten an(other) educated opinion that the H.263 Baseline IPR risk was &quo= t;virtually non-existent" already a few years back.

In any case we need to define what "H.263" actually means within = the alternatives. Does it stand for the H.263 Baseline, or do we want to ad= d some of the features listed in Stephan's mail to make it usable?

I'm currently thinking that "MUST implement any two of {VP8, H.264= CBP, H.263}" is the only sensible outcome for the WG apart from the &= quot;MUST implement either one of {VP8, H.264 CBP}, that I assume everyone = will anyway be compliant with. But that would require:
1.) Define what exactly "H.263" is in this context: Baseline or B= aseline plus a set of extensions
2.) People consider it better than H.261, and actually usable for WebRTC 3.) People can live with the IPR risk. (I don't think we can conduct a = comprehensive study within the WG, but people need to draw their own conclu= sions.)

Markus


> -----Original Message-----
> From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ie= tf.org] On
> Behalf Of ext Stephan Wenger
> Sent: 18 November, 2013 18:36
> To: rtcweb@ietf.org
> Subject: [rtcweb] H.263 licensing situation
>
> Hi,
>
> Here is what I know or suspect regarding H.263 licensing:
>
> Know:
>
> Leon is correct, there are type 2 patent declarations in the ITU again= st H.263.
>
> Maik is also correct, H.263 baseline is a subset of MPEG-4 part 2. =A0= MPEG-4
> part 2 is generally considered royalty bearing and the license has bee= n
> enforced. =A0However, very few (no one?) is using strict H.263 baselin= e, and
> even for an only slightly more advanced use of H.263 (no need to go to=
> H.263+, for example), the MPEG-4 portfolio license would not apply. >
> H.263 has been the predominant codec in the video conferencing industr= y
> for close to a decade (ca. 1996 through ca. 2005). =A0In all this time= , I have heard
> of one single instance of patent assertion by a non-troll against seve= ral of the
> large video conferencing vendors. =A0However, since those vendors all = used a
> chip produced by the non-troll, they had enough commercial leverage to=
> fend off those assertions without the dispute ever going to trial and,= so I
> hear, without paying any premium for the use of
> the patent. =A0 The patent in question has now expired.
>
> H.263 baseline is insufficient for rtcweb=B9s purposes, as it does not= allow
> arbitrary picture sizes. =A0You want to have at least the PLUSPTYPE pi= cture
> header extension which allows arbitrary picture sizes. =A0You also pro= bably
> want a few of the optional modes, especially the bug-fixes (improved V= LC)
> and the deblocking filter. =A0Patents related to this technologies are= not
> covered under the MPEG-LA MPEG-4 part 2 license.
>
> Suspect:
>
> Since we would most likely not use strict H.263 baseline, the war-ches= t of the
> MPEG-LA pool cannot be used to enforce a patent against our hypothetic= al
> H.263 implementation because it is not MPEG-4 part 2 compliant. =A0Whi= ch, in
> turn, means that the MPEG-4 part 2 rightholders would be on their own = in
> asserting their patents. =A0Which, in turn, means that there is no dif= ference
> between H.263 and other non-pooled video codecs from an MPEG-LA
> related risk assessment.
>
>
> There have been patent assertions by trolls allegedly related to video=
> compression in general and H.263 in particular, but those happen all t= he time
> and there is not much one can do about them. =A0Once you are a juicy e= nough
> target (based on the troll=B9s perception of relationship between your= legal
> competence versus your size) the troll will find you.
> Technicalities such as whether the patent is actually infringed or rel= ated to
> standards are secondary at best in the eye of a troll. =A0Their busine= ss, at least
> when going against smaller companies, is to settle for a few hundreds = of
> thousands--an amount the alleged infringer can pay without excessive h= urt--
> thereby filling their war chest and then go to the next =B3customer=B2= . =A0When
> they meet determined opposition (based on a combination of legal and > technical competence), they often move on to greener pastures.
>
> As H.263 is fairly widely deployed, and I have not heard about patent<= br> > assertions except the cases mentioned above, the risk of a successful = patent
> assertion is probably manageable for almost everyone with sufficient l= egal
> resources. =A0At least in countries that allow equitable defenses (imp= lied
> license, laches, estoppel).
>
> So is it worth evaluating H.263 further? =A0IMO, probably not. =A0It= =B9s doubtless
> technically better than H.261, but the risk is inproportionally higher= . =A0And the
> whole idea of this substandard baseline codec has been to be essential= ly
> without risk.
>
> Stephan
>
>
> >
>
> _______________________________________________
> 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

--001a113429c0a4857d04ec069170-- From derhoermi@gmx.net Mon Nov 25 14:40:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE01AE07C for ; Mon, 25 Nov 2013 14:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcoBTpPdkVw2 for ; Mon, 25 Nov 2013 14:40:13 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id F03401AE06A for ; Mon, 25 Nov 2013 14:40:12 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.12.181]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MLA45-1Vknhy46XB-000N2e for ; Mon, 25 Nov 2013 23:40:12 +0100 From: Bjoern Hoehrmann To: rtcweb@ietf.org Date: Mon, 25 Nov 2013 23:40:13 +0100 Message-ID: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:VXPyKtzQdAQXPvCS/wesPWIvTddUdccrbxdNnid6rHVSfcxirIJ WzUweiA1p9+vw6jeVcWPKT3mcC2dQCb9tGKqzi4ikMcUtRroWj8WQEkZ/njlJIc0GgRKPLf uMxZ40I8CfX2KQug5DzSmzQ+U8v7xhJqMcLgDSSfvhU19S4F2L/sT5MqXa5Fn9yupXrIonh y+jQuw7MOBpB62fFZ0HbQ== Subject: [rtcweb] Trademarks in draft-ietf-rtcweb-security-05 X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 22:40:15 -0000 Hi, http://tools.ietf.org/html/draft-ietf-rtcweb-security-05#section-4.1.1 has "For example, an attacker site might request screen sharing and then briefly open up a new Window to the user's bank or Gmail account, using screen sharing to read the resulting displayed content." It is neither necessary nor useful to refer to a specific product here, use "webmail" or something like that. Thanks, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From jlaurens@cisco.com Mon Nov 25 15:53:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB0B1AE0C6 for ; Mon, 25 Nov 2013 15:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3bwwXw8Z1MD for ; Mon, 25 Nov 2013 15:53:51 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3721AE0BA for ; Mon, 25 Nov 2013 15:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3765; q=dns/txt; s=iport; t=1385423631; x=1386633231; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GOAMEt26nH0PynzvW/u9vv/Td8GzJmYNpxPPoty79i4=; b=B3IwtuWQ5yqBHX97VBVVZ6o4k3rESGoYhV1C/IxE89EKjKnW0xdKGxYr Uk0HM3hO2EQpXOLFscoJSsWWLArkIWPVQ7zjaT8tWgx0Y8PNK07Fd9/z+ 5B4kqqjE8tszPdqtk6WIqcC52inXQN7BdFZ+WViLM7SyGCZCkEBmM9jsI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEGAMXhk1KtJV2d/2dsb2JhbABDEgSCQ0Q4tC+IAU6BJhZ0giYBAQQBAQFrCxACAQgECh0CEgcnCxQRAgQOBYdvAw8NvjYXjHiBJSw6BAcJAYMWgRMDiQqPCoEwkGKDKA X-IronPort-AV: E=Sophos;i="4.93,770,1378857600"; d="scan'208,217";a="287550136" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 25 Nov 2013 23:53:51 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAPNroZQ025710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 23:53:50 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.23]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 25 Nov 2013 17:53:50 -0600 From: "Jeremy Laurenson (jlaurens)" To: Bjoern Hoehrmann Thread-Topic: [rtcweb] Trademarks in draft-ietf-rtcweb-security-05 Thread-Index: AQHO6i9Xd/Sbv7xKD0ql4/IU7jU2cpo2ns3L Date: Mon, 25 Nov 2013 23:53:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CD58C55CB2124BE4A742E944645EE312ciscocom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Trademarks in draft-ietf-rtcweb-security-05 X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 23:53:52 -0000 --_000_CD58C55CB2124BE4A742E944645EE312ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How about "or other account" Jeremy Laurenson Distinguished Engineer Cisco Global Collab Sales Strategy On Nov 25, 2013, at 5:40 PM, "Bjoern Hoehrmann" > wrote: Hi, http://tools.ietf.org/html/draft-ietf-rtcweb-security-05#section-4.1.1 has "For example, an attacker site might request screen sharing and then briefly open up a new Window to the user's bank or Gmail account, using screen sharing to read the resulting displayed content." It is neither necessary nor useful to refer to a specific product here, use "webmail" or something like that. Thanks, -- Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehrma= nn.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.d= e 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CD58C55CB2124BE4A742E944645EE312ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How about "or other account"

Jeremy Laurenson
Distinguished Engineer
Cisco Global Collab Sales Strategy

On Nov 25, 2013, at 5:40 PM, "Bjoern Hoehrmann" <derhoermi@gmx.net> wrote:

Hi,

 http://tools.ietf.org/html/draft-ietf-rtcweb-security-0= 5#section-4.1.1
has "For example, an attacker site might request screen sharing = and then
briefly open up a new Window to the user's bank or Gmail account, usi= ng
screen sharing to read the resulting displayed content." It is n= either
necessary nor useful to refer to a specific product here, use "w= ebmail"
or something like that.

Thanks,
--
Bj=F6rn H=F6hrmann =B7 mailto:= bjoern@hoehrmann.de =B7 http://bjoern.hoehrmann.de
Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.de
25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_CD58C55CB2124BE4A742E944645EE312ciscocom_-- From derhoermi@gmx.net Mon Nov 25 15:56:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1637A1AE0BA for ; Mon, 25 Nov 2013 15:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHB9xJ7mGSQf for ; Mon, 25 Nov 2013 15:56:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4E31AE07F for ; Mon, 25 Nov 2013 15:56:49 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.12.181]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0LkTSx-1VD8mY0P4l-00cNf7 for ; Tue, 26 Nov 2013 00:56:49 +0100 From: Bjoern Hoehrmann To: "Jeremy Laurenson (jlaurens)" Date: Tue, 26 Nov 2013 00:56:50 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:5ZTNDVUdz34jaiP95fqmSXUgx25MKfEC3VfPN+9ZN5BbHs6MtIx yuk4vPdVvE2rJUWr5egd5OWBfK8Pkyh9jDjo9n4lb6reiPh37JbaXhh0ndvh0i3rlFkItJQ Tf5WbC3eIu/6z6b3VPgeg2uPfgZ0ACyUZX8ZUDnaU1ybIBO/YJzzHWVG6w2Xqo4UhTn+N3X a2z+117i3N3dp3vMFHCaw== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Trademarks in draft-ietf-rtcweb-security-05 X-BeenThere: rtcweb@ietf.org 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, 25 Nov 2013 23:56:51 -0000 * Jeremy Laurenson (jlaurens) wrote: >How about "or other account" (That would be fine with me.) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From juberti@google.com Mon Nov 25 16:24:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEF71AE0A2 for ; Mon, 25 Nov 2013 16:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUQfX5xlnI9i for ; Mon, 25 Nov 2013 16:24:12 -0800 (PST) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 155761ADF92 for ; Mon, 25 Nov 2013 16:24:11 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id x11so3361198vbb.34 for ; Mon, 25 Nov 2013 16:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ys1iT5bOvxQJTNkNm5O6xomaqS18FPuywAESuhizP0o=; b=cRCw3qjd1NITABCTcEMBxruCN2lagmQaoOUY23jQS0k0CgRmbtVteAV/2jRsdvLSv3 Tl4NpIPMhRVmvsGuUvnN8mWDaScrY3Rw50eB//t5CiyedsY4oCLOq5rEwI6igoeVOlPn 6ZeF/nZx6ucOv9IbxvOphjNdd97sk8YOfMwQrF7eV+360h76uNxY+9h07aVE8RmoD0JF RmSy+KZCZq5pXGMwQMnwY2FHqTn51OTw3yb0dhAZ5iCP5D0zsiClZHZ7AQYduARND0Cs KyjsY5sH+zqFafECGh1B6r3JI+smvRboYGKQm6loIIhhRHSeYltoyasEkddTIaQXgCpu hNyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ys1iT5bOvxQJTNkNm5O6xomaqS18FPuywAESuhizP0o=; b=cDNxZZ9HKHcXcdFBQ17zAdwZ5nKEoMTsn3yBGIfddDH4GgSwC4CYB9x72UX3ImrtTU cm0Vog+VxQclFlmW5kn+Lr5H6q/4Ofkoc+VDa+4YuItQc/c2jKCAdZa30fPA3J6AhbhE Ztv3Pmy3vXOmWIuKmlPx3EjYTyL9JpTmcwX/tGB3tl8ISyUfkXW8Xd9NW4xeVfvQ8/vP oUdVykXjG+gbUXjD54m6GC6XkP/3kYZigC1tMfb9i6edRUSqGwsVdmBYubNiCLuvxs9O 0ObdEZuuEeYbiOzn3LH/7XLTmhbeYnkrHWQDiIeNvG0D8W1aVS0p3bhtjqVotLuXVRiI DMDA== X-Gm-Message-State: ALoCoQmdUu/FCjyHR+9GORK9tWlNJxgllUpn40x1xCqERnC4cXMY8CtN1UWPThi8cXdJ7q9wL6F7NJ/VZAh5YrfIq+mrcTLGCxD+Y0FJRcpGHn+TfTuyNgf3aQI02mvUsU1+cChGp1FiENK9TdU7WtDaTyYeAG2OYjv14NQrCxCnU4mG2t+xdzPiBwlk0+yNZkvUAOxoNJiS X-Received: by 10.221.60.134 with SMTP id ws6mr8066vcb.44.1385425450752; Mon, 25 Nov 2013 16:24:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Mon, 25 Nov 2013 16:23:50 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Mon, 25 Nov 2013 16:23:50 -0800 Message-ID: To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=001a113393a4db626004ec097f31 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Trademarks in draft-ietf-rtcweb-security-05 X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 00:24:13 -0000 --001a113393a4db626004ec097f31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 'webmail' seems more informative than 'other'. On Mon, Nov 25, 2013 at 3:56 PM, Bjoern Hoehrmann wrote= : > * Jeremy Laurenson (jlaurens) wrote: > >How about "or other account" > > (That would be fine with me.) > -- > Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://= bjoern.hoehrmann.de > Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoern= sworld.de > 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.w= ebsitedev.de/ > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113393a4db626004ec097f31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
'webmail' seems more informative than 'other&#= 39;.


On = Mon, Nov 25, 2013 at 3:56 PM, Bjoern Hoehrmann <derhoermi@gmx.net><= /span> wrote:
* Jeremy Laurenson (jlaure= ns) wrote:
>How about "or other account"

(That would be fine with me.)
--
Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://bjoern.hoehrmann.de
Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoernsworld.de
25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.websitedev.de/
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a113393a4db626004ec097f31-- From hangzhou.chenxin@huawei.com Mon Nov 25 18:16:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DA01AE122 for ; Mon, 25 Nov 2013 18:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF0OB3jZVw3R for ; Mon, 25 Nov 2013 18:16:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A31351AE123 for ; Mon, 25 Nov 2013 18:16:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAR94270; Tue, 26 Nov 2013 02:16:37 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 02:16:04 +0000 Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 02:16:31 +0000 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.191]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Tue, 26 Nov 2013 10:16:27 +0800 From: "Chenxin (Xin)" To: "Markus.Isomaki@nokia.com" , "magnus.westerlund@ericsson.com" , "lgeyser@gmail.com" Thread-Topic: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? Thread-Index: AQHO6emAL0HmNLHA8EW7Ei95u3URtJo1e8EAgAADrICAAFYogIAA7Lig Date: Tue, 26 Nov 2013 02:16:27 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE0397680A16A5@SZXEMA504-MBX.china.huawei.com> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 02:16:44 -0000 Hi >-----Original Message----- >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of >Markus.Isomaki@nokia.com >Sent: Tuesday, November 26, 2013 3:52 AM >To: magnus.westerlund@ericsson.com; lgeyser@gmail.com >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? > >Hi, > >magnus.westerlund@ericsson.com wrote: >> >> On 2013-11-25 15:30, Leon Geyser wrote: >> > Hi Magnus, >> > >> > Was H.263 a typo? >> > I agree that 10 can be changed to: >> > 10. MUST implement at least two of {VP8, H.264 CBP, H.261} >> >> Sorry, >> >> I did a mistake in this call. I missed that 10 and 11 talked about H.261= and >> H.263 respectively. >> >> I think the above question of writing 10 in the above proposed format is= then >> the relevant question to the WG. >> > >I agree that alternatives 10. and 11. are better to be written in the same >format: > >10. MUST implement at least two of {VP8, H.264 CBP, H.261} >11. MUST implement at least two of {VP8, H.264, H.263} > [Xin]I forget who proposed 10 first, but there are differences between new = 10 and origin 10.=20 In origin 10, H.261 has little chance be implemented. I don't think it is p= ossible that one browser do not implement both H.264 and vp8, but implement= H.261. even it is possible, only implement H.261 will not be helpful for i= nteroperation.=20 In alternatives 10, H.261 has much more possible be used, which is designed= for interoperation purpose.=20 So I agree to change alternatives 10. to 10. MUST implement at least two of {VP8, H.264 CBP, H.261} >I assume H.264 CBP =3D Constrained Baseline Profile as proposed in >draft-burman-rtcweb-h264-proposal. > >For H.263 we would need to define if it means H.263 Baseline or something >beyond that. I have seen at least Stephan Wenger arguing that H.263 Baseli= ne is >not suitable for WebRTC. [xin]It is good we could get consensus on H.263 profile before the voting, = which will be a argument if we miss it now. > >Markus >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From cowwoc@bbs.darktech.org Tue Nov 26 00:13:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734E21AC4A7 for ; Tue, 26 Nov 2013 00:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnNHcp-up1Yt for ; Tue, 26 Nov 2013 00:13:41 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 163391AC441 for ; Tue, 26 Nov 2013 00:13:40 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so8420506ief.20 for ; Tue, 26 Nov 2013 00:13:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=L02+F5x2XAZI7jvPIyqcHYyV43SF2e2EKScInmSZLWU=; b=JP/MXHKtq4AlTnNno7VcS86f+RgeRucyPcfnJhU/u+vA0fMADbVl3YGkzFYs92OsOG FxZhLjoQR4iHO8BzxOSu/nLdl7VcW7JnXJMgpfYm4h3ZTEwtcTzDf0fipR5wgVz3FvaZ ovBVumw0YuYc0N8ah7o0YtpQM6Ii5Ca1J/GXc2Lb9FGzVyeqtkFKsqENYHczc9NW31vg iBW5fDnseYgu+H+qrDlTjuqUmMWPMjyoeH7DSuKIbIYmBqwImDOSSE2avznS5k0WCB/u Vp+HeJA+EqXX/yoAAcMBWrsxzbQOvqgxxFjhCJMnaZC2zaVZwlV7A7MLlWZHshu2PDJB pf5Q== X-Gm-Message-State: ALoCoQlAsAmKKAHwTpufSGAtzOZOo4WzDWhOq5BNiQWleX4qWW42vBfcQT6QNzHI2R8K3dipm4S5 X-Received: by 10.50.17.100 with SMTP id n4mr16086819igd.11.1385453620850; Tue, 26 Nov 2013 00:13:40 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ri5sm30520911igc.1.2013.11.26.00.13.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 00:13:40 -0800 (PST) Message-ID: <52945813.2050309@bbs.darktech.org> Date: Tue, 26 Nov 2013 03:13:07 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <9E34D50A21D1D1489134B4D770CE0397680A16A5@SZXEMA504-MBX.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE0397680A16A5@SZXEMA504-MBX.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 08:13:42 -0000 On 25/11/2013 9:16 PM, Chenxin (Xin) wrote: > [Xin]I forget who proposed 10 first, but there are differences between > new 10 and origin 10. In origin 10, H.261 has little chance be > implemented. I don't think it is possible that one browser do not > implement both H.264 and vp8, but implement H.261. even it is > possible, only implement H.261 will not be helpful for interoperation. > In alternatives 10, H.261 has much more possible be used, which is > designed for interoperation purpose. So I agree to change alternatives > 10. to 10. MUST implement at least two of {VP8, H.264 CBP, H.261} You're missing the point of MTI. If H.261 is MTI, nothing prevents you from supporting VP8 and H.264 anyway. It is possible for mobile applications that interact with web clients to only need lower-resolution videos (think: accessibility applications). It is quite reasonable for them to only implement H.261 and no one will be harmed because specialized applications are not meant to act as generic web browsers. Gili From tireddy@cisco.com Tue Nov 26 02:34:13 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4BE1ADFDA for ; Tue, 26 Nov 2013 02:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhhiTaCsKjYj for ; Tue, 26 Nov 2013 02:34:12 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2E06F1ADFA0 for ; Tue, 26 Nov 2013 02:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1971; q=dns/txt; s=iport; t=1385462052; x=1386671652; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vYJZZ05/pJ3gn/8SeDKP1jJiKBz4Jgpozma89vvJbRA=; b=PpvvwUrKsYWlqwVT/L++mE/iQGkLYkXxB9KG5RYXOGxY9TDrLKvIlsRf YBzUZ0HwTrvhiKOGxyM6bgKY2jdtSQt4M2TH10ing4oV67AHRoNsLFPDr x3NI17JHpVuqbZpFdpaNwzNO7C34/ZCfOAZ5FkuugtYArz8tpzMf7FcJv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAPd3lFKtJXG8/2dsb2JhbABZgwc4U6kqkmyBKhZ0giUBAQEDAXkFCwIBCBEEAQELHQcyFAkIAgQBDQUIh2cDCQYNvyUXjGeBXjEHgyCBEwOJCo0ggxqLKYU4gyiBaAc7 X-IronPort-AV: E=Sophos;i="4.93,773,1378857600"; d="scan'208";a="287573523" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 26 Nov 2013 10:34:11 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAQAYB0d011014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 10:34:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 04:34:11 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Bernard Aboba , Martin Thomson Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 Thread-Index: AQHO5h7F18JxZ44GPE2jRnBwqO7Il5o3GL0w Date: Tue, 26 Nov 2013 10:34:10 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> References: , <5285E318.3090006@ericsson.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.69.77] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 10:34:13 -0000 Hi Bernard, Yes, this needs to be discussed further. With DTLS, there is no need to sen= d consent checks if authentic SRTP/SRTCP packets are being received. we ma= y also want to compare DTLS heartbeat mechanism with STUN consent. Some of = my observations: [1] Remote peer may or may not support DTLS heartbeat.=20 [2] DTLS heartbeat can only be sent if remote peer accepts heartbeat reques= t.=20 [1] and [2] can be solved by mandating WebRTC endpoints to support consent. [3] DTLS heartbeat seems to be more CPU intensive than STUN consent (Genera= ting arbitrary content (payload and padding 40 bytes), encrypting it). Thou= gh this may not a concern since heartbeat will only be sent when authentica= ted packets are not received. [4] DTLS heartbeat doubles the timer value at each retransmission but with = STUN consent retransmission is repeated every 500ms. There seems to be no a= pplication level control on the retransmission mechanism used by OpenSSL DT= LS implementation.=20 [5] With STUN consent, browser can find the RTT time which is not possible = with OpenSSL DTLS heartbeat API.=20 [4] and [5] need enhancement in OpenSSL. -Tiru. From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Thursday, November 21, 2013 12:02 AM To: Martin Thomson Cc: Magnus Westerlund; draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.= org; rtcweb@ietf.org; Eric Rescorla Subject: RE: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness= -00 > I think that it's at least in good enough shape=A0to put up for wider dis= cussion. > http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00 >=20 > Overall, I think that this is cleaner. The main advantage is that any > authenticated data counts toward refreshing consent. That means zero > overhead in many common cases. [BA] I have to agree that it is worth discussing, particularly given the po= tential for zero additional overhead.=A0 From Michael.Tuexen@lurchi.franken.de Tue Nov 26 03:14:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E6A1ADFA0 for ; Tue, 26 Nov 2013 03:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bssPWyMQZ8BC for ; Tue, 26 Nov 2013 03:14:46 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 602EB1AE1B2 for ; Tue, 26 Nov 2013 03:14:46 -0800 (PST) Received: from [10.225.15.120] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A16081C0C0692; Tue, 26 Nov 2013 12:14:44 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> Date: Tue, 26 Nov 2013 12:14:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <49668FCC-875C-4567-946C-4D6C759B9EA4@lurchi.franken.de> References: , <5285E318.3090006@ericsson.com>, , <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> To: Tirumaleswar Reddy (tireddy) X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 11:14:49 -0000 On Nov 26, 2013, at 11:34 AM, Tirumaleswar Reddy (tireddy) = wrote: > Hi Bernard, >=20 > Yes, this needs to be discussed further. With DTLS, there is no need = to send consent checks if authentic SRTP/SRTCP packets are being = received. we may also want to compare DTLS heartbeat mechanism with = STUN consent. Some of my observations: >=20 > [1] Remote peer may or may not support DTLS heartbeat.=20 > [2] DTLS heartbeat can only be sent if remote peer accepts heartbeat = request.=20 >=20 > [1] and [2] can be solved by mandating WebRTC endpoints to support = consent. >=20 > [3] DTLS heartbeat seems to be more CPU intensive than STUN consent = (Generating arbitrary content (payload and padding 40 bytes), encrypting = it). Though this may not a concern since heartbeat will only be sent = when authenticated packets are not received. >=20 > [4] DTLS heartbeat doubles the timer value at each retransmission but = with STUN consent retransmission is repeated every 500ms. There seems to = be no application level control on the retransmission mechanism used by = OpenSSL DTLS implementation.=20 >=20 > [5] With STUN consent, browser can find the RTT time which is not = possible with OpenSSL DTLS heartbeat API.=20 >=20 > [4] and [5] need enhancement in OpenSSL. As you say: This is just an implementation issue of one particular = implementation, not an issue with the protocol itself... Best regards Michael >=20 > -Tiru. >=20 > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Thursday, November 21, 2013 12:02 AM > To: Martin Thomson > Cc: Magnus Westerlund; = draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org; = rtcweb@ietf.org; Eric Rescorla > Subject: RE: [rtcweb] RFC 6520 vs. = draft-ietf-rtcweb-stun-consent-freshness-00 >=20 >> I think that it's at least in good enough shape to put up for wider = discussion. >> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00 >>=20 >> Overall, I think that this is cleaner. The main advantage is that any >> authenticated data counts toward refreshing consent. That means zero >> overhead in many common cases. >=20 > [BA] I have to agree that it is worth discussing, particularly given = the potential for zero additional overhead.=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From martin.thomson@gmail.com Tue Nov 26 10:13:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928831ADFE3 for ; Tue, 26 Nov 2013 10:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adzUc35Ea2F3 for ; Tue, 26 Nov 2013 10:13:01 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E740F1ADFB1 for ; Tue, 26 Nov 2013 10:13:00 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id ey16so882269wid.13 for ; Tue, 26 Nov 2013 10:13:00 -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=gnvTpUFKIT9vVmoM5H8igW1sHfXd18u5d9HO+7pLYy0=; b=Y3YO8pfkVKIc0IEyXXbSl6XEtQIYrrdXmPgnsT4zjsUBQwzgqbUosX6daNTGjSJ4Zc rMEedQFhJXg6/w3WuQjUXWfiygMpzE/8KPzr662z+mDhdmLkEg7xTGaJ1npX67DoXEa0 bP+H1sDsvII2WUfIo+Y9wE9Q8IBKqMnOEBjVKMC1SNnO/o/poHQ5TNTSc3U4KQgefzCO KmasuKaQ2ibPEAAU8R8un2lDHzqsaRidBPQRGOdqJ2e+3uqebyZQTqF7uXieZ1vlO/Px BEJh5YeJ8e0RPuWPl3RH4pZ4JeAKn9GaFjQHX2WGFRFCRrYnHzMeZjEB3UxTqd0ynGn4 EMrw== MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr19319571wic.64.1385489580285; Tue, 26 Nov 2013 10:13:00 -0800 (PST) Received: by 10.227.134.195 with HTTP; Tue, 26 Nov 2013 10:13:00 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> Date: Tue, 26 Nov 2013 10:13:00 -0800 Message-ID: From: Martin Thomson To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 18:13:02 -0000 These are good observations. On 26 November 2013 02:34, Tirumaleswar Reddy (tireddy) wrote: > [1] and [2] can be solved by mandating WebRTC endpoints to support consent. Yes, that would be the plan. We would also have to force the inclusion of peer_allowed_to_send(1) in the extension, lest things get perverse. > [3] DTLS heartbeat seems to be more CPU intensive than STUN consent (Generating arbitrary content (payload and padding 40 bytes), encrypting it). Though this may not a concern since heartbeat will only be sent when authenticated packets are not received. I'm thinking: a) not a concern because it's only a factor if you aren't sending, and b) not a concern because it's not a lot of work to generate an authenticated packet. Less work I think if you are using AES-GCM modes. > [4] DTLS heartbeat doubles the timer value at each retransmission but with STUN consent retransmission is repeated every 500ms. There seems to be no application level control on the retransmission mechanism used by OpenSSL DTLS implementation. That's a good point, I'll have to check to see if we need to update 6520, or whether just saying to avoid retransmission is sufficient. (I think the latter, but don't care too much.) > [5] With STUN consent, browser can find the RTT time which is not possible with OpenSSL DTLS heartbeat API. This is true to exactly the same extent for both forms. Some STUN implementations don't allow for the sending of a single check, they also do the full exponential backoff thing. From fluffy@iii.ca Tue Nov 26 11:32:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDD01ADFFD for ; Tue, 26 Nov 2013 11:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6hRZHS2eCVj for ; Tue, 26 Nov 2013 11:32:41 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id DC5FD1ADFBD for ; Tue, 26 Nov 2013 11:32:40 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F2DDE509B6; Tue, 26 Nov 2013 14:32:39 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: <20131121234706.09a04878@rainpc> Date: Tue, 26 Nov 2013 12:32:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1EB8F765-7FA5-4FA1-A3E8-A2B940335B08@iii.ca> References: <52891EDB.2050607@googlemail.com> <528B2ABE.4040701@googlemail.com> <528C79AD.10608@googlemail.com> <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com> <20131121234706.09a04878@rainpc> To: Lorenzo Miniero X-Mailer: Apple Mail (2.1510) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] cisco binary on ec2 X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 19:32:43 -0000 I think for a scenario like that you would use a different approach as = long as you used less than 100k virtual machines - which is a reasonable = assumption for all the cloud services I am aware of. You would take the = source code and compile it to form the executables on the master image = for the VM. You would then distribute the VM normally and not use the = Cisco binary.=20 The other case that has come up is a large enterprise that makes a = master copy of the image that distributed to all their desktops and it = is a case where the company has over 100k desktops. If they own the = desktops my understanding is they are the end user from that point of = view and as long as the IT department downloaded a copy of the Cisco = binary and put it into their master image and then put that master image = on computers they own / operate then that can be made to work too.=20 This stuff is all sort of subtle but there seems to be a wide range of = options that can be made to work and have examples of people already = doing it with H264 MPEG LA licenses.=20 On Nov 21, 2013, at 3:47 PM, Lorenzo Miniero = wrote: > On Thu, 21 Nov 2013 14:33:15 -0800 > Cullen Jennings wrote: >=20 >>=20 >> On Nov 21, 2013, at 12:21 PM, Matt Fredrickson = wrote: >>=20 >>> I cannot use that on my dynamically >>> deployed EC2 instances due to licensing restrictions. :-) >>=20 >>=20 >> My understanding of the legal situation is that you can use the cisco = binary on your EC2 instance and have Cisco pay the MPEG-LA fees.=20 >=20 >=20 > The issue that was mentioned was cloned/frozen VM images that you = could spawn to increase scalability. In that case, you would = prepare/install an image just once, freeze it, and then launch a new one = whenever you need it. Ideally you'd have the plugin installed that first = time only, but then all cloned instances would fall out of the license = agreement, as they'd actually be different machines with the plugin = reinstalled rather than downloaded on the fly. Downloading the plugin = for each new image that is spawned as it unfreezes would be a problem, = as 1) the image wouldn't be ready right away, and 2) any problem in the = download process would make the machine useless with respect to H.264. >=20 > Lorenzo >=20 >=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > --=20 > Lorenzo Miniero, COB >=20 > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com From cowwoc@bbs.darktech.org Tue Nov 26 12:51:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C73C1ADFA9 for ; Tue, 26 Nov 2013 12:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVFGuTHoRErn for ; Tue, 26 Nov 2013 12:51:00 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 240EF1AD942 for ; Tue, 26 Nov 2013 12:51:00 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id tp5so10257853ieb.11 for ; Tue, 26 Nov 2013 12:50:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jGigTTK0hHLy6FrV+xZwGZxK8ALeivjJz67qW+YH6r8=; b=LFExaBPmEpbYE03chcmttYwf1u5f3UpLMLVlkluoama9ijzAHrSCbQWSc0vWl2t2oU A9nLVMcT1iis/mY6Cnq+oCKmL0qdpuXmaSI1FLjCXIJ4AM77IDV5fJ3v7mm97WibNcbC /QQ4eUzXoO4Ic8ma3Sff8ssDe0XSXNi4SXTbBFYUB+5+y0N0iHpWcbP3WnbTooLWZ5IO t3A5QrCa6Tp6Q/9ZrR/5alSDjK95iGlK1pVB8Cua6Y/Me1aftoPmkIt6q5eqpW8kbCSM YsKwm5126su8JhhDpgwykE7coTL5OGDp0nETM8Il+DsFwOIcXwZmCFVc9UC5aFJ9ZXez 9mJA== X-Gm-Message-State: ALoCoQkReIu8kt/z7bQDyV5WalIis20XSoXGc2V/LqR/pQPBTSWq/mzQMJ8zSyH/yLUAM+H9HTMH X-Received: by 10.50.103.6 with SMTP id fs6mr18944026igb.16.1385499059718; Tue, 26 Nov 2013 12:50:59 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f5sm34290334igc.4.2013.11.26.12.50.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 12:50:58 -0800 (PST) Message-ID: <52950992.9050100@bbs.darktech.org> Date: Tue, 26 Nov 2013 15:50:26 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52891EDB.2050607@googlemail.com> <528B2ABE.4040701@googlemail.com> <528C79AD.10608@googlemail.com> <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com> <20131121234706.09a04878@rainpc> <1EB8F765-7FA5-4FA1-A3E8-A2B940335B08@iii.ca> In-Reply-To: <1EB8F765-7FA5-4FA1-A3E8-A2B940335B08@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] cisco binary on ec2 X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 20:51:02 -0000 MPEG-LA is doing a terrible job here. The licensing rules are so poorly understood and enforced that they have a practical impact of companies ignoring them altogether (unless you're huge like Apple or Google). They are wasting our time, and it is costing themselves legitimate royalties. The fact that we are being asked to pay lawyers as an insurance policy (to get a legal opinion on a vague license) is not right. I can understand why the open-source guys are finding this lack of transparency very disturbing. All this is to say: Cisco's proposal is a step in the right direction but there remains a large gap that needs to be filled. I encourage H.264 advocates to work with MPEG-LA to bridge this gap as opposed to pushing this on the rest of us. As discussed with Cullen during the conference, we should be able to come up with "creative" licensing terms that allow us to buy multiple units in bulk and integrating the codec directly into our images. As opposed to manually downloading the codec each time. Similarly, we should get more concrete/official answers from MPEG-LA regarding the various questions that came up, such as what constitutes a "unit". Gili On 26/11/2013 2:32 PM, Cullen Jennings wrote: > I think for a scenario like that you would use a different approach as long as you used less than 100k virtual machines - which is a reasonable assumption for all the cloud services I am aware of. You would take the source code and compile it to form the executables on the master image for the VM. You would then distribute the VM normally and not use the Cisco binary. > > The other case that has come up is a large enterprise that makes a master copy of the image that distributed to all their desktops and it is a case where the company has over 100k desktops. If they own the desktops my understanding is they are the end user from that point of view and as long as the IT department downloaded a copy of the Cisco binary and put it into their master image and then put that master image on computers they own / operate then that can be made to work too. > > This stuff is all sort of subtle but there seems to be a wide range of options that can be made to work and have examples of people already doing it with H264 MPEG LA licenses. > > > On Nov 21, 2013, at 3:47 PM, Lorenzo Miniero wrote: > >> On Thu, 21 Nov 2013 14:33:15 -0800 >> Cullen Jennings wrote: >> >>> On Nov 21, 2013, at 12:21 PM, Matt Fredrickson wrote: >>> >>>> I cannot use that on my dynamically >>>> deployed EC2 instances due to licensing restrictions. :-) >>> >>> My understanding of the legal situation is that you can use the cisco binary on your EC2 instance and have Cisco pay the MPEG-LA fees. >> >> The issue that was mentioned was cloned/frozen VM images that you could spawn to increase scalability. In that case, you would prepare/install an image just once, freeze it, and then launch a new one whenever you need it. Ideally you'd have the plugin installed that first time only, but then all cloned instances would fall out of the license agreement, as they'd actually be different machines with the plugin reinstalled rather than downloaded on the fly. Downloading the plugin for each new image that is spawned as it unfreezes would be a problem, as 1) the image wouldn't be ready right away, and 2) any problem in the download process would make the machine useless with respect to H.264. >> >> Lorenzo >> >> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> -- >> Lorenzo Miniero, COB >> >> Meetecho s.r.l. >> Web Conferencing and Collaboration Tools >> http://www.meetecho.com > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Tue Nov 26 13:17:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22881ADF38 for ; Tue, 26 Nov 2013 13:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh6zFmq43fDt for ; Tue, 26 Nov 2013 13:17:16 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC7C61AD942 for ; Tue, 26 Nov 2013 13:17:15 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id a1so4084892wgh.23 for ; Tue, 26 Nov 2013 13:17:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9vTTX5NF4EzwFXNARUFmtbT4tLwvlGrtY76KKFzop1I=; b=XkcvE8WLK6+1ROpl7dDSeon+u0rXSfYwW90UEXVCioOf0n/8CCJT5hIWfvlHaZIxPZ cmXNiiCdfjxQgotcdbliw7WwrJRdbFtcLn1lq3FziZ7Cckf88IX1j64lkcpapP93lvec g+En6JOLUwV1thPsbAonjK/9KwyTpH67sdJ43LS6265x+Kwcwie9xbAfC7fYAm5IVXJi uDQWw6AO7tqqNibPCV5xEU8GMlFqIPz7CrTTNCYP7Gbh9edSAZKE5aY5BdwujMYft5cl FUq4LYz3dhMSBAQ3OFL9ZPovmv92fKMfKQZet8HsluO03cml2kSCcDRX4ria7AbkwzEZ 9i4w== X-Gm-Message-State: ALoCoQlRUSgHJ1gd4+bIpLnTC+6DJ/RjIOs6d3dY932kPlhj2+y00BeH/JyWyaBnQt14HDtSRaTD X-Received: by 10.180.206.18 with SMTP id lk18mr19922407wic.64.1385500635162; Tue, 26 Nov 2013 13:17:15 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by mx.google.com with ESMTPSA id c10sm63972067wie.11.2013.11.26.13.17.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 13:17:14 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id ca18so5852096wib.16 for ; Tue, 26 Nov 2013 13:17:13 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.198.170 with SMTP id jd10mr19810387wic.65.1385500633564; Tue, 26 Nov 2013 13:17:13 -0800 (PST) Received: by 10.217.88.133 with HTTP; Tue, 26 Nov 2013 13:17:13 -0800 (PST) In-Reply-To: <52950992.9050100@bbs.darktech.org> References: <52891EDB.2050607@googlemail.com> <528B2ABE.4040701@googlemail.com> <528C79AD.10608@googlemail.com> <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com> <20131121234706.09a04878@rainpc> <1EB8F765-7FA5-4FA1-A3E8-A2B940335B08@iii.ca> <52950992.9050100@bbs.darktech.org> Date: Tue, 26 Nov 2013 16:17:13 -0500 Message-ID: From: Roman Shpount To: cowwoc Content-Type: multipart/alternative; boundary=047d7b62509e198ce204ec1b010f Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] cisco binary on ec2 X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 21:17:19 -0000 --047d7b62509e198ce204ec1b010f Content-Type: text/plain; charset=ISO-8859-1 Just a reminder that license from MPEG-LA, even though required, is not sufficient to use H.264 codec. There are other intellectual property holders (such as Nokia) which are not part of MPEG-LA. These property holders are supposed to give you license under RAND terms, but you need to negotiate with them separately. All of this before taking patent trolls into account, which can obviously sue you at any time for any reason. Bottom line, unless you want to spend thousands of dollars and a lot of time negotiating, you cannot license H.264. Your choices are either use H.264 licensed by somebody else, assuming they will be responsible for license fee (like Cisco binary download) or hope that you are small enough not be sued. _____________ Roman Shpount On Tue, Nov 26, 2013 at 3:50 PM, cowwoc wrote: > > MPEG-LA is doing a terrible job here. The licensing rules are so poorly > understood and enforced that they have a practical impact of companies > ignoring them altogether (unless you're huge like Apple or Google). They > are wasting our time, and it is costing themselves legitimate royalties. > > The fact that we are being asked to pay lawyers as an insurance policy (to > get a legal opinion on a vague license) is not right. I can understand why > the open-source guys are finding this lack of transparency very disturbing. > > All this is to say: Cisco's proposal is a step in the right direction but > there remains a large gap that needs to be filled. I encourage H.264 > advocates to work with MPEG-LA to bridge this gap as opposed to pushing > this on the rest of us. > > As discussed with Cullen during the conference, we should be able to come > up with "creative" licensing terms that allow us to buy multiple units in > bulk and integrating the codec directly into our images. As opposed to > manually downloading the codec each time. Similarly, we should get more > concrete/official answers from MPEG-LA regarding the various questions that > came up, such as what constitutes a "unit". > > Gili > > On 26/11/2013 2:32 PM, Cullen Jennings wrote: > >> I think for a scenario like that you would use a different approach as >> long as you used less than 100k virtual machines - which is a reasonable >> assumption for all the cloud services I am aware of. You would take the >> source code and compile it to form the executables on the master image for >> the VM. You would then distribute the VM normally and not use the Cisco >> binary. >> >> The other case that has come up is a large enterprise that makes a master >> copy of the image that distributed to all their desktops and it is a case >> where the company has over 100k desktops. If they own the desktops my >> understanding is they are the end user from that point of view and as long >> as the IT department downloaded a copy of the Cisco binary and put it into >> their master image and then put that master image on computers they own / >> operate then that can be made to work too. >> >> This stuff is all sort of subtle but there seems to be a wide range of >> options that can be made to work and have examples of people already doing >> it with H264 MPEG LA licenses. >> >> >> On Nov 21, 2013, at 3:47 PM, Lorenzo Miniero >> wrote: >> >> On Thu, 21 Nov 2013 14:33:15 -0800 >>> Cullen Jennings wrote: >>> >>> On Nov 21, 2013, at 12:21 PM, Matt Fredrickson >>>> wrote: >>>> >>>> I cannot use that on my dynamically >>>>> deployed EC2 instances due to licensing restrictions. :-) >>>>> >>>> >>>> My understanding of the legal situation is that you can use the cisco >>>> binary on your EC2 instance and have Cisco pay the MPEG-LA fees. >>>> >>> >>> The issue that was mentioned was cloned/frozen VM images that you could >>> spawn to increase scalability. In that case, you would prepare/install an >>> image just once, freeze it, and then launch a new one whenever you need it. >>> Ideally you'd have the plugin installed that first time only, but then all >>> cloned instances would fall out of the license agreement, as they'd >>> actually be different machines with the plugin reinstalled rather than >>> downloaded on the fly. Downloading the plugin for each new image that is >>> spawned as it unfreezes would be a problem, as 1) the image wouldn't be >>> ready right away, and 2) any problem in the download process would make the >>> machine useless with respect to H.264. >>> >>> Lorenzo >>> >>> >>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >>> -- >>> Lorenzo Miniero, COB >>> >>> Meetecho s.r.l. >>> Web Conferencing and Collaboration Tools >>> http://www.meetecho.com >>> >> _______________________________________________ >> 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 > --047d7b62509e198ce204ec1b010f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Just a reminder that license from MPEG-LA, even thoug= h required, is not sufficient to use H.264 codec. There are other intellect= ual property holders (such as Nokia) which are not part of MPEG-LA. These p= roperty holders are supposed to give you license under RAND terms, but you = need to negotiate with them separately. All of this before taking patent tr= olls into account, which can obviously sue you at any time for any reason.<= br>
Bottom line, unless you want to spend thousands of dollars and a = lot of time negotiating, you cannot license H.264. Your choices are either = use H.264 licensed by somebody else, assuming they will be responsible for = license fee (like Cisco binary download) or hope that you are small enough = not be sued.


_____________Roman Shpount


On Tue, Nov 26, 2013 at 3:50 PM, cowwoc = <cowwoc@bbs.darktech.org> wrote:

MPEG-LA is doing a terrible job here. The licensing rules are so poorly und= erstood and enforced that they have a practical impact of companies ignorin= g them altogether (unless you're huge like Apple or Google). They are w= asting our time, and it is costing themselves legitimate royalties.

The fact that we are being asked to pay lawyers as an insurance policy (to = get a legal opinion on a vague license) is not right. I can understand why = the open-source guys are finding this lack of transparency very disturbing.=

All this is to say: Cisco's proposal is a step in the right direction b= ut there remains a large gap that needs to be filled. I encourage H.264 adv= ocates to work with MPEG-LA to bridge this gap as opposed to pushing this o= n the rest of us.

As discussed with Cullen during the conference, we should be able to come u= p with "creative" licensing terms that allow us to buy multiple u= nits in bulk and integrating the codec directly into our images. As opposed= to manually downloading the codec each time. Similarly, we should get more= concrete/official answers from MPEG-LA regarding the various questions tha= t came up, such as what constitutes a "unit".

Gili

On 26/11/2013 2:32 PM, Cullen Jennings wrote:
I think for a scenario like that you would use a different approach as long= as you used less than 100k virtual machines - which is a reasonable assump= tion for all the cloud services I am aware of. You would take the source co= de and compile it to form the executables on the master image for the VM. Y= ou would then distribute the VM normally and not use the Cisco binary.

The other case that has come up is a large enterprise that makes a master c= opy of the image that distributed to all their desktops =A0and it is a case= where the company has over 100k desktops. =A0If they own the desktops my u= nderstanding is they are the end user from that point of view and as long a= s the IT department downloaded a copy of the Cisco binary and put it into t= heir master image and then put that master image on computers they own / op= erate then that can be made to work too.

This stuff is all sort of subtle but there seems to be a wide range of opti= ons that can be made to work and have examples of people already doing it w= ith H264 MPEG LA licenses.


On Nov 21, 2013, at 3:47 PM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:

On Thu, 21 Nov 2013 14:33:15 -0800
Cullen Jennings <fluf= fy@iii.ca> wrote:

On Nov 21, 2013, at 12:21 PM, Matt Fredrickson <creslin@digium.com> wrote:

I cannot use that on my dynamically
deployed EC2 instances due to licensing restrictions. :-)

My understanding of the legal situation is that you can use the cisco binar= y on your EC2 instance and have Cisco pay the MPEG-LA fees.

The issue that was mentioned was cloned/frozen VM images that you could spa= wn to increase scalability. In that case, you would prepare/install an imag= e just once, freeze it, and then launch a new one whenever you need it. Ide= ally you'd have the plugin installed that first time only, but then all= cloned instances would fall out of the license agreement, as they'd ac= tually be different machines with the plugin reinstalled rather than downlo= aded on the fly. Downloading the plugin for each new image that is spawned = as it unfreezes would be a problem, as 1) the image wouldn't be ready r= ight away, and 2) any problem in the download process would make the machin= e useless with respect to H.264.

Lorenzo


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.c= om
_______________________________________________
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

--047d7b62509e198ce204ec1b010f-- From harald@alvestrand.no Tue Nov 26 14:57:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2A71ADE72 for ; Tue, 26 Nov 2013 14:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PWrAMPLZ35R for ; Tue, 26 Nov 2013 14:57:34 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E55651AE021 for ; Tue, 26 Nov 2013 14:57:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3949D39E070; Tue, 26 Nov 2013 23:57:04 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 964PFawskEqW; Tue, 26 Nov 2013 23:57:03 +0100 (CET) Received: from [10.10.3.142] (unknown [148.122.12.30]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D464439E029; Tue, 26 Nov 2013 23:57:02 +0100 (CET) Message-ID: <5295273C.1070602@alvestrand.no> Date: Tue, 26 Nov 2013 23:57:00 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Derek Pang References: <59A91D84-3D29-47C4-8688-CB60844B15D3@cisco.com> <24B2A6DE-958C-445C-BE77-8BD1661DC33D@cisco.com> <52922BA1.6070805@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------020708090901030201020300" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 22:57:39 -0000 This is a multi-part message in MIME format. --------------020708090901030201020300 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 11/26/2013 11:07 PM, Derek Pang wrote: > I am new to rtcweb community. Was there any proposal on making both > Vp8 and H264 decoders MTI in webrtc, but VP8 or H264 encoder to be > optional ? Does this offer a better option for the marketplace, while > allowing interoperability. I appreciate that the amount of reading you have to do in order to catch up with the archives is enormous, but it is definitely a good thing to do at this juncture. This is alternative 12 on http://tools.ietf.org/wg/rtcweb/trac/wiki, where the current alternatives that the chairs are considering proposing a vote to choose between have been listed. > > > On Sun, Nov 24, 2013 at 8:38 AM, Harald Alvestrand > > wrote: > > On 11/23/2013 01:20 AM, Paul Giralt (pgiralt) wrote: > > On Nov 22, 2013, at 7:06 PM, Martin Thomson > > > wrote: > > On 22 November 2013 15:44, Paul Giralt (pgiralt) > > wrote: > > While you’re right that it would work for this > scenario, my point was really > that Offer/Answer is not really asymmetric as implied > earlier. Take for > example the hypothetical case where you are only able > to decode VP8 but only > able to encode H.264. If I offer VP8 as my only codec > (because it’s the only > thing I’m able to decode therefore I never want anyone > to send me anything > other than VP8) I cannot send H.264 in the offer > because that implies I’m > able to decode it. The other side then wants to say it > can only receive > H.264 so it would have to send back an answer with > only H.264. I guess > there’s nothing really inherently stopping you from > doing this because as > far as I can tell, 3264 only says the answer has to be > a subset of the offer > for multicast streams, however how would the answering > side know that the > offering side is even capable to receiving H.264? > Perhaps Offer/Answer can > technically be asymmetric, but it doesn’t seem > practical to use it this way > because you cannot really indicate your send and > receive capabilities > independent of each other. > > Judicious application of a=sendonly or a=recvonly avoids > this issue. > If you want to send H.264, try a=sendonly on a line with > H.264. If > you want to receive VP8, try a=recvonly on a line with VP8. > > I gave this as an example of a possible way to do it, but that > means you need two separate m= lines - one for send and one > for receive. Seems strange to do this for something that you > really want to be a single bi-directional stream. > > > An application that can't talk to itself is kind of bizarre too. > > I think this is a corner case. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Surveillance is pervasive. Go Dark. --------------020708090901030201020300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/26/2013 11:07 PM, Derek Pang wrote:
I am new to rtcweb community. Was there any proposal on making both Vp8 and H264 decoders MTI in webrtc, but VP8 or H264 encoder to be optional ? Does this offer a better option for the marketplace, while allowing interoperability.

I appreciate that the amount of reading you have to do in order to catch up with the archives is enormous, but it is definitely a good thing to do at this juncture.

This is alternative 12 on http://tools.ietf.org/wg/rtcweb/trac/wiki, where the current alternatives that the chairs are considering proposing a vote to choose between have been listed.




On Sun, Nov 24, 2013 at 8:38 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
On 11/23/2013 01:20 AM, Paul Giralt (pgiralt) wrote:
On Nov 22, 2013, at 7:06 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 22 November 2013 15:44, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:
While you’re right that it would work for this scenario, my point was really
that Offer/Answer is not really asymmetric as implied earlier. Take for
example the hypothetical case where you are only able to decode VP8 but only
able to encode H.264. If I offer VP8 as my only codec (because it’s the only
thing I’m able to decode therefore I never want anyone to send me anything
other than VP8) I cannot send H.264 in the offer because that implies I’m
able to decode it. The other side then wants to say it can only receive
H.264 so it would have to send back an answer with only H.264. I guess
there’s nothing really inherently stopping you from doing this because as
far as I can tell, 3264 only says the answer has to be a subset of the offer
for multicast streams, however how would the answering side know that the
offering side is even capable to receiving H.264? Perhaps Offer/Answer can
technically be asymmetric, but it doesn’t seem practical to use it this way
because you cannot really indicate your send and receive capabilities
independent of each other.
Judicious application of a=sendonly or a=recvonly avoids this issue.
If you want to send H.264, try a=sendonly on a line with H.264.  If
you want to receive VP8, try a=recvonly on a line with VP8.
I gave this as an example of a possible way to do it, but that means you need two separate m= lines - one for send and one for receive. Seems strange to do this for something that you really want to be a single bi-directional stream.

An application that can't talk to itself is kind of bizarre too.

I think this is a corner case.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Surveillance is pervasive. Go Dark.
--------------020708090901030201020300-- From cowwoc@bbs.darktech.org Tue Nov 26 15:04:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085911AE037 for ; Tue, 26 Nov 2013 15:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTLYa7wp1cXK for ; Tue, 26 Nov 2013 15:04:03 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5DC1AE038 for ; Tue, 26 Nov 2013 15:04:03 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so10692427iec.13 for ; Tue, 26 Nov 2013 15:04:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ZyMWxjNR1HMedLL0ZzkxI90y5a1juzT02gu4e7HOgxQ=; b=RZkOoBaQpfnQvIjL/E+/5sac66RC8ZGv1FKCPhZsSWKE1sktBLnhNkwMjRXrpraUlA O2msrChtR2puN6dKSk9F4CF5zVRkdXcsKDhU6rimwcJytUMcv+az9Wtg0O1DiLxF1FLu yuJh9hgfAYEFBB9rys4oyVbBJkbDp4W/KPzIfN3aFLOgX3TjBW0qmItP84x8Q/dimiQn FTcrfybc4NRXrpSgiwd0vAfuLUZYF4kXp3ou1vZtE+5AVo3Xo2pFe1iZH5I6nmOEgrqH wMNc4Cgl78v4uK4VgMlDHMgbAtc9XaA2SZYNyH/qQMG+KwCvEiCjOunYZwsdQmGozhM2 TmaA== X-Gm-Message-State: ALoCoQkVeZY0sjm/G60tqCNgZPRaZJqxSPgog/5c4A6XrpNQOT81/fQiPvYw48TkLEYlsfcNawPg X-Received: by 10.50.127.197 with SMTP id ni5mr18930092igb.54.1385507042813; Tue, 26 Nov 2013 15:04:02 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id q6sm34278793igi.0.2013.11.26.15.04.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 15:04:01 -0800 (PST) Message-ID: <529528C0.40200@bbs.darktech.org> Date: Tue, 26 Nov 2013 18:03:28 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Apparently TLS is IPR-encumbered X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 23:04:06 -0000 http://yro.slashdot.org/story/13/11/26/1927254/jury-finds-newegg-infringed-patent-owes-23-million This is meant to be funny, but it just goes to show you the kind of stupid situations that software patents result in. I assume we don't use RC4 ciphers? :) Gili From stephen.farrell@cs.tcd.ie Tue Nov 26 15:15:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A14D1AE04A for ; Tue, 26 Nov 2013 15:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOtJ8Rfr101N for ; Tue, 26 Nov 2013 15:15:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 57ABD1AE054 for ; Tue, 26 Nov 2013 15:15:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BE9BCBE5B; Tue, 26 Nov 2013 23:14:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDDa+E1efpgF; Tue, 26 Nov 2013 23:14:58 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.23.183]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 06B48BE62; Tue, 26 Nov 2013 23:14:58 +0000 (GMT) Message-ID: <52952B71.4090208@cs.tcd.ie> Date: Tue, 26 Nov 2013 23:14:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: cowwoc , "rtcweb@ietf.org" References: <529528C0.40200@bbs.darktech.org> In-Reply-To: <529528C0.40200@bbs.darktech.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Apparently TLS is IPR-encumbered X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 23:15:11 -0000 On 11/26/2013 11:03 PM, cowwoc wrote: > http://yro.slashdot.org/story/13/11/26/1927254/jury-finds-newegg-infringed-patent-owes-23-million > > > This is meant to be funny, but it just goes to show you the kind of > stupid situations that software patents result in. I assume we don't use > RC4 ciphers? :) RC4 is in common use with TLS. For other reasons we're in the process of working on BCPs for more desirable/modern ciphersuites for (D)TLS. This WG could well select some ciphersuites that you like better (or maybe you have, I've not read the drafts recently, sorry). S. > > Gili > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From martin.thomson@gmail.com Tue Nov 26 15:23:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799E71AE05B for ; Tue, 26 Nov 2013 15:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2zu4hO7bFyw for ; Tue, 26 Nov 2013 15:23:01 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D1D171AE04A for ; Tue, 26 Nov 2013 15:23:00 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id p61so5987891wes.20 for ; Tue, 26 Nov 2013 15:22:59 -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=i5qos58nxiGddt8IPcGfSlRbNCAZcdqyXQfqqxfwWJM=; b=shy32aPB9I13idj+US8BMS8MFsM+poGOoxOjkGuUUCM/pAHuiYia6mReiB7jXonCjb OmYbF8XaQ0FbeHdMRYU4zmVriaLbk169G30YSim7WYrpUSDBVcE4gFzZusXPCAzWxN+t KhMHzE/gnz1JcaMeF5a3Xu0YiRhluXvT2DbosyDy5OZ0cP3FaoGYtZRZMEPQnHbzDIvU dgMjdtT4chcJPRIn3hDAJ4qvELgmNXnm8s8WJbqoWwzsHI2ZSPb/p/4C+7FA4TXgifhL bjRZSrQZts1edCzRIf84TpSV0iGvmErj3LR+wfCIUTZLpaDZHhTtXsq9AzzrBI/+RddW 3jTA== MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr20231979wic.64.1385508179794; Tue, 26 Nov 2013 15:22:59 -0800 (PST) Received: by 10.227.134.195 with HTTP; Tue, 26 Nov 2013 15:22:59 -0800 (PST) In-Reply-To: <52952B71.4090208@cs.tcd.ie> References: <529528C0.40200@bbs.darktech.org> <52952B71.4090208@cs.tcd.ie> Date: Tue, 26 Nov 2013 15:22:59 -0800 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Apparently TLS is IPR-encumbered X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 23:23:02 -0000 On 26 November 2013 15:14, Stephen Farrell wrote: > This WG could well select some > ciphersuites that you like better DTLS doesn't use RC4. It's a little tricky dealing with a stream cipher in datagram mode. From stephen.farrell@cs.tcd.ie Tue Nov 26 15:38:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFD51AE04C for ; Tue, 26 Nov 2013 15:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tttW5_8KsQbf for ; Tue, 26 Nov 2013 15:38:30 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EE6201AE045 for ; Tue, 26 Nov 2013 15:38:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D860ABE61; Tue, 26 Nov 2013 23:38:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQGyiuquWaeA; Tue, 26 Nov 2013 23:38:25 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.23.183]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C3F56BE60; Tue, 26 Nov 2013 23:38:25 +0000 (GMT) Message-ID: <529530F1.6040108@cs.tcd.ie> Date: Tue, 26 Nov 2013 23:38:25 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Martin Thomson References: <529528C0.40200@bbs.darktech.org> <52952B71.4090208@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Apparently TLS is IPR-encumbered X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 23:38:32 -0000 On 11/26/2013 11:22 PM, Martin Thomson wrote: > On 26 November 2013 15:14, Stephen Farrell wrote: >> This WG could well select some >> ciphersuites that you like better > > DTLS doesn't use RC4. It's a little tricky dealing with a stream > cipher in datagram mode. Sorry yes, I meant that even if rtcweb don't like the generic BCP stuff that TLS (or UTA) does, for (D)TLS this wg can always pick its own preferred ciphersuites. S. > > From martin.thomson@gmail.com Tue Nov 26 15:44:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16781AE03D for ; Tue, 26 Nov 2013 15:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwSgT2i1oWO6 for ; Tue, 26 Nov 2013 15:44:47 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CCA0F1AE05B for ; Tue, 26 Nov 2013 15:44:46 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id q58so5993989wes.2 for ; Tue, 26 Nov 2013 15:44:46 -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=8WF2LkyJxmeuBYKToIx6nYOQ99U8zI1tXwnwGUr26z0=; b=bbWAEo+dc4+3CI1eQEmiaqxZ+1Ru0RRmcUXwoGszy745uaFOphR/Lec6RfGYkvQGBt pljQg3uTBuqi79dpQwVRrzB3gw1KOt3Ss3z7m33rPnzmDEVmhh6sEBe22wfvs4MeH01r 2t774bNrx21QagSo12JbYVRcp+BbSqrNXNLpFzJrgqvAb+haxbkL8Im3SWCBMTbT3Uko RVzgMAvwfA0at66BHOY7T9KurRmpO0RZxlAaJ06eZ7kXw1FbIryDya+gSXtDY6o7YX95 Rw8KnXQ1i6wNT/B+it7tmV0NblN7Qb/9kkBZ0qUM9293Ashb7Lezx+qcTJgvpEPejD1b za0g== MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr20280549wic.64.1385509486158; Tue, 26 Nov 2013 15:44:46 -0800 (PST) Received: by 10.227.134.195 with HTTP; Tue, 26 Nov 2013 15:44:46 -0800 (PST) In-Reply-To: <529530F1.6040108@cs.tcd.ie> References: <529528C0.40200@bbs.darktech.org> <52952B71.4090208@cs.tcd.ie> <529530F1.6040108@cs.tcd.ie> Date: Tue, 26 Nov 2013 15:44:46 -0800 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Apparently TLS is IPR-encumbered X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 23:44:49 -0000 On 26 November 2013 15:38, Stephen Farrell wrote: > Sorry yes, I meant that even if rtcweb don't like the generic > BCP stuff that TLS (or UTA) does, for (D)TLS this wg can always > pick its own preferred ciphersuites. Definitely. For instance, I'm currently considering the raising of the bar for identity to SHA-256. There's no point in building a new thing on top of SHA-1. First, I'll have to check whether that's at all possible. From dcpang@highfive.com Tue Nov 26 14:07:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C543C1ADF84 for ; Tue, 26 Nov 2013 14:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjqv2nurtkIm for ; Tue, 26 Nov 2013 14:07:54 -0800 (PST) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by ietfa.amsl.com (Postfix) with ESMTP id 29B5B1ADF7A for ; Tue, 26 Nov 2013 14:07:39 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id v10so2866004bkz.35 for ; Tue, 26 Nov 2013 14:07:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sj02IsTrR4hVVnYCx9H53dXpuzmmUrJTo8vQCjRaR3k=; b=GqrqZbWdRaoShKvB+CQmiEr23SmYJiizIX/b2E+Zp53EW2xgtoQAkwyJulkHeRmLJx J/+OILqFjNq8+cYOsKouGMAa8ceqIyWHO7k2CYqYJXEyrcXHwMWCy+vtu6/qWXcMtMeZ uermCu0hQAqvi6IbbjFRI6Y8mdlyr9Vf1c7RCr+PnGQml1fCybMc4TmAJI1Tghk4rD4q y8zm5+qalfOoxa4DMgL3vFPqADRDFRTr+WbSKu7ReJD8wnkUlYNW6/G4LyfU8qrJGUzk Iqe3Ow1Npew+afR0d0jV1yz8BD8mdEM+FloBCs6jckwF2n7zcVpyzO+gKgKXsZXzbEdI 1eeg== X-Gm-Message-State: ALoCoQl+/u6ENyaF5Yb5BrtxPYNVp7GSw0kOBHXwUDL+Jp5OSnm5M+VAskIZd4lTW8gs/a7W0xh+ X-Received: by 10.205.36.81 with SMTP id sz17mr24174720bkb.29.1385503659074; Tue, 26 Nov 2013 14:07:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.162.78 with HTTP; Tue, 26 Nov 2013 14:07:18 -0800 (PST) In-Reply-To: <52922BA1.6070805@alvestrand.no> References: <59A91D84-3D29-47C4-8688-CB60844B15D3@cisco.com> <24B2A6DE-958C-445C-BE77-8BD1661DC33D@cisco.com> <52922BA1.6070805@alvestrand.no> From: Derek Pang Date: Tue, 26 Nov 2013 14:07:18 -0800 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec52c67756f899504ec1bb5d6 X-Mailman-Approved-At: Tue, 26 Nov 2013 16:04:03 -0800 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 22:10:40 -0000 --bcaec52c67756f899504ec1bb5d6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am new to rtcweb community. Was there any proposal on making both Vp8 and H264 decoders MTI in webrtc, but VP8 or H264 encoder to be optional ? Does this offer a better option for the marketplace, while allowing interoperability. On Sun, Nov 24, 2013 at 8:38 AM, Harald Alvestrand wr= ote: > On 11/23/2013 01:20 AM, Paul Giralt (pgiralt) wrote: > >> On Nov 22, 2013, at 7:06 PM, Martin Thomson >> wrote: >> >> On 22 November 2013 15:44, Paul Giralt (pgiralt) >>> wrote: >>> >>>> While you=92re right that it would work for this scenario, my point wa= s >>>> really >>>> that Offer/Answer is not really asymmetric as implied earlier. Take fo= r >>>> example the hypothetical case where you are only able to decode VP8 bu= t >>>> only >>>> able to encode H.264. If I offer VP8 as my only codec (because it=92s = the >>>> only >>>> thing I=92m able to decode therefore I never want anyone to send me >>>> anything >>>> other than VP8) I cannot send H.264 in the offer because that implies >>>> I=92m >>>> able to decode it. The other side then wants to say it can only receiv= e >>>> H.264 so it would have to send back an answer with only H.264. I guess >>>> there=92s nothing really inherently stopping you from doing this becau= se >>>> as >>>> far as I can tell, 3264 only says the answer has to be a subset of the >>>> offer >>>> for multicast streams, however how would the answering side know that >>>> the >>>> offering side is even capable to receiving H.264? Perhaps Offer/Answer >>>> can >>>> technically be asymmetric, but it doesn=92t seem practical to use it t= his >>>> way >>>> because you cannot really indicate your send and receive capabilities >>>> independent of each other. >>>> >>> Judicious application of a=3Dsendonly or a=3Drecvonly avoids this issue= . >>> If you want to send H.264, try a=3Dsendonly on a line with H.264. If >>> you want to receive VP8, try a=3Drecvonly on a line with VP8. >>> >> I gave this as an example of a possible way to do it, but that means you >> need two separate m=3D lines - one for send and one for receive. Seems >> strange to do this for something that you really want to be a single >> bi-directional stream. >> > > An application that can't talk to itself is kind of bizarre too. > > I think this is a corner case. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec52c67756f899504ec1bb5d6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I am new to rtcweb community. Was there any proposal = on making both Vp8 and H264 decoders MTI in webrtc, but VP8 or H264 encoder= to be optional ? Does this offer a better option for the marketplace, whil= e allowing interoperability.=A0


O= n Sun, Nov 24, 2013 at 8:38 AM, Harald Alvestrand <harald@alvestrand.no= > wrote:
On 1= 1/23/2013 01:20 AM, Paul Giralt (pgiralt) wrote:
On Nov 22, 2013, at 7:06 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On 22 November 2013 15:44, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:
While you=92re right that it would work for this scenario, my point was rea= lly
that Offer/Answer is not really asymmetric as implied earlier. Take for
example the hypothetical case where you are only able to decode VP8 but onl= y
able to encode H.264. If I offer VP8 as my only codec (because it=92s the o= nly
thing I=92m able to decode therefore I never want anyone to send me anythin= g
other than VP8) I cannot send H.264 in the offer because that implies I=92m=
able to decode it. The other side then wants to say it can only receive
H.264 so it would have to send back an answer with only H.264. I guess
there=92s nothing really inherently stopping you from doing this because as=
far as I can tell, 3264 only says the answer has to be a subset of the offe= r
for multicast streams, however how would the answering side know that the offering side is even capable to receiving H.264? Perhaps Offer/Answer can<= br> technically be asymmetric, but it doesn=92t seem practical to use it this w= ay
because you cannot really indicate your send and receive capabilities
independent of each other.
Judicious application of a=3Dsendonly or a=3Drecvonly avoids this issue. If you want to send H.264, try a=3Dsendonly on a line with H.264. =A0If
you want to receive VP8, try a=3Drecvonly on a line with VP8.
I gave this as an example of a possible way to do it, but that means you ne= ed two separate m=3D lines - one for send and one for receive. Seems strang= e to do this for something that you really want to be a single bi-direction= al stream.

An application that can't talk to itself is kind of bizarre too.

I think this is a corner case.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec52c67756f899504ec1bb5d6-- From dcpang@highfive.com Tue Nov 26 14:11:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DB11ADF64 for ; Tue, 26 Nov 2013 14:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKzcJM5IML8z for ; Tue, 26 Nov 2013 14:11:17 -0800 (PST) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2E50F1ADF7F for ; Tue, 26 Nov 2013 14:11:17 -0800 (PST) Received: by mail-bk0-f50.google.com with SMTP id e11so2807336bkh.23 for ; Tue, 26 Nov 2013 14:11:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=o8+WIl+H5Ia2IB3V8fSB7SJVBPbNGdfFe90ZfC4o1kw=; b=Ho3smGneBEhIaRp1FSO3awNK6gVu+Ly7ulP6Wy1ns8aAumjOjAh7H9mbSES3eJq+J3 LluLY8Bm7j5T19Ke4FpCO3hSIh71XndOele/61x87vwNVs0eQmFTe70ccfB2iaoG0txZ 64f4Lmo41hZWIG4RAm+ORY7ZZVEkCzE/ZFSphpaENbebz0Bqjn3GcyC4zjmVMqECeKzo os/EG4LBaMfIohWnDh9VaucUEdt7owxGqF+X3AYf7SAAQOoJzlNozoy7fiYIwNQwr+pS 3b7lvHvUksGhomAHLYSOFw3oidkYSdcJZ0RTP/Kn2hjHiss6U14mWMM0fviv5xJDRn6d kglw== X-Gm-Message-State: ALoCoQlWfLhdCXo3nC4dshtTDVAQ3ZlQhcA14IzlpdvEa7Bse17VvzFTcaNEhZCdatbuwHBlGeO1 X-Received: by 10.205.78.131 with SMTP id zm3mr1230264bkb.63.1385503876356; Tue, 26 Nov 2013 14:11:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.162.78 with HTTP; Tue, 26 Nov 2013 14:10:56 -0800 (PST) In-Reply-To: References: <59A91D84-3D29-47C4-8688-CB60844B15D3@cisco.com> <24B2A6DE-958C-445C-BE77-8BD1661DC33D@cisco.com> <52922BA1.6070805@alvestrand.no> From: Derek Pang Date: Tue, 26 Nov 2013 14:10:56 -0800 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=f46d04103ad162fd5f04ec1bc25c X-Mailman-Approved-At: Tue, 26 Nov 2013 16:04:03 -0800 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode X-BeenThere: rtcweb@ietf.org 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: Tue, 26 Nov 2013 22:11:24 -0000 --f46d04103ad162fd5f04ec1bc25c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am new to rtcweb community. Was there any proposal on making both Vp8 and H264 decoders MTI in webrtc, but VP8 or H264 encoder to be optional ? Does this offer a better option for the marketplace, while allowing interoperability. -Derek On Tue, Nov 26, 2013 at 2:07 PM, Derek Pang wrote: > I am new to rtcweb community. Was there any proposal on making both Vp8 > and H264 decoders MTI in webrtc, but VP8 or H264 encoder to be optional ? > Does this offer a better option for the marketplace, while allowing > interoperability. > > > On Sun, Nov 24, 2013 at 8:38 AM, Harald Alvestrand = wrote: > >> On 11/23/2013 01:20 AM, Paul Giralt (pgiralt) wrote: >> >>> On Nov 22, 2013, at 7:06 PM, Martin Thomson >>> wrote: >>> >>> On 22 November 2013 15:44, Paul Giralt (pgiralt) >>>> wrote: >>>> >>>>> While you=92re right that it would work for this scenario, my point w= as >>>>> really >>>>> that Offer/Answer is not really asymmetric as implied earlier. Take f= or >>>>> example the hypothetical case where you are only able to decode VP8 >>>>> but only >>>>> able to encode H.264. If I offer VP8 as my only codec (because it=92s >>>>> the only >>>>> thing I=92m able to decode therefore I never want anyone to send me >>>>> anything >>>>> other than VP8) I cannot send H.264 in the offer because that implies >>>>> I=92m >>>>> able to decode it. The other side then wants to say it can only recei= ve >>>>> H.264 so it would have to send back an answer with only H.264. I gues= s >>>>> there=92s nothing really inherently stopping you from doing this beca= use >>>>> as >>>>> far as I can tell, 3264 only says the answer has to be a subset of th= e >>>>> offer >>>>> for multicast streams, however how would the answering side know that >>>>> the >>>>> offering side is even capable to receiving H.264? Perhaps Offer/Answe= r >>>>> can >>>>> technically be asymmetric, but it doesn=92t seem practical to use it >>>>> this way >>>>> because you cannot really indicate your send and receive capabilities >>>>> independent of each other. >>>>> >>>> Judicious application of a=3Dsendonly or a=3Drecvonly avoids this issu= e. >>>> If you want to send H.264, try a=3Dsendonly on a line with H.264. If >>>> you want to receive VP8, try a=3Drecvonly on a line with VP8. >>>> >>> I gave this as an example of a possible way to do it, but that means yo= u >>> need two separate m=3D lines - one for send and one for receive. Seems >>> strange to do this for something that you really want to be a single >>> bi-directional stream. >>> >> >> An application that can't talk to itself is kind of bizarre too. >> >> I think this is a corner case. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --f46d04103ad162fd5f04ec1bc25c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I am new to rtcweb community. Was there any proposal on m= aking both Vp8 and H264 decoders MTI in webrtc, but VP8 or H264 encoder to = be optional ? Does this offer a better option for the marketplace, while al= lowing interoperability.=A0

-Derek


On Tue, Nov 26, 2013 at 2:07 PM, Derek P= ang <dcpang@highfive.com> wrote:
I am new to rtcweb community. Was there any proposal = on making both Vp8 and H264 decoders MTI in webrtc, but VP8 or H264 encoder= to be optional ? Does this offer a better option for the marketplace, whil= e allowing interoperability.=A0


On Sun, Nov 24, 2013 at 8:38 AM, Har= ald Alvestrand <harald@alvestrand.no> wrote:
On 11/23/2013 01:20 AM, Paul Giral= t (pgiralt) wrote:
On Nov 22, 2013, at 7:06 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On 22 November 2013 15:44, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:
While you=92re right that it would work for this scenario, my point was rea= lly
that Offer/Answer is not really asymmetric as implied earlier. Take for
example the hypothetical case where you are only able to decode VP8 but onl= y
able to encode H.264. If I offer VP8 as my only codec (because it=92s the o= nly
thing I=92m able to decode therefore I never want anyone to send me anythin= g
other than VP8) I cannot send H.264 in the offer because that implies I=92m=
able to decode it. The other side then wants to say it can only receive
H.264 so it would have to send back an answer with only H.264. I guess
there=92s nothing really inherently stopping you from doing this because as=
far as I can tell, 3264 only says the answer has to be a subset of the offe= r
for multicast streams, however how would the answering side know that the offering side is even capable to receiving H.264? Perhaps Offer/Answer can<= br> technically be asymmetric, but it doesn=92t seem practical to use it this w= ay
because you cannot really indicate your send and receive capabilities
independent of each other.
Judicious application of a=3Dsendonly or a=3Drecvonly avoids this issue. If you want to send H.264, try a=3Dsendonly on a line with H.264. =A0If
you want to receive VP8, try a=3Drecvonly on a line with VP8.
I gave this as an example of a possible way to do it, but that means you ne= ed two separate m=3D lines - one for send and one for receive. Seems strang= e to do this for something that you really want to be a single bi-direction= al stream.

An application that can't talk to itself is kind of bizarre too.

I think this is a corner case.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


--f46d04103ad162fd5f04ec1bc25c-- From mperumal@cisco.com Tue Nov 26 18:06:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C251AE051 for ; Tue, 26 Nov 2013 18:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7IrOLlMnY1S for ; Tue, 26 Nov 2013 18:06:48 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD9B1AE061 for ; Tue, 26 Nov 2013 18:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2613; q=dns/txt; s=iport; t=1385518003; x=1386727603; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3NB0I2CTXAN52EWuqnwQ+iXRN/caDTCFe/ll83Ifksc=; b=Uqzte8gVIhkrJX2xzgvyB8fP+Y9Lm9uREgxuonoO8lPWlfKuM3+F+smL 7Ielg5QyeiixSLee6kUXuW6bQ2tLzb2D0akc1xZWad73ov+fbcaOnm/xq f514+6NR51q+wVrz7AFEZXENbOp594L2Xik0PynHqfWOGvSLIBzp3E9Tw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAMdSlVKtJXHB/2dsb2JhbABZgwc4U7o2ToEnFnSCJQEBAQQBAQE3NAsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQiHeQ2/URMEjksxBwaDGoETA6ongyiCKg X-IronPort-AV: E=Sophos;i="4.93,779,1378857600"; d="scan'208";a="287759423" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 27 Nov 2013 02:06:43 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAR26hhR015402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 02:06:43 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 20:06:42 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Martin Thomson , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 Thread-Index: AQHO6tMq3kHRuwrIQkmVqlzIxQ7eZJo4UCJA Date: Wed, 27 Nov 2013 02:06:41 +0000 Message-ID: References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.69.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 02:06:50 -0000 Are there cases where you won't do ICE but do DTLS, for WebRTC? If not, I t= hink you can combine the best of both: - The initial consent is established by ICE connectivity checks already. - The receipt of any authenticated packet, including DTLS heartbeat, grants= =20 you consent to send more packets. - If you doesn't receive any packet and consent is about to expire, send a= =20 STUN binding request that is comparatively less CPU intensive. Minimal overhead overall :) Muthu |-----Original Message----- |From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson |Sent: Tuesday, November 26, 2013 11:43 PM |To: Tirumaleswar Reddy (tireddy) |Cc: draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org; rtcweb@ietf.o= rg |Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshnes= s-00 | |These are good observations. | |On 26 November 2013 02:34, Tirumaleswar Reddy (tireddy) | wrote: |> [1] and [2] can be solved by mandating WebRTC endpoints to support conse= nt. | |Yes, that would be the plan. We would also have to force the |inclusion of peer_allowed_to_send(1) in the extension, lest things get |perverse. | |> [3] DTLS heartbeat seems to be more CPU intensive than STUN consent (Gen= erating arbitrary content |(payload and padding 40 bytes), encrypting it). Though this may not a conc= ern since heartbeat will |only be sent when authenticated packets are not received. | |I'm thinking: a) not a concern because it's only a factor if you |aren't sending, and b) not a concern because it's not a lot of work to |generate an authenticated packet. Less work I think if you are using |AES-GCM modes. | |> [4] DTLS heartbeat doubles the timer value at each retransmission but wi= th STUN consent |retransmission is repeated every 500ms. There seems to be no application l= evel control on the |retransmission mechanism used by OpenSSL DTLS implementation. | |That's a good point, I'll have to check to see if we need to update |6520, or whether just saying to avoid retransmission is sufficient. |(I think the latter, but don't care too much.) | |> [5] With STUN consent, browser can find the RTT time which is not possib= le with OpenSSL DTLS |heartbeat API. | |This is true to exactly the same extent for both forms. Some STUN |implementations don't allow for the sending of a single check, they |also do the full exponential backoff thing. |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Tue Nov 26 19:30:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E29B1AE0FE for ; Tue, 26 Nov 2013 19:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAccSFNV-ApD for ; Tue, 26 Nov 2013 19:30:46 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 54BE91AE0D8 for ; Tue, 26 Nov 2013 19:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1430; q=dns/txt; s=iport; t=1385523046; x=1386732646; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=snaFk9y6K/bkZ1ZHyayu+nNuhC3fvhwqp6xLrQv8kgg=; b=A5lotetc8eXwU9eoLFfdhcjeNYdQF7VCGPqASAuP/QakC4EjONS4xfR8 BwJR1Euu/0CwDZhERFBqQZOYM4lvhXo2J16ZtMD7ZTavnKeMmg88V7sYu MSe6SoEmkolarpkDqoxmaLYGKcbSOV3CvYUUw/N5/Sr3LXULJdU6DLBWH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFALdmlVKtJV2d/2dsb2JhbABZgweBC7sGgSYWdIIlAQEBAwF5BQsCAQgYLjIlAgQOBYd7Br9iF45JMweDIIETA5gUkhODKIIq X-IronPort-AV: E=Sophos;i="4.93,779,1378857600"; d="scan'208";a="287808253" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 27 Nov 2013 03:30:46 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAR3UjiM002436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 03:30:45 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 21:30:45 -0600 From: "Cullen Jennings (fluffy)" To: Adam Roach Thread-Topic: [rtcweb] H.261 Thread-Index: AQHO6yEOI3eaXh/hPUO/BFD+9F35bg== Date: Wed, 27 Nov 2013 03:30:44 +0000 Message-ID: <097CFAA6-32B7-4541-9C4A-FF8F034EC194@cisco.com> References: <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBD13.5040801@gmail.com> <528FD429.7090002@nostrum.com> <528FDE5E.5080301@librevideo.org> <20131123003548.GD3245@audi.shelbyville.oz> <529006BB.609@nostrum.com> In-Reply-To: <529006BB.609@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 03:30:48 -0000 On Nov 22, 2013, at 6:36 PM, Adam Roach wrote: > On 11/22/13 18:35, Ron wrote: >> The whole point of many distros is to supply binaries, often built >> many times for many different system architectures. >=20 > And the overwhelming majority of these do so by including a list of repos= itories from which the binaries can be downloaded. >=20 > I'm 100% confident that we could convince Cisco to serve up RPMs, DPKGs, = and whatever else is needed for these distros, targeting whatever platforms= are required. Now, whether we can get the distro maintainers to add a sing= le line to their list of repos -- because that's all it would take -- is a = different issue. But at that point, it's just a matter of the distro mainta= iners being intransigent rather than any real technical or legal barrier. +1 adam and to add a bit more =85 and also at the same time making sure the= source is available so people can compute their own signatures and verify = the binary matches the open source and the open source does not contain any= malware.=20 For distributions that distribute source like debian, they can just keep do= ing what they are doing now in distributing the source. They can distribute= openh264 or x264 or both depending on what is needed and what licenses the= y like. For the same reason they can currently distribute x264, they can di= stribute the BSD source. From fluffy@cisco.com Tue Nov 26 19:30:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDC81AE105 for ; Tue, 26 Nov 2013 19:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.502 X-Spam-Level: X-Spam-Status: No, score=-109.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKBXEh4Uc5S5 for ; Tue, 26 Nov 2013 19:30:56 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 7B87A1AE104 for ; Tue, 26 Nov 2013 19:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3671; q=dns/txt; s=iport; t=1385523056; x=1386732656; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Wpmzd1zHsu2zZWBWn70iEh91Z4ufwhJWdtuOzFlsu2A=; b=d6w8JRWkKIcF3qLNn5ZBVofZJC2tjgxRNI2nqlncd8p1Lfx7oiQAMmMm kqQixX/yBU3hCz54vzYRmq+w1M5zQjBX9t6gs0mauLJgLH6hdwVFXATCM IN551oWSngfONfQypNZeqRX0zalRtFJpUqSVcfaCb03cql3dxt2B9EZzl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAIxmlVKtJV2d/2dsb2JhbABZgwc4U7o4ToEmFnSCJQEBAQMBAQEBNxsZBgUFBwQCAQgRBAEBAR4JByEGCxQJCAIEDgUJD4dXAwkGDbc8DYgMF4xcEIFdMwcGgxqBEwOWKYFrgTCLKoU5gyiCKg X-IronPort-AV: E=Sophos;i="4.93,779,1378857600"; d="scan'208";a="2543654" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 27 Nov 2013 03:30:55 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAR3UtjU002612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 03:30:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 21:30:55 -0600 From: "Cullen Jennings (fluffy)" To: Basil Mohamed Gohar Thread-Topic: [rtcweb] H.261 Thread-Index: AQHO6yEUk7F2h8ervECMuCGHC18NQw== Date: Wed, 27 Nov 2013 03:30:55 +0000 Message-ID: <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> In-Reply-To: <528FBC43.5000409@librevideo.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 03:30:59 -0000 When I go to http://www.librevideo.org, the top headline is "Google Chrome = dropping support for H.264, will support only open web codecs in the future= " which seem, ah, a little out of date. I think the http://www.librevideo.o= rg/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/= article is also a bit confused about the current state of MPEG LA license = terms for 264 AVC pool. I do get they MPEG LA terms can be confusing at tim= es but lots of people have figured it out. If people have questions about s= pecific use case I'm glad to try and get them answers.=20 On Nov 22, 2013, at 1:19 PM, Basil Mohamed Gohar wrote: > Stefan, >=20 > I am not trying to be condescending or put down your comments, but > actually, a lot of what you are bringing up now has been discussed on > this list earlier, and we still arrived where we're at. >=20 > The Cisco offer, if and when it actual reaches fruition, solves some but > not all problems with using H.264 as an MTI codec. It definitely widens > the audience that can use H.264 in some cases, but there are definitely > use cases it does not cover, because H.264 *itself* is not licensed in a > way that is usable. I'd like to point you to this posting [1] I made > years ago after a long interview process with a representative from > MPEG-LA, which reaches some interesting conclusions. >=20 > [1] > http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-= about-avch-264-licensing/ >=20 > On 11/22/2013 03:11 PM, Stefan Slivinski wrote: >> As I'm sure everyone in this group is aware, Cisco has provided an open = source implementation of H.264 and they will cover the patent licensing fee= s. Seems like this would be a good option for the little guys worried abou= t dealing with the mpeg-la >>=20 >> -----Original Message----- >> From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]=20 >> Sent: Friday, November 22, 2013 11:59 AM >> To: Stefan Slivinski; Maik Merten; rtcweb@ietf.org >> Subject: Re: [rtcweb] H.261 >>=20 >>=20 >> On 11/22/13 8:30 PM, Stefan Slivinski wrote: >>> No, this is taking things to extremes. This codec hasn't been used in = any industry for 15 years. The entire video conferencing industry uses H.2= 64, the broadcast industry uses H.264, the streaming video industry uses H.= 264, facetime, skype both use H.264. The list goes on and on. There is no= t a single company is existence today using H.261 over H.264 because of pat= ent fears. It is asinine that this is even being discussed. >>=20 >> You misunderstood the issue. h264 has already an incompatible licensing = policy for many situations, especially towards open source. Not using >> h264 is not about fears of new patents, but because of the conditions im= posed by exiting patents. >>=20 >> The vp8 vs h261 is actually the case when today none of them has a known= /final incompatible license, but of course, the future is not known. Agains= t vp8 there are some claims, but none with a final decision in court (some = already dismissed in early stages). >>=20 >> Daniel >>=20 >> -- >> Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/m= iconda - http://www.linkedin.com/in/miconda >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 > --=20 > Libre Video > http://librevideo.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cowwoc@bbs.darktech.org Tue Nov 26 19:41:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DFF1AE0D8 for ; Tue, 26 Nov 2013 19:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZcErh4Xek0r for ; Tue, 26 Nov 2013 19:41:37 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8A31AE0AB for ; Tue, 26 Nov 2013 19:41:37 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so10930345ieb.36 for ; Tue, 26 Nov 2013 19:41:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=a6LX9qprV1eN1bfQSzCMxow+Uaas5NVeDumBu8BXUd0=; b=mtxiOT1wjyCWoEemrvN+jieePia5Blxdq/AhlUhCq++xjajA0lmNJ9013ULX3kemi1 fjJbSWCcJWKakvfVNzInDLvhore7zFHfeZ74PbDyIXUH8pusgZU0Xqgju0d9RgZi0piu WZszjkiHh74+pDGSIzrmGLPvKYDjZGgdsxlYLW5ferNgD4L+WIDTTVpW0rAEI7LS3crw rXbw6T+EznCK05INW4Pwt9sOpoaUSFXrOkkCS+t/5aw2UW7EMPLKgHORSBKwf7CJTfbg XZwy+1a9dvZNrLQsbPdZGH9ZDIGEV4nW4SXTIopJjam9Z+E2J2kmCd8/kB2R24sq2ZSt w0mg== X-Gm-Message-State: ALoCoQncu5EvumKrsIyJVrVqYH/hgbw74ShOWxJIMSmI8LqL+jM/QQbTl+VIl5MbdApW8JWHCKGg X-Received: by 10.42.177.10 with SMTP id bg10mr23379970icb.18.1385523696865; Tue, 26 Nov 2013 19:41:36 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id j16sm35726696igf.6.2013.11.26.19.41.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 19:41:35 -0800 (PST) Message-ID: <529569C1.5010909@bbs.darktech.org> Date: Tue, 26 Nov 2013 22:40:49 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> In-Reply-To: <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> Content-Type: multipart/alternative; boundary="------------030006080300010604000503" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 03:41:50 -0000 This is a multi-part message in MIME format. --------------030006080300010604000503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 26/11/2013 10:30 PM, Cullen Jennings (fluffy) wrote: > When I go to http://www.librevideo.org, the top headline is "Google Chrome dropping support for H.264, will support only open web codecs in the future" which seem, ah, a little out of date. I think the http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/ article is also a bit confused about the current state of MPEG LA license terms for 264 AVC pool. I do get they MPEG LA terms can be confusing at times but lots of people have figured it out. If people have questions about specific use case I'm glad to try and get them answers. Sure: 1. If I recall correctly, someone asked for a more concrete definition of a licensing "unit". 2. On a related note, if my application is downloaded once but installed 5 times by the same end-user, how many units is that? 3. I asked for the ability to license multiple units at a time so we deploy images and applications without a separate plugin/download process. Thanks, Gili --------------030006080300010604000503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 26/11/2013 10:30 PM, Cullen Jennings (fluffy) wrote:
When I go to http://www.librevideo.org, the top headline is "Google Chrome dropping support for H.264, will support only open web codecs in the future" which seem, ah, a little out of date. I think the http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/ article is also a bit confused about the current state of MPEG LA license terms for 264 AVC pool. I do get they MPEG LA terms can be confusing at times but lots of people have figured it out. If people have questions about specific use case I'm glad to try and get them answers.

Sure:

  1. If I recall correctly, someone asked for a more concrete definition of a licensing "unit".
  2. On a related note, if my application is downloaded once but installed 5 times by the same end-user, how many units is that?
  3. I asked for the ability to license multiple units at a time so we deploy images and applications without a separate plugin/download process.
Thanks,
Gili
--------------030006080300010604000503-- From stewe@stewe.org Tue Nov 26 20:41:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265EF1AE0F3 for ; Tue, 26 Nov 2013 20:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kf0Fiuq7sSff for ; Tue, 26 Nov 2013 20:40:57 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id DD0351AE049 for ; Tue, 26 Nov 2013 20:40:57 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 27 Nov 2013 04:40:55 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.113]) with mapi id 15.00.0820.005; Wed, 27 Nov 2013 04:40:54 +0000 From: Stephan Wenger To: cowwoc , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Apparently TLS is IPR-encumbered Thread-Index: AQHO6vvT7nzh8UuRk0C4/8DcwC0WhZo3+ZWA Date: Wed, 27 Nov 2013 04:40:52 +0000 Message-ID: References: <529528C0.40200@bbs.darktech.org> In-Reply-To: <529528C0.40200@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.99] x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(51704005)(199002)(189002)(74366001)(36756003)(81816001)(87936001)(51856001)(2656002)(50986001)(81542001)(76482001)(85306002)(54356001)(81342001)(53806001)(56816003)(81686001)(46102001)(76786001)(76796001)(15395725003)(15975445006)(56776001)(80976001)(83072001)(15202345003)(74706001)(74876001)(4396001)(77982001)(19580405001)(59766001)(83322001)(19580395003)(65816001)(80022001)(66066001)(63696002)(79102001)(49866001)(74662001)(69226001)(47976001)(87266001)(54316002)(74502001)(31966008)(47736001)(77096001)(47446002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:50.174.124.99; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] Apparently TLS is IPR-encumbered X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 04:41:00 -0000 If you are interested in this case and in high-powered, successful trolls, I recommend this article: http://arstechnica.com/tech-policy/2013/11/newegg-on-trial-mystery-company- tqp-re-writes-the-history-of-encryption/ There are also a number of blog posts in IP professional blogs, but those are full of jargon. A few data points for those with no or only little time to read: -Spangenberg is perhaps the most successful troll on the planet. -the industry at large has paid many millions in royalties for this patent already. For example, MS paid $1M, and Amazon $0.5M -the patent reportedly expired in mid 2012. Which does not necessarily mean that you cannot be sued for past infringement (that timeframe will only be up around 2018). Stephan On 11.26.2013, 15:03 , "cowwoc" wrote: >http://yro.slashdot.org/story/13/11/26/1927254/jury-finds-newegg-infringed >-patent-owes-23-million > >This is meant to be funny, but it just goes to show you the kind of >stupid situations that software patents result in. I assume we don't use >RC4 ciphers? :) > >Gili >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From stewe@stewe.org Tue Nov 26 21:07:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5241A1F62 for ; Tue, 26 Nov 2013 21:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn_JLpq_kBoP for ; Tue, 26 Nov 2013 21:07:25 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id D50A21AE124 for ; Tue, 26 Nov 2013 21:07:24 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 27 Nov 2013 05:07:16 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.113]) with mapi id 15.00.0820.005; Wed, 27 Nov 2013 05:07:15 +0000 From: Stephan Wenger To: cowwoc , "rtcweb@ietf.org" Thread-Topic: [rtcweb] H.261 Thread-Index: AQHO50Itstn9eh6B8EejB0XcQHHKMpoxfO0AgAADjQCAAAzFgIAABU2AgAAKLQCAAAdiAIAACBKAgAADOgCAAAJPgIAGwe6AgAACxID//5IBgA== Date: Wed, 27 Nov 2013 05:07:13 +0000 Message-ID: References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> In-Reply-To: <529569C1.5010909@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.99] x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(164054003)(199002)(189002)(479174003)(377454003)(24454002)(19580395003)(80022001)(65816001)(77982001)(4396001)(59766001)(19580405001)(16601075003)(83322001)(49866001)(74662001)(66066001)(79102001)(63696002)(80976001)(83072001)(74706001)(74876001)(15202345003)(74502001)(47446002)(31966008)(77096001)(47736001)(69226001)(47976001)(87266001)(54316002)(2656002)(51856001)(87936001)(74366001)(16236675002)(36756003)(81816001)(76786001)(46102001)(76796001)(53806001)(56816003)(81686001)(56776001)(15975445006)(85306002)(81342001)(54356001)(76482001)(81542001)(50986001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:50.174.124.99; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CEBABA4FAAF51stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 05:07:30 -0000 --_000_CEBABA4FAAF51stewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Inline below, with the caveat that I do not represent MPEG-LA; I'm only a g= uy who works for a company that is both an MPEG-LA licensee and licensor, a= nd therefore have some very limited insight in their thinking process. Stephan From: cowwoc > Date: Tuesday, 26 November, 2013 at 19:40 To: "rtcweb@ietf.org" > Subject: Re: [rtcweb] H.261 On 26/11/2013 10:30 PM, Cullen Jennings (fluffy) wrote: When I go to http://www.librevideo.org, the top headline is "Google Chrome = dropping support for H.264, will support only open web codecs in the future= " which seem, ah, a little out of date. I think the http://www.librevideo.o= rg/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/= article is also a bit confused about the current state of MPEG LA license = terms for 264 AVC pool. I do get they MPEG LA terms can be confusing at tim= es but lots of people have figured it out. If people have questions about s= pecific use case I'm glad to try and get them answers. Sure: 1. If I recall correctly, someone asked for a more concrete definition o= f a licensing "unit". StW: I do not recall the context, but MPEG-LA licenses (in addition to cont= ent, which is not at issue here) a thing called "codec", which is defined a= s one encoder, one decoder, or one encoder and one decoder. /StW 2. On a related note, if my application is downloaded once but installed 5 = times by the same end-user, how many units is that? StW: I believe the correct answer would be 5. However, there is a provisio= n that allows you to distribute "disabled" copies of a "codec", and in that= case the license fee only becomes due upon the enabling of the copy, for e= xample at the first use. People use this in conjunction with software acti= vation mechanisms. /StW 3. I asked for the ability to license multiple units at a time so we deploy= images and applications without a separate plugin/download process. StW: if this is related to MPEG-LA (and not to the Cisco download mechanism= ) the answer is simple. You, as an MPEG-LA sublicensee, are responsible fo= r the correct accounting of the number of codecs you "sell" (where "sell" i= ncludes things like free download etc.). MPEG-LA has the right to audit yo= u, and if they do and you are found cheating, then there are provisions fo= r penalties. /StW Thanks, Gili --_000_CEBABA4FAAF51stewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <84C807128767DB43A0639C9A8A4DD2E1@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Inline below, with the caveat that I do not represent MPEG-LA; I’= ;m only a guy who works for a company that is both an MPEG-LA licensee and = licensor, and therefore have some very limited insight in their thinking pr= ocess.
Stephan

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Tuesday, 26 November, 2013 at= 19:40
To: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: Re: [rtcweb] H.261

On 26/11/2013 10:30 PM, Cullen Jennings (flu= ffy) wrote:
When I go to http://www.librevideo.org, the top headline is &=
quot;Google Chrome dropping support for H.264, will support only open web c=
odecs in the future" which seem, ah, a little out of date. I think the=
 http:/=
/www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-av=
ch-264-licensing/ article is also a bit confused about the current stat=
e of MPEG LA license terms for 264 AVC pool. I do get they MPEG LA terms ca=
n be confusing at times but lots of people have figured it out. If people h=
ave questions about specific use case I'm glad to try and get them answers.=
=20

Sure:

  1. If I recall correctly, someone asked for a more concrete definition of = a licensing "unit".
StW: I do not recall the context, but MPEG-LA licenses (in addition to= content, which is not at issue here) a thing called “codec”, w= hich is defined as one encoder, one decoder, or one encoder and one decoder= . /StW


2.&nbs= p;On a related note, if my application is downloaded once but installed 5 t= imes by the same end-user, how many units is that?

StW: I believe the correct answer would be 5.  However, there is = a provision that allows you to distribute “disabled” copies of = a “codec”, and in that case the license fee only becomes due up= on the enabling of the copy, for example at the first use.  People use this in conjunction with software activation mechanisms.  /StW

3.&nbs= p;I asked for the ability to license multiple units at a time so we deploy = images and applications without a separate plugin/download process.

StW: if this is related to MPEG-LA (and not to the Cisco download mech= anism) the answer is simple.  You, as an MPEG-LA sublicensee, are resp= onsible for the correct accounting of the number of codecs you “sell&= #8221; (where “sell” includes things like free download etc.).  MPEG-LA has the right to audit you, and if they do  and = you are found cheating, then there are provisions for penalties. /StW

Thanks,
Gili
 --_000_CEBABA4FAAF51stewesteweorg_-- From cowwoc@bbs.darktech.org Tue Nov 26 21:27:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EAA1AE12D for ; Tue, 26 Nov 2013 21:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfJDyOOWStNa for ; Tue, 26 Nov 2013 21:27:24 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id C2EFD1ABD2A for ; Tue, 26 Nov 2013 21:27:24 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so11042169iec.33 for ; Tue, 26 Nov 2013 21:27:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=cWeZahV8RX8kQhKJB/HDJPBSCcAKXWnvpbgPrbyyzd8=; b=ZvcbwtpeeDvhVje0STtnV6zb74HXQ5BFZnGEkXU6h/aUQjWTkW6PQUHmyfUKtJ+tTe TJEIlzz+qIZjqJ6XsfEu2FFBoiVIqwX9FcrqxqKEQKyxXk5Tc0gRvucjHqydkmICtZhQ 7qzFCrHaaVOPyzXOLW+sUotK4ZghgAV/aUcJpPaSJkk2EXRgY8zaieIuMGQ2jqPlM5VH DiNKMvIg628ICVazdf/F/Xhnyco0fkAlNaJMp1OYe69Pq6hJNsNyRV7gB6+O2WBOmrcs WnMO/ObMAV1ky0oOsZGBFnR/SQVbjP1ZoLI3L1MEt1t3vAyQE3CJ7rhrui7bzXh17kdH m9FA== X-Gm-Message-State: ALoCoQl3Nzi5c4LO6/eFgRAUfDCa7a/5SqXuoryX9ciQOtCrKjAM7SveDtXVjqRduUIr1UN1Xy5K X-Received: by 10.50.29.43 with SMTP id g11mr20340492igh.25.1385530041311; Tue, 26 Nov 2013 21:27:21 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p14sm36216185igr.7.2013.11.26.21.27.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 21:27:20 -0800 (PST) Message-ID: <5295828A.4050506@bbs.darktech.org> Date: Wed, 27 Nov 2013 00:26:34 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stephan Wenger , "rtcweb@ietf.org" References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000205080601000103020808" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 05:27:27 -0000 This is a multi-part message in MIME format. --------------000205080601000103020808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 27/11/2013 12:07 AM, Stephan Wenger wrote: > If I recall correctly, someone asked for a more concrete definition of > a licensing "unit". > StW: I do not recall the context, but MPEG-LA licenses (in addition to > content, which is not at issue here) a thing called "codec", which is > defined as one encoder, one decoder, or one encoder and one decoder. /StW I don't think that answers the question. It was my understanding they were asking what constitutes one unit (out of the 100k free units we are allowed per year). For example, should we be counting the number of installs? Or number of concurrent users (e.g. what happens when a user installs the software on 5 machines but only runs one at a time?)? Or number of downloads? What happens if the same user downloads the app 100 times? When users uninstall the app, do we get a unit back? The point is, we need a very concrete definition of how to count units. > > 2. On a related note, if my application is downloaded once but > installed 5 times by the same end-user, how many units is that? > > StW: I believe the correct answer would be 5. However, there is a > provision that allows you to distribute "disabled" copies of a > "codec", and in that case the license fee only becomes due upon the > enabling of the copy, for example at the first use. People use this > in conjunction with software activation mechanisms. /StW (Folded into the above question) > > 3. I asked for the ability to license multiple units at a time so we > deploy images and applications without a separate plugin/download > process. > > StW: if this is related to MPEG-LA (and not to the Cisco download > mechanism) the answer is simple. You, as an MPEG-LA sublicensee, are > responsible for the correct accounting of the number of codecs you > "sell" (where "sell" includes things like free download etc.). > MPEG-LA has the right to audit you, and if they do and you are found > cheating, then there are provisions for penalties. /StW Good point. I guess I am asking about Cisco's mechanism, since it is the one that we will be bound by. I guess this would be much simpler if Cisco hit the licensing upper limit, because then we wouldn't need to keep on counting. Gili --------------000205080601000103020808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 27/11/2013 12:07 AM, Stephan Wenger wrote:
If I recall correctly, someone asked for a more concrete definition of a licensing "unit".
StW: I do not recall the context, but MPEG-LA licenses (in addition to content, which is not at issue here) a thing called “codec”, which is defined as one encoder, one decoder, or one encoder and one decoder. /StW

I don't think that answers the question. It was my understanding they were asking what constitutes one unit (out of the 100k free units we are allowed per year). For example, should we be counting the number of installs? Or number of concurrent users (e.g. what happens when a user installs the software on 5 machines but only runs one at a time?)? Or number of downloads? What happens if the same user downloads the app 100 times? When users uninstall the app, do we get a unit back? The point is, we need a very concrete definition of how to count units.


2. On a related note, if my application is downloaded once but installed 5 times by the same end-user, how many units is that?

StW: I believe the correct answer would be 5.  However, there is a provision that allows you to distribute “disabled” copies of a “codec”, and in that case the license fee only becomes due upon the enabling of the copy, for example at the first use.  People use this in conjunction with software activation mechanisms.  /StW

(Folded into the above question)


3. I asked for the ability to license multiple units at a time so we deploy images and applications without a separate plugin/download process.

StW: if this is related to MPEG-LA (and not to the Cisco download mechanism) the answer is simple.  You, as an MPEG-LA sublicensee, are responsible for the correct accounting of the number of codecs you “sell” (where “sell” includes things like free download etc.).  MPEG-LA has the right to audit you, and if they do  and you are found cheating, then there are provisions for penalties. /StW

Good point. I guess I am asking about Cisco's mechanism, since it is the one that we will be bound by. I guess this would be much simpler if Cisco hit the licensing upper limit, because then we wouldn't need to keep on counting.

Gili
--------------000205080601000103020808-- From adam@nostrum.com Tue Nov 26 21:53:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839CC1AE13F for ; Tue, 26 Nov 2013 21:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh8WT1br-Ykh for ; Tue, 26 Nov 2013 21:53:32 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 484021AE134 for ; Tue, 26 Nov 2013 21:53:31 -0800 (PST) Received: from [192.168.0.191] (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAR5rPEL015979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Nov 2013 23:53:26 -0600 (CST) (envelope-from adam@nostrum.com) References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> Mime-Version: 1.0 (1.0) In-Reply-To: <5295828A.4050506@bbs.darktech.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3132244A-FCB5-4C1F-86F1-E0897C47BCDA@nostrum.com> X-Mailer: iPhone Mail (10B350) From: Adam Roach Date: Tue, 26 Nov 2013 23:53:20 -0600 To: cowwoc Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 05:53:35 -0000 On Nov 26, 2013, at 23:26, cowwoc wrote: > I guess I am asking about Cisco's mechanism, since it is the one that we w= ill be bound by. I guess this would be much simpler if Cisco hit the licensi= ng upper limit, because then we wouldn't need to keep on counting. If you use Cisco's binary, you don't have to count. Cisco takes care if that= for you. As far as I understand, they are paying the cap, but that fact doe= sn't make any difference to you one way or another. The important thing is t= hat Cisco is distributing the codec, and Cisco is bearing the costs for maki= ng sure that anything it distributes is properly licensed.=20 /a= From rishi@turtleyogi.com Tue Nov 26 22:39:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D7D1AE166 for ; Tue, 26 Nov 2013 22:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osw1xxTMCGyx for ; Tue, 26 Nov 2013 22:39:10 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7071AE119 for ; Tue, 26 Nov 2013 22:39:10 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id e14so11470824iej.0 for ; Tue, 26 Nov 2013 22:39:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M7w2UZZbAio//84P0dug+wjA0yN/muw7+oIPYDYSJic=; b=lzXX076T33U7RaGQFb+RogzI9lbNvSSvhAZ6+etDYHeAF3bTfLi1T4oPPl6z7GHO1O N0+lZpayTjt/OTTV2pfLnVJJS35VBGW3mF69uuU4+3IfQnFUebHwPOyDgZWXjBQEaUzf wLj8/vqg/jz2SpS+wpPCJiMLNBWX1Wn+PAc+MNGCH7aJj87ETb0J0PT6kub/YSefblpI oyM99DZkhRv9L1i2Sa/vPiQ2ZH9Odt+RKYC4mCqjTmlhqVVJVAZvMuKFBFxvWq7Znl30 khdGEWpHk443jj+ztRAU8g36AxntstLqqQL7tMMVa86bZsmskd4YQzStZKZiOi29X7uz yekA== X-Gm-Message-State: ALoCoQnQz/IdfCvS82zf9NTwIfZTqfU/kkeB7PCnHl89AbUh2uAIzKVPZS6QTwLO2UVo3zB5oQuV MIME-Version: 1.0 X-Received: by 10.42.40.83 with SMTP id k19mr22240776ice.3.1385534349759; Tue, 26 Nov 2013 22:39:09 -0800 (PST) Received: by 10.64.229.68 with HTTP; Tue, 26 Nov 2013 22:39:09 -0800 (PST) X-Originating-IP: [115.113.11.220] In-Reply-To: References: Date: Wed, 27 Nov 2013 12:09:09 +0530 Message-ID: From: Hrishikesh Kulkarni To: Justin Uberti Content-Type: multipart/alternative; boundary=90e6ba1efbf4be160504ec22da00 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 06:39:15 -0000 --90e6ba1efbf4be160504ec22da00 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Nov 22, 2013 at 10:23 PM, Justin Uberti wrote: > For 1:many with MCU, I don't understand why you wouldn't do #2, i.e. > transcode. As stated earlier, the bandwidth costs of using an inefficient > codec (which any MCU service will incur) exceed the CPU cost of transcode= . > Good point on bandwidth costs. But you need to transcode if the decoding endpoints/browsers dont support the codec or the bitrate of the source. This applies to audio and video. If the source video is 720p@800kbps which could then "transrated" into multiple bitrates at 500kbps or downsized to 480p@300kbps. We did this for audio when Chrome was on isac and Firefox was on opus. > > > On Fri, Nov 22, 2013 at 4:47 AM, wrote: > >> Lots of uses will be 1:1 calls, and maybe 30% fallback applies in this >> case. My use of WebRTC involves 1:many group calls in the browser with = an >> MCU. For 1:many, the options are 1) fallback to common codec and 2) >> transcode. So, for 1:many we can say that the chance of using the fallb= ack >> codec is 100%. Assuming IE and Safari actually ship WebRTC. >> >> >> >> On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann wrote: >> >>> >>> Mo, >>> >>> I think we all agree that choosing H.264 or VP8 would be better, but it >>> is clear that neither option today has consensus. Circumstances coul= d >>> change in the future, but it seems that OpenH264 was not enough to chan= ge >>> that circumstance. >>> >>> I think that where your scenario might go astray is that users won=92t >>> associate their poor experience with =93WebRTC=94, or =93that web stuff= =94 =97 they >>> will associate it with the brand of the service which they are using at= the >>> time. >>> >>> So, for example, if Facebook builds video chat using WebRTC, and they d= o >>> no transcoding, 30% of users might associate their poor video with >>> Facebook, but most of them won=92t call it =93that web shit=94 =97 they= would say >>> Facebook video sucks. >>> >>> Of course, Facebook could decide to transcode 30% of the time, in which >>> case the user would have a different experience. >>> >>> Facebook obviously just being used as an example service which might >>> implement WebRTC video. >>> >>> -SteveK >>> >>> >>> >>> From: "Mo Zanaty (mzanaty)" >>> Date: Thursday, November 21, 2013 at 9:17 PM >>> To: Basil Mohamed Gohar >>> Cc: "rtcweb@ietf.org" >>> Subject: [rtcweb] H.261 >>> >>> On 11/21/13 12:48, Basil Mohamed Gohar >>> wrote: >>> >>> Has anyone actually objected to H.261 being the one MTI codec [...] ? >>> >>> >>> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does >>> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. Accordin= g to >>> various (incredibly extrapolated, possibly inaccurate and sometimes >>> conflicting) sources [1] on who uses what browser, the chance of H.261 >>> fallback is a whopping 30% [2]. Not the minor insignificant case some h= ad >>> assumed. >>> >>> How will these users react to H.261 QCIF/CIF compared to what they use >>> today, say Skype for example? "This web shit really sucks. I=92m going = back >>> to Skype and never trying it again." Is that the first (and perhaps las= t) >>> impression we want from users that try webrtc? Those arguing crappy vid= eo >>> is better than no video are ignoring the critical importance of first >>> impressions. While some may accept crappy video as usable, many more ma= y be >>> permanently turned off and tune out even faster than if they got only >>> (good) audio. It=92s not as if webrtc is the only game in town. Users h= ave >>> options, so it needs to be competitive with competitive technology whic= h >>> has already set the bar. >>> >>> We previously narrowed the options down to H.264 and VP8 for good >>> reasons over the course of this excruciatingly long decision. Reopening >>> discarded tangents like H.261 does not move us forward as a workgroup, = and >>> certainly does not move webrtc forward as a technology. >>> >>> Mo >>> >>> [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers >>> [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x = (IE% >>> + Safari%) >>> >>> _______________________________________________ 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 > > --90e6ba1efbf4be160504ec22da00 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 22, 2013 at 10:23 PM, Justin Uberti <juberti@google.com>= wrote:
For 1:many with MCU, I don't understa= nd why you wouldn't do #2, i.e. transcode. As stated earlier, the bandw= idth costs of using an inefficient codec (which any MCU service will incur)= exceed the CPU cost of transcode.

Good point on bandwidth costs. But yo= u need to transcode if the decoding endpoints/browsers dont support the cod= ec or the bitrate of the source. This applies to audio and video. If the so= urce video is 720p@800kbps which could then "transrated" into mul= tiple bitrates at 500kbps or downsized to 480p@300kbps. We did this for aud= io when Chrome was on isac and Firefox was on opus.
=A0


On Fri, Nov 2= 2, 2013 at 4:47 AM, <bryandonnovan@gmail.com> wrote:<= br>
Lots of uses will be 1:1 calls, and maybe 30% fallback app= lies in this case. =A0My use of WebRTC involves 1:many group calls in the b= rowser with an MCU. =A0For 1:many, the options are 1) fallback to common co= dec and 2) transcode. =A0So, for 1:many we can say that the chance of using= the fallback codec is 100%. =A0Assuming IE and Safari actually ship WebRTC= . =A0



On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann <stevek@stevek.c= om> wrote:

Mo,

I think we all agree that choosing H.264 or VP8 would b= e better, but it is clear that neither option today has consensus. =A0 =A0C= ircumstances could change in the future, but it seems that OpenH264 was not= enough to change that circumstance.

I think that where your scenario might go astray is tha= t users won=92t associate their poor experience with =93WebRTC=94, or =93th= at web stuff=94 =97 they will associate it with the brand of the service wh= ich they are using at the time.

So, for example, if Facebook builds video chat using We= bRTC, and they do no transcoding, 30% of users might associate their poor v= ideo with Facebook, but most of them won=92t call it =93that web shit=94 = =97 they would say Facebook video sucks.

Of course, Facebook could decide to transcode 30% of th= e time, in which case the user would have a different experience.

Facebook obviously just being used as an example service wh= ich might implement WebRTC video.

-SteveK



From: "Mo Zanaty (mzanaty)&qu= ot; <mzanaty@cisc= o.com>
Date: Thursday, N= ovember 21, 2013 at 9:17 PM
To: Basil Mohamed Gohar <basilgohar@librevi= deo.org>
Cc: "rtcweb@ietf.org" &= lt;rtcweb@ietf.org= >
Subject: [rtcweb] H.261
<= div>
On 11/21/13 12:48, Basil Mohamed Gohar <basilgohar@librevideo.org> wrote= :
Has anyone actually objected to H.261 being the one MTI codec [...] ?<= /div>

Assume this wins and all obey. Chrome= does H.261+VP8, Firefox does H.261+H.264+VP8, IE does H.261+H.264, Safari = does H.261+H.264. According to various (incredibly extrapolated, possibly i= naccurate and sometimes conflicting) sources [1] on who uses what browser, the chance of H.261 fallback is a whopping 30% [2]. Not the minor= insignificant case some had assumed.

How will the= se users react to H.261 QCIF/CIF compared to what they use today, say Skype= for example? "This web shit really sucks. I=92m going back to Skype a= nd never trying it again." Is that the first (and perhaps last) impres= sion we want from users that try webrtc? Those arguing crappy video is better than no video are ignorin= g the critical importance of first impressions. While some may accept crapp= y video as usable, many more may be permanently turned off and tune out eve= n faster than if they got only (good) audio. It=92s not as if webrtc is the only game in town. Users have option= s, so it needs to be competitive with competitive technology which has alre= ady set the bar.

We previously narrowed the option= s down to H.264 and VP8 for good reasons over the course of this excruciati= ngly long decision. Reopening discarded tangents like H.261 does not move u= s forward as a workgroup, and certainly does not move webrtc forward as a technology.

Mo

[2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x= (IE% + Safari%)


_______________________________________________
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


--90e6ba1efbf4be160504ec22da00-- From lgeyser@gmail.com Tue Nov 26 22:55:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896661AE22C for ; Tue, 26 Nov 2013 22:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqUAOOfx7sZN for ; Tue, 26 Nov 2013 22:55:28 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDA11AE213 for ; Tue, 26 Nov 2013 22:55:27 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ec20so4987834lab.15 for ; Tue, 26 Nov 2013 22:55:26 -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=xjdG31BuFCsRgiahK+J2BhKTqQcM3lrlp5U9si2cCBE=; b=wIBvXr+3ZQC52B3Ft+RBO/WcAvwJmlgcnUR5euBk69ioXd/w/v22tihRlTViMYor72 JtKSAwh5KveLJhIFeC1kvHOpaOri1rNbjvvEyZpcchzvwPOz+L0NkaNSrVoHiC48pjvC M0naGcqrxMKQ0LhFPLLqirvkLlhbu32+a88oAXR64GtEKbzh7MHWqKJZqOd/lno9cMY5 xUg93uoyv5FDYLW6jy4CUKaCGfXIeCShxtmA+yyjo66x7Km0C0NGvde0zuaD58oWAqvt M5uA6e1uhRBY5u+6NH0nZz7hQolfR0Yl7DheFWGFLGjPIK7ut5WIwosBYl2m1LDfxlvF eiSw== MIME-Version: 1.0 X-Received: by 10.152.88.8 with SMTP id bc8mr102878lab.47.1385535326904; Tue, 26 Nov 2013 22:55:26 -0800 (PST) Received: by 10.114.168.70 with HTTP; Tue, 26 Nov 2013 22:55:26 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Nov 2013 08:55:26 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a11c35664fbe41404ec2314d3 Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 06:55:32 -0000 --001a11c35664fbe41404ec2314d3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Why not just run the codec at the same bitrates that the other codecs would of been using anyway? That wouldn't increase the costs of bandwidth. On 27 November 2013 08:39, Hrishikesh Kulkarni wrote= : > On Fri, Nov 22, 2013 at 10:23 PM, Justin Uberti wrote= : > >> For 1:many with MCU, I don't understand why you wouldn't do #2, i.e. >> transcode. As stated earlier, the bandwidth costs of using an inefficien= t >> codec (which any MCU service will incur) exceed the CPU cost of transcod= e. >> > > Good point on bandwidth costs. But you need to transcode if the decoding > endpoints/browsers dont support the codec or the bitrate of the source. > This applies to audio and video. If the source video is 720p@800kbpswhich= could then "transrated" into multiple bitrates at 500kbps or > downsized to 480p@300kbps. We did this for audio when Chrome was on isac > and Firefox was on opus. > > >> >> >> On Fri, Nov 22, 2013 at 4:47 AM, wrote: >> >>> Lots of uses will be 1:1 calls, and maybe 30% fallback applies in this >>> case. My use of WebRTC involves 1:many group calls in the browser with= an >>> MCU. For 1:many, the options are 1) fallback to common codec and 2) >>> transcode. So, for 1:many we can say that the chance of using the fall= back >>> codec is 100%. Assuming IE and Safari actually ship WebRTC. >>> >>> >>> >>> On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann wrote: >>> >>>> >>>> Mo, >>>> >>>> I think we all agree that choosing H.264 or VP8 would be better, but i= t >>>> is clear that neither option today has consensus. Circumstances cou= ld >>>> change in the future, but it seems that OpenH264 was not enough to cha= nge >>>> that circumstance. >>>> >>>> I think that where your scenario might go astray is that users won=92t >>>> associate their poor experience with =93WebRTC=94, or =93that web stuf= f=94 =97 they >>>> will associate it with the brand of the service which they are using a= t the >>>> time. >>>> >>>> So, for example, if Facebook builds video chat using WebRTC, and they >>>> do no transcoding, 30% of users might associate their poor video with >>>> Facebook, but most of them won=92t call it =93that web shit=94 =97 the= y would say >>>> Facebook video sucks. >>>> >>>> Of course, Facebook could decide to transcode 30% of the time, in whic= h >>>> case the user would have a different experience. >>>> >>>> Facebook obviously just being used as an example service which might >>>> implement WebRTC video. >>>> >>>> -SteveK >>>> >>>> >>>> >>>> From: "Mo Zanaty (mzanaty)" >>>> Date: Thursday, November 21, 2013 at 9:17 PM >>>> To: Basil Mohamed Gohar >>>> Cc: "rtcweb@ietf.org" >>>> Subject: [rtcweb] H.261 >>>> >>>> On 11/21/13 12:48, Basil Mohamed Gohar >>>> wrote: >>>> >>>> Has anyone actually objected to H.261 being the one MTI codec [...] ? >>>> >>>> >>>> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does >>>> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. Accordi= ng to >>>> various (incredibly extrapolated, possibly inaccurate and sometimes >>>> conflicting) sources [1] on who uses what browser, the chance of H.261 >>>> fallback is a whopping 30% [2]. Not the minor insignificant case some = had >>>> assumed. >>>> >>>> How will these users react to H.261 QCIF/CIF compared to what they use >>>> today, say Skype for example? "This web shit really sucks. I=92m going= back >>>> to Skype and never trying it again." Is that the first (and perhaps la= st) >>>> impression we want from users that try webrtc? Those arguing crappy vi= deo >>>> is better than no video are ignoring the critical importance of first >>>> impressions. While some may accept crappy video as usable, many more m= ay be >>>> permanently turned off and tune out even faster than if they got only >>>> (good) audio. It=92s not as if webrtc is the only game in town. Users = have >>>> options, so it needs to be competitive with competitive technology whi= ch >>>> has already set the bar. >>>> >>>> We previously narrowed the options down to H.264 and VP8 for good >>>> reasons over the course of this excruciatingly long decision. Reopenin= g >>>> discarded tangents like H.261 does not move us forward as a workgroup,= and >>>> certainly does not move webrtc forward as a technology. >>>> >>>> Mo >>>> >>>> [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers >>>> [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x= (IE% >>>> + Safari%) >>>> >>>> _______________________________________________ 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 >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c35664fbe41404ec2314d3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Why not just run the codec at the same bitrates that the o= ther codecs would of been using anyway? That wouldn't increase the cost= s of bandwidth.


On 27 November 2013 08:39, Hrishikesh Kulkarni <rishi@turtleyogi.com> wrote:
On Fri, Nov 22, 2013 at 10:23 PM, Justin Uberti <juberti@go= ogle.com> wrote:
For 1:many with MCU, I don't understa= nd why you wouldn't do #2, i.e. transcode. As stated earlier, the bandw= idth costs of using an inefficient codec (which any MCU service will incur)= exceed the CPU cost of transcode.

Good point on bandwidth costs. = But you need to transcode if the decoding endpoints/browsers dont support t= he codec or the bitrate of the source. This applies to audio and video. If = the source video is 720p@800kbps which could then "transrated" in= to multiple bitrates at 500kbps or downsized to 480p@300kbps. We did this f= or audio when Chrome was on isac and Firefox was on opus.
=A0


On Fri, Nov 2= 2, 2013 at 4:47 AM, <bryandonnovan@gmail.com> wrote:<= br>
Lots of uses will be 1:1 calls, and maybe 30% fallback app= lies in this case. =A0My use of WebRTC involves 1:many group calls in the b= rowser with an MCU. =A0For 1:many, the options are 1) fallback to common co= dec and 2) transcode. =A0So, for 1:many we can say that the chance of using= the fallback codec is 100%. =A0Assuming IE and Safari actually ship WebRTC= . =A0



On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann <stevek@stevek.c= om> wrote:

Mo,

I think we all agree that choosing H.264 or VP8 would b= e better, but it is clear that neither option today has consensus. =A0 =A0C= ircumstances could change in the future, but it seems that OpenH264 was not= enough to change that circumstance.

I think that where your scenario might go astray is tha= t users won=92t associate their poor experience with =93WebRTC=94, or =93th= at web stuff=94 =97 they will associate it with the brand of the service wh= ich they are using at the time.

So, for example, if Facebook builds video chat using We= bRTC, and they do no transcoding, 30% of users might associate their poor v= ideo with Facebook, but most of them won=92t call it =93that web shit=94 = =97 they would say Facebook video sucks.

Of course, Facebook could decide to transcode 30% of th= e time, in which case the user would have a different experience.

Facebook obviously just being used as an example service wh= ich might implement WebRTC video.

-SteveK



From: "Mo Zanaty (mzanaty)&qu= ot; <mzanaty@cisc= o.com>
Date: Thursday, N= ovember 21, 2013 at 9:17 PM
To: Basil Mohamed Gohar <basilgohar@librevi= deo.org>
Cc: "rtcweb@ietf.org" &= lt;rtcweb@ietf.org= >
Subject: [rtcweb] H.261
<= div>
On 11/21/13 12:48, Basil Mohamed Gohar <basilgohar@librevideo.org> wrote= :
Has anyone actually objected to H.261 being the one MTI codec [...] ?<= /div>

Assume this wins and all obey. Chrome= does H.261+VP8, Firefox does H.261+H.264+VP8, IE does H.261+H.264, Safari = does H.261+H.264. According to various (incredibly extrapolated, possibly i= naccurate and sometimes conflicting) sources [1] on who uses what browser, the chance of H.261 fallback is a whopping 30% [2]. Not the minor= insignificant case some had assumed.

How will the= se users react to H.261 QCIF/CIF compared to what they use today, say Skype= for example? "This web shit really sucks. I=92m going back to Skype a= nd never trying it again." Is that the first (and perhaps last) impres= sion we want from users that try webrtc? Those arguing crappy video is better than no video are ignorin= g the critical importance of first impressions. While some may accept crapp= y video as usable, many more may be permanently turned off and tune out eve= n faster than if they got only (good) audio. It=92s not as if webrtc is the only game in town. Users have option= s, so it needs to be competitive with competitive technology which has alre= ady set the bar.

We previously narrowed the option= s down to H.264 and VP8 for good reasons over the course of this excruciati= ngly long decision. Reopening discarded tangents like H.261 does not move u= s forward as a workgroup, and certainly does not move webrtc forward as a technology.

Mo

[2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x= (IE% + Safari%)


_______________________________________________
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


--001a11c35664fbe41404ec2314d3-- From rishi@turtleyogi.com Tue Nov 26 23:26:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A781AE159 for ; Tue, 26 Nov 2013 23:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wpt06FaQ734S for ; Tue, 26 Nov 2013 23:26:53 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA921AE115 for ; Tue, 26 Nov 2013 23:26:53 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so10882915ief.6 for ; Tue, 26 Nov 2013 23:26:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rH0sMFQdQx2zcmcJ5/pAeNzh4J2R0bAity3B1Yq0qTM=; b=Ya0OvsqHbu81RHw3iBXidGtHnWBxOGLI4kEwiAYCFsrbwY7lwmXOOWuC05EMw0wxsZ PIut/Ng0k79SfVmNizNW/rIeeKBQb7wdaTmUINs2/aXPAtB/kJQPM/akLcXG2fDkaI5M p90TLQJ4qm+8P8p6+ZS5bCO2LY4aLSud4TE76Y1jj2rEkB/COjLNs/bMKVzz+QwraxPQ za+wqvpr+wb4ygKEN6PSrIoagTtzIX5DdBQoPWY+DuXqfb9iuMJxeS6hRW4ggkBP5hFM OYvDH3Pq7EdCucsyGhy/9v1yw4Uhnm41pLYj2OhvVE1fKOjSXiRPcmJ9s6RAXvob4fLZ N7Lw== X-Gm-Message-State: ALoCoQkrzyYvv2bm+hOir5Ry0UEDldF5Brx1WBAxhObItOv2XoIMXtpSLD9+I5I2XyrJrSYE5dKT MIME-Version: 1.0 X-Received: by 10.42.82.196 with SMTP id e4mr4273603icl.58.1385537213233; Tue, 26 Nov 2013 23:26:53 -0800 (PST) Received: by 10.64.229.68 with HTTP; Tue, 26 Nov 2013 23:26:53 -0800 (PST) X-Originating-IP: [14.139.157.28] In-Reply-To: References: Date: Wed, 27 Nov 2013 12:56:53 +0530 Message-ID: From: Hrishikesh Kulkarni To: Leon Geyser Content-Type: multipart/alternative; boundary=20cf30363fa16b134004ec23850d Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 07:26:56 -0000 --20cf30363fa16b134004ec23850d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In that case the source endpoint/browser needs the bandwidth/compute to produce many encode streams (different codecs/bitrate). I would rather the MCU handle the transcoding/transrating. On Wed, Nov 27, 2013 at 12:25 PM, Leon Geyser wrote: > Why not just run the codec at the same bitrates that the other codecs > would of been using anyway? That wouldn't increase the costs of bandwidth= . > > > On 27 November 2013 08:39, Hrishikesh Kulkarni wrot= e: > >> On Fri, Nov 22, 2013 at 10:23 PM, Justin Uberti wrot= e: >> >>> For 1:many with MCU, I don't understand why you wouldn't do #2, i.e. >>> transcode. As stated earlier, the bandwidth costs of using an inefficie= nt >>> codec (which any MCU service will incur) exceed the CPU cost of transco= de. >>> >> >> Good point on bandwidth costs. But you need to transcode if the decoding >> endpoints/browsers dont support the codec or the bitrate of the source. >> This applies to audio and video. If the source video is 720p@800kbpswhic= h could then "transrated" into multiple bitrates at 500kbps or >> downsized to 480p@300kbps. We did this for audio when Chrome was on isac >> and Firefox was on opus. >> >> >>> >>> >>> On Fri, Nov 22, 2013 at 4:47 AM, wrote: >>> >>>> Lots of uses will be 1:1 calls, and maybe 30% fallback applies in this >>>> case. My use of WebRTC involves 1:many group calls in the browser wit= h an >>>> MCU. For 1:many, the options are 1) fallback to common codec and 2) >>>> transcode. So, for 1:many we can say that the chance of using the fal= lback >>>> codec is 100%. Assuming IE and Safari actually ship WebRTC. >>>> >>>> >>>> >>>> On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann wrote= : >>>> >>>>> >>>>> Mo, >>>>> >>>>> I think we all agree that choosing H.264 or VP8 would be better, but >>>>> it is clear that neither option today has consensus. Circumstances= could >>>>> change in the future, but it seems that OpenH264 was not enough to ch= ange >>>>> that circumstance. >>>>> >>>>> I think that where your scenario might go astray is that users won=92= t >>>>> associate their poor experience with =93WebRTC=94, or =93that web stu= ff=94 =97 they >>>>> will associate it with the brand of the service which they are using = at the >>>>> time. >>>>> >>>>> So, for example, if Facebook builds video chat using WebRTC, and they >>>>> do no transcoding, 30% of users might associate their poor video with >>>>> Facebook, but most of them won=92t call it =93that web shit=94 =97 th= ey would say >>>>> Facebook video sucks. >>>>> >>>>> Of course, Facebook could decide to transcode 30% of the time, in >>>>> which case the user would have a different experience. >>>>> >>>>> Facebook obviously just being used as an example service which might >>>>> implement WebRTC video. >>>>> >>>>> -SteveK >>>>> >>>>> >>>>> >>>>> From: "Mo Zanaty (mzanaty)" >>>>> Date: Thursday, November 21, 2013 at 9:17 PM >>>>> To: Basil Mohamed Gohar >>>>> Cc: "rtcweb@ietf.org" >>>>> Subject: [rtcweb] H.261 >>>>> >>>>> On 11/21/13 12:48, Basil Mohamed Gohar >>>>> wrote: >>>>> >>>>> Has anyone actually objected to H.261 being the one MTI codec [...] ? >>>>> >>>>> >>>>> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does >>>>> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. Accord= ing to >>>>> various (incredibly extrapolated, possibly inaccurate and sometimes >>>>> conflicting) sources [1] on who uses what browser, the chance of H.26= 1 >>>>> fallback is a whopping 30% [2]. Not the minor insignificant case some= had >>>>> assumed. >>>>> >>>>> How will these users react to H.261 QCIF/CIF compared to what they us= e >>>>> today, say Skype for example? "This web shit really sucks. I=92m goin= g back >>>>> to Skype and never trying it again." Is that the first (and perhaps l= ast) >>>>> impression we want from users that try webrtc? Those arguing crappy v= ideo >>>>> is better than no video are ignoring the critical importance of first >>>>> impressions. While some may accept crappy video as usable, many more = may be >>>>> permanently turned off and tune out even faster than if they got only >>>>> (good) audio. It=92s not as if webrtc is the only game in town. Users= have >>>>> options, so it needs to be competitive with competitive technology wh= ich >>>>> has already set the bar. >>>>> >>>>> We previously narrowed the options down to H.264 and VP8 for good >>>>> reasons over the course of this excruciatingly long decision. Reopeni= ng >>>>> discarded tangents like H.261 does not move us forward as a workgroup= , and >>>>> certainly does not move webrtc forward as a technology. >>>>> >>>>> Mo >>>>> >>>>> [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers >>>>> [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% = x >>>>> (IE% + Safari%) >>>>> >>>>> _______________________________________________ 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 >>> >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --20cf30363fa16b134004ec23850d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
In that case the source endpoint/browser needs the bandwid= th/compute to produce many encode streams (different codecs/bitrate). I wou= ld rather the MCU handle the transcoding/transrating.



On Wed, Nov 2= 7, 2013 at 12:25 PM, Leon Geyser <lgeyser@gmail.com> wrote:<= br>
Why not just run the codec at the same bitrates that the o= ther codecs would of been using anyway? That wouldn't increase the cost= s of bandwidth.


On 27 November 2013 08:39, Hrishikesh Kulkarni <rishi@turtleyogi.com> wrote:
On Fri, Nov 22, 2013 at 10:23 PM, Justin Uberti <juberti@google.com&= gt; wrote:
For 1:many with MCU, I don't understa= nd why you wouldn't do #2, i.e. transcode. As stated earlier, the bandw= idth costs of using an inefficient codec (which any MCU service will incur)= exceed the CPU cost of transcode.

Good point on bandwidth costs. = But you need to transcode if the decoding endpoints/browsers dont support t= he codec or the bitrate of the source. This applies to audio and video. If = the source video is 720p@800kbps which could then "transrated" in= to multiple bitrates at 500kbps or downsized to 480p@300kbps. We did this f= or audio when Chrome was on isac and Firefox was on opus.
=A0


On Fri, Nov 2= 2, 2013 at 4:47 AM, <bryandonnovan@gmail.com> wrote:<= br>
Lots of uses will be 1:1 calls, and maybe 30% fallback app= lies in this case. =A0My use of WebRTC involves 1:many group calls in the b= rowser with an MCU. =A0For 1:many, the options are 1) fallback to common co= dec and 2) transcode. =A0So, for 1:many we can say that the chance of using= the fallback codec is 100%. =A0Assuming IE and Safari actually ship WebRTC= . =A0



On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann <stevek@stevek.c= om> wrote:

Mo,

I think we all agree that choosing H.264 or VP8 would b= e better, but it is clear that neither option today has consensus. =A0 =A0C= ircumstances could change in the future, but it seems that OpenH264 was not= enough to change that circumstance.

I think that where your scenario might go astray is tha= t users won=92t associate their poor experience with =93WebRTC=94, or =93th= at web stuff=94 =97 they will associate it with the brand of the service wh= ich they are using at the time.

So, for example, if Facebook builds video chat using We= bRTC, and they do no transcoding, 30% of users might associate their poor v= ideo with Facebook, but most of them won=92t call it =93that web shit=94 = =97 they would say Facebook video sucks.

Of course, Facebook could decide to transcode 30% of th= e time, in which case the user would have a different experience.

Facebook obviously just being used as an example service wh= ich might implement WebRTC video.

-SteveK



From: "Mo Zanaty (mzanaty)&qu= ot; <mzanaty@cisc= o.com>
Date: Thursday, N= ovember 21, 2013 at 9:17 PM
To: Basil Mohamed Gohar <basilgohar@librevi= deo.org>
Cc: "rtcweb@ietf.org" &= lt;rtcweb@ietf.org= >
Subject: [rtcweb] H.261
<= div>
On 11/21/13 12:48, Basil Mohamed Gohar <basilgohar@librevideo.org> wrote= :
Has anyone actually objected to H.261 being the one MTI codec [...] ?<= /div>

Assume this wins and all obey. Chrome= does H.261+VP8, Firefox does H.261+H.264+VP8, IE does H.261+H.264, Safari = does H.261+H.264. According to various (incredibly extrapolated, possibly i= naccurate and sometimes conflicting) sources [1] on who uses what browser, the chance of H.261 fallback is a whopping 30% [2]. Not the minor= insignificant case some had assumed.

How will the= se users react to H.261 QCIF/CIF compared to what they use today, say Skype= for example? "This web shit really sucks. I=92m going back to Skype a= nd never trying it again." Is that the first (and perhaps last) impres= sion we want from users that try webrtc? Those arguing crappy video is better than no video are ignorin= g the critical importance of first impressions. While some may accept crapp= y video as usable, many more may be permanently turned off and tune out eve= n faster than if they got only (good) audio. It=92s not as if webrtc is the only game in town. Users have option= s, so it needs to be competitive with competitive technology which has alre= ady set the bar.

We previously narrowed the option= s down to H.264 and VP8 for good reasons over the course of this excruciati= ngly long decision. Reopening discarded tangents like H.261 does not move u= s forward as a workgroup, and certainly does not move webrtc forward as a technology.

Mo

[2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x= (IE% + Safari%)


_______________________________________________
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



--20cf30363fa16b134004ec23850d-- From christer.holmberg@ericsson.com Tue Nov 26 23:38:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62C51AE23A for ; Tue, 26 Nov 2013 23:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLJ_ON_mnPRp for ; Tue, 26 Nov 2013 23:38:55 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id AA1BD1AE22C for ; Tue, 26 Nov 2013 23:38:54 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-54-5295a18dc4d1 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 41.34.22496.D81A5925; Wed, 27 Nov 2013 08:38:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Wed, 27 Nov 2013 08:38:52 +0100 From: Christer Holmberg To: Martin Thomson , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 Thread-Index: AQHO6tMo2ZLY49xAXES3ooOpoMHDbpo4sR6g Date: Wed, 27 Nov 2013 07:38:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C55D40B@ESESSMB209.ericsson.se> References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+JvrW7vwqlBBscWSFmsePKIxeLamX+M Fmv/tbNbnNi9jdGBxWPK742sHjtn3WX3WLLkJ5PHl8uf2QJYorhsUlJzMstSi/TtErgyzrdM ZC44w1ixYtZ7tgbGmYxdjJwcEgImEpPuH2aCsMUkLtxbz9bFyMUhJHCCUeLkuzZWCGcxo8S2 1UeBMhwcbAIWEt3/tEEaRASSJTY+n8QMUsMssIBR4vTqlSwgCWGBAInehe9YIIoCJVofLmSH sI0kWpfcZgWxWQRUJZ7MvA8W5xXwlVjccQVqczOzxMK578ESnEDNR1c1gg1iBDrv+6k1YKcy C4hL3HoyH+psAYkle84zQ9iiEi8f/2OFsBUlrk5fDlWvI7Fg9yc2CFtbYtnC18wQiwUlTs58 wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYySxanFxbnpRgZ6uem5JXqpRZnJxcX5eXrFqZsYgTF3 cMtvox2MJ/fYH2KU5mBREue9zloTJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxN0JvPQeH WXTx+2OJr8x3Jm2Vu/5dYUWUTknhqcf/Cp6y7GCqZHj7ZdGpjZsy1A68ttHfbjrt6OsDU9bb hXVUuHgfWl3i/2qu62qXV75G287NYFgz6ccH9UNnjE/8D0hborwqMOr8Jae1q/+sP+Tk+Ekn KGGK8N2ElQKMrAEHJs/xCGZTCn6yQomlOCPRUIu5qDgRAHQV19iHAgAA Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 07:38:57 -0000 Hi, > [1] and [2] can be solved by mandating WebRTC endpoints to support consen= t. I thought we were going to do that anyway - no matter what consent mechanis= m we use. Regards, Christer From tireddy@cisco.com Tue Nov 26 23:52:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B1B1AE198 for ; Tue, 26 Nov 2013 23:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 219McGvt7VoV for ; Tue, 26 Nov 2013 23:52:26 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6111AE199 for ; Tue, 26 Nov 2013 23:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=772; q=dns/txt; s=iport; t=1385538746; x=1386748346; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9xKNXUn/2N5U/GUrzZF8RjlZnhIqZJ+1gzs8X/8iDaw=; b=Zhv8fTpvvNBuGQLwyDVleWo17HVIVlnExMV5NmsNyua8xsLefAfmBrze eBtETuVoAQPggZ/YkcLpeZwzu6RmVZRV4mIHZ1/V4JjEh5UHYL/N2ONcC yd6671APn2fujrhxwBYGZplM0kQPBK/eyG5XzvhkzfNsnK02bcOHXstCW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALyjlVKtJV2Y/2dsb2JhbABZgweBC7sOgR0WdIIlAQEBAwE6PwwEAgEIEQQBAQsUCQcyFAkIAgQBDQUIh3MGwAcXjlExBwaDGoETA6ongymCKg X-IronPort-AV: E=Sophos;i="4.93,780,1378857600"; d="scan'208";a="284821899" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 27 Nov 2013 07:52:25 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAR7qPTI027523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 07:52:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 01:52:24 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Christer Holmberg , Martin Thomson Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 Thread-Index: AQHO60O66nMexb/MjEm6a7rVxenuKJo4sw3A Date: Wed, 27 Nov 2013 07:52:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2426EF4D@xmb-rcd-x10.cisco.com> References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C55D40B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C55D40B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 07:52:28 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, November 27, 2013 1:09 PM > To: Martin Thomson; Tirumaleswar Reddy (tireddy) > Cc: draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org; rtcweb@ietf.= org > Subject: RE: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshne= ss-00 >=20 > Hi, >=20 > > [1] and [2] can be solved by mandating WebRTC endpoints to support cons= ent. >=20 > I thought we were going to do that anyway - no matter what consent mechan= ism > we use. If DTLS based consent mechanism is picked then both peers must support DTLS= heartbeat and willing to exchange DTLS heartbeat request/response. Cheers, -Tiru. >=20 > Regards, >=20 > Christer From cowwoc@bbs.darktech.org Wed Nov 27 00:01:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C121AE1AB for ; Wed, 27 Nov 2013 00:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pqPW79lKIPa for ; Wed, 27 Nov 2013 00:01:29 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id A2C781AE254 for ; Wed, 27 Nov 2013 00:01:28 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id e14so11578322iej.0 for ; Wed, 27 Nov 2013 00:01:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sswzxQEBiVbexACPwPPViyGTEe/iGYlNtrJpNMTbOGk=; b=ecnH/SS5W+Ym8U559jPeE8FUodO1+KzTyi9dBdwKPBZF9XMvDXOkJedKQRZUSOzPIt iyxbVy+TQKJRWW7Qd6KLgVhU5aHQ2yKNeLfRBtRO1WweUp8vlpHW/p3lkgdqtp9w5EgN zUiPwaHoa4553QLFiNQ+lyIEJW5BZzXzyhaaIBGNU+4RTXFrjLf0CzvzRpdAU68cmGjj +VhFsteZX5Z8ZYa40vGWRnSBdtVJp4RqtN88Yk0a5Xw/MxjJYejhw8P+sUpcwQ2598Eu W0WH9eMDmnM75TngQj7zHLbpq3R1LUoFuHCgwqj1Ckj8RrChcar1C6BPa2DMKsjTgkwd jKWg== X-Gm-Message-State: ALoCoQnQdSHRhI32Acnma5Bzsah/hy2qe4vZGjuRpld9BoFMrIkPhq+usNQctKoq80N3lWEjXVXq X-Received: by 10.42.82.196 with SMTP id e4mr4344812icl.58.1385539288208; Wed, 27 Nov 2013 00:01:28 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id hv5sm37497770igb.9.2013.11.27.00.01.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 00:01:27 -0800 (PST) Message-ID: <5295A6A8.4080100@bbs.darktech.org> Date: Wed, 27 Nov 2013 03:00:40 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Adam Roach References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> <3132244A-FCB5-4C1F-86F1-E0897C47BCDA@nostrum.com> In-Reply-To: <3132244A-FCB5-4C1F-86F1-E0897C47BCDA@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 08:01:39 -0000 On 27/11/2013 12:53 AM, Adam Roach wrote: > On Nov 26, 2013, at 23:26, cowwoc wrote: > >> I guess I am asking about Cisco's mechanism, since it is the one that we will be bound by. I guess this would be much simpler if Cisco hit the licensing upper limit, because then we wouldn't need to keep on counting. > If you use Cisco's binary, you don't have to count. Cisco takes care if that for you. As far as I understand, they are paying the cap, but that fact doesn't make any difference to you one way or another. The important thing is that Cisco is distributing the codec, and Cisco is bearing the costs for making sure that anything it distributes is properly licensed. > Hi Adam, We still need to count. If that weren't the case, Cisco would let us bundle their binary as part of our installers. The reason they force us to download the binary after-the-fact is so that they can keep track of the count. Gili From christer.holmberg@ericsson.com Wed Nov 27 00:02:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0111ADEA6 for ; Wed, 27 Nov 2013 00:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE7Uj87MyD39 for ; Wed, 27 Nov 2013 00:02:32 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 80B231A1F3D for ; Wed, 27 Nov 2013 00:02:31 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-e6-5295a716e0db Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id EF.C7.22496.617A5925; Wed, 27 Nov 2013 09:02:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Wed, 27 Nov 2013 09:02:29 +0100 From: Christer Holmberg To: "Tirumaleswar Reddy (tireddy)" , Martin Thomson Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 Thread-Index: AQHO6tMo2ZLY49xAXES3ooOpoMHDbpo4sR6g///zrwCAABNW8A== Date: Wed, 27 Nov 2013 08:02:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C55D48D@ESESSMB209.ericsson.se> References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C55D40B@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A2426EF4D@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2426EF4D@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvra7Y8qlBBm/naVqsePKIxeLamX+M Fmv/tbNbnNi9jdGBxWPK742sHjtn3WX3WLLkJ5PHl8uf2QJYorhsUlJzMstSi/TtErgyNj0+ z17wmLnix+t5LA2Mv5m6GDk4JARMJC7+1upi5AQyxSQu3FvPBmILCZxglJg5WbmLkQvIXswo sW3eFxaQejYBC4nuf9ogNSICyRIv/31iB6lhFljAKHF69UoWkISwQIBE78J3LBBFgRKtDxey Q9hOEk3XpzOC2CwCqhKH2vrAbF4BX4mdf1awQizrYpHY+LEBLMEJlJjwdAcriM0IdN33U2uY QGxmAXGJW0/mM0FcLSCxZM95ZghbVOLl43+sELaixNXpy6HqdSQW7P7EBmFrSyxb+JoZYrGg xMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDIsopRsji1uDg33chALzc9t0QvtSgzubg4P0+vOHUT IzDeDm75bbSD8eQe+0OM0hwsSuK811lrgoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwVovF au7JYN8Ux7I5+9Gqvx6KDvLia4ytxLy+V8WK2552UedbqTJ/p8Y8YduwH69bsjYsNj3Xs7sp cIngxSU/he88uhvp9PJ75I2FWr0hiQVLb/j5sXSunxMqPWOhufvvH8FVWddvnP7hVBPX+13M YSGXpnvvsu4TWw9aPXXiPinTG6/x/l+JEktxRqKhFnNRcSIAhGVyx4UCAAA= Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 08:02:33 -0000 Hi, >>> [1] and [2] can be solved by mandating WebRTC endpoints to support cons= ent. >>=20 >> I thought we were going to do that anyway - no matter what consent=20 >> mechanism we use. > > If DTLS based consent mechanism is picked then both peers must support DT= LS heartbeat and willing to exchange DTLS heartbeat request/response. How is that different from using ICE for consent? That also require support= from both peers, doesn't it? Regards, Christer From dcpang@highfive.com Tue Nov 26 17:44:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9755D1AE03D for ; Tue, 26 Nov 2013 17:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9gDYCnyok1Y for ; Tue, 26 Nov 2013 17:44:23 -0800 (PST) Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by ietfa.amsl.com (Postfix) with ESMTP id EAA6F1ADF7F for ; Tue, 26 Nov 2013 17:44:22 -0800 (PST) Received: by mail-bk0-f41.google.com with SMTP id v15so2981751bkz.28 for ; Tue, 26 Nov 2013 17:44:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=a7MBBXEbB80WV2kmChg2qhIhPx8D8HSb61pMXH9Dnkc=; b=M/TFDDf6jFixUXnuD81rwr5GEqAQbnWTCpp2vmR2HTZbDh79IrnAG08wEESxj6y3g+ jF28bt7K1bz7KKn2taJFyqAPcvSy7c6eHn55O8Id1kk7bq+lPelE0yu9ADdHdv/dhybe HDhDjz3fSavRQ+WKW2781ydYgY9DzxeG1Xw7oFRQEgyDdXRjr+CvtS2pjQFz9+hD6TWa E+CQeEHrd/xlylMOQVkQn4ivbLUimxbRe5dn2RbnAoJO6ISiMi0BrUdjbvT36k+KbzFH Wc1CH+AXWOEkzUHIYNUPcV3oILBU6pV68s0ExpvOMGXttG0oP2qwRQAfeK3aH9/Xf3Dh Qoqw== X-Gm-Message-State: ALoCoQmdT1Zc5g2U+ZJQfZ1KJrs+pSHm9r/K+pzdJIL/niXpCRdBx7t696yxREkTQ2VBIsMzAIaE X-Received: by 10.204.106.139 with SMTP id x11mr28163336bko.7.1385516661606; Tue, 26 Nov 2013 17:44:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.162.78 with HTTP; Tue, 26 Nov 2013 17:44:01 -0800 (PST) In-Reply-To: <5295273C.1070602@alvestrand.no> References: <59A91D84-3D29-47C4-8688-CB60844B15D3@cisco.com> <24B2A6DE-958C-445C-BE77-8BD1661DC33D@cisco.com> <52922BA1.6070805@alvestrand.no> <5295273C.1070602@alvestrand.no> From: Derek Pang Date: Tue, 26 Nov 2013 17:44:01 -0800 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11333cc47277b404ec1ebc92 X-Mailman-Approved-At: Wed, 27 Nov 2013 00:34:25 -0800 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Offer/answer for heterogeneous encode/decode X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 01:44:25 -0000 --001a11333cc47277b404ec1ebc92 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Harald, Thank you for your patience and the pointer. Much appreciated, Derek On Tue, Nov 26, 2013 at 2:57 PM, Harald Alvestrand wr= ote: > On 11/26/2013 11:07 PM, Derek Pang wrote: > > I am new to rtcweb community. Was there any proposal on making both Vp8 > and H264 decoders MTI in webrtc, but VP8 or H264 encoder to be optional ? > Does this offer a better option for the marketplace, while allowing > interoperability. > > > I appreciate that the amount of reading you have to do in order to catch > up with the archives is enormous, but it is definitely a good thing to do > at this juncture. > > This is alternative 12 on http://tools.ietf.org/wg/rtcweb/trac/wiki, > where the current alternatives that the chairs are considering proposing = a > vote to choose between have been listed. > > > > > > On Sun, Nov 24, 2013 at 8:38 AM, Harald Alvestrand = wrote: > >> On 11/23/2013 01:20 AM, Paul Giralt (pgiralt) wrote: >> >>> On Nov 22, 2013, at 7:06 PM, Martin Thomson >>> wrote: >>> >>> On 22 November 2013 15:44, Paul Giralt (pgiralt) >>>> wrote: >>>> >>>>> While you=92re right that it would work for this scenario, my point w= as >>>>> really >>>>> that Offer/Answer is not really asymmetric as implied earlier. Take f= or >>>>> example the hypothetical case where you are only able to decode VP8 >>>>> but only >>>>> able to encode H.264. If I offer VP8 as my only codec (because it=92s >>>>> the only >>>>> thing I=92m able to decode therefore I never want anyone to send me >>>>> anything >>>>> other than VP8) I cannot send H.264 in the offer because that implies >>>>> I=92m >>>>> able to decode it. The other side then wants to say it can only recei= ve >>>>> H.264 so it would have to send back an answer with only H.264. I gues= s >>>>> there=92s nothing really inherently stopping you from doing this beca= use >>>>> as >>>>> far as I can tell, 3264 only says the answer has to be a subset of th= e >>>>> offer >>>>> for multicast streams, however how would the answering side know that >>>>> the >>>>> offering side is even capable to receiving H.264? Perhaps Offer/Answe= r >>>>> can >>>>> technically be asymmetric, but it doesn=92t seem practical to use it >>>>> this way >>>>> because you cannot really indicate your send and receive capabilities >>>>> independent of each other. >>>>> >>>> Judicious application of a=3Dsendonly or a=3Drecvonly avoids this issu= e. >>>> If you want to send H.264, try a=3Dsendonly on a line with H.264. If >>>> you want to receive VP8, try a=3Drecvonly on a line with VP8. >>>> >>> I gave this as an example of a possible way to do it, but that means yo= u >>> need two separate m=3D lines - one for send and one for receive. Seems >>> strange to do this for something that you really want to be a single >>> bi-directional stream. >>> >> >> An application that can't talk to itself is kind of bizarre too. >> >> I think this is a corner case. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > > -- > Surveillance is pervasive. Go Dark. > > --001a11333cc47277b404ec1ebc92 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Harald,

Thank you for your patience and= the pointer.=A0

Much appreciated,
Derek=


O= n Tue, Nov 26, 2013 at 2:57 PM, Harald Alvestrand <harald@alvestrand.no= > wrote:
=20 =20 =20
On 11/26/2013 11:07 PM, Derek Pang wrote:
I am new to rtcweb community. Was there any proposal on making both Vp8 and H264 decoders MTI in webrtc, but VP8 or H264 encoder to be optional ? Does this offer a better option for the marketplace, while allowing interoperability.

I appreciate that the amount of reading you have to do in order to catch up with the archives is enormous, but it is definitely a good thing to do at this juncture.

This is alternative 12 on =20 http://tools.ietf.org/wg/rtcweb/trac/wiki, where the current alternatives that the chairs are considering proposing a vote to choose between have been listed.





On Sun, Nov 24, 2013 at 8:38 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
On 11/23/2013 01:20 AM, Paul Giralt (pgiralt) wrote:
On Nov 22, 2013, at 7:06 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:

On 22 November 2013 15:44, Paul Giralt (pgiralt) <pgiralt@cisco.com> wrote:
While you=92re right that it would work for this scenario, my point was really
that Offer/Answer is not really asymmetric as implied earlier. Take for
example the hypothetical case where you are only able to decode VP8 but only
able to encode H.264. If I offer VP8 as my only codec (because it=92s the only
thing I=92m able to decode therefore I never want anyone to send me anything
other than VP8) I cannot send H.264 in the offer because that implies I=92m
able to decode it. The other side then wants to say it can only receive
H.264 so it would have to send back an answer with only H.264. I guess
there=92s nothing really inherently stopping you from doing this because as
far as I can tell, 3264 only says the answer has to be a subset of the offer
for multicast streams, however how would the answering side know that the
offering side is even capable to receiving H.264? Perhaps Offer/Answer can
technically be asymmetric, but it doesn=92t seem practical to use it this way
because you cannot really indicate your send and receive capabilities
independent of each other.
Judicious application of a=3Dsendonly or a=3Drecvonly avoids this issue.
If you want to send H.264, try a=3Dsendonly on a line with H.264. =A0If
you want to receive VP8, try a=3Drecvonly on a line with VP8.
I gave this as an example of a possible way to do it, but that means you need two separate m=3D lines - one for send and one for receive. Seems strange to do this for something that you really want to be a single bi-directional stream.

An application that can't talk to itself is kind of bizarre too.

I think this is a corner case.


_______________________________________________
rtcweb mailing list
rtcweb= @ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



--=20
Surveillance is pervasive. Go Dark.

--001a11333cc47277b404ec1ebc92-- From magnus.westerlund@ericsson.com Wed Nov 27 00:51:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3191AD944 for ; Wed, 27 Nov 2013 00:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXAvCmAJRpcq for ; Wed, 27 Nov 2013 00:51:12 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 54A0F1AE004 for ; Wed, 27 Nov 2013 00:51:06 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-1d-5295b27a5768 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 37.0F.22496.A72B5925; Wed, 27 Nov 2013 09:51:06 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.328.9; Wed, 27 Nov 2013 09:50:59 +0100 Message-ID: <5295B273.1060305@ericsson.com> Date: Wed, 27 Nov 2013 09:50:59 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: , References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+JvrW7VpqlBBpsPCVh0r57FZnH+7yI2 i7X/2tkdmD12zrrL7rFkyU8mj7u3LjEFMEdx2aSk5mSWpRbp2yVwZTTsnsJU0MFW8efoa5YG xn8sXYwcHBICJhKzp/t3MXICmWISF+6tZ+ti5OIQEjjBKPH3z1EoZzmjxInlp9lAqngFtCUm nb7EBGKzCKhKzHr4E8xmE7CQuPmjEaxGVCBY4mrvOmaIekGJkzOfsIDYIgLGEitn9IDVMwuI Srx6OAWsRljAS2LJwznsEMvuMEq83nWGHSTBKRAhcbz1JdSl4hI9jUEQvXoSU662MELY8hLN W2eDzRECuq2hqYN1AqPQLCSrZyFpmYWkZQEj8ypGyeLU4uLcdCMDvdz03BK91KLM5OLi/Dy9 4tRNjMAQP7jlt9EOxpN77A8xSnOwKInzXmetCRISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA 6BEW/mPv2YaqqBiR209Dn1z7ufmhzgLha+rzLn9/Me0t1/VJcWH5DEfixH+W6H5uP/dN7Z7A w9mX5Uwaa7d3r9a/fkP5T4jFizuWL47+ztpzc3NvupTMxYeLXu26mVoldG9K5v22So7bKWo9 TBf9335/nbevd4bgYdZ2Bs2p7CfKq/5WnLqmeVOJpTgj0VCLuag4EQAZe0e6PwIAAA== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 08:51:31 -0000 On 2013-11-25 20:51, Markus.Isomaki@nokia.com wrote: > MUST implement at least two of {VP8, H.264 CBP, H.261} I have now updated the list to read: 10. All entities MUST implement at least two of {VP8, H.264 CBP, H.261} 11. All entities MUST implement at least two of {VP8, H.264 CBP, H.263} Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Nov 27 00:55:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9771AE266 for ; Wed, 27 Nov 2013 00:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur4rD2Ww-H7V for ; Wed, 27 Nov 2013 00:54:59 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B28931AE21A for ; Wed, 27 Nov 2013 00:54:49 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-9c-5295b358200a Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B4.70.23787.853B5925; Wed, 27 Nov 2013 09:54:48 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.328.9; Wed, 27 Nov 2013 09:54:48 +0100 Message-ID: <5295B358.1040302@ericsson.com> Date: Wed, 27 Nov 2013 09:54:48 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+JvrW7E5qlBBrdu61us/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO4JhxkLFnFXNN69wtjA+J+ji5GTQ0LAROLVqsOMELaYxIV7 69m6GLk4hAQOMUr8nfGXGcJZziixqPMwG0gVr4C2RNOxicwgNouAqsT7T1fYQWw2AQuJmz8a wWpEBYIlrvauY4aoF5Q4OfMJC4gtIqAucfnhBbB6YQF3iZ5H+1m7GDmANotL9DQGgYSZBfQk plxtYYSw5SWat84GGyMEtLahqYN1AiP/LCRTZyFpmYWkZQEj8ypG9tzEzJz0csNNjMBwOrjl t+4OxlPnRA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMeBjUMyXDN7J Gy7o9/oWL+TMY2H2UJ3VvFuo5MONiC3Hd8u8dU6zcZD5esDR6JcH0yr+qBzpZRIbwoVXTV/V tyGqZiPH1+Ldr/6qnJMv+BpTqrZIVGsj6yqLL6ymRqxsm7Zv8p3+9Yfs80VsC/N8Xr6yPsnM MqFgcyGLpWzPxOXZe9esE7vxT4mlOCPRUIu5qDgRAFhtrzn1AQAA Subject: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 08:55:25 -0000 WG, Today (27th November) is the last day to propose any additional alternatives for the Video Codec Selection. The current list of alternatives are the following: 1. All entities MUST support H.264 2. All entities MUST support VP8 3. All entities MUST support both H.264 and VP8 4. Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8 5. All entities MUST support at least one of H.264 and VP8 6. All entities MUST support H.261 7. There is no MTI video codec 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8 9. All entities MUST support Theora. 10. All entities MUST implement at least two of {VP8, H.264 CBP, H.261} 11. All entities MUST implement at least two of {VP8, H.264 CBP, H.263} 12. All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8 Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Nov 27 01:15:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF131AE033 for ; Wed, 27 Nov 2013 01:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HSseiVkqFbK for ; Wed, 27 Nov 2013 01:15:15 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 254681AE008 for ; Wed, 27 Nov 2013 01:15:14 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-ac-5295b821edad Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 4C.5A.27941.128B5925; Wed, 27 Nov 2013 10:15:14 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Wed, 27 Nov 2013 10:15:13 +0100 Message-ID: <5295B821.6030807@ericsson.com> Date: Wed, 27 Nov 2013 10:15:13 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: References: <5295B358.1040302@ericsson.com> In-Reply-To: <5295B358.1040302@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvra7SjqlBBi/ec1qs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE0L1AoWyFbMfenQwHhMvIuRk0NCwERiX992VghbTOLCvfVs ILaQwBFGiYvvM7sYuYDs5YwS7669BiviFdCWePqtiR3EZhFQlTi9/ToziM0mYCFx80cjWLOo QLDE1d51zBD1ghInZz5hAbFFBEQlXj+eBjZHWCBEYu6XF+wQy7QlZl8/BlbPKaAjsexJD1AN B9BB4hI9jUEgYWYBTYnW7b/ZIWx5ieats5lhWhuaOlgnMArOQrJtFpKWWUhaFjAyr2LkKE4t TspNNzLYxAgMvYNbflvsYLz81+YQozQHi5I478e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGPkk2ffK/hYoaedwWXJb/fYevn2pH++kev7SOtfwOlcpTG1vfm6+ZsJGnr99HHq3DxU7 zuS7/qn20M6PJ54f6Lrs/ufIPP3fnfbaG/7um2U1yUvPhO9P13ETwxU7BKYbXOaVy2eMNf7a X1Wz6r/v56dvjxjlZqzjMSlnOuzluDXwJ+8bFWm7i0osxRmJhlrMRcWJAMOm8uoLAgAA Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 09:15:30 -0000 WG, I got a comment that it was a bit confusing that just 10 and 11 contained the Constrained Baseline Profile. To my understanding all mentionings of H.264 reference the proposal in https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ and all VP8 are a reference to https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/ This has been edited into the Wiki list: http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart That thus read: The following alternatives has been proposed: 1. All entities MUST support H.264 2. All entities MUST support VP8 3. All entities MUST support both H.264 and VP8 4. Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8 5. All entities MUST support at least one of H.264 and VP8 6. All entities MUST support H.261 7. There is no MTI video codec 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8 9. All entities MUST support Theora 10. All entities MUST implement at least two of {VP8, H.264, H.261} 11. All entities MUST implement at least two of {VP8, H.264, H.263} 12. All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8 H.264 is a reference to the proposal in ​ https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ VP8 is a reference to the proposal in ​ https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/ Cheers Magnus On 2013-11-27 09:54, Magnus Westerlund wrote: > WG, > > Today (27th November) is the last day to propose any additional > alternatives for the Video Codec Selection. > > The current list of alternatives are the following: > > 1. All entities MUST support H.264 > 2. All entities MUST support VP8 > 3. All entities MUST support both H.264 and VP8 > 4. Browsers MUST support both H.264 and VP8, other entities MUST > support at least one of H.264 and VP8 > 5. All entities MUST support at least one of H.264 and VP8 > 6. All entities MUST support H.261 > 7. There is no MTI video codec > 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST > support at least one of H.264 and VP8 > 9. All entities MUST support Theora. > 10. All entities MUST implement at least two of {VP8, H.264 CBP, H.261} > 11. All entities MUST implement at least two of {VP8, H.264 CBP, H.263} > 12. All entities MUST support decoding using both H.264 and VP8, and > MUST support encoding using at least one of H.264 or VP8 > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From keith.drage@alcatel-lucent.com Wed Nov 27 02:25:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBE71AE029 for ; Wed, 27 Nov 2013 02:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXbk8_z06RYL for ; Wed, 27 Nov 2013 02:25:37 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 064791AD68D for ; Wed, 27 Nov 2013 02:25:36 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rARAPXrU021368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 27 Nov 2013 04:25:35 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rARAPWKa019785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 27 Nov 2013 11:25:33 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 27 Nov 2013 11:25:33 +0100 From: "DRAGE, Keith (Keith)" To: "rtcweb@ietf.org" Thread-Topic: Mandatory to implement video codec? Thread-Index: Ac7cLiqalLlZVs40QU+PGyClgL6FtQPLLwbA Date: Wed, 27 Nov 2013 10:25:32 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0EE419@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [rtcweb] Mandatory to implement video codec? X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 10:25:39 -0000 A reminder that I have not had any response to this mail. It would be nice if someone cound direct me to the right place. Keith=20 > -----Original Message----- > From: DRAGE, Keith (Keith)=20 > Sent: 08 November 2013 02:57 > To: rtcweb@ietf.org > Subject: Mandatory to implement video codec? >=20 > References have been made to a prior consensus decision to=20 > have a mandatory to implement video codec. >=20 > I'd like to refresh myself on those discussions and am having=20 > difficulty finding them. >=20 > Can someone remember when they occurred and therefore point=20 > me in the right direction? >=20 > Regards >=20 > Keith= From emil@sip-communicator.org Wed Nov 27 03:41:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5263F1AE135 for ; Wed, 27 Nov 2013 03:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIbAk9feBdfD for ; Wed, 27 Nov 2013 03:41:16 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9511AE101 for ; Wed, 27 Nov 2013 03:41:15 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so6734554wes.29 for ; Wed, 27 Nov 2013 03:41:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xFkxuPOEmIIlpDzc1RqogZKPK8CzjzJjR44zkl+sHm8=; b=Nl2KawdlCe2yNAsgHzLgODzZkMrdsei28f6yr5RBmbGu2d+qnYcae5OJmG6n0Ty2L3 4RCm60/MYQLix+u+qW1Lxkmwx67xpBUlnroEPw2MrZebOGQSduRlhLaAe6vvuJ1Qox8k 6Nc1PgzoA3EoLiW/1N6v6W2frDYiSiDo8PT26y+F/7y05BMbHTRcusRolSfpIds7vDQg 6Fs9xEl67KSm1chN8dGN++/OKai+Pjb09dHryrqow0vgO7WZ8RjIdtIjpZZBFEo9RJ89 O25dtMKN5lKekC4pSEoKvGwr84rOhjQCT9F0r0c9xhxBI+bFDe75O/Hh9fbhwHRLchc7 4ZMw== X-Gm-Message-State: ALoCoQktxtH5Fx84M8PqC4P2MzjiBQGoGBYia3Rli0aTB7GDLYoixYM4L9bElqfjPjmMnNJQmxTQ X-Received: by 10.194.174.36 with SMTP id bp4mr30558265wjc.7.1385552474869; Wed, 27 Nov 2013 03:41:14 -0800 (PST) Received: from camionet.local ([2a01:e35:8a04:14f0:f1f2:b650:288c:56fb]) by mx.google.com with ESMTPSA id a19sm69972203wib.1.2013.11.27.03.41.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 03:41:13 -0800 (PST) Message-ID: <5295DA58.60504@jitsi.org> Date: Wed, 27 Nov 2013 12:41:12 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Magnus Westerlund References: <5295B358.1040302@ericsson.com> In-Reply-To: <5295B358.1040302@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 11:41:18 -0000 Just to confirm, this is NOT the last day of discussion on whether a=20 vote is the right way to do this at all, right? That sounds like it would still be an open question for step two here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html It's not explicitly stated though so a confirmation would be nice. Emil On 27.11.13, 09:54, Magnus Westerlund wrote: > WG, > > Today (27th November) is the last day to propose any additional > alternatives for the Video Codec Selection. > > The current list of alternatives are the following: > > 1. All entities MUST support H.264 > 2. All entities MUST support VP8 > 3. All entities MUST support both H.264 and VP8 > 4. Browsers MUST support both H.264 and VP8, other entities MUST > support at least one of H.264 and VP8 > 5. All entities MUST support at least one of H.264 and VP8 > 6. All entities MUST support H.261 > 7. There is no MTI video codec > 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST > support at least one of H.264 and VP8 > 9. All entities MUST support Theora. > 10. All entities MUST implement at least two of {VP8, H.264 CBP, H.261}= > 11. All entities MUST implement at least two of {VP8, H.264 CBP, H.263}= > 12. All entities MUST support decoding using both H.264 and VP8, and > MUST support encoding using at least one of H.264 or VP8 > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > . > --=20 https://jitsi.org From magnus.westerlund@ericsson.com Wed Nov 27 04:32:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD171AE1C6 for ; Wed, 27 Nov 2013 04:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxjvJGEu9nJ0 for ; Wed, 27 Nov 2013 04:32:38 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id B45BC1AE1B8 for ; Wed, 27 Nov 2013 04:32:37 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-49-5295e664ac93 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 4F.7A.27941.466E5925; Wed, 27 Nov 2013 13:32:36 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.328.9; Wed, 27 Nov 2013 13:32:35 +0100 Message-ID: <5295E663.4020607@ericsson.com> Date: Wed, 27 Nov 2013 13:32:35 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Emil Ivov References: <5295B358.1040302@ericsson.com> <5295DA58.60504@jitsi.org> In-Reply-To: <5295DA58.60504@jitsi.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Vjfl2dQgg9bVRhZrdk5gsVj7r53d gcljyZKfTB7/3wQGMEVx2aSk5mSWpRbp2yVwZfxtbmEvuMRZcfz7d+YGxtfsXYycHBICJhJ/ Ji9ngbDFJC7cW88GYgsJHGGUWHuBuYuRC8heziixed4cVpAEr4C2xOkN38EaWARUJdZO2g4W ZxOwkLj5oxGsWVQgWOJq7zpmiHpBiZMzn4DViwjIS3S3LWICsZkF1CXuLD4HdoSwQIjE3C8v 2CEWu0lsWPMZzOYEqpn6pwOongPoOHGJnsYgiFY9iSlXWxghbHmJ5q2zmSFatSUamjpYJzAK zUKyeRaSlllIWhYwMq9i5ChOLU7KTTcy2MQIDNSDW35b7GC8/NfmEKM0B4uSOO/Ht85BQgLp iSWp2ampBalF8UWlOanFhxiZODilGhhPh19d8L+oJ+D/98ezZ+74XvFkieziBaJH67VnuUst Dtj6btq1hTbP3+v7SMs5K9UvFeP5x/Vlzpcnq56Eihwx2dC4S+56xq+oz3ymClOmOdx6HzM1 mv/4qf2nK1kCd08IUfyb4DDhno3WmWliy+UnGNpPky2403Z/mXOt2FUzq7fdqgpm0V58SizF GYmGWsxFxYkA/kx8+iICAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 12:32:39 -0000 On 2013-11-27 12:41, Emil Ivov wrote: > Just to confirm, this is NOT the last day of discussion on whether a > vote is the right way to do this at all, right? No, but tomorrow a week will have passed since we chairs sent out the proposal and solicited feedback on the proposal. > > That sounds like it would still be an open question for step two here: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html As we stated in this message, after the week we chairs would update the process proposal if we considered it necessary. I believe there are some clarifications that needs to be done, including the voter eligibility. After that the stated plan was to hold a consensus call in the WG to use the proposed process. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tireddy@cisco.com Wed Nov 27 05:02:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D011ADF91 for ; Wed, 27 Nov 2013 05:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQG2BSPHDR0X for ; Wed, 27 Nov 2013 05:02:28 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 718601AD8E3 for ; Wed, 27 Nov 2013 05:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=965; q=dns/txt; s=iport; t=1385557348; x=1386766948; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PLDLNQsWYSczDPDoMUD8UISUOjrCvhCiYEeA1g8W4rs=; b=dvjlvCy+rND3PM2CkKcxCxQe/dAfXQ/aBE5WAQQFkMMSwT7nTU1G39aS OGf41UmmbPgpLomFlpcR1L+5ekzy6QADBZ5AWj+VoDTykys9mZ8/wHoQD vL2SDq0eJMfVzGNk/mAwKPZPYca0EfVxkS/pd5xQ7Gk0ctugdq4BkF2nY o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFABftlVKtJV2Z/2dsb2JhbABZgweBC7pxgR0WdIIlAQEBAwE6PwwEAgEIEQQBAQsUCQcyFAkIAgQBDQUIh3MGwD4XjlExBwaDGoETA6ongymCKg X-IronPort-AV: E=Sophos;i="4.93,782,1378857600"; d="scan'208";a="2637521" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 27 Nov 2013 13:02:27 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rARD2Rh9032292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 13:02:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 07:02:27 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Christer Holmberg , Martin Thomson Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 Thread-Index: AQHO60O66nMexb/MjEm6a7rVxenuKJo4sw3AgABpCYD//+ogoA== Date: Wed, 27 Nov 2013 13:02:26 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2426F209@xmb-rcd-x10.cisco.com> References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C55D40B@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A2426EF4D@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C55D48D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C55D48D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 13:02:30 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, November 27, 2013 1:32 PM > To: Tirumaleswar Reddy (tireddy); Martin Thomson > Cc: draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org; rtcweb@ietf.= org > Subject: RE: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshne= ss-00 >=20 > Hi, >=20 > >>> [1] and [2] can be solved by mandating WebRTC endpoints to support > consent. > >> > >> I thought we were going to do that anyway - no matter what consent > >> mechanism we use. > > > > If DTLS based consent mechanism is picked then both peers must support = DTLS > heartbeat and willing to exchange DTLS heartbeat request/response. >=20 > How is that different from using ICE for consent? That also require suppo= rt > from both peers, doesn't it ? Yes, ICE for consent also requires support from both peers.=20 -Tiru. >=20 > Regards, >=20 > Christer From magnus.westerlund@ericsson.com Wed Nov 27 05:13:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FA71AE197 for ; Wed, 27 Nov 2013 05:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jov_ck-dHnNh for ; Wed, 27 Nov 2013 05:13:26 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1001AD943 for ; Wed, 27 Nov 2013 05:13:25 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-03-5295eff46bc8 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F3.55.03802.4FFE5925; Wed, 27 Nov 2013 14:13:24 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.2.328.9; Wed, 27 Nov 2013 14:13:24 +0100 Message-ID: <5295EFF3.9050303@ericsson.com> Date: Wed, 27 Nov 2013 14:13:23 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "rtcweb@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B0EE419@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0EE419@FR712WXCHMBA11.zeu.alcatel-lucent.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3VvfL+6lBBhcvqVs8bTzLaLH2Xzu7 A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY/e8wS8FJoYp5By6wNTB28XcxcnJICJhI zP67hB3CFpO4cG89WxcjF4eQwCFGieNrPkM5yxklDj6exARSxSugLXF2Zz9LFyMHB4uAqsT9 OUkgYTYBC4mbPxrZQGxRgWCJq73rmCHKBSVOznzCAmKLCCRJHPzVzQpiCwtYSiy6vhisXkgg SmLvtONMICM5BaIl1h7lAzElBMQlehqDQCqYBfQkplxtYYSw5SWat85mhujUlmho6mCdwCg4 C8myWUhaZiFpWcDIvIqRPTcxMye93GgTIzAcD275rbqD8c45kUOM0hwsSuK8H946BwkJpCeW pGanphakFsUXleakFh9iZOLglGpgFOl/0JCw3fTZsZsKUYUnZ++Uklyy8kH6LM+HG5YLxHmL r7DlUl9cPSO2pk8sv3XOAs+NFSfruc9qnBL3sJDO1GFzDzXOLZ/zYnfVNCaRo+sPlnY3PLG0 EIucItP7+RJzS3vj289Mn1nOGL56+/ne4Yrd+94vjtk4yXfTymV/70/YaLQv79dnUSWW4oxE Qy3mouJEAEWs6h0VAgAA Subject: Re: [rtcweb] Mandatory to implement video codec? X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 13:13:29 -0000 Keith, I think this really goes back to the BOF and ad-hoc meeting during IETF 80 and the chartering, considering our charter do contain the following text: 6. Define a set of media formats that must or should be supported by a client to improve interoperability. Unfortunately the minutes for IETF 80 Adhoc simply mentions codec discussion but no details. Also Harald's email moving the discussion to the WG mailing list (8th of April 2011), includes a immediate jump to how do we achieve a MTI, rather any discussion if this is something that needs to be established. I am quite certain that this consensus was something the WG was created with. And all mentions in email or slides that I have looked includes this assumption. Including the Video Codec discussion in Paris. Look at slide 3 where the slides states that we have consensus on the need for MTI. http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-5.pdf http://www.ietf.org/proceedings/83/minutes/minutes-83-rtcweb.txt Cheers Magnus On 2013-11-27 11:25, DRAGE, Keith (Keith) wrote: > A reminder that I have not had any response to this mail. > > It would be nice if someone cound direct me to the right place. > > Keith > >> -----Original Message----- >> From: DRAGE, Keith (Keith) >> Sent: 08 November 2013 02:57 >> To: rtcweb@ietf.org >> Subject: Mandatory to implement video codec? >> >> References have been made to a prior consensus decision to >> have a mandatory to implement video codec. >> >> I'd like to refresh myself on those discussions and am having >> difficulty finding them. >> >> Can someone remember when they occurred and therefore point >> me in the right direction? >> >> Regards >> >> Keith > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From treising75@gmail.com Wed Nov 27 05:17:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D3D1A1F3E for ; Wed, 27 Nov 2013 05:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g9G_E8gEZry for ; Wed, 27 Nov 2013 05:17:03 -0800 (PST) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id E48F51A1F19 for ; Wed, 27 Nov 2013 05:17:02 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id d10so4706059eaj.37 for ; Wed, 27 Nov 2013 05:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=UD41yRL1azISsOPqRXvz+btuJCLt8P5FTgd+TOlQ9wQ=; b=R/3L4thgl5c+ICcjoI5sJV8aOg305XltRNTSzWSXRo52JM1IP4e3f3WBKHapNiaKmL on6PWIqfU13qWZIFdMme5/irpMVL70WNOaFMpKA4cMJoCIlamikuiz70ZTBPOn5OzfPA a6WhKq/fBUeZ+6ENwxZ/3nZdZ+HSiynr/Y0+VOYm2PYYmem41J2Tgx/jg132rQkJlbwk Fqe1ivohnrGoVlVzYDIYK+OlA4tDCEnC9I4+OgeV30CnqO1MqQ8OcK+MVRem+XjJ9ydH qbJ5xsXOodP1kR5C59kkIbS8xTGHiEsUFFoH6JXCIu46iPzScfN+hFiDEURW8It42s8o nAJQ== X-Received: by 10.14.101.4 with SMTP id a4mr44490167eeg.28.1385558221966; Wed, 27 Nov 2013 05:17:01 -0800 (PST) Received: from [10.147.184.53] (213162068021.public.t-mobile.at. [213.162.68.21]) by mx.google.com with ESMTPSA id h48sm19524291eev.3.2013.11.27.05.17.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 05:17:00 -0800 (PST) References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5295B273.1060305@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B554a) From: Thomas Reisinger Date: Wed, 27 Nov 2013 14:16:57 +0100 To: Magnus Westerlund Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 13:17:04 -0000 Magnus, Could you please share the latest list and how the voting will be conducted/= what's required to vote. Cheers, Thomas Reisinger > On 27.11.2013, at 09:50, Magnus Westerlund wrote: >=20 >> On 2013-11-25 20:51, Markus.Isomaki@nokia.com wrote: >> MUST implement at least two of {VP8, H.264 CBP, H.261} >=20 > I have now updated the list to read: >=20 > 10. All entities MUST implement at least two of {VP8, H.264 CBP, H.261} > 11. All entities MUST implement at least two of {VP8, H.264 CBP, H.263} >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 From tim@phonefromhere.com Wed Nov 27 05:28:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF481AD9A9 for ; Wed, 27 Nov 2013 05:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKEn9o04coMn for ; Wed, 27 Nov 2013 05:28:38 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id 24DAF1AD7BF for ; Wed, 27 Nov 2013 05:28:38 -0800 (PST) Received: (qmail 75391 invoked from network); 27 Nov 2013 13:28:36 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 7352 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 27 Nov 2013 13:28:36 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id AE26018A03EC; Wed, 27 Nov 2013 13:28:36 +0000 (GMT) Received: from [192.168.157.132] (unknown [192.67.4.35]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 5CB1318A02FF; Wed, 27 Nov 2013 13:28:36 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: tim panton In-Reply-To: <5295EFF3.9050303@ericsson.com> Date: Wed, 27 Nov 2013 13:28:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1E2FADBF-061B-4549-98B2-B1BFE06D8394@phonefromhere.com> References: <949EF20990823C4C85C18D59AA11AD8B0EE419@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5295EFF3.9050303@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1822) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mandatory to implement video codec? X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 13:28:40 -0000 On 27 Nov 2013, at 13:13, Magnus Westerlund = wrote: > Keith, >=20 > I think this really goes back to the BOF and ad-hoc meeting during = IETF > 80 and the chartering, considering our charter do contain the = following > text: >=20 > 6. Define a set of media formats that must or should be supported by > a client to improve interoperability. >=20 > Unfortunately the minutes for IETF 80 Adhoc simply mentions codec > discussion but no details. >=20 > Also Harald's email moving the discussion to the WG mailing list (8th = of > April 2011), includes a immediate jump to how do we achieve a MTI, > rather any discussion if this is something that needs to be = established. >=20 > I am quite certain that this consensus was something the WG was = created > with. And all mentions in email or slides that I have looked includes > this assumption. Including the Video Codec discussion in Paris. Look = at > slide 3 where the slides states that we have consensus on the need for = MTI. > http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-5.pdf > http://www.ietf.org/proceedings/83/minutes/minutes-83-rtcweb.txt >=20 Unfortunately the WG was also started on the assumption that the IETF = doesn=92t do voting. It also doesn=92t do voting by arbitrary closed groups. =20 It seems to me we have 2 sets of incompatible assumptions. At least one of them has to go. One option would be to punt the codec decision to somewhere they do vote = - e.g. W3C. Tim. From magnus.westerlund@ericsson.com Wed Nov 27 05:43:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13BE1ADF97 for ; Wed, 27 Nov 2013 05:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kjrlu-7SQLM1 for ; Wed, 27 Nov 2013 05:43:55 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AC5A01ADF65 for ; Wed, 27 Nov 2013 05:43:54 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-2e-5295f719a9a7 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 47.59.03802.917F5925; Wed, 27 Nov 2013 14:43:53 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.328.9; Wed, 27 Nov 2013 14:43:52 +0100 Message-ID: <5295F718.9010603@ericsson.com> Date: Wed, 27 Nov 2013 14:43:52 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Thomas Reisinger References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+Jvra7k96lBBpPeaVh0r57FZnH+7yI2 i7X/2tktWl9uY3Ng8dg56y67x5IlP5k87t66xBTAHMVlk5Kak1mWWqRvl8CVcePGL6aCy+IV e78+YGlgnCbcxcjJISFgIvHk43lWCFtM4sK99WxdjFwcQgKHGCU+7G6CcpYzSvw7t4INpIpX QFvizZOf7CA2i4CqxJ+uiWDdbAIWEjd/NILViAoES1ztXccMUS8ocXLmE5YuRg4OEaDeJ8tq QGYyC/QzShx/0ANWLyzgJbHk4Rx2iGVrmSROfn8G1swpYCvRsfY2K0izhIC4RE9jEEiYWUBT onX7b3YIW16ieetssHIhoPkNTR2sExiFZiFZPQtJyywkLQsYmVcxsucmZuaklxttYgSG8sEt v1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjHskFs54o75k nr8rbynLlE23etMFsr/8aquWS7UWY1noeyutdPrKog1NdW8VHuXq+yzdflVEQaxNsOLg9z2X NNe8nlbIdux8kdl/DvZ1y/L2RdxKfiGxNG6SUnxp5bop8pvea8TVNZfOPSxjtELf7F5NwlKf JX1/9c8+fap2qSTyAt/5438WaiqxFGckGmoxFxUnAgCfP187MwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 13:43:58 -0000 On 2013-11-27 14:16, Thomas Reisinger wrote: > Magnus, > > Could you please share the latest list and how the voting will be conducted/what's required to vote. For the proposed voting process see our previous message http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html As I stated, we chairs will need to update this based on the discussion. For the current list of alternatives is on the WG's wiki: http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart Reproduced here: The following alternatives has been proposed: 1. All entities MUST support H.264 2. All entities MUST support VP8 3. All entities MUST support both H.264 and VP8 4. Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8 5. All entities MUST support at least one of H.264 and VP8 6. All entities MUST support H.261 7. There is no MTI video codec 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8 9. All entities MUST support Theora 10. All entities MUST implement at least two of {VP8, H.264, H.261} 11. All entities MUST implement at least two of {VP8, H.264, H.263} 12. All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8 H.264 is a reference to the proposal in ​ https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ VP8 is a reference to the proposal in ​ https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/ > > Cheers, > > Thomas Reisinger > >> On 27.11.2013, at 09:50, Magnus Westerlund wrote: >> >>> On 2013-11-25 20:51, Markus.Isomaki@nokia.com wrote: >>> MUST implement at least two of {VP8, H.264 CBP, H.261} >> >> I have now updated the list to read: >> >> 10. All entities MUST implement at least two of {VP8, H.264 CBP, H.261} >> 11. All entities MUST implement at least two of {VP8, H.264 CBP, H.263} >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fluffy@cisco.com Wed Nov 27 06:53:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557071ADDAF for ; Wed, 27 Nov 2013 06:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.501 X-Spam-Level: X-Spam-Status: No, score=-114.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIwYiUoRS5oT for ; Wed, 27 Nov 2013 06:53:19 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 712981ADBF7 for ; Wed, 27 Nov 2013 06:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1788; q=dns/txt; s=iport; t=1385563999; x=1386773599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uNS3Ljh8kpybrM1D2vhiVP0RujEsPpCnEm4bC8CE0SQ=; b=XZKhEoOj/p4gqa4CMK57uV1SwRz5MbaxHSRYvEd90GqkA3WgF+cMAS8k Mgusc+OkZd++0HnVc5FpLaR5cIDKI4mjGPd+tsTBOa8S3f78sjLK6ajFJ Tpf13HN2A7HGzaIl/MXZH0zZJDZvk7FNj3JYB+g7I0zkKVRJJZ07F/bFF U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMKAFMGllKtJV2Z/2dsb2JhbABZgwc4U7k4ToEdFnSBeBIBGgEBAQMBAQEBNzQLBQsCAQgYHhAnCyUCBA4Fh3sGDcA9F4Z/hxY6MweDIIETA4VokiySE4Mpgio X-IronPort-AV: E=Sophos;i="4.93,782,1378857600"; d="scan'208";a="284894865" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 27 Nov 2013 14:53:19 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rARErInb030342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 14:53:18 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 08:53:18 -0600 From: "Cullen Jennings (fluffy)" To: Adam Roach Thread-Topic: [rtcweb] Proposed Video Selection Process Thread-Index: AQHO64BnAeeozn/0CECMWetiwkXodQ== Date: Wed, 27 Nov 2013 14:53:17 +0000 Message-ID: References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> <528EBAB0.2010906@librevideo.org> <528EBD4C.8070504@librevideo.org> <02B96CE8-A6D9-4288-B052-FB54B07447FB@apple.com> <528FCA68.2070309@googlemail.com> <528FE08B.1020908@nostrum.com> In-Reply-To: <528FE08B.1020908@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <6B8A74CF61AFD445ABB5F58EA7CA668C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 14:53:23 -0000 Adam, thought I agree with your meta point about submarine patents existed = in the past, I don' think you have this quite right on the details on this = one.=20 For US patents applications filed prior to June 8, 1995, the term is either= 17 years from date of issue or 20 years from earliest priority date, which= ever is later. For applications filed after June 8, 1995, the term is 20 ye= ars from the earliest priority date. Given this was filed after 1995, it expires 20 years after the priority dat= e so it expired in 2012.=20 On Nov 22, 2013, at 3:54 PM, Adam Roach wrote: > On 11/22/13 15:19, Maik Merten wrote: >> It is hard to come up with a scenario where patents covering the origina= l standard and original reference implementation would still be enforceable= .=20 >=20 > As a specific example of such a scenario -- one that is tantalizingly clo= se to the subject at hand -- look here: >=20 > http://www.google.com/patents/US7376184 >=20 > Read the first paragraph of the description. In layman's terms, it says "= even though this patent is being issued in 2008, we claim that it was inven= ted in January of 1992." And with a priority date prior to 1995, this means= that they have protection for seventeen years from the date of issuance (i= .e., until 2025). >=20 > Yes, this means that they have patent protection on this specific techniq= ue for 33 years after its invention. >=20 > In US courts, this is 100% legal and fully enforceable, since they starte= d the process prior to 1995. And "prior to 1995" is exactly when we're talk= ing about. >=20 > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From lgeyser@gmail.com Wed Nov 27 07:21:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD1C1AC862 for ; Wed, 27 Nov 2013 07:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOK9igQGBbSL for ; Wed, 27 Nov 2013 07:21:47 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id D5E281A1F1A for ; Wed, 27 Nov 2013 07:21:46 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ey16so2202153wid.6 for ; Wed, 27 Nov 2013 07:21:45 -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=X/QjAXZr4jcqMqVE145v2oG5EqJqfCNmFXixhDpLRn4=; b=Mll/zoEYCwlTNYPvYQiDNJzK9EjBBUUKENbpy/ZjAU9dMPm859jHzewJzr0HYC8LBW Kab0D7nAUFRf63Vy+yvdAh2ejw8SQX56Bod8yNWkAgL/dlG9yY+edxhVYrR2sSwvqrKf jTh0PsAPHbLf/5v+d7BOWgSzlDs8AjzBAdCmWsn9zR8rQZIQamp0BJZ8eaK+7uK0dhaG vr/VMt7ndRLVg5moUOQKnwWZ/d8UuQdiiP+B1t2nKCf4Bi6DUtwi8DYmvtkrZEhDwI46 WW/CTwT841nD91OhP3LgcKcRh3bkxPYDRL4/E/BTBhYoIMpeuj+exgHC7ejcJwN1EntW 2dVA== MIME-Version: 1.0 X-Received: by 10.180.187.72 with SMTP id fq8mr23384404wic.26.1385565705838; Wed, 27 Nov 2013 07:21:45 -0800 (PST) Received: by 10.227.9.5 with HTTP; Wed, 27 Nov 2013 07:21:45 -0800 (PST) In-Reply-To: <5295F718.9010603@ericsson.com> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> Date: Wed, 27 Nov 2013 17:21:45 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2679cb5a46204ec2a2753 Cc: Thomas Reisinger Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 15:21:53 -0000 --001a11c2679cb5a46204ec2a2753 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why don't we keep CBP on each H.264 entry? It will be more clear for the voter for what they are actually voting for, My opinions on some of the options: Personally I feel there are too many options :) 1 and 2: Was already debated so I don't know why we should list them again. 3: Might be too difficult to follow resulting in people breaking the spec anyway. 5: Actually implies 7. 7: Fail 8: I know I suggested this one, but 10 is actually nearly the same and is a better option. Votes might get split between the two resulting in another option taking lead. Is my thinking wrong? 11: Is H.263 really safe? 12: Do we know if you only implement a decoder that royalties won't apply? On 27 November 2013 15:43, Magnus Westerlund wrote: > On 2013-11-27 14:16, Thomas Reisinger wrote: > > Magnus, > > > > Could you please share the latest list and how the voting will be > conducted/what's required to vote. > > For the proposed voting process see our previous message > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html > > As I stated, we chairs will need to update this based on the discussion. > > For the current list of alternatives is on the WG's wiki: > http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart > > > Reproduced here: > The following alternatives has been proposed: > > 1. All entities MUST support H.264 > 2. All entities MUST support VP8 > 3. All entities MUST support both H.264 and VP8 > 4. Browsers MUST support both H.264 and VP8, other entities MUST > support at least one of H.264 and VP8 > 5. All entities MUST support at least one of H.264 and VP8 > 6. All entities MUST support H.261 > 7. There is no MTI video codec > 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST > support at least one of H.264 and VP8 > 9. All entities MUST support Theora > 10. All entities MUST implement at least two of {VP8, H.264, H.261} > 11. All entities MUST implement at least two of {VP8, H.264, H.263} > 12. All entities MUST support decoding using both H.264 and VP8, and > MUST support encoding using at least one of H.264 or VP8 > > H.264 is a reference to the proposal in=20 > https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ > > VP8 is a reference to the proposal in=20 > https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/ > > > > > > > Cheers, > > > > Thomas Reisinger > > > >> On 27.11.2013, at 09:50, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> > >>> On 2013-11-25 20:51, Markus.Isomaki@nokia.com wrote: > >>> MUST implement at least two of {VP8, H.264 CBP, H.261} > >> > >> I have now updated the list to read: > >> > >> 10. All entities MUST implement at least two of {VP8, H.264 CBP, H.261= } > >> 11. All entities MUST implement at least two of {VP8, H.264 CBP, H.263= } > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> ---------------------------------------------------------------------- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >> ---------------------------------------------------------------------- > >> > >> > > > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --001a11c2679cb5a46204ec2a2753 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Why don't we keep CBP on each H.264 entry? I= t will be more clear for the voter for what they are actually voting for,

My opinions on some of the options:
Personally I = feel there are too many options :)
1 and 2: Was already debated so I don't know why we should l= ist them again.
3: Might be too difficult to follow resulting in people breaking= the spec anyway.
5: Actually implies 7.
7: Fai= l
8: I know I suggested this one, but 10 is actually nearly t= he same and is a better option. Votes might get split between the two resul= ting in another option taking lead. Is my thinking wrong?
11: Is H.263 really safe?
12: Do we know if you on= ly implement a decoder that royalties won't apply?

<= div class=3D"gmail_extra">

On 27 November= 2013 15:43, Magnus Westerlund <magnus.westerlund@ericsson.co= m> wrote:
On 2013-11-27 14:16, Thoma= s Reisinger wrote:
> Magnus,
>
> Could you please share the latest list and how the voting will be cond= ucted/what's required to vote.

For the proposed voting process see our previous message
http://www.ietf.org/mail-archive/web/rtcweb/current/ms= g09909.html

As I stated, we chairs will need to update this based on the discussion.
For the current list of alternatives is on the WG's wiki:
http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart

Reproduced here:
=A0The following alternatives has been proposed:

=A01. All entities MUST support H.264
=A02. All entities MUST support VP8
=A03. All entities MUST support both H.264 and VP8
=A04. Browsers MUST support both H.264 and VP8, other entities MUST
=A0 =A0 support at least one of H.264 and VP8
=A05. All entities MUST support at least one of H.264 and VP8
=A06. All entities MUST support H.261
=A07. There is no MTI video codec
=A08. 5+6, i.e. All entities MUST support H.261 and all entities MUST
=A0 =A0 support at least one of H.264 and VP8
=A09. All entities MUST support Theora
10. All entities MUST implement at least two of {VP8, H.264, H.261}
11. All entities MUST implement at least two of {VP8, H.264, H.263}
12. All entities MUST support decoding using both H.264 and VP8, and
=A0 =A0 MUST support encoding using at least one of H.264 or VP8

H.264 is a reference to the proposal in
https://datatracker.ietf.org/doc/draft-burman-rtcweb= -h264-proposal/

VP8 is a reference to the proposal in
https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-v= p8/



>
> Cheers,
>
> Thomas Reisinger
>
>> On 27.11.2013, at 09:50, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote= :
>>
>>> On 2013-11-25 20:51, Markus.Isomaki@nokia.com wrote:
>>> MUST implement at least two of {VP8, H.264 CBP, H.261}
>>
>> I have now updated the list to read:
>>
>> 10. All entities MUST implement at least two of {VP8, H.264 CBP, H= .261}
>> 11. All entities MUST implement at least two of {VP8, H.264 CBP, H= .263}
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ------------------------------------------------------------------= ----
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ------------------------------------------------------------------= ----
>> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 71482= 87
>> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 094= 9079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>> ------------------------------------------------------------------= ----
>>
>>
>
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--001a11c2679cb5a46204ec2a2753-- From stewe@stewe.org Wed Nov 27 07:22:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B4B1AC862 for ; Wed, 27 Nov 2013 07:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOhhz29MvDPY for ; Wed, 27 Nov 2013 07:22:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0151.outbound.protection.outlook.com [207.46.163.151]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFC31AC829 for ; Wed, 27 Nov 2013 07:22:32 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 27 Nov 2013 15:22:29 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.113]) with mapi id 15.00.0820.005; Wed, 27 Nov 2013 15:22:28 +0000 From: Stephan Wenger To: "Cullen Jennings (fluffy)" , Adam Roach Thread-Topic: [rtcweb] Proposed Video Selection Process Thread-Index: AQHO5tnk2wfNffVCI02rNFBZREEO/pov+9iAgAACNgCAAAr/gIAABK+AgAAYwYCAAAHxAIAAAPyAgAARmQCAAAD1AIAAMeGAgAAE/oCAAAJigIAACkAAgAABfoCAAAGeAIAAAhYAgAEo7oCAABXKAIAAGmOAgAdVVYD//4IDgA== Date: Wed, 27 Nov 2013 15:22:27 +0000 Message-ID: References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> <528EBAB0.2010906@librevideo.org> <528EBD4C.8070504@librevideo.org> <02B96CE8-A6D9-4288-B052-FB54B07447FB@apple.com> <528FCA68.2070309@googlemail.com> <528FE08B.1020908@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.60.27.131] x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(479174003)(377454003)(51704005)(199002)(189002)(74366001)(36756003)(81816001)(76786001)(2656002)(87936001)(51856001)(50986001)(81342001)(54356001)(81542001)(76482001)(81686001)(46102001)(15975445006)(53806001)(56816003)(76796001)(56776001)(85306002)(80976001)(83072001)(15202345003)(74706001)(74876001)(4396001)(77982001)(19580405001)(59766001)(83322001)(19580395003)(65816001)(80022001)(66066001)(63696002)(79102001)(49866001)(74662001)(69226001)(47976001)(87266001)(54316002)(74502001)(31966008)(77096001)(47736001)(47446002)(6234004)(42262001)(16940595002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:75.60.27.131; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <239F0E8A3CCE5542854C3BC70FD5DEF2@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 15:22:38 -0000 Cullen, You missed the patent term adjustment of 487 days in this case--a very short adjustment period for a video coding patent (see note on over page right below the assignees). Note that this PTA is occasionally adjusted upwards after printing of the cover page (quite often actually for standards essential cases), which is recorded in the file wrapper and usually (but not always) in a certificate of correction. The patent in question is currently being litigated in an MPEG-2 context, and I have heard that the question of PTA has come up (though I do not know any details). Stephan =20 On 11.27.2013, 06:53 , "Cullen Jennings (fluffy)" wrote: > >Adam, thought I agree with your meta point about submarine patents >existed in the past, I don' think you have this quite right on the >details on this one. > >For US patents applications filed prior to June 8, 1995, the term is >either 17 years from date of issue or 20 years from earliest priority >date, whichever is later. For applications filed after June 8, 1995, the >term is 20 years from the earliest priority date. > >Given this was filed after 1995, it expires 20 years after the priority >date so it expired in 2012. > > > >On Nov 22, 2013, at 3:54 PM, Adam Roach wrote: > >> On 11/22/13 15:19, Maik Merten wrote: >>> It is hard to come up with a scenario where patents covering the >>>original standard and original reference implementation would still be >>>enforceable.=20 >>=20 >> As a specific example of such a scenario -- one that is tantalizingly >>close to the subject at hand -- look here: >>=20 >> http://www.google.com/patents/US7376184 >>=20 >> Read the first paragraph of the description. In layman's terms, it says >>"even though this patent is being issued in 2008, we claim that it was >>invented in January of 1992." And with a priority date prior to 1995, >>this means that they have protection for seventeen years from the date >>of issuance (i.e., until 2025). >>=20 >> Yes, this means that they have patent protection on this specific >>technique for 33 years after its invention. >>=20 >> In US courts, this is 100% legal and fully enforceable, since they >>started the process prior to 1995. And "prior to 1995" is exactly when >>we're talking about. >>=20 >> /a >> _______________________________________________ >> 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 From fluffy@cisco.com Wed Nov 27 07:23:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4031AE076 for ; Wed, 27 Nov 2013 07:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.502 X-Spam-Level: X-Spam-Status: No, score=-109.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oy5_eIUXyV5 for ; Wed, 27 Nov 2013 07:23:50 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 95C4A1ACCE2 for ; Wed, 27 Nov 2013 07:23:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1118; q=dns/txt; s=iport; t=1385565830; x=1386775430; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GKtyo4xwKNsSH98LvYCR+BlSzxg6wBhwQfkMTIefMMo=; b=BBJfMp3ayXxw8x07GdOnN6oX6o04rJbsR/EPdEmKKiCrLXZKvEiPGX7R Ld4f7fwgRa3X/RG2ObsjxRzMCAHCJrh+2TqxjcEbZ+Shp3Fz2DHkBTeRa f90Qf53OXVVWTWkaq/b11yRXiBvj3EZ/HaQdjR4Lv2dTXH0m4W8Drxmc2 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAOsNllKtJV2d/2dsb2JhbABZgweBC7lAgR0WdIImAQEEeRACAQhGMiUCBA4FiAHAPReOKyQzB4MggRMDmBSSE4MpgWlB X-IronPort-AV: E=Sophos;i="4.93,782,1378857600"; d="scan'208";a="2671650" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 27 Nov 2013 15:23:49 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rARFNnuZ011955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 15:23:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 09:23:49 -0600 From: "Cullen Jennings (fluffy)" To: cowwoc Thread-Topic: [rtcweb] H.261 Thread-Index: AQHO64Sr/l9V2MkxaEONbIXXAbyvmQ== Date: Wed, 27 Nov 2013 15:23:49 +0000 Message-ID: References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> In-Reply-To: <5295828A.4050506@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3C3536E181E9A443AB2687CCFEFBE5FA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 15:23:58 -0000 On Nov 26, 2013, at 10:26 PM, cowwoc wrote: >>=20 >> 3. I asked for the ability to license multiple units at a time so we dep= loy images and applications without a separate plugin/download process. >>=20 >> StW: if this is related to MPEG-LA (and not to the Cisco download mechan= ism) the answer is simple. You, as an MPEG-LA sublicensee, are responsible= for the correct accounting of the number of codecs you =93sell=94 (where = =93sell=94 includes things like free download etc.). MPEG-LA has the right= to audit you, and if they do and you are found cheating, then there are p= rovisions for penalties. /StW >=20 > Good point. I guess I am asking about Cisco's mechanism, since it is the = one that we will be bound by. I guess this would be much simpler if Cisco h= it the licensing upper limit, because then we wouldn't need to keep on coun= ting. >=20 > Gili Cisco is going to pay the cap - not because we think counting is hard (even= CDNs allow easy counting) - but because we believe that the Firefox usage = alone will greatly exceed the cap.=20 From fluffy@cisco.com Wed Nov 27 07:28:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4277F1AE0A2 for ; Wed, 27 Nov 2013 07:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.501 X-Spam-Level: X-Spam-Status: No, score=-114.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iN7TZshpq4oa for ; Wed, 27 Nov 2013 07:28:53 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 948511AE030 for ; Wed, 27 Nov 2013 07:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3078; q=dns/txt; s=iport; t=1385566133; x=1386775733; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tSstdAtzOuQAg04w9oF/x2MMwpjrqMPmnax55FNYsac=; b=kp683l62Lm7IPwgbAUC/auA3dGDyUGpDNBQs4hCL/Qq86WiajkgG5jSX o5AU5DHrEJPi3oAiS4B3aBQHhNYhapwqtnn1TdBr5zzV3bLlbfpaBLeDy S/GMVRFzM9VGXkIBnYSB9tCVh8gdzN08qo+ZxIcZclBG/ppcfsA5dHWHG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMKAFAPllKtJV2b/2dsb2JhbABZgwc4U7hxToEdFnSBeBIBGgEBAQMBAQEBNzQLBQsCAQgOCh4QJwslAgQOBYd7Bg3ALheGf4cWOjMHgyCBEwOFaJIskhODKYIq X-IronPort-AV: E=Sophos;i="4.93,782,1378857600"; d="scan'208";a="287864024" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 27 Nov 2013 15:28:30 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rARFSTOw010630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 15:28:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 09:28:29 -0600 From: "Cullen Jennings (fluffy)" To: Stephan Wenger Thread-Topic: [rtcweb] Proposed Video Selection Process Thread-Index: AQHO5tnkAeeozn/0CECMWetiwkXodZov+9iAgAACNgCAAAr/gIAABK+AgAAYwYCAAAHxAIAAAPyAgAARmQCAAAD1AIAAMeGAgAAE/oCAAAJigIAACkAAgAABfoCAAAGeAIAAAhYAgAEo7oCAABXKAIAAGmOAgAdVVYD//4IDgIAA7GcA Date: Wed, 27 Nov 2013 15:28:28 +0000 Message-ID: <23F7A503-6F95-4472-B68F-BA36B6BCCAA9@cisco.com> References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> <528EBAB0.2010906@librevideo.org> <528EBD4C.8070504@librevideo.org> <02B96CE8-A6D9-4288-B052-FB54B07447FB@apple.com> <528FCA68.2070309@googlemail.com> <528FE08B.1020908@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed Video Selection Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 15:28:57 -0000 fair enough - I did not look at any of the file wrapper information=20 On Nov 27, 2013, at 8:22 AM, Stephan Wenger wrote: > Cullen, > You missed the patent term adjustment of 487 days in this case--a very > short adjustment period for a video coding patent (see note on over page > right below the assignees). Note that this PTA is occasionally adjusted > upwards after printing of the cover page (quite often actually for > standards essential cases), which is recorded in the file wrapper and > usually (but not always) in a certificate of correction. > The patent in question is currently being litigated in an MPEG-2 context, > and I have heard that the question of PTA has come up (though I do not > know any details). > Stephan >=20 >=20 >=20 >=20 > On 11.27.2013, 06:53 , "Cullen Jennings (fluffy)" wrot= e: >=20 >>=20 >> Adam, thought I agree with your meta point about submarine patents >> existed in the past, I don' think you have this quite right on the >> details on this one. >>=20 >> For US patents applications filed prior to June 8, 1995, the term is >> either 17 years from date of issue or 20 years from earliest priority >> date, whichever is later. For applications filed after June 8, 1995, the >> term is 20 years from the earliest priority date. >>=20 >> Given this was filed after 1995, it expires 20 years after the priority >> date so it expired in 2012. >>=20 >>=20 >>=20 >> On Nov 22, 2013, at 3:54 PM, Adam Roach wrote: >>=20 >>> On 11/22/13 15:19, Maik Merten wrote: >>>> It is hard to come up with a scenario where patents covering the >>>> original standard and original reference implementation would still be >>>> enforceable.=20 >>>=20 >>> As a specific example of such a scenario -- one that is tantalizingly >>> close to the subject at hand -- look here: >>>=20 >>> http://www.google.com/patents/US7376184 >>>=20 >>> Read the first paragraph of the description. In layman's terms, it says >>> "even though this patent is being issued in 2008, we claim that it was >>> invented in January of 1992." And with a priority date prior to 1995, >>> this means that they have protection for seventeen years from the date >>> of issuance (i.e., until 2025). >>>=20 >>> Yes, this means that they have patent protection on this specific >>> technique for 33 years after its invention. >>>=20 >>> In US courts, this is 100% legal and fully enforceable, since they >>> started the process prior to 1995. And "prior to 1995" is exactly when >>> we're talking about. >>>=20 >>> /a >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Wed Nov 27 07:31:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D5F1ACC8A for ; Wed, 27 Nov 2013 07:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v23kgt-adkjk for ; Wed, 27 Nov 2013 07:30:59 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 32F161AE030 for ; Wed, 27 Nov 2013 07:30:54 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-22-5296102d5e50 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 27.DB.23787.D2016925; Wed, 27 Nov 2013 16:30:54 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.328.9; Wed, 27 Nov 2013 16:30:53 +0100 Message-ID: <5296102D.9030607@ericsson.com> Date: Wed, 27 Nov 2013 16:30:53 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Leon Geyser , "rtcweb@ietf.org" References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvra6ewLQggxPL2Sy6V89iszj/dxGb xdp/7ewWrS+3sTmweOycdZfdY8mSn0wed29dYgpgjuKySUnNySxLLdK3S+DKaP9zmK3grWbF r0tn2RoYd8h3MXJySAiYSEzpecYMYYtJXLi3nq2LkYtDSOAQo8TCjrdQznJGiUfbd7KAVPEK aEtsW/SQCcRmEVCVmHprEyOIzSZgIXHzRyMbiC0qECxxtXcdM0S9oMTJmU/AekUEPCRmXFvN 2sXIwcEskCZx8Ws1SFhYwEtiycM57BC7JjFL/Ph8iR0kwSkQKPFs6gxmkHoJAXGJnsYgkDCz gJ7ElKstjBC2vETz1tlgq4SATmto6mCdwCg0C8nmWUhaZiFpWcDIvIqRPTcxMye93HATIzCQ D275rbuD8dQ5kUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgzFVgVbB8 umaV9yUrhegmfYO3WSG8ChLvVC3U7qxX3/BGLv/9YWPFTLv5dyO3KPV/LrEIYvu04uwhVaep P1vdnRoUj0ilHBKZU7zz/QXW9H1yN1jj3vC9kTov6n0iyHfljVn592+t2nTjZW7gJQ2uKccq FFzPXb1/vqL3wTuN0LQP/zP2vFYXU2Ipzkg01GIuKk4EAJSXecIyAgAA Cc: Thomas Reisinger Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 15:31:14 -0000 On 2013-11-27 16:21, Leon Geyser wrote: > Why don't we keep CBP on each H.264 entry? It will be more clear for the > voter for what they are actually voting for, Because, the H.264 proposal draft defines it to be CBP, and no one to my understanding has made another proposal. Thus, I think a general clarification through the reference is clearer. /Magnus > > My opinions on some of the options: > Personally I feel there are too many options :) > 1 and 2: Was already debated so I don't know why we should list them again. > 3: Might be too difficult to follow resulting in people breaking the > spec anyway. > 5: Actually implies 7. > 7: Fail > 8: I know I suggested this one, but 10 is actually nearly the same and > is a better option. Votes might get split between the two resulting in > another option taking lead. Is my thinking wrong? > 11: Is H.263 really safe? > 12: Do we know if you only implement a decoder that royalties won't apply? > > > > On 27 November 2013 15:43, Magnus Westerlund > > > wrote: > > On 2013-11-27 14:16, Thomas Reisinger wrote: > > Magnus, > > > > Could you please share the latest list and how the voting will be > conducted/what's required to vote. > > For the proposed voting process see our previous message > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html > > As I stated, we chairs will need to update this based on the discussion. > > For the current list of alternatives is on the WG's wiki: > http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart > > > Reproduced here: > The following alternatives has been proposed: > > 1. All entities MUST support H.264 > 2. All entities MUST support VP8 > 3. All entities MUST support both H.264 and VP8 > 4. Browsers MUST support both H.264 and VP8, other entities MUST > support at least one of H.264 and VP8 > 5. All entities MUST support at least one of H.264 and VP8 > 6. All entities MUST support H.261 > 7. There is no MTI video codec > 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST > support at least one of H.264 and VP8 > 9. All entities MUST support Theora > 10. All entities MUST implement at least two of {VP8, H.264, H.261} > 11. All entities MUST implement at least two of {VP8, H.264, H.263} > 12. All entities MUST support decoding using both H.264 and VP8, and > MUST support encoding using at least one of H.264 or VP8 > > H.264 is a reference to the proposal in > https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ > > VP8 is a reference to the proposal in > https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/ > > > > > > > Cheers, > > > > Thomas Reisinger > > > >> On 27.11.2013, at 09:50, Magnus Westerlund > > wrote: > >> > >>> On 2013-11-25 20:51, Markus.Isomaki@nokia.com > wrote: > >>> MUST implement at least two of {VP8, H.264 CBP, H.261} > >> > >> I have now updated the list to read: > >> > >> 10. All entities MUST implement at least two of {VP8, H.264 CBP, > H.261} > >> 11. All entities MUST implement at least two of {VP8, H.264 CBP, > H.263} > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> > ---------------------------------------------------------------------- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> > ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> Färögatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden| mailto: > magnus.westerlund@ericsson.com > >> > ---------------------------------------------------------------------- > >> > >> > > > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > > Färögatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tim@phonefromhere.com Wed Nov 27 08:03:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B211D1ACCE9 for ; Wed, 27 Nov 2013 08:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTa0VEMtwZOf for ; Wed, 27 Nov 2013 08:03:36 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id 9639F1ACCE8 for ; Wed, 27 Nov 2013 08:03:36 -0800 (PST) Received: (qmail 9307 invoked from network); 27 Nov 2013 16:03:35 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10453 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 27 Nov 2013 16:03:35 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id CCAAC18A0243; Wed, 27 Nov 2013 16:03:34 +0000 (GMT) Received: from [192.168.157.132] (unknown [192.67.4.35]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7A2B418A01E0; Wed, 27 Nov 2013 16:03:34 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: tim panton In-Reply-To: <5295828A.4050506@bbs.darktech.org> Date: Wed, 27 Nov 2013 16:03:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1822) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 16:03:39 -0000 On 27 Nov 2013, at 05:26, cowwoc wrote: > On 27/11/2013 12:07 AM, Stephan Wenger wrote: >> If I recall correctly, someone asked for a more concrete definition = of a licensing "unit". >> StW: I do not recall the context, but MPEG-LA licenses (in addition = to content, which is not at issue here) a thing called =93codec=94, = which is defined as one encoder, one decoder, or one encoder and one = decoder. /StW >=20 > I don't think that answers the question. It was my understanding they = were asking what constitutes one unit (out of the 100k free units we are = allowed per year). For example, should we be counting the number of = installs? Or number of concurrent users (e.g. what happens when a user = installs the software on 5 machines but only runs one at a time?)? Or = number of downloads? What happens if the same user downloads the app 100 = times? When users uninstall the app, do we get a unit back? The point = is, we need a very concrete definition of how to count units. Or even more fun, if you install an update of the app, say once a month, = that=92s 12 units per year per user - Or am I misunderstanding the = =91unit=92 thing? T. From tim@phonefromhere.com Wed Nov 27 08:05:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B421ACCE8 for ; Wed, 27 Nov 2013 08:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm8UB8uQobLn for ; Wed, 27 Nov 2013 08:05:48 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id 960C31A1F5D for ; Wed, 27 Nov 2013 08:05:48 -0800 (PST) Received: (qmail 15531 invoked from network); 27 Nov 2013 16:05:47 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10495 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 27 Nov 2013 16:05:47 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 624FA18A06E1; Wed, 27 Nov 2013 16:05:47 +0000 (GMT) Received: from [192.168.157.132] (unknown [192.67.4.35]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 0BF3B18A0461; Wed, 27 Nov 2013 16:05:46 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: tim panton In-Reply-To: <3132244A-FCB5-4C1F-86F1-E0897C47BCDA@nostrum.com> Date: Wed, 27 Nov 2013 16:05:46 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <47C40788-131C-4CFC-944F-7DD2B5BC4AED@phonefromhere.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> <3132244A-FCB5-4C1F-86F1-E0897C47BCDA@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1822) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 16:05:51 -0000 On 27 Nov 2013, at 05:53, Adam Roach wrote: >=20 >=20 > On Nov 26, 2013, at 23:26, cowwoc wrote: >=20 >> I guess I am asking about Cisco's mechanism, since it is the one that = we will be bound by. I guess this would be much simpler if Cisco hit the = licensing upper limit, because then we wouldn't need to keep on = counting. >=20 > If you use Cisco's binary, you don't have to count. Cisco takes care = if that for you. As far as I understand, they are paying the cap, but = that fact doesn't make any difference to you one way or another. The = important thing is that Cisco is distributing the codec, and Cisco is = bearing the costs for making sure that anything it distributes is = properly licensed.=20 Unless or until one of your users uses your app for a purpose that isn=92t= covered by Cisco=92s license grant, at which point you=92d better be able to count users by usage type = _really_ fast. T. >=20 > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From gmartincocher@blackberry.com Wed Nov 27 08:29:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E579A1AC829 for ; Wed, 27 Nov 2013 08:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjazIdZ9BJKL for ; Wed, 27 Nov 2013 08:29:08 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id DA8871A1F7C for ; Wed, 27 Nov 2013 08:29:07 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 Nov 2013 11:28:58 -0500 Received: from XCT104CNC.rim.net (10.65.161.204) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 11:28:58 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 11:28:58 -0500 From: Gaelle Martin-Cocher To: Magnus Westerlund , Emil Ivov Thread-Topic: [rtcweb] Last day for any additional Video Codec Selection alternatives Thread-Index: AQHO606Vpz1RIQde60qEONvclkDthZo5SFkAgAAOW4D//+lHUA== Date: Wed, 27 Nov 2013 16:28:57 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AA548ADD3C@XMB111CNC.rim.net> References: <5295B358.1040302@ericsson.com> <5295DA58.60504@jitsi.org> <5295E663.4020607@ericsson.com> In-Reply-To: <5295E663.4020607@ericsson.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 16:29:10 -0000 Dear All, Sorry for this late message, I was not available this past week. It has been mentioned by a few of us that the risks on VP8 that some can't = leave with, can be mitigated when VP8 becomes an ISO standard (via MPEG). = VP8 has a chance to become an MPEG deliverable in January. I believe that c= ould make a few of us more comfortable with supporting/mandating both H264 = and VP8 and could change the consensus reaching process. Can we give VP8 that chance before forcing a vote? Thanks Sincerely, Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: Wednesday, November 27, 2013 7:33 AM To: Emil Ivov Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alt= ernatives On 2013-11-27 12:41, Emil Ivov wrote: > Just to confirm, this is NOT the last day of discussion on whether a = > vote is the right way to do this at all, right? No, but tomorrow a week will have passed since we chairs sent out the propo= sal and solicited feedback on the proposal. > = > That sounds like it would still be an open question for step two here: > = > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html As we stated in this message, after the week we chairs would update the pro= cess proposal if we considered it necessary. I believe there are some clari= fications that needs to be done, including the voter eligibility. After that the stated plan was to hold a consensus call in the WG to use th= e proposed process. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From ron@debian.org Wed Nov 27 08:31:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49831ACCE8 for ; Wed, 27 Nov 2013 08:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiNOu-7X4tgC for ; Wed, 27 Nov 2013 08:30:59 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id B3D3E1AC829 for ; Wed, 27 Nov 2013 08:30:58 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 28 Nov 2013 03:00:57 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 5E3B24F8F3 for ; Thu, 28 Nov 2013 02:55:53 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G0ICrRHwsLge for ; Thu, 28 Nov 2013 02:55:52 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 6CDB44F902; Thu, 28 Nov 2013 02:55:52 +1030 (CST) Date: Thu, 28 Nov 2013 02:55:52 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131127162552.GP3245@audi.shelbyville.oz> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 16:31:00 -0000 On Wed, Nov 27, 2013 at 03:30:55AM +0000, Cullen Jennings (fluffy) wrote: > I do get they MPEG LA terms can be confusing at times > but lots of people have figured it out. I can only assume that you mean this in the same sense that "lots of people" have "figured out" those click through EULA conditions that don't actually allow them to do the things they'll be doing but obviously aren't intended to be read since a 50 page document is presented in a 4 line scroll box with no button that says "click here to send this to your lawyer". [1] Like the ones that say your TV can report everything that's ever watched on it to the manufacturer, even after you click the Don't Do That button. [2] Or in the same sense that they drive their motor vehicles without complying with their legal obligation to keep a bale of hay in the trunk or have some person walk in front at all times waving a flag. A licence that says "we'll take your money, but we can't actually grant you the rights to use this since we don't own or control them - we'll just sort of promise that WE won't drag you through the courts, in exchange for being able to track exactly how profitable your business is" -- isn't a licence at all. It's a protection racket. With a dash of industrial espionage thrown in for good measure. This isn't something we should be booby trapping IETF standards with. The IETF has disclosure rules that are aimed at avoiding, so much as is possible, this sort of Don't ask Don't tell nonsense. And yet we *still* don't have disclosures from the H.264 IPR holders that *are* present here for the use of H.264 in this standard. Despite them having core dumped their IPR restrictions on alternative proposals. How can we possibly take mandating that technology seriously in this light? That alone should already rule this out from consideration. > If people have questions about specific use case I'm glad to try and get > them answers. The specific question about how the Cisco offer resolves the problem of MPEG LA not being the only holder of IPR that would need to be licenced has so far met with deafening silence. Glad answers to that would certainly be nice. People keep making claims about that offer "solving everything", which can't possibly be true unless you pretend those other licence holders don't exist. By comparison, Google at least has shown that it is *very* willing to do whatever is necessary to ensure that the licence and IPR of VP8 is very unambiguously exactly as they claim it to be. That seems a lot more reassuring than the state of denial that has surrounded promoting H.264. First pretending the IPR wasn't a problem, then pretending they could buy us all free tickets, then claiming they "really wished there was a solution with no IPR burden", then rejecting that solution when it was actually presented as a compromise. Then pushing for getting the IETF to vote ... The number of dimensions in which we'd have to disconnect from reality to make this proposal acceptable makes even string theory start to look well grounded. Ron [1] http://i.imgur.com/m0sQKZI.jpg [2] http://www.bbc.co.uk/news/technology-25042563 From sanjay.mishra@verizon.com Wed Nov 27 08:33:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2531AD7C0 for ; Wed, 27 Nov 2013 08:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gxbQYgKPi2I for ; Wed, 27 Nov 2013 08:33:44 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 55C351ACCDE for ; Wed, 27 Nov 2013 08:33:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 27 Nov 2013 16:33:43 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="4.93,783,1378857600"; d="scan'208";a="615496774" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi01.verizon.com with ESMTP; 27 Nov 2013 16:33:42 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 27 Nov 2013 11:33:41 -0500 To: Magnus Westerlund Date: Wed, 27 Nov 2013 11:33:41 -0500 Thread-Topic: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? Thread-Index: Ac7rdwHa+7lSAlvjRYaSNbRZ7l2ruwAFxtUw Message-ID: <900A1E2059ADB149B905E3C8FA0046A62C80B27806@FHDP1LUMXC7V23.us.one.verizon.com> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> In-Reply-To: <5295F718.9010603@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 16:33:46 -0000 TWFnbnVzIC0tIFRvIGNvbmZpcm0sIHRoZSB2b3RpbmcgcGVyaW9kIGlzIGJlIHR3byB3ZWVrcywg c28gSSBhbSBhc3N1bWluZyBzdGFydGluZyB0b21vcnJvdyAoTm92IDI4KSBhbmQgbGFzdGluZyBm b3IgdHdvIHdlZWtzIChEZWMgMTI/KS4NCg0KVGhhbmtzDQpTYW5qYXkNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE1hZ251cyBXZXN0ZXJsdW5kDQpTZW50OiBXZWRuZXNkYXksIE5vdmVt YmVyIDI3LCAyMDEzIDg6NDQgQU0NClRvOiBUaG9tYXMgUmVpc2luZ2VyDQpDYzogcnRjd2ViQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gVmlkZW8gQ29kZWMgU2VsZWN0aW9uIEFsdGVy bmF0aXZlcyAxMCBhbmQgMTE6IE1lcmdlPw0KDQpPbiAyMDEzLTExLTI3IDE0OjE2LCBUaG9tYXMg UmVpc2luZ2VyIHdyb3RlOg0KPiBNYWdudXMsDQo+IA0KPiBDb3VsZCB5b3UgcGxlYXNlIHNoYXJl IHRoZSBsYXRlc3QgbGlzdCBhbmQgaG93IHRoZSB2b3Rpbmcgd2lsbCBiZSBjb25kdWN0ZWQvd2hh dCdzIHJlcXVpcmVkIHRvIHZvdGUuDQoNCkZvciB0aGUgcHJvcG9zZWQgdm90aW5nIHByb2Nlc3Mg c2VlIG91ciBwcmV2aW91cyBtZXNzYWdlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9ydGN3ZWIvY3VycmVudC9tc2cwOTkwOS5odG1sDQoNCkFzIEkgc3RhdGVkLCB3ZSBjaGFp cnMgd2lsbCBuZWVkIHRvIHVwZGF0ZSB0aGlzIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uLg0KDQpG b3IgdGhlIGN1cnJlbnQgbGlzdCBvZiBhbHRlcm5hdGl2ZXMgaXMgb24gdGhlIFdHJ3Mgd2lraToN Cmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3J0Y3dlYi90cmFjL3dpa2kvV2lraVN0YXJ0 DQoNCg0KUmVwcm9kdWNlZCBoZXJlOg0KIFRoZSBmb2xsb3dpbmcgYWx0ZXJuYXRpdmVzIGhhcyBi ZWVuIHByb3Bvc2VkOg0KDQogMS4gQWxsIGVudGl0aWVzIE1VU1Qgc3VwcG9ydCBILjI2NA0KIDIu IEFsbCBlbnRpdGllcyBNVVNUIHN1cHBvcnQgVlA4DQogMy4gQWxsIGVudGl0aWVzIE1VU1Qgc3Vw cG9ydCBib3RoIEguMjY0IGFuZCBWUDggIDQuIEJyb3dzZXJzIE1VU1Qgc3VwcG9ydCBib3RoIEgu MjY0IGFuZCBWUDgsIG90aGVyIGVudGl0aWVzIE1VU1QNCiAgICBzdXBwb3J0IGF0IGxlYXN0IG9u ZSBvZiBILjI2NCBhbmQgVlA4ICA1LiBBbGwgZW50aXRpZXMgTVVTVCBzdXBwb3J0IGF0IGxlYXN0 IG9uZSBvZiBILjI2NCBhbmQgVlA4ICA2LiBBbGwgZW50aXRpZXMgTVVTVCBzdXBwb3J0IEguMjYx ICA3LiBUaGVyZSBpcyBubyBNVEkgdmlkZW8gY29kZWMgIDguIDUrNiwgaS5lLiBBbGwgZW50aXRp ZXMgTVVTVCBzdXBwb3J0IEguMjYxIGFuZCBhbGwgZW50aXRpZXMgTVVTVA0KICAgIHN1cHBvcnQg YXQgbGVhc3Qgb25lIG9mIEguMjY0IGFuZCBWUDggIDkuIEFsbCBlbnRpdGllcyBNVVNUIHN1cHBv cnQgVGhlb3JhIDEwLiBBbGwgZW50aXRpZXMgTVVTVCBpbXBsZW1lbnQgYXQgbGVhc3QgdHdvIG9m IHtWUDgsIEguMjY0LCBILjI2MX0gMTEuIEFsbCBlbnRpdGllcyBNVVNUIGltcGxlbWVudCBhdCBs ZWFzdCB0d28gb2Yge1ZQOCwgSC4yNjQsIEguMjYzfSAxMi4gQWxsIGVudGl0aWVzIE1VU1Qgc3Vw cG9ydCBkZWNvZGluZyB1c2luZyBib3RoIEguMjY0IGFuZCBWUDgsIGFuZA0KICAgIE1VU1Qgc3Vw cG9ydCBlbmNvZGluZyB1c2luZyBhdCBsZWFzdCBvbmUgb2YgSC4yNjQgb3IgVlA4DQoNCkguMjY0 IGlzIGEgcmVmZXJlbmNlIHRvIHRoZSBwcm9wb3NhbCBpbiDigIsgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtYnVybWFuLXJ0Y3dlYi1oMjY0LXByb3Bvc2FsLw0KDQpWUDgg aXMgYSByZWZlcmVuY2UgdG8gdGhlIHByb3Bvc2FsIGluIOKAiw0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtYWx2ZXN0cmFuZC1ydGN3ZWItdnA4Lw0KDQoNCg0KPiANCj4g Q2hlZXJzLA0KPiANCj4gVGhvbWFzIFJlaXNpbmdlcg0KPiANCj4+IE9uIDI3LjExLjIwMTMsIGF0 IDA5OjUwLCBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29t PiB3cm90ZToNCj4+DQo+Pj4gT24gMjAxMy0xMS0yNSAyMDo1MSwgTWFya3VzLklzb21ha2lAbm9r aWEuY29tIHdyb3RlOg0KPj4+IE1VU1QgaW1wbGVtZW50IGF0IGxlYXN0IHR3byBvZiB7VlA4LCBI LjI2NCBDQlAsIEguMjYxfQ0KPj4NCj4+IEkgaGF2ZSBub3cgdXBkYXRlZCB0aGUgbGlzdCB0byBy ZWFkOg0KPj4NCj4+IDEwLiBBbGwgZW50aXRpZXMgTVVTVCBpbXBsZW1lbnQgYXQgbGVhc3QgdHdv IG9mIHtWUDgsIEguMjY0IENCUCwgDQo+PiBILjI2MX0gMTEuIEFsbCBlbnRpdGllcyBNVVNUIGlt cGxlbWVudCBhdCBsZWFzdCB0d28gb2Yge1ZQOCwgSC4yNjQgDQo+PiBDQlAsIEguMjYzfQ0KPj4N Cj4+IENoZWVycw0KPj4NCj4+IE1hZ251cyBXZXN0ZXJsdW5kDQo+Pg0KPj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+PiAtIE11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZN DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBob25l ICArNDYgMTAgNzE0ODI4Nw0KPj4gRsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmls ZSArNDYgNzMgMDk0OTA3OQ0KPj4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVufCBtYWlsdG86 IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAtDQo+ Pg0KPj4NCj4gDQo+IA0KDQoNCi0tIA0KDQpNYWdudXMgV2VzdGVybHVuZA0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEw IDcxNDgyODcNCkbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5 NDkwNzkNClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From stewe@stewe.org Wed Nov 27 08:41:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCF01ADBF7 for ; Wed, 27 Nov 2013 08:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZRTHVv2eqS9 for ; Wed, 27 Nov 2013 08:41:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) by ietfa.amsl.com (Postfix) with ESMTP id B680A1ACCFE for ; Wed, 27 Nov 2013 08:41:37 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 27 Nov 2013 16:41:33 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.113]) with mapi id 15.00.0820.005; Wed, 27 Nov 2013 16:41:33 +0000 From: Stephan Wenger To: tim panton , cowwoc Thread-Topic: [rtcweb] H.261 Thread-Index: AQHO50Itstn9eh6B8EejB0XcQHHKMpoxfO0AgAADjQCAAAzFgIAABU2AgAAKLQCAAAdiAIAACBKAgAADOgCAAAJPgIAGwe6AgAACxID//5IBgIAAi4sAgACx+YD//4R3AA== Date: Wed, 27 Nov 2013 16:41:32 +0000 Message-ID: References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.60.27.131] x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(479174003)(377454003)(51704005)(199002)(189002)(74366001)(36756003)(81816001)(76786001)(2656002)(87936001)(51856001)(50986001)(54356001)(81342001)(76482001)(81542001)(81686001)(46102001)(53806001)(56816003)(76796001)(56776001)(85306002)(80976001)(83072001)(74706001)(74876001)(4396001)(77982001)(19580405001)(59766001)(83322001)(19580395003)(65816001)(80022001)(66066001)(63696002)(79102001)(49866001)(74662001)(69226001)(87266001)(54316002)(47976001)(74502001)(31966008)(77096001)(47736001)(47446002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:75.60.27.131; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 16:41:41 -0000 Hi, On 11.27.2013, 08:03 , "tim panton" wrote: > >On 27 Nov 2013, at 05:26, cowwoc wrote: > >> On 27/11/2013 12:07 AM, Stephan Wenger wrote: >>> If I recall correctly, someone asked for a more concrete definition of >>>a licensing "unit". >>> StW: I do not recall the context, but MPEG-LA licenses (in addition to >>>content, which is not at issue here) a thing called =B3codec=B2, which i= s >>>defined as one encoder, one decoder, or one encoder and one decoder. >>>/StW >>=20 >> I don't think that answers the question. It was my understanding they >>were asking what constitutes one unit (out of the 100k free units we are >>allowed per year). For example, should we be counting the number of >>installs? Or number of concurrent users (e.g. what happens when a user >>installs the software on 5 machines but only runs one at a time?)? Or >>number of downloads? What happens if the same user downloads the app 100 >>times? When users uninstall the app, do we get a unit back? The point >>is, we need a very concrete definition of how to count units. > >Or even more fun, if you install an update of the app, say once a month, >that=B9s 12 units per year per user - Or am I misunderstanding the =8Cunit= =B9 >thing? You guys are discussing MPEG-LA FAQ and agreement interpretations. Therein, there is no such thing as a =B3unit=B2 in the context you use it. When discussing hypothetical interpretations of an agreement text most of you obviously have never seen, let=B9s at least try to stick with terminology that is known to exist in the agreement. Broader point: I doubt very much that you will get an authoritive answer to the those broad interpretation questions from MPEG-LA, even if they were formulated in a precise and concise way (which, currently, they certainly are not). MPEG-LA commonly doesn't want to go public with their own interpretation of the agreement, and prefer to do so only with consent of the licensor group, which is harder to obtain than herding cats because of the very diverse nature of the licensor community. One motivation of this silence may be the fear of weakening the license by making public statements about its interpretation that may provide openings for sharp company lawyers to cheat out of their licensing obligations. It=B9s a common theme in the legal community: say as little as possible. What can be done, and is (so I understand) not uncommon, is that a company (a prospective licensee, but not a =B3community=B2) contacts MPEG-LA direct= ly, explains their business model, and asks how that fits within the agreement language. This process can result in a side letter that includes an interpretation of the agreement language tailored to the business model of the company. Those side letters are confidential. The agreement itself is AFAIK take it or leave it. Stephan > >T. > From tim@phonefromhere.com Wed Nov 27 09:02:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2D31ACC91 for ; Wed, 27 Nov 2013 09:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU0NS5M4oz9w for ; Wed, 27 Nov 2013 09:02:38 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id A42C61A1F6F for ; Wed, 27 Nov 2013 09:02:37 -0800 (PST) Received: (qmail 80152 invoked from network); 27 Nov 2013 17:02:36 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 11633 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 27 Nov 2013 17:02:36 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 514F418A0243; Wed, 27 Nov 2013 17:02:36 +0000 (GMT) Received: from [192.168.157.132] (unknown [192.67.4.35]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id EC84018A023A; Wed, 27 Nov 2013 17:02:35 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: tim panton In-Reply-To: Date: Wed, 27 Nov 2013 17:02:35 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6F64B67E-A22C-45F4-9986-63DAE582D6BF@phonefromhere.com> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> To: Stephan Wenger X-Mailer: Apple Mail (2.1822) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 17:02:40 -0000 On 27 Nov 2013, at 16:41, Stephan Wenger wrote: > Hi, >=20 > On 11.27.2013, 08:03 , "tim panton" wrote: >=20 >>=20 >> On 27 Nov 2013, at 05:26, cowwoc wrote: >>=20 >>> On 27/11/2013 12:07 AM, Stephan Wenger wrote: >>>> If I recall correctly, someone asked for a more concrete definition = of >>>> a licensing "unit". >>>> StW: I do not recall the context, but MPEG-LA licenses (in addition = to >>>> content, which is not at issue here) a thing called =B3codec=B2, = which is >>>> defined as one encoder, one decoder, or one encoder and one = decoder. >>>> /StW >>>=20 >>> I don't think that answers the question. It was my understanding = they >>> were asking what constitutes one unit (out of the 100k free units we = are >>> allowed per year). For example, should we be counting the number of >>> installs? Or number of concurrent users (e.g. what happens when a = user >>> installs the software on 5 machines but only runs one at a time?)? = Or >>> number of downloads? What happens if the same user downloads the app = 100 >>> times? When users uninstall the app, do we get a unit back? The = point >>> is, we need a very concrete definition of how to count units. >>=20 >> Or even more fun, if you install an update of the app, say once a = month, >> that=B9s 12 units per year per user - Or am I misunderstanding the = =8Cunit=B9 >> thing? >=20 > You guys are discussing MPEG-LA FAQ and agreement interpretations. > Therein, there is no such thing as a =B3unit=B2 in the context you use = it. > When discussing hypothetical interpretations of an agreement text most = of > you obviously have never seen, let=B9s at least try to stick with > terminology that is known to exist in the agreement. My example was lifted from the direct experience of a startup I know who were indeed charged license fees for every upgrade by the MPEG-LA.=20 They ended up shipping partial patches that re-used old binaries to avoid this issue. But you are correct I have not read the license. >=20 > Broader point: >=20 > I doubt very much that you will get an authoritive answer to the those > broad interpretation questions from MPEG-LA, even if they were = formulated > in a precise and concise way (which, currently, they certainly are = not). > MPEG-LA commonly doesn't want to go public with their own = interpretation > of the agreement, and prefer to do so only with consent of the = licensor > group, which is harder to obtain than herding cats because of the very > diverse nature of the licensor community. One motivation of this = silence > may be the fear of weakening the license by making public statements = about > its interpretation that may provide openings for sharp company lawyers = to > cheat out of their licensing obligations. It=B9s a common theme in = the > legal community: say as little as possible. >=20 > What can be done, and is (so I understand) not uncommon, is that a = company > (a prospective licensee, but not a =B3community=B2) contacts MPEG-LA = directly, > explains their business model, and asks how that fits within the = agreement > language. This process can result in a side letter that includes an > interpretation of the agreement language tailored to the business = model of > the company. Those side letters are confidential. The agreement = itself > is AFAIK take it or leave it. >=20 This is the kind of restrictive thinking that was common place before = the web. Back in the day, if you wanted to use the Nortel SDK, you had to apply = to use it, handing over a detailed app description and business model to them, which might or = might not be=20 =91accepted=92.=20 Tim. From martin.thomson@gmail.com Wed Nov 27 09:24:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625121AD79D for ; Wed, 27 Nov 2013 09:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X25pBItQX6GC for ; Wed, 27 Nov 2013 09:24:07 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15D1AD628 for ; Wed, 27 Nov 2013 09:24:07 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id k14so4555338wgh.22 for ; Wed, 27 Nov 2013 09:24:06 -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=gLwHjl/wcyEPDcrDNhx8Q2ucwCyztcx3IVw5YuqOh9M=; b=k00LnXTKA4Q7i0htwW2D6tNh88OSiYy+yRTk1E/nbPQ3mu3WToF2GN1CaSZPplnl0N g8kR7chKlmUQcUfaEXr5A0nVFXiER2EdivbhIWs0GvebtMnKWCg2oUJd6DtoI5++gsD7 QCdE2AljRfGsANZ4Wz3I/fQlKvZTHSmdpQWBErm61V/K7pDM5IQZwIX2uln/5IK6FLb1 cFeMdAd2gCTpmkQq3v31X7UCAV9by6/9XBQMRiJZLcbn28r4YxW4C1811qBYcUNSU+sT rpSN5KOxQgjMBBIyFxf/OfNCGZcpVNYzVvqhvLLhkYFw6uzuIzwH3uKzvWVJr2zvChVx 2E9Q== MIME-Version: 1.0 X-Received: by 10.194.94.167 with SMTP id dd7mr12698241wjb.43.1385573046589; Wed, 27 Nov 2013 09:24:06 -0800 (PST) Received: by 10.227.134.195 with HTTP; Wed, 27 Nov 2013 09:24:06 -0800 (PST) In-Reply-To: References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> Date: Wed, 27 Nov 2013 09:24:06 -0800 Message-ID: From: Martin Thomson To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 17:24:09 -0000 On 26 November 2013 18:06, Muthu Arul Mozhi Perumal (mperumal) wrote: > Are there cases where you won't do ICE but do DTLS, for WebRTC? If not, I think you can combine the best of both: > - The initial consent is established by ICE connectivity checks already. > - The receipt of any authenticated packet, including DTLS heartbeat, grants > you consent to send more packets. > - If you doesn't receive any packet and consent is about to expire, send a > STUN binding request that is comparatively less CPU intensive. > > Minimal overhead overall :) I disagree. One of the merits of using the DTLS handshake to establish initial consent, authenticated packets to maintain it, and the DTLS heartbeat in the absence of authenticated packets is that it is all DTLS. As someone who writes software, being able to keep all the logic constrained to a single software module is a significant improvement. I don't believe the CPU cost of a DTLS heartbeat to be expensive enough to justify changes to this. Given that you aren't using the CPU for crypto at all when you send it, I'm pretty sure that the CPU cost can be borne. From mperumal@cisco.com Wed Nov 27 09:38:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871121ADEB7 for ; Wed, 27 Nov 2013 09:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRZZLXSRqINw for ; Wed, 27 Nov 2013 09:38:06 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 19EF31AD628 for ; Wed, 27 Nov 2013 09:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2580; q=dns/txt; s=iport; t=1385573885; x=1386783485; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6j/Lk1qCf+FM01ztP7enz7wURIIWPtmMo1oxa49+c7k=; b=L6mDFdu2iD2uz1VUnbtm1omGVoo/hCSW/rvkgVATUOYENOJeKfVMdtc9 yOr/NnfiO/d6zwmtRgiXS9pEVNKR6IjyEOQFSyn+7Ez739XmZoUqUsJ1f GL6gidGTg8U4aaXQXWSXUhlVBWTR2W4BXFiZhhJteehZkoMiQd4eSrPpY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFANosllKtJV2c/2dsb2JhbABZgweBC4J6tUgYgQgWdIIlAQEBBCMRRQwEAgEIEQQBAQMCBh0DAgICHxEUAQgIAgQOBQiHZwMPrzaIaw2IAheBKYtIgWAWGwcGgmU1gRMDlimORYU5gymCKg X-IronPort-AV: E=Sophos;i="4.93,783,1378857600"; d="scan'208";a="2704364" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 27 Nov 2013 17:38:05 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rARHc5Jm016214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 17:38:05 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 11:38:04 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Martin Thomson Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 Thread-Index: AQHO65WAELUuQiNDn0uSYfT1pzheJ5o5VRlQ Date: Wed, 27 Nov 2013 17:38:04 +0000 Message-ID: References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.65.196] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 17:38:07 -0000 fC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQp8RnJvbTogTWFydGluIFRob21zb24gW21haWx0 bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dDQp8U2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAy NywgMjAxMyAxMDo1NCBQTQ0KfFRvOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFs KQ0KfENjOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBkcmFmdC1pZXRmLXJ0Y3dlYi1z dHVuLWNvbnNlbnQtZnJlc2huZXNzQHRvb2xzLmlldGYub3JnOw0KfHJ0Y3dlYkBpZXRmLm9yZw0K fFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBSRkMgNjUyMCB2cy4gZHJhZnQtaWV0Zi1ydGN3ZWItc3R1 bi1jb25zZW50LWZyZXNobmVzcy0wMA0KfA0KfE9uIDI2IE5vdmVtYmVyIDIwMTMgMTg6MDYsIE11 dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpDQp8PG1wZXJ1bWFsQGNpc2NvLmNvbT4g d3JvdGU6DQp8PiBBcmUgdGhlcmUgY2FzZXMgd2hlcmUgeW91IHdvbid0IGRvIElDRSBidXQgZG8g RFRMUywgZm9yIFdlYlJUQz8gSWYgbm90LCBJIHRoaW5rIHlvdSBjYW4gY29tYmluZSB0aGUNCnxi ZXN0IG9mIGJvdGg6DQp8PiAtIFRoZSBpbml0aWFsIGNvbnNlbnQgaXMgZXN0YWJsaXNoZWQgYnkg SUNFIGNvbm5lY3Rpdml0eSBjaGVja3MgYWxyZWFkeS4NCnw+IC0gVGhlIHJlY2VpcHQgb2YgYW55 IGF1dGhlbnRpY2F0ZWQgcGFja2V0LCBpbmNsdWRpbmcgRFRMUyBoZWFydGJlYXQsIGdyYW50cw0K fD4gICB5b3UgY29uc2VudCB0byBzZW5kIG1vcmUgcGFja2V0cy4NCnw+IC0gSWYgeW91IGRvZXNu J3QgcmVjZWl2ZSBhbnkgcGFja2V0IGFuZCBjb25zZW50IGlzIGFib3V0IHRvIGV4cGlyZSwgc2Vu ZCBhDQp8PiAgIFNUVU4gYmluZGluZyByZXF1ZXN0IHRoYXQgaXMgY29tcGFyYXRpdmVseSBsZXNz IENQVSBpbnRlbnNpdmUuDQp8Pg0KfD4gTWluaW1hbCBvdmVyaGVhZCBvdmVyYWxsIDopDQp8DQp8 SSBkaXNhZ3JlZS4gIE9uZSBvZiB0aGUgbWVyaXRzIG9mIHVzaW5nIHRoZSBEVExTIGhhbmRzaGFr ZSB0bw0KfGVzdGFibGlzaCBpbml0aWFsIGNvbnNlbnQsIGF1dGhlbnRpY2F0ZWQgcGFja2V0cyB0 byBtYWludGFpbiBpdCwgYW5kDQp8dGhlIERUTFMgaGVhcnRiZWF0IGluIHRoZSBhYnNlbmNlIG9m IGF1dGhlbnRpY2F0ZWQgcGFja2V0cyBpcyB0aGF0IGl0DQp8aXMgYWxsIERUTFMuICBBcyBzb21l b25lIHdobyB3cml0ZXMgc29mdHdhcmUsIGJlaW5nIGFibGUgdG8ga2VlcCBhbGwNCnx0aGUgbG9n aWMgY29uc3RyYWluZWQgdG8gYSBzaW5nbGUgc29mdHdhcmUgbW9kdWxlIGlzIGEgc2lnbmlmaWNh bnQNCnxpbXByb3ZlbWVudC4NCg0KV2VsbCwgbXkgcG9pbnQgaXMsIGZvciBXZWJSVEMgeW91IGNh biBhbHNvIGRvIHRoZSBzYW1lIG9wdGltaXphdGlvbiBieSBjb25maW5pbmcgdGhlIGxvZ2ljIHRv IHRoZSBTVFVOIG1vZHVsZSAtLSBib3RoIGNhbiBlc3RhYmxpc2ggYW5kIG1haW50YWluIGNvbnNl bnQgd2l0aG91dCBnZW5lcmF0aW5nIGFkZGl0aW9uYWwgdHJhZmZpYyBmb3IgbWFqb3JpdHkgb2Yg dGhlIHVzZS1jYXNlcy4NCg0KRnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlLCBJIGRvbid0IHNl ZSBhIHJlYWwgYWR2YW50YWdlIG9mIG9uZSBvdmVyIHRoZSBvdGhlci4NCg0KTXV0aHUNCg0KfA0K fEkgZG9uJ3QgYmVsaWV2ZSB0aGUgQ1BVIGNvc3Qgb2YgYSBEVExTIGhlYXJ0YmVhdCB0byBiZSBl eHBlbnNpdmUNCnxlbm91Z2ggdG8ganVzdGlmeSBjaGFuZ2VzIHRvIHRoaXMuICBHaXZlbiB0aGF0 IHlvdSBhcmVuJ3QgdXNpbmcgdGhlDQp8Q1BVIGZvciBjcnlwdG8gYXQgYWxsIHdoZW4geW91IHNl bmQgaXQsIEknbSBwcmV0dHkgc3VyZSB0aGF0IHRoZSBDUFUNCnxjb3N0IGNhbiBiZSBib3JuZS4N Cg== From dcpang@highfive.com Wed Nov 27 09:53:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4BE1ADEAE for ; Wed, 27 Nov 2013 09:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLL_tFLLkAwM for ; Wed, 27 Nov 2013 09:53:46 -0800 (PST) Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) by ietfa.amsl.com (Postfix) with ESMTP id E3BF81ADF5E for ; Wed, 27 Nov 2013 09:53:45 -0800 (PST) Received: by mail-bk0-f45.google.com with SMTP id mx13so3365074bkb.18 for ; Wed, 27 Nov 2013 09:53:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1+uMLQNjJM4RkfiANRDCgKegtutyDMweZj3Q4bjhWjo=; b=fdugnKfE+IVqApe1mE3tig4Hu4yUOtnBZb0qWwrG9ndL5TLpm4+tn0tOsF/Gx0zdn7 aoNmlaorYclTDxXgYHf37RE2NZLykQZdp1xgI1plV4bd6JToq7n+zIzTDPpoo3/Nih0u paOUmRSfVgpxuSeeI/xu9C680p8QwfscwwVD/6DCZp4pqAlSnUMbLlqFqhlPHDau/q6z XB+en6EY98u42oOV/195XL0ioiQXA1LpgOpuwPgQShixcwQkeEjtXc8NY4DzNBq//ld2 Puvg8/1zmVT7lweelVHPLKNGH6mfLalsuL8WRsTimQ4q5iGf/cXChIBnNYBedOM4rRpk jYAA== X-Gm-Message-State: ALoCoQnDLnjL6hsx0wpZqZ8m0DhJi2gzLtnuXprntTqa0yawqPnx1o7xjYobnLpXmMl5igVgHcmK X-Received: by 10.204.167.8 with SMTP id o8mr47056bky.133.1385574824331; Wed, 27 Nov 2013 09:53:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.162.78 with HTTP; Wed, 27 Nov 2013 09:53:24 -0800 (PST) In-Reply-To: <900A1E2059ADB149B905E3C8FA0046A62C80B27806@FHDP1LUMXC7V23.us.one.verizon.com> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <900A1E2059ADB149B905E3C8FA0046A62C80B27806@FHDP1LUMXC7V23.us.one.verizon.com> From: Derek Pang Date: Wed, 27 Nov 2013 09:53:24 -0800 Message-ID: To: "Mishra, Sanjay" Content-Type: multipart/alternative; boundary=bcaec52d569937287904ec2c4798 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 17:53:49 -0000 --bcaec52d569937287904ec2c4798 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Also, is there information on the voting process and instruction ? On Wed, Nov 27, 2013 at 8:33 AM, Mishra, Sanjay wrote: > Magnus -- To confirm, the voting period is be two weeks, so I am assuming > starting tomorrow (Nov 28) and lasting for two weeks (Dec 12?). > > Thanks > Sanjay > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: Wednesday, November 27, 2013 8:44 AM > To: Thomas Reisinger > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge= ? > > On 2013-11-27 14:16, Thomas Reisinger wrote: > > Magnus, > > > > Could you please share the latest list and how the voting will be > conducted/what's required to vote. > > For the proposed voting process see our previous message > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html > > As I stated, we chairs will need to update this based on the discussion. > > For the current list of alternatives is on the WG's wiki: > http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart > > > Reproduced here: > The following alternatives has been proposed: > > 1. All entities MUST support H.264 > 2. All entities MUST support VP8 > 3. All entities MUST support both H.264 and VP8 4. Browsers MUST suppor= t > both H.264 and VP8, other entities MUST > support at least one of H.264 and VP8 5. All entities MUST support a= t > least one of H.264 and VP8 6. All entities MUST support H.261 7. There = is > no MTI video codec 8. 5+6, i.e. All entities MUST support H.261 and all > entities MUST > support at least one of H.264 and VP8 9. All entities MUST support > Theora 10. All entities MUST implement at least two of {VP8, H.264, H.261= } > 11. All entities MUST implement at least two of {VP8, H.264, H.263} 12. A= ll > entities MUST support decoding using both H.264 and VP8, and > MUST support encoding using at least one of H.264 or VP8 > > H.264 is a reference to the proposal in > https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ > > VP8 is a reference to the proposal in > https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/ > > > > > > > Cheers, > > > > Thomas Reisinger > > > >> On 27.11.2013, at 09:50, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> > >>> On 2013-11-25 20:51, Markus.Isomaki@nokia.com wrote: > >>> MUST implement at least two of {VP8, H.264 CBP, H.261} > >> > >> I have now updated the list to read: > >> > >> 10. All entities MUST implement at least two of {VP8, H.264 CBP, > >> H.261} 11. All entities MUST implement at least two of {VP8, H.264 > >> CBP, H.263} > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> --------------------------------------------------------------------- > >> - Multimedia Technologies, Ericsson Research EAB/TVM > >> ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >> --------------------------------------------------------------------- > >> - > >> > >> > > > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > 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 > --bcaec52d569937287904ec2c4798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Also, is there information on the voting process and instr= uction ?


On Wed, Nov 27, 2013 at 8:33 AM, Mishra, Sanjay <sanjay.mishra@ve= rizon.com> wrote:
Magnus -- To confirm, the voting period is b= e two weeks, so I am assuming starting tomorrow (Nov 28) and lasting for tw= o weeks (Dec 12?).

Thanks
Sanjay
-----Original Message-----
From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of Magnus Westerlund
Sent: Wednesday, November 27, 2013 8:44 AM
To: Thomas Reisinger
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge?<= br>
On 2013-11-27 14:16, Thomas Reisinger wrote: > Magnus,
>
> Could you please share the latest list and how the voting will be cond= ucted/what's required to vote.

For the proposed voting process see our previous message http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html
As I stated, we chairs will need to update this based on the discussion.
For the current list of alternatives is on the WG's wiki:
http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart

Reproduced here:
=A0The following alternatives has been proposed:

=A01. All entities MUST support H.264
=A02. All entities MUST support VP8
=A03. All entities MUST support both H.264 and VP8 =A04. Browsers MUST supp= ort both H.264 and VP8, other entities MUST
=A0 =A0 support at least one of H.264 and VP8 =A05. All entities MUST suppo= rt at least one of H.264 and VP8 =A06. All entities MUST support H.261 =A07= . There is no MTI video codec =A08. 5+6, i.e. All entities MUST support H.2= 61 and all entities MUST
=A0 =A0 support at least one of H.264 and VP8 =A09. All entities MUST suppo= rt Theora 10. All entities MUST implement at least two of {VP8, H.264, H.26= 1} 11. All entities MUST implement at least two of {VP8, H.264, H.263} 12. = All entities MUST support decoding using both H.264 and VP8, and
=A0 =A0 MUST support encoding using at least one of H.264 or VP8

H.264 is a reference to the proposal in https://dat= atracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/

VP8 is a reference to the proposal in
https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-v= p8/



>
> Cheers,
>
> Thomas Reisinger
>
>> On 27.11.2013, at 09:50, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote= :
>>
>>> On 2013-11-25 20:51, Markus.Isomaki@nokia.com wrote:
>>> MUST implement at least two of {VP8, H.264 CBP, H.261}
>>
>> I have now updated the list to read:
>>
>> 10. All entities MUST implement at least two of {VP8, H.264 CBP, >> H.261} 11. All entities MUST implement at least two of {VP8, H.264=
>> CBP, H.263}
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ------------------------------------------------------------------= ---
>> - Multimedia Technologies, Ericsson Research EAB/TVM
>> --------------------------= --------------------------------------------
>> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
>> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>> ------------------------------------------------------------------= ---
>> -
>>
>>
>
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
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

--bcaec52d569937287904ec2c4798-- From john@jlc.net Wed Nov 27 09:54:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCC81ADF10 for ; Wed, 27 Nov 2013 09:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoMZKEVHdWUy for ; Wed, 27 Nov 2013 09:54:17 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id F1A431ADF5E for ; Wed, 27 Nov 2013 09:54:16 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 729AEC94BF; Wed, 27 Nov 2013 12:54:14 -0500 (EST) Date: Wed, 27 Nov 2013 12:54:14 -0500 From: John Leslie To: Magnus Westerlund Message-ID: <20131127175414.GA87911@verdi> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5295F718.9010603@ericsson.com> User-Agent: Mutt/1.4.1i Cc: "rtcweb@ietf.org" Subject: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 17:54:20 -0000 Magnus Westerlund wrote: > > For the proposed voting process see our previous message > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html > > As I stated, we chairs will need to update this based on the discussion. I gather the WGCs intend to update that tomorrow. While I would _much_ prefer not to mix discussion of the process with discussion of the alternatives, there are some really serious problems with this proposal. First: ] ] The method we propose is based on Instant-runoff voting, ] http://en.wikipedia.org/wiki/Instant-runoff_voting, with the ] understanding that the choice will be the winner according to the ] Instant-runoff voting process. Fail! A reference to wikipedia is completely unstable unless it refers to the webpage retrieved at a particular time. It is the _intent_ of Wikipedia that the webpage may be modified at any time by any person: thus people retrieving the page on different days may receive different text. Those differences may be obvious or they may be subtle. Second: ] ] 2) Establish those eligible to vote. What follows doesn't do that. It instead establishes rules for determining at some later time _whether_ an individual is eligible. ] Any participant in the working group process either electronically ] or in-person as of yesterday (20th of November). (That's where Magnus broke the sentence. Don't blame me...) I merely raise the question of whether the process Magnus outlined is likely to match that goal. ] Who has participated in the Working group process will be anyone ] that can be identified from: ] - The Blue Sheets for any RTCWEB WG session during an IETF meeting or ] an interim meeting since the WG's creation. ] - posting of at least one email to the RTCWEB mailing list Obviously missing from this list is persons subscribed to the mailing-list during some period. Those would ordinarily be considered participants. ] The voter must at time of voting prove their eligibility, by pointing ] to the mail archive or a particular blue sheet/meeting. Please verify ] your own eligibility. "Voter" is vague here. I take it to mean any person sending a ballot. Thus there is no way of challenging a right to vote before the ballot itself is opened. I believe that is unheard-of. It is, IMHO, strange to have no list of eligible voters to enable challenging eligibility (or absence from the list) before a vote is cast. ] 3) Start the the voting period. Those eligible and willing to vote send ] their ballot to a vote collector (Matt Lepinski, former Nomcom chair) ] within two weeks using email. The vote collector will check when ] receiving a ballot the that the voter is eligible and send a ] confirmation email on receiving the ballot. During the balloting period ] the vote collector will keep all ballots secret. (Just to prove I'm not leaving anything out.) ] Balloting: ] - The voter MUST rank ALL alternatives in their ballot from the most ] preferred, marked with rank 1, the second most with 2, all the way ] to the least preferred marked with rank N. This is very unusual in Instant Runoff. There are always choices that a voter would vote _against_ regardless of the alternatives. This requires that a voter may be counted as in favor of something s/he completely opposes. (Further, it leaves open the "or else" question: what happens if a ballot doesn't exactly match that requirement?) ] 4) When the voting period is over the ballot collector will publish the ] results as well as all ballots, including the voters name to the RTCWEB ] WG mailing list. This enables all voting individuals to verify that ] their ballot is unmodified. And allows anyone to verify the result of ] the vote. Thus every detail of preference becomes public. Inevitably there will be some persons who are nervous about publishing so much detail. (I don't mean to imply that employers _would_ punish employees, merely that employees could understandably be nervous.) ] 5) The selection is recorded in the drafts. Even when we get that wikipedia page "retrieved at a particular time," it will contain half a dozen different rules for how the counting proceeds. I strongly recommend extracting the actual rules the WGCs intend to follow on this list (which will be archival). Further, some person needs to be designated to interpret the rules during counting. ==== There are many other things I could mention from the email quoted; but I think it would only detract from the discussion to do so. -- John Leslie From martin.thomson@gmail.com Wed Nov 27 09:55:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DE81ACCDE for ; Wed, 27 Nov 2013 09:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KHPEfzQNTvj for ; Wed, 27 Nov 2013 09:55:32 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 960201ADF59 for ; Wed, 27 Nov 2013 09:55:32 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id z12so7011180wgg.3 for ; Wed, 27 Nov 2013 09:55:31 -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=9jHqGKsuxZxnz86SMeu6CM34ytRJncYycUAqk8w/PbA=; b=Xp468x3Zs7KrYGxTvzNsJBtZdeaqnNrdufab9wr7CrEne7CV7N9Byfa0hLa8vI/sUO 5FudHoUFWInWyclFVTVpuvngCGGU7OZ083Jmt+FWoRB3CKzxS6z3HYxuTD/xc1t4IQqg 473oIDU20FZsYWSlX9LmBLorWUJb4S8Ct61BUww/N0c4kqcA/FmPiFnboil1pyAS5STl OjTdgxM9aeTV6DveQ/ZRZSnnaOqo9MRi0bD9niITyCxc8hyPUhV4iy4e4Yijx/1+LRQg zLymGTC2pVKPbMC8o2uz/YHAoAe0CvEDbLrGues0MjCXj6OMWC2LpRaFDAzSItWINRz5 PO/Q== MIME-Version: 1.0 X-Received: by 10.194.143.4 with SMTP id sa4mr19223035wjb.4.1385574921464; Wed, 27 Nov 2013 09:55:21 -0800 (PST) Received: by 10.227.134.195 with HTTP; Wed, 27 Nov 2013 09:55:21 -0800 (PST) In-Reply-To: References: <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> Date: Wed, 27 Nov 2013 09:55:21 -0800 Message-ID: From: Martin Thomson To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 17:55:34 -0000 On 27 November 2013 09:38, Muthu Arul Mozhi Perumal (mperumal) wrote: > From a security perspective, I don't see a real advantage of one over the other. That's right, they are equivalent. Unless you consider the risk of a preimage attack on SHA-1 within the confines of the STUN message size limit to be a realistic. (I don't.) Equivalence on security is only the first order bit upon which we decide. From martin.thomson@gmail.com Wed Nov 27 10:02:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19B21ADF9F for ; Wed, 27 Nov 2013 10:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHjl0Hu82Rjc for ; Wed, 27 Nov 2013 10:02:15 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4128A1ADF59 for ; Wed, 27 Nov 2013 10:02:15 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so7170385wid.5 for ; Wed, 27 Nov 2013 10:02:14 -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=4nTgR67g0ASPEPPJU/n1YEi5w9ctD46UDM0Wpw2MH8Q=; b=lMHJiQO53eAGyctpifX6Hh6eQ4+3WxsPjufAEoZmU8bsoy1SrJI5R62tkKDI1/rP+L 45K7jREbS9OFlcTukY9w7n3uEcHnNPi17rJjjDKcAFc7EbtmDeAlVCyv0J11iUHlcb0i gBUXBNDVHfzwZ6qYKLAImIJBSQ7SjKJRwsMeRTQkjWsn0fK8lQIwkWRiYubcrUFCw8PS cBdA1N1wGG7M7LFDCYxI8sB9piAmBHAfin9KuQz3pD/fQchoghiJON+LnO8X/iCn9dBD dbPwEhgp8pSrA4LTQ+QIQpK25BUJUomyslj7EE0a2Ls8MEWHQzEr0Klxbx0JhJTGwzhN 7zrw== MIME-Version: 1.0 X-Received: by 10.194.108.100 with SMTP id hj4mr1686802wjb.83.1385575334173; Wed, 27 Nov 2013 10:02:14 -0800 (PST) Received: by 10.227.134.195 with HTTP; Wed, 27 Nov 2013 10:02:14 -0800 (PST) In-Reply-To: References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <900A1E2059ADB149B905E3C8FA0046A62C80B27806@FHDP1LUMXC7V23.us.one.verizon.com> Date: Wed, 27 Nov 2013 10:02:14 -0800 Message-ID: From: Martin Thomson To: Derek Pang Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge? X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 18:02:17 -0000 On 27 November 2013 09:53, Derek Pang wrote: > Also, is there information on the voting process and instruction ? https://www.ietf.org/tao.html#rfc.section.2 ... um, http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html From tim@phonefromhere.com Wed Nov 27 10:02:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2687F1ADF8F for ; Wed, 27 Nov 2013 10:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF-7UkW3dzoM for ; Wed, 27 Nov 2013 10:02:28 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 48FEE1ADF59 for ; Wed, 27 Nov 2013 10:02:28 -0800 (PST) Received: (qmail 98951 invoked from network); 27 Nov 2013 18:02:26 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 12479 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 27 Nov 2013 18:02:26 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id AB49918A043E; Wed, 27 Nov 2013 18:02:26 +0000 (GMT) Received: from [192.168.157.132] (unknown [192.67.4.35]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 54B9918A0207; Wed, 27 Nov 2013 18:02:26 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: tim panton In-Reply-To: <20131127175414.GA87911@verdi> Date: Wed, 27 Nov 2013 18:02:25 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <49D33D9F-BC65-4AE8-B98A-04D3C170F644@phonefromhere.com> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> To: John Leslie X-Mailer: Apple Mail (2.1822) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 18:02:30 -0000 On 27 Nov 2013, at 17:54, John Leslie wrote: > Magnus Westerlund wrote: >>=20 >> For the proposed voting process see our previous message >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html >>=20 >> As I stated, we chairs will need to update this based on the = discussion. >=20 > I gather the WGCs intend to update that tomorrow. >=20 > While I would _much_ prefer not to mix discussion of the process > with discussion of the alternatives, there are some really serious > problems with this proposal. In the spirit of sheer mischief, I=92d like to propose that individuals = who work for organisations that would directly profit from the gathering of = license fees should be requested to recuse themselves from the votes involving those = fees, due to conflict of interest. - This is the norm in voting for local government here in the UK. Whilst I=92m not entirely serious, I am raising this to indicate what = happens when you start to make up process on the fly. Tim.= From roman@telurix.com Wed Nov 27 10:13:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6861ADE85 for ; Wed, 27 Nov 2013 10:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkvAnseu9gQ2 for ; Wed, 27 Nov 2013 10:13:38 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0323A1ADDAC for ; Wed, 27 Nov 2013 10:13:37 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so5983664wgh.26 for ; Wed, 27 Nov 2013 10:13:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=hzI8/E8MRwI4S15MSnoVW+CjVW7qjDfP5aHHzVw5zGA=; b=A7RpwEUh64Zk8apk1VJ3QxuCTsO9cNCY7EIhXsWqnTFdZqugzQDRAKnfEGpKvOr/CR TXIaxU4p5beemVJVPswIwUGwk3QnP1Bxls0T4F3Szzj388pAMKDnSenTO3uHj9+BWqhS E+ECCP1DbK/ghEUFznafHkq5hf6ELTnqOd0eFOyTWsxq+2MNaLeOv6IxrXYmtcjPbhVV I1bl6gsEguIuUrcofQw8gckmNZPeZuFTLrsIud4Ol94NuCdlTAoIDMt2JxIOifD4b6cS 2NfS1XKMED5D8BWVvUTik21lJSeIV0XJ43KTdlrPEytbsDAMO8UVaTcZatT7SOcf5jY9 0J4A== X-Gm-Message-State: ALoCoQnQkXZBb0Fg7UcaCuptb7mSMm91dap/062Z6izQsOBVeALZ/1B9bFEiqrgfAAVqdzqRNZM8 X-Received: by 10.180.210.130 with SMTP id mu2mr24078072wic.61.1385576016785; Wed, 27 Nov 2013 10:13:36 -0800 (PST) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by mx.google.com with ESMTPSA id b7sm73514634wiz.8.2013.11.27.10.13.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 10:13:35 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id u57so1472532wes.23 for ; Wed, 27 Nov 2013 10:13:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.1.139 with SMTP id 11mr15986930wjm.33.1385576015122; Wed, 27 Nov 2013 10:13:35 -0800 (PST) Received: by 10.217.88.133 with HTTP; Wed, 27 Nov 2013 10:13:35 -0800 (PST) In-Reply-To: <49D33D9F-BC65-4AE8-B98A-04D3C170F644@phonefromhere.com> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <49D33D9F-BC65-4AE8-B98A-04D3C170F644@phonefromhere.com> Date: Wed, 27 Nov 2013 13:13:35 -0500 Message-ID: From: Roman Shpount Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a8c3030d92504ec2c8ed7 Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 18:13:39 -0000 --047d7b3a8c3030d92504ec2c8ed7 Content-Type: text/plain; charset=ISO-8859-1 I am not sure about the rest of the group but from my point of view the proposed process clearly shows that IETF in general and this group in particular is not equipped to vote. I also strongly disagree that voting would produce a MTI video codec decision which would meaningful in any way. We need a way to find consensus regarding the MTI or drop the whole MTI idea (which would also require consensus). _____________ Roman Shpount --047d7b3a8c3030d92504ec2c8ed7 Content-Type: text/html; charset=ISO-8859-1

I am not sure about the rest of the group but from my point of view the proposed process clearly shows that IETF in general and this group in particular is not equipped to vote. I also strongly disagree that voting would produce a MTI video codec decision which would meaningful in any way. We need a way to find consensus regarding the MTI or drop the whole MTI idea (which would also require consensus).
_____________
Roman Shpount

--047d7b3a8c3030d92504ec2c8ed7-- From ron@debian.org Wed Nov 27 10:38:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED921ADF98 for ; Wed, 27 Nov 2013 10:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW4X3ofEu0fn for ; Wed, 27 Nov 2013 10:38:08 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 878951AD8EE for ; Wed, 27 Nov 2013 10:38:08 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 28 Nov 2013 05:08:07 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 243254F8F3 for ; Thu, 28 Nov 2013 05:08:05 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TyJ9vW9I9fw6 for ; Thu, 28 Nov 2013 05:08:03 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id B9ACB4F902; Thu, 28 Nov 2013 05:08:03 +1030 (CST) Date: Thu, 28 Nov 2013 05:08:03 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131127183803.GQ3245@audi.shelbyville.oz> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <49D33D9F-BC65-4AE8-B98A-04D3C170F644@phonefromhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <49D33D9F-BC65-4AE8-B98A-04D3C170F644@phonefromhere.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 18:38:11 -0000 On Wed, Nov 27, 2013 at 06:02:25PM +0000, tim panton wrote: > > On 27 Nov 2013, at 17:54, John Leslie wrote: > > > Magnus Westerlund wrote: > >> > >> For the proposed voting process see our previous message > >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html > >> > >> As I stated, we chairs will need to update this based on the discussion. > > > > I gather the WGCs intend to update that tomorrow. > > > > While I would _much_ prefer not to mix discussion of the process > > with discussion of the alternatives, there are some really serious > > problems with this proposal. > > In the spirit of sheer mischief, I’d like to propose that individuals who > work for organisations that would directly profit from the gathering of > license fees should be requested to recuse themselves from the votes > involving those fees, due to conflict of interest. > > - This is the norm in voting for local government here in the UK. > > Whilst I’m not entirely serious, I am raising this to indicate what > happens when you start to make up process on the fly. Clearly we need an electoral collage to vote on whose vote counts as a vote. ___ /. .\ m---U---m From fluffy@cisco.com Wed Nov 27 10:38:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9011AD8EE for ; Wed, 27 Nov 2013 10:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.502 X-Spam-Level: X-Spam-Status: No, score=-109.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6y9oQaQI8Hi for ; Wed, 27 Nov 2013 10:38:10 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE321ADF76 for ; Wed, 27 Nov 2013 10:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6204; q=dns/txt; s=iport; t=1385577490; x=1386787090; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JlhLwOXzQN/xQupd998mw9tL8J4aVnFnCAhqFDOxrPA=; b=d9I3MGSELgTLITjPmVZ3ajo3DzxE3Vcjc3TLrkSYtzwsHdsB79R18pzX YEsSmmPLVhRQrEgcSAVjyiJREZrURcwh34EZXw0G+Gq7ktcWJJDywEi1H LMT6Hk4+jxWwmOXob6rjMui7TMHmOxVit+AHu3XDhHtEhIaQ5KMitXEpb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAMA7llKtJV2b/2dsb2JhbABZgwc4U4IuTLR6ThiBCBZ0giUBAQEDAQEBAQkXEToLBQcCAgIBBgIRBAEBAQICIwMCAgIZDAsUAQgIAgQOBQmHZgMJBg2TQZthkHIXBIEli0gkgRwBATQbBwaCZTWBEwOYFIEwkGODKYFxOQ X-IronPort-AV: E=Sophos;i="4.93,784,1378857600"; d="scan'208";a="2727750" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 27 Nov 2013 18:38:09 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rARIc9nQ017489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 18:38:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 12:38:09 -0600 From: "Cullen Jennings (fluffy)" To: "Mishra, Sanjay" Thread-Topic: [rtcweb] Video Codec Selection Alternatives - Timing Thread-Index: AQHO65/RWnplPSF720KudunmUkqDag== Date: Wed, 27 Nov 2013 18:38:09 +0000 Message-ID: References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <900A1E2059ADB149B905E3C8FA0046A62C80B27806@FHDP1LUMXC7V23.us.one.verizon.com> In-Reply-To: <900A1E2059ADB149B905E3C8FA0046A62C80B27806@FHDP1LUMXC7V23.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="utf-8" Content-ID: <9E26916DD832784091E709B0850D85C5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Alternatives - Timing X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 18:38:13 -0000 DQpTYW5qYXksIHRoZSBmaXJzdCBzdGVwIHdpbGwgYmUgdG8gYXNrIGlmIHRoZXJlIGlzIGNvbnNl bnN1cyB0byB1c2UgdGhlIHByb2Nlc3MuIFJpZ2h0IG5vdyB3ZSBoYXZlIGJlZW4gY29sbGVjdGlu ZyBjb21tZW50cyBvbiB0aGUgcHJvY2VzcyB0aGVuIE1hZ251cyB3aWxsIHNlbmQgb3V0IGEgcmV2 aXNlZCBwcm9jZXNzIGFuZCBhIGNvbnNlbnN1cyBjYWxsIHRvIHVzZSB0aGF0IHByb2Nlc3MuIEkn ZCBleHBlY3QgdGhhdCBjb25zZW5zdXMgY2FsbCB0byBhbmQgcmV2aXNlZCBwcm9jZXNzIHRvIGdv IG91dCB0b21vcnJvdyBhdCB0aGUgZWFybGllc3QgYW5kIHBvc3NpYmx5IGEgYml0IGxhdGVyLiBU aGF0IGNvbnNlbnN1cyBjYWxsIHdvdWxkIGxhc3Qgcm91Z2hseSAyIHdlZWtzLiBJZiB0aGVyZSBp cyBjb25zZW5zdXMgdG8gdXNlIHRoYXQgcHJvY2VzcyB0aGVuIHRoZSB2b3RpbmcgcGVyaW9kIHdv dWxkIHN0YXJ0IGFuZCBiZSBhdCBsZWFzdCBhIGZldyB3ZWVrcyBsb25nIGJ1dCBhZGp1c3RlZCB0 byBiZSBsb25nZXIgaWYgaXQgcmFuIG92ZXIgYSBzaWduaWZpY2FudCBob2xpZGF5LiANCg0KDQpP biBOb3YgMjcsIDIwMTMsIGF0IDk6MzMgQU0sICJNaXNocmEsIFNhbmpheSIgPHNhbmpheS5taXNo cmFAdmVyaXpvbi5jb20+IHdyb3RlOg0KDQo+IE1hZ251cyAtLSBUbyBjb25maXJtLCB0aGUgdm90 aW5nIHBlcmlvZCBpcyBiZSB0d28gd2Vla3MsIHNvIEkgYW0gYXNzdW1pbmcgc3RhcnRpbmcgdG9t b3Jyb3cgKE5vdiAyOCkgYW5kIGxhc3RpbmcgZm9yIHR3byB3ZWVrcyAoRGVjIDEyPykuDQo+IA0K PiBUaGFua3MNCj4gU2FuamF5DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFn bnVzIFdlc3Rlcmx1bmQNCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyNywgMjAxMyA4OjQ0 IEFNDQo+IFRvOiBUaG9tYXMgUmVpc2luZ2VyDQo+IENjOiBydGN3ZWJAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtydGN3ZWJdIFZpZGVvIENvZGVjIFNlbGVjdGlvbiBBbHRlcm5hdGl2ZXMgMTAg YW5kIDExOiBNZXJnZT8NCj4gDQo+IE9uIDIwMTMtMTEtMjcgMTQ6MTYsIFRob21hcyBSZWlzaW5n ZXIgd3JvdGU6DQo+PiBNYWdudXMsDQo+PiANCj4+IENvdWxkIHlvdSBwbGVhc2Ugc2hhcmUgdGhl IGxhdGVzdCBsaXN0IGFuZCBob3cgdGhlIHZvdGluZyB3aWxsIGJlIGNvbmR1Y3RlZC93aGF0J3Mg cmVxdWlyZWQgdG8gdm90ZS4NCj4gDQo+IEZvciB0aGUgcHJvcG9zZWQgdm90aW5nIHByb2Nlc3Mg c2VlIG91ciBwcmV2aW91cyBtZXNzYWdlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9ydGN3ZWIvY3VycmVudC9tc2cwOTkwOS5odG1sDQo+IA0KPiBBcyBJIHN0YXRlZCwgd2Ug Y2hhaXJzIHdpbGwgbmVlZCB0byB1cGRhdGUgdGhpcyBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbi4N Cj4gDQo+IEZvciB0aGUgY3VycmVudCBsaXN0IG9mIGFsdGVybmF0aXZlcyBpcyBvbiB0aGUgV0cn cyB3aWtpOg0KPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9ydGN3ZWIvdHJhYy93aWtp L1dpa2lTdGFydA0KPiANCj4gDQo+IFJlcHJvZHVjZWQgaGVyZToNCj4gVGhlIGZvbGxvd2luZyBh bHRlcm5hdGl2ZXMgaGFzIGJlZW4gcHJvcG9zZWQ6DQo+IA0KPiAxLiBBbGwgZW50aXRpZXMgTVVT VCBzdXBwb3J0IEguMjY0DQo+IDIuIEFsbCBlbnRpdGllcyBNVVNUIHN1cHBvcnQgVlA4DQo+IDMu IEFsbCBlbnRpdGllcyBNVVNUIHN1cHBvcnQgYm90aCBILjI2NCBhbmQgVlA4ICA0LiBCcm93c2Vy cyBNVVNUIHN1cHBvcnQgYm90aCBILjI2NCBhbmQgVlA4LCBvdGhlciBlbnRpdGllcyBNVVNUDQo+ ICAgIHN1cHBvcnQgYXQgbGVhc3Qgb25lIG9mIEguMjY0IGFuZCBWUDggIDUuIEFsbCBlbnRpdGll cyBNVVNUIHN1cHBvcnQgYXQgbGVhc3Qgb25lIG9mIEguMjY0IGFuZCBWUDggIDYuIEFsbCBlbnRp dGllcyBNVVNUIHN1cHBvcnQgSC4yNjEgIDcuIFRoZXJlIGlzIG5vIE1USSB2aWRlbyBjb2RlYyAg OC4gNSs2LCBpLmUuIEFsbCBlbnRpdGllcyBNVVNUIHN1cHBvcnQgSC4yNjEgYW5kIGFsbCBlbnRp dGllcyBNVVNUDQo+ICAgIHN1cHBvcnQgYXQgbGVhc3Qgb25lIG9mIEguMjY0IGFuZCBWUDggIDku IEFsbCBlbnRpdGllcyBNVVNUIHN1cHBvcnQgVGhlb3JhIDEwLiBBbGwgZW50aXRpZXMgTVVTVCBp bXBsZW1lbnQgYXQgbGVhc3QgdHdvIG9mIHtWUDgsIEguMjY0LCBILjI2MX0gMTEuIEFsbCBlbnRp dGllcyBNVVNUIGltcGxlbWVudCBhdCBsZWFzdCB0d28gb2Yge1ZQOCwgSC4yNjQsIEguMjYzfSAx Mi4gQWxsIGVudGl0aWVzIE1VU1Qgc3VwcG9ydCBkZWNvZGluZyB1c2luZyBib3RoIEguMjY0IGFu ZCBWUDgsIGFuZA0KPiAgICBNVVNUIHN1cHBvcnQgZW5jb2RpbmcgdXNpbmcgYXQgbGVhc3Qgb25l IG9mIEguMjY0IG9yIFZQOA0KPiANCj4gSC4yNjQgaXMgYSByZWZlcmVuY2UgdG8gdGhlIHByb3Bv c2FsIGluIOKAiyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1idXJtYW4t cnRjd2ViLWgyNjQtcHJvcG9zYWwvDQo+IA0KPiBWUDggaXMgYSByZWZlcmVuY2UgdG8gdGhlIHBy b3Bvc2FsIGluIOKAiw0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1h bHZlc3RyYW5kLXJ0Y3dlYi12cDgvDQo+IA0KPiANCj4gDQo+PiANCj4+IENoZWVycywNCj4+IA0K Pj4gVGhvbWFzIFJlaXNpbmdlcg0KPj4gDQo+Pj4gT24gMjcuMTEuMjAxMywgYXQgMDk6NTAsIE1h Z251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+IHdyb3RlOg0K Pj4+IA0KPj4+PiBPbiAyMDEzLTExLTI1IDIwOjUxLCBNYXJrdXMuSXNvbWFraUBub2tpYS5jb20g d3JvdGU6DQo+Pj4+IE1VU1QgaW1wbGVtZW50IGF0IGxlYXN0IHR3byBvZiB7VlA4LCBILjI2NCBD QlAsIEguMjYxfQ0KPj4+IA0KPj4+IEkgaGF2ZSBub3cgdXBkYXRlZCB0aGUgbGlzdCB0byByZWFk Og0KPj4+IA0KPj4+IDEwLiBBbGwgZW50aXRpZXMgTVVTVCBpbXBsZW1lbnQgYXQgbGVhc3QgdHdv IG9mIHtWUDgsIEguMjY0IENCUCwgDQo+Pj4gSC4yNjF9IDExLiBBbGwgZW50aXRpZXMgTVVTVCBp bXBsZW1lbnQgYXQgbGVhc3QgdHdvIG9mIHtWUDgsIEguMjY0IA0KPj4+IENCUCwgSC4yNjN9DQo+ Pj4gDQo+Pj4gQ2hlZXJzDQo+Pj4gDQo+Pj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4+PiANCj4+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+PiAtIE11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNl YXJjaCBFQUIvVFZNDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IEVyaWNzc29uIEFCICAgICAgICAg ICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+Pj4gRsOkcsO2Z2F0YW4gNiAgICAgICAg ICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPj4+IFNFLTE2NCA4MCBTdG9ja2hvbG0s IFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+PiAtDQo+Pj4gDQo+Pj4gDQo+PiANCj4+IA0KPiANCj4gDQo+IC0tIA0KPiAN Cj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gTXVsdGltZWRpYSBU ZWNobm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UVk0NCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPiBG w6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNF LTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmlj c3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRj d2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K From cowwoc@bbs.darktech.org Wed Nov 27 10:54:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDE31AD8EE for ; Wed, 27 Nov 2013 10:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYcZiqD1I5vi for ; Wed, 27 Nov 2013 10:54:33 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1971B1ADF6E for ; Wed, 27 Nov 2013 10:54:32 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id e14so12607919iej.14 for ; Wed, 27 Nov 2013 10:54:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Xcr+fYXdPN5rZXsdk9GdYfV/GL2EP0+j/V/t0Y/V29k=; b=LeViC5ecf4s83E5rvkHrfPfM0SwZteApNFs7F6MY3D1+fi/5Lhzcxo9LwpJXOaxCNx LbklXWtnD+71/HiIMmO/ZuVZlQCwKyL2pZ2974zOCUo/PQHckCshq/ubN9i38dskbGi5 6VsXnuvb2N+Fnk1k0iY0qxOBfT4obOkvNglksSOuQavWLVs6vE2cAOLjSDpi24kWcqn2 7hBDT0bsL5ZTdhrt+XMdlB7J8ypWL1iW9/jlDStpmdFeDzLqR9t/sooBUtBMF5tpjNDG 6w/x9nHOjqlFhkp4e1L1FKDdl3wYMZcjFIRQgxbZ+PczFrhGp2mX1aXmlV7fo8fZFjXt P/Pw== X-Gm-Message-State: ALoCoQk8/NQP1junAiH50YatizJfTCAq6yxY3C15YzBHuLTimsT+mgdG+Vecvvi73zaEp9lQcB2l X-Received: by 10.50.87.36 with SMTP id u4mr23107612igz.40.1385578472373; Wed, 27 Nov 2013 10:54:32 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id x6sm39707690igb.3.2013.11.27.10.54.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 10:54:31 -0800 (PST) Message-ID: <52963FB9.7020002@bbs.darktech.org> Date: Wed, 27 Nov 2013 13:53:45 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 18:54:34 -0000 On 27/11/2013 10:23 AM, Cullen Jennings (fluffy) wrote: > On Nov 26, 2013, at 10:26 PM, cowwoc wrote: > >>> 3. I asked for the ability to license multiple units at a time so we deploy images and applications without a separate plugin/download process. >>> >>> StW: if this is related to MPEG-LA (and not to the Cisco download mechanism) the answer is simple. You, as an MPEG-LA sublicensee, are responsible for the correct accounting of the number of codecs you “sell” (where “sell” includes things like free download etc.). MPEG-LA has the right to audit you, and if they do and you are found cheating, then there are provisions for penalties. /StW >> Good point. I guess I am asking about Cisco's mechanism, since it is the one that we will be bound by. I guess this would be much simpler if Cisco hit the licensing upper limit, because then we wouldn't need to keep on counting. >> >> Gili > Cisco is going to pay the cap - not because we think counting is hard (even CDNs allow easy counting) - but because we believe that the Firefox usage alone will greatly exceed the cap. So why can't we bundle the H.264 codec again? If you are already hitting the cap, I don't see a reason to force us to download the codec after-the-fact. Gili From cowwoc@bbs.darktech.org Wed Nov 27 10:54:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F971AD8EE for ; Wed, 27 Nov 2013 10:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHzbb4IIOERc for ; Wed, 27 Nov 2013 10:54:41 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 926621ADFAD for ; Wed, 27 Nov 2013 10:54:41 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so12279980ieb.22 for ; Wed, 27 Nov 2013 10:54:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M/z3lflMS4VVxF6vI4rARM8GFStBlkbsmK3HUpkrT28=; b=aYI1LPglV2SRd2TYeywRY5pBHwAQ/aEMskNh3LKSg4iCyV82JRWZz1Gamkz4OuEiRL 6HK+AtXSklSWXaFr4GDJl8IkmuGG3Dfi+DUG/Fqvhf7EdX152bhO6QrLPzmuqPa3bEmL raVrn0kPup4K2S9TL/aNXEKid3J5pl3cn/VPnEUGepo+gOYq74fuQvdr4TNWXxhMvnB5 pOxU7B3gd5aT8MTSKzKqb1RJra87XiKcyVk9/bbDptARr9RoMkA73wesDZuEX/CixNSx E8sVm2tur/+MlI1F0sp65gNcaSBnvv+IKUyyWpQ2e32VUcwDENaaKmzq7xMNK4WUyjd7 NRBA== X-Gm-Message-State: ALoCoQl+qZbyxcg8345Lzu8vLvo7QkbDrvq3SgJ6vBosuHKHnIQasJdDSIYa4JXP0++YFPnaSwyb X-Received: by 10.42.148.200 with SMTP id s8mr1575127icv.67.1385578481040; Wed, 27 Nov 2013 10:54:41 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id a17sm4534604ign.2.2013.11.27.10.54.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 10:54:40 -0800 (PST) Message-ID: <52963FC2.3000104@bbs.darktech.org> Date: Wed, 27 Nov 2013 13:53:54 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <20131127162552.GP3245@audi.shelbyville.oz> In-Reply-To: <20131127162552.GP3245@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 18:54:43 -0000 +1. There seems to be a lot of hand waving when it comes to H.264. Some very concrete questions are going unanswered. Gili On 27/11/2013 11:25 AM, Ron wrote: > On Wed, Nov 27, 2013 at 03:30:55AM +0000, Cullen Jennings (fluffy) wrote: >> I do get they MPEG LA terms can be confusing at times >> but lots of people have figured it out. > I can only assume that you mean this in the same sense that "lots of people" > have "figured out" those click through EULA conditions that don't actually > allow them to do the things they'll be doing but obviously aren't intended > to be read since a 50 page document is presented in a 4 line scroll box with > no button that says "click here to send this to your lawyer". [1] > > Like the ones that say your TV can report everything that's ever watched on > it to the manufacturer, even after you click the Don't Do That button. [2] > > Or in the same sense that they drive their motor vehicles without complying > with their legal obligation to keep a bale of hay in the trunk or have some > person walk in front at all times waving a flag. > > > A licence that says "we'll take your money, but we can't actually grant you > the rights to use this since we don't own or control them - we'll just sort > of promise that WE won't drag you through the courts, in exchange for being > able to track exactly how profitable your business is" -- isn't a licence at > all. It's a protection racket. With a dash of industrial espionage thrown > in for good measure. > > This isn't something we should be booby trapping IETF standards with. > > The IETF has disclosure rules that are aimed at avoiding, so much as is > possible, this sort of Don't ask Don't tell nonsense. And yet we *still* > don't have disclosures from the H.264 IPR holders that *are* present here > for the use of H.264 in this standard. Despite them having core dumped > their IPR restrictions on alternative proposals. > > How can we possibly take mandating that technology seriously in this light? > > That alone should already rule this out from consideration. > > >> If people have questions about specific use case I'm glad to try and get >> them answers. > The specific question about how the Cisco offer resolves the problem of > MPEG LA not being the only holder of IPR that would need to be licenced > has so far met with deafening silence. > > Glad answers to that would certainly be nice. > > People keep making claims about that offer "solving everything", which > can't possibly be true unless you pretend those other licence holders > don't exist. > > By comparison, Google at least has shown that it is *very* willing to > do whatever is necessary to ensure that the licence and IPR of VP8 is > very unambiguously exactly as they claim it to be. > > That seems a lot more reassuring than the state of denial that has > surrounded promoting H.264. First pretending the IPR wasn't a problem, > then pretending they could buy us all free tickets, then claiming they > "really wished there was a solution with no IPR burden", then rejecting > that solution when it was actually presented as a compromise. > > Then pushing for getting the IETF to vote ... > > The number of dimensions in which we'd have to disconnect from reality > to make this proposal acceptable makes even string theory start to look > well grounded. > > Ron > > > [1] http://i.imgur.com/m0sQKZI.jpg > > [2] http://www.bbc.co.uk/news/technology-25042563 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cowwoc@bbs.darktech.org Wed Nov 27 10:56:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571AC1ADF98 for ; Wed, 27 Nov 2013 10:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id px1erPZrgVyR for ; Wed, 27 Nov 2013 10:56:47 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id C49EC1ADF73 for ; Wed, 27 Nov 2013 10:56:47 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so12871632iej.12 for ; Wed, 27 Nov 2013 10:56:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2CcRzGWTS0HnFSegFPsKX3pLCnNjsMlgiMi5/oIju38=; b=PkRrOLOz+6WAQTRP5NOphq8APrKTqb1pBXnAA74ECJriPjEsmcqEtuw2nf3h6n0oH+ 9wGCgfdz7F5QbYwC2bthnTVmrqjv/bF6I/y2fB6E/8XXAfhwCtsOrLkKC1olJWtXdQBs 7zUdURnVq78+PKryR/o6k+OkfPt5qIwAfluJ3CMvCZxZvNBrY5qD9CIeKBoDSiDQXym8 0tEeYXjUdYvpqlXaEke1b67MIBzoKGw1RwOvtOTM8CBT6p6AmMSQb9VMeXRO5tEfS3Ng Y0T32m3RkxnGKi8Ua79yVYlh/xeX0O1QrBCAgNMJ33qFx45lpZRv2yvKSLXcE5TasrmY x1SQ== X-Gm-Message-State: ALoCoQkUKyoXy4cBK4BFw2ZB/Qa9RbvNCMtTxtg8umXBbn7mbK5togE/mlBQzkKMTHLSnDO+Ic0O X-Received: by 10.42.226.66 with SMTP id iv2mr18606402icb.11.1385578607164; Wed, 27 Nov 2013 10:56:47 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ft2sm40383182igb.5.2013.11.27.10.56.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 10:56:46 -0800 (PST) Message-ID: <52964040.2010103@bbs.darktech.org> Date: Wed, 27 Nov 2013 13:56:00 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stephan Wenger , tim panton References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 18:56:49 -0000 This interpretation leaves me very uncomfortable at the thought of using H.264 in my own products. How can we base our business on a technology when the owner refuses to issue public answers (i.e. commitments) regarding its own licensing terms? This might work for companies with deep pockets for lawyers, but I don't think it makes sense for the rest of all. And don't tell me that we're safe so long as we use less than "100k units" when the very definition of a unit is unknown. Gili On 27/11/2013 11:41 AM, Stephan Wenger wrote: > I doubt very much that you will get an authoritive answer to the those > broad interpretation questions from MPEG-LA, even if they were formulated > in a precise and concise way (which, currently, they certainly are not). > MPEG-LA commonly doesn't want to go public with their own interpretation > of the agreement, and prefer to do so only with consent of the licensor > group, which is harder to obtain than herding cats because of the very > diverse nature of the licensor community. One motivation of this silence > may be the fear of weakening the license by making public statements about > its interpretation that may provide openings for sharp company lawyers to > cheat out of their licensing obligations. It¹s a common theme in the > legal community: say as little as possible. > > What can be done, and is (so I understand) not uncommon, is that a company > (a prospective licensee, but not a ³community²) contacts MPEG-LA directly, > explains their business model, and asks how that fits within the agreement > language. This process can result in a side letter that includes an > interpretation of the agreement language tailored to the business model of > the company. Those side letters are confidential. The agreement itself > is AFAIK take it or leave it. From cowwoc@bbs.darktech.org Wed Nov 27 11:08:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D851ADEB1 for ; Wed, 27 Nov 2013 11:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvFOTPAEy8oV for ; Wed, 27 Nov 2013 11:08:41 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0291AD72A for ; Wed, 27 Nov 2013 11:08:41 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id to1so12556753ieb.18 for ; Wed, 27 Nov 2013 11:08:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=6aELhWJZEERlazUN79PYfbheQrjq852pQw6m7QgBdq4=; b=dU7DF1YXO4SRK3YLvee1RvLOM4uvGDQADHWrEeUYDGUShz55kjQajg0Yldwbqg8+0K DuRJ8GnGerysI/VNjERDpBC1Gub+dyuC0Py1qSW+UGGcaqlfoZcHvT8ebpcyPCuNljX+ GWj4AStKej4UIUM3riYfDxHDREYwz40YiD4kBZRvBI9HLnFdpAPttM2pHfmvptxmgXHe nHMySwgS54pXJu4whkOBzPY50bWPk64HuBvW+PJ1mmd0F8Y439t81dxU3ckf+Pveauei ZPA/XLq9+HL0oaE7iCDHIrKbKxJ1qORqarS2OG/hlvW3T49/T9rDBBUeOM/aZtpRKZ+j xCzg== X-Gm-Message-State: ALoCoQlWSNBuYOrtG+rkRDDe83Cld24lnKUaS8rMwgIWWqb24+x5/KH4QAnJdKHOR9UCELc3YEJP X-Received: by 10.43.77.212 with SMTP id zj20mr25215770icb.5.1385579320578; Wed, 27 Nov 2013 11:08:40 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id u1sm39790159ige.1.2013.11.27.11.08.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 11:08:39 -0800 (PST) Message-ID: <52964309.3060108@bbs.darktech.org> Date: Wed, 27 Nov 2013 14:07:53 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <49D33D9F-BC65-4AE8-B98A-04D3C170F644@phonefromhere.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020906070008000903020905" Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 19:08:51 -0000 This is a multi-part message in MIME format. --------------020906070008000903020905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If you could come up with an alternative that works, great. The only reason we are voting is because all other options have failed. It is my understanding that we have the following options (from best to worst): 1. Come up with a better mechanism for establishing MTI, or 2. Vote for MTI, or 3. Give up and declare No MTI Gili On 27/11/2013 1:13 PM, Roman Shpount wrote: > > I am not sure about the rest of the group but from my point of view > the proposed process clearly shows that IETF in general and this group > in particular is not equipped to vote. I also strongly disagree that > voting would produce a MTI video codec decision which would meaningful > in any way. We need a way to find consensus regarding the MTI or drop > the whole MTI idea (which would also require consensus). > _____________ > Roman Shpount > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020906070008000903020905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

If you could come up with an alternative that works, great. The only reason we are voting is because all other options have failed.

It is my understanding that we have the following options (from best to worst):
  1. Come up with a better mechanism for establishing MTI, or
  2. Vote for MTI, or
  3. Give up and declare No MTI

Gili

On 27/11/2013 1:13 PM, Roman Shpount wrote:

I am not sure about the rest of the group but from my point of view the proposed process clearly shows that IETF in general and this group in particular is not equipped to vote. I also strongly disagree that voting would produce a MTI video codec decision which would meaningful in any way. We need a way to find consensus regarding the MTI or drop the whole MTI idea (which would also require consensus).
_____________
Roman Shpount



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------020906070008000903020905-- From ekr@rtfm.com Wed Nov 27 11:25:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBB71AE04F for ; Wed, 27 Nov 2013 11:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SYx6pN7annW for ; Wed, 27 Nov 2013 11:25:26 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 75B061ADFEC for ; Wed, 27 Nov 2013 11:24:16 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so7330129wes.29 for ; Wed, 27 Nov 2013 11:24:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=drtYmm9g+P1nchpxOwgsL40QVmSGRIj4ct/gHR963L8=; b=GQcjsj+FntguWnLxv4qMBSvBoUADggF1sm3jvibUKsERTYv5p70s8xMHwc8pdefWdW /IMJgtk6BcVcLjZTDeUIGl7T5v5UQDntMcIwq8jEylFOXfrLeU6i9XYTg8wCYe7H3B7Q 4bo4Kv7Nes9nCFdo806pSt/578l0Nmcqmnt2VGN7TFtxJUG5nOLnazoY9534Mo3LPYiV cAi8J4tzMdxsLIfIhkdQF7vYQK6NdC6Beo+FuKLPU9OrNxhGWTE4IvDPyxrEOG/lwoKv 2JyPIvERWkiwBGUXmyfar5u/SeV2PA/DKmNSnJ15xnTFpcDzsDVU33HuDkinFLdjYzqL hgDA== X-Gm-Message-State: ALoCoQk0wLRt6URXii2m87YLqqn+JMQc4PzyZ+lfikNkjA3i8eFLWbADJSBF9o2O7KBS9ORDl+MT X-Received: by 10.180.12.179 with SMTP id z19mr24077734wib.24.1385580255268; Wed, 27 Nov 2013 11:24:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Wed, 27 Nov 2013 11:22:24 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: <52963FB9.7020002@bbs.darktech.org> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> <52963FB9.7020002@bbs.darktech.org> From: Eric Rescorla Date: Wed, 27 Nov 2013 11:22:24 -0800 Message-ID: To: cowwoc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 19:25:44 -0000 On Wed, Nov 27, 2013 at 10:53 AM, cowwoc wrote: > On 27/11/2013 10:23 AM, Cullen Jennings (fluffy) wrote: >> >> On Nov 26, 2013, at 10:26 PM, cowwoc wrote: >> >>>> 3. I asked for the ability to license multiple units at a time so we >>>> deploy images and applications without a separate plugin/download proc= ess. >>>> >>>> StW: if this is related to MPEG-LA (and not to the Cisco download >>>> mechanism) the answer is simple. You, as an MPEG-LA sublicensee, are >>>> responsible for the correct accounting of the number of codecs you =93= sell=94 >>>> (where =93sell=94 includes things like free download etc.). MPEG-LA h= as the >>>> right to audit you, and if they do and you are found cheating, then t= here >>>> are provisions for penalties. /StW >>> >>> Good point. I guess I am asking about Cisco's mechanism, since it is th= e >>> one that we will be bound by. I guess this would be much simpler if Cis= co >>> hit the licensing upper limit, because then we wouldn't need to keep on >>> counting. >>> >>> Gili >> >> Cisco is going to pay the cap - not because we think counting is hard >> (even CDNs allow easy counting) - but because we believe that the Firefo= x >> usage alone will greatly exceed the cap. > > > So why can't we bundle the H.264 codec again? If you are already hitting = the > cap, I don't see a reason to force us to download the codec after-the-fac= t. Because Cisco distributing the copies is what makes them, not you, responsible for the license fee. -Ekr From gmartincocher@blackberry.com Wed Nov 27 11:42:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DE31AD83F for ; Wed, 27 Nov 2013 11:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GE2wmbgb9Xs for ; Wed, 27 Nov 2013 11:42:09 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4F13A1ADFB9 for ; Wed, 27 Nov 2013 11:38:49 -0800 (PST) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 Nov 2013 14:38:44 -0500 Received: from XCT110CNC.rim.net (10.65.161.210) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 14:38:44 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT110CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 14:38:44 -0500 From: Gaelle Martin-Cocher To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Last day for any additional Video Codec Selection alternatives Thread-Index: AQHO643PBBm8QNZdcEutrff6BvQeJZo5c9hA Date: Wed, 27 Nov 2013 19:38:44 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AA548AE06C@XMB111CNC.rim.net> References: <5295B358.1040302@ericsson.com> <5295DA58.60504@jitsi.org> <5295E663.4020607@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA548ADD3C@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AA548ADD3C@XMB111CNC.rim.net> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 19:42:12 -0000 If we proceed with the vote, I would like to see the following choice: All entities must support H263. Thanks Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Gaelle Martin-Co= cher Sent: Wednesday, November 27, 2013 11:29 AM To: Magnus Westerlund; Emil Ivov Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alt= ernatives Dear All, Sorry for this late message, I was not available this past week. It has been mentioned by a few of us that the risks on VP8 that some can't = leave with, can be mitigated when VP8 becomes an ISO standard (via MPEG). = VP8 has a chance to become an MPEG deliverable in January. I believe that c= ould make a few of us more comfortable with supporting/mandating both H264 = and VP8 and could change the consensus reaching process. Can we give VP8 that chance before forcing a vote? Thanks Sincerely, Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: Wednesday, November 27, 2013 7:33 AM To: Emil Ivov Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alt= ernatives On 2013-11-27 12:41, Emil Ivov wrote: > Just to confirm, this is NOT the last day of discussion on whether a = > vote is the right way to do this at all, right? No, but tomorrow a week will have passed since we chairs sent out the propo= sal and solicited feedback on the proposal. > = > That sounds like it would still be an open question for step two here: > = > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html As we stated in this message, after the week we chairs would update the pro= cess proposal if we considered it necessary. I believe there are some clari= fications that needs to be done, including the voter eligibility. After that the stated plan was to hold a consensus call in the WG to use th= e proposed process. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From martin.thomson@gmail.com Wed Nov 27 11:49:14 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A061ADF90 for ; Wed, 27 Nov 2013 11:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9_7cgPG_JJC for ; Wed, 27 Nov 2013 11:49:09 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 66AF61ADF6C for ; Wed, 27 Nov 2013 11:49:09 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so6320027wgh.9 for ; Wed, 27 Nov 2013 11:49:08 -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=rCzlTkfKPx+mFZorfP3ppCoivf5qrLfSwv//GLf32B4=; b=SxGU7UEVtwKndM3CxFssIkyJsluUj4Y9GgFeijzgAngcc/7jTLKkSSPGCwjlng5pQx rT6PyTJn1EwThXXcKxQQojTZwjrrw+oV0BK3FEUn0wN533Ktyj1CS0Ae0SunCgyD66+j tc8W4N5fe+v6RhJeBIJ6pMKT/mfMVu9p7LSRaX/qqG2KUdA52YLTNFj8BEXbpKZcnVGD D3DC0s39HNJC4JfbhH0IpnRvRdsV+t/x0tGVBn8GLKij6YesaCVakuqT5iPaOJmv4qjI PlbIwBPKpEcqxUZhePvR2JMZvdBEOh7bSTI/5cjCny41O+eKqcwuO2XwPBcF1Sgxequ3 0Bwg== MIME-Version: 1.0 X-Received: by 10.180.86.102 with SMTP id o6mr24410952wiz.30.1385581748221; Wed, 27 Nov 2013 11:49:08 -0800 (PST) Received: by 10.227.134.195 with HTTP; Wed, 27 Nov 2013 11:49:08 -0800 (PST) In-Reply-To: <5295B358.1040302@ericsson.com> References: <5295B358.1040302@ericsson.com> Date: Wed, 27 Nov 2013 11:49:08 -0800 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 19:49:14 -0000 On 27 November 2013 00:54, Magnus Westerlund wrote: > Today (27th November) is the last day to propose any additional > alternatives for the Video Codec Selection. Just to cover all bases, I think that there is one important option missing: X. The working group MUST make no MTI recommendation regarding video codecs. Just to put it on the table at this level. I suspect that many will prefer this over their most hated alternatives. From tim@phonefromhere.com Wed Nov 27 11:50:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5481ADF90 for ; Wed, 27 Nov 2013 11:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QqVsNxozsNW for ; Wed, 27 Nov 2013 11:50:56 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id 1679E1ADF9F for ; Wed, 27 Nov 2013 11:50:53 -0800 (PST) Received: (qmail 54862 invoked from network); 27 Nov 2013 19:50:52 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 13086 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 27 Nov 2013 19:50:52 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id BE5CF18A01EF; Wed, 27 Nov 2013 19:50:52 +0000 (GMT) Received: from [192.168.157.132] (unknown [192.67.4.35]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 4D6A318A0577; Wed, 27 Nov 2013 19:50:52 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_361D8A56-20EB-4844-BCDB-FA8B7B15977B" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: tim panton In-Reply-To: Date: Wed, 27 Nov 2013 19:50:52 +0000 Message-Id: References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> <52963FB9.7020002@bbs.darktech.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1822) Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 19:50:59 -0000 --Apple-Mail=_361D8A56-20EB-4844-BCDB-FA8B7B15977B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 27 Nov 2013, at 19:22, Eric Rescorla wrote: > On Wed, Nov 27, 2013 at 10:53 AM, cowwoc = wrote: >> On 27/11/2013 10:23 AM, Cullen Jennings (fluffy) wrote: >>>=20 >>> On Nov 26, 2013, at 10:26 PM, cowwoc = wrote: >>>=20 >>>>> 3. I asked for the ability to license multiple units at a time so = we >>>>> deploy images and applications without a separate plugin/download = process. >>>>>=20 >>>>> StW: if this is related to MPEG-LA (and not to the Cisco download >>>>> mechanism) the answer is simple. You, as an MPEG-LA sublicensee, = are >>>>> responsible for the correct accounting of the number of codecs you = =93sell=94 >>>>> (where =93sell=94 includes things like free download etc.). = MPEG-LA has the >>>>> right to audit you, and if they do and you are found cheating, = then there >>>>> are provisions for penalties. /StW >>>>=20 >>>> Good point. I guess I am asking about Cisco's mechanism, since it = is the >>>> one that we will be bound by. I guess this would be much simpler if = Cisco >>>> hit the licensing upper limit, because then we wouldn't need to = keep on >>>> counting. >>>>=20 >>>> Gili >>>=20 >>> Cisco is going to pay the cap - not because we think counting is = hard >>> (even CDNs allow easy counting) - but because we believe that the = Firefox >>> usage alone will greatly exceed the cap. >>=20 >>=20 >> So why can't we bundle the H.264 codec again? If you are already = hitting the >> cap, I don't see a reason to force us to download the codec = after-the-fact. >=20 > Because Cisco distributing the copies is what makes them, not you, > responsible for the license fee. >=20 If (and only if) you and your users meet some as-yet-to-be-defined = criteria. Unless Cisco is indemnifying all possible uses of the downloadable blob? T. > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_361D8A56-20EB-4844-BCDB-FA8B7B15977B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 27 Nov 2013, at 19:22, Eric = Rescorla <ekr@rtfm.com> = wrote:

On Wed, Nov 27, 2013 at 10:53 AM, = cowwoc <cowwoc@bbs.darktech.org> = wrote:
On 27/11/2013 10:23 AM, Cullen = Jennings (fluffy) wrote:

On Nov 26, = 2013, at 10:26 PM, cowwoc <cowwoc@bbs.darktech.org> = wrote:

3. I = asked for the ability to license multiple units at a time so = we
deploy images and applications without a separate plugin/download = process.

StW: if this is related to MPEG-LA (and not to the Cisco = download
mechanism) the answer is simple.  You, as an MPEG-LA = sublicensee, are
responsible for the correct accounting of the number = of codecs you =93sell=94
(where =93sell=94 includes things like free = download etc.).  MPEG-LA has the
right to audit you, and if they = do  and you are found cheating, then there
are provisions for = penalties. /StW

Good point. I guess I am asking = about Cisco's mechanism, since it is the
one that we will be bound = by. I guess this would be much simpler if Cisco
hit the licensing = upper limit, because then we wouldn't need to keep = on
counting.

Gili

Cisco is going to pay = the cap - not because we think counting is hard
(even CDNs allow easy = counting) - but because we believe that the Firefox
usage alone will = greatly exceed the cap.


So why can't we bundle = the H.264 codec again? If you are already hitting the
cap, I don't = see a reason to force us to download the codec = after-the-fact.

Because Cisco distributing the = copies is what makes them, not you,
responsible for the license = fee.


If (and only if) you = and your users meet some as-yet-to-be-defined criteria.
Unless = Cisco is indemnifying all possible uses of the downloadable = blob?

T.

-Ekr
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org= /mailman/listinfo/rtcweb

= --Apple-Mail=_361D8A56-20EB-4844-BCDB-FA8B7B15977B-- From pgiralt@cisco.com Wed Nov 27 12:19:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05ED41AE0F1 for ; Wed, 27 Nov 2013 12:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24IJu1uLReZX for ; Wed, 27 Nov 2013 12:19:03 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7841AE262 for ; Wed, 27 Nov 2013 12:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=791; q=dns/txt; s=iport; t=1385583251; x=1386792851; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/DRhtx8F9ldW16M6tI+3fOicO0fuPn9UZ7UKs6lU5ZQ=; b=OzFIzLaLANmq5y3yMBbMn1OuG58Glsb1bccYCzLVAtWMl5l7/k2c1+lz TLtSFBuNHgC38B0GhJBnWuWLa1tvVSyf+BAaBK6qCZQc6FDAmIN+adhVa HRyGPL0a+Upcv5LGBoiYGKe6Osszw5PBAk+BACwqgyKrLJBGzMB2CLVH8 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAAdSllKtJV2Z/2dsb2JhbABZgwc4uEhOgR8WdIIlAQEBAwEBAQE3NAsFCwsYLiEGMAYTh28DCQYNt28NiAITBIxxgV4zB4MggRMDiUKMZ4FrjFqFOYNHHg X-IronPort-AV: E=Sophos;i="4.93,784,1378857600"; d="scan'208";a="2755194" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 27 Nov 2013 20:14:10 +0000 Received: from rtp-pgiralt-8912.cisco.com (rtp-pgiralt-8912.cisco.com [10.116.101.35]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rARKE8jk031110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Nov 2013 20:14:09 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Paul Giralt In-Reply-To: Date: Wed, 27 Nov 2013 15:14:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5295B358.1040302@ericsson.com> To: Martin Thomson X-Mailer: Apple Mail (2.1812) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 20:19:06 -0000 How is that different from Option 7?=20 -Paul On Nov 27, 2013, at 2:49 PM, Martin Thomson = wrote: > On 27 November 2013 00:54, Magnus Westerlund > wrote: >> Today (27th November) is the last day to propose any additional >> alternatives for the Video Codec Selection. >=20 > Just to cover all bases, I think that there is one important option = missing: >=20 > X. The working group MUST make no MTI recommendation regarding video = codecs. >=20 > Just to put it on the table at this level. I suspect that many will > prefer this over their most hated alternatives. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From gmartincocher@blackberry.com Wed Nov 27 12:31:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433E31A1F7D for ; Wed, 27 Nov 2013 12:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNKK3VC8Xuq9 for ; Wed, 27 Nov 2013 12:31:01 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0F71ADF9F for ; Wed, 27 Nov 2013 12:31:01 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 Nov 2013 15:30:53 -0500 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 15:30:53 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 15:30:52 -0500 From: Gaelle Martin-Cocher To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] The Voting Process Thread-Index: AQHO65m19m9vCl4mUkGjCQkgFJ+S/Jo5skWAgAADH4CAAA8sgP//rKBA Date: Wed, 27 Nov 2013 20:30:51 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AA548AE102@XMB111CNC.rim.net> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <49D33D9F-BC65-4AE8-B98A-04D3C170F644@phonefromhere.com> <52964309.3060108@bbs.darktech.org> In-Reply-To: <52964309.3060108@bbs.darktech.org> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AA548AE102XMB111CNCrimnet_" MIME-Version: 1.0 Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 20:31:04 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AA548AE102XMB111CNCrimnet_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On the process: Could we try to reach a consensus by involving a multiple steps process? Could we structure the MTI question into three questions, with consensus be= ing declared on one before moving onto the next? This way the question is structured as to find the last point at which a co= nsensus can be achieved. This would look like: First step: determine the consensus for an MTI or not: 7. There is no MTI video codec Step two: determine the consensus for the "last resort" codec 6. All entities MUST support H.261 6. All entities MUST support H.263 9. All entities MUST support Theora Step three: determine if there is any further consensus on a better MTI pro= position: 1. All entities MUST support H.264 2. All entities MUST support VP8 3. All entities MUST support both H.264 and VP8 4. Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8 5. All entities MUST support at least one of H.264 and VP8 8. 5+$last_resort, i.e. All entities MUST support $last_resort and all entities MUST support at least one of H.264 and VP8 10. All entities MUST implement at least two of {VP8, H.264, $last_resort} 12. All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8 If there is no consensus at step 3, then use the consensus reached at step = 2. If a consensus for an MTI is reached at step 1, but there is no consensus a= t step 2, then no MTI would be defined. Sincerely, Ga=EBlle From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc Sent: Wednesday, November 27, 2013 2:08 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] The Voting Process If you could come up with an alternative that works, great. The only reason= we are voting is because all other options have failed. It is my understanding that we have the following options (from best to wor= st): 1. Come up with a better mechanism for establishing MTI, or 2. Vote for MTI, or 3. Give up and declare No MTI Gili On 27/11/2013 1:13 PM, Roman Shpount wrote: I am not sure about the rest of the group but from my point of view the pro= posed process clearly shows that IETF in general and this group in particul= ar is not equipped to vote. I also strongly disagree that voting would prod= uce a MTI video codec decision which would meaningful in any way. We need a= way to find consensus regarding the MTI or drop the whole MTI idea (which = would also require consensus). _____________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_92D0D52F3A63344CA478CF12DB0648AA548AE102XMB111CNCrimnet_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

On the process:

 <= /p>

Could we try to reach a c= onsensus by involving a multiple steps process?

Could we structure the MT= I question into three questions, with consensus being declared on one befor= e moving onto the next?

This way the question is = structured as to find the last point at which a consensus can be achieved.<= o:p>

 <= /p>

This would look like:

 <= /p>

First step: determine the= consensus for an MTI or not:

7. There is no MTI video = codec

 <= /p>

Step two: determine the c= onsensus for the "last resort" codec

6. All entities MUST supp= ort H.261

6. All entities MUST supp= ort H.263

9. All entities MUST supp= ort Theora

 <= /p>

Step three: determine if = there is any further consensus on a better MTI proposition:

1. All entities MUST supp= ort H.264

2. All entities MUST supp= ort VP8

3. All entities MUST supp= ort both H.264 and VP8

4. Browsers MUST support = both H.264 and VP8, other entities MUST

    suppor= t at least one of H.264 and VP8

5. All entities MUST supp= ort at least one of H.264 and VP8

8. 5+$last_resort, i.= e. All entities MUST support $last_resort and

    all en= tities MUST support at least one of H.264 and VP8

10. All entities MUST imp= lement at least two of {VP8, H.264, $last_resort}

12. All entities MUST sup= port decoding using both H.264 and VP8, and

    MUST s= upport encoding using at least one of H.264 or VP8

 <= /p>

If there is no consensus = at step 3, then use the consensus reached at step 2.

If a consensus for an MTI= is reached at step 1, but there is no consensus at step 2, then  no M= TI would be defined.

 <= /p>

Sincerely,

Ga=EBlle

 <= /p>

 <= /p>

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
Sent: Wednesday, November 27, 2013 2:08 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] The Voting Process

 


If you could come up with an alternative that works, great. The only reason= we are voting is because all other options have failed.

It is my understanding that we have the following options (from best to wor= st):

  1. Come up with a better mechanism for establishing MTI, or
    2. Vote for MTI, or
  2. Give up and declare No MTI

Gili

On 27/11/2013 1:13 PM, Roman Shpount wrote:

 

I am not sure about the rest of the group but from m= y point of view the proposed process clearly shows that IETF in general and= this group in particular is not equipped to vote. I also strongly disagree= that voting would produce a MTI video codec decision which would meaningful in any way. We need a way to find co= nsensus regarding the MTI or drop the whole MTI idea (which would also requ= ire consensus).

_____________
Roman Shpount

 




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.i=
etf.org/mailman/listinfo/rtcweb

 

---------------------------------------------------------------------
Th= is transmission (including any attachments) may contain confidential inform= ation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immed= iately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by uni= ntended recipients is not authorized and may be unlawful.
--_000_92D0D52F3A63344CA478CF12DB0648AA548AE102XMB111CNCrimnet_-- From bernard_aboba@hotmail.com Wed Nov 27 12:33:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53B01A1F7D for ; Wed, 27 Nov 2013 12:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6X9zAMyU7Xt for ; Wed, 27 Nov 2013 12:33:05 -0800 (PST) Received: from blu0-omc3-s31.blu0.hotmail.com (blu0-omc3-s31.blu0.hotmail.com [65.55.116.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3216D1A1F00 for ; Wed, 27 Nov 2013 12:33:05 -0800 (PST) Received: from BLU169-W38 ([65.55.116.72]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Nov 2013 12:33:04 -0800 X-TMN: [zNQ+fbns0WEVq+UJGF9JWyItDOZDgHvs] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_869db093-f7f4-4ebe-a6db-9cea8f2e2f3d_" From: Bernard Aboba To: Paul Giralt , Martin Thomson Date: Wed, 27 Nov 2013 12:33:04 -0800 Importance: Normal In-Reply-To: References: <5295B358.1040302@ericsson.com>, , MIME-Version: 1.0 X-OriginalArrivalTime: 27 Nov 2013 20:33:04.0939 (UTC) FILETIME=[DFF347B0:01CEEBAF] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 20:33:07 -0000 --_869db093-f7f4-4ebe-a6db-9cea8f2e2f3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It appears different because not only would it not choose an MTI codec from= among the present list of alternatives=2C but it also would take the MTI d= iscussion off the table in the future as well.=20 > From: pgiralt@cisco.com > Date: Wed=2C 27 Nov 2013 15:14:05 -0500 > To: martin.thomson@gmail.com > CC: rtcweb@ietf.org > Subject: Re: [rtcweb] Last day for any additional Video Codec Selection a= lternatives >=20 > How is that different from Option 7?=20 >=20 > -Paul >=20 > On Nov 27=2C 2013=2C at 2:49 PM=2C Martin Thomson wrote: >=20 > > On 27 November 2013 00:54=2C Magnus Westerlund > > wrote: > >> Today (27th November) is the last day to propose any additional > >> alternatives for the Video Codec Selection. > >=20 > > Just to cover all bases=2C I think that there is one important option m= issing: > >=20 > > X. The working group MUST make no MTI recommendation regarding video co= decs. > >=20 > > Just to put it on the table at this level. I suspect that many will > > prefer this over their most hated alternatives. > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_869db093-f7f4-4ebe-a6db-9cea8f2e2f3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It appears different because not= only would it not choose an MTI codec from among the present list of alter= natives=2C but it also would take the MTI discussion off the table in the f= uture as well. =3B

>=3B From: pgiralt@cisco.com
>= =3B Date: Wed=2C 27 Nov 2013 15:14:05 -0500
>=3B To: martin.thomson@gm= ail.com
>=3B CC: rtcweb@ietf.org
>=3B Subject: Re: [rtcweb] Last = day for any additional Video Codec Selection alternatives
>=3B
>= =3B How is that different from Option 7?
>=3B
>=3B -Paul
>= =3B
>=3B On Nov 27=2C 2013=2C at 2:49 PM=2C Martin Thomson <=3Bmart= in.thomson@gmail.com>=3B wrote:
>=3B
>=3B >=3B On 27 Novembe= r 2013 00:54=2C Magnus Westerlund
>=3B >=3B <=3Bmagnus.westerlund@= ericsson.com>=3B wrote:
>=3B >=3B>=3B Today (27th November) is t= he last day to propose any additional
>=3B >=3B>=3B alternatives f= or the Video Codec Selection.
>=3B >=3B
>=3B >=3B Just to co= ver all bases=2C I think that there is one important option missing:
>= =3B >=3B
>=3B >=3B X. The working group MUST make no MTI recommen= dation regarding video codecs.
>=3B >=3B
>=3B >=3B Just to p= ut it on the table at this level. I suspect that many will
>=3B >= =3B prefer this over their most hated alternatives.
>=3B >=3B ______= _________________________________________
>=3B >=3B rtcweb mailing l= ist
>=3B >=3B rtcweb@ietf.org
>=3B >=3B https://www.ietf.org/= mailman/listinfo/rtcweb
>=3B
>=3B ______________________________= _________________
>=3B rtcweb mailing list
>=3B rtcweb@ietf.org>=3B https://www.ietf.org/mailman/listinfo/rtcweb
=
= --_869db093-f7f4-4ebe-a6db-9cea8f2e2f3d_-- From cowwoc@bbs.darktech.org Wed Nov 27 12:40:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CBA1AE076 for ; Wed, 27 Nov 2013 12:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyEReTEh6Giw for ; Wed, 27 Nov 2013 12:40:37 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 085DA1A1F7D for ; Wed, 27 Nov 2013 12:40:36 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so12625051iec.23 for ; Wed, 27 Nov 2013 12:40:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=EEAwLmcK8itpXFwC6w8bLKNgW9mgl8ySSma/COAUN0g=; b=h9qJnR00wuN5iJILQlNL+UQMNcnayfhNP7bchM3CispyyZSOEZdUCHR/G7KRcjnvTK Njvy22OJhQise1s3ZKQpR9+K0gRQbrQM5BmeqHYwi5r3ScVrKGtTZVTBSx1aMOhLNjKO Uqrhgzai6TlmWTfHA79DqIrqjTlCiIigTcW9fAnTBOhJ/74pbyv95ROJnkG1FF26wcxD wlMmDVNq9ATS+NvNJjMFo2HMTF77kP7/dyKvyu/eaiyTHtJ3aEuKEb9Ix5NIHNlYh0oP K6h5hxVEgc4eNm+v5qh5t4jxEL9bN8tPpTtdIPJyLZm1sWlH3bETQWT4y32JUKtXbbO5 VYkw== X-Gm-Message-State: ALoCoQlz/OuSNQ++n2+WBt3QLOoXN1JEyUCtffCIhwMS9RbxAL3I4awTzp1x7yLeGUAuQKNStDXp X-Received: by 10.50.85.115 with SMTP id g19mr23620983igz.1.1385584836307; Wed, 27 Nov 2013 12:40:36 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id l7sm40921160igx.2.2013.11.27.12.40.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 12:40:35 -0800 (PST) Message-ID: <52965894.5020203@bbs.darktech.org> Date: Wed, 27 Nov 2013 15:39:48 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5295B358.1040302@ericsson.com>, , In-Reply-To: Content-Type: multipart/alternative; boundary="------------000906060200040900010703" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 20:40:41 -0000 This is a multi-part message in MIME format. --------------000906060200040900010703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Option 7 already implies that to me. I'm in favor of leaving the list as-is or amending #7. Gili On 27/11/2013 3:33 PM, Bernard Aboba wrote: > It appears different because not only would it not choose an MTI codec > from among the present list of alternatives, but it also would take > the MTI discussion off the table in the future as well. > > > From: pgiralt@cisco.com > > Date: Wed, 27 Nov 2013 15:14:05 -0500 > > To: martin.thomson@gmail.com > > CC: rtcweb@ietf.org > > Subject: Re: [rtcweb] Last day for any additional Video Codec > Selection alternatives > > > > How is that different from Option 7? > > > > -Paul > > > > On Nov 27, 2013, at 2:49 PM, Martin Thomson > wrote: > > > > > On 27 November 2013 00:54, Magnus Westerlund > > > wrote: > > >> Today (27th November) is the last day to propose any additional > > >> alternatives for the Video Codec Selection. > > > > > > Just to cover all bases, I think that there is one important > option missing: > > > > > > X. The working group MUST make no MTI recommendation regarding > video codecs. > > > > > > Just to put it on the table at this level. I suspect that many will > > > prefer this over their most hated alternatives. > > > _______________________________________________ > > > 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 --------------000906060200040900010703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Option 7 already implies that to me. I'm in favor of leaving the list as-is or amending #7.

Gili

On 27/11/2013 3:33 PM, Bernard Aboba wrote:
It appears different because not only would it not choose an MTI codec from among the present list of alternatives, but it also would take the MTI discussion off the table in the future as well. 

> From: pgiralt@cisco.com
> Date: Wed, 27 Nov 2013 15:14:05 -0500
> To: martin.thomson@gmail.com
> CC: rtcweb@ietf.org
> Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives
>
> How is that different from Option 7?
>
> -Paul
>
> On Nov 27, 2013, at 2:49 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> > On 27 November 2013 00:54, Magnus Westerlund
> > <magnus.westerlund@ericsson.com> wrote:
> >> Today (27th November) is the last day to propose any additional
> >> alternatives for the Video Codec Selection.
> >
> > Just to cover all bases, I think that there is one important option missing:
> >
> > X. The working group MUST make no MTI recommendation regarding video codecs.
> >
> > Just to put it on the table at this level. I suspect that many will
> > prefer this over their most hated alternatives.
> > _______________________________________________
> > 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

--------------000906060200040900010703-- From cowwoc@bbs.darktech.org Wed Nov 27 12:40:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFE21AE087 for ; Wed, 27 Nov 2013 12:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UtVMhkDD0vX for ; Wed, 27 Nov 2013 12:40:44 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD281A1F7D for ; Wed, 27 Nov 2013 12:40:44 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at1so12538910iec.21 for ; Wed, 27 Nov 2013 12:40:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KvGG1imzsged3C0vXzrGkSbWoFoTeiPCb4eLEwni/CA=; b=mvfLBgGonVdi71Irtm/b7wQH9wRjbLpl6GMkHdo88wMc9h6E3EnMYIBhoZibBIJrvr Cm95uIkRRftdO+xAYHaGl8E5A2fE26SrBSuhAs/WR6FCMaNu6eqoKiA9LIQ521Uu055P wf+r2/mSx95ovTG7Mn8K9x6pZXfRGrpgmshBMzZWBGWI1410loIuT3SDyxjiPb0pgKBG kggg0ksLyV6iakEpvcBNyAFROxldm07iF5KurCLKBMEkcHNsMYOIozO/ntzb2SEPK5co +vAIj67QN2YmMlpfK4WY7JEXHvooGBMq0JLmvglaLkonNJaZlFNM+VsgsyPn8zn6RD0o bH5Q== X-Gm-Message-State: ALoCoQnErsqBtV++bx0/OqWe13VqdOSVw05VNdffQt9L8u2QNnNWp9L63/J3FF5la471T663fqoJ X-Received: by 10.50.85.115 with SMTP id g19mr23621354igz.1.1385584844031; Wed, 27 Nov 2013 12:40:44 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id v9sm30906889igh.7.2013.11.27.12.40.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 12:40:43 -0800 (PST) Message-ID: <5296589D.9070009@bbs.darktech.org> Date: Wed, 27 Nov 2013 15:39:57 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Eric Rescorla References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> <52963FB9.7020002@bbs.darktech.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 20:40:46 -0000 On 27/11/2013 2:22 PM, Eric Rescorla wrote: > On Wed, Nov 27, 2013 at 10:53 AM, cowwoc wrote: >> On 27/11/2013 10:23 AM, Cullen Jennings (fluffy) wrote: >>> On Nov 26, 2013, at 10:26 PM, cowwoc wrote: >>> >>>>> 3. I asked for the ability to license multiple units at a time so we >>>>> deploy images and applications without a separate plugin/download process. >>>>> >>>>> StW: if this is related to MPEG-LA (and not to the Cisco download >>>>> mechanism) the answer is simple. You, as an MPEG-LA sublicensee, are >>>>> responsible for the correct accounting of the number of codecs you “sell” >>>>> (where “sell” includes things like free download etc.). MPEG-LA has the >>>>> right to audit you, and if they do and you are found cheating, then there >>>>> are provisions for penalties. /StW >>>> Good point. I guess I am asking about Cisco's mechanism, since it is the >>>> one that we will be bound by. I guess this would be much simpler if Cisco >>>> hit the licensing upper limit, because then we wouldn't need to keep on >>>> counting. >>>> >>>> Gili >>> Cisco is going to pay the cap - not because we think counting is hard >>> (even CDNs allow easy counting) - but because we believe that the Firefox >>> usage alone will greatly exceed the cap. >> >> So why can't we bundle the H.264 codec again? If you are already hitting the >> cap, I don't see a reason to force us to download the codec after-the-fact. > Because Cisco distributing the copies is what makes them, not you, > responsible for the license fee. Either you misunderstood my question or I am misunderstanding your answer. I'm asking what prevents us from bundling Cisco's binary as part of our installer or image? Originally we were told we could not bundle their binary in-line because Cisco had to count how many license units they were giving out, but now that they say they will hit the cap what is the point of counting? Gili From ekr@rtfm.com Wed Nov 27 12:43:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3C21ADE86 for ; Wed, 27 Nov 2013 12:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mFGOMMG9LMl for ; Wed, 27 Nov 2013 12:43:07 -0800 (PST) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 515BF1ADA5D for ; Wed, 27 Nov 2013 12:43:07 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so7260270wes.40 for ; Wed, 27 Nov 2013 12:43:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=wnDp2jHKlD7V9RlIxZRGWwePYxCQo7wTPe2B4pPZHWY=; b=OVkWyCkk8V2a5wSsv6bxCFq2VgpVCPdxIUb93exX7gPqqZHlsjW1vti26mTAUPMYm5 euvB3eWxAg3vM/qqD9ScHO5i/Yh3aECFb3T/xaP2j77Ck3s1jIOPNdLGwc0Ic1VCGoxN wZCeYrxNfYHcdky6YHz7rzF2m3n8i5Tq1RwIYgImW1JEn/qC/2+lxrkVPiun5nje59qH EoYascoCJYJIqkjSPrHD25aLlPA4QsNOB4ofdwwckvvN9oG8HZdCuQSl1/p1swyzcMKI HifNgYDHNrUrIBSiQOIQkfXz3ECxGJvZmsGyhGibuLWM4elN/Z27+KopPQAhuDUTRSJh 9BBQ== X-Gm-Message-State: ALoCoQmDnE/TpOJpOI9BzbBwk5yHPBygmZX79/iTgKtg6d2tH4gTBOOEjS2ndFsG6+gquuJZwa4F X-Received: by 10.180.211.71 with SMTP id na7mr24692412wic.5.1385584986077; Wed, 27 Nov 2013 12:43:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Wed, 27 Nov 2013 12:42:25 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: <5296589D.9070009@bbs.darktech.org> References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> <52963FB9.7020002@bbs.darktech.org> <5296589D.9070009@bbs.darktech.org> From: Eric Rescorla Date: Wed, 27 Nov 2013 12:42:25 -0800 Message-ID: To: cowwoc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 20:43:09 -0000 On Wed, Nov 27, 2013 at 12:39 PM, cowwoc wrote: > On 27/11/2013 2:22 PM, Eric Rescorla wrote: >> >> On Wed, Nov 27, 2013 at 10:53 AM, cowwoc wrote= : >>> >>> On 27/11/2013 10:23 AM, Cullen Jennings (fluffy) wrote: >>>> >>>> On Nov 26, 2013, at 10:26 PM, cowwoc wrote: >>>> >>>>>> 3. I asked for the ability to license multiple units at a time so we >>>>>> deploy images and applications without a separate plugin/download >>>>>> process. >>>>>> >>>>>> StW: if this is related to MPEG-LA (and not to the Cisco download >>>>>> mechanism) the answer is simple. You, as an MPEG-LA sublicensee, ar= e >>>>>> responsible for the correct accounting of the number of codecs you >>>>>> =93sell=94 >>>>>> (where =93sell=94 includes things like free download etc.). MPEG-LA= has >>>>>> the >>>>>> right to audit you, and if they do and you are found cheating, then >>>>>> there >>>>>> are provisions for penalties. /StW >>>>> >>>>> Good point. I guess I am asking about Cisco's mechanism, since it is >>>>> the >>>>> one that we will be bound by. I guess this would be much simpler if >>>>> Cisco >>>>> hit the licensing upper limit, because then we wouldn't need to keep = on >>>>> counting. >>>>> >>>>> Gili >>>> >>>> Cisco is going to pay the cap - not because we think counting is hard >>>> (even CDNs allow easy counting) - but because we believe that the >>>> Firefox >>>> usage alone will greatly exceed the cap. >>> >>> >>> So why can't we bundle the H.264 codec again? If you are already hittin= g >>> the >>> cap, I don't see a reason to force us to download the codec >>> after-the-fact. >> >> Because Cisco distributing the copies is what makes them, not you, >> responsible for the license fee. > > > Either you misunderstood my question or I am misunderstanding your answer= . > I'm asking what prevents us from bundling Cisco's binary as part of our > installer or image? What makes it a Cisco product is that it comes from Cisco, not that you make a bunch of copies and send it to people. > Originally we were told we could not bundle their binary > in-line because Cisco had to count how many license units they were givin= g > out, but now that they say they will hit the cap what is the point of > counting? I don't recall anyone saying that they had to count. What I recall them saying was that licensing restrictions required them to distribute the binary directly to end users. -Ekr From cowwoc@bbs.darktech.org Wed Nov 27 12:49:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFBD1ADFD7 for ; Wed, 27 Nov 2013 12:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DH4Ndw-iKyS for ; Wed, 27 Nov 2013 12:49:27 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 593E11ADFEC for ; Wed, 27 Nov 2013 12:49:27 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id qd12so12888389ieb.31 for ; Wed, 27 Nov 2013 12:49:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4gylYucMl/xu+MFfjdlC5li6Jajqeg5nIwVY0Mn0xJc=; b=XHh5l8cgc7u4SV5fENk82DFUf2NOlYTf+Om0VU8reHqDNWz5okvP7+ugDaceLtfpfo lNhkwVv9fIR49mXsJQ/sIZSBCvZglPFqC42YezhrC66fbGYkYqOAOVNt01eOcnoHaCZW QbhzkJXT0rSyThcQnpETXgAyBEyXx+Hr4esHOiLXi1bsxkoXpdpq3gSlRcR+rCS2nKlw jLZCS96Ea99M8VpCdyIPy9MpJukIvnV9h2CtNBxERcw2v4BfBPatSaWCJF9z5hwxM+PL VSwP32M8brBIT8oGHOw4ieyxu+buwTBNtwMkKsxkOx7XotpS6WaqH+gMAKdVcSYcmk8i zLVw== X-Gm-Message-State: ALoCoQmBWMXRJ7mN+QODPxigeGar/T/TSflFZDzl94zymmU/xnn3DYpdIgCLagmbrhtONwFmOs8p X-Received: by 10.50.73.164 with SMTP id m4mr23014857igv.7.1385585366708; Wed, 27 Nov 2013 12:49:26 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id k6sm40945141igx.8.2013.11.27.12.49.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 12:49:25 -0800 (PST) Message-ID: <52965AA6.3010100@bbs.darktech.org> Date: Wed, 27 Nov 2013 15:48:38 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Eric Rescorla References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> <52963FB9.7020002@bbs.darktech.org> <5296589D.9070009@bbs.darktech.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 20:49:29 -0000 On 27/11/2013 3:42 PM, Eric Rescorla wrote: > On Wed, Nov 27, 2013 at 12:39 PM, cowwoc wrote: >> On 27/11/2013 2:22 PM, Eric Rescorla wrote: >>> On Wed, Nov 27, 2013 at 10:53 AM, cowwoc wrote: >>>> On 27/11/2013 10:23 AM, Cullen Jennings (fluffy) wrote: >>>>> On Nov 26, 2013, at 10:26 PM, cowwoc wrote: >>>>> >>>>>>> 3. I asked for the ability to license multiple units at a time so we >>>>>>> deploy images and applications without a separate plugin/download >>>>>>> process. >>>>>>> >>>>>>> StW: if this is related to MPEG-LA (and not to the Cisco download >>>>>>> mechanism) the answer is simple. You, as an MPEG-LA sublicensee, are >>>>>>> responsible for the correct accounting of the number of codecs you >>>>>>> “sell” >>>>>>> (where “sell” includes things like free download etc.). MPEG-LA has >>>>>>> the >>>>>>> right to audit you, and if they do and you are found cheating, then >>>>>>> there >>>>>>> are provisions for penalties. /StW >>>>>> Good point. I guess I am asking about Cisco's mechanism, since it is >>>>>> the >>>>>> one that we will be bound by. I guess this would be much simpler if >>>>>> Cisco >>>>>> hit the licensing upper limit, because then we wouldn't need to keep on >>>>>> counting. >>>>>> >>>>>> Gili >>>>> Cisco is going to pay the cap - not because we think counting is hard >>>>> (even CDNs allow easy counting) - but because we believe that the >>>>> Firefox >>>>> usage alone will greatly exceed the cap. >>>> >>>> So why can't we bundle the H.264 codec again? If you are already hitting >>>> the >>>> cap, I don't see a reason to force us to download the codec >>>> after-the-fact. >>> Because Cisco distributing the copies is what makes them, not you, >>> responsible for the license fee. >> >> Either you misunderstood my question or I am misunderstanding your answer. >> I'm asking what prevents us from bundling Cisco's binary as part of our >> installer or image? > What makes it a Cisco product is that it comes from Cisco, not that you > make a bunch of copies and send it to people. > >> Originally we were told we could not bundle their binary >> in-line because Cisco had to count how many license units they were giving >> out, but now that they say they will hit the cap what is the point of >> counting? > I don't recall anyone saying that they had to count. What I recall them > saying was that licensing restrictions required them to distribute the > binary directly to end users. Makes sense, though if that's the case, what the heck was I discussing with Cullen on Wednesday night? :) Remember, we were talking about licensing a block of units at a time. Cullen, can you please shed some light on this? Thanks, Gili From martin.thomson@gmail.com Wed Nov 27 12:57:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7671ADEBA for ; Wed, 27 Nov 2013 12:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgs2uABjdYlW for ; Wed, 27 Nov 2013 12:57:09 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 62E9D1ADFFD for ; Wed, 27 Nov 2013 12:57:09 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id k14so4766155wgh.8 for ; Wed, 27 Nov 2013 12:57:08 -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=nchxoPCQm1FyuDHGg3VvA50G4eVXLIGFsSVfPw70Jc4=; b=MBSvYfPYmxwA+qdxNefmNUwBNxT50mXNlaxJijXakInI5G/x5+G5PZobPxYBnihOOi PyXRZMcPFJI68Lt7l6OlQZvC5Xnb32eSaMB9ZdTq+2JVFO+nqFtWybyg7vdIgkDAaT/c s1KkSmTh8lcn5l8nRxA2NLApAHpGi5MTTgVVZeppXFoXWOsvo6ma2dNCGl/4ah2xEHRH kXlS+Ozi/I4gB5txi9anDGbLiV5g3WyWtacvcDxlG02cYBD8TdeldMJPzrnUUYP2ghyp WS2u5WN9SJJFLRKAXPBrwQw8Y+i9XTzW+O418TMvPFgNgCgukeo3LXNxvzjPqPF2RDq0 HWFA== MIME-Version: 1.0 X-Received: by 10.180.20.102 with SMTP id m6mr24409251wie.22.1385585828400; Wed, 27 Nov 2013 12:57:08 -0800 (PST) Received: by 10.227.134.195 with HTTP; Wed, 27 Nov 2013 12:57:08 -0800 (PST) In-Reply-To: References: <5295B358.1040302@ericsson.com> Date: Wed, 27 Nov 2013 12:57:08 -0800 Message-ID: From: Martin Thomson To: Paul Giralt Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 20:57:11 -0000 My bad. Lost 7 in the middle of the list. On 27 November 2013 12:14, Paul Giralt wrote: > How is that different from Option 7? > > -Paul > > On Nov 27, 2013, at 2:49 PM, Martin Thomson wrote: > >> On 27 November 2013 00:54, Magnus Westerlund >> wrote: >>> Today (27th November) is the last day to propose any additional >>> alternatives for the Video Codec Selection. >> >> Just to cover all bases, I think that there is one important option missing: >> >> X. The working group MUST make no MTI recommendation regarding video codecs. >> >> Just to put it on the table at this level. I suspect that many will >> prefer this over their most hated alternatives. >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From sanjay.mishra@verizon.com Wed Nov 27 12:57:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D5E1ADFFD for ; Wed, 27 Nov 2013 12:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RUEx5_cC9u4 for ; Wed, 27 Nov 2013 12:57:51 -0800 (PST) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id A06381ADEBA for ; Wed, 27 Nov 2013 12:57:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe02.verizonbusiness.com with ESMTP; 27 Nov 2013 20:57:50 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="4.93,784,1378857600"; d="scan'208";a="601579434" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 27 Nov 2013 20:57:45 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Wed, 27 Nov 2013 15:57:43 -0500 To: "Cullen Jennings (fluffy)" , =?utf-8?B?SGVydsOp?= Date: Wed, 27 Nov 2013 15:57:42 -0500 Thread-Topic: [rtcweb] Video Codec Selection Alternatives - Timing Thread-Index: AQHO65/RWnplPSF720KudunmUkqDapo5jPZg Message-ID: <900A1E2059ADB149B905E3C8FA0046A62C80C15604@FHDP1LUMXC7V23.us.one.verizon.com> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <900A1E2059ADB149B905E3C8FA0046A62C80B27806@FHDP1LUMXC7V23.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec Selection Alternatives - Timing X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 20:57:54 -0000 Q3VsbGVuIC0tIEdvdCBpdC4gVGhhbmtzIGZvciBjbGFyaWZ5aW5nLg0KDQpIZXJ2ZSAtLSBUaGFu ayB5b3UgZm9yIHlvdXIgZS1tYWlsIG9uIHRoZSBzYW1lIGFzIHdlbGwuDQoNClRoYW5rIHlvdQ0K U2FuamF5DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ3VsbGVuIEplbm5pbmdz IChmbHVmZnkpIFttYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIE5v dmVtYmVyIDI3LCAyMDEzIDE6MzggUE0NClRvOiBNaXNocmEsIFNhbmpheQ0KQ2M6IE1hZ251cyBX ZXN0ZXJsdW5kOyBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBWaWRlbyBD b2RlYyBTZWxlY3Rpb24gQWx0ZXJuYXRpdmVzIC0gVGltaW5nDQoNCg0KU2FuamF5LCB0aGUgZmly c3Qgc3RlcCB3aWxsIGJlIHRvIGFzayBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdG8gdXNlIHRoZSBw cm9jZXNzLiBSaWdodCBub3cgd2UgaGF2ZSBiZWVuIGNvbGxlY3RpbmcgY29tbWVudHMgb24gdGhl IHByb2Nlc3MgdGhlbiBNYWdudXMgd2lsbCBzZW5kIG91dCBhIHJldmlzZWQgcHJvY2VzcyBhbmQg YSBjb25zZW5zdXMgY2FsbCB0byB1c2UgdGhhdCBwcm9jZXNzLiBJJ2QgZXhwZWN0IHRoYXQgY29u c2Vuc3VzIGNhbGwgdG8gYW5kIHJldmlzZWQgcHJvY2VzcyB0byBnbyBvdXQgdG9tb3Jyb3cgYXQg dGhlIGVhcmxpZXN0IGFuZCBwb3NzaWJseSBhIGJpdCBsYXRlci4gVGhhdCBjb25zZW5zdXMgY2Fs bCB3b3VsZCBsYXN0IHJvdWdobHkgMiB3ZWVrcy4gSWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIHVz ZSB0aGF0IHByb2Nlc3MgdGhlbiB0aGUgdm90aW5nIHBlcmlvZCB3b3VsZCBzdGFydCBhbmQgYmUg YXQgbGVhc3QgYSBmZXcgd2Vla3MgbG9uZyBidXQgYWRqdXN0ZWQgdG8gYmUgbG9uZ2VyIGlmIGl0 IHJhbiBvdmVyIGEgc2lnbmlmaWNhbnQgaG9saWRheS4gDQoNCg0KT24gTm92IDI3LCAyMDEzLCBh dCA5OjMzIEFNLCAiTWlzaHJhLCBTYW5qYXkiIDxzYW5qYXkubWlzaHJhQHZlcml6b24uY29tPiB3 cm90ZToNCg0KPiBNYWdudXMgLS0gVG8gY29uZmlybSwgdGhlIHZvdGluZyBwZXJpb2QgaXMgYmUg dHdvIHdlZWtzLCBzbyBJIGFtIGFzc3VtaW5nIHN0YXJ0aW5nIHRvbW9ycm93IChOb3YgMjgpIGFu ZCBsYXN0aW5nIGZvciB0d28gd2Vla3MgKERlYyAxMj8pLg0KPiANCj4gVGhhbmtzDQo+IFNhbmph eQ0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGN3ZWIgW21haWx0bzpy dGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hZ251cyANCj4gV2VzdGVybHVu ZA0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI3LCAyMDEzIDg6NDQgQU0NCj4gVG86IFRo b21hcyBSZWlzaW5nZXINCj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3J0 Y3dlYl0gVmlkZW8gQ29kZWMgU2VsZWN0aW9uIEFsdGVybmF0aXZlcyAxMCBhbmQgMTE6IE1lcmdl Pw0KPiANCj4gT24gMjAxMy0xMS0yNyAxNDoxNiwgVGhvbWFzIFJlaXNpbmdlciB3cm90ZToNCj4+ IE1hZ251cywNCj4+IA0KPj4gQ291bGQgeW91IHBsZWFzZSBzaGFyZSB0aGUgbGF0ZXN0IGxpc3Qg YW5kIGhvdyB0aGUgdm90aW5nIHdpbGwgYmUgY29uZHVjdGVkL3doYXQncyByZXF1aXJlZCB0byB2 b3RlLg0KPiANCj4gRm9yIHRoZSBwcm9wb3NlZCB2b3RpbmcgcHJvY2VzcyBzZWUgb3VyIHByZXZp b3VzIG1lc3NhZ2UgDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3 ZWIvY3VycmVudC9tc2cwOTkwOS5odG1sDQo+IA0KPiBBcyBJIHN0YXRlZCwgd2UgY2hhaXJzIHdp bGwgbmVlZCB0byB1cGRhdGUgdGhpcyBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbi4NCj4gDQo+IEZv ciB0aGUgY3VycmVudCBsaXN0IG9mIGFsdGVybmF0aXZlcyBpcyBvbiB0aGUgV0cncyB3aWtpOg0K PiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9ydGN3ZWIvdHJhYy93aWtpL1dpa2lTdGFy dA0KPiANCj4gDQo+IFJlcHJvZHVjZWQgaGVyZToNCj4gVGhlIGZvbGxvd2luZyBhbHRlcm5hdGl2 ZXMgaGFzIGJlZW4gcHJvcG9zZWQ6DQo+IA0KPiAxLiBBbGwgZW50aXRpZXMgTVVTVCBzdXBwb3J0 IEguMjY0DQo+IDIuIEFsbCBlbnRpdGllcyBNVVNUIHN1cHBvcnQgVlA4DQo+IDMuIEFsbCBlbnRp dGllcyBNVVNUIHN1cHBvcnQgYm90aCBILjI2NCBhbmQgVlA4ICA0LiBCcm93c2VycyBNVVNUIHN1 cHBvcnQgYm90aCBILjI2NCBhbmQgVlA4LCBvdGhlciBlbnRpdGllcyBNVVNUDQo+ICAgIHN1cHBv cnQgYXQgbGVhc3Qgb25lIG9mIEguMjY0IGFuZCBWUDggIDUuIEFsbCBlbnRpdGllcyBNVVNUIHN1 cHBvcnQgYXQgbGVhc3Qgb25lIG9mIEguMjY0IGFuZCBWUDggIDYuIEFsbCBlbnRpdGllcyBNVVNU IHN1cHBvcnQgSC4yNjEgIDcuIFRoZXJlIGlzIG5vIE1USSB2aWRlbyBjb2RlYyAgOC4gNSs2LCBp LmUuIEFsbCBlbnRpdGllcyBNVVNUIHN1cHBvcnQgSC4yNjEgYW5kIGFsbCBlbnRpdGllcyBNVVNU DQo+ICAgIHN1cHBvcnQgYXQgbGVhc3Qgb25lIG9mIEguMjY0IGFuZCBWUDggIDkuIEFsbCBlbnRp dGllcyBNVVNUIHN1cHBvcnQgVGhlb3JhIDEwLiBBbGwgZW50aXRpZXMgTVVTVCBpbXBsZW1lbnQg YXQgbGVhc3QgdHdvIG9mIHtWUDgsIEguMjY0LCBILjI2MX0gMTEuIEFsbCBlbnRpdGllcyBNVVNU IGltcGxlbWVudCBhdCBsZWFzdCB0d28gb2Yge1ZQOCwgSC4yNjQsIEguMjYzfSAxMi4gQWxsIGVu dGl0aWVzIE1VU1Qgc3VwcG9ydCBkZWNvZGluZyB1c2luZyBib3RoIEguMjY0IGFuZCBWUDgsIGFu ZA0KPiAgICBNVVNUIHN1cHBvcnQgZW5jb2RpbmcgdXNpbmcgYXQgbGVhc3Qgb25lIG9mIEguMjY0 IG9yIFZQOA0KPiANCj4gSC4yNjQgaXMgYSByZWZlcmVuY2UgdG8gdGhlIHByb3Bvc2FsIGluIOKA iyANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYnVybWFuLXJ0Y3dl Yi1oMjY0LXByb3Bvc2FsLw0KPiANCj4gVlA4IGlzIGEgcmVmZXJlbmNlIHRvIHRoZSBwcm9wb3Nh bCBpbiDigIsgDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFsdmVz dHJhbmQtcnRjd2ViLXZwOC8NCj4gDQo+IA0KPiANCj4+IA0KPj4gQ2hlZXJzLA0KPj4gDQo+PiBU aG9tYXMgUmVpc2luZ2VyDQo+PiANCj4+PiBPbiAyNy4xMS4yMDEzLCBhdCAwOTo1MCwgTWFnbnVz IFdlc3Rlcmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4g DQo+Pj4+IE9uIDIwMTMtMTEtMjUgMjA6NTEsIE1hcmt1cy5Jc29tYWtpQG5va2lhLmNvbSB3cm90 ZToNCj4+Pj4gTVVTVCBpbXBsZW1lbnQgYXQgbGVhc3QgdHdvIG9mIHtWUDgsIEguMjY0IENCUCwg SC4yNjF9DQo+Pj4gDQo+Pj4gSSBoYXZlIG5vdyB1cGRhdGVkIHRoZSBsaXN0IHRvIHJlYWQ6DQo+ Pj4gDQo+Pj4gMTAuIEFsbCBlbnRpdGllcyBNVVNUIGltcGxlbWVudCBhdCBsZWFzdCB0d28gb2Yg e1ZQOCwgSC4yNjQgQ0JQLCANCj4+PiBILjI2MX0gMTEuIEFsbCBlbnRpdGllcyBNVVNUIGltcGxl bWVudCBhdCBsZWFzdCB0d28gb2Yge1ZQOCwgSC4yNjQgDQo+Pj4gQ0JQLCBILjI2M30NCj4+PiAN Cj4+PiBDaGVlcnMNCj4+PiANCj4+PiBNYWdudXMgV2VzdGVybHVuZA0KPj4+IA0KPj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+Pj4gLQ0KPj4+IC0gTXVsdGltZWRpYSBUZWNobm9sb2dpZXMsIEVyaWNzc29uIFJl c2VhcmNoIEVBQi9UVk0NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gRXJpY3Nzb24gQUIgICAgICAg ICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4+PiBGw6Ryw7ZnYXRhbiA2ICAgICAg ICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+Pj4gU0UtMTY0IDgwIFN0b2NraG9s bSwgU3dlZGVufCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+Pj4gLQ0KPj4+IC0NCj4+PiANCj4+PiANCj4+IA0KPj4gDQo+IA0KPiANCj4g LS0NCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IE11bHRp bWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgy ODcNCj4gRsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3 OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1 bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4g cnRjd2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gcnRjd2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== From frodek@tele.no Wed Nov 27 12:59:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE371AE147 for ; Wed, 27 Nov 2013 12:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HelZXeDEsc0 for ; Wed, 27 Nov 2013 12:59:17 -0800 (PST) Received: from gorgon.tele.no (gorgon.tele.no [193.156.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 685D71AE14B for ; Wed, 27 Nov 2013 12:59:17 -0800 (PST) Received: from gorgon.tele.no ([193.156.17.70] helo=[IPv6:::1]) by gorgon.tele.no with esmtp (Exim 4.80) (envelope-from ) id 1VlmuT-0001AY-H9 for rtcweb@ietf.org; Wed, 27 Nov 2013 22:44:37 +0100 Message-ID: <52965CE7.2090506@tele.no> Date: Wed, 27 Nov 2013 21:58:15 +0100 From: Frode Kileng User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5295B358.1040302@ericsson.com> In-Reply-To: <5295B358.1040302@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Adding additional text to to all options X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 20:59:19 -0000 Hi, I guess this could wait, or is considered implicit by many, but I would propose that the following text is added to all options, i.e. similar to the text added to draft-ietf-rtcweb-audio-03: If other suitable video codecs are available to use, it is RECOMMENDED that they are also be included in the offer in order to maximize the possibility to establish the session without the need for video transcoding. It may help comforting "the losers" and be useful in sourcing processes within big companies... Best regards Frode Kileng From ted.ietf@gmail.com Wed Nov 27 13:36:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03E71ADED9 for ; Wed, 27 Nov 2013 13:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkaGwnT3NIRw for ; Wed, 27 Nov 2013 13:36:26 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id AC4141ADF38 for ; Wed, 27 Nov 2013 13:36:26 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id e14so12932127iej.14 for ; Wed, 27 Nov 2013 13:36:26 -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=a74KHRtXK75FJfcDgXFX9HJKkSJfw/K2t6VbT/LvzNo=; b=Bfr9qBMqnpCZ/rnJUQQUShpw9dpczFpjZ1P30dA6z2saDt/fUuf71u/oPa9+kcXKZO 3hSOcXCGnSYxQZuvfHDB7/NgLk58gYmpZHgdzoahtnIKsfoeS0VVse9I2hnq54K4b9Xt gpJhBMvmFkNXtA91BbUeRXP5ICZorILrXfhtnQwOKFaSzOmvyKnJVAl+cLXDmi2KgzGu SDj823/aSzbKm+Abq1xtuuuYfVojdW0GRq23avQosWYxcBnyQ13vqPY0upauTBAe8kIP HflFnNq4SUZ2ZQzKprEOXfrSkqBx6HtOdBxHcjV7PIfmmoIZ01Few5+PXV5hw3Dp8dC0 8dgQ== MIME-Version: 1.0 X-Received: by 10.50.61.205 with SMTP id s13mr23678101igr.29.1385588186005; Wed, 27 Nov 2013 13:36:26 -0800 (PST) Received: by 10.43.104.130 with HTTP; Wed, 27 Nov 2013 13:36:25 -0800 (PST) In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AA548AE06C@XMB111CNC.rim.net> References: <5295B358.1040302@ericsson.com> <5295DA58.60504@jitsi.org> <5295E663.4020607@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA548ADD3C@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AA548AE06C@XMB111CNC.rim.net> Date: Wed, 27 Nov 2013 13:36:25 -0800 Message-ID: From: Ted Hardie To: Gaelle Martin-Cocher Content-Type: multipart/alternative; boundary=047d7bd7679aa1c62504ec2f6362 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 21:36:30 -0000 --047d7bd7679aa1c62504ec2f6362 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 11:38 AM, Gaelle Martin-Cocher < gmartincocher@blackberry.com> wrote: > If we proceed with the vote, I would like to see the following choice: > All entities must support H263. > > Thanks > Ga=EBlle > > I've updated the wiki to include this as choice 13. If you have a reference that we could use that specifies version, annexes, or any other additional detail, we can include a pointer. Ted > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Gaelle > Martin-Cocher > Sent: Wednesday, November 27, 2013 11:29 AM > To: Magnus Westerlund; Emil Ivov > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Last day for any additional Video Codec Selection > alternatives > > Dear All, > > Sorry for this late message, I was not available this past week. > > It has been mentioned by a few of us that the risks on VP8 that some can'= t > leave with, can be mitigated when VP8 becomes an ISO standard (via MPEG). > VP8 has a chance to become an MPEG deliverable in January. I believe that > could make a few of us more comfortable with supporting/mandating both H2= 64 > and VP8 and could change the consensus reaching process. > > Can we give VP8 that chance before forcing a vote? > > Thanks > Sincerely, > Ga=EBlle > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: Wednesday, November 27, 2013 7:33 AM > To: Emil Ivov > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Last day for any additional Video Codec Selection > alternatives > > On 2013-11-27 12:41, Emil Ivov wrote: > > Just to confirm, this is NOT the last day of discussion on whether a > > vote is the right way to do this at all, right? > > No, but tomorrow a week will have passed since we chairs sent out the > proposal and solicited feedback on the proposal. > > > > > That sounds like it would still be an open question for step two here: > > > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html > > As we stated in this message, after the week we chairs would update the > process proposal if we considered it necessary. I believe there are some > clarifications that needs to be done, including the voter eligibility. > > After that the stated plan was to hold a consensus call in the WG to use > the proposed process. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawf= ul. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawf= ul. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bd7679aa1c62504ec2f6362 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 27, 2013 at 11:38 AM, Gaelle Martin-Cocher <gmartincocher@blackberry.com> wrote:
If we proceed wit= h the vote, I would like to see the following choice:
All entities must support H263.

Thanks
Ga=EBlle

<= br>
I've updated the wiki to include this as choice 13.=A0 If= you have a reference that we could use that specifies version, annexes, or= any other additional detail, we can include a pointer.

Ted
=A0

-----Original Message-----
From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of Gaelle Martin-Cocher
Sent: Wednesday, November 27, 2013 11:29 AM
To: Magnus Westerlund; Emil Ivov
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alt= ernatives

Dear All,

Sorry for this late message, I was not available this past week.

It has been mentioned by a few of us that the risks on VP8 that some can= 9;t leave with, can be mitigated when VP8 becomes an ISO standard (via MPEG= ).
VP8 has a chance to become an MPEG deliverable in January. I believe that c= ould make a few of us more comfortable with supporting/mandating both H264 = and VP8 and could change the consensus reaching process.

Can we give VP8 that chance before forcing a vote?

Thanks
Sincerely,
Ga=EBlle


-----Original Message-----
From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of Magnus Westerlund
Sent: Wednesday, November 27, 2013 7:33 AM
To: Emil Ivov
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alt= ernatives

On 2013-11-27 12:41, Emil Ivov wrote:
> Just to confirm, this is NOT the last day of discussion on whether a > vote is the right way to do this at all, right?

No, but tomorrow a week will have passed since we chairs sent out the propo= sal and solicited feedback on the proposal.

>
> That sounds like it would still be an open question for step two here:=
>
> http://www.ietf.org/mail-archive/web/rtcweb/curre= nt/msg09909.html

As we stated in this message, after the week we chairs would update the pro= cess proposal if we considered it necessary. I believe there are some clari= fications that needs to be done, including the voter eligibility.

After that the stated plan was to hold a consensus call in the WG to use th= e proposed process.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bd7679aa1c62504ec2f6362-- From engel.nyst@gmail.com Wed Nov 27 13:36:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FFE1AE00E for ; Wed, 27 Nov 2013 13:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO7VxkANQjvP for ; Wed, 27 Nov 2013 13:36:32 -0800 (PST) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id EEC041ADFEE for ; Wed, 27 Nov 2013 13:36:31 -0800 (PST) Received: by mail-ea0-f180.google.com with SMTP id f15so5138335eak.39 for ; Wed, 27 Nov 2013 13:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=d2g5uLoNgNLEaq/J8uOAciUNXGaIjoXzglsRM3OJ1Xo=; b=tMulgjYBfFkVm4oyvU3xM91KRwyFkPLR7/QXaFfm95w5DemeaGTyf7SXeb7YfaL18C CtZyj2gBR148Fog0lwTpQKu+zDkh8zG/5l3kdQH6uQolO5LVIuv3oWhO97YaIDUtKGiu 8B+xG9vkNIke9HEqN56fl5f2fghSu2DiYshQ1tjdiY/Iq6TnOhqf0D9Vm2RqaEsbFDS6 01rYg77NfKc1zKKdJhctaOKJsTSU84tYC8dzqgDmf3IOMkvuLX1BpXCP6govBHvcsQrU y4MUPKHp7s0Ux2YJsT2aqzUhJfsxc5tZUtM+n66xhsicHgaxE+k0BhYAmrvykJnyGY5k QWrQ== X-Received: by 10.14.221.193 with SMTP id r41mr884109eep.92.1385588190814; Wed, 27 Nov 2013 13:36:30 -0800 (PST) Received: from [192.168.1.33] ([109.100.150.49]) by mx.google.com with ESMTPSA id a51sm23421895eeh.8.2013.11.27.13.36.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 13:36:29 -0800 (PST) Message-ID: <529665D9.4040604@gmail.com> Date: Wed, 27 Nov 2013 23:36:25 +0200 From: Engel Nyst User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131104 Icedove/17.0.10 MIME-Version: 1.0 To: cowwoc References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> <52963FB9.7020002@bbs.darktech.org> <5296589D.9070009@bbs.darktech.org> In-Reply-To: <5296589D.9070009@bbs.darktech.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 21:38:17 -0000 On 11/27/2013 10:39 PM, cowwoc wrote: >>> So why can't we bundle the H.264 codec again? If you are already >>> hitting the >>> cap, I don't see a reason to force us to download the codec >>> after-the-fact. >> Because Cisco distributing the copies is what makes them, not you, >> responsible for the license fee. > > Either you misunderstood my question or I am misunderstanding your > answer. I'm asking what prevents us from bundling Cisco's binary as part > of our installer or image? Originally we were told we could not bundle > their binary in-line because Cisco had to count how many license units > they were giving out, but now that they say they will hit the cap what > is the point of counting? > MPEG-LA has not licensed the codec to anyone but Cisco, for an year if I understand correctly. Cisco pays the license fees for their distribution. Cisco's cap is for downloads from their site alone. Anyone else doesn't have a license from MPEG-LA. No one else can offer for download or reuse the codec implementation in their applications, unless they strike another deal with MPEG-LA. (or have very small uses, of no interest) It looks like essentially a trap, sorry to say. -- ~enyst "Excuse me, Professor Lessig, but may I ask you to sign this CLA, so that we have legally your permission to distribute your CC-licensed words?" ~ Permission culture, take two. From silviapfeiffer1@gmail.com Wed Nov 27 13:39:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5B61ADF96 for ; Wed, 27 Nov 2013 13:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUlnr8YjrHay for ; Wed, 27 Nov 2013 13:39:36 -0800 (PST) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7B41ADED9 for ; Wed, 27 Nov 2013 13:39:36 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id m1so8374255oag.3 for ; Wed, 27 Nov 2013 13:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=M0LnVPVtarQYWVlgca/70YDW645EqAUowwuxtcxy1ug=; b=Q9+Tnrvgeo29JmlV6FegE/w4E3//LvkUHFYaTgXKc83l4SRBklRuR1r13l1SAXn36c tdUQAalOuNLd5jwParuGgOGauih31bxp4mLSo8AH89nf2ebe1fVdB5mXrUA/J94BwZiH LG2cBxpIudgTMIYvRRi/lUTk1jcBjFRLuGVjz1yfZYIlZNtRIPHAdHJDjr+YbKPO+NJe 5c8e49mFWp9cf74g5vZOaJC2ZZivzB0068EzFAUwZXL+6UhjS0HyS6eRNK6Qr5f7KekL dIy+iiNnMSoAsMJkFdhiZ7+3zFlaeGg1UhcoJCuiSF7iVlrHQrjI5JEbfmZ6L4FWIXyU 0gkA== X-Received: by 10.60.93.67 with SMTP id cs3mr35649870oeb.12.1385588375436; Wed, 27 Nov 2013 13:39:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.68.106 with HTTP; Wed, 27 Nov 2013 13:39:14 -0800 (PST) In-Reply-To: References: <5295B358.1040302@ericsson.com> <5295DA58.60504@jitsi.org> <5295E663.4020607@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA548ADD3C@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AA548AE06C@XMB111CNC.rim.net> From: Silvia Pfeiffer Date: Thu, 28 Nov 2013 08:39:14 +1100 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 21:39:38 -0000 Could we please include also: All entities MUST implement at least two of {VP8, H.264 CBP, Theora} Thanks, Silvia. On Thu, Nov 28, 2013 at 8:36 AM, Ted Hardie wrote: > On Wed, Nov 27, 2013 at 11:38 AM, Gaelle Martin-Cocher > wrote: >> >> If we proceed with the vote, I would like to see the following choice: >> All entities must support H263. >> >> Thanks >> Ga=EBlle >> > > I've updated the wiki to include this as choice 13. If you have a refere= nce > that we could use that specifies version, annexes, or any other additiona= l > detail, we can include a pointer. > > Ted > >> >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Gaelle >> Martin-Cocher >> Sent: Wednesday, November 27, 2013 11:29 AM >> To: Magnus Westerlund; Emil Ivov >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Last day for any additional Video Codec Selection >> alternatives >> >> Dear All, >> >> Sorry for this late message, I was not available this past week. >> >> It has been mentioned by a few of us that the risks on VP8 that some can= 't >> leave with, can be mitigated when VP8 becomes an ISO standard (via MPEG)= . >> VP8 has a chance to become an MPEG deliverable in January. I believe tha= t >> could make a few of us more comfortable with supporting/mandating both H= 264 >> and VP8 and could change the consensus reaching process. >> >> Can we give VP8 that chance before forcing a vote? >> >> Thanks >> Sincerely, >> Ga=EBlle >> >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus >> Westerlund >> Sent: Wednesday, November 27, 2013 7:33 AM >> To: Emil Ivov >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Last day for any additional Video Codec Selection >> alternatives >> >> On 2013-11-27 12:41, Emil Ivov wrote: >> > Just to confirm, this is NOT the last day of discussion on whether a >> > vote is the right way to do this at all, right? >> >> No, but tomorrow a week will have passed since we chairs sent out the >> proposal and solicited feedback on the proposal. >> >> > >> > That sounds like it would still be an open question for step two here: >> > >> > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html >> >> As we stated in this message, after the week we chairs would update the >> process proposal if we considered it necessary. I believe there are some >> clarifications that needs to be done, including the voter eligibility. >> >> After that the stated plan was to hold a consensus call in the WG to use >> the proposed process. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute non-publ= ic >> information. Any use of this information by anyone other than the intend= ed >> recipient is prohibited. If you have received this transmission in error= , >> please immediately reply to the sender and delete this information from = your >> system. Use, dissemination, distribution, or reproduction of this >> transmission by unintended recipients is not authorized and may be unlaw= ful. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute non-publ= ic >> information. Any use of this information by anyone other than the intend= ed >> recipient is prohibited. If you have received this transmission in error= , >> please immediately reply to the sender and delete this information from = your >> system. Use, dissemination, distribution, or reproduction of this >> transmission by unintended recipients is not authorized and may be unlaw= ful. >> >> _______________________________________________ >> 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 > From mzanaty@cisco.com Wed Nov 27 13:42:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA951AE00E for ; Wed, 27 Nov 2013 13:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqG_1w9RdACH for ; Wed, 27 Nov 2013 13:42:47 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 45D521ADF71 for ; Wed, 27 Nov 2013 13:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1298; q=dns/txt; s=iport; t=1385588567; x=1386798167; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=3dd5b7E5TVBqPK2NFCL2W0UgM+76JSG0GsDhzmqtKk0=; b=HAStrfS4vfxPlogDoScd9tajx36bklFj6+l+lWwXWSO6IjCxhrI3U4Qy CDqsyPC7ufjbVGOXiVYH1o/V5hiN7qpvTBYAkBcGMWpWqNMzC6dovB1Xc Qpp/Avwka1Xjq29gMGPAArlDB0Exb+Vf+HZgfvwFTkbCtzjVmA0ZXa9b2 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAElmllKtJXG8/2dsb2JhbABZgweBC7lkFnSCLIELAQh4JwQBJodtwAYXkzwDiQqPCpITgymCKg X-IronPort-AV: E=Sophos;i="4.93,785,1378857600"; d="scan'208";a="287958602" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 27 Nov 2013 21:42:46 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rARLgkxW006407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 21:42:46 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 15:42:46 -0600 From: "Mo Zanaty (mzanaty)" To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Last day for any additional Video Codec Selection alternatives Thread-Index: AQHO67mcb3GqaKqJ/kqpXKe0fhw5BA== Date: Wed, 27 Nov 2013 21:42:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.150.30.48] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 21:42:48 -0000 Several folks have objected to a vote. Is it worthwhile to have an alternative that expresses this? =B3Voting MUST NOT be used to decide MTI video codec(s).=B2 I realize it is whacky to ask someone to vote to express an objection to voting. But otherwise, how will the chairs/ADs be able to reconcile the objections with the vote results? I=B9ve only seen a handful of voting objections, and only several dozen total voices expressing various opinions, while the rooms seemed packed with hundreds and the list has over a thousand subs. I have no idea where rough consensus lies in the larger community, nor how significant voting objections may be in that larger community. But that seems like useful, perhaps essential, information to know how to interpret the results. For example, if 40% objected to voting (as a first choice), that would immediately send a red flag no matter what result was ultimately selected via instant runoff. Conversely, if only 1% objected to voting, that may be less of a concern. Of course, a small minority of objectors may argue that is the essence of their objection to voting in the first place. I also support the option of not ranking any equally undesired alternatives. Especially for those who choose only the alternative above. Mo From silviapfeiffer1@gmail.com Wed Nov 27 13:54:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D3D1ADFA4 for ; Wed, 27 Nov 2013 13:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ODaAW0MkZlR for ; Wed, 27 Nov 2013 13:54:50 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1860A1AD93D for ; Wed, 27 Nov 2013 13:54:50 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so8123363obc.9 for ; Wed, 27 Nov 2013 13:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=w+dbl3a3CBF+tn5d62WnWUTDJxwCVE6QCRifNuIMnyI=; b=E7jPb6qaRR0AV25PQuxefuB+s7Y+1scDCYAuTN+xd5oQeQOPl0hCXGSeWO/vRAfSTB SkQPj5/BvGsXUQdaYZ5CZrZH5PTQKTDAl0qnqo2AjK7Uy+Tb5z66MAJw+ljGCJp8ODZ/ TLFm6vb9lQVYpTURJKEeUx4/YgzxzuU4FG0+skAgZjnb6lCaTzGD6HYtlVSIWYpsC9rR rl5mg6YWTiPN6R/5JSreAv5ABkgitG+qOGSeWVVWxsC4kYSiCo3a9qCM7+UbUNLSyTeJ lI11kKVcB5NmG7SiabzxVJicR4ssrnXwudClXzPcOWNDhCZ2adj7i+dQ7fYttIknW64L 0CeA== X-Received: by 10.182.215.202 with SMTP id ok10mr8081516obc.62.1385589289373; Wed, 27 Nov 2013 13:54:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.68.106 with HTTP; Wed, 27 Nov 2013 13:54:29 -0800 (PST) In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AA548AE102@XMB111CNC.rim.net> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <49D33D9F-BC65-4AE8-B98A-04D3C170F644@phonefromhere.com> <52964309.3060108@bbs.darktech.org> <92D0D52F3A63344CA478CF12DB0648AA548AE102@XMB111CNC.rim.net> From: Silvia Pfeiffer Date: Thu, 28 Nov 2013 08:54:29 +1100 Message-ID: To: Gaelle Martin-Cocher Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 21:54:52 -0000 That begs the question whether when voting one is allowed to click multiple boxes or just one. Silvia. On Thu, Nov 28, 2013 at 7:30 AM, Gaelle Martin-Cocher wrote: > On the process: > > > > Could we try to reach a consensus by involving a multiple steps process? > > Could we structure the MTI question into three questions, with consensus > being declared on one before moving onto the next? > > This way the question is structured as to find the last point at which a > consensus can be achieved. > > > > This would look like: > > > > First step: determine the consensus for an MTI or not: > > 7. There is no MTI video codec > > > > Step two: determine the consensus for the "last resort" codec > > 6. All entities MUST support H.261 > > 6. All entities MUST support H.263 > > 9. All entities MUST support Theora > > > > Step three: determine if there is any further consensus on a better MTI > proposition: > > 1. All entities MUST support H.264 > > 2. All entities MUST support VP8 > > 3. All entities MUST support both H.264 and VP8 > > 4. Browsers MUST support both H.264 and VP8, other entities MUST > > support at least one of H.264 and VP8 > > 5. All entities MUST support at least one of H.264 and VP8 > > 8. 5+$last_resort, i.e. All entities MUST support $last_resort and > > all entities MUST support at least one of H.264 and VP8 > > 10. All entities MUST implement at least two of {VP8, H.264, $last_resort= } > > 12. All entities MUST support decoding using both H.264 and VP8, and > > MUST support encoding using at least one of H.264 or VP8 > > > > If there is no consensus at step 3, then use the consensus reached at ste= p > 2. > > If a consensus for an MTI is reached at step 1, but there is no consensus= at > step 2, then no MTI would be defined. > > > > Sincerely, > > Ga=EBlle > > > > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc > Sent: Wednesday, November 27, 2013 2:08 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] The Voting Process > > > > > If you could come up with an alternative that works, great. The only reas= on > we are voting is because all other options have failed. > > It is my understanding that we have the following options (from best to > worst): > > Come up with a better mechanism for establishing MTI, or > Vote for MTI, or > Give up and declare No MTI > > Gili > > On 27/11/2013 1:13 PM, Roman Shpount wrote: > > > > I am not sure about the rest of the group but from my point of view the > proposed process clearly shows that IETF in general and this group in > particular is not equipped to vote. I also strongly disagree that voting > would produce a MTI video codec decision which would meaningful in any wa= y. > We need a way to find consensus regarding the MTI or drop the whole MTI i= dea > (which would also require consensus). > > _____________ > Roman Shpount > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from y= our > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawf= ul. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From jmvalin@mozilla.com Wed Nov 27 13:57:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CD51AD93D for ; Wed, 27 Nov 2013 13:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE9yvZSvk-03 for ; Wed, 27 Nov 2013 13:57:04 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id E17791AD937 for ; Wed, 27 Nov 2013 13:57:03 -0800 (PST) Received: from [192.168.1.15] (modemcable130.97-201-24.mc.videotron.ca [24.201.97.130]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id BA59AF23A2; Wed, 27 Nov 2013 13:57:02 -0800 (PST) Message-ID: <52966AAD.3080401@mozilla.com> Date: Wed, 27 Nov 2013 16:57:01 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Silvia Pfeiffer , "rtcweb@ietf.org" References: <5295B358.1040302@ericsson.com> <5295DA58.60504@jitsi.org> <5295E663.4020607@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA548ADD3C@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AA548AE06C@XMB111CNC.rim.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 21:57:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/27/2013 04:39 PM, Silvia Pfeiffer wrote: > Could we please include also: All entities MUST implement at least > two of {VP8, H.264 CBP, Theora} In practice, how does this differ from the option of having Theora as the single MTI? Jean-Marc > Thanks, Silvia. > > On Thu, Nov 28, 2013 at 8:36 AM, Ted Hardie > wrote: >> On Wed, Nov 27, 2013 at 11:38 AM, Gaelle Martin-Cocher >> wrote: >>> >>> If we proceed with the vote, I would like to see the following >>> choice: All entities must support H263. >>> >>> Thanks Gaëlle >>> >> >> I've updated the wiki to include this as choice 13. If you have >> a reference that we could use that specifies version, annexes, or >> any other additional detail, we can include a pointer. >> >> Ted >> >>> >>> >>> -----Original Message----- From: rtcweb >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Gaelle >>> Martin-Cocher Sent: Wednesday, November 27, 2013 11:29 AM To: >>> Magnus Westerlund; Emil Ivov Cc: rtcweb@ietf.org Subject: Re: >>> [rtcweb] Last day for any additional Video Codec Selection >>> alternatives >>> >>> Dear All, >>> >>> Sorry for this late message, I was not available this past >>> week. >>> >>> It has been mentioned by a few of us that the risks on VP8 that >>> some can't leave with, can be mitigated when VP8 becomes an ISO >>> standard (via MPEG). VP8 has a chance to become an MPEG >>> deliverable in January. I believe that could make a few of us >>> more comfortable with supporting/mandating both H264 and VP8 >>> and could change the consensus reaching process. >>> >>> Can we give VP8 that chance before forcing a vote? >>> >>> Thanks Sincerely, Gaëlle >>> >>> >>> -----Original Message----- From: rtcweb >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus >>> Westerlund Sent: Wednesday, November 27, 2013 7:33 AM To: Emil >>> Ivov Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last day for any >>> additional Video Codec Selection alternatives >>> >>> On 2013-11-27 12:41, Emil Ivov wrote: >>>> Just to confirm, this is NOT the last day of discussion on >>>> whether a vote is the right way to do this at all, right? >>> >>> No, but tomorrow a week will have passed since we chairs sent >>> out the proposal and solicited feedback on the proposal. >>> >>>> >>>> That sounds like it would still be an open question for step >>>> two here: >>>> >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html >>> >>> >>>> As we stated in this message, after the week we chairs would update the >>> process proposal if we considered it necessary. I believe there >>> are some clarifications that needs to be done, including the >>> voter eligibility. >>> >>> After that the stated plan was to hold a consensus call in the >>> WG to use the proposed process. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> ---------------------------------------------------------------------- >>> >>> Ericsson AB | Phone +46 10 7148287 >>> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >>> Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >>> >>> _______________________________________________ >>> rtcweb mailing list rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> --------------------------------------------------------------------- >>> >>> This transmission (including any attachments) may contain confidential >>> information, privileged material (including material protected >>> by the solicitor-client or other applicable privileges), or >>> constitute non-public information. Any use of this information >>> by anyone other than the intended recipient is prohibited. If >>> you have received this transmission in error, please >>> immediately reply to the sender and delete this information >>> from your system. Use, dissemination, distribution, or >>> reproduction of this transmission by unintended recipients is >>> not authorized and may be unlawful. >>> >>> _______________________________________________ rtcweb mailing >>> list rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> --------------------------------------------------------------------- >>> >>> This transmission (including any attachments) may contain confidential >>> information, privileged material (including material protected >>> by the solicitor-client or other applicable privileges), or >>> constitute non-public information. Any use of this information >>> by anyone other than the intended recipient is prohibited. If >>> you have received this transmission in error, please >>> immediately reply to the sender and delete this information >>> from your system. Use, dissemination, distribution, or >>> reproduction of this transmission by unintended recipients is >>> not authorized and may be unlawful. >>> >>> _______________________________________________ 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlmqtAAoJEJ6/8sItn9q9ducH/RxSc3qp1tetc6u+PVfK9tJL 8/kcZ4CTIQLhC1mfePvaQYFj/C0E1pPzigHE9I6Nrm/WtdrRZ3Ww95NQMU4WzP2N G9tUjczEdCp3nNpG0ADBYvb73Rgi9WhivzWRUqO7qW3ZUICi8TyfLKbYo1hflu0I UwH9cB9eu2B3X6YVW2yJBfvl3bSql3+drGxivoo5ByllzsfE0G3njyx4RxeT9UKU D8exv0OhMThFlBxXvyVJ59xm8p5CbXwuLKmnH6fAZJ23JVW3XZDhcV2Q0OUp6FPC 4zGQit7Wy1VPgRcl6oGTTKM/T4rH6BrUWsnwlJaIYmeN8uNtlrrhKPRfyuPNZOk= =KR44 -----END PGP SIGNATURE----- From ron@debian.org Wed Nov 27 14:04:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C1F1AD8EB for ; Wed, 27 Nov 2013 14:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt3a9KjNFXW9 for ; Wed, 27 Nov 2013 14:04:23 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 03A891AD937 for ; Wed, 27 Nov 2013 14:04:22 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail04.adl6.internode.on.net with ESMTP; 28 Nov 2013 08:34:22 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 0266D4F8F3 for ; Thu, 28 Nov 2013 08:34:20 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G-js-R6wxj9u for ; Thu, 28 Nov 2013 08:34:18 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id B957B4F902; Thu, 28 Nov 2013 08:34:18 +1030 (CST) Date: Thu, 28 Nov 2013 08:34:18 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131127220418.GR3245@audi.shelbyville.oz> References: <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <5295828A.4050506@bbs.darktech.org> <52963FB9.7020002@bbs.darktech.org> <5296589D.9070009@bbs.darktech.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] H.261 X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 22:04:24 -0000 On Wed, Nov 27, 2013 at 12:42:25PM -0800, Eric Rescorla wrote: > > On Wed, Nov 27, 2013 at 12:39 PM, cowwoc wrote: > > Either you misunderstood my question or I am misunderstanding your answer. > > I'm asking what prevents us from bundling Cisco's binary as part of our > > installer or image? > > What makes it a Cisco product is that it comes from Cisco, not that you > make a bunch of copies and send it to people. So, if I buy a video camera with H.264 support from some local store, are you saying that it's the retailer responsible for purchasing the licence? Or maybe it's the sweat-shop fabricator that's responsible for this? Who did my camera "come from" in this case? And are you by extension saying that I'm responsible for a 'unit' every time that Cisco binary is copied from disk storage to RAM? What if the disk it's on is in a NAS? Juries in Texas are going to love this. Ron From silviapfeiffer1@gmail.com Wed Nov 27 14:04:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE201AE0FA for ; Wed, 27 Nov 2013 14:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIlpXKkTU_oH for ; Wed, 27 Nov 2013 14:04:42 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C42F01AE04F for ; Wed, 27 Nov 2013 14:04:42 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id gq1so8070906obb.3 for ; Wed, 27 Nov 2013 14:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BkbBSgK9tK8kziYGIIP2Cky6yByW6/jv1WR0EKHQqXY=; b=yoHH2ZJy/IxRsHToKZuOihtDMlerROU/WnkiN0ln1/agh/WhRvBrYcgkVKIz1/2H/A Mlyx0em+W94TYHZq5jIimjyW773T9cWKuiDDOR81a0zR0d1USeV1KhmFq6xfiZxrJ94t te/JmnMdZQ61oQOubL03/sEWtzv76q6wjxRBYij14JNek9LGAW85BdkzWXG/BlHqCFg7 QLvEJ++eA8Llj7ay8IK/DHDdpe2Y7wByvsPfASKPPC85INRzWSwFqtPrWVnHdQpHgJyw tlCiWmgMyVsZbtnLifTAjsQPPPvbeH8OfmnoXHu/b6icQiy/kvc5XD+ZM+IIl3LHx+NO xPAg== X-Received: by 10.182.213.97 with SMTP id nr1mr12352949obc.48.1385589882182; Wed, 27 Nov 2013 14:04:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.68.106 with HTTP; Wed, 27 Nov 2013 14:04:20 -0800 (PST) In-Reply-To: <52966AAD.3080401@mozilla.com> References: <5295B358.1040302@ericsson.com> <5295DA58.60504@jitsi.org> <5295E663.4020607@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA548ADD3C@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AA548AE06C@XMB111CNC.rim.net> <52966AAD.3080401@mozilla.com> From: Silvia Pfeiffer Date: Thu, 28 Nov 2013 09:04:20 +1100 Message-ID: To: Jean-Marc Valin Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 22:04:48 -0000 On Thu, Nov 28, 2013 at 8:57 AM, Jean-Marc Valin wrote: > > On 11/27/2013 04:39 PM, Silvia Pfeiffer wrote: >> Could we please include also: All entities MUST implement at least >> two of {VP8, H.264 CBP, Theora} > > In practice, how does this differ from the option of having Theora as > the single MTI? > > Jean-Marc It gives people a choice between implementing VP8 or Theora in addition to H.264 (or between Theora and H.264 in addition to VP8). Silvia. BTW: I think the spec ref for Theora is http://www.theora.org/doc/Theora.pdf From cowwoc@bbs.darktech.org Wed Nov 27 14:06:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6821AE04F for ; Wed, 27 Nov 2013 14:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7wu4b6J_bPG for ; Wed, 27 Nov 2013 14:05:58 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id BC62B1AE066 for ; Wed, 27 Nov 2013 14:05:58 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so12670444ief.20 for ; Wed, 27 Nov 2013 14:05:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0nzGT2GzMqbkHTgpyMq36asHAM0BcIkThnLKfyjB/bM=; b=l+gT1Ubjv1mHNoxX8Up9WpuhfiGmQ/5npX+8DLoHK5u0UhM8bjWoN+Hq6OhRAcRwdC /DnhwyVVSaSdiCstAJxdxzeHyj4wi3TNTOBU3cdjr3oeJj50e26kffsfTewpJs6DGs1j kTFlVA5D+YsQlQye9/T874ug3IHHg8gxrGXIBhdjFMyMvl4JbhePMvpKkgHkICi41v+K AUewSQSDVc4d6n8qpRXYB/3ma/2EuKHS0tT9orqWMnQ5vEgcIyLhUyCnxGZNAiisBhJB JRlAwmAqqfKsFnmyQPUxoFYXrC5Kz3gYjX5+yRdfFv+dqaFlpi7CX1HA6Z/FiRQnGJko u1Lg== X-Gm-Message-State: ALoCoQkorlBTcScw2MmMVtbslY+yXvZd6OiFw9eqTpgeNl8qbaYnabTZGNYXoqUfU6sOeLdYgLLx X-Received: by 10.42.149.130 with SMTP id w2mr9569icv.64.1385589958146; Wed, 27 Nov 2013 14:05:58 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id da14sm1101319igc.1.2013.11.27.14.05.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 14:05:57 -0800 (PST) Message-ID: <52966C97.5020102@bbs.darktech.org> Date: Wed, 27 Nov 2013 17:05:11 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 22:06:00 -0000 Sounds to me like an issue that should be "voted on" before the actual vote. If voting proceeds, I am in favor of disqualifying any ballot that omits a ranking for a voting option. The entire point of this process is to look for a compromise, not to let people vote for their favorite option and nothing else. It is highly unlikely that anyone's 1st choice will end up winning. Gili On 27/11/2013 4:42 PM, Mo Zanaty (mzanaty) wrote: > Several folks have objected to a vote. Is it worthwhile to have an > alternative that expresses this? > > ³Voting MUST NOT be used to decide MTI video codec(s).² > > I realize it is whacky to ask someone to vote to express an objection to > voting. But otherwise, how will the chairs/ADs be able to reconcile the > objections with the vote results? I¹ve only seen a handful of voting > objections, and only several dozen total voices expressing various > opinions, while the rooms seemed packed with hundreds and the list has > over a thousand subs. I have no idea where rough consensus lies in the > larger community, nor how significant voting objections may be in that > larger community. But that seems like useful, perhaps essential, > information to know how to interpret the results. For example, if 40% > objected to voting (as a first choice), that would immediately send a red > flag no matter what result was ultimately selected via instant runoff. > Conversely, if only 1% objected to voting, that may be less of a concern. > Of course, a small minority of objectors may argue that is the essence of > their objection to voting in the first place. > > I also support the option of not ranking any equally undesired > alternatives. Especially for those who choose only the alternative above. > > Mo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Wed Nov 27 14:07:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB901ADF66 for ; Wed, 27 Nov 2013 14:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVPm8WkcybSM for ; Wed, 27 Nov 2013 14:07:42 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7AD1AD6A4 for ; Wed, 27 Nov 2013 14:07:42 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar20so13017940iec.16 for ; Wed, 27 Nov 2013 14:07:41 -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=NEXESCo4URTJ6J8JwROsRV6sU5x1sZik8CFmCKO8wSY=; b=NqlX7LqJwbM0oWQBpW/jlFPUYtIWfdxtK5WWPLD5eQlzMIhJF97OjbxEXIdq6heV+S 5PVrIPP9ItGFSRt8VqsHtu/gsQMV0GKlvo6gDeokG8SBaSIBFSzbjAw5bxskoG7IYjtq PZuFMI7jJfw8HFX2cLouGrpDm163XTGBiMrgeXpvPbu82iipGdwMel/K+oJB05iXTnCe JQ1fyZi45G8QQfbyBlNUmqZAFnpuFWPZp2bRKo9svhjVSoFyICHLxgs3rJgyd7IgJUS5 Lk/fWvF2egBWnwaHZWPGeDTA/Y0BzwbHrgzHDyHefJY8An21sbkjHqx5aCha6AxeMtzo cOWw== MIME-Version: 1.0 X-Received: by 10.43.178.135 with SMTP id ow7mr10271714icc.43.1385590061847; Wed, 27 Nov 2013 14:07:41 -0800 (PST) Received: by 10.43.104.130 with HTTP; Wed, 27 Nov 2013 14:07:41 -0800 (PST) In-Reply-To: References: <5295B358.1040302@ericsson.com> <5295DA58.60504@jitsi.org> <5295E663.4020607@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA548ADD3C@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AA548AE06C@XMB111CNC.rim.net> Date: Wed, 27 Nov 2013 14:07:41 -0800 Message-ID: From: Ted Hardie To: Silvia Pfeiffer Content-Type: multipart/alternative; boundary=001a11c30bec70df3e04ec2fd396 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 22:07:46 -0000 --001a11c30bec70df3e04ec2fd396 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 1:39 PM, Silvia Pfeiffer wrote: > Could we please include also: > All entities MUST implement at least two of {VP8, H.264 CBP, Theora} > > Added as item 14. Ted > Thanks, > Silvia. > > On Thu, Nov 28, 2013 at 8:36 AM, Ted Hardie wrote: > > On Wed, Nov 27, 2013 at 11:38 AM, Gaelle Martin-Cocher > > wrote: > >> > >> If we proceed with the vote, I would like to see the following choice: > >> All entities must support H263. > >> > >> Thanks > >> Ga=EBlle > >> > > > > I've updated the wiki to include this as choice 13. If you have a > reference > > that we could use that specifies version, annexes, or any other > additional > > detail, we can include a pointer. > > > > Ted > > > >> > >> > >> -----Original Message----- > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Gaelle > >> Martin-Cocher > >> Sent: Wednesday, November 27, 2013 11:29 AM > >> To: Magnus Westerlund; Emil Ivov > >> Cc: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Last day for any additional Video Codec Selectio= n > >> alternatives > >> > >> Dear All, > >> > >> Sorry for this late message, I was not available this past week. > >> > >> It has been mentioned by a few of us that the risks on VP8 that some > can't > >> leave with, can be mitigated when VP8 becomes an ISO standard (via > MPEG). > >> VP8 has a chance to become an MPEG deliverable in January. I believe > that > >> could make a few of us more comfortable with supporting/mandating both > H264 > >> and VP8 and could change the consensus reaching process. > >> > >> Can we give VP8 that chance before forcing a vote? > >> > >> Thanks > >> Sincerely, > >> Ga=EBlle > >> > >> > >> -----Original Message----- > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus > >> Westerlund > >> Sent: Wednesday, November 27, 2013 7:33 AM > >> To: Emil Ivov > >> Cc: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Last day for any additional Video Codec Selectio= n > >> alternatives > >> > >> On 2013-11-27 12:41, Emil Ivov wrote: > >> > Just to confirm, this is NOT the last day of discussion on whether a > >> > vote is the right way to do this at all, right? > >> > >> No, but tomorrow a week will have passed since we chairs sent out the > >> proposal and solicited feedback on the proposal. > >> > >> > > >> > That sounds like it would still be an open question for step two her= e: > >> > > >> > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html > >> > >> As we stated in this message, after the week we chairs would update th= e > >> process proposal if we considered it necessary. I believe there are so= me > >> clarifications that needs to be done, including the voter eligibility. > >> > >> After that the stated plan was to hold a consensus call in the WG to u= se > >> the proposed process. > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> ---------------------------------------------------------------------- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >> ---------------------------------------------------------------------- > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> --------------------------------------------------------------------- > >> This transmission (including any attachments) may contain confidential > >> information, privileged material (including material protected by the > >> solicitor-client or other applicable privileges), or constitute > non-public > >> information. Any use of this information by anyone other than the > intended > >> recipient is prohibited. If you have received this transmission in > error, > >> please immediately reply to the sender and delete this information fro= m > your > >> system. Use, dissemination, distribution, or reproduction of this > >> transmission by unintended recipients is not authorized and may be > unlawful. > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> --------------------------------------------------------------------- > >> This transmission (including any attachments) may contain confidential > >> information, privileged material (including material protected by the > >> solicitor-client or other applicable privileges), or constitute > non-public > >> information. Any use of this information by anyone other than the > intended > >> recipient is prohibited. If you have received this transmission in > error, > >> please immediately reply to the sender and delete this information fro= m > your > >> system. Use, dissemination, distribution, or reproduction of this > >> transmission by unintended recipients is not authorized and may be > unlawful. > >> > >> _______________________________________________ > >> 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 > --001a11c30bec70df3e04ec2fd396 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 27, 2013 at 1:39 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
Could we please include also:
All entities MUST implement at least two of {VP8, H.264 CBP, Theora}


Added as item 14.

Ted
=A0
Thanks,
Silvia.

On Thu, Nov 28, 2013 at 8:36 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> On Wed, Nov 27, 2013 at 11:38 AM, Gaelle Martin-Cocher
> <gmartincocher@blac= kberry.com> wrote:
>>
>> If we proceed with the vote, I would like to see the following cho= ice:
>> All entities must support H263.
>>
>> Thanks
>> Ga=EBlle
>>
>
> I've updated the wiki to include this as choice 13. =A0If you have= a reference
> that we could use that specifies version, annexes, or any other additi= onal
> detail, we can include a pointer.
>
> Ted
>
>>
>>
>> -----Original Message-----
>> From: rtcweb [mailto:rt= cweb-bounces@ietf.org] On Behalf Of Gaelle
>> Martin-Cocher
>> Sent: Wednesday, November 27, 2013 11:29 AM
>> To: Magnus Westerlund; Emil Ivov
>> Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Last day for any additional Video Codec Sele= ction
>> alternatives
>>
>> Dear All,
>>
>> Sorry for this late message, I was not available this past week. >>
>> It has been mentioned by a few of us that the risks on VP8 that so= me can't
>> leave with, can be mitigated when VP8 becomes an ISO standard (via= MPEG).
>> VP8 has a chance to become an MPEG deliverable in January. I belie= ve that
>> could make a few of us more comfortable with supporting/mandating = both H264
>> and VP8 and could change the consensus reaching process.
>>
>> Can we give VP8 that chance before forcing a vote?
>>
>> Thanks
>> Sincerely,
>> Ga=EBlle
>>
>>
>> -----Original Message-----
>> From: rtcweb [mailto:rt= cweb-bounces@ietf.org] On Behalf Of Magnus
>> Westerlund
>> Sent: Wednesday, November 27, 2013 7:33 AM
>> To: Emil Ivov
>> Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Last day for any additional Video Codec Sele= ction
>> alternatives
>>
>> On 2013-11-27 12:41, Emil Ivov wrote:
>> > Just to confirm, this is NOT the last day of discussion on wh= ether a
>> > vote is the right way to do this at all, right?
>>
>> No, but tomorrow a week will have passed since we chairs sent out = the
>> proposal and solicited feedback on the proposal.
>>
>> >
>> > That sounds like it would still be an open question for step = two here:
>> >
>> > http://www.ietf.org/mail-archive/web/rtc= web/current/msg09909.html
>>
>> As we stated in this message, after the week we chairs would updat= e the
>> process proposal if we considered it necessary. I believe there ar= e some
>> clarifications that needs to be done, including the voter eligibil= ity.
>>
>> After that the stated plan was to hold a consensus call in the WG = to use
>> the proposed process.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ------------------------------------------------------------------= ----
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ------------------------------------------------------------------= ----
>> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
>> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>> ------------------------------------------------------------------= ----
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> ------------------------------------------------------------------= ---
>> This transmission (including any attachments) may contain confiden= tial
>> information, privileged material (including material protected by = the
>> solicitor-client or other applicable privileges), or constitute no= n-public
>> information. Any use of this information by anyone other than the = intended
>> recipient is prohibited. If you have received this transmission in= error,
>> please immediately reply to the sender and delete this information= from your
>> system. Use, dissemination, distribution, or reproduction of this<= br> >> transmission by unintended recipients is not authorized and may be= unlawful.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> ------------------------------------------------------------------= ---
>> This transmission (including any attachments) may contain confiden= tial
>> information, privileged material (including material protected by = the
>> solicitor-client or other applicable privileges), or constitute no= n-public
>> information. Any use of this information by anyone other than the = intended
>> recipient is prohibited. If you have received this transmission in= error,
>> please immediately reply to the sender and delete this information= from your
>> system. Use, dissemination, distribution, or reproduction of this<= br> >> transmission by unintended recipients is not authorized and may be= unlawful.
>>
>> _______________________________________________
>> 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

--001a11c30bec70df3e04ec2fd396-- From derhoermi@gmx.net Wed Nov 27 14:31:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447F61AE00B for ; Wed, 27 Nov 2013 14:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra60oQjI5VDR for ; Wed, 27 Nov 2013 14:31:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 544C51ADFD2 for ; Wed, 27 Nov 2013 14:31:29 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.1.63]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0LnDof-1V9i7s0ajd-00hNqc for ; Wed, 27 Nov 2013 23:31:27 +0100 From: Bjoern Hoehrmann To: Magnus Westerlund Date: Wed, 27 Nov 2013 23:31:25 +0100 Message-ID: <38sc99tl8csfmfe6tgsm41ou2mrg6lhpgh@hive.bjoern.hoehrmann.de> References: <5295B358.1040302@ericsson.com> In-Reply-To: <5295B358.1040302@ericsson.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:5sbowpx5oMouxeZjUk57D1caGkBTzZ5eSUeMoWFys3TtN9JG7iP iborSjQVyCx9w8PhoK1x3Ywe060s6oefZFKmTk3DIo/tGfM+XbwL6fNFly5DZdClzaBPYke BAxQ5I6ONz/51u6/YdJQhAorrChskqR7EFeOvgCt06+woWmHweLISBRXjoecMGL/91gFuJE 9rVI1INoW1lLuDnDK1Myg== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 22:31:31 -0000 * Magnus Westerlund wrote: >Today (27th November) is the last day to propose any additional >alternatives for the Video Codec Selection. I would like to have available the following additional option: All entities MUST support decoding using Theora. Thank you. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From silviapfeiffer1@gmail.com Wed Nov 27 14:33:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1531AE087 for ; Wed, 27 Nov 2013 14:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0RO37a00_p0 for ; Wed, 27 Nov 2013 14:33:32 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 476151ADFD2 for ; Wed, 27 Nov 2013 14:33:32 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id j17so8483376oag.0 for ; Wed, 27 Nov 2013 14:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Yk6YWQ44r4NaWyWhSHLfX+JgU49KrL0v+T9v7Y91Mjk=; b=z72sbE2nrQM/CyYvMGMOAUwfTuRRAM03ksWja+a6GPuFuuSfXSJ/6zk9Zz3HB/vmoi NzvVDQXlC9lRCLqkGk2rv0nrfoK3Cjb/ig0HMg0/HIe8JIk2nLzm4LJ3s/UfKoBh2bEa Jocgm7+JIt+Y4wrBf+eNEkTeOHhl03hQvBIvNHVrCtpY8rfqK0Xm9LcPyGut/ZtzQv3L g+ax1THwOhY23rrzB3nd4doFg9U+OaXn08m2xbUydFGtbPoEmOUPi6Q+lJ1/2xV2CD1G /Wtj9QQNGMod8KtAHCa3TlPUycbVNbqec2NyoAvHc7YMPZoRgdfDomwJrKRoMrQYTib+ 2wrw== X-Received: by 10.182.194.5 with SMTP id hs5mr5658725obc.19.1385591611586; Wed, 27 Nov 2013 14:33:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.68.106 with HTTP; Wed, 27 Nov 2013 14:33:11 -0800 (PST) In-Reply-To: <38sc99tl8csfmfe6tgsm41ou2mrg6lhpgh@hive.bjoern.hoehrmann.de> References: <5295B358.1040302@ericsson.com> <38sc99tl8csfmfe6tgsm41ou2mrg6lhpgh@hive.bjoern.hoehrmann.de> From: Silvia Pfeiffer Date: Thu, 28 Nov 2013 09:33:11 +1100 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 22:33:34 -0000 On Thu, Nov 28, 2013 at 9:31 AM, Bjoern Hoehrmann wrote: > * Magnus Westerlund wrote: >>Today (27th November) is the last day to propose any additional >>alternatives for the Video Codec Selection. > > I would like to have available the following additional option: > > All entities MUST support decoding using Theora. So who encodes it? How is that different to option 9? Silvia. From derhoermi@gmx.net Wed Nov 27 14:39:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4995F1AE15B for ; Wed, 27 Nov 2013 14:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXYTQ6nDmqRb for ; Wed, 27 Nov 2013 14:39:56 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7CC1AE04F for ; Wed, 27 Nov 2013 14:39:56 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.1.63]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MBJF3-1Vtjqv2bJ7-00AECi for ; Wed, 27 Nov 2013 23:39:55 +0100 From: Bjoern Hoehrmann To: Silvia Pfeiffer Date: Wed, 27 Nov 2013 23:39:51 +0100 Message-ID: <9ssc99tnqdthectfc18q99926qt6dptfm1@hive.bjoern.hoehrmann.de> References: <5295B358.1040302@ericsson.com> <38sc99tl8csfmfe6tgsm41ou2mrg6lhpgh@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Vmn0X+2nCLGeVGdIEd0ufjJIjatPYHvj6Q+7pU5zUSx4/f3LJa+ nIkNA6JLWNLfcTnolQRuTfgq8Rmi3vT0jl9KImUDe75tyKD/JAs4ZmFTH/qLRveKZ2cVpmo 4lrkyXCa2qZvSwvYk79LB0fuvOSnKah4Q3Y6dVFGdXnCTFO8oXE8tvGPHVch0vB2tCU1YYT eKkFJ/3Zo40sNEcedF/0g== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 22:39:58 -0000 * Silvia Pfeiffer wrote: >On Thu, Nov 28, 2013 at 9:31 AM, Bjoern Hoehrmann wrote: >> * Magnus Westerlund wrote: >>>Today (27th November) is the last day to propose any additional >>>alternatives for the Video Codec Selection. >> >> I would like to have available the following additional option: >> >> All entities MUST support decoding using Theora. > >So who encodes it? How is that different to option 9? There would be no mandatory-to-implement video codec for encoding in "this" version of the specification should this option be selected. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From gmartincocher@blackberry.com Wed Nov 27 14:49:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5321AE15B for ; Wed, 27 Nov 2013 14:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKVB_r1QS7c9 for ; Wed, 27 Nov 2013 14:49:28 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF8B1AE0B5 for ; Wed, 27 Nov 2013 14:49:27 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 Nov 2013 17:49:24 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 17:49:23 -0500 From: Gaelle Martin-Cocher To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] The Voting Process Thread-Index: AQHO65m19m9vCl4mUkGjCQkgFJ+S/Jo5skWAgAADH4CAAA8sgP//rKBAgACIDgD//6ye0A== Date: Wed, 27 Nov 2013 22:49:23 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AA548AE629@XMB111CNC.rim.net> References: <52935C89.5040408@ericsson.com>, , <52936207.5040704@ericsson.com>, , <5295B273.1060305@ericsson.com>, , <5295F718.9010603@ericsson.com>, <20131127175414.GA87911@verdi>, <49D33D9F-BC65-4AE8-B98A-04D3C170F644@phonefromhere.com>, , <52964309.3060108@bbs.darktech.org>, <92D0D52F3A63344CA478CF12DB0648AA548AE102@XMB111CNC.rim.net> In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 22:49:31 -0000 Hi Herv=E9 -----Original Message----- From: Herv=E9 [mailto:h_o_w_@hotmail.com] = Sent: Wednesday, November 27, 2013 5:16 PM To: Gaelle Martin-Cocher; rtcweb@ietf.org Cc: Magnus Westerlund; John Leslie; tim panton; Roman Shpount; Ron; cowwoc;= Silvia Pfeiffer Subject: RE: [rtcweb] The Voting Process ________________________________ > From: gmartincocher@blackberry.com > To: rtcweb@ietf.org > Date: Wed, 27 Nov 2013 20:30:51 +0000 > Subject: Re: [rtcweb] The Voting Process > > > On the process: > > > > Could we try to reach a consensus by involving a multiple steps process? > > Could we structure the MTI question into three questions, with = > consensus being declared on one before moving onto the next? > > This way the question is structured as to find the last point at which = > a consensus can be achieved. > > > > This would look like: > > > > First step: determine the consensus for an MTI or not: > > 7. There is no MTI video codec > > > > Step two: determine the consensus for the "last resort" codec > > 6. All entities MUST support H.261 > > 6. All entities MUST support H.263 > > 9. All entities MUST support Theora > > > > Step three: determine if there is any further consensus on a better = > MTI > proposition: > > 1. All entities MUST support H.264 > > 2. All entities MUST support VP8 > > 3. All entities MUST support both H.264 and VP8 > > 4. Browsers MUST support both H.264 and VP8, other entities MUST > > support at least one of H.264 and VP8 > > 5. All entities MUST support at least one of H.264 and VP8 > > 8. 5+$last_resort, i.e. All entities MUST support $last_resort and > > all entities MUST support at least one of H.264 and VP8 > > 10. All entities MUST implement at least two of {VP8, H.264, = > $last_resort} > > 12. All entities MUST support decoding using both H.264 and VP8, and > > MUST support encoding using at least one of H.264 or VP8 > > > > If there is no consensus at step 3, then use the consensus reached at ste= p 2. > If a consensus for an MTI is reached at step 1, but there is no = > consensus at step 2, then no MTI would be defined. At that point, they just agreed there should be an MTI. [Gaelle] at that point we would have agreed that it would be ideal to have = an MTI but as we can't reach a consensus on any of them, then the conclusio= n is "while it would have been ideal, the group is unable to make a recomme= ndation, hence no MTI is defined". Is the "we won't get to your high quality codec unless you first agree abou= t these older ones" part to encourage people to reach consensus? [Gaelle] Those last_resort codecs are indeed far to be ideal but seems more= favorable to a consensus (from my perception of the discussions on the lis= t and of previous consensus calls). If we can't reach a consensus even on t= hose, then we don't move to step 3 as at that point it seem highly probable= that we would not reach a consensus at step 3 either. It should be noted t= hat some of the least controversial options in step 3 do not replace step 2= but are enhancing it. (e.g. option 8 and 10). At the contrary, if we reach a consensus at step 2, then at step 3, we may = either have enough desire to reach a consensus on one of the step 3 options= , or that would clearly indicate that the consensus reached at step 2 is "g= ood enough". = Since they're looking for consensus, they could agree to have any number ev= en no $last_resort in step 2, right? and then still proceed to step 3. Is that intentional? [gaelle] as proposed at the beginning, a consensus needs to be reached at e= ach step to proceed to the next. > Sincerely, > > Ga=EBlle Looks like it could be a long process, with many opportunities to come to t= he default state, no MTI. I think the voting process proposed by the WG Chairs could give about the s= ame information faster, especially if modified to use a condorcet method. But as far as consensus based processes go, I think Ga=EBlle's is preferabl= e to going straight to no MTI. - Herv=E9 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc > Sent: Wednesday, November 27, 2013 2:08 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] The Voting Process > > > > If you could come up with an alternative that works, great. The only = > reason we are voting is because all other options have failed. > > It is my understanding that we have the following options (from best = > to > worst): > > 1. Come up with a better mechanism for establishing MTI, or > 2. Vote for MTI, or > 3. Give up and declare No MTI > > Gili > > On 27/11/2013 1:13 PM, Roman Shpount wrote: > > > > I am not sure about the rest of the group but from my point of view = > the proposed process clearly shows that IETF in general and this group = > in particular is not equipped to vote. I also strongly disagree that = > voting would produce a MTI video codec decision which would meaningful = > in any way. We need a way to find consensus regarding the MTI or drop = > the whole MTI idea (which would also require consensus). > > _____________ > Roman Shpount > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential = > information, privileged material (including material protected by the = > solicitor-client or other applicable privileges), or constitute = > non-public information. Any use of this information by anyone other = > than the intended recipient is prohibited. If you have received this = > transmission in error, please immediately reply to the sender and = > delete this information from your system. Use, dissemination, = > distribution, or reproduction of this transmission by unintended = > recipients is not authorized and may be unlawful. > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb = --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From gmartincocher@blackberry.com Wed Nov 27 14:56:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332EF1ADFA4 for ; Wed, 27 Nov 2013 14:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwZTQeXIwGrF for ; Wed, 27 Nov 2013 14:56:56 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id A2E491ADF9A for ; Wed, 27 Nov 2013 14:56:56 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 Nov 2013 17:56:55 -0500 Received: from XCT110CNC.rim.net (10.65.161.210) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 17:56:55 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT110CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 17:56:54 -0500 From: Gaelle Martin-Cocher To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] The Voting Process Thread-Index: AQHO65m19m9vCl4mUkGjCQkgFJ+S/Jo5skWAgAADH4CAAA8sgP//rKBAgACB7ID//6/JwA== Date: Wed, 27 Nov 2013 22:56:53 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AA548AE656@XMB111CNC.rim.net> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <49D33D9F-BC65-4AE8-B98A-04D3C170F644@phonefromhere.com> <52964309.3060108@bbs.darktech.org> <92D0D52F3A63344CA478CF12DB0648AA548AE102@XMB111CNC.rim.net> In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 22:56:59 -0000 Hi Silvia, If there is a consensus on the 3 steps approach then we should start talkin= g about consensus call more than vote. If we reach step 2, as there is much less options in step 2 than in step 3,= we may be able to reach a consensus as per the usual IETF process. If we reach step 3 there might be an opportunity given to the group to refi= ne the list of options in step 3 to make the consensus call easier. = Sincerely, Ga=EBlle = -----Original Message----- From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] = Sent: Wednesday, November 27, 2013 4:54 PM To: Gaelle Martin-Cocher Cc: rtcweb@ietf.org Subject: Re: [rtcweb] The Voting Process That begs the question whether when voting one is allowed to click multiple= boxes or just one. Silvia. On Thu, Nov 28, 2013 at 7:30 AM, Gaelle Martin-Cocher wrote: > On the process: > > > > Could we try to reach a consensus by involving a multiple steps process? > > Could we structure the MTI question into three questions, with = > consensus being declared on one before moving onto the next? > > This way the question is structured as to find the last point at which = > a consensus can be achieved. > > > > This would look like: > > > > First step: determine the consensus for an MTI or not: > > 7. There is no MTI video codec > > > > Step two: determine the consensus for the "last resort" codec > > 6. All entities MUST support H.261 > > 6. All entities MUST support H.263 > > 9. All entities MUST support Theora > > > > Step three: determine if there is any further consensus on a better = > MTI > proposition: > > 1. All entities MUST support H.264 > > 2. All entities MUST support VP8 > > 3. All entities MUST support both H.264 and VP8 > > 4. Browsers MUST support both H.264 and VP8, other entities MUST > > support at least one of H.264 and VP8 > > 5. All entities MUST support at least one of H.264 and VP8 > > 8. 5+$last_resort, i.e. All entities MUST support $last_resort and > > all entities MUST support at least one of H.264 and VP8 > > 10. All entities MUST implement at least two of {VP8, H.264, = > $last_resort} > > 12. All entities MUST support decoding using both H.264 and VP8, and > > MUST support encoding using at least one of H.264 or VP8 > > > > If there is no consensus at step 3, then use the consensus reached at = > step 2. > > If a consensus for an MTI is reached at step 1, but there is no = > consensus at step 2, then no MTI would be defined. > > > > Sincerely, > > Ga=EBlle > > > > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc > Sent: Wednesday, November 27, 2013 2:08 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] The Voting Process > > > > > If you could come up with an alternative that works, great. The only = > reason we are voting is because all other options have failed. > > It is my understanding that we have the following options (from best = > to > worst): > > Come up with a better mechanism for establishing MTI, or Vote for MTI, = > or Give up and declare No MTI > > Gili > > On 27/11/2013 1:13 PM, Roman Shpount wrote: > > > > I am not sure about the rest of the group but from my point of view = > the proposed process clearly shows that IETF in general and this group = > in particular is not equipped to vote. I also strongly disagree that = > voting would produce a MTI video codec decision which would meaningful in= any way. > We need a way to find consensus regarding the MTI or drop the whole = > MTI idea (which would also require consensus). > > _____________ > Roman Shpount > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential = > information, privileged material (including material protected by the = > solicitor-client or other applicable privileges), or constitute = > non-public information. Any use of this information by anyone other = > than the intended recipient is prohibited. If you have received this = > transmission in error, please immediately reply to the sender and = > delete this information from your system. Use, dissemination, = > distribution, or reproduction of this transmission by unintended recipien= ts is not authorized and may be unlawful. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From cowwoc@bbs.darktech.org Wed Nov 27 14:57:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801721ADFAB for ; Wed, 27 Nov 2013 14:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEk3U_X5P1hh for ; Wed, 27 Nov 2013 14:57:43 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2854F1ADF9A for ; Wed, 27 Nov 2013 14:57:43 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id x13so12657797ief.24 for ; Wed, 27 Nov 2013 14:57:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qK72zOkBDCLzfJK+SUxJD9sLAfFZDPG0bjJVQfKRPeQ=; b=KbpYoeQDQDFPYkXSm3FtWXeKcCFBfvzSvDYyuSTPzSULhIQL/ytL2Rxst3Qw5blriJ 2wwdEaH+1uutGJYOzri4KLuYjXQZoMzJzDP8fFNq/zq8XSmrLMs6Usv+Mhd8VpXW8/71 3gt6DMmGFUWrMIY+1LuuhO1FspOF/CIPf7rFg/1w7jvY8pYscEOHwriSG5ri87uL/6Oa R8BtyvCCrFR49kYKmyAN0OXpHQPGoQYz9Uh24i0nGygigpf378DR7db9odqoshfboy9z bGcInT7rpT+cIJmoahtAnQSmyeZRGm7ijk1Nn6l3n3f1MksKLDd4PopXTYGDXX/InViQ 6BgQ== X-Gm-Message-State: ALoCoQk9JCN3CcV68w0++8X0mC5gsRyYmJbZb317upl9uh/Zo2RP9iwC5S5lOSbz1CI3uxrRZ0nT X-Received: by 10.43.132.66 with SMTP id ht2mr26092087icc.26.1385593062379; Wed, 27 Nov 2013 14:57:42 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id a17sm5772676ign.2.2013.11.27.14.57.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 14:57:41 -0800 (PST) Message-ID: <529678B7.1030508@bbs.darktech.org> Date: Wed, 27 Nov 2013 17:56:55 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5295B358.1040302@ericsson.com> <38sc99tl8csfmfe6tgsm41ou2mrg6lhpgh@hive.bjoern.hoehrmann.de> <9ssc99tnqdthectfc18q99926qt6dptfm1@hive.bjoern.hoehrmann.de> In-Reply-To: <9ssc99tnqdthectfc18q99926qt6dptfm1@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 22:57:44 -0000 On 27/11/2013 5:39 PM, Bjoern Hoehrmann wrote: > * Silvia Pfeiffer wrote: >> On Thu, Nov 28, 2013 at 9:31 AM, Bjoern Hoehrmann wrote: >>> * Magnus Westerlund wrote: >>>> Today (27th November) is the last day to propose any additional >>>> alternatives for the Video Codec Selection. >>> I would like to have available the following additional option: >>> >>> All entities MUST support decoding using Theora. >> So who encodes it? How is that different to option 9? > There would be no mandatory-to-implement video codec for encoding in > "this" version of the specification should this option be selected. This sounds like a cross-cutting concern that should be extracted from voting options (otherwise we'll end up with endless permutations). I think we could replace "MUST support X" with "MUST decode X" for all options and obviously implementations MUST encode at least one of the formats being decoded. Do we really need to specify which formats get encoded? Gili From emil@sip-communicator.org Wed Nov 27 15:32:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD51ADF7C for ; Wed, 27 Nov 2013 15:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P09Z0jXH-MNI for ; Wed, 27 Nov 2013 15:32:04 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6503D1ADE72 for ; Wed, 27 Nov 2013 15:32:04 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id ca18so102662wib.11 for ; Wed, 27 Nov 2013 15:32:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fFTsN59ohhVcnR0rDwk55tRPFDPYtyC8k3d/jYJNxvo=; b=l+8WyBjlUvmLwWTtudc15HpolN+1qjCIxrc17y+gUzufCVp0/IhhJ4HBfp0wo0FgyW qIY9GGEnn0CpztSWrR9snHBhBRI9jxEgXkhGSOnmaBKCv4+nu7Y9Yhh9Q04b8jHM3hbv tKyUB3vL/duNWi/0GgdzJQuhQ/xowLTODvDbgU+7ger8Exj3x1FB8FZ6JcILHjPih5c+ ZHjYpZpL9VESEM0mqZkaf690UletbT8f912d2W8kjdwK6kSWntHzkeIgHPX8gQAzwOt+ WxFdqpLm7Mxp+AgQo0nfwFRfL9Magr6uwlbyuy4c+4e9D8YKFRlQVtfTdXbxoEejIcta R/Zg== X-Gm-Message-State: ALoCoQkgS9LRUBvuOEpa/nHZm9bDg6zgVDmpjPPA/+ipECU7g4hgcOUG3myHGeX8u+pRLmvuIElr X-Received: by 10.180.103.193 with SMTP id fy1mr353176wib.10.1385595123211; Wed, 27 Nov 2013 15:32:03 -0800 (PST) Received: from camionet.local ([2a01:e35:8a04:14f0:e0dc:6c8b:ed3a:af2e]) by mx.google.com with ESMTPSA id w1sm39999431wib.6.2013.11.27.15.32.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 15:32:02 -0800 (PST) Message-ID: <529680EF.4010908@jitsi.org> Date: Thu, 28 Nov 2013 00:31:59 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Wed, 27 Nov 2013 23:32:06 -0000 On 27.11.13, 22:42, Mo Zanaty (mzanaty) wrote: > Several folks have objected to a vote. Is it worthwhile to have an > alternative that expresses this? > > =B3Voting MUST NOT be used to decide MTI video codec(s).=B2 > > I realize it is whacky to ask someone to vote to express an objection t= o > voting. It is indeed quite ironic. > But otherwise, how will the chairs/ADs be able to reconcile the > objections with the vote results? The same way we generally declare consensus or lack thereof. A vote=20 would be exactly as nonsensical here as for any other IETF decision. > I=B9ve only seen a handful of voting objections, I haven't seen any arguments against those objections. Just people=20 worried that if a vote does eventually happen their favorite option=20 might not be on the list. I haven't seen anyone explaining how any possible constituency would be=20 defended, how non-rights would be determined, or why it is IETFs=20 business at all to resolve questions after clearly proving it couldn't. > and only several dozen total voices expressing various > opinions, while the rooms seemed packed with hundreds and the list has > over a thousand subs. I have no idea where rough consensus lies in the > larger community, You seem to assume that rough consensus necessarily lies somewhere. It=20 doesn't. Sometimes people agree to disagree. > nor how significant voting objections may be in that > larger community. But that seems like useful, perhaps essential, > information to know how to interpret the results. For example, if 40% > objected to voting (as a first choice), What if 30% objected to voting as a third choice? > that would immediately send a red > flag no matter what result was ultimately selected via instant runoff. > Conversely, if only 1% objected to voting, that may be less of a concer= n. Or it may be game theory in action. It's an entirely new land where the=20 IETF has not ventured before. Doing so now cannot work! A vote in the=20 IETF is only a reason to contest the results forever and discredit the=20 work of this group. If we can't reach consensus then let's call it a day and leave another=20 body do the call if they feel comfortable with it. Emil --=20 https://jitsi.org From cowwoc@bbs.darktech.org Wed Nov 27 19:37:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214311AC828 for ; Wed, 27 Nov 2013 19:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM_cm1TJNWau for ; Wed, 27 Nov 2013 19:37:51 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDC21A8032 for ; Wed, 27 Nov 2013 19:37:51 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id e14so13796268iej.0 for ; Wed, 27 Nov 2013 19:37:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fq6XZ7zVh2GKZLLL+sEw+nOxRSWv28WZMLwepIVNjWM=; b=Yjp5SIqs+su96PmLESOw0IuqFaIk4jMl6b86u2TyO+jQnMJP+BiSCSlYtz32N4p8T/ bblVIOT/ksVWIk3ojXHKd9fh8Mn4/h8yG7jNs0QwafhGTuY8a00QifhUKDHOHHWOfIPH Og6fqX+hfWaGmKMHNef0j/uu3t7zHq8LwzmhykSjtV0s0EDs59A87LiQlu46RaFU22w2 FUPKYNYeNb0oMq63B1GVcjEZMIucp1XL3NDh18Kz4/swLS9XdwBAUY9Xn4bcPlMSOCOQ 294lAlQ3aFI9BtUe4fEiqX5KpsYVxRQoxuNyAeNMlCeLW1krA4qeqLHuPeJ+U2+8Okok 9N7Q== X-Gm-Message-State: ALoCoQmSkYQCzhgITGEzhibnbiKljcfJFL676aU8TGk+ANWNRE8vzO40h5Ss8Km8QuAVmP520RhX X-Received: by 10.50.117.3 with SMTP id ka3mr380963igb.15.1385609870199; Wed, 27 Nov 2013 19:37:50 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p14sm42290786igr.7.2013.11.27.19.37.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 19:37:49 -0800 (PST) Message-ID: <5296BA5E.20801@bbs.darktech.org> Date: Wed, 27 Nov 2013 22:37:02 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529680EF.4010908@jitsi.org> In-Reply-To: <529680EF.4010908@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 03:37:53 -0000 On 27/11/2013 6:31 PM, Emil Ivov wrote: > I haven't seen any arguments against those objections. Just people > worried that if a vote does eventually happen their favorite option > might not be on the list. I've heard objections along the lines of "IETF does not vote. We reach consensus by evaluating the technical merits of each argument and choose the one with the least number of objections". My counter-argument is that this isn't a technical question (we've reached consensus that both VP8 and H.264 are "good enough" from a technical point of view). This is a legal and political question. You can resolve the legal question by deferring to legal experts and political question by voting. That's how we ended up where we are today. > I haven't seen anyone explaining how any possible constituency would > be defended That is a legitimate concern, but I believe that with additional discussion we'll be able to reach a consensus on it. > You seem to assume that rough consensus necessarily lies somewhere. It > doesn't. Sometimes people agree to disagree. Anyone who feels this way should feel free to vote for "No MTI". > What if 30% objected to voting as a third choice? I suspect that if a substantial number of people vote for "No MTI" then it would warrant further investigation. I can't comment on what the actual threshold should be. > Or it may be game theory in action. It's an entirely new land where > the IETF has not ventured before. Doing so now cannot work! A vote in > the IETF is only a reason to contest the results forever and discredit > the work of this group. I don't agree. Giving up on MTI because of we have multiple good options and a very polarized community would be like throwing out the baby with the bathwater. People see a lot of arguing on the mailing list and mistake it for a lack of consensus. Where they see a lack of consensus, I see a good evaluation process that has fleshed out the technical and legal issues of each codec. My hope is that this will allow the community to make an informed decision. Gili From mzanaty@cisco.com Wed Nov 27 20:33:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82091AE0C1 for ; Wed, 27 Nov 2013 20:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeJmASUz02_O for ; Wed, 27 Nov 2013 20:33:41 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A9AF11ADF87 for ; Wed, 27 Nov 2013 20:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=586; q=dns/txt; s=iport; t=1385613221; x=1386822821; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qLSoxF9QnNAlDwmqTDV/2QUfr4sH+vYpagP/dcTxt9A=; b=A9Hml3nYgftjctggetiP9tinCQLHE2Y5+fsZ41LmoP7W5oFfhvy+WyDC xlHeUzlDoKD4/bF126i2UqgSCsZbEbQbKtaJEIV4pwXDEaZPA3aed6Vty qhPgxLtQldw+bAFswBEpcG0lwmJNoL4zkW8pRVOlq8MnYdu2R5EbFjMIG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAG7HllKtJXG//2dsb2JhbABZgweBC7hEgR8WdIIlAQEBBHkQAgEIDgouMiUCBA4FiAG/bBePAgeEMwOJCo8KkhODKYIq X-IronPort-AV: E=Sophos;i="4.93,788,1378857600"; d="scan'208";a="288131069" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 28 Nov 2013 04:33:37 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAS4XaxS000599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Nov 2013 04:33:36 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 22:33:36 -0600 From: "Mo Zanaty (mzanaty)" To: Emil Ivov Thread-Topic: [rtcweb] Last day for any additional Video Codec Selection alternatives Thread-Index: AQHO6/MADuQaJxvLekG6Km6teA6Taw== Date: Thu, 28 Nov 2013 04:33:36 +0000 Message-ID: References: <529680EF.4010908@jitsi.org> In-Reply-To: <529680EF.4010908@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.213.54] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <87B334C3FDDAD0468BDFF17A0130FA9A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 04:33:43 -0000 On 11/27/13, 6:31 PM, Emil Ivov wrote: > On 27.11.13, 22:42, Mo Zanaty (mzanaty) wrote: >> Several folks have objected to a vote. Is it worthwhile to have an >> alternative that expresses this? >> "Voting MUST NOT be used to decide MTI video codec(s).=B2 >> I realize it is whacky to ask someone to vote to express an objection >> to voting. > It is indeed quite ironic. And quite idiotic. Since we will have a normal consensus call starting soon to accept or reject this alternative process, which I completely overlooked. Sorry for the stupid suggestion. From andrew.hutton@unify.com Wed Nov 27 23:44:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5DA1AE182 for ; Wed, 27 Nov 2013 23:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y79Ky5ePkoXt for ; Wed, 27 Nov 2013 23:44:06 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 39D4E1AC7EE for ; Wed, 27 Nov 2013 23:44:06 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id E042C1EB85CA; Thu, 28 Nov 2013 08:44:04 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 08:44:04 +0100 From: "Hutton, Andrew" To: Emil Ivov Thread-Topic: [rtcweb] Last day for any additional Video Codec Selection alternatives Thread-Index: AQHO68jmMsNzl/GA5k+N2jf2CqzHjZo6Q6aN Date: Thu, 28 Nov 2013 07:44:03 +0000 Message-ID: <384FC86B-9D26-41AF-8A79-9EB76609049E@siemens-enterprise.com> References: ,<529680EF.4010908@jitsi.org> In-Reply-To: <529680EF.4010908@jitsi.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 07:44:08 -0000 +1 to Emil's comments seems some people have forgotten that the first phase= of this process is a consensus call on whether to go ahead with voting or = not. I am still hoping it won't come to a vote which is unknown territory for th= e IETF and unlikely to provide any good result. Andy On 27 Nov 2013, at 23:32, "Emil Ivov" wrote: > On 27.11.13, 22:42, Mo Zanaty (mzanaty) wrote: >> Several folks have objected to a vote. Is it worthwhile to have an >> alternative that expresses this? >>=20 >> =B3Voting MUST NOT be used to decide MTI video codec(s).=B2 >>=20 >> I realize it is whacky to ask someone to vote to express an objection to >> voting. >=20 > It is indeed quite ironic. >=20 >> But otherwise, how will the chairs/ADs be able to reconcile the >> objections with the vote results? >=20 > The same way we generally declare consensus or lack thereof. A vote would= be exactly as nonsensical here as for any other IETF decision. >=20 >> I=B9ve only seen a handful of voting objections, >=20 > I haven't seen any arguments against those objections. Just people worrie= d that if a vote does eventually happen their favorite option might not be = on the list. >=20 > I haven't seen anyone explaining how any possible constituency would be d= efended, how non-rights would be determined, or why it is IETFs business at= all to resolve questions after clearly proving it couldn't. >=20 >> and only several dozen total voices expressing various >> opinions, while the rooms seemed packed with hundreds and the list has >> over a thousand subs. I have no idea where rough consensus lies in the >> larger community, >=20 > You seem to assume that rough consensus necessarily lies somewhere. It do= esn't. Sometimes people agree to disagree. >=20 >> nor how significant voting objections may be in that >> larger community. But that seems like useful, perhaps essential, >> information to know how to interpret the results. For example, if 40% >> objected to voting (as a first choice), >=20 > What if 30% objected to voting as a third choice? >=20 >> that would immediately send a red >> flag no matter what result was ultimately selected via instant runoff. >> Conversely, if only 1% objected to voting, that may be less of a concern= . >=20 > Or it may be game theory in action. It's an entirely new land where the I= ETF has not ventured before. Doing so now cannot work! A vote in the IETF i= s only a reason to contest the results forever and discredit the work of th= is group. >=20 > If we can't reach consensus then let's call it a day and leave another bo= dy do the call if they feel comfortable with it. >=20 > Emil >=20 >=20 > --=20 > https://jitsi.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Markus.Isomaki@nokia.com Thu Nov 28 00:30:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4604A1AD6D1 for ; Thu, 28 Nov 2013 00:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJKKGQmcOPL8 for ; Thu, 28 Nov 2013 00:30:21 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id D1D931AD84D for ; Thu, 28 Nov 2013 00:30:20 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rAS8MxIO029924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Thu, 28 Nov 2013 10:23:00 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.177]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.03.0158.002; Thu, 28 Nov 2013 08:22:59 +0000 From: To: Thread-Topic: Video codec selection: Dropping options Thread-Index: Ac7sDy85pPAEQkadSWWa4C8bEEktTw== Date: Thu, 28 Nov 2013 08:22:59 +0000 Message-ID: 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; x-titus-version: 3.5.9.3 x-headerinfofordlp: x-tituslabs-classificationhash-30: 7dNHFIWeM+LwDx2hQ+BXFjVJPDrlSQ9nKjS5OO31/C4SomrglQ4UHSvHQodIw3BM0cJV5E1qkwTVAQXGAYYX6Z1hF/UVFHUyQneDTOhPrMeiEZHt+eDzE9guu2n44KBwIs7o1Blm6ko6zTFjeEO1Olt8mRUYHzXUpfjQSPzg/9yL9qB+PTlcNR8M2WT0Xk4Qyr4sEzZm/JjFI0Ef76r732V0KwyAqXzA0woDGgQHj9I= x-originating-ip: [10.163.22.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Subject: [rtcweb] Video codec selection: Dropping options X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 08:30:23 -0000 Hi, I'm not much in favor of the voting, but if we do it: Based on the consensus call we already held in Vancouver, I would propose t= o drop from the list in [1] any options that make exclusively VP8 mandatory= to implement or exclusively H.264 mandatory to implement. I think we have = already established that much, and including those options in any vote seem= s wrong.=20 In practice I'm talking about these four options: 1. All entities MUST support H.264 2. All entities MUST support VP8 3. All entities MUST support both H.264 and VP8=20 4. Browsers MUST support both H.264 and VP8, other entities MUST support at= least one of H.264 and VP8 What the WG should focus on is to see if there is a consensus on any of the= so called "fallback" options vs. no MTI. I think these are all valid as su= ch as a "fallback": 5. All entities MUST support at least one of H.264 and VP8 6. All entities MUST support H.261 7. There is no MTI video codec 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST support = at least one of H.264 and VP8 9. All entities MUST support Theora 10. All entities MUST implement at least two of {VP8, H.264, H.261} 11. All entities MUST implement at least two of {VP8, H.264, H.263} 12. All entities MUST support decoding using both H.264 and VP8, and MUST s= upport encoding using at least one of H.264 or VP8 13. All entities MUST support H.263 14. All entities MUST implement at least two of {VP8, H.264 CBP, Theora} 15. All entities MUST support decoding using Theora. I think it would be problematic even if one of options 1-4 came out as a wi= nner from a voting procedure, since it would force a large part of the comm= unity to implement something they have valid reasons to avoid. Some of the = options 5-15 may have issues as well, but at least a consensus call among t= hem would still be in order, since we haven't really had it so far. And pre= sumably the issues and polarization are "smaller" than with the VP8 vs. H.2= 64 argument.=20 Regards, Markus [1] http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart =20 From lgeyser@gmail.com Thu Nov 28 02:20:29 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B071ADF47 for ; Thu, 28 Nov 2013 02:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH2JhX1IYe5T for ; Thu, 28 Nov 2013 02:20:27 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1746F1ADF46 for ; Thu, 28 Nov 2013 02:20:26 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id q8so5997226lbi.16 for ; Thu, 28 Nov 2013 02:20:25 -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=vdhAWXXCs66C48bewr/irODpSymNk+37da51g8tkv18=; b=U5XdE0YB9LeHFqN7ixk5xyX2ZzOEEKZrrrP9tavsR2dfPFJE6XKi/EKR2Whi6iNcyA BSFO2JWJ4h/I3ByRr2hj4t3NZUJkQCmgktH9oNUN54M7wC67b0rt+3m5urwYOMUg203P Ww61eYk1/JSd0+YVFzi0OvCwGYuQIRpCsPXi0Iwik6zx8MFLPITEeMGj2eBE0szpZcRD DRRZYZp9DVzKP1mCO3plwH0fTCZD+X11VZjQB4pJaBtTI1eTEdYcabLCXjeSp0qIBywK kwEDkNTnue/NpP7FEQFV9+9KCmK0sZ5hNjjcX5pQG+9f+IKnapQCP4tadGcEh0a00zJC 7UlQ== MIME-Version: 1.0 X-Received: by 10.152.6.201 with SMTP id d9mr15670029laa.25.1385634025578; Thu, 28 Nov 2013 02:20:25 -0800 (PST) Received: by 10.114.168.70 with HTTP; Thu, 28 Nov 2013 02:20:25 -0800 (PST) In-Reply-To: References: Date: Thu, 28 Nov 2013 12:20:25 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e013d1a94e2226b04ec3a0f9c Subject: Re: [rtcweb] Video codec selection: Dropping options X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 10:20:30 -0000 --089e013d1a94e2226b04ec3a0f9c Content-Type: text/plain; charset=ISO-8859-1 I also agree on this. Also 5 does not mean anything. I don't like my own option of 8 that much, because 10 is much better :) 11 and 13 are scary options. If 12 is possible it would be a great option. Do most patents only apply for encoding? I am a bit confused about option 15. How does that one work? Let's say I have a two sides: H.264 encoding/decoding + Theora decoder and the other side has VP8 encoding/decoding + Theora decoder. How do they communicate? On 28 November 2013 10:22, wrote: > Hi, > > I'm not much in favor of the voting, but if we do it: > > Based on the consensus call we already held in Vancouver, I would propose > to drop from the list in [1] any options that make exclusively VP8 > mandatory to implement or exclusively H.264 mandatory to implement. I think > we have already established that much, and including those options in any > vote seems wrong. > > In practice I'm talking about these four options: > 1. All entities MUST support H.264 > 2. All entities MUST support VP8 > 3. All entities MUST support both H.264 and VP8 > 4. Browsers MUST support both H.264 and VP8, other entities MUST support > at least one of H.264 and VP8 > > What the WG should focus on is to see if there is a consensus on any of > the so called "fallback" options vs. no MTI. I think these are all valid as > such as a "fallback": > > 5. All entities MUST support at least one of H.264 and VP8 > 6. All entities MUST support H.261 > 7. There is no MTI video codec > 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST support > at least one of H.264 and VP8 > 9. All entities MUST support Theora > 10. All entities MUST implement at least two of {VP8, H.264, H.261} > 11. All entities MUST implement at least two of {VP8, H.264, H.263} > 12. All entities MUST support decoding using both H.264 and VP8, and MUST > support encoding using at least one of H.264 or VP8 > 13. All entities MUST support H.263 > 14. All entities MUST implement at least two of {VP8, H.264 CBP, Theora} > 15. All entities MUST support decoding using Theora. > > I think it would be problematic even if one of options 1-4 came out as a > winner from a voting procedure, since it would force a large part of the > community to implement something they have valid reasons to avoid. Some of > the options 5-15 may have issues as well, but at least a consensus call > among them would still be in order, since we haven't really had it so far. > And presumably the issues and polarization are "smaller" than with the VP8 > vs. H.264 argument. > > Regards, > Markus > > [1] http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e013d1a94e2226b04ec3a0f9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I also agree on this.

Also 5 does n= ot mean anything.
I don't like my own option of 8 that mu= ch, because 10 is much better :)
11 and 13 are scary options.
If 12 is possible it would be a great option. Do most patents only app= ly for encoding?

I am a bit confused about option 15. How= does that one work?
Let's say I have a two sides: H.264 = encoding/decoding + Theora decoder and the other side has VP8 encoding/deco= ding + Theora decoder. How do they communicate?


O= n 28 November 2013 10:22, <Markus.Isomaki@nokia.com>= wrote:
Hi,

I'm not much in favor of the voting, but if we do it:

Based on the consensus call we already held in Vancouver, I would propose t= o drop from the list in [1] any options that make exclusively VP8 mandatory= to implement or exclusively H.264 mandatory to implement. I think we have = already established that much, and including those options in any vote seem= s wrong.

In practice I'm talking about these four options:
1. All entities MUST support H.264
2. All entities MUST support VP8
3. All entities MUST support both H.264 and VP8
4. Browsers MUST support both H.264 and VP8, other entities MUST support at= least one of H.264 and VP8

What the WG should focus on is to see if there is a consensus on any of the= so called "fallback" options vs. no MTI. I think these are all v= alid as such as a "fallback":

5. All entities MUST support at least one of H.264 and VP8
6. All entities MUST support H.261
7. There is no MTI video codec
8. 5+6, i.e. All entities MUST support H.261 and all entities MUST support = at least one of H.264 and VP8
9. All entities MUST support Theora
10. All entities MUST implement at least two of {VP8, H.264, H.261}
11. All entities MUST implement at least two of {VP8, H.264, H.263}
12. All entities MUST support decoding using both H.264 and VP8, and MUST s= upport encoding using at least one of H.264 or VP8
13. All entities MUST support H.263
14. All entities MUST implement at least two of {VP8, H.264 CBP, Theora} 15. All entities MUST support decoding using Theora.

I think it would be problematic even if one of options 1-4 came out as a wi= nner from a voting procedure, since it would force a large part of the comm= unity to implement something they have valid reasons to avoid. Some of the = options 5-15 may have issues as well, but at least a consensus call among t= hem would still be in order, since we haven't really had it so far. And= presumably the issues and polarization are "smaller" than with t= he VP8 vs. H.264 argument.

Regards,
=A0 =A0 =A0 =A0 Markus

[1] http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e013d1a94e2226b04ec3a0f9c-- From magnus.westerlund@ericsson.com Thu Nov 28 02:21:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E0B1ADF34 for ; Thu, 28 Nov 2013 02:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi45Sx68giET for ; Thu, 28 Nov 2013 02:21:44 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFA81ACCE5 for ; Thu, 28 Nov 2013 02:21:43 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-9b-52971935ab7b Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 65.AA.22496.53917925; Thu, 28 Nov 2013 11:21:42 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.328.9; Thu, 28 Nov 2013 11:21:41 +0100 Message-ID: <52971935.50408@ericsson.com> Date: Thu, 28 Nov 2013 11:21:41 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: John Leslie References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> In-Reply-To: <20131127175414.GA87911@verdi> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvra6Z5PQgg6WPmSzeXzjPaLH2Xzu7 A5PHkiU/mTyOzT3MHMAUxWWTkpqTWZZapG+XwJXxbvpCxoIJ1hWvznxjaWC8qNfFyMkhIWAi saLhOBuELSZx4d56IJuLQ0jgBKPExZ09LCAJIYHljBJLWotBbF4BTYk3DxYwg9gsAqoSyzoP M4HYbAIWEjd/NIINEhUIlrjau44Zol5Q4uTMJ2BzRATkJH6dfcAIYjMLqEvcWXyOHcQWFpCX +LHqLQvE4jdMEqsO7gZLcApoS9y4cwQowQF0nbhET2MQRK+exJSrLVBz5CWat85mhrhTW6Kh qYN1AqPQLCSrZyFpmYWkZQEj8ypGyeLU4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMBwPrjl t9EOxpN77A8xSnOwKInzXmetCRISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6BGg465ypi63 2W1NwVEHt/C1azcsd91xLyy5XJi/IkDNmOXLm3bHxT8zN+/Zu2qLmoJ362aNqxMbOb35ihjf 9avuvfS18IrzXs79Sh+7EvaYaYeu2PZYdQYr620Bib1PS06vlEv9oPVn0cWgV/9jyp3zfi5d 0tnAviblsLu8i9Wj6btPbHL/ocRSnJFoqMVcVJwIACNWQ7w1AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 10:21:46 -0000 Hi John, On 2013-11-27 18:54, John Leslie wrote: > Magnus Westerlund wrote: >> >> For the proposed voting process see our previous message >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html >> >> As I stated, we chairs will need to update this based on the discussion. > > I gather the WGCs intend to update that tomorrow. > > While I would _much_ prefer not to mix discussion of the process > with discussion of the alternatives, there are some really serious > problems with this proposal. > > First: > ] > ] The method we propose is based on Instant-runoff voting, > ] http://en.wikipedia.org/wiki/Instant-runoff_voting, with the > ] understanding that the choice will be the winner according to the > ] Instant-runoff voting process. > > Fail! > > A reference to wikipedia is completely unstable unless it refers > to the webpage retrieved at a particular time. Yes, we will update our proposal to reference a particular date. The one currently available. > > It is the _intent_ of Wikipedia that the webpage may be modified > at any time by any person: thus people retrieving the page on > different days may receive different text. Those differences may be > obvious or they may be subtle. > > Second: > ] > ] 2) Establish those eligible to vote. > > What follows doesn't do that. It instead establishes rules for > determining at some later time _whether_ an individual is eligible. Yes, and the reason is that we realized what amount of work it would be to gather a list of all that would be eligible in an list and publish that ahead of time. Including the failure of the jabber log to capture JIDs and no mapping to Full name and email address. The later problem also exist for blue sheets. Thus, the workable approach was to let people to provide the pointer that prove their eligibility. > > ] Any participant in the working group process either electronically > ] or in-person as of yesterday (20th of November). > > (That's where Magnus broke the sentence. Don't blame me...) > > I merely raise the question of whether the process Magnus outlined > is likely to match that goal. > > ] Who has participated in the Working group process will be anyone > ] that can be identified from: > ] - The Blue Sheets for any RTCWEB WG session during an IETF meeting or > ] an interim meeting since the WG's creation. > ] - posting of at least one email to the RTCWEB mailing list > > Obviously missing from this list is persons subscribed to the > mailing-list during some period. Those would ordinarily be considered > participants. Still our proposal in the updated version will be participants that considered active in the WG. Thus the ones that been to a meeting, IRL or electronically in the jabber room, or have sent an email to the list. > > ] The voter must at time of voting prove their eligibility, by pointing > ] to the mail archive or a particular blue sheet/meeting. Please verify > ] your own eligibility. > > "Voter" is vague here. I take it to mean any person sending a ballot. Yes, the balloting individual. > > Thus there is no way of challenging a right to vote before the > ballot itself is opened. I believe that is unheard-of. The point was to have clear cut criteria for who are eligible. > > It is, IMHO, strange to have no list of eligible voters to enable > challenging eligibility (or absence from the list) before a vote is > cast. You as an individual can already now verify that you can provide such a pointer or not. I agree that it is not possible to challenge another persons eligibility prior to the balloting having completed and the list of who voted becomes available. > > ] 3) Start the the voting period. Those eligible and willing to vote send > ] their ballot to a vote collector (Matt Lepinski, former Nomcom chair) > ] within two weeks using email. The vote collector will check when > ] receiving a ballot the that the voter is eligible and send a > ] confirmation email on receiving the ballot. During the balloting period > ] the vote collector will keep all ballots secret. > > (Just to prove I'm not leaving anything out.) > > ] Balloting: > ] - The voter MUST rank ALL alternatives in their ballot from the most > ] preferred, marked with rank 1, the second most with 2, all the way > ] to the least preferred marked with rank N. > > This is very unusual in Instant Runoff. There are always choices > that a voter would vote _against_ regardless of the alternatives. > This requires that a voter may be counted as in favor of something > s/he completely opposes. My understanding this was one of the few options in Instant Runoff voting. We have selected full ranked to ensure that the voting will provide a winner. If one doesn't mark all the option then that can't be guaranteed. We wanted a voting process that would yield a winner. I would note that No MTI at least can be used to indicate the options that the balloter considered better or worse than no MTI. Although nothing in the IVR process prevents the ranking below "no MTI" to be used to determine the outcome of the voting. > > (Further, it leaves open the "or else" question: what happens if > a ballot doesn't exactly match that requirement?) Then we propose the ballot will be discarded. The vote collector if he notice the issue when ballot is submitted shall contact the balloting individual and notify them of the issue. If not corrected ballot is available by end of balloting period then it will be discarded. > > ] 4) When the voting period is over the ballot collector will publish the > ] results as well as all ballots, including the voters name to the RTCWEB > ] WG mailing list. This enables all voting individuals to verify that > ] their ballot is unmodified. And allows anyone to verify the result of > ] the vote. > > Thus every detail of preference becomes public. Inevitably there will > be some persons who are nervous about publishing so much detail. (I > don't mean to imply that employers _would_ punish employees, merely > that employees could understandably be nervous.) Yes, we understand that as a potential issue. However, without making the ballots public we don't see how we reasonably can ensure the voting is done correctly and in a verifiable way. > > ] 5) The selection is recorded in the drafts. > > Even when we get that wikipedia page "retrieved at a particular time," > it will contain half a dozen different rules for how the counting > proceeds. I strongly recommend extracting the actual rules the WGCs > intend to follow on this list (which will be archival). > > Further, some person needs to be designated to interpret the rules > during counting. Noted, we chairs propose the vote collector will be arbiter. And the normal IETF venues of appeal will be available for the arbiter's decision. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Nov 28 02:28:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEA21ADEB5 for ; Thu, 28 Nov 2013 02:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak6cz4iY5G12 for ; Thu, 28 Nov 2013 02:28:37 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3051A1ADDD2 for ; Thu, 28 Nov 2013 02:28:37 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-a5-52971ad34121 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F8.AE.23787.3DA17925; Thu, 28 Nov 2013 11:28:35 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Thu, 28 Nov 2013 11:28:34 +0100 Message-ID: <52971AD2.2040508@ericsson.com> Date: Thu, 28 Nov 2013 11:28:34 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIJMWRmVeSWpSXmKPExsUyM+Jvre5lqelBBss+6Vms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJbN29kK9glWvJ68irWBsYOvi5GDQ0LAROJCf2AXIyeQKSZx 4d56ti5GLg4hgUOMEnua+6Cc5YwS+3+/ZAOp4hXQlni/YBoTiM0ioCrx4NkNdhCbTcBC4uaP RrAaUYFgiau965gh6gUlTs58wgJiiwioS1x+eAGsXlhAX2LhqsnMEEeIS/Q0BoGEmQX0JKZc bWGEsOUlmrfOBhsjBLS2oamDdQIj/ywkU2chaZmFpGUBI/MqRvbcxMyc9HLDTYzAYDq45bfu DsZT50QOMUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTHPSWH6DpfPz7dF 7lG/sHEGU9vHJQpvEoquvCvq9jPyDDmQejhitXavmInFRQ/OU1k9l7nObe/f8f3z3oplF5Sb tiUYnJUr/pPe2c+j+SAoZPv8e3lxv1I2hZZECHbtUcxbGfKpeKvisRW/zIViVN9vODwnb6Kt u7tX4QyWrbyF6j/vzJ1udEWJpTgj0VCLuag4EQAZMESZ9AEAAA== Subject: [rtcweb] Final list of Video Codec Alternatives X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 10:28:40 -0000 WG, The below is the final list of the alternatives proposed: ---- Start of list --- 1. All entities MUST support H.264 2. All entities MUST support VP8 3. All entities MUST support both H.264 and VP8 4. Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8 5. All entities MUST support at least one of H.264 and VP8 6. All entities MUST support H.261 7. There is no MTI video codec 8. All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8 9. All entities MUST support Theora 10. All entities MUST implement at least two of {VP8, H.264, H.261} 11. All entities MUST implement at least two of {VP8, H.264, H.263} 12. All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8 13. All entities MUST support H.263 14. All entities MUST implement at least two of {VP8, H.264, Theora} 15. All entities MUST support decoding using Theora. H.264 is a reference to the proposal in https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ VP8 is a reference to the proposal in https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/ Unless explicitly noted in an alternative, implementation or support of a codec requires both encoder and decoder. --- End of list --- If anyone see any issues with this list, please report them ASAP. I have applied some last minute edits for clarification and harmonization. I removed CBP from 14, the same that was done earlier to 10 and 11. I have also added the clarification that unless noted, implement or support means both encoder and decoder. I also removed the 5+6 from 8. Regards Magnus Westerlund (As WG chair) ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jeremy.fuller@genband.com Thu Nov 28 02:40:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EDB1ADFE2 for ; Thu, 28 Nov 2013 02:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVMMRxy3fj7S for ; Thu, 28 Nov 2013 02:40:35 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id C21A11ADFDB for ; Thu, 28 Nov 2013 02:40:35 -0800 (PST) Received: from mail121-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.22; Thu, 28 Nov 2013 10:40:34 +0000 Received: from mail121-co1 (localhost [127.0.0.1]) by mail121-co1-R.bigfish.com (Postfix) with ESMTP id 9EE9A70059F for ; Thu, 28 Nov 2013 10:40:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:63.149.188.7; KIP:(null); UIP:(null); IPV:NLI; H:owa.genband.com; RD:63-149-188-7.dia.static.qwest.net; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dIc85dh1432Izz1f42h2148h208ch1ee6h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h1155h) Received-SPF: pass (mail121-co1: domain of genband.com designates 63.149.188.7 as permitted sender) client-ip=63.149.188.7; envelope-from=jeremy.fuller@genband.com; helo=owa.genband.com ; .genband.com ; Received: from mail121-co1 (localhost.localdomain [127.0.0.1]) by mail121-co1 (MessageSwitch) id 1385635232179554_24361; Thu, 28 Nov 2013 10:40:32 +0000 (UTC) Received: from CO1EHSMHS006.bigfish.com (unknown [10.243.78.254]) by mail121-co1.bigfish.com (Postfix) with ESMTP id BA1BC4C0080 for ; Thu, 28 Nov 2013 10:40:31 +0000 (UTC) Received: from owa.genband.com (63.149.188.7) by CO1EHSMHS006.bigfish.com (10.243.66.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 28 Nov 2013 10:40:30 +0000 Received: from GBPLMAIL03.genband.com ([fe80::cc33:96c3:49a1:aa21]) by GBEX01.genband.com ([::1]) with mapi id 14.03.0158.001; Thu, 28 Nov 2013 04:40:30 -0600 From: Jeremy Fuller To: "rtcweb@ietf.org" Thread-Topic: Video codec selection: Dropping options Thread-Index: Ac7sJQ712ll4SaS7SNOdKhpNlt3olA== Date: Thu, 28 Nov 2013 10:40:29 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.21.173] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: genband.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [rtcweb] Video codec selection: Dropping options X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 10:40:38 -0000 Since we appear to be entering the realm of voting game theory, +1 to dropp= ing options where consensus has previously proven to be unobtainable. These= options have had their moment, time to focus on something else.=20 "Insanity is doing the same thing over and over and expecting different res= ults" Date: Thu, 28 Nov 2013 12:20:25 +0200 From: Leon Geyser To: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codec selection: Dropping options Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" I also agree on this. Also 5 does not mean anything. I don't like my own option of 8 that much, because 10 is much better :) 11 and 13 are scary options. If 12 is possible it would be a great option. Do most patents only apply fo= r encoding? I am a bit confused about option 15. How does that one work? Let's say I have a two sides: H.264 encoding/decoding + Theora decoder and = the other side has VP8 encoding/decoding + Theora decoder. How do they comm= unicate? On 28 November 2013 10:22, wrote: > Hi, > > I'm not much in favor of the voting, but if we do it: > > Based on the consensus call we already held in Vancouver, I would=20 > propose to drop from the list in [1] any options that make exclusively=20 > VP8 mandatory to implement or exclusively H.264 mandatory to=20 > implement. I think we have already established that much, and=20 > including those options in any vote seems wrong. > > In practice I'm talking about these four options: > 1. All entities MUST support H.264 > 2. All entities MUST support VP8 > 3. All entities MUST support both H.264 and VP8 4. Browsers MUST=20 > support both H.264 and VP8, other entities MUST support at least one=20 > of H.264 and VP8 > > What the WG should focus on is to see if there is a consensus on any=20 > of the so called "fallback" options vs. no MTI. I think these are all=20 > valid as such as a "fallback": > > 5. All entities MUST support at least one of H.264 and VP8 6. All=20 > entities MUST support H.261 7. There is no MTI video codec 8. 5+6,=20 > i.e. All entities MUST support H.261 and all entities MUST support at=20 > least one of H.264 and VP8 9. All entities MUST support Theora 10. All=20 > entities MUST implement at least two of {VP8, H.264, H.261} 11. All=20 > entities MUST implement at least two of {VP8, H.264, H.263} 12. All=20 > entities MUST support decoding using both H.264 and VP8, and MUST=20 > support encoding using at least one of H.264 or VP8 13. All entities=20 > MUST support H.263 14. All entities MUST implement at least two of=20 > {VP8, H.264 CBP, Theora} 15. All entities MUST support decoding using=20 > Theora. > > I think it would be problematic even if one of options 1-4 came out as=20 > a winner from a voting procedure, since it would force a large part of=20 > the community to implement something they have valid reasons to avoid.=20 > Some of the options 5-15 may have issues as well, but at least a=20 > consensus call among them would still be in order, since we haven't reall= y had it so far. > And presumably the issues and polarization are "smaller" than with the=20 > VP8 vs. H.264 argument. > > Regards, > Markus > > [1] http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From gonzalo.camarillo@ericsson.com Thu Nov 28 03:49:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C1E1AE086 for ; Thu, 28 Nov 2013 03:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.24 X-Spam-Level: X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPw2neE651G4 for ; Thu, 28 Nov 2013 03:49:23 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0C1AE085 for ; Thu, 28 Nov 2013 03:49:22 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-b0-52972dc145fc Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 56.57.22496.1CD27925; Thu, 28 Nov 2013 12:49:21 +0100 (CET) Received: from [131.160.36.172] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.328.9; Thu, 28 Nov 2013 12:49:21 +0100 Message-ID: <52972DC1.8000208@ericsson.com> Date: Thu, 28 Nov 2013 13:49:21 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMJMWRmVeSWpSXmKPExsUyM+Jvre5B3elBBl0btS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxotX39gKZjBWzD94lrmBsa6LkZNDQsBEouHsUzYIW0ziwr31 QDYXh5DACUaJ1uWnmSCcNYwSE5dNYQGp4hXQlvj7ezUziM0ioCrRufQXWJxNwEJiy637YLao QJTE+XMvmSDqBSVOznwCFhcREJV4/XgaK4gtDLT56OOJQDYH0GZxiZ7GIJAws4CexJSrLYwQ trzE9rdzwFYJAa1d/qyFZQIj/ywkU2chaZmFpGUBI/MqRsni1OLi3HQjA73c9NwSvdSizOTi 4vw8veLUTYzAgDu45bfRDsaTe+wPMUpzsCiJ815nrQkSEkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwFhYPGVRZLXW24sFPworra+UGzVcn3NZ1KbrJo+IZkm8Zc7Gogh9S5M5J84eyTiqd5Cx OU7vpwvD1uuHCucIaL7tZupSD5/85GmLwrkPdYXnPnq6PeIvLzwQnZZsfO/jl6vvzts+7i98 zP1vWw9LUMka/u7qRmvROTfernKdOsE3eunK2L8N1UosxRmJhlrMRcWJAHgN3UYGAgAA Subject: [rtcweb] Process discussion on the IETF general list X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 11:49:24 -0000 Hi, FYI: discussion about RTCWeb on the IETF general list: http://www.ietf.org/mail-archive/web/ietf/current/msg84566.html Cheers, Gonzalo From john@jlc.net Thu Nov 28 05:53:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C886F1AD8D5 for ; Thu, 28 Nov 2013 05:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R28rYWfIxsWB for ; Thu, 28 Nov 2013 05:53:13 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C264E1ACC81 for ; Thu, 28 Nov 2013 05:53:12 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 617DEC94C0; Thu, 28 Nov 2013 08:53:10 -0500 (EST) Date: Thu, 28 Nov 2013 08:53:10 -0500 From: John Leslie To: Magnus Westerlund Message-ID: <20131128135310.GE87911@verdi> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <52971935.50408@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52971935.50408@ericsson.com> User-Agent: Mutt/1.4.1i Cc: rtcweb@ietf.org Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 13:53:16 -0000 Note: I'm not trying to be contentious here; I'm merely offering my expertise on voting. I have supervised Hale Preferential Transferrable Voting, and have served as Assistant Moderator during Town voting. Magnus Westerlund wrote: > On 2013-11-27 18:54, John Leslie wrote: >> Magnus Westerlund wrote: >> >> A reference to wikipedia is completely unstable unless it refers >> to the webpage retrieved at a particular time. > > Yes, we will update our proposal to reference a particular date. The one > currently available. :^) (May I suggest picking a particular time available from The Wayback Machine?) >> What follows doesn't do that. It instead establishes rules for >> determining at some later time _whether_ an individual is eligible. > > Yes, and the reason is that we realized what amount of work it would be > to gather a list of all that would be eligible in an list and publish > that ahead of time. Agreed. Usually there is a registration process where potential voters declare an intent to vote, and their eligibility is verified and published. >> Obviously missing from this list is persons subscribed to the >> mailing-list during some period. Those would ordinarily be considered >> participants. > > Still our proposal in the updated version will be participants that > considered active in the WG. Thus the ones that been to a meeting, IRL > or electronically in the jabber room, or have sent an email to the list. "Sent an email to the list" may prove subject to argument. Many folks use and abandon multiple email addresses. Also, I frequently see "On behalf of " emails... >> "Voter" is vague here. I take it to mean any person sending a ballot. > > Yes, the balloting individual. Thanks. >> Thus there is no way of challenging a right to vote before the >> ballot itself is opened. I believe that is unheard-of. > > The point was to have clear cut criteria for who are eligible. Someone must evaluate against those criteria. This, IMHO, should be done in plain view. >> It is, IMHO, strange to have no list of eligible voters to enable >> challenging eligibility (or absence from the list) before a vote is >> cast. > > You as an individual can already now verify that you can provide such a > pointer or not. Someone must evaluate any pointer I provide. This, IMHO, should be done in plain view. > I agree that it is not possible to challenge another persons eligibility > prior to the balloting having completed and the list of who voted > becomes available. :^( >> This is very unusual in Instant Runoff. There are always choices >> that a voter would vote _against_ regardless of the alternatives. >> This requires that a voter may be counted as in favor of something >> s/he completely opposes. > > My understanding this was one of the few options in Instant Runoff > voting. (There are quite a few options during counting...) > We have selected full ranked to ensure that the voting will provide > a winner. If one doesn't mark all the option then that can't be > guaranteed. We wanted a voting process that would yield a winner. This is a misunderstanding. All versions can guarantee a winner. None of them can avoid the need for tie-breaking. It is my understanding that Australians use mandatory marking, apparently to increase the apparent vote totals. It doesn't work IMHO, because folks cast intentionally invalid ballots. > I would note that No MTI at least can be used to indicate the options > that the balloter considered better or worse than no MTI. Although > nothing in the IVR process prevents the ranking below "no MTI" to be > used to determine the outcome of the voting. Noted. >> (Further, it leaves open the "or else" question: what happens if >> a ballot doesn't exactly match that requirement?) > > Then we propose the ballot will be discarded. The vote collector if he > notice the issue when ballot is submitted shall contact the balloting > individual and notify them of the issue. If not corrected ballot is > available by end of balloting period then it will be discarded. This appears to say it is up to the vote collector to "notice" the discrepancy. There is also the possibility that the discrepancy will be found during counting... >> Thus every detail of preference becomes public. Inevitably there will >> be some persons who are nervous about publishing so much detail. (I >> don't mean to imply that employers _would_ punish employees, merely >> that employees could understandably be nervous.) > > Yes, we understand that as a potential issue. However, without making > the ballots public we don't see how we reasonably can ensure the voting > is done correctly and in a verifiable way. The usual practice is to fully verify the voter before the actual ballot is visible; then count the ballot (or declare it invalid or blank). Votes-needed-to-win is determined after subtracting invalid and blank counts. >> Further, some person needs to be designated to interpret the rules >> during counting. > > Noted, we chairs propose the vote collector will be arbiter. And the > normal IETF venues of appeal will be available for the arbiter's decision. Thank you. -- John Leslie From gmartincocher@blackberry.com Thu Nov 28 06:11:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB671AD8D5 for ; Thu, 28 Nov 2013 06:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4QX-N7Hy-ZT for ; Thu, 28 Nov 2013 06:11:44 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 05A181AD6BF for ; Thu, 28 Nov 2013 06:11:43 -0800 (PST) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 28 Nov 2013 09:11:38 -0500 Received: from XCT110CNC.rim.net (10.65.161.210) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 09:11:38 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT110CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 09:11:37 -0500 From: Gaelle Martin-Cocher To: Magnus Westerlund , John Leslie Thread-Topic: [rtcweb] The Voting Process Thread-Index: AQHO65m19m9vCl4mUkGjCQkgFJ+S/Jo6w+CA///sJ7A= Date: Thu, 28 Nov 2013 14:11:37 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AA548AF45D@XMB111CNC.rim.net> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <52971935.50408@ericsson.com> In-Reply-To: <52971935.50408@ericsson.com> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 14:11:52 -0000 Hi Magnus, Is the proposal to reach consensus via a 3 steps approach disregarded? Sincerely, Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: Thursday, November 28, 2013 5:22 AM To: John Leslie Cc: rtcweb@ietf.org Subject: Re: [rtcweb] The Voting Process Hi John, On 2013-11-27 18:54, John Leslie wrote: > Magnus Westerlund wrote: >> >> For the proposed voting process see our previous message = >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html >> >> As I stated, we chairs will need to update this based on the discussion. > = > I gather the WGCs intend to update that tomorrow. > = > While I would _much_ prefer not to mix discussion of the process = > with discussion of the alternatives, there are some really serious = > problems with this proposal. > = > First: > ] > ] The method we propose is based on Instant-runoff voting, ] = > http://en.wikipedia.org/wiki/Instant-runoff_voting, with the ] = > understanding that the choice will be the winner according to the ] = > Instant-runoff voting process. > = > Fail! > = > A reference to wikipedia is completely unstable unless it refers to = > the webpage retrieved at a particular time. Yes, we will update our proposal to reference a particular date. The one cu= rrently available. > = > It is the _intent_ of Wikipedia that the webpage may be modified at = > any time by any person: thus people retrieving the page on different = > days may receive different text. Those differences may be obvious or = > they may be subtle. > = > Second: > ] > ] 2) Establish those eligible to vote. > = > What follows doesn't do that. It instead establishes rules for = > determining at some later time _whether_ an individual is eligible. Yes, and the reason is that we realized what amount of work it would be to = gather a list of all that would be eligible in an list and publish that ahe= ad of time. Including the failure of the jabber log to capture JIDs and no = mapping to Full name and email address. The later problem also exist for bl= ue sheets. Thus, the workable approach was to let people to provide the poi= nter that prove their eligibility. > = > ] Any participant in the working group process either electronically ] = > or in-person as of yesterday (20th of November). > = > (That's where Magnus broke the sentence. Don't blame me...) > = > I merely raise the question of whether the process Magnus outlined = > is likely to match that goal. > = > ] Who has participated in the Working group process will be anyone ] = > that can be identified from: > ] - The Blue Sheets for any RTCWEB WG session during an IETF meeting or > ] an interim meeting since the WG's creation. > ] - posting of at least one email to the RTCWEB mailing list > = > Obviously missing from this list is persons subscribed to the = > mailing-list during some period. Those would ordinarily be considered = > participants. Still our proposal in the updated version will be participants that conside= red active in the WG. Thus the ones that been to a meeting, IRL or electron= ically in the jabber room, or have sent an email to the list. > = > ] The voter must at time of voting prove their eligibility, by = > pointing ] to the mail archive or a particular blue sheet/meeting. = > Please verify ] your own eligibility. > = > "Voter" is vague here. I take it to mean any person sending a ballot. Yes, the balloting individual. > = > Thus there is no way of challenging a right to vote before the = > ballot itself is opened. I believe that is unheard-of. The point was to have clear cut criteria for who are eligible. > = > It is, IMHO, strange to have no list of eligible voters to enable = > challenging eligibility (or absence from the list) before a vote is = > cast. You as an individual can already now verify that you can provide such a poi= nter or not. I agree that it is not possible to challenge another persons eligibility pr= ior to the balloting having completed and the list of who voted becomes ava= ilable. > = > ] 3) Start the the voting period. Those eligible and willing to vote = > send ] their ballot to a vote collector (Matt Lepinski, former Nomcom = > chair) ] within two weeks using email. The vote collector will check = > when ] receiving a ballot the that the voter is eligible and send a ] = > confirmation email on receiving the ballot. During the balloting = > period ] the vote collector will keep all ballots secret. > = > (Just to prove I'm not leaving anything out.) > = > ] Balloting: > ] - The voter MUST rank ALL alternatives in their ballot from the most > ] preferred, marked with rank 1, the second most with 2, all the way > ] to the least preferred marked with rank N. > = > This is very unusual in Instant Runoff. There are always choices = > that a voter would vote _against_ regardless of the alternatives. > This requires that a voter may be counted as in favor of something = > s/he completely opposes. My understanding this was one of the few options in Instant Runoff voting. = We have selected full ranked to ensure that the voting will provide a winne= r. If one doesn't mark all the option then that can't be guaranteed. We wan= ted a voting process that would yield a winner. I would note that No MTI at least can be used to indicate the options that = the balloter considered better or worse than no MTI. Although nothing in th= e IVR process prevents the ranking below "no MTI" to be used to determine t= he outcome of the voting. > = > (Further, it leaves open the "or else" question: what happens if a = > ballot doesn't exactly match that requirement?) Then we propose the ballot will be discarded. The vote collector if he noti= ce the issue when ballot is submitted shall contact the balloting individua= l and notify them of the issue. If not corrected ballot is available by end= of balloting period then it will be discarded. > = > ] 4) When the voting period is over the ballot collector will publish = > the ] results as well as all ballots, including the voters name to the = > RTCWEB ] WG mailing list. This enables all voting individuals to = > verify that ] their ballot is unmodified. And allows anyone to verify = > the result of ] the vote. > = > Thus every detail of preference becomes public. Inevitably there = > will be some persons who are nervous about publishing so much detail. = > (I don't mean to imply that employers _would_ punish employees, merely = > that employees could understandably be nervous.) Yes, we understand that as a potential issue. However, without making the b= allots public we don't see how we reasonably can ensure the voting is done = correctly and in a verifiable way. > = > ] 5) The selection is recorded in the drafts. > = > Even when we get that wikipedia page "retrieved at a particular time," > it will contain half a dozen different rules for how the counting = > proceeds. I strongly recommend extracting the actual rules the WGCs = > intend to follow on this list (which will be archival). > = > Further, some person needs to be designated to interpret the rules = > during counting. Noted, we chairs propose the vote collector will be arbiter. And the normal= IETF venues of appeal will be available for the arbiter's decision. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From magnus.westerlund@ericsson.com Thu Nov 28 06:24:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92D31AE127 for ; Thu, 28 Nov 2013 06:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7d3SRdEofUXw for ; Thu, 28 Nov 2013 06:24:38 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E0DEC1AE120 for ; Thu, 28 Nov 2013 06:24:37 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-71-5297522436b2 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 64.94.27941.42257925; Thu, 28 Nov 2013 15:24:36 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.328.9; Thu, 28 Nov 2013 15:24:36 +0100 Message-ID: <52975223.50209@ericsson.com> Date: Thu, 28 Nov 2013 15:24:35 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Gaelle Martin-Cocher , John Leslie References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <52971935.50408@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA548AF45D@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AA548AF45D@XMB111CNC.rim.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvra5K0PQgg3OzVSxW/L3HbPH+wnlG i7X/2tkdmD1mNaxl91iy5CeTx7G5h5kDmKO4bFJSczLLUov07RK4Mj42fGAp2Mpe8XlHI2sD YxNbFyMnh4SAiUR70xUoW0ziwr31QDYXh5DAEUaJKdtmM0M4yxkl+ldtZASp4hXQlDjftIwd xGYRUJVovXSZBcRmE7CQuPmjEWySqECwxNXedcwQ9YISJ2c+Aarh4BARCJVoauYACTMLqEvc WXyOHSQsLKAhsfGIBcSq48wSR07/ABvDKeApcXD6bbBWCQFxiZ7GIIhWPYkpV1sYIWx5ieat s8E2CQloSzQ0dbBOYBSahWTxLCQts5C0LGBkXsXIUZxanJSbbmSwiREYvge3/LbYwXj5r80h RmkOFiVx3o9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MMakx21aaHJAjjXZ9Mx+/2TF VUUxmYrlJ5RP3g7Y9SVnx9wtPx9or/p+7K3756chKbbiLznLHE/oPj4pG6v4fXeCt50FD+8y qaJ3rU7Tn0/b9tsof8fcG36rTpS/2ygZVqFycvWPzsCu/GtT+upyZlXuLaz+XNZ+yjVAx75v S8zZTZqJZzjbu5VYijMSDbWYi4oTAWnKTzgtAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 14:24:40 -0000 On 2013-11-28 15:11, Gaelle Martin-Cocher wrote: > Hi Magnus, > > Is the proposal to reach consensus via a 3 steps approach disregarded? Gaelle, It is less than 24 hours since you provided your feedback. Today is Thanksgiving in US. The chairs did prepare to start the consensus call with an updated procedure. However, based on the last 24 hours feedback I think we will have to evaluate the latest feedback and determine what we see as the next step. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From gmartincocher@blackberry.com Thu Nov 28 06:27:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12DA1AE064 for ; Thu, 28 Nov 2013 06:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON0tmNXntQ0V for ; Thu, 28 Nov 2013 06:27:47 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id E7EF51ADFB0 for ; Thu, 28 Nov 2013 06:27:46 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 28 Nov 2013 09:27:45 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0158.001; Thu, 28 Nov 2013 09:27:45 -0500 From: Gaelle Martin-Cocher To: Magnus Westerlund , John Leslie Thread-Topic: [rtcweb] The Voting Process Thread-Index: AQHO65m19m9vCl4mUkGjCQkgFJ+S/Jo6w+CA///sJ7CAAFe2gP//rIHg Date: Thu, 28 Nov 2013 14:27:44 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AA548AF4AC@XMB111CNC.rim.net> References: <52935C89.5040408@ericsson.com> <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <52971935.50408@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA548AF45D@XMB111CNC.rim.net> <52975223.50209@ericsson.com> In-Reply-To: <52975223.50209@ericsson.com> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 14:27:48 -0000 Thank you. The proposal to drop some of the options would also fit nicely in the step = 3, the list could be refined immediately or only if we reach that step. Cheers, Ga=EBlle -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] = Sent: Thursday, November 28, 2013 9:25 AM To: Gaelle Martin-Cocher; John Leslie Cc: rtcweb@ietf.org Subject: Re: [rtcweb] The Voting Process On 2013-11-28 15:11, Gaelle Martin-Cocher wrote: > Hi Magnus, > = > Is the proposal to reach consensus via a 3 steps approach disregarded? Gaelle, It is less than 24 hours since you provided your feedback. Today is Thanksg= iving in US. The chairs did prepare to start the consensus call with an updated procedur= e. However, based on the last 24 hours feedback I think we will have to eva= luate the latest feedback and determine what we see as the next step. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From magnus.westerlund@ericsson.com Thu Nov 28 06:43:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432161AE13E for ; Thu, 28 Nov 2013 06:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD0XxHdTQG8r for ; Thu, 28 Nov 2013 06:43:28 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD791AE103 for ; Thu, 28 Nov 2013 06:43:27 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-3b-5297568df30e Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 95.3E.03802.D8657925; Thu, 28 Nov 2013 15:43:25 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.2.328.9; Thu, 28 Nov 2013 15:43:25 +0100 Message-ID: <5297568D.9060400@ericsson.com> Date: Thu, 28 Nov 2013 15:43:25 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: , References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3VrcvbHqQwe6lLBbn/y5is1j7r53d gcljyZKfTB53b11iCmCK4rJJSc3JLEst0rdL4MrY3rGKpeC5dMXOB6wNjMvEuhg5OSQETCRe nd7KDGGLSVy4t56ti5GLQ0jgEKPEkSdvmCCc5YwS/x8+ZwGp4hXQlljbcpIJxGYRUJXYfnEb WJxNwELi5o9GNhBbVCBY4mrvOmaIekGJkzOfgNWICBhKbOiaxw5iCwvYSrxb+RXI5gBaEC7x Z6YVSJhTIEJi+rHDbCBhCQFxiZ7GIJAws4CexJSrLYwQtrxE89bZYNOFgK5paOpgncAoOAvJ sllIWmYhaVnAyLyKkT03MTMnvdxoEyMwHA9u+a26g/HOOZFDjNIcLErivB/eOgcJCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYFx0IPwR6/+QeK/w/vU9X3TCLzLMYRPYs/t8CFers+ZNaysR 4bI5Ho4H5A5ufs8dPGvxtJZDP1MTbthIpu2v/TwxsGLHtqACt/yYDc5Fnd/qPy1cOfnNCXlf UykR+VXXj3wPfvWyo3WtXo6WltKyg3f6Pz1avC7zgcjf9ykztqf7LI3csd1oTpcSS3FGoqEW c1FxIgAtn9oPFQIAAA== Subject: Re: [rtcweb] Video codec selection: Dropping options X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 14:43:30 -0000 Markus, I would note that I consider this suggestion highly problematic at this time. Especially considering the process we have proposed for selecting a winning alternative. The issue is that we had an open call for proposals to be considered. To be able to exclude options I see a need for both a process and consensus to use this process to eliminate options. I hope you see the problem with eliminating alternatives by any form of chair decision at this time. Thus we would be forced to run different sets of consensus calls to determine if there are consensus to eliminate as well as which. Thus, I would consider your comment as, the process we chairs are proposing is the wrong one. Cheers Magnus On 2013-11-28 09:22, Markus.Isomaki@nokia.com wrote: > Hi, > > I'm not much in favor of the voting, but if we do it: > > Based on the consensus call we already held in Vancouver, I would propose to drop from the list in [1] any options that make exclusively VP8 mandatory to implement or exclusively H.264 mandatory to implement. I think we have already established that much, and including those options in any vote seems wrong. > > In practice I'm talking about these four options: > 1. All entities MUST support H.264 > 2. All entities MUST support VP8 > 3. All entities MUST support both H.264 and VP8 > 4. Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8 > > What the WG should focus on is to see if there is a consensus on any of the so called "fallback" options vs. no MTI. I think these are all valid as such as a "fallback": > > 5. All entities MUST support at least one of H.264 and VP8 > 6. All entities MUST support H.261 > 7. There is no MTI video codec > 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8 > 9. All entities MUST support Theora > 10. All entities MUST implement at least two of {VP8, H.264, H.261} > 11. All entities MUST implement at least two of {VP8, H.264, H.263} > 12. All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8 > 13. All entities MUST support H.263 > 14. All entities MUST implement at least two of {VP8, H.264 CBP, Theora} > 15. All entities MUST support decoding using Theora. > > I think it would be problematic even if one of options 1-4 came out as a winner from a voting procedure, since it would force a large part of the community to implement something they have valid reasons to avoid. Some of the options 5-15 may have issues as well, but at least a consensus call among them would still be in order, since we haven't really had it so far. And presumably the issues and polarization are "smaller" than with the VP8 vs. H.264 argument. > > Regards, > Markus > > [1] http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Ted.Lemon@nominum.com Thu Nov 28 07:34:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C561ADBC9; Thu, 28 Nov 2013 07:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvxZA9BgkwSo; Thu, 28 Nov 2013 07:34:56 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id DA6EF1AE034; Thu, 28 Nov 2013 07:34:55 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUpdinkgRy3wRr172I69pXoZnAQI+qhdd@postini.com; Thu, 28 Nov 2013 07:34:55 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2259E1B82E5; Thu, 28 Nov 2013 07:34:54 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 14FD2190043; Thu, 28 Nov 2013 07:34:54 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 07:34:53 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <52974AA8.6080702@cisco.com> Date: Thu, 28 Nov 2013 10:34:48 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> References: <52974AA8.6080702@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: rtcweb-chairs@tools.ietf.org, Dave Cridland , rtcweb@ietf.org, Eric Burger , IETF Discussion Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 15:34:57 -0000 On Nov 28, 2013, at 8:52 AM, Eliot Lear wrote: > While I appreciate the difficult position the chairs are in, I don't > agree with the approach and I believe it is inappropriate for the > working group to make such a decision. Working groups don't vote. = Want > to change that process? Better gain IETF consensus first. And I will > argue against any such attempt. There are plenty of other standards > bodies that do vote. Go to one of them if that's what you want. One of the things to talk about here is the issue of voting versus a = coin toss. The advantage of a coin toss is that nobody can say it was = gamed, because it's random=97there is no process to blame if it doesn't = go your way. Voting, however, is somewhat predictable, and can be = gamed. So the concern is that if the working group has consensus to vote, it's = probably because interested parties have some reason to believe the vote = will go their way. They may be horribly mistaken, or they may be = correct=97that isn't the point. The point is that they aren't actually = okay with the outcome not going their way. So if the working group is willing to agree to a vote, and unwilling to = agree to a coin toss, that says something _very important_ about the = status of consensus in the working group. From Ted.Lemon@nominum.com Thu Nov 28 09:03:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5656C1ADEB6; Thu, 28 Nov 2013 09:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifVYzgwTt-HQ; Thu, 28 Nov 2013 09:03:06 -0800 (PST) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 562C31AC403; Thu, 28 Nov 2013 09:03:06 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUpd3ScJOBIvB7IjKYvo0hqm4fbKGPJMs@postini.com; Thu, 28 Nov 2013 09:03:05 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 82EA51B82ED; Thu, 28 Nov 2013 09:03:01 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 55FE6190043; Thu, 28 Nov 2013 09:03:01 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 09:03:00 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <52976F56.4020706@dcrocker.net> Date: Thu, 28 Nov 2013 12:02:57 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: rtcweb-chairs@tools.ietf.org, Eliot Lear , rtcweb@ietf.org, Eric Burger , IETF Discussion Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 17:03:07 -0000 On Nov 28, 2013, at 11:29 AM, Dave Crocker wrote: > As merely one obvious example, people can simply be tired of the = impasse > and eagerly seek progress and be willing to settle on any mechanism = they > think will fairly break it -- even if it works against the outcome = they > prefer. The one tidbit you may be missing is that the working group specifically = chose not to do a coin toss. So "willing to settle for any mechanism" = clearly doesn't apply in this case. From cowwoc@bbs.darktech.org Thu Nov 28 09:56:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460311ADED5 for ; Thu, 28 Nov 2013 09:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4wUynrUfncL for ; Thu, 28 Nov 2013 09:56:06 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id A7CCC1ACCE6 for ; Thu, 28 Nov 2013 09:56:05 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id tp5so14715698ieb.11 for ; Thu, 28 Nov 2013 09:56:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0VphmmRkNniuiF9AfTlrs7YwZCQ0ig3dkK3Bj1yNlj4=; b=ESDbYjhhBfToI8s86Szll+38bYEoaZ5qaK1P55CxJkSBGwQlcfMFtcTrmrDi2jvCL+ F+Z2MH6cJ6p0BRCFuiohBeUuglgMmKHwd8sU9E8H5KvgUrds6JX6TsKx6I9tPRk+9VZf fCME7QPRE5G5YUylH2egq+a9ET57YcuF+/G7c+dzr0rPiqbNRA6mWENjmxUullMYteXO 0zMkpcupstX3GRpxvNAH3mjNvljoCXnbyngIGuGntTu9A6rJrFVhFxDNyhJFo2NIyu5+ hrsOuOAWIOeZhgBjlB/M1jbNPywBtVqsghB/LD7RVnqNKLuS9ct9TjaPBo0MLSzT09h/ s4sA== X-Gm-Message-State: ALoCoQkA2ZukNvMft4dV43D6NqVN5/g6QILK30QggM6qTAZGfYYnOsHysEZzb24xwjhI/79FIzdX X-Received: by 10.50.41.38 with SMTP id c6mr2903963igl.47.1385661364711; Thu, 28 Nov 2013 09:56:04 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id w4sm45936446igb.5.2013.11.28.09.56.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 09:56:03 -0800 (PST) Message-ID: <52978385.8070703@bbs.darktech.org> Date: Thu, 28 Nov 2013 12:55:17 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> In-Reply-To: <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 17:56:07 -0000 On 28/11/2013 10:34 AM, Ted Lemon wrote: > On Nov 28, 2013, at 8:52 AM, Eliot Lear wrote: >> While I appreciate the difficult position the chairs are in, I don't >> agree with the approach and I believe it is inappropriate for the >> working group to make such a decision. Working groups don't vote. Want >> to change that process? Better gain IETF consensus first. And I will >> argue against any such attempt. There are plenty of other standards >> bodies that do vote. Go to one of them if that's what you want. > One of the things to talk about here is the issue of voting versus a coin toss. The advantage of a coin toss is that nobody can say it was gamed, because it's random—there is no process to blame if it doesn't go your way. Voting, however, is somewhat predictable, and can be gamed. > > So the concern is that if the working group has consensus to vote, it's probably because interested parties have some reason to believe the vote will go their way. They may be horribly mistaken, or they may be correct—that isn't the point. The point is that they aren't actually okay with the outcome not going their way. > > So if the working group is willing to agree to a vote, and unwilling to agree to a coin toss, that says something _very important_ about the status of consensus in the working group. > The list we are preparing to vote on is an all-inclusive list. If you feel that a coin flip is a better option, you're going to need to compile an "all options being equal" list first. If it's any consolation, I believe the fact that voting records will be open to the public (who voted and for what) will act to reduce gaming or at least enable us to detect it after-the-fact. Which brings up the question: will the vote results be binding? Or will they act as a strong recommendation for a follow-up consensus call? :) Gili From cowwoc@bbs.darktech.org Thu Nov 28 09:57:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18B71ADED5 for ; Thu, 28 Nov 2013 09:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSzehWklpiZx for ; Thu, 28 Nov 2013 09:57:12 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id B56F31ACCE6 for ; Thu, 28 Nov 2013 09:57:12 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so14645131iec.37 for ; Thu, 28 Nov 2013 09:57:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=zsmEO0OtXeZqwVdnXR6UgUmmpvgpRqF0VGOAJZtcbwA=; b=EJR3R5MidJBhA/T34aPE/O/7aneUoyP0jDVWbooGGBWIF/OaRJ2pxlUHz3QpLM9GGZ Cr7sacHaEwan/AWlhHkMgKOpcIw0YLzFLOJ5dl5MChnELc9G8GbiN6DH7gVZ7sG/nnSv lOw9LHkiYehjWXj4wk1/q3p+Qsi2OHRXxn/RhsO7SKh7l+0zIRyd6pQ8g1GJwGMuYDDh VbP+6vAEFlsCHOnWZsgmQDotgIdjYIdHrNLPohC7rWoxoAxmCcesUlj35M7Lm0tRvMqg COe6p0Qqbkbh7gNSlTRRpyM+8kisqP3QS5wdSP3O4AXtbOLo7tiB9ASYyfjgORMjMePr 7c6A== X-Gm-Message-State: ALoCoQlfUWRpviDViJYbNLLEKb/IUTm2PLoe2VJ1hPpDGJphRw9IZCq5r5V5Vd40PlePrQ+nLpRR X-Received: by 10.50.234.162 with SMTP id uf2mr2996033igc.48.1385661431827; Thu, 28 Nov 2013 09:57:11 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id v9sm36607919igh.7.2013.11.28.09.57.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 09:57:11 -0800 (PST) Message-ID: <529783C8.7090806@bbs.darktech.org> Date: Thu, 28 Nov 2013 12:56:24 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070309070809070308090607" Subject: Re: [rtcweb] Video codec selection: Dropping options X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 17:57:15 -0000 This is a multi-part message in MIME format. --------------070309070809070308090607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 28/11/2013 5:20 AM, Leon Geyser wrote: > I am a bit confused about option 15. How does that one work? > Let's say I have a two sides: H.264 encoding/decoding + Theora decoder > and the other side has VP8 encoding/decoding + Theora decoder. How do > they communicate? Any option that mandates one or more decoders implies "and MUST support encoding of one of the aforementioned formats". Gili > > > On 28 November 2013 10:22, > wrote: > > Hi, > > I'm not much in favor of the voting, but if we do it: > > Based on the consensus call we already held in Vancouver, I would > propose to drop from the list in [1] any options that make > exclusively VP8 mandatory to implement or exclusively H.264 > mandatory to implement. I think we have already established that > much, and including those options in any vote seems wrong. > > In practice I'm talking about these four options: > 1. All entities MUST support H.264 > 2. All entities MUST support VP8 > 3. All entities MUST support both H.264 and VP8 > 4. Browsers MUST support both H.264 and VP8, other entities MUST > support at least one of H.264 and VP8 > > What the WG should focus on is to see if there is a consensus on > any of the so called "fallback" options vs. no MTI. I think these > are all valid as such as a "fallback": > > 5. All entities MUST support at least one of H.264 and VP8 > 6. All entities MUST support H.261 > 7. There is no MTI video codec > 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST > support at least one of H.264 and VP8 > 9. All entities MUST support Theora > 10. All entities MUST implement at least two of {VP8, H.264, H.261} > 11. All entities MUST implement at least two of {VP8, H.264, H.263} > 12. All entities MUST support decoding using both H.264 and VP8, > and MUST support encoding using at least one of H.264 or VP8 > 13. All entities MUST support H.263 > 14. All entities MUST implement at least two of {VP8, H.264 CBP, > Theora} > 15. All entities MUST support decoding using Theora. > > I think it would be problematic even if one of options 1-4 came > out as a winner from a voting procedure, since it would force a > large part of the community to implement something they have valid > reasons to avoid. Some of the options 5-15 may have issues as > well, but at least a consensus call among them would still be in > order, since we haven't really had it so far. And presumably the > issues and polarization are "smaller" than with the VP8 vs. H.264 > argument. > > Regards, > Markus > > [1] http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart > > _______________________________________________ > 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 --------------070309070809070308090607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 28/11/2013 5:20 AM, Leon Geyser wrote:
I am a bit confused about option 15. How does that one work?
Let's say I have a two sides: H.264 encoding/decoding + Theora decoder and the other side has VP8 encoding/decoding + Theora decoder. How do they communicate?

Any option that mandates one or more decoders implies "and MUST support encoding of one of the aforementioned formats".

Gili



On 28 November 2013 10:22, <Markus.Isomaki@nokia.com> wrote:
Hi,

I'm not much in favor of the voting, but if we do it:

Based on the consensus call we already held in Vancouver, I would propose to drop from the list in [1] any options that make exclusively VP8 mandatory to implement or exclusively H.264 mandatory to implement. I think we have already established that much, and including those options in any vote seems wrong.

In practice I'm talking about these four options:
1. All entities MUST support H.264
2. All entities MUST support VP8
3. All entities MUST support both H.264 and VP8
4. Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8

What the WG should focus on is to see if there is a consensus on any of the so called "fallback" options vs. no MTI. I think these are all valid as such as a "fallback":

5. All entities MUST support at least one of H.264 and VP8
6. All entities MUST support H.261
7. There is no MTI video codec
8. 5+6, i.e. All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8
9. All entities MUST support Theora
10. All entities MUST implement at least two of {VP8, H.264, H.261}
11. All entities MUST implement at least two of {VP8, H.264, H.263}
12. All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8
13. All entities MUST support H.263
14. All entities MUST implement at least two of {VP8, H.264 CBP, Theora}
15. All entities MUST support decoding using Theora.

I think it would be problematic even if one of options 1-4 came out as a winner from a voting procedure, since it would force a large part of the community to implement something they have valid reasons to avoid. Some of the options 5-15 may have issues as well, but at least a consensus call among them would still be in order, since we haven't really had it so far. And presumably the issues and polarization are "smaller" than with the VP8 vs. H.264 argument.

Regards,
        Markus

[1] http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart

_______________________________________________
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

--------------070309070809070308090607-- From harald@alvestrand.no Thu Nov 28 09:59:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725101ADF5A for ; Thu, 28 Nov 2013 09:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrMc0UlXG_2P for ; Thu, 28 Nov 2013 09:59:39 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1A81ACCE6 for ; Thu, 28 Nov 2013 09:59:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D82239E0C8 for ; Thu, 28 Nov 2013 18:59:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUdabE6L5HF9 for ; Thu, 28 Nov 2013 18:59:38 +0100 (CET) Received: from [10.130.3.90] (unknown [193.110.199.36]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5EA4539E09F for ; Thu, 28 Nov 2013 18:59:38 +0100 (CET) Message-ID: <52978488.4010108@alvestrand.no> Date: Thu, 28 Nov 2013 18:59:36 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Video codec selection: Dropping options X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 17:59:42 -0000 On 11/28/2013 11:40 AM, Jeremy Fuller wrote: > Since we appear to be entering the realm of voting game theory, +1 to dropping options where consensus has previously proven to be unobtainable. These options have had their moment, time to focus on something else. The WG has never voted on these alternatives; what failed was an attempt at finding consensus. Furhtermore, the choice of voting method that the chairs are still advocating (IRV) is one where presence of non-selected alternatives on the slate can influence the outcome. I'm not enough of a game theorist to figure out which way the presence of the previously non-consensual options may influence the ballot, but I don't think I am in agreement with dropping these alternatives from the ballot. (I still haven't decided whether or not I'm in agreement with doing a ballot at all, though.) > > "Insanity is doing the same thing over and over and expecting different results" > > Date: Thu, 28 Nov 2013 12:20:25 +0200 > From: Leon Geyser > To: "rtcweb@ietf.org" > Subject: Re: [rtcweb] Video codec selection: Dropping options > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > I also agree on this. > > Also 5 does not mean anything. > I don't like my own option of 8 that much, because 10 is much better :) > 11 and 13 are scary options. > If 12 is possible it would be a great option. Do most patents only apply for encoding? > > I am a bit confused about option 15. How does that one work? > Let's say I have a two sides: H.264 encoding/decoding + Theora decoder and the other side has VP8 encoding/decoding + Theora decoder. How do they communicate? > > > On 28 November 2013 10:22, wrote: > >> Hi, >> >> I'm not much in favor of the voting, but if we do it: >> >> Based on the consensus call we already held in Vancouver, I would >> propose to drop from the list in [1] any options that make exclusively >> VP8 mandatory to implement or exclusively H.264 mandatory to >> implement. I think we have already established that much, and >> including those options in any vote seems wrong. >> >> In practice I'm talking about these four options: >> 1. All entities MUST support H.264 >> 2. All entities MUST support VP8 >> 3. All entities MUST support both H.264 and VP8 4. Browsers MUST >> support both H.264 and VP8, other entities MUST support at least one >> of H.264 and VP8 >> >> What the WG should focus on is to see if there is a consensus on any >> of the so called "fallback" options vs. no MTI. I think these are all >> valid as such as a "fallback": >> >> 5. All entities MUST support at least one of H.264 and VP8 6. All >> entities MUST support H.261 7. There is no MTI video codec 8. 5+6, >> i.e. All entities MUST support H.261 and all entities MUST support at >> least one of H.264 and VP8 9. All entities MUST support Theora 10. All >> entities MUST implement at least two of {VP8, H.264, H.261} 11. All >> entities MUST implement at least two of {VP8, H.264, H.263} 12. All >> entities MUST support decoding using both H.264 and VP8, and MUST >> support encoding using at least one of H.264 or VP8 13. All entities >> MUST support H.263 14. All entities MUST implement at least two of >> {VP8, H.264 CBP, Theora} 15. All entities MUST support decoding using >> Theora. >> >> I think it would be problematic even if one of options 1-4 came out as >> a winner from a voting procedure, since it would force a large part of >> the community to implement something they have valid reasons to avoid. >> Some of the options 5-15 may have issues as well, but at least a >> consensus call among them would still be in order, since we haven't really had it so far. >> And presumably the issues and polarization are "smaller" than with the >> VP8 vs. H.264 argument. >> >> Regards, >> Markus >> >> [1] http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart >> >> _______________________________________________ >> 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 -- Surveillance is pervasive. Go Dark. From dhc@dcrocker.net Thu Nov 28 08:30:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03C91AE0A2; Thu, 28 Nov 2013 08:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BcpLg3NF6Mo; Thu, 28 Nov 2013 08:30:05 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9D2D1ADF97; Thu, 28 Nov 2013 08:30:05 -0800 (PST) Received: from [10.211.51.212] (rbiguest.jcresorts.com [206.170.126.120] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rASGTx7U024845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Nov 2013 08:30:02 -0800 Message-ID: <52976F56.4020706@dcrocker.net> Date: Thu, 28 Nov 2013 08:29:10 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ted Lemon , Eliot Lear References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> In-Reply-To: <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 28 Nov 2013 08:30:03 -0800 (PST) X-Mailman-Approved-At: Thu, 28 Nov 2013 10:02:48 -0800 Cc: rtcweb@ietf.org, rtcweb-chairs@tools.ietf.org, Eric Burger , IETF Discussion Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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: Thu, 28 Nov 2013 16:30:07 -0000 On 11/28/2013 7:34 AM, Ted Lemon wrote: > if the working group has consensus to vote, it's probably because > interested parties have some reason to believe the vote will go > their way. ... > So if the working group is willing to agree to a vote, and unwilling > to agree to a coin toss, that says something _very important_ about > the status of consensus in the working group. No it doesn't. Or at least, not what you indicate, above, that it says. The thinking you describe is possible, of course, but it's not guaranteed. People's motives and expectations and logic can vary quite a bit in a situation like this. As merely one obvious example, people can simply be tired of the impasse and eagerly seek progress and be willing to settle on any mechanism they think will fairly break it -- even if it works against the outcome they prefer. Let's not confuse 'possible' with 'certain'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From lear@cisco.com Thu Nov 28 05:52:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA791ACC87; Thu, 28 Nov 2013 05:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SqprCCNwrZG; Thu, 28 Nov 2013 05:52:50 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 15A061A1F19; Thu, 28 Nov 2013 05:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2758; q=dns/txt; s=iport; t=1385646769; x=1386856369; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=of9Cwtn0+lzovpWosdPwYeOBUoJOdyRQmS6/RNEsyco=; b=KQkkMp1zDRt3gSixsIr44B4/QQZNEu+JZv+E/AALtVzlqEmUcT5mnL7i oHgu/LgAYxwlHGX54wqWsJzQNml4Spq3XfXjf4gzZDJML04Yc5cAANG+W S713Hh3qDxBqkHgz1h9GiZSaX1/fymUjAAwYSV6IXIV49/Q6D2ZyXGTtc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAIhJl1KQ/khN/2dsb2JhbAA/GoMHOINNtH9OgR0WdIIlAQEBBB0GDwE5AggCARALGAICBRYLAgIJAwIBAgFFBgEMAQcBAQWHeA02rxKRCYEpjQ4BAU8HgmuBSAOYFIEwkGODKjuBNQ X-IronPort-AV: E=Sophos;i="4.93,791,1378857600"; d="scan'208";a="771642" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 28 Nov 2013 13:52:48 +0000 Received: from dhcp-wlsn01-vlan250-10-147-28-63.cisco.com (dhcp-wlsn01-vlan250-10-147-28-63.cisco.com [10.147.28.63]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rASDqfke026951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Nov 2013 13:52:43 GMT Message-ID: <52974AA8.6080702@cisco.com> Date: Thu, 28 Nov 2013 14:52:40 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: =?UTF-8?B?SGVydsOp?= , Dave Cridland , IETF Discussion References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 28 Nov 2013 10:02:48 -0800 Cc: rtcweb@ietf.org, Eric Burger , rtcweb-chairs@tools.ietf.org Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 13:52:52 -0000 While I appreciate the difficult position the chairs are in, I don't agree with the approach and I believe it is inappropriate for the working group to make such a decision. Working groups don't vote. Want to change that process? Better gain IETF consensus first. And I will argue against any such attempt. There are plenty of other standards bodies that do vote. Go to one of them if that's what you want. Eliot On 11/28/13 2:35 PM, Hervé wrote: > Dave Cridland wrote: > >> 2) If the Working Group does want to mandate a single codec, is there > consensus for one of the alternate decision-making processes described > in RFC 3929? This is our best guess at what to do here; despite it being > a (presumably expired) Experimental track RFC. > > > RFC 3929 has been mentioned on the rtcweb mailinglist and during the last meeting. > http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html > http://ietf88.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB_II > > >> If nobody else appeals the decision, then I will - assuming I'm allowed to - if it gets this far. >> it's not clear to me that there is a consensus surrounding the voting > rules - they've certainly yet to be summarised in one place based on the > discussion that has occurred so far. > > No decision yet. Per > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html today > is the last planned day for comment/discussion on the _proposal_ to vote, > before the proposal gets updated. A further call for consensus to use > the proposal would follow after updating. > Perhaps you'd like to get involved now rather than later. > > > Here's what I sent to someone else regarding the proposed schedule: > Nov 28 last day of comment/discussion period on proposed _voting process_ http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html > > after Nov 28 WG chairs will update, if necessary, the process proposal > after update normal IETF process to reach consensus about adopting the (updated) process proposal > > +2 weeks last day of the consensus call about adopting the voting process > > > IF consensus was reached to use the voting process in those 2 weeks after the update for that process, ONLY THEN would the (2 week) voting period start (if that wasn't changed in the update/concensus call). > > So the voting process can theoretically _start_ Dec 13 at the earliest, if accepted. Probably later (if ever), given that updating the proposal is unlikely to be instantaneous. > > > I hope that made it clearer. The source for this is the bottom section of http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html > > > - Hervé > From ekr@rtfm.com Thu Nov 28 10:06:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EAC1AE02C for ; Thu, 28 Nov 2013 10:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERl7yeGwmFit for ; Thu, 28 Nov 2013 10:05:59 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 976501ADF5A for ; Thu, 28 Nov 2013 10:05:59 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so1150902wid.11 for ; Thu, 28 Nov 2013 10:05:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kyCF42YvW0xgVh4jFXGEVUmRQKUca/+3c+Ta2VRgwAU=; b=QnzkW591aAGRTo728OLoE/8mcoalFRz8Shmro2+8b1zfavDjiJgjNHeNdZeIIfpfHJ 4UW2YgJLYDC2Uo59ofvNd4prjKlLXD6zmfAcZX8CcXGkP90K4d8Sxzy+IhKaHPR8jJ/j nkxpw3/MSS34nCIPO/aYOrY3MTo2GsB1WlB+tJwg2/dmHMRWAAn5lxoz5z4m5itc8ZAH vTUWox8/ZP8xYfzpbyaLctVBi7TsWfWk0SrG6T5SUNKCnwBJg+e2YG0v+i7LkoMurSAE t5mH34QjkzHPo5HIJUKwEMdX4CPlV4tUlTXXHWrLobi7+fOZwSXQdZ8/4LQaUkRwfr+5 hV5w== X-Gm-Message-State: ALoCoQkNUF0Df+0/o5YArw0Up/6kHEK19YHbTFnNQN/E/wfKHKbzzjX0bCodCNXPfnNVx9yy+xCD X-Received: by 10.180.221.38 with SMTP id qb6mr3526311wic.8.1385661958116; Thu, 28 Nov 2013 10:05:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Thu, 28 Nov 2013 10:05:18 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: <52978488.4010108@alvestrand.no> References: <52978488.4010108@alvestrand.no> From: Eric Rescorla Date: Thu, 28 Nov 2013 10:05:18 -0800 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codec selection: Dropping options X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 18:06:02 -0000 On Thu, Nov 28, 2013 at 9:59 AM, Harald Alvestrand wrote: > On 11/28/2013 11:40 AM, Jeremy Fuller wrote: >> Since we appear to be entering the realm of voting game theory, +1 to dropping options where consensus has previously proven to be unobtainable. These options have had their moment, time to focus on something else. > > The WG has never voted on these alternatives; what failed was an attempt > at finding consensus. > > Furhtermore, the choice of voting method that the chairs are still > advocating (IRV) is one where presence of non-selected alternatives on > the slate can influence the outcome. Without taking a position on which system we should use, I would note that this is also true of Condorcet. http://en.wikipedia.org/wiki/Condorcet_method#Evaluation_by_criteria -Ekr > I'm not enough of a game theorist to figure out which way the presence > of the previously non-consensual options may influence the ballot, but I > don't think I am in agreement with dropping these alternatives from the > ballot. > > (I still haven't decided whether or not I'm in agreement with doing a > ballot at all, though.) > >> >> "Insanity is doing the same thing over and over and expecting different results" >> >> Date: Thu, 28 Nov 2013 12:20:25 +0200 >> From: Leon Geyser >> To: "rtcweb@ietf.org" >> Subject: Re: [rtcweb] Video codec selection: Dropping options >> Message-ID: >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> I also agree on this. >> >> Also 5 does not mean anything. >> I don't like my own option of 8 that much, because 10 is much better :) >> 11 and 13 are scary options. >> If 12 is possible it would be a great option. Do most patents only apply for encoding? >> >> I am a bit confused about option 15. How does that one work? >> Let's say I have a two sides: H.264 encoding/decoding + Theora decoder and the other side has VP8 encoding/decoding + Theora decoder. How do they communicate? >> >> >> On 28 November 2013 10:22, wrote: >> >>> Hi, >>> >>> I'm not much in favor of the voting, but if we do it: >>> >>> Based on the consensus call we already held in Vancouver, I would >>> propose to drop from the list in [1] any options that make exclusively >>> VP8 mandatory to implement or exclusively H.264 mandatory to >>> implement. I think we have already established that much, and >>> including those options in any vote seems wrong. >>> >>> In practice I'm talking about these four options: >>> 1. All entities MUST support H.264 >>> 2. All entities MUST support VP8 >>> 3. All entities MUST support both H.264 and VP8 4. Browsers MUST >>> support both H.264 and VP8, other entities MUST support at least one >>> of H.264 and VP8 >>> >>> What the WG should focus on is to see if there is a consensus on any >>> of the so called "fallback" options vs. no MTI. I think these are all >>> valid as such as a "fallback": >>> >>> 5. All entities MUST support at least one of H.264 and VP8 6. All >>> entities MUST support H.261 7. There is no MTI video codec 8. 5+6, >>> i.e. All entities MUST support H.261 and all entities MUST support at >>> least one of H.264 and VP8 9. All entities MUST support Theora 10. All >>> entities MUST implement at least two of {VP8, H.264, H.261} 11. All >>> entities MUST implement at least two of {VP8, H.264, H.263} 12. All >>> entities MUST support decoding using both H.264 and VP8, and MUST >>> support encoding using at least one of H.264 or VP8 13. All entities >>> MUST support H.263 14. All entities MUST implement at least two of >>> {VP8, H.264 CBP, Theora} 15. All entities MUST support decoding using >>> Theora. >>> >>> I think it would be problematic even if one of options 1-4 came out as >>> a winner from a voting procedure, since it would force a large part of >>> the community to implement something they have valid reasons to avoid. >>> Some of the options 5-15 may have issues as well, but at least a >>> consensus call among them would still be in order, since we haven't really had it so far. >>> And presumably the issues and polarization are "smaller" than with the >>> VP8 vs. H.264 argument. >>> >>> Regards, >>> Markus >>> >>> [1] http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart >>> >>> _______________________________________________ >>> 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 > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From gmartincocher@blackberry.com Thu Nov 28 10:51:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2751ADFBE for ; Thu, 28 Nov 2013 10:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph4AgHi4KhgE for ; Thu, 28 Nov 2013 10:51:28 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3B41ADF26 for ; Thu, 28 Nov 2013 10:51:28 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 28 Nov 2013 13:51:25 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0158.001; Thu, 28 Nov 2013 13:51:25 -0500 From: Gaelle Martin-Cocher To: Ted Hardie Thread-Topic: [rtcweb] Last day for any additional Video Codec Selection alternatives Thread-Index: AQHO67i6dNo34aPgQE+1qfFpjXBB+po6/ATQ Date: Thu, 28 Nov 2013 18:51:24 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AA548AF935@XMB111CNC.rim.net> References: <5295B358.1040302@ericsson.com> <5295DA58.60504@jitsi.org> <5295E663.4020607@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA548ADD3C@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AA548AE06C@XMB111CNC.rim.net> In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AA548AF935XMB111CNCrimnet_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alternatives X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 18:51:32 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AA548AF935XMB111CNCrimnet_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thanks. I would propose profile 0 level 70 defined in annex X of http://www.itu.int/rec/T-REC-H.263/ Sincerely, Ga=EBlle From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: Wednesday, November 27, 2013 4:36 PM To: Gaelle Martin-Cocher Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alt= ernatives On Wed, Nov 27, 2013 at 11:38 AM, Gaelle Martin-Cocher > wrote: If we proceed with the vote, I would like to see the following choice: All entities must support H263. Thanks Ga=EBlle I've updated the wiki to include this as choice 13. If you have a referenc= e that we could use that specifies version, annexes, or any other additiona= l detail, we can include a pointer. Ted -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Gaelle Martin-Cocher Sent: Wednesday, November 27, 2013 11:29 AM To: Magnus Westerlund; Emil Ivov Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alt= ernatives Dear All, Sorry for this late message, I was not available this past week. It has been mentioned by a few of us that the risks on VP8 that some can't = leave with, can be mitigated when VP8 becomes an ISO standard (via MPEG). VP8 has a chance to become an MPEG deliverable in January. I believe that c= ould make a few of us more comfortable with supporting/mandating both H264 = and VP8 and could change the consensus reaching process. Can we give VP8 that chance before forcing a vote? Thanks Sincerely, Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: Wednesday, November 27, 2013 7:33 AM To: Emil Ivov Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alt= ernatives On 2013-11-27 12:41, Emil Ivov wrote: > Just to confirm, this is NOT the last day of discussion on whether a > vote is the right way to do this at all, right? No, but tomorrow a week will have passed since we chairs sent out the propo= sal and solicited feedback on the proposal. > > That sounds like it would still be an open question for step two here: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html As we stated in this message, after the week we chairs would update the pro= cess proposal if we considered it necessary. I believe there are some clari= fications that needs to be done, including the voter eligibility. After that the stated plan was to hold a consensus call in the WG to use th= e proposed process. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_92D0D52F3A63344CA478CF12DB0648AA548AF935XMB111CNCrimnet_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Thanks.=

 <= /p>

I would propose profile 0= level 70 defined in annex X of

http://www.itu.int/rec/T-REC-H.263/

 <= /p>

Sincerely,

Ga=EBlle

 <= /p>

 <= /p>

From: Ted Hard= ie [mailto:ted.ietf@gmail.com]
Sent: Wednesday, November 27, 2013 4:36 PM
To: Gaelle Martin-Cocher
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Last day for any additional Video Codec Select= ion alternatives

 

On Wed, Nov 27, 2013 at 11:38 AM, Gaelle Martin-Coch= er <gm= artincocher@blackberry.com> wrote:

If we proceed with the vote, I would like to see the= following choice:
All entities must support H263.

Thanks
Ga=EBlle

 

 

I've updated the wiki to include this as choice 13.&= nbsp; If you have a reference that we could use that specifies version, ann= exes, or any other additional detail, we can include a pointer.

Ted

 


-----Original Message-----
From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of Gaelle Martin-Cocher
Sent: Wednesday, November 27, 2013 11:29 AM
To: Magnus Westerlund; Emil Ivov
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alt= ernatives

Dear All,

Sorry for this late message, I was not available this past week.

It has been mentioned by a few of us that the risks on VP8 that some can't = leave with, can be mitigated when VP8 becomes an ISO standard (via MPEG). VP8 has a chance to become an MPEG deliverable in January. I believe that c= ould make a few of us more comfortable with supporting/mandating both H264 = and VP8 and could change the consensus reaching process.

Can we give VP8 that chance before forcing a vote?

Thanks
Sincerely,
Ga=EBlle


-----Original Message-----
From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of Magnus Westerlund
Sent: Wednesday, November 27, 2013 7:33 AM
To: Emil Ivov
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Last day for any additional Video Codec Selection alt= ernatives

On 2013-11-27 12:41, Emil Ivov wrote:
> Just to confirm, this is NOT the last day of discussion on whether a > vote is the right way to do this at all, right?

No, but tomorrow a week will have passed since we chairs sent out the propo= sal and solicited feedback on the proposal.

>
> That sounds like it would still be an open question for step two here:=
>
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html

As we stated in this message, after the week we chairs would update the pro= cess proposal if we considered it necessary. I believe there are some clari= fications that needs to be done, including the voter eligibility.

After that the stated plan was to hold a consensus call in the WG to use th= e proposed process.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone =  +46 10 7148287
F=E4r=F6gatan 6                | Mo= bile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

 

---------------------------------------------------------------------
Th= is transmission (including any attachments) may contain confidential inform= ation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immed= iately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by uni= ntended recipients is not authorized and may be unlawful.
--_000_92D0D52F3A63344CA478CF12DB0648AA548AF935XMB111CNCrimnet_-- From Ted.Lemon@nominum.com Thu Nov 28 12:51:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F79B1AE218; Thu, 28 Nov 2013 12:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPqXofMqEPfY; Thu, 28 Nov 2013 12:51:29 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0D04D1AE215; Thu, 28 Nov 2013 12:51:28 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUpesz4tPNxUT20MFRm3L38wktIkafW3+@postini.com; Thu, 28 Nov 2013 12:51:28 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1B9201B82E8; Thu, 28 Nov 2013 12:51:27 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E6776190043; Thu, 28 Nov 2013 12:51:26 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 12:51:26 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <5006.1385666853@sandelman.ca> Date: Thu, 28 Nov 2013 15:51:22 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: IETF Discussion , rtcweb@ietf.org, Dave Crocker , Eric Burger , rtcweb-chairs@tools.ietf.org Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 20:51:30 -0000 On Nov 28, 2013, at 2:27 PM, Michael Richardson = wrote: > That tells me that the participants are not willing to live with = losing and > move on, and so no voting process will work either. Right, that's the concern. From emil@sip-communicator.org Thu Nov 28 13:03:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882641ADF9B for ; Thu, 28 Nov 2013 13:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14LHIqKiB3YC for ; Thu, 28 Nov 2013 13:03:42 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3511ADA5D for ; Thu, 28 Nov 2013 13:03:41 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so6754731wgh.17 for ; Thu, 28 Nov 2013 13:03:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2ro5KfhwkDlrlLlQEwsW6Xkw0YSwBp/rBOITwxPG9Eg=; b=m3xRQIG8u/WKj7Rm7NpJyDgqHzWwxtMPPf2B69o3Fn6rALe/jKoTIaC6Q9jZ+EdGGA KuUIn9IO4/Af4YXLwJKeBtApqdRrUoB4zJGq1wsMAJB8n1fSrTvnIyHQRXR4+WQ2xPBQ W41Z7tbrKQYJhgYOScDsr0h/KDX3RrP9KLXcAaFA2AwrJ3yZKYvsBB0BSP8wjN49IolF LqRckLjlp/u0mHCZTxOhYJbCnmWTQPDhO+bQa44yydSCSiI4AZE3L3PrJ65vd6EJhTDY O/8+xrycZUYNj2cIXNQbDqlS6orwEXr06PwrkQFGPwhyOV7AQ/dq+GbAD3ZONFuC4TBV TLTQ== X-Gm-Message-State: ALoCoQk58cj5j//0WJWKBVSQBk8NKgCU99+IiH/AJeKCRst4p9jL/z1ulIw6L8M/rHOrOCK3eDBq X-Received: by 10.180.76.204 with SMTP id m12mr4087104wiw.9.1385672620389; Thu, 28 Nov 2013 13:03:40 -0800 (PST) Received: from camionet.local (neu67-4-88-160-65-79.fbx.proxad.net. [88.160.65.79]) by mx.google.com with ESMTPSA id b7sm85603409wiz.8.2013.11.28.13.03.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 13:03:39 -0800 (PST) Message-ID: <5297AFA8.5000107@jitsi.org> Date: Thu, 28 Nov 2013 22:03:36 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cowwoc References: <529680EF.4010908@jitsi.org> <5296BA5E.20801@bbs.darktech.org> In-Reply-To: <5296BA5E.20801@bbs.darktech.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: [rtcweb] Why voting is not a viable process for the IETF (Was: Last day for any additional Video Codec Selection alternatives ) X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 21:03:44 -0000 On 28.11.13, 04:37, cowwoc wrote: > I've heard objections along the lines of "IETF does not vote. We reach > consensus by evaluating the technical merits of each argument and choose > the one with the least number of objections". Note that these are not just a matter of ideology there are very practical reasons why voting can't be properly implemented here. More on that below. > My counter-argument is that this isn't a technical question Then there is NO reason for it to be answered by the IETF. > (we've > reached consensus that both VP8 and H.264 are "good enough" from a > technical point of view). This is a legal and political question. Exactly the kind of questions that the IETF does NOT handle. >> I haven't seen anyone explaining how any possible constituency would >> be defended > > That is a legitimate concern, but I believe that with additional > discussion we'll be able to reach a consensus on it. No we won't. We can't. Determining constituency is a very laborious process that should have been completed while setting up the body that will be taking the decision. To be more specific, it should in the very least be in our charter. It has to be clear in advance that voting is a possible outcome of all discussions. It has to be clear who will be allowed to vote and, just as importantly, who won't be. A good practice would be to then contact potentially interested parties and inform them of the process and voting conditions so that they can choose to get involved and make sure they satisfy those conditions. The rules that are currently being presented are EXPLICITLY PREVENTING people from getting involved in the process and becoming a part of the vote from now on. This is such a glaring deficiency that I am amazed we are still discussing the option. The rules that have been presented basically sound like: "here are the people that we think will produce the result we are looking for" Now, I would never assume that our chairs would attempt to game a process that they are proposing to us. I am simply convinced the pressure of choosing an MTI has made them overlook the problems. >> You seem to assume that rough consensus necessarily lies somewhere. It >> doesn't. Sometimes people agree to disagree. > > Anyone who feels this way should feel free to vote for "No MTI". Voting "No MTI" is a very different position than not agreeing with a vote. >> What if 30% objected to voting as a third choice? > > I suspect that if a substantial number of people vote for "No MTI" then > it would warrant further investigation. I can't comment on what the > actual threshold should be. No one could. Not here. >> Or it may be game theory in action. It's an entirely new land where >> the IETF has not ventured before. Doing so now cannot work! A vote in >> the IETF is only a reason to contest the results forever and discredit >> the work of this group. > > I don't agree. Giving up on MTI because of we have multiple good options > and a very polarized community would be like throwing out the baby with > the bathwater. I don't necessarily agree with that but if people think an MTI is of utmost importance and a vote is the only way to get it, they can then simply achieve that in any of the multiple bodies that allow for this (e.g. W3C) or simply establish a new one that will. Cheers, Emil -- https://jitsi.org From bernard_aboba@hotmail.com Thu Nov 28 13:40:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFF41AE23F for ; Thu, 28 Nov 2013 13:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z0ggLx89kOL for ; Thu, 28 Nov 2013 13:40:56 -0800 (PST) Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by ietfa.amsl.com (Postfix) with ESMTP id E9A941AE17F for ; Thu, 28 Nov 2013 13:40:55 -0800 (PST) Received: from BLU169-W81 ([65.55.116.72]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Nov 2013 13:40:55 -0800 X-TMN: [wG3meOB52UYvhsZOCoJZgg2ovy29Wo2i] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_fbb7a298-6ea9-4b81-bde3-4afc1e953572_" From: Bernard Aboba To: Emil Ivov Date: Thu, 28 Nov 2013 13:40:54 -0800 Importance: Normal In-Reply-To: <5297AFA8.5000107@jitsi.org> References: <529680EF.4010908@jitsi.org>, <5296BA5E.20801@bbs.darktech.org>, <5297AFA8.5000107@jitsi.org> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Nov 2013 21:40:55.0285 (UTC) FILETIME=[847A8A50:01CEEC82] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why voting is not a viable process for the IETF (Was: Last day for any additional Video Codec Selection alternatives ) X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 21:40:58 -0000 --_fbb7a298-6ea9-4b81-bde3-4afc1e953572_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > This is a legal and political question. >=20 > Exactly the kind of questions that the IETF does NOT handle. =20 [BA] Indeed. Legal questions are handled in the courts=2C political questi= ons are handled within legislatures/parliaments (or in the case of a monarc= hy/dictatorship by the dictator or monarch). Last time I looked=2C the IET= F was neither a court nor a legislative body (nor within the jurisdiction o= f a specific monarch or dictator).=20 =20 So I fail to see how the outcome of this proposed vote could be expected to= convince someone who is concerned about legal/IPR issues that their concer= ns have been addressed. Is legal counsel expected to view the outcome and = say "I had concerns relating to the IPR/licensing risks of but now that the IETF RTCWEB WG has concluded its voting process=2C I r= ealize that my concerns were merely the invention of an over-active legal m= ind!"=20 > The rules that have been presented basically sound like: "here are the pe= ople that we think will produce the result we are looking for" =20 [BA] I am SHOCKED=2C SHOCKED that such a thing could be going on here! http://www.youtube.com/watch?v=3DSjbPi00k_ME =20 = --_fbb7a298-6ea9-4b81-bde3-4afc1e953572_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B >=3B This is a lega= l and political question.
>=3B
>=3B Exactly the kind of question= s that the IETF does NOT handle.
 =3B
[BA] Indeed. =3B Legal = questions are handled in the courts=2C political questions are handled with= in legislatures/parliaments (or in the case of a monarchy/dictatorship by t= he dictator or monarch). =3B Last time I looked=2C the IETF was neither= a court nor a legislative body (nor within the jurisdiction of a specific = monarch or dictator).
 =3B
So I fail to see how the outcome of t= his proposed vote could be expected to convince someone who is concerned ab= out legal/IPR issues that their concerns have been addressed. =3B Is le= gal =3Bcounsel expected to view the outcome and say "I had concerns rel= ating to the IPR/licensing risks of <=3Binsert codec here>=3B but now t= hat the IETF RTCWEB WG has concluded its voting process=2C I realize that m= y concerns were merely the invention of an over-active legal mind!"
>=3B The rules that have been presented basically sound like: "here are = the people that we think will produce the result we are looking for"
&nb= sp=3B
[BA] I am SHOCKED=2C SHOCKED =3Bthat such a thing could be goi= ng on here!
htt= p://www.youtube.com/watch?v=3DSjbPi00k_ME
 =3B
= --_fbb7a298-6ea9-4b81-bde3-4afc1e953572_-- From cowwoc@bbs.darktech.org Thu Nov 28 13:49:36 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914E01AE0E1 for ; Thu, 28 Nov 2013 13:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YubqbjRmz9f1 for ; Thu, 28 Nov 2013 13:49:35 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFC41AE06C for ; Thu, 28 Nov 2013 13:49:35 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id e14so15012060iej.14 for ; Thu, 28 Nov 2013 13:49:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qJd9IoZgOhpoOpTyT1xAh1QZYkb5P96yXAP2beB+xh4=; b=RIGTIThC1QEoYwV+1/kE5CSEARdjB52JK06Oc9P269PHp49tbhID3oIl9aB1l0jnhc oiEZkP0me/abGA5wimx3+iai1lvB+7hAFn0DkFIvIsr7nQ7fXLRiJ5uy3lUJita29d1d 4TbMbNSzg9fMoukEv/jRlqI9DRazy+m1wDuy7rQ0PMl5Z2uAvkegiEeFlQY/1xu2MQ3C vYfqcLKAQ1figb8CR7h7A4rCcQC6kl181vsMlNJ/NCGLWh0eC7VI2tN+LE0hhi367HU0 AhV8h6uA7ENIk+VopX5kAW7nqpAh8KV0/6QC+BI6K2qmGP3Z69zf9ImrXiHpA9ln2dgG Ui3A== X-Gm-Message-State: ALoCoQnKa0ltNkei1XXveTTiZx5K1tYo3jHK5kJyswuoUHgT1YrkS1jKJeZ5dxKAkVjc49ZUB5pl X-Received: by 10.50.115.35 with SMTP id jl3mr3545299igb.37.1385675374102; Thu, 28 Nov 2013 13:49:34 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id hv5sm47680385igb.9.2013.11.28.13.49.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 13:49:33 -0800 (PST) Message-ID: <5297BA3E.9030708@bbs.darktech.org> Date: Thu, 28 Nov 2013 16:48:46 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529680EF.4010908@jitsi.org> <5296BA5E.20801@bbs.darktech.org> <5297AFA8.5000107@jitsi.org> In-Reply-To: <5297AFA8.5000107@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Why voting is not a viable process for the IETF (Was: Last day for any additional Video Codec Selection alternatives ) X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 21:49:36 -0000 On 28/11/2013 4:03 PM, Emil Ivov wrote: > Voting "No MTI" is a very different position than not agreeing with a > vote. It is my understanding that you are advocating that IETF abandon its attempt to mandate an MTI codec. How is this any different (on a practical level) than voting "No MTI"? I'd rather settle on the 3rd-best codec than no MTI at all. Whether we reach a compromise through voting or alternative approaches such as the one brought up by Gaëlle doesn't really concern me. Gili From silviapfeiffer1@gmail.com Thu Nov 28 14:06:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BC21ADFDC for ; Thu, 28 Nov 2013 14:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNB8z7ZgKdhX for ; Thu, 28 Nov 2013 14:06:26 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A4B1C1AE160 for ; Thu, 28 Nov 2013 14:06:26 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id gq1so9328017obb.31 for ; Thu, 28 Nov 2013 14:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Q1i6Q+FP//dfNBtvoISr3963hjRkDB0G1VZDjwr6HOE=; b=wTYmSBELKrNX1dXqzk2Z2OVYh8uZcG/EdgwFW1gYvoyP8yRAO71b2bj4GIwd6Rgf7D H0AafF9QqrqO5TJ6id1yfaDoQGE7xyexuI1HoBnd5WhOrGozEbYANXFOARPUwrxIUCsk VrmbrtxhNZA8OXeq22gZONB/HWT35V5Hi4y9BAXz5rD5j9WNhQHeyvyLp/+xwZhPMPca iVPIAAz7fDIoZUlOdrtIfx156++OyYGovTRDyFZfgSS7FbW/S7EdDM78i+OlBIq0mDDL pLbXbYycqom0YPxG+XI0fBxFiCjDYglSVHMCEJi8yvxi5eCosKDWeS91s+cdQyTiMm3X Fs4A== X-Received: by 10.182.227.136 with SMTP id sa8mr21656565obc.39.1385676385541; Thu, 28 Nov 2013 14:06:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.68.106 with HTTP; Thu, 28 Nov 2013 14:06:05 -0800 (PST) In-Reply-To: <5297AFA8.5000107@jitsi.org> References: <529680EF.4010908@jitsi.org> <5296BA5E.20801@bbs.darktech.org> <5297AFA8.5000107@jitsi.org> From: Silvia Pfeiffer Date: Fri, 29 Nov 2013 09:06:05 +1100 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why voting is not a viable process for the IETF (Was: Last day for any additional Video Codec Selection alternatives ) X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 22:06:27 -0000 On Fri, Nov 29, 2013 at 8:03 AM, Emil Ivov wrote: > > > On 28.11.13, 04:37, cowwoc wrote: >> >> I've heard objections along the lines of "IETF does not vote. We reach >> consensus by evaluating the technical merits of each argument and choose >> the one with the least number of objections". > > > Note that these are not just a matter of ideology there are very practical > reasons why voting can't be properly implemented here. > > More on that below. > >> My counter-argument is that this isn't a technical question > > > Then there is NO reason for it to be answered by the IETF. > >> (we've >> reached consensus that both VP8 and H.264 are "good enough" from a >> technical point of view). This is a legal and political question. > > > Exactly the kind of questions that the IETF does NOT handle. Standards are created such that system are able to interoperate with each other. Deciding to avoid the decision for an MTI and thus creating non-interoperable rtcweb systems is giving up on standardising interoperability. IMO that is very much a technical question. What if we standardised power plugs and sockets and couldn't agree on the shape of the plug and socket, so left it for anyone to do what they liked. I'd call that a failed standardisation. It's the same here: if we can't agree on what encoding and decoding formats must be supported, we can't plug a WebRTC connection together. #FAIL Regards, Silvia. From bernard_aboba@hotmail.com Thu Nov 28 14:24:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEE71AE160 for ; Thu, 28 Nov 2013 14:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-icAb02oJEB for ; Thu, 28 Nov 2013 14:24:48 -0800 (PST) Received: from blu0-omc1-s5.blu0.hotmail.com (blu0-omc1-s5.blu0.hotmail.com [65.55.116.16]) by ietfa.amsl.com (Postfix) with ESMTP id 76C0B1AE14B for ; Thu, 28 Nov 2013 14:24:48 -0800 (PST) Received: from BLU169-W49 ([65.55.116.8]) by blu0-omc1-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Nov 2013 14:24:47 -0800 X-TMN: [b57TuVuRxcnCh+5cMz+/lUCef8xXoF01] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c785fc0c-f343-4f28-ae4e-f51bae59eab8_" From: Bernard Aboba To: Silvia Pfeiffer , Emil Ivov Date: Thu, 28 Nov 2013 14:24:47 -0800 Importance: Normal In-Reply-To: References: <529680EF.4010908@jitsi.org>,<5296BA5E.20801@bbs.darktech.org> <5297AFA8.5000107@jitsi.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 28 Nov 2013 22:24:47.0748 (UTC) FILETIME=[A58C8440:01CEEC88] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Why voting is not a viable process for the IETF (Was: Last day for any additional Video Codec Selection alternatives ) X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 22:24:50 -0000 --_c785fc0c-f343-4f28-ae4e-f51bae59eab8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > if we can't agree on what encoding and decoding formats must be > supported=2C we can't plug a WebRTC connection together. #FAIL [BA] Just because the IETF can't come to consensus doesn't mean that intero= peration won't be possible. With respect to streaming video=2C the W3C cou= ld not come to consensus on an MTI codec=2C yet today=2C millions of Intern= et users are able to watch videos. =20 = --_c785fc0c-f343-4f28-ae4e-f51bae59eab8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B if we can't agree on what= encoding and decoding formats must be
>=3B supported=2C we can't plug= a WebRTC connection together. #FAIL


[BA] Just because the IETF = can't come to consensus doesn't mean that interoperation won't be possible.=  =3BWith respect to streaming video=2C the W3C could not come to conse= nsus on an MTI codec=2C yet today=2C millions of Internet users are able to= watch videos.  =3B
= --_c785fc0c-f343-4f28-ae4e-f51bae59eab8_-- From cowwoc@bbs.darktech.org Thu Nov 28 14:27:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A861ADF8C for ; Thu, 28 Nov 2013 14:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cXkxOKHRH3t for ; Thu, 28 Nov 2013 14:27:02 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id AE5DB1A1F7D for ; Thu, 28 Nov 2013 14:27:02 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so15010454ieb.36 for ; Thu, 28 Nov 2013 14:27:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=y4wwG0WuMDUdtDQJeOMueQoZ1EbwGwYc9DLgRCaeu0A=; b=PRk8vaCNJP8lzOsdK+fGZJGzH16hPO4EApN2ZTpjKtGrnUPb3ejKlKtqf+mCXexgF9 0LfmUY+lIfKzyhpiQ4yJZkXksXqqjQjwrms7Qw5Ga39qv2BYONVoFwxvrN/dFZs/fx1N AHFvKLjYAuFL72wyj2FMDdOJFZThmp/P7qMLYS5cp7BFfI1pDhUjVubR5pGrOwkLoXel UsJ1TQhWVMSmSAIzTuFmd6bx+Og+8ToVK4rJEFhAWyxR3zu0b1x44dRBcYoSWvixLPvt W3dvlcWCRCbEt52iS87rnSp5c4Mq+H6wYPM7vm7vtaclB0NfYiASlYN04i8IZxPbjr6s 4u4Q== X-Gm-Message-State: ALoCoQkaZ9X/cEXRN2dNdp6FGicv/8VGZHBeOQvoXcvDIm4Ywzc4+i4E8t6Leqvb4mLaqT66pMVp X-Received: by 10.42.215.11 with SMTP id hc11mr10449338icb.47.1385677621616; Thu, 28 Nov 2013 14:27:01 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id qi3sm47156433igc.8.2013.11.28.14.27.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 14:27:00 -0800 (PST) Message-ID: <5297C306.1070905@bbs.darktech.org> Date: Thu, 28 Nov 2013 17:26:14 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529680EF.4010908@jitsi.org>, <5296BA5E.20801@bbs.darktech.org> <5297AFA8.5000107@jitsi.org>, In-Reply-To: Content-Type: multipart/alternative; boundary="------------030503070307020109060508" Subject: Re: [rtcweb] Why voting is not a viable process for the IETF (Was: Last day for any additional Video Codec Selection alternatives ) X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 22:27:04 -0000 This is a multi-part message in MIME format. --------------030503070307020109060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 28/11/2013 5:24 PM, Bernard Aboba wrote: > > if we can't agree on what encoding and decoding formats must be > > supported, we can't plug a WebRTC connection together. #FAIL > > > [BA] Just because the IETF can't come to consensus doesn't mean that > interoperation won't be possible. With respect to streaming video, > the W3C could not come to consensus on an MTI codec, yet today, > millions of Internet users are able to watch videos. > That's because servers are able to offer the same pre-recorded video in multiple formats. The same is not true for WebRTC where: * There might not be a server. * Transcoding video in real-time is expensive. GIli --------------030503070307020109060508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 28/11/2013 5:24 PM, Bernard Aboba wrote:
> if we can't agree on what encoding and decoding formats must be
> supported, we can't plug a WebRTC connection together. #FAIL


[BA] Just because the IETF can't come to consensus doesn't mean that interoperation won't be possible.  With respect to streaming video, the W3C could not come to consensus on an MTI codec, yet today, millions of Internet users are able to watch videos.  


That's because servers are able to offer the same pre-recorded video in multiple formats. The same is not true for WebRTC where:
  • There might not be a server.
  • Transcoding video in real-time is expensive.
GIli
--------------030503070307020109060508-- From bernard_aboba@hotmail.com Thu Nov 28 14:39:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7461AD93D; Thu, 28 Nov 2013 14:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t34kEP0xp41F; Thu, 28 Nov 2013 14:39:50 -0800 (PST) Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by ietfa.amsl.com (Postfix) with ESMTP id 782D91ADF76; Thu, 28 Nov 2013 14:39:50 -0800 (PST) Received: from BLU169-W117 ([65.55.111.71]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Nov 2013 14:39:49 -0800 X-TMN: [EYXemPDCGUI6iZmav9gk6jFDCOA5EPEX] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_84423b41-b90c-4658-b731-012e92c49847_" From: Bernard Aboba To: Ted Lemon , Michael Richardson Date: Thu, 28 Nov 2013 14:39:49 -0800 Importance: Normal In-Reply-To: References: , <52974AA8.6080702@cisco.com>, <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com>, <52976F56.4020706@dcrocker.net>, <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com>, <5006.1385666853@sandelman.ca>, MIME-Version: 1.0 X-OriginalArrivalTime: 28 Nov 2013 22:39:49.0779 (UTC) FILETIME=[BF338630:01CEEC8A] Cc: "rtcweb-chairs@tools.ietf.org" , "rtcweb@ietf.org" , IETF Discussion , Eric Burger , Dave CROCKER Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 22:39:52 -0000 --_84423b41-b90c-4658-b731-012e92c49847_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > On Nov 28=2C 2013=2C at 2:27 PM=2C Michael Richardson wrote: > That tells me that the participants are not willing to live with losing a= nd > move on=2C and so no voting process will work either. [BA] The participants aren't willing to live with losing for business or le= gal reasons that aren't within the jurisdiction of an IETF WG. As an examp= le=2C would an open source product that requires source code to be provide= d without a license fee put that aside because IETF RTCWEB has agreed upon = H.264 as MTI? Similarly=2C would a vendor who is concerned about potential= liability from incorporating VP8 put that concern aside because the IETF R= TCWEB WG has decided to make VP8 MTI? =20 Given that "alternative decision processes" are quite unlikely to influence= participant behavior=2C it is appropriate to question why such a voting p= rocess is being used=2C without at least a determination of consensus to do= so.=20 = --_84423b41-b90c-4658-b731-012e92c49847_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B On Nov 28=2C 2013=2C at 2= :27 PM=2C Michael Richardson <=3Bmcr+ietf@sandelman.ca>=3B wrote:
&g= t=3B That tells me that the participants are not willing to live with losin= g and
>=3B move on=2C and so no voting process will work either.
[BA] The participants aren't willing to live with losing for business or = legal reasons that aren't within the jurisdiction of an IETF WG.  =3BAs= an example=2C  =3Bwould an open source product that requires source co= de to be provided without a license fee put that aside because IETF RTCWEB = has agreed upon H.264 as MTI?  =3BSimilarly=2C would a vendor who is co= ncerned about potential liability from incorporating VP8 put that concern a= side because the IETF RTCWEB WG has decided to make VP8 MTI?  =3B

Given that "alternative decision processes" are quite unlikely to inf= luence participant behavior=2C  =3Bit is appropriate to question why su= ch a voting process is being used=2C without at least a determination of co= nsensus to do so. =3B
= --_84423b41-b90c-4658-b731-012e92c49847_-- From emil@sip-communicator.org Thu Nov 28 14:44:21 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13281AE04D for ; Thu, 28 Nov 2013 14:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFdgsavaE0eM for ; Thu, 28 Nov 2013 14:44:20 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9221ADF72 for ; Thu, 28 Nov 2013 14:44:20 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hm4so1382566wib.7 for ; Thu, 28 Nov 2013 14:44:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YhBhUK5SV6Q47zfot+TEHVETKTw17LIqIZGsWkfH3Fw=; b=GkR5lSERCQ+zDg9p8g0TCuJuUIrbUIU1mr5DiAWHbTNuQHi89KnUiIa0Az0ja44yU4 N2cJkWa1IK1KjjTYdZ+ks63N+6FpU3QMha9Fwx2GZyl2EeFfja+ZtPQTgRStrlW6jD3c GCGUhO/+vJL/Y0Ilwrfkj/Vs4ZkloAeKALsXTyOe0xBtlXIXMbwk1f3+HfwXvZKw3XcL uRPByOeEUd5oCHzTmhe4dEeHPR2ZKnLzZUFOCJHBaLcWhEKX3HgcIutcZqS0jiD2TzK8 elHk9rgYHOWNyY77XK6QMTv/xRZo60DUB6K79Vt42AOBK17ayEgK8jg7khYnF8dlSEa7 Mfpg== X-Gm-Message-State: ALoCoQk3sW/NOzxChg1VR0rbDtUQtArY9XhFowkuYt7WARdXdnahJ7nZwneHtnyypwXjqdnxt/T9 X-Received: by 10.194.78.141 with SMTP id b13mr21870568wjx.32.1385678658742; Thu, 28 Nov 2013 14:44:18 -0800 (PST) Received: from camionet.local ([2a01:e35:8a04:14f0:e0dc:6c8b:ed3a:af2e]) by mx.google.com with ESMTPSA id w20sm85704773wia.5.2013.11.28.14.44.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 14:44:17 -0800 (PST) Message-ID: <5297C73F.6080600@jitsi.org> Date: Thu, 28 Nov 2013 23:44:15 +0100 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cowwoc References: <529680EF.4010908@jitsi.org>, <5296BA5E.20801@bbs.darktech.org> <5297AFA8.5000107@jitsi.org>, <5297C306.1070905@bbs.darktech.org> In-Reply-To: <5297C306.1070905@bbs.darktech.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why voting is not a viable process for the IETF (Was: Last day for any additional Video Codec Selection alternatives ) X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 22:44:22 -0000 On 28.11.13, 23:26, cowwoc wrote: > On 28/11/2013 5:24 PM, Bernard Aboba wrote: >> > if we can't agree on what encoding and decoding formats must be >> > supported, we can't plug a WebRTC connection together. #FAIL >> >> >> [BA] Just because the IETF can't come to consensus doesn't mean that >> interoperation won't be possible. With respect to streaming video, >> the W3C could not come to consensus on an MTI codec, yet today, >> millions of Internet users are able to watch videos. >> > > That's because servers are able to offer the same pre-recorded video in > multiple formats. The same is not true for WebRTC where: > > * There might not be a server. > * Transcoding video in real-time is expensive. The point is that solutions emerge. SIP has been in exactly the same situation for a few years now and, last I checked, it was enjoying quite the popularity. -- https://jitsi.org From sm@resistor.net Thu Nov 28 14:45:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C161AE23F for ; Thu, 28 Nov 2013 14:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdHUKDDPad9L for ; Thu, 28 Nov 2013 14:45:11 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2365E1AE17F for ; Thu, 28 Nov 2013 14:45:11 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rASMiumL026104; Thu, 28 Nov 2013 14:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1385678703; bh=TAB4LQBym6VJ3/J6sS4tw4gHvrSFwLhALprYRu4AbK0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3rgnmHzqzgPFTB4sMTBP0O3eTSMwsiG8K0cb58zQCCwvYlrgaDyGHehso9Osx9J1N chQU3gCfjYqWhn53LzLoiLjIsKYRgEeWuM6dk3mywljIcwft+ZQ4YZMNoKNsx8fWw5 TDM/P0SedfEzJRMi3aAL0xiPsgsLAUGtNMETHcBo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1385678703; i=@resistor.net; bh=TAB4LQBym6VJ3/J6sS4tw4gHvrSFwLhALprYRu4AbK0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pduEeEu1Q5kPfeeHhe0zSGjRgEZg18vV/5i4ljDgswghohqSVeQ62tIPwl4rwh40j mDsPnDqXU7KgrzGK9R61bbGUkCi0APneCzI0jZE0XBtjpA0jPSZcIVdQ6WsY+egYJe LuOKMjkvgI0yHWo+78vNyEINkbGkCY4um0+nzucM= Message-Id: <6.2.5.6.2.20131128133436.0b951538@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Nov 2013 14:05:48 -0800 To: Emil Ivov , cowwoc , Bernard Aboba , Silvia Pfeiffer From: SM In-Reply-To: <5297AFA8.5000107@jitsi.org> References: <529680EF.4010908@jitsi.org> <5296BA5E.20801@bbs.darktech.org> <5297AFA8.5000107@jitsi.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why voting is not a viable process for the IETF (Was: Last day for any additional Video Codec Selection alternatives ) X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 22:45:13 -0000 At 13:03 28-11-2013, Emil Ivov wrote: >Exactly the kind of questions that the IETF does NOT handle. In my humble opinion it does. >It has to be clear in advance that voting is a possible outcome of >all discussions. It has to be clear who will be allowed to vote and, >just as importantly, who won't be. A good practice would be to then >contact potentially interested parties and inform them of the >process and voting conditions so that they can choose to get >involved and make sure they satisfy those conditions. There are some details in the message at http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html about the eligibility rules. I think that I may be eligible but I am not sure. >The rules that are currently being presented are EXPLICITLY >PREVENTING people from getting involved in the process and becoming >a part of the vote from now on. This is such a glaring deficiency >that I am amazed we are still discussing the option. It is to prevent breaking the rules to gain unfair advantage. :-) >The rules that have been presented basically sound like: "here are >the people that we think will produce the result we are looking for" I have not looked into the details to take a guess about whether it is possible to predict the outcome. Several decision-making alternatives have been put before this working group. It seems that there has been difficulty getting people to agree on how to find a way to agree. There isn't much an Area Director or a Working Group can do in those circumstances. At 13:40 28-11-2013, Bernard Aboba wrote: >So I fail to see how the outcome of this proposed vote could be >expected to convince someone who is concerned about legal/IPR issues >that their concerns have been addressed. Is legal counsel expected >to view the outcome and say "I had concerns relating to the >IPR/licensing risks of but now that the IETF >RTCWEB WG has concluded its voting process, I realize that my >concerns were merely the invention of an over-active legal mind!" I would not conclude that there isn't any IPR issue based on the conclusion of the decision process. I am not keen about voting as it can be a problem in future. >[BA] I am SHOCKED, SHOCKED that such a thing could be going on here! >http://www.youtube.com/watch?v=SjbPi00k_ME This is a moment of humor at in that video. :-) At 14:06 28-11-2013, Silvia Pfeiffer wrote: >Standards are created such that system are able to interoperate with >each other. Deciding to avoid the decision for an MTI and thus >creating non-interoperable rtcweb systems is giving up on >standardising interoperability. IMO that is very much a technical >question. Yes. Regards, -sm From cowwoc@bbs.darktech.org Thu Nov 28 15:25:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB8A1AE147 for ; Thu, 28 Nov 2013 15:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECamyEWxQ1de for ; Thu, 28 Nov 2013 15:25:38 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8141ADF64 for ; Thu, 28 Nov 2013 15:25:38 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id to1so15360053ieb.32 for ; Thu, 28 Nov 2013 15:25:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0ydgh6Nhog2ooL63cegY2KykSF6xbOFYZflcXEON96s=; b=XeyDBtN0+1c5kpk9ToTZEcqJDJYcsuGns54VWISC5wRgcIQznl4GevcqW0l5m0cA+H DpkSIelSYZebEvaOlLRa39agbwAKl9sykRAk2qxgu/LxSB9TQaq8c6t7tmkn7Jqo5Fx+ hoa5tpdVpMRnjijZQH39xCIDFG8I3wlyRnS0lNW16Bte3DSYMSHcDFSwsT4qnkikz2Co uXo0KOekgeoEjww44mporTmvPwrq+AaDzS4FujMITgRtDCSf16LWN/Ypxd9TSW/V8fGg ASy53L6E21ygA66j5VONOO0K53iHKFZeta2ZcBXf+p50RmOyX+697OtOgsHqqT1T2qMg 364A== X-Gm-Message-State: ALoCoQn4W3F/i3XUhuyctN8Y0Q5CmVHvNSEGUIQKCKdwIFaasJBir6inJag+bvpQls/2VfrldHaB X-Received: by 10.50.73.201 with SMTP id n9mr3816832igv.8.1385681137103; Thu, 28 Nov 2013 15:25:37 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id x6sm47409320igb.3.2013.11.28.15.25.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 15:25:35 -0800 (PST) Message-ID: <5297D0C1.80105@bbs.darktech.org> Date: Thu, 28 Nov 2013 18:24:49 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Emil Ivov References: <529680EF.4010908@jitsi.org>, <5296BA5E.20801@bbs.darktech.org> <5297AFA8.5000107@jitsi.org>, <5297C306.1070905@bbs.darktech.org> <5297C73F.6080600@jitsi.org> In-Reply-To: <5297C73F.6080600@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Why voting is not a viable process for the IETF (Was: Last day for any additional Video Codec Selection alternatives ) X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 23:25:39 -0000 On 28/11/2013 5:44 PM, Emil Ivov wrote: > > > On 28.11.13, 23:26, cowwoc wrote: >> On 28/11/2013 5:24 PM, Bernard Aboba wrote: >>> > if we can't agree on what encoding and decoding formats must be >>> > supported, we can't plug a WebRTC connection together. #FAIL >>> >>> >>> [BA] Just because the IETF can't come to consensus doesn't mean that >>> interoperation won't be possible. With respect to streaming video, >>> the W3C could not come to consensus on an MTI codec, yet today, >>> millions of Internet users are able to watch videos. >>> >> >> That's because servers are able to offer the same pre-recorded video in >> multiple formats. The same is not true for WebRTC where: >> >> * There might not be a server. >> * Transcoding video in real-time is expensive. > > The point is that solutions emerge. > > SIP has been in exactly the same situation for a few years now and, > last I checked, it was enjoying quite the popularity Video is a lot more expensive to transcode than audio. Correct me if I'm wrong, but isn't SIP predominantly used to carry audio? Gili From keith.drage@alcatel-lucent.com Thu Nov 28 17:08:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0901AE047; Thu, 28 Nov 2013 17:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8uDQih-JHuh; Thu, 28 Nov 2013 17:08:06 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 21E0C1ADFE1; Thu, 28 Nov 2013 17:08:06 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rAT17q7k012506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Nov 2013 19:07:54 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rAT17pTK005877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Nov 2013 02:07:51 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 29 Nov 2013 02:07:52 +0100 From: "DRAGE, Keith (Keith)" To: Ted Lemon , Dave Crocker Thread-Topic: [rtcweb] Alternative decision process in RTCWeb Thread-Index: AQHO7FvNsYxRjdMaJkWnvYaO/CT08po7YxVQ Date: Fri, 29 Nov 2013 01:07:51 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0EF1B8@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> In-Reply-To: <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Eric Burger , "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" , Eliot Lear , IETF Discussion Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 01:08:08 -0000 While I don't believe the WG would be positive on that, I do not believe th= at question has been put to a consensus call. So I would question the word = specifically.=20 If you still believe it so, please tell me when you think the WG decided th= is. Keith=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: 28 November 2013 17:03 > To: Dave Crocker > Cc: rtcweb-chairs@tools.ietf.org; Eliot Lear;=20 > rtcweb@ietf.org; Eric Burger; IETF Discussion > Subject: Re: [rtcweb] Alternative decision process in RTCWeb >=20 > On Nov 28, 2013, at 11:29 AM, Dave Crocker wrote: > > As merely one obvious example, people can simply be tired of the=20 > > impasse and eagerly seek progress and be willing to settle on any=20 > > mechanism they think will fairly break it -- even if it=20 > works against=20 > > the outcome they prefer. >=20 > The one tidbit you may be missing is that the working group=20 > specifically chose not to do a coin toss. So "willing to=20 > settle for any mechanism" clearly doesn't apply in this case. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From Ted.Lemon@nominum.com Thu Nov 28 19:38:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEC11AE15C; Thu, 28 Nov 2013 19:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAc6Nog1tTA7; Thu, 28 Nov 2013 19:38:16 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC201AE15A; Thu, 28 Nov 2013 19:38:16 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUpgMJ+M9Y2yDOmkFS7DQ8Hb1qWOKt+eL@postini.com; Thu, 28 Nov 2013 19:38:15 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 411DC1B82E8; Thu, 28 Nov 2013 19:38:15 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2FA28190043; Thu, 28 Nov 2013 19:38:15 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 19:38:08 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0EF1B8@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 28 Nov 2013 22:38:03 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <949EF20990823C4C85C18D59AA11AD8B0EF1B8@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: IETF Discussion , Eliot Lear , "rtcweb@ietf.org" , Dave Crocker , Eric Burger , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 03:38:17 -0000 On Nov 28, 2013, at 8:07 PM, DRAGE, Keith (Keith) = wrote: > If you still believe it so, please tell me when you think the WG = decided this. I'm just going by what people have told me. If the working group = hasn't indeed been asked whether they would accept the outcome of a coin = toss, I would argue that that question should be asked. From ron@debian.org Thu Nov 28 22:10:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1508B1AE0EA; Thu, 28 Nov 2013 22:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oy-hWEvIuoqW; Thu, 28 Nov 2013 22:10:02 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id C2DC71AE0CC; Thu, 28 Nov 2013 22:10:01 -0800 (PST) Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail06.adl6.internode.on.net with ESMTP; 29 Nov 2013 16:39:57 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id D19C24F8F3; Fri, 29 Nov 2013 16:39:38 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sF3sA9YHnPVO; Fri, 29 Nov 2013 16:39:36 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id BE9FB4F902; Fri, 29 Nov 2013 16:39:36 +1030 (CST) Date: Fri, 29 Nov 2013 16:39:36 +1030 From: Ron To: Bernard Aboba Message-ID: <20131129060936.GV3245@audi.shelbyville.oz> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IETF Discussion , Michael Richardson , "rtcweb@ietf.org" , Ted Lemon , Eric Burger , Dave CROCKER , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 06:10:04 -0000 On Thu, Nov 28, 2013 at 02:39:49PM -0800, Bernard Aboba wrote: > > On Nov 28, 2013, at 2:27 PM, Michael Richardson wrote: > > That tells me that the participants are not willing to live with losing and > > move on, and so no voting process will work either. > > [BA] The participants aren't willing to live with losing for business or > legal reasons that aren't within the jurisdiction of an IETF WG. As an > example, would an open source product that requires source code to be > provided without a license fee put that aside because IETF RTCWEB has agreed > upon H.264 as MTI? Similarly, would a vendor who is concerned about > potential liability from incorporating VP8 put that concern aside because the > IETF RTCWEB WG has decided to make VP8 MTI? I think EKR said this more succinctly with: "it's important to understand that in in this case, many people more don't want X than do want Y." And I think you both have clearly identified the problem, and why voting is clearly not a solution to it. The blocking issue is that many people have valid reasons why they _can't_ deploy one or more of the possible choices. You can't possibly solve that by taking a poll of what the majority of people would _prefer_, ignoring all other people's blocking constraints. However I think we can still resolve this by following normal consensus procedures, and walking our way up from the least troublesome options to the most, and seeing at what point consensus actually breaks down. 1. Do we want an MTI codec? It's generally accepted there is consensus the answer to this is Yes. We also have a list of codecs that we could possibly choose from. It also seems generally accepted that IPR trouble is the least negotiable problem that is at the heart of many objections. So let's start where that problem is the smallest, at the very bottom: 2. Can anybody show a sustainable objection for why we _can't_ use H.261. If they can, we're probably doomed. If they can't we have an initial choice for MTI. 3. Can anybody show a sustainable objection for why can't replace H.261 as the MTI codec? If they can, lather rinse repeat through the other alternatives. If they can't, we have a new baseline to ask this question of for the remaining alternatives. Yes, this may take some time (but surely less than we've already spent), but it clearly separates the question of what people _can't_ do, from what they would prefer to do if they had their druthers. We probably won't get the best possible codec as the MTI fallback, but we probably will get a decision that isn't fundamentally doomed. And that's fine, because people will still get their preferred codec through runtime negotiation if they use an implementation which does accept the risk of supporting it - and the safe interop fallback if it doesn't. Why would this one simple procedure not work to resolve the deadlock? Ron From mcr@sandelman.ca Thu Nov 28 11:27:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B821ADF76; Thu, 28 Nov 2013 11:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ-Gsk-P8xxH; Thu, 28 Nov 2013 11:27:37 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 54AC71ADF5E; Thu, 28 Nov 2013 11:27:37 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2268820030; Thu, 28 Nov 2013 15:40:33 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id AD4D763B88; Thu, 28 Nov 2013 14:27:33 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9EBFE63AED; Thu, 28 Nov 2013 14:27:33 -0500 (EST) From: Michael Richardson To: Ted Lemon In-Reply-To: <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Fri, 29 Nov 2013 00:18:14 -0800 Cc: IETF Discussion , rtcweb@ietf.org, Dave Crocker , Eric Burger , rtcweb-chairs@tools.ietf.org Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Thu, 28 Nov 2013 19:27:39 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: > On Nov 28, 2013, at 11:29 AM, Dave Crocker wrote: >> As merely one obvious example, people can simply be tired of the >> impasse and eagerly seek progress and be willing to settle on any >> mechanism they think will fairly break it -- even if it works against >> the outcome they prefer. > The one tidbit you may be missing is that the working group > specifically chose not to do a coin toss. So "willing to settle for > any mechanism" clearly doesn't apply in this case. That tells me that the participants are not willing to live with losing and move on, and so no voting process will work either. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUpeZIIqHRg3pndX9AQKz6QQAzaQ/hQD8y32hQGjs5K9rkn1AMDF8kspN nev172QPnBGXZKehK3lAxYDcLkUA2v7HN6f9pBQwQ30DqoCWJQgvvaoyfEX55cet pt6VAxvlgLTvSbBE0DxMCcxVRyvIqG+cBdlzaT01dwpDCOGkoOdmnfoi61EdNZ0o L+jNePhjAPE= =3TA0 -----END PGP SIGNATURE----- --=-=-=-- From maikmerten@googlemail.com Fri Nov 29 00:28:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A941AE28D for ; Fri, 29 Nov 2013 00:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJts9PNNCrNq for ; Fri, 29 Nov 2013 00:28:54 -0800 (PST) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A46961AE28C for ; Fri, 29 Nov 2013 00:28:53 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id g15so6499930eak.32 for ; Fri, 29 Nov 2013 00:28:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Hzrbo9JP4K3gfsAV4fqjKw/fUKXzOKZp5wsXBubgTuI=; b=u7nQ6aDLT6mLtZwUvYx5Y+VnJFjMJk0NVBSXKa1Y+vGCrgRDQU2kAVNU+HIXSOSsLu NijLlOpXm0qgvklAAIbbYBxPpG6dPJxz0MrbB4+rjj7hLg4VXXb6egHvxcDlZxufp6tE CmS/O8kVhcBOsUwwZEFHcxYW6Wg+oFcHlru5DgLZPkiX4A/Rjxqm9V3g3dit86vFQWGM ld+pBBLd+YOmk7IKSHotRiAfDaF2Xr6v6UEFrty2n/mMTnwkGoQaqGlcyxzn3Sr0FYjP MXB7Xz8AOtEECtrCz6hhVdpAdrHR5na5mg8SJH7GMaouDwoj2S/EpepHpecJ2AddNyG/ jwWg== X-Received: by 10.14.149.13 with SMTP id w13mr71796eej.134.1385713732155; Fri, 29 Nov 2013 00:28:52 -0800 (PST) Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id b41sm14711042eef.16.2013.11.29.00.28.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 00:28:50 -0800 (PST) Message-ID: <529850A4.606@googlemail.com> Date: Fri, 29 Nov 2013 09:30:28 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> In-Reply-To: <20131129060936.GV3245@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 08:28:56 -0000 I very much agree with Ron here. Given that both H.264 and VP8 seem to not be universally deployable by all participants in all scenarios I guess many will agree that reaching consensus on one of those may not be realistic. So it appears that we need $fallback (to be later used in something like "all entities MUST implement $fallback" or "all entities MUST implement at least two of {H.264, VP8, $fallback}" etc.). As far as I can see following codecs have been mentioned as possible candidates for $fallback: H.261, MPEG-1 Part 2, H.263, Theora (sorted by age and performance) I don't remember seeing an exploratory discussion to determine what (if any) codecs are considered to have "acceptable risk" (this is different from "no risk", which may not be achievable). However, it may take some time for each participant to make their own risk assessment. Thus I very much like Ron's proposal of starting discussion with the codec with the lowest perceived IPR risk and trying to move to higher performance levels until substantial indication shows up that the next step brings "unacceptable risk". Maik Am 29.11.2013 07:09, schrieb Ron: > On Thu, Nov 28, 2013 at 02:39:49PM -0800, Bernard Aboba wrote: >>> On Nov 28, 2013, at 2:27 PM, Michael Richardson wrote: >>> That tells me that the participants are not willing to live with losing and >>> move on, and so no voting process will work either. >> >> [BA] The participants aren't willing to live with losing for business or >> legal reasons that aren't within the jurisdiction of an IETF WG. As an >> example, would an open source product that requires source code to be >> provided without a license fee put that aside because IETF RTCWEB has agreed >> upon H.264 as MTI? Similarly, would a vendor who is concerned about >> potential liability from incorporating VP8 put that concern aside because the >> IETF RTCWEB WG has decided to make VP8 MTI? > > I think EKR said this more succinctly with: > > "it's important to understand that in in this case, many people more > don't want X than do want Y." > > And I think you both have clearly identified the problem, and why voting > is clearly not a solution to it. > > > The blocking issue is that many people have valid reasons why they _can't_ > deploy one or more of the possible choices. You can't possibly solve that > by taking a poll of what the majority of people would _prefer_, ignoring > all other people's blocking constraints. > > > However I think we can still resolve this by following normal consensus > procedures, and walking our way up from the least troublesome options to > the most, and seeing at what point consensus actually breaks down. > > > 1. Do we want an MTI codec? > > It's generally accepted there is consensus the answer to this is Yes. > We also have a list of codecs that we could possibly choose from. > It also seems generally accepted that IPR trouble is the least > negotiable problem that is at the heart of many objections. > > So let's start where that problem is the smallest, at the very bottom: > > > 2. Can anybody show a sustainable objection for why we _can't_ use H.261. > > If they can, we're probably doomed. If they can't we have an initial > choice for MTI. > > > 3. Can anybody show a sustainable objection for why > can't replace H.261 as the MTI codec? > > If they can, lather rinse repeat through the other alternatives. > If they can't, we have a new baseline to ask this question of > for the remaining alternatives. > > > Yes, this may take some time (but surely less than we've already spent), > but it clearly separates the question of what people _can't_ do, from > what they would prefer to do if they had their druthers. > > We probably won't get the best possible codec as the MTI fallback, > but we probably will get a decision that isn't fundamentally doomed. > And that's fine, because people will still get their preferred codec > through runtime negotiation if they use an implementation which does > accept the risk of supporting it - and the safe interop fallback if > it doesn't. > > > Why would this one simple procedure not work to resolve the deadlock? > > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Fri Nov 29 01:31:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D0D1A1F55 for ; Fri, 29 Nov 2013 01:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUNGDArO7JrF for ; Fri, 29 Nov 2013 01:31:35 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0421ACB4E for ; Fri, 29 Nov 2013 01:31:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B1D1339E132 for ; Fri, 29 Nov 2013 10:31:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSF4AgnBshtN for ; Fri, 29 Nov 2013 10:31:35 +0100 (CET) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 067BE39E091 for ; Fri, 29 Nov 2013 10:31:35 +0100 (CET) Message-ID: <52985F2F.6030507@alvestrand.no> Date: Fri, 29 Nov 2013 10:32:31 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Video codec selection: Dropping options X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 09:31:37 -0000 On 11/28/2013 11:20 AM, Leon Geyser wrote: > I also agree on this. > > Also 5 does not mean anything. > I don't like my own option of 8 that much, because 10 is much better :) > 11 and 13 are scary options. > If 12 is possible it would be a great option. Do most patents only > apply for encoding? > One curiosity of the way standards for codecs are produced is that only the decoder is normative. So the only patents licensors are required to disclose in the standards process are patents on the decoder. In theory, I think they could also be required to disclose patents that apply to any possible encoder for which this is a valid decoder, but I think this is unlikely to happen in practice (because most such patents would also describe the decoding part). But that is uncomfortably close to speculation, so don't trust me on that. From grmocg@gmail.com Fri Nov 29 00:22:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707801AE02E; Fri, 29 Nov 2013 00:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTJg2bfhwSOV; Fri, 29 Nov 2013 00:22:54 -0800 (PST) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id B22571ACC89; Fri, 29 Nov 2013 00:22:54 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id h16so10121812oag.11 for ; Fri, 29 Nov 2013 00:22:53 -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=3Ml4TX7BVH5Jrnk9atmXVCVALsEpScy6EMRmZtz03CI=; b=JUQmVrfJT96w1L0hJSftIzChFSFzuN80XJnrp4zxsN6KA+bkmYQeRPlaoY5biPQLpi 7RbObCd7mHw45MizhK4CLJJzbQn6ZxM7Hexp1XNlllSZiaO6jLFRTl4TxoiMYOcdkhfB SQE5HsFRGqlx+XWQsGUCPVEjUdQqhtuGwCARlqkD1IZjdowz6Is7ltc5T0aIxTxml93o 2GAHzrUWS3YGQ3IV9ujrx9M8ZDhSAbc+R/o392/aeEaqe0qI5ZkimA7ns1voseFk/l9q ERBODLSD3/UTvsuSwyORxF9TBQ93wGEtKuh//kMu8UG9T4taktG1n3RWhw/G9zrdNVle OxEQ== MIME-Version: 1.0 X-Received: by 10.182.18.102 with SMTP id v6mr572184obd.71.1385713373534; Fri, 29 Nov 2013 00:22:53 -0800 (PST) Received: by 10.76.105.114 with HTTP; Fri, 29 Nov 2013 00:22:53 -0800 (PST) In-Reply-To: References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <949EF20990823C4C85C18D59AA11AD8B0EF1B8@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Fri, 29 Nov 2013 00:22:53 -0800 Message-ID: From: Roberto Peon To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c339e663e12704ec4c8990 X-Mailman-Approved-At: Fri, 29 Nov 2013 02:06:42 -0800 Cc: "rtcweb-chairs@tools.ietf.org" , "rtcweb@ietf.org" , Dave Crocker , Eric Burger , IETF Discussion Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 08:22:56 -0000 --001a11c339e663e12704ec4c8990 Content-Type: text/plain; charset=ISO-8859-1 I'd prefer seeing the charter changed and no codec mandated. The only reason to specify a must-implement is to increase interop; if mandating a codec does not increase the amount of interop, why do it? -=R On Thu, Nov 28, 2013 at 7:38 PM, Ted Lemon wrote: > On Nov 28, 2013, at 8:07 PM, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > > If you still believe it so, please tell me when you think the WG decided > this. > > I'm just going by what people have told me. If the working group hasn't > indeed been asked whether they would accept the outcome of a coin toss, I > would argue that that question should be asked. > > --001a11c339e663e12704ec4c8990 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'd prefer seeing the charter changed and no codec man= dated.
The only reason to specify a must-implement is to incr= ease interop; if mandating a codec does not increase the amount of interop,= why do it?

-=3DR


On Thu, Nov 28, 2013 at 7:38 PM, Ted Le= mon <ted.lemon@nominum.com> wrote:
On Nov 28, 2013, at 8:07 PM, DRAGE, Keith (K= eith) <keith.drage@alc= atel-lucent.com> wrote:
> If you still believe it so, please tell me when you think the WG decid= ed this.

I'm just going by what people have told me. =A0 If the working group ha= sn't indeed been asked whether they would accept the outcome of a coin = toss, I would argue that that question should be asked.


--001a11c339e663e12704ec4c8990-- From harald@alvestrand.no Fri Nov 29 04:00:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37131ADFF3 for ; Fri, 29 Nov 2013 04:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTY3wwbm6UfZ for ; Fri, 29 Nov 2013 04:00:32 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5551ADF5B for ; Fri, 29 Nov 2013 04:00:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7AC9039E209; Fri, 29 Nov 2013 13:00:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gd9OZLyT0psu; Fri, 29 Nov 2013 13:00:31 +0100 (CET) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 883E039E132; Fri, 29 Nov 2013 13:00:31 +0100 (CET) Message-ID: <52988217.3030101@alvestrand.no> Date: Fri, 29 Nov 2013 13:01:27 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Eric Rescorla References: <52978488.4010108@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codec selection: Dropping options X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 12:00:35 -0000 On 11/28/2013 07:05 PM, Eric Rescorla wrote: > On Thu, Nov 28, 2013 at 9:59 AM, Harald Alvestrand wrote: >> On 11/28/2013 11:40 AM, Jeremy Fuller wrote: >>> Since we appear to be entering the realm of voting game theory, +1 to dropping options where consensus has previously proven to be unobtainable. These options have had their moment, time to focus on something else. >> The WG has never voted on these alternatives; what failed was an attempt >> at finding consensus. >> >> Furhtermore, the choice of voting method that the chairs are still >> advocating (IRV) is one where presence of non-selected alternatives on >> the slate can influence the outcome. > Without taking a position on which system we should use, I would note > that this is also true of Condorcet. > > http://en.wikipedia.org/wiki/Condorcet_method#Evaluation_by_criteria I think this is only true for candidates that form part of a Condorcet cycle. If we get a real live Condorcet cycle, I for one am willing to live with any of the cycle members just because Condorcet cycles are cool :-) From Markus.Isomaki@nokia.com Fri Nov 29 04:43:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B5B1AE072 for ; Fri, 29 Nov 2013 04:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh9oXOdv5TcG for ; Fri, 29 Nov 2013 04:43:51 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 910AF1ADF7E for ; Fri, 29 Nov 2013 04:43:51 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.49]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rATChItc018375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 29 Nov 2013 14:43:18 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.177]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.03.0158.002; Fri, 29 Nov 2013 12:43:17 +0000 From: To: , Thread-Topic: [rtcweb] Video codec selection: Dropping options Thread-Index: Ac7sDy85pPAEQkadSWWa4C8bEEktTwAOQIeAACyVqTA= Date: Fri, 29 Nov 2013 12:43:17 +0000 Message-ID: References: <5297568D.9060400@ericsson.com> In-Reply-To: <5297568D.9060400@ericsson.com> 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; x-titus-version: 3.5.9.3 x-headerinfofordlp: x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IsMYwYvlwi0oDC9KWeaffszB1/ZYqd+OD2BouzEFndLN7BAiPZ+/0+97SEfaJsl0V83yHn2UsjJ0oZkMko6shHKl5KyR7wQNuOzrQYKPzxsNVJzztM+wRNGi6nhbl27qFYzaqJ0Vc3EjNGA3qWTgvrfIUK4Pgcrh0pJJ82SLH4gTnCf9s4ZdJ15uF9e4MnqaYhftkNQrVhRoBo1aLtHmRspLr4LbGKwmnh0nbDCBOIOp x-originating-ip: [10.236.10.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Subject: Re: [rtcweb] Video codec selection: Dropping options X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 12:43:53 -0000 Hi Magnus, Thanks for your reply. magnus.westerlund@ericsson.com wrote: > =20 > I hope you see the problem with eliminating alternatives by any form of c= hair > decision at this time. Thus we would be forced to run different sets of > consensus calls to determine if there are consensus to eliminate as well = as > which. >=20 OK, fair enough. I understand the chairs are in a difficult situation with = all the proposals flying around.=20 > Thus, I would consider your comment as, the process we chairs are proposi= ng > is the wrong one. > Yes. My opinion is that we should NOT go for the vote as currently proposed= .=20 I think the right track would be along the lines that Maik Merten recently = suggested: > So it appears that we need $fallback (to be later used in something like = "all > entities MUST implement $fallback" or "all entities MUST implement at lea= st > two of {H.264, VP8, $fallback}" etc.). As far as I can see following code= cs have > been mentioned as possible candidates for $fallback: >=20 > H.261, MPEG-1 Part 2, H.263, Theora (sorted by age and performance) And if the there is no rough consensus for any of these fallback options de= clare "no MTI".=20 (Perhaps it can be argued that the proposed voting method will find the sam= e out as well, but it is much less clear.)=20 Markus=20 From magnus.westerlund@ericsson.com Fri Nov 29 05:40:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8021AE029 for ; Fri, 29 Nov 2013 05:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bw6FYMmoBNt5 for ; Fri, 29 Nov 2013 05:40:08 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 72C6D1AD7C2 for ; Fri, 29 Nov 2013 05:40:07 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-2a-52989934e3ad Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8E.AF.03802.43998925; Fri, 29 Nov 2013 14:40:05 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.328.9; Fri, 29 Nov 2013 14:40:03 +0100 Message-ID: <52989933.6000907@ericsson.com> Date: Fri, 29 Nov 2013 14:40:03 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Martin Thomson , "rtcweb@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvra7pzBlBBlf+K1p0TGazuHbmH6PF 2n/t7A7MHlN+b2T12DnrLrvHkiU/mQKYo7hsUlJzMstSi/TtErgyrnw8w1rwUqpiwqfJzA2M D0S7GDk5JARMJN59PckMYYtJXLi3nq2LkYtDSOAQo8S1a79YIZzljBKz/ixiBKniFdCW6Nj0 F8hm52ARUJXYpAoSZROwkLj5o5ENxBYVCJa42ruOGaJaUOLkzCcsILaIQIjEkbbprCA2s4Ca xKPLh8FqhAU0Je5cawabLiQQIDHnwTSwGk6BQImX17YD1XAA3SYu0dMYBNGqJzHlagsjhC0v 0bx1NjNEq7ZEQ1MH6wRGoVlINs9C0jILScsCRuZVjOy5iZk56eVGmxiBgXtwy2/VHYx3zokc YpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2P3eqbotsXKe3L+8f7xS1fc /HRK7GfTaTtUP4Y+/afGvS4ilMOPdfNmh2d9X2sKK5+2b5vKyZVw+O7tj1l5T8SjZM48+B53 Ksf+3kef2O11jEcOWmY9upWSXuzE+Ctpa5Ddo8/N3FqlpU6Bzu0PVto6Ho0/fYS9cHnmnHO2 0xpdJjFt1frSnqfEUpyRaKjFXFScCABt8x8RKgIAAA== Cc: Cullen Jennings Subject: Re: [rtcweb] Consent alternative X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 13:40:10 -0000 On 2013-11-22 18:55, Martin Thomson wrote: > I know that I've been a fan of consent via ICE, but with the decision > in Berlin to move to DTLS only, several of us have observed that > perhaps RFC 6520 might be a better alternative. > > We've put together an exploration of the idea here: > > http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00 > > The best part of this is that it changes the dynamics (for the better, > I think). You don't need to send extra packets if you are actively > using the flow. That means that 1:1 sessions won't need to spend > extra cycles or bytes on keeping the session live. > > There are some gotchas for multiparty sessions, but I believe those to > be manageable. Hi, I have looked briefly on this and wonder if this isn't vulnerable to active attacks from a attacker (Alice) that likes to use a set of WebRTC browsers, including (Bob) to generate DDOS traffic towards the target (Charlie). So Alice has a web-service which see has attracted a user base or subverted an existing one for her purpose. The users of said web-service includes Bob. So Alice gets Bob's browser to establish a PeerConnection with Alice, establishing an DTLS security context between them. Then using the regular signaling Alice triggers an ICE reneg, to move the transport address target for the Alice to Bob PC to become between Bob and Charlie. This will require that Alice can intercept or spoof binding requests response to the Bob's binding requests, especially anyone promoting it for use so that Bob thinks the ICE reneg succeeds with Charlie's transport address. When that has happened, Alice can send periodically Bob DTLS messages with source address spoofed like they come from Charlie's transport address to maintain consent. Alice also can use the Stats API and the HTTP/Websocket connection to Alice web service to forge DTLS protected RTCP report block messages for the traffic Bob sends to Charlie. Comparing the ICE based mechanism and the DTLS based consent mechanisms I would draw the following conclusions. 1. If one doesn't have any chance to intercept STUN binding requests at all, they are equally secure. 2. If the attacker has some limited or very expensive method for intercepting Bob's STUN binding requests, then he might be able to mount the above attack using DTLS consent as he only needs interception initially when moving Bob to the target, compared to continuously as long as he like to maintain the attack using the ICE based method. Cases when this might apply is when Bob are in a poorly protected shared network and Alice or Alice agent likes to leave the network after having initiated the attack, rather than have to remain. This change of properties is due to that the consent is associated with the DTLS connections security context, rather than constant return routability with random token property that ICE has. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From cowwoc@bbs.darktech.org Fri Nov 29 07:55:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC0F1ADEA3 for ; Fri, 29 Nov 2013 07:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrCVtx0c0sJx for ; Fri, 29 Nov 2013 07:55:28 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id E6B491AE002 for ; Fri, 29 Nov 2013 07:55:23 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so16048327ieb.22 for ; Fri, 29 Nov 2013 07:55:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gRoEWRkekSR35LyXEKiIbl+TDatXx2s470ywEl2QO8U=; b=CiISa4xao2qhEB1j8Klz2Y89drnFVSL2M8SGJ4rS4BHZYaN6892fIguwP21W1w0o86 +OMTyO/tBh2cN0Pf+I/+uwLkpeZleXkWWta0OIN2SE+he2nOCFfuxQZB/0SEUslReyyO 7eUEVk+dpYmF1YCWziBNFtombWagaOuLM6naa7K/FPJwmjb5L8CTpKNeL1vRYONmiJro F4Wk1MiBJN2ucwRzB3z00PYZ50Y3YKKauEkmh46KO3cKJmixDnVshPpSEkQ+Alv3hvcj dMm7ri+nQJNTVqpwE/bV/UeS0cJ1f87PLEdkWRfMjm1QGr+cqaoshG8XzfLq4qnSpiFg 4bNQ== X-Gm-Message-State: ALoCoQnYYId0uB2VKwZaPt4pBVAy7s0T1MKOrREqmkKX/JiFvto9gVgiW+Mk7p8shhWA4EuQywUW X-Received: by 10.50.82.10 with SMTP id e10mr6844343igy.58.1385740522637; Fri, 29 Nov 2013 07:55:22 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p14sm50845121igr.7.2013.11.29.07.55.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 07:55:21 -0800 (PST) Message-ID: <5298B8BB.70307@bbs.darktech.org> Date: Fri, 29 Nov 2013 10:54:35 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <529850A4.606@googlemail.com> In-Reply-To: <529850A4.606@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 15:55:31 -0000 I'm in favor of this approach, with a fallback to voting if that fails, with a fallback to "No MTI" if that fails. Gili On 29/11/2013 3:30 AM, Maik Merten wrote: > I very much agree with Ron here. Given that both H.264 and VP8 seem to > not be universally deployable by all participants in all scenarios I > guess many will agree that reaching consensus on one of those may not > be realistic. > > So it appears that we need $fallback (to be later used in something > like "all entities MUST implement $fallback" or "all entities MUST > implement at least two of {H.264, VP8, $fallback}" etc.). As far as I > can see following codecs have been mentioned as possible candidates > for $fallback: > > H.261, MPEG-1 Part 2, H.263, Theora (sorted by age and performance) > > I don't remember seeing an exploratory discussion to determine what > (if any) codecs are considered to have "acceptable risk" (this is > different from "no risk", which may not be achievable). However, it > may take some time for each participant to make their own risk > assessment. Thus I very much like Ron's proposal of starting > discussion with the codec with the lowest perceived IPR risk and > trying to move to higher performance levels until substantial > indication shows up that the next step brings "unacceptable risk". > > > Maik > > Am 29.11.2013 07:09, schrieb Ron: >> On Thu, Nov 28, 2013 at 02:39:49PM -0800, Bernard Aboba wrote: >>>> On Nov 28, 2013, at 2:27 PM, Michael Richardson >>>> wrote: >>>> That tells me that the participants are not willing to live with >>>> losing and >>>> move on, and so no voting process will work either. >>> >>> [BA] The participants aren't willing to live with losing for >>> business or >>> legal reasons that aren't within the jurisdiction of an IETF WG. As an >>> example, would an open source product that requires source code to be >>> provided without a license fee put that aside because IETF RTCWEB >>> has agreed >>> upon H.264 as MTI? Similarly, would a vendor who is concerned about >>> potential liability from incorporating VP8 put that concern aside >>> because the >>> IETF RTCWEB WG has decided to make VP8 MTI? >> >> I think EKR said this more succinctly with: >> >> "it's important to understand that in in this case, many people more >> don't want X than do want Y." >> >> And I think you both have clearly identified the problem, and why voting >> is clearly not a solution to it. >> >> >> The blocking issue is that many people have valid reasons why they >> _can't_ >> deploy one or more of the possible choices. You can't possibly solve >> that >> by taking a poll of what the majority of people would _prefer_, ignoring >> all other people's blocking constraints. >> >> >> However I think we can still resolve this by following normal consensus >> procedures, and walking our way up from the least troublesome options to >> the most, and seeing at what point consensus actually breaks down. >> >> >> 1. Do we want an MTI codec? >> >> It's generally accepted there is consensus the answer to this is >> Yes. >> We also have a list of codecs that we could possibly choose from. >> It also seems generally accepted that IPR trouble is the least >> negotiable problem that is at the heart of many objections. >> >> So let's start where that problem is the smallest, at the very bottom: >> >> >> 2. Can anybody show a sustainable objection for why we _can't_ use >> H.261. >> >> If they can, we're probably doomed. If they can't we have an >> initial >> choice for MTI. >> >> >> 3. Can anybody show a sustainable objection for why >> can't replace H.261 as the MTI codec? >> >> If they can, lather rinse repeat through the other alternatives. >> If they can't, we have a new baseline to ask this question of >> for the remaining alternatives. >> >> >> Yes, this may take some time (but surely less than we've already spent), >> but it clearly separates the question of what people _can't_ do, from >> what they would prefer to do if they had their druthers. >> >> We probably won't get the best possible codec as the MTI fallback, >> but we probably will get a decision that isn't fundamentally doomed. >> And that's fine, because people will still get their preferred codec >> through runtime negotiation if they use an implementation which does >> accept the risk of supporting it - and the safe interop fallback if >> it doesn't. >> >> >> Why would this one simple procedure not work to resolve the deadlock? >> >> Ron >> >> >> _______________________________________________ >> 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 From john@jlc.net Fri Nov 29 08:40:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBDD1AD8D5 for ; Fri, 29 Nov 2013 08:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yztWvTL5olgG for ; Fri, 29 Nov 2013 08:40:53 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 468961A1F5F for ; Fri, 29 Nov 2013 08:40:53 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 22ADCC94BE; Fri, 29 Nov 2013 11:40:50 -0500 (EST) Date: Fri, 29 Nov 2013 11:40:50 -0500 From: John Leslie To: Magnus Westerlund Message-ID: <20131129164050.GF87911@verdi> References: <52936207.5040704@ericsson.com> <5295B273.1060305@ericsson.com> <5295F718.9010603@ericsson.com> <20131127175414.GA87911@verdi> <52971935.50408@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA548AF45D@XMB111CNC.rim.net> <52975223.50209@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52975223.50209@ericsson.com> User-Agent: Mutt/1.4.1i Cc: rtcweb@ietf.org Subject: Re: [rtcweb] The Voting Process X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 16:40:55 -0000 Magnus Westerlund wrote: > > The chairs did prepare to start the consensus call with an updated > procedure. However, based on the last 24 hours feedback I think we will > have to evaluate the latest feedback and determine what we see as the > next step. This seems like a good time to expand on the "Condorcet" issue. Condorcet methods set out to solve a real issue. (There is a lot of discussion available on the web about what other problems they cause while doing so -- if you care about that, go look.) In most versions of "Instant Runoff" voting, one option can be everybody's second choice but nobody's first choice -- and be eliminated as a possible winner at the first round of transfers. That is a plausible problem here. :^( It's arguably possible that "no MTI" could be everybody's second choice but nobody's first choice; and thus be eliminated. This is not necessarily a killer problem; but intelligent voters would have to take that into account, and enough of them would have to list no-MTI as their first choice with their actual first choice listed second. (I am not asking for any particular change here: merely hoping to help folks understand why several posters seem to be hung-up on using Condorcet rules instead.) -- John Leslie From lgeyser@gmail.com Fri Nov 29 10:01:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26D61AD6C1 for ; Fri, 29 Nov 2013 10:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeKteKf8iShZ for ; Fri, 29 Nov 2013 10:01:48 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AC0051ACCFC for ; Fri, 29 Nov 2013 10:01:47 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id eh20so7149904lab.32 for ; Fri, 29 Nov 2013 10:01:45 -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=RZgRZsAHoAJv/Z4AWdrBgm8CzDUsHyhi6ww7OWJzD4A=; b=aW8dvrswgODk7zw1w3Lj7hiF1xM4v07LUP6otAtHYRrUqVsE3hvj8QCGwRuaNLjK66 QSQV0jvBjTGMpvhCzBFwPA4L1sovO94w6Ssq4NCyigRrAnIG8VW377p6Udw6cpnF8sir jj2qEHUkRbxS84YTLgP6FYbrAs7PgTwAhfEURVh+g/r6epGySxph30SXTFitdJViV9kA jmvM1QLefnqB/XNgKtbKGj9h3ZfZ5sqHBYy8R3wqHBTJYXPgJgpx3Lz/2+Rqy7KfXtRV 9d1opBHr3tYVrQSwr2O5mKh5R4rtLVfbw1ZDpxmotN0ftUUMYASgsrNuGqMPDTlkoPIm mj2w== MIME-Version: 1.0 X-Received: by 10.112.154.129 with SMTP id vo1mr2120027lbb.31.1385748105770; Fri, 29 Nov 2013 10:01:45 -0800 (PST) Received: by 10.114.28.7 with HTTP; Fri, 29 Nov 2013 10:01:45 -0800 (PST) In-Reply-To: <5298B8BB.70307@bbs.darktech.org> References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> <529850A4.606@googlemail.com> <5298B8BB.70307@bbs.darktech.org> Date: Fri, 29 Nov 2013 20:01:45 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e0115fb0897bb5e04ec549f95 Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 18:01:50 -0000 --089e0115fb0897bb5e04ec549f95 Content-Type: text/plain; charset=ISO-8859-1 I also agree what Ron said. On 29 November 2013 17:54, cowwoc wrote: > > I'm in favor of this approach, with a fallback to voting if that fails, > with a fallback to "No MTI" if that fails. > > Gili > > > On 29/11/2013 3:30 AM, Maik Merten wrote: > >> I very much agree with Ron here. Given that both H.264 and VP8 seem to >> not be universally deployable by all participants in all scenarios I guess >> many will agree that reaching consensus on one of those may not be >> realistic. >> >> So it appears that we need $fallback (to be later used in something like >> "all entities MUST implement $fallback" or "all entities MUST implement at >> least two of {H.264, VP8, $fallback}" etc.). As far as I can see following >> codecs have been mentioned as possible candidates for $fallback: >> >> H.261, MPEG-1 Part 2, H.263, Theora (sorted by age and performance) >> >> I don't remember seeing an exploratory discussion to determine what (if >> any) codecs are considered to have "acceptable risk" (this is different >> from "no risk", which may not be achievable). However, it may take some >> time for each participant to make their own risk assessment. Thus I very >> much like Ron's proposal of starting discussion with the codec with the >> lowest perceived IPR risk and trying to move to higher performance levels >> until substantial indication shows up that the next step brings >> "unacceptable risk". >> >> >> Maik >> >> Am 29.11.2013 07:09, schrieb Ron: >> >>> On Thu, Nov 28, 2013 at 02:39:49PM -0800, Bernard Aboba wrote: >>> >>>> On Nov 28, 2013, at 2:27 PM, Michael Richardson >>>>> wrote: >>>>> That tells me that the participants are not willing to live with >>>>> losing and >>>>> move on, and so no voting process will work either. >>>>> >>>> >>>> [BA] The participants aren't willing to live with losing for business or >>>> legal reasons that aren't within the jurisdiction of an IETF WG. As an >>>> example, would an open source product that requires source code to be >>>> provided without a license fee put that aside because IETF RTCWEB has >>>> agreed >>>> upon H.264 as MTI? Similarly, would a vendor who is concerned about >>>> potential liability from incorporating VP8 put that concern aside >>>> because the >>>> IETF RTCWEB WG has decided to make VP8 MTI? >>>> >>> >>> I think EKR said this more succinctly with: >>> >>> "it's important to understand that in in this case, many people more >>> don't want X than do want Y." >>> >>> And I think you both have clearly identified the problem, and why voting >>> is clearly not a solution to it. >>> >>> >>> The blocking issue is that many people have valid reasons why they >>> _can't_ >>> deploy one or more of the possible choices. You can't possibly solve >>> that >>> by taking a poll of what the majority of people would _prefer_, ignoring >>> all other people's blocking constraints. >>> >>> >>> However I think we can still resolve this by following normal consensus >>> procedures, and walking our way up from the least troublesome options to >>> the most, and seeing at what point consensus actually breaks down. >>> >>> >>> 1. Do we want an MTI codec? >>> >>> It's generally accepted there is consensus the answer to this is Yes. >>> We also have a list of codecs that we could possibly choose from. >>> It also seems generally accepted that IPR trouble is the least >>> negotiable problem that is at the heart of many objections. >>> >>> So let's start where that problem is the smallest, at the very bottom: >>> >>> >>> 2. Can anybody show a sustainable objection for why we _can't_ use >>> H.261. >>> >>> If they can, we're probably doomed. If they can't we have an initial >>> choice for MTI. >>> >>> >>> 3. Can anybody show a sustainable objection for why >>> can't replace H.261 as the MTI codec? >>> >>> If they can, lather rinse repeat through the other alternatives. >>> If they can't, we have a new baseline to ask this question of >>> for the remaining alternatives. >>> >>> >>> Yes, this may take some time (but surely less than we've already spent), >>> but it clearly separates the question of what people _can't_ do, from >>> what they would prefer to do if they had their druthers. >>> >>> We probably won't get the best possible codec as the MTI fallback, >>> but we probably will get a decision that isn't fundamentally doomed. >>> And that's fine, because people will still get their preferred codec >>> through runtime negotiation if they use an implementation which does >>> accept the risk of supporting it - and the safe interop fallback if >>> it doesn't. >>> >>> >>> Why would this one simple procedure not work to resolve the deadlock? >>> >>> Ron >>> >>> >>> _______________________________________________ >>> 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 > --089e0115fb0897bb5e04ec549f95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I also agree what Ron said.


On 29 November 2013 17:54, cowwoc = <cowwoc@bbs.darktech.org> wrote:

I'm in favor of this approach, with a fallback to voting if that fails,= with a fallback to "No MTI" if that fails.

Gili


On 29/11/2013 3:30 AM, Maik Merten wrote:
I very much agree with Ron here. Given that both H.264 and VP8 seem to not = be universally deployable by all participants in all scenarios I guess many= will agree that reaching consensus on one of those may not be realistic.
So it appears that we need $fallback (to be later used in something like &q= uot;all entities MUST implement $fallback" or "all entities MUST = implement at least two of {H.264, VP8, $fallback}" etc.). As far as I = can see following codecs have been mentioned as possible candidates for $fa= llback:

H.261, MPEG-1 Part 2, H.263, Theora (sorted by age and performance)

I don't remember seeing an exploratory discussion to determine what (if= any) codecs are considered to have "acceptable risk" (this is di= fferent from "no risk", which may not be achievable). However, it= may take some time for each participant to make their own risk assessment.= Thus I very much like Ron's proposal of starting discussion with the c= odec with the lowest perceived IPR risk and trying to move to higher perfor= mance levels until substantial indication shows up that the next step bring= s "unacceptable risk".


Maik

Am 29.11.2013 07:09, schrieb Ron:
On Thu, Nov 28, 2013 at 02:39:49PM -0800, Bernard Aboba wrote:
On Nov 28, 2013, at 2:27 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:<= br> That tells me that the participants are not willing to live with losing and=
move on, and so no voting process will work either.

[BA] The participants aren't willing to live with losing for business o= r
legal reasons that aren't within the jurisdiction of an IETF WG. =A0As = an
example, =A0would an open source product that requires source code to be provided without a license fee put that aside because IETF RTCWEB has agree= d
upon H.264 as MTI? =A0Similarly, would a vendor who is concerned about
potential liability from incorporating VP8 put that concern aside because t= he
IETF RTCWEB WG has decided to make VP8 MTI?

I think EKR said this more succinctly with:

=A0 "it's important to understand that in in this case, many peopl= e more
=A0 =A0don't want X than do want Y."

And I think you both have clearly identified the problem, and why voting is clearly not a solution to it.


The blocking issue is that many people have valid reasons why they _can'= ;t_
deploy one or more of the possible choices. =A0You can't possibly solve= that
by taking a poll of what the majority of people would _prefer_, ignoring all other people's blocking constraints.


However I think we can still resolve this by following normal consensus
procedures, and walking our way up from the least troublesome options to the most, and seeing at what point consensus actually breaks down.


=A0 1. Do we want an MTI codec?

=A0 =A0 It's generally accepted there is consensus the answer to this i= s Yes.
=A0 =A0 We also have a list of codecs that we could possibly choose from. =A0 =A0 It also seems generally accepted that IPR trouble is the least
=A0 =A0 negotiable =A0problem that is at the heart of many objections.

=A0 So let's start where that problem is the smallest, at the very bott= om:


=A0 2. Can anybody show a sustainable objection for why we _can't_ use = H.261.

=A0 =A0 If they can, we're probably doomed. =A0If they can't we hav= e an initial
=A0 =A0 choice for MTI.


=A0 3. Can anybody show a sustainable objection for why <alternative>=
=A0 =A0 =A0can't replace H.261 as the MTI codec?

=A0 =A0 If they can, lather rinse repeat through the other alternatives. =A0 =A0 If they can't, we have a new baseline to ask this question of =A0 =A0 for the remaining alternatives.


Yes, this may take some time (but surely less than we've already spent)= ,
but it clearly separates the question of what people _can't_ do, from what they would prefer to do if they had their druthers.

We probably won't get the best possible codec as the MTI fallback,
but we probably will get a decision that isn't fundamentally doomed. And that's fine, because people will still get their preferred codec through runtime negotiation if they use an implementation which does
accept the risk of supporting it - and the safe interop fallback if
it doesn't.


Why would this one simple procedure not work to resolve the deadlock?

=A0 =A0Ron


_______________________________________________
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

--089e0115fb0897bb5e04ec549f95-- From basilgohar@librevideo.org Fri Nov 29 12:41:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261B31ADDAC for ; Fri, 29 Nov 2013 12:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRVKL9TsDzrW for ; Fri, 29 Nov 2013 12:41:38 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id E3CA31ADBCA for ; Fri, 29 Nov 2013 12:41:37 -0800 (PST) Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id D7B4265A278 for ; Fri, 29 Nov 2013 15:41:35 -0500 (EST) Message-ID: <5298FBF4.6060909@librevideo.org> Date: Fri, 29 Nov 2013 15:41:24 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <20131129060936.GV3245@audi.shelbyville.oz> In-Reply-To: <20131129060936.GV3245@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Alternative decision process in RTCWeb X-BeenThere: rtcweb@ietf.org 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: Fri, 29 Nov 2013 20:41:40 -0000 On 11/29/2013 01:09 AM, Ron wrote: > On Thu, Nov 28, 2013 at 02:39:49PM -0800, Bernard Aboba wrote: >>> On Nov 28, 2013, at 2:27 PM, Michael Richardson wrote: >>> That tells me that the participants are not willing to live with losing and >>> move on, and so no voting process will work either. >> >> [BA] The participants aren't willing to live with losing for business or >> legal reasons that aren't within the jurisdiction of an IETF WG. As an >> example, would an open source product that requires source code to be >> provided without a license fee put that aside because IETF RTCWEB has agreed >> upon H.264 as MTI? Similarly, would a vendor who is concerned about >> potential liability from incorporating VP8 put that concern aside because the >> IETF RTCWEB WG has decided to make VP8 MTI? > > I think EKR said this more succinctly with: > > "it's important to understand that in in this case, many people more > don't want X than do want Y." > > And I think you both have clearly identified the problem, and why voting > is clearly not a solution to it. > > > The blocking issue is that many people have valid reasons why they _can't_ > deploy one or more of the possible choices. You can't possibly solve that > by taking a poll of what the majority of people would _prefer_, ignoring > all other people's blocking constraints. > > > However I think we can still resolve this by following normal consensus > procedures, and walking our way up from the least troublesome options to > the most, and seeing at what point consensus actually breaks down. > > > 1. Do we want an MTI codec? > > It's generally accepted there is consensus the answer to this is Yes. > We also have a list of codecs that we could possibly choose from. > It also seems generally accepted that IPR trouble is the least > negotiable problem that is at the heart of many objections. > > So let's start where that problem is the smallest, at the very bottom: > > > 2. Can anybody show a sustainable objection for why we _can't_ use H.261. > > If they can, we're probably doomed. If they can't we have an initial > choice for MTI. > > > 3. Can anybody show a sustainable objection for why > can't replace H.261 as the MTI codec? > > If they can, lather rinse repeat through the other alternatives. > If they can't, we have a new baseline to ask this question of > for the remaining alternatives. > > > Yes, this may take some time (but surely less than we've already spent), > but it clearly separates the question of what people _can't_ do, from > what they would prefer to do if they had their druthers. > > We probably won't get the best possible codec as the MTI fallback, > but we probably will get a decision that isn't fundamentally doomed. > And that's fine, because people will still get their preferred codec > through runtime negotiation if they use an implementation which does > accept the risk of supporting it - and the safe interop fallback if > it doesn't. > > > Why would this one simple procedure not work to resolve the deadlock? > > Ron This is as good or better than anything else I've seen mentioned so far. Definitely a +1 from me, not that we're voting or anything...;) -- Libre Video http://librevideo.org From giles@thaumas.net Fri Nov 29 16:49:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801581ADFD7 for ; Fri, 29 Nov 2013 16:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIwYFe5EGTU5 for ; Fri, 29 Nov 2013 16:49:03 -0800 (PST) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4D17D1AE11E for ; Fri, 29 Nov 2013 16:49:02 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so14499657pde.20 for ; Fri, 29 Nov 2013 16:49:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=XTw74/BCgqiD14rri2lrRKkdTCYCj6cjVkZ+PziKYTw=; b=X1MeKXV0+OjQ12XsxNN5N+ZP5e/VogBboM/vhtXkflqjK/E7sl25MYfx2xLoV70RuI nNU3LXxgDUGPGEABWtZE1AFEdCwUGUscNDw5biT4y7fGx1gNzfd/o9umzzy4I51m3wlD 1o1Q5EijefULKZ8Oz24EwzbnT+I+FT3/E8/ZBsUOQQljw+isOCUCz40cSpuC4fYPAsxz +EOOuEiHmYNCWZdb83XSCSYpAByB2FZBceLefQBt6Eo0IK8QGPN0khelccYTxg1f0jdg IIu2eBDKDaXyadmKqnUU74Y/9czx54TErrXWWWZaSDrUd8AFOkoKj0hZeKlwbJCUtoSg dNiA== X-Gm-Message-State: ALoCoQmoDpR1KQ2thWzsVlUqxmqtSRk5OKf33sHbXjCcKdGruqx8MUdYkvmW5y//4kBk7DNyFUXD X-Received: by 10.66.178.143 with SMTP id cy15mr55618617pac.105.1385772540780; Fri, 29 Nov 2013 16:49:00 -0800 (PST) Received: from tamias.local (static-68-179-67-77.ptr.terago.net. [68.179.67.77]) by mx.google.com with ESMTPSA id gv10sm13081273pbd.0.2013.11.29.16.48.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 16:48:59 -0800 (PST) Message-ID: <529935FD.7090409@thaumas.net> Date: Fri, 29 Nov 2013 16:49:01 -0800 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rtcweb] MTI motion JPEG X-BeenThere: rtcweb@ietf.org 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: Sat, 30 Nov 2013 00:49:04 -0000 I'd like propose motion JPEG as the manditory-to-implement video codec, per RFC 2435 or similar. Yes, I'm serious. I didn't propose this earlier to avoid splitting the vote at the last meeting. Our goal here is to to avoid negotiation failure. We don't have concensus for either h.264 or VP8, but no one is happy with the performance of the older formats we've been discussing. Since we can't have acceptable performance in our fallback we should instead optimize for minimum complexity. We all have to ship this and hope it's never used in practice. While not as trivial as G.711 audio, mjpeg+rtp is simpler to implement than the more recent obsolete codecs we've been discussing. JPEG decode is already universally supported for still images. As the simplest compressed format it has advantages for testing and legacy interoperation, just like G.711. It works fine over a LAN and for the WAN...well, you can have a couple of blurry frames a minute if you like that better than nothing at all. -r From cowwoc@bbs.darktech.org Fri Nov 29 17:08:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926541AE232 for ; Fri, 29 Nov 2013 17:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04fb-0yBO-3k for ; Fri, 29 Nov 2013 17:08:10 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id D31111ADFF2 for ; Fri, 29 Nov 2013 17:08:09 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so17246702iec.27 for ; Fri, 29 Nov 2013 17:08:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V4hxTv3/5slimypx52ZtqngaIJoRnWRroGpQ1ExtYPI=; b=bNC/OntwIamdQlGzAq3JVzly0a//+p5auibxP/Nz3daCfFJGyU1TINUduVVd4UPLc6 UiDKOAPI/kQWA5ygjBv075MQUeVJ9wHbwBSs7MN5RaS4/SlEHrFtQKiVjzR4/gS23+TN 3rk2joJzP1QO9ZHNj7EluwC4zDkKtJo1ZFwEnUJur43C1n8GiWJJostfUimJOdRQ2ZFG gup3uLPfynH2JAyuIXhdhNvhnBHf+jGxkYa03HeXHdovo9B/OMDmFwWwFXJpZo2NqDk5 WwHJJk+2YLkvQ9KyKmZwNjoPs28bj87mzwvg7hNfp31azt5p5T9stUpC93hvHCFjs87V TO3w== X-Gm-Message-State: ALoCoQlmKQQfbD1l6gn4Mho1nhX2TspEg5vWzHt9vkASyczo7UKRDTXr6kSuB6klTx/4jQbMADMy X-Received: by 10.50.221.99 with SMTP id qd3mr8311353igc.49.1385773687893; Fri, 29 Nov 2013 17:08:07 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id w4sm53106338igb.5.2013.11.29.17.08.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 17:08:07 -0800 (PST) Message-ID: <52993A48.4070600@bbs.darktech.org> Date: Fri, 29 Nov 2013 20:07:20 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529935FD.7090409@thaumas.net> In-Reply-To: <529935FD.7090409@thaumas.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] MTI motion JPEG X-BeenThere: rtcweb@ietf.org 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: Sat, 30 Nov 2013 01:08:11 -0000 This reminds me of a joke from Google's keynote in the WebRTC World conference, where they demoed http://idevelop.ro/ascii-camera/ Didn't we say there were multiple mature implementations of H.261 in the wild? As such, what does it matter how complex the implementation is? Gili On 29/11/2013 7:49 PM, Ralph Giles wrote: > I'd like propose motion JPEG as the manditory-to-implement video codec, > per RFC 2435 or similar. > > Yes, I'm serious. I didn't propose this earlier to avoid splitting the > vote at the last meeting. > > Our goal here is to to avoid negotiation failure. We don't have > concensus for either h.264 or VP8, but no one is happy with the > performance of the older formats we've been discussing. > > Since we can't have acceptable performance in our fallback we should > instead optimize for minimum complexity. We all have to ship this and > hope it's never used in practice. > > While not as trivial as G.711 audio, mjpeg+rtp is simpler to implement > than the more recent obsolete codecs we've been discussing. JPEG decode > is already universally supported for still images. As the simplest > compressed format it has advantages for testing and legacy > interoperation, just like G.711. It works fine over a LAN and for the > WAN...well, you can have a couple of blurry frames a minute if you like > that better than nothing at all. > > -r > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From maikmerten@googlemail.com Sat Nov 30 12:46:35 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7D1AE28F for ; Sat, 30 Nov 2013 12:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anv8jjn7cayv for ; Sat, 30 Nov 2013 12:46:34 -0800 (PST) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C15781AE1B4 for ; Sat, 30 Nov 2013 12:46:33 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id z10so7776997ead.34 for ; Sat, 30 Nov 2013 12:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=a5q/GoQh9iDKRohSY6zF2mz+uUgzb724ZsPqb90kXYg=; b=W2dtGh4XKu3C4wV4+VUYaEGWeXNEPztUonk3Ygoylj6ylwtHBP/TrgXiZp6LYA6mfF 9dEj6AJdpR1YVKEBmVUztbVWu4xRDBaRT5CldBZHNKL/v4bzxWa7N4q4L7UemJRtQq/j 0yZmtdN/DeSzP1RQZH78qWwACymzW33ZBdtaWn6qU2QYHYOVsL2bNzJawiiT+UNj8cXq uA8StG3ZfHAkklRKcE5ccB3boyAKL4NKAa1uWgpcIu2IY76ind/JKpn+L6R6jJewzViK RC7tqVTHsv/vBHTRN94CPlOflwWHQxzGZ/hzNoGwphBxKvHl/0joe+b9cuK6cA7RPlE+ tZew== X-Received: by 10.15.76.6 with SMTP id m6mr3206329eey.37.1385844391691; Sat, 30 Nov 2013 12:46:31 -0800 (PST) Received: from [192.168.2.109] (port-92-201-122-127.dynamic.qsc.de. [92.201.122.127]) by mx.google.com with ESMTPSA id v7sm37136738eel.2.2013.11.30.12.46.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Nov 2013 12:46:30 -0800 (PST) Message-ID: <529A4EA3.9010003@googlemail.com> Date: Sat, 30 Nov 2013 21:46:27 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529935FD.7090409@thaumas.net> In-Reply-To: <529935FD.7090409@thaumas.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] MTI motion JPEG X-BeenThere: rtcweb@ietf.org 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: Sat, 30 Nov 2013 20:46:36 -0000 Actually that may work. Toying around with mjpeg I found that, for instance, CIF video can be transmitted with somewhat usable quality at full framerate at slightly over one mbit/s. Usable quality at around half a mbit/s can be achieved by decreasing the framerate. Perceived picture quality can be increased by postprocessing (deblocking, deringing) or the decoding technique described in "William B. Pennebaker, Joan L. Mitchell - JPEG: Still Image Data Compression Standard, 1993". I would also assume that support for the arithmetic encoder could be mandated by now, increasing coding efficiency. So this makes for a lousy video codec, but at least it's fast, "everywhere", presumably free of additional IPR risk, and flexible regarding frame size. I can also be used to occasionally push high-quality pictures (think slide shows), a use case H.261 included a hack for (4CIF) but would be better handled by MJPEG anyways. Maik Am 30.11.2013 01:49, schrieb Ralph Giles: > I'd like propose motion JPEG as the manditory-to-implement video codec, > per RFC 2435 or similar. > > Yes, I'm serious. I didn't propose this earlier to avoid splitting the > vote at the last meeting. > > Our goal here is to to avoid negotiation failure. We don't have > concensus for either h.264 or VP8, but no one is happy with the > performance of the older formats we've been discussing. > > Since we can't have acceptable performance in our fallback we should > instead optimize for minimum complexity. We all have to ship this and > hope it's never used in practice. > > While not as trivial as G.711 audio, mjpeg+rtp is simpler to implement > than the more recent obsolete codecs we've been discussing. JPEG decode > is already universally supported for still images. As the simplest > compressed format it has advantages for testing and legacy > interoperation, just like G.711. It works fine over a LAN and for the > WAN...well, you can have a couple of blurry frames a minute if you like > that better than nothing at all. > > -r > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From maikmerten@googlemail.com Sat Nov 30 12:49:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D3C1AE291 for ; Sat, 30 Nov 2013 12:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3toHKKIAdhL for ; Sat, 30 Nov 2013 12:48:59 -0800 (PST) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 82C651AE1B4 for ; Sat, 30 Nov 2013 12:48:59 -0800 (PST) Received: by mail-ea0-f170.google.com with SMTP id k10so7797372eaj.29 for ; Sat, 30 Nov 2013 12:48:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XSVu9LWq8NiGZ6NPrCrpdVhT5URbbX5f6fsNimdJxTc=; b=iOX/7s8iRkLhe4xHeAA/NBA7iVn9vZs1pUGxYZgNQY+hxQc/pbCmWXSKgLO96L/JFF KTpdxUjuTnkp+NkR5POUPFdG87LN6dHnlbIK6COkFbZhScb5snjf8TNVZVO6uPAyU5o5 kqVui9zMIMcr+ctD9PpnelI/BqONL1QJUdWaDm17pUHA/N9mM8oXgHwCfJ52MesxYUiS eCtDMxkcW5kyrM9al2c0UxUsuWe9OBnDeqDK8qJEhheTo2kX41QN1AyyizUpJ64qm0kA y3h9hS6duFwtjzQB/JulzK16GAieHOKbKvESbF0jigcyoZTpD6H9rvwoB+nqnH7LRKSs hXMw== X-Received: by 10.15.82.136 with SMTP id a8mr690738eez.81.1385844537440; Sat, 30 Nov 2013 12:48:57 -0800 (PST) Received: from [192.168.2.109] (port-92-201-122-127.dynamic.qsc.de. [92.201.122.127]) by mx.google.com with ESMTPSA id g7sm5611686eet.12.2013.11.30.12.48.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Nov 2013 12:48:56 -0800 (PST) Message-ID: <529A4F35.4030203@googlemail.com> Date: Sat, 30 Nov 2013 21:48:53 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529935FD.7090409@thaumas.net> <529A4EA3.9010003@googlemail.com> In-Reply-To: <529A4EA3.9010003@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] MTI motion JPEG X-BeenThere: rtcweb@ietf.org 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: Sat, 30 Nov 2013 20:49:01 -0000 Am 30.11.2013 21:46, schrieb Maik Merten: > I can also be used to occasionally push > high-quality pictures (think slide shows) *It* (MJPEG) can be used to occasionally push high-quality pictures. I transmit only low-quality pictures. Maik From lgeyser@gmail.com Sat Nov 30 12:50:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82C31AE291 for ; Sat, 30 Nov 2013 12:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKPOIxxz0eLx for ; Sat, 30 Nov 2013 12:50:26 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 53C251AE1B4 for ; Sat, 30 Nov 2013 12:50:26 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id n7so7484792lam.16 for ; Sat, 30 Nov 2013 12:50:24 -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=S8uqH8vYE2OmjWeei4vaz9IMtcqmzZEc4bDD/LQ+tzk=; b=in78T04bhFXf+4hDaVYFss/ilL+fOIbsNbbCPP7iSEfZixtbe2wCUVmn1SUFqMs+M/ +FzL2fxLm/z3FTAXjpmI7DyJrw5UCyFdspQnhl9lhFGSEd/lJoEIdmJWPKkHASc1IXv+ oe56QY72x+PzbI+nakSWATDHJRvTOQkBS57P5aBPrhKVSzLTHpfSZRAtxCWDjKQ+0A6m PWI2olSPafOFDfU9AYz+zaLRFFuGt1KJu86CYkKU/blFhdrEUqAuu14f95+nRcDL6+YV NGSEKrJVw/3md7ce4QVK+f7Qo9bwzDhNgn9ia21Wex1PlvwU81eu2OZ0gW7WPA4icvS4 yY2g== MIME-Version: 1.0 X-Received: by 10.152.22.4 with SMTP id z4mr40066509lae.14.1385844623926; Sat, 30 Nov 2013 12:50:23 -0800 (PST) Received: by 10.114.28.7 with HTTP; Sat, 30 Nov 2013 12:50:23 -0800 (PST) In-Reply-To: <529A4EA3.9010003@googlemail.com> References: <529935FD.7090409@thaumas.net> <529A4EA3.9010003@googlemail.com> Date: Sat, 30 Nov 2013 22:50:23 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e0158b8e285ea7b04ec6b1898 Subject: Re: [rtcweb] MTI motion JPEG X-BeenThere: rtcweb@ietf.org 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: Sat, 30 Nov 2013 20:50:29 -0000 --089e0158b8e285ea7b04ec6b1898 Content-Type: text/plain; charset=ISO-8859-1 I don't mind MJPEG at high bitrates like 1Mbit/s, but at 256Kbps I struggled to get something acceptable out of ffmpeg's MJPEG encoder. I have a 256Kbps connection btw :) On 30 November 2013 22:46, Maik Merten wrote: > Actually that may work. Toying around with mjpeg I found that, for > instance, CIF video can be transmitted with somewhat usable quality at full > framerate at slightly over one mbit/s. Usable quality at around half a > mbit/s can be achieved by decreasing the framerate. Perceived picture > quality can be increased by postprocessing (deblocking, deringing) or the > decoding technique described in "William B. Pennebaker, Joan L. Mitchell - > JPEG: Still Image Data Compression Standard, 1993". I would also assume > that support for the arithmetic encoder could be mandated by now, > increasing coding efficiency. > > So this makes for a lousy video codec, but at least it's fast, > "everywhere", presumably free of additional IPR risk, and flexible > regarding frame size. I can also be used to occasionally push high-quality > pictures (think slide shows), a use case H.261 included a hack for (4CIF) > but would be better handled by MJPEG anyways. > > > Maik > > > Am 30.11.2013 01:49, schrieb Ralph Giles: > > I'd like propose motion JPEG as the manditory-to-implement video codec, >> per RFC 2435 or similar. >> >> Yes, I'm serious. I didn't propose this earlier to avoid splitting the >> vote at the last meeting. >> >> Our goal here is to to avoid negotiation failure. We don't have >> concensus for either h.264 or VP8, but no one is happy with the >> performance of the older formats we've been discussing. >> >> Since we can't have acceptable performance in our fallback we should >> instead optimize for minimum complexity. We all have to ship this and >> hope it's never used in practice. >> >> While not as trivial as G.711 audio, mjpeg+rtp is simpler to implement >> than the more recent obsolete codecs we've been discussing. JPEG decode >> is already universally supported for still images. As the simplest >> compressed format it has advantages for testing and legacy >> interoperation, just like G.711. It works fine over a LAN and for the >> WAN...well, you can have a couple of blurry frames a minute if you like >> that better than nothing at all. >> >> -r >> _______________________________________________ >> 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 > --089e0158b8e285ea7b04ec6b1898 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't mind MJPEG at high bitrates like 1Mbit/s,= but at 256Kbps I struggled to get something acceptable out of ffmpeg's= MJPEG encoder. I have a 256Kbps connection btw :)


On 30 November 2013 22:46, Maik Merten <= span dir=3D"ltr"><maikmerten@googlemail.com> wrote:
Actually that may work. Toying around with mjpeg I found that, for instance= , CIF video can be transmitted with somewhat usable quality at full framera= te at slightly over one mbit/s. Usable quality at around half a mbit/s can = be achieved by decreasing the framerate. Perceived picture quality can be i= ncreased by postprocessing (deblocking, deringing) or the decoding techniqu= e described in "William B. Pennebaker, Joan L. Mitchell - JPEG: Still = Image Data Compression Standard, 1993". I would also assume that suppo= rt for the arithmetic encoder could be mandated by now, increasing coding e= fficiency.

So this makes for a lousy video codec, but at least it's fast, "ev= erywhere", presumably free of additional IPR risk, and flexible regard= ing frame size. I can also be used to occasionally push high-quality pictur= es (think slide shows), a use case H.261 included a hack for (4CIF) but wou= ld be better handled by MJPEG anyways.


Maik


Am 30.11.2013 01:49, schrieb Ralph Giles:

I'd like propose motion JPEG as the manditory-to-implement video codec,=
per RFC 2435 or similar.

Yes, I'm serious. I didn't propose this earlier to avoid splitting = the
vote at the last meeting.

Our goal here is to to avoid negotiation failure. We don't have
concensus for either h.264 or VP8, but no one is happy with the
performance of the older formats we've been discussing.

Since we can't have acceptable performance in our fallback we should instead optimize for minimum complexity. We all have to ship this and
hope it's never used in practice.

While not as trivial as G.711 audio, mjpeg+rtp is simpler to implement
than the more recent obsolete codecs we've been discussing. JPEG decode=
is already universally supported for still images. As the simplest
compressed format it has advantages for testing and legacy
interoperation, just like G.711. It works fine over a LAN and for the
WAN...well, you can have a couple of blurry frames a minute if you like
that better than nothing at all.

=A0 -r
_______________________________________________
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

--089e0158b8e285ea7b04ec6b1898-- From basilgohar@librevideo.org Sat Nov 30 13:57:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EB31AE492 for ; Sat, 30 Nov 2013 13:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9aP2Tad9zfh for ; Sat, 30 Nov 2013 13:57:53 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 496151AE48B for ; Sat, 30 Nov 2013 13:57:53 -0800 (PST) Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 05A5865AAA0 for ; Sat, 30 Nov 2013 16:57:50 -0500 (EST) Message-ID: <529A5F5C.5060706@librevideo.org> Date: Sat, 30 Nov 2013 16:57:48 -0500 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529935FD.7090409@thaumas.net> <529A4EA3.9010003@googlemail.com> In-Reply-To: <529A4EA3.9010003@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] MTI motion JPEG X-BeenThere: rtcweb@ietf.org 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: Sat, 30 Nov 2013 21:57:55 -0000 On 11/30/2013 03:46 PM, Maik Merten wrote: > Actually that may work. Toying around with mjpeg I found that, for > instance, CIF video can be transmitted with somewhat usable quality at > full framerate at slightly over one mbit/s. Usable quality at around > half a mbit/s can be achieved by decreasing the framerate. Perceived > picture quality can be increased by postprocessing (deblocking, > deringing) or the decoding technique described in "William B. > Pennebaker, Joan L. Mitchell - JPEG: Still Image Data Compression > Standard, 1993". I would also assume that support for the arithmetic > encoder could be mandated by now, increasing coding efficiency. > > So this makes for a lousy video codec, but at least it's fast, > "everywhere", presumably free of additional IPR risk, and flexible > regarding frame size. I can also be used to occasionally push > high-quality pictures (think slide shows), a use case H.261 included a > hack for (4CIF) but would be better handled by MJPEG anyways. > > > Maik > Maik, Can you share your technique for making your test clip(s)? I am trying but ffmpeg (the only tool I know how to do this with) keeps overshooting severely the bitrate I set for it. -- Libre Video http://librevideo.org From maikmerten@googlemail.com Sat Nov 30 14:31:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C2D1AE478 for ; Sat, 30 Nov 2013 14:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOY4ppWg5ZvM for ; Sat, 30 Nov 2013 14:31:36 -0800 (PST) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 376271AE496 for ; Sat, 30 Nov 2013 14:31:36 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id z10so7815252ead.34 for ; Sat, 30 Nov 2013 14:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=PoTr6eiZcsSuX9duWfoysFuRyF9yykDYTgJ8d1uWdWc=; b=MBlSZ5iyaip99BvdWQ8xcPVnt4LgeB6/UktnaAvFpfKzx4iixQqsJF9XKVSQAiGY/P kRcStCIakhlUERFTh0QzDJIwPAVw4+XwkgGu1LA6JrhoRAHf+3MqbqfHHDJZqccxRPUF qouGGpN4PZ2iniXw7APz6IQ00h+2mLX4XR1MJnv4sS6ZXTAfuyat+q0lBteMH81S9RSk KDenIjtOp+GvJ5iX0x5Qz0mjeEMFoaP0MhWk436H2ZI8kOET7XR8rCTkijh9P8kI2sd6 tzBb76YI5omVFkYzslUMG+vNjtPTvLqtHaiCN6ptAL05bN1WB6FKSq2EjNRQr1BYJ7hX CQjg== X-Received: by 10.14.179.130 with SMTP id h2mr26380999eem.34.1385850694113; Sat, 30 Nov 2013 14:31:34 -0800 (PST) Received: from [192.168.2.109] (port-92-201-122-127.dynamic.qsc.de. [92.201.122.127]) by mx.google.com with ESMTPSA id o47sm55087112eem.21.2013.11.30.14.31.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Nov 2013 14:31:33 -0800 (PST) Message-ID: <529A6742.3010002@googlemail.com> Date: Sat, 30 Nov 2013 23:31:30 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529935FD.7090409@thaumas.net> <529A4EA3.9010003@googlemail.com> <529A5F5C.5060706@librevideo.org> In-Reply-To: <529A5F5C.5060706@librevideo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] MTI motion JPEG X-BeenThere: rtcweb@ietf.org 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: Sat, 30 Nov 2013 22:31:37 -0000 Am 30.11.2013 22:57, schrieb Basil Mohamed Gohar: > Can you share your technique for making your test clip(s)? I am trying > but ffmpeg (the only tool I know how to do this with) keeps overshooting > severely the bitrate I set for it. Basically I'm either forcing a fixed quantizer with -qmin and -qmax or asking for really low bitrates via -vb. Yes, bitrate control in ffmpeg seems to be somewhat unreliable in ffmpeg. Maik From maikmerten@googlemail.com Sat Nov 30 15:46:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D2A1AE4AD for ; Sat, 30 Nov 2013 15:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjoiLPPOOcB2 for ; Sat, 30 Nov 2013 15:46:47 -0800 (PST) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id ED5B81AE4B0 for ; Sat, 30 Nov 2013 15:46:46 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id m10so7828412eaj.40 for ; Sat, 30 Nov 2013 15:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TjSPFJ7bd8k/t6eKlnri5pKd3fjQgLKt1361J0ZKy/0=; b=Tl8IfunfGAyGXoYfOS5Ty5uGFiov1HPRzyk/8faQE5v6CO1obxgfXbPpahlKgckgFC PVlLhI5EyayLKclWpv8LbqcWYOVtNzVyR+eGngX1ETxQWQKZ09qpjeVxlpBmlVtCErOo 0FdQbEgsP2XPrvhHTEJKoF7yyGU/oMSQKnZy96DtZPe4xTyvBRckqgalj/hiuiuGJyoJ c9wMwxnjXfnrolWjXqPM0rmyoKckaZdoUjbfXVsxScSg6AGR4sITRwKec2hG6SwJBO+H tv9bU1Kem+JGP1S1cJtMV/WXuWwPbacLwj9V5j5wc2ahpb0q7gq30KNnTWmlAu/FnswI IcKA== X-Received: by 10.14.184.66 with SMTP id r42mr1008315eem.86.1385855204669; Sat, 30 Nov 2013 15:46:44 -0800 (PST) Received: from [192.168.2.109] (port-92-201-122-127.dynamic.qsc.de. [92.201.122.127]) by mx.google.com with ESMTPSA id g7sm6797695eet.12.2013.11.30.15.46.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Nov 2013 15:46:43 -0800 (PST) Message-ID: <529A78E0.4020106@googlemail.com> Date: Sun, 01 Dec 2013 00:46:40 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <529935FD.7090409@thaumas.net> In-Reply-To: <529935FD.7090409@thaumas.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] MTI motion JPEG X-BeenThere: rtcweb@ietf.org 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: Sat, 30 Nov 2013 23:46:48 -0000 Am 30.11.2013 01:49, schrieb Ralph Giles: > I'd like propose motion JPEG as the manditory-to-implement video codec, > per RFC 2435 or similar. Is it feasible to extend the RFC with, e.g., a run-length coded list of skipped MCUs ("macroblocks")? Picture data for those would be copied over from the last frame. This may even work with unmodified JPEG decoders (either by filling in stub data for the skipped MCUs at the receiving end or by encoding skipped MCUs compact run of zeroed coefficents) and a postprocessing step. (If coding an explicit list of skipped MCUs is not practical, one can regard MCUs with all-zero coefficients as "skipped". An encoder will have to take this into account so no MCUs are skipped by accident, though.) This contradicts the minimal-effort argument to some degree, but at least this would enable efficient transmission of screencasts, increase coding efficiency for "talking head" content, and offer additional means for bitrate management (partial screen updates). Maik
Actually I was very happy that ISO had cleaned up the data= base to the point where they made the actual statements publicly available = - I see this as a major step forward. Whether they manage to apply that tra= nsparency retroactively remains to be seen.

That's how I found that the Microsoft statement doesn= 9;t say that it will go to type-1 if all others do the same; it says that i= t will "reconsider the matter". I assume this is just lawyers bei= ng cagy, and that they have given assurance that they really mean "wil= l switch to type 1", but their public statement doesn't say so.

Looking forward to seeing the result of the next phase = of the work.




On Fri, Nov 8, 2013 at 2:07 AM, Da= vid Singer <singer@apple.com> wrote:

On Nov 8, 2013, at 10:01 , Harald Alvestrand <hta@google.com> wrote:

> Changing the subject, since this is a different topic to where we star= ted the thread.
> It is also perhaps somewhat irrelevant to the rtcweb mailing list.
>
> The public statement is the public statement of Motorola Mobility, jus= t like the Microsoft public statement (also type 2) is the public statement= of Microsoft.
>
> If you want more information than what's given in the statement, y= ou have to ask the persons who made the statement.
> Which is not me - that's really all I was saying.
>
> (One of the things I've been surprised about in the discussions of= WebVC is that the proponents have not seemed to have any plan to resolve t= he issue of the Type 2 filings they have received. I'm not sure what su= ch a plan would consist of - but my inability to see how we could resolve t= his issue is a major reason why I don't have a strong belief that this = project can actually achieve its stated goals.)

The plan of record, as of the previous meeting, was to consider filin= gs made by the close of the DIS ballot, which was just a week or two ago. = =C2=A0Then we try to get the pipeline to deliver us all the statements and = their details (don't ask why that is hard, it beats me), and then we co= nsider where we are.

Plumbers are at work trying to get the data out of the pipeline, into the d= atabase, and so on.

Whether the non-type-1 statements can be resolved, how many there are, and = so on, is obviously a question to be answered. =C2=A0That was part of the p= lan at inception and has not been discussed since, so you may not have been= around for the discussion.

(The Microsoft statement is very similar to a couple of others, which are f= ormally type-2 but would go to type-1 -- RF -- if all others do the same).<= br>

>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Harald
>
>
> On Fri, Nov 8, 2013 at 1:18 AM, David Singer <singer@apple.com> wrote:
>
> On Nov 8, 2013, at 6:27 , Harald Alvestrand <hta@google.com> wrote:
>
> > Krasimir, if you want to discuss licenses with the Motorola Mobil= ity lawyers, the contact details are in the filing.
>
> Is there anything ambiguous or unclear that would warrant discussion? = =C2=A0The statement seems fairly straightforward. =C2=A0And generally, in t= he standards bodies we work on what is formally said, not what we might lea= rn in hypothetical side-conversations.
>
> > My impression when I asked them to file something was that the st= atus of that project didn't even enter into consideration when they dec= ided how to respond - but I'm not going to speak for them. If you want = to know, call them.
>
> It's not Krasimir who wants to know, it's all of us. =C2=A0The= public statement is presumed to be your public statement.
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>

David Singer
Multimedia and Software Standards, Apple Inc.


--001a1133970635b51204eaa01ed1-- From singer@apple.com Thu Nov 7 17:21:58 2013 Return-Path: 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 A647511E81B9 for ; Thu, 7 Nov 2013 17:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 9vCWzIDxYPfD for ; Thu, 7 Nov 2013 17:21:51 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1C111E8170 for ; Thu, 7 Nov 2013 17:21:49 -0800 (PST) Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 64.CC.21841.CAC3C725; Fri, 8 Nov 2013 09:21:48 +0800 (MYT) X-AuditID: 1152fe11-b7f256d000005551-16-527c3caccd6f Received: from sng-mmpp-sz01.asia.apple.com ( [17.82.200.58]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id E8.46.14371.CAC3C725; Fri, 8 Nov 2013 09:21:48 +0800 (MYT) Received: from [17.83.34.135] (unknown [17.83.34.135]) by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MVX009QO7SBIM10@sng-mmpp-sz01.asia.apple.com> for rtcweb@ietf.org; Fri, 08 Nov 2013 09:21:48 +0800 (SGT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: David Singer In-reply-to: Date: Fri, 08 Nov 2013 10:21:48 +0900 Content-transfer-encoding: quoted-printable Message-id: <818B7C78-ED93-454B-9B12-5E7DE94F6FEF@apple.com> References: <3B441C46-2738-495B-93FA-FF63EEA4C54B@apple.com> To: Harald Alvestrand X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUiGHRCSHeNTU2QwdG15hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48fv6UwFh1gq3l66z9TAeI65i5GTQ0LARGL7jl9MELaYxIV7 69m6GLk4hAR2M0osWLyNDabowbTX7BCJyUwSaze8gqraxCTRffYFK0gVs4CWxPqdx8FG8Qro Sezcuw0sLixQIfH7wncWEJtNQFXiwZxjjCA2p0CwxOK/R8BsFqD4uYa7bBBzfCVuPX/LDmFr Szx5d4EVYqaNxNKdG1ghFp9hlLjbvBOsQURATWLtlC5WiFNlJU6fe84CUiQh8JFVYs3pHpYJ jMKzkBw4C8mBs5AsWcDIvIpRPDcxM0c3M89QL7E4M1EvsaAgJ1UvOT93EyM4rP8J7mCcutDw EKMAB6MSD69nUnGQEGtiWXFl7iFGCQ5mJRHeZ4o1QUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 P7tUBwkJpCeWpGanphakFsFkmTg4pRoYD7DtO9oUG9X5pYsjUUPP7NSXKa5R61et3i2iOsPg 2J8dV192Ll85t+Tyfg3ZacuvOG/5f3NX5YFKYR3zMx938Z3yniBl6GchkPtBVX9qUX1MxFzj bXmbWXcq9D4wk53ckyhwMtrYe2NfqfnpORbGF3fYyV/ecDzo8eNFJtGvb2fnabkY33vRo8RS nJFoqMVcVJwIAJszkytnAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUiGHTCSneNTU2Qwbv/JhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48fv6UwFh1gq3l66z9TAeI65i5GTQ0LAROLBtNfsELaYxIV7 69m6GLk4hAQmM0ms3fAKytnEJNF99gUrSBWzgJbE+p3HmUBsXgE9iZ17t4HFhQUqJH5f+M4C YrMJqEo8mHOMEcTmFAiWWPz3CJjNAhQ/13CXDWKOr8St52/ZIWxtiSfvLrBCzLSRWLpzAyvE 4jOMEnebd4I1iAioSayd0sUKcaqsxOlzz1kmMArMQnLTLCQ3zUIydwEj8ypG0aLUnMRKQ73E 4sxEvcSCgpxUveT83E2MkDAU2sH4cb/BIUYBDkYlHt7rD4qChFgTy4orcw8xSnAwK4nwPlOs CRLiTUmsrEotyo8vKs1JLT7EKM3BoiTOa+dRHSQkkJ5YkpqdmlqQWgSTZeLglGpgPPCI5262 ee331intf9iKpRMWuIWqftrHJcX330+28KDha5Yp9wILPvhe+LTwBMfGLi+7/IY7WtcfiOip S7acVDEuNr6ReGGf2G2nrQFPJ4fsF4g/LnGX8f2Jw6anNz9/LN/vKuuw9qYLn2zG0+k7Fs+Y kHXNQ7V5p6rt7rhpLwwEP2zWWL11kRJLcUaioRZzUXEiAIL1L2Y/AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebVC licensing issues (Re: Congratuiations on the Cisco announcement - but we still prefer VP8) X-BeenThere: rtcweb@ietf.org 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 01:21:58 -0000 On Nov 8, 2013, at 10:15 , Harald Alvestrand wrote: > Actually I was very happy that ISO had cleaned up the database to the = point where they made the actual statements publicly available - I see = this as a major step forward. Whether they manage to apply that = transparency retroactively remains to be seen. >=20 Yes, an unintended (but welcome) side-effect of this work has been a = closer look at, and improvements in, this filing process. This should = benefit all projects. David Singer Multimedia and Software Standards, Apple Inc. From gmaxwell@gmail.com Thu Nov 7 18:23:00 2013 Return-Path: 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 4993F21E814B for ; Thu, 7 Nov 2013 18:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 c6yoNCFa0mER for ; Thu, 7 Nov 2013 18:22:59 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 77BEA21E80D2 for ; Thu, 7 Nov 2013 18:22:59 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id n7so150661lam.35 for ; Thu, 07 Nov 2013 18:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=NKiVJWHKlPu0j4Q4WIHDne5xy5P49YS/SZD4NwYRkik=; b=PUJu4bCpbiY+R8oajgMqbFBarqLURM31MHC2w48wiF6lSf+YmY8utUPH0Mv93LZ/rb l9uwPrCQZEWCm6e9kSM/CGbwdOzJOWXUIGMPzM7gDRtJcXimj+SqdeMExp/dyaFrkSge Tjjt2r4nfhBPjpcCfZJ2pF9vFekMHTyVhgi1ETQseEElkx9JfmGznOY7GGmzuxCcKtEj 0fsiF7bBs4ryLB7ytoWQ7rWXaTSqTniMESDfsiOJLSw+mdjptAXxpC6CMAw9c/hAu+bQ uV+ry2yMmi9qiWgcaR++ys3RVqxmFvPns2W+hrYgvH4+bultZxkjcAZ840/JfXS7gQSN CYgA== MIME-Version: 1.0 X-Received: by 10.152.143.6 with SMTP id sa6mr8790851lab.20.1383877378000; Thu, 07 Nov 2013 18:22:58 -0800 (PST) Sender: gmaxwell@gmail.com Received: by 10.112.63.164 with HTTP; Thu, 7 Nov 2013 18:22:57 -0800 (PST) In-Reply-To: <527C38FF.6040000@nostrum.com> References: <527C38FF.6040000@nostrum.com> Date: Thu, 7 Nov 2013 18:22:57 -0800 X-Google-Sender-Auth: up2GhVjLr-9a4I2_1kiU4qQHeO8 Message-ID: From: Gregory Maxwell To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] Alternative consensus and MTI video codecs X-BeenThere: rtcweb@ietf.org 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 02:23:00 -0000 On Thu, Nov 7, 2013 at 5:06 PM, Adam Roach wrote: > Our situation is radically different: there are a number of actual argume= nts > to be made for both options. We've heard these arguments, at long length, and have, apparently, not found them sufficiently decisive or we wouldn't be at this juncture. I must have failed to make the point I was attempting to make sufficiently clear. Let me retry: If we believe that an MTI video codec, regardless of what it is, was an independently important thing to have then "no MTI" shouldn't be the result of failing to achieve an MTI in discussion, because there exist _an option_, any option, to achieve a MTI video codec. So I was hoping to see any support for "no MTI" (which sounded very popular in the room) to come with arguments for why an MTI doesn't actually matter. Without intending any "push", strong or otherwise, I'll point out that the apparent difficulty in responding to my message without allegations of irrational arguments and emotional investments increases my estimation that locating a set of "randomly selected neutral parties" which is sufficiently non-partisan to not cloud the process is not obviously possible. Without that kind of doubt in mind it's not clear to me if that alternative process could be successful, which is why I attempted to illustrate my point with the 4.4 coinflip. Coinflip will produce a result, and the result it will produce will achieve the goal of selecting an MTI codec (especially in consideration of substantial support for either option, both on the list and in the room), and it doesn't require selecting non-partisan parties. I wasn't trying to say it was _good_ though, only that it was enough to say failure to pick an MTI alone isn't enough to justify removing MTI for the sake of MTI from the goals. (There are plenty of other arguments that can be made about the non-optimality of the 3929 panel process=E2=80=94 e.g. the requirement to m= eet nomcom requirements with physical meeting attendance would generally make it easy for large corporate contributors, especially ones with diverse participation, to be over represented. But, to be frank, your response has made me feel uncomfortable pointing that much out... I didn't start this thread with an intention to argue against it, but I wonder after your message if anyone else would dare.) From stewe@stewe.org Thu Nov 7 18:58:10 2013 Return-Path: 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 8588521E8119 for ; Thu, 7 Nov 2013 18:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 JMwOjhu-qFo6 for ; Thu, 7 Nov 2013 18:58:00 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id AFDE021E81A2 for ; Thu, 7 Nov 2013 18:57:54 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB362.namprd07.prod.outlook.com (10.141.75.21) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 8 Nov 2013 02:57:51 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.55]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.167]) with mapi id 15.00.0785.001; Fri, 8 Nov 2013 02:57:51 +0000 From: Stephan Wenger To: "rtcweb@ietf.org" Thread-Topic: MTI video codec, charter, RFC 3929 Thread-Index: AQHO3C5PKYlhQnrmxU2nAnCXMnJnig== Date: Fri, 8 Nov 2013 02:57:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.114.24.114] x-forefront-prvs: 00246AB517 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(57704003)(53754006)(52604005)(87266001)(83072001)(54316002)(81686001)(66066001)(81816001)(59766001)(56776001)(77982001)(79102001)(49866001)(80976001)(47736001)(50986001)(16236675002)(47976001)(83322001)(36756003)(76786001)(76176001)(56816003)(77096001)(76796001)(31966008)(46102001)(80022001)(81542001)(74662001)(65816001)(74502001)(47446002)(69226001)(63696002)(81342001)(54356001)(4396001)(76482001)(53806001)(74876001)(74706001)(51856001)(85306002)(74366001)(2656002)(87936001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB362; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:64.114.24.114; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CEA19328A9A84stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: [rtcweb] MTI video codec, charter, RFC 3929 X-BeenThere: rtcweb@ietf.org 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 02:58:10 -0000 --_000_CEA19328A9A84stewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, At the mike, I suggested that it is time to reconsider the currently standi= ng WG's consensus to select at least one mandatory to implement video codec= . The chairs asked that such positions be stated on the list. Here is my = position, as usual as an individual (do I need to mention this?). (1) Specifying one or more MTI video codecs is IMO desirable ONLY if the va= st majority of the implementations, including both browser-based implementa= tions and non-browser implementations would follow that requirement, and if= the chosen MTI codec is technically suitable. Both candidates under discu= ssion are probably technically suitable, while old and reasonably patent-sa= ve stuff like H.261 probably is not. However, today's statements and humms= show, at least to me, rather convincingly that a decision for either of th= e two candidate codecs will be ignored by a significant part of the impleme= nter community. An SDO shouldn't mandate something of which it is clear th= at it is going to be widely ignored, for the same reason that no good manag= er issues orders that he knows will be ignored by the subordinate. (2) Under the assumption that (1) is supported by rtcweb consensus, I think= we need to take off the table the following options: (2) a) Mandating one of the two candidate codecs, by RFC 3929. Doing so wi= ll be painful, and will not lead to interoperability among most or all rtcw= eb devices/browsers, and is therefore a failure. It will also damage the w= ebrtc standard suite as a whole: who knows what else will be ignored when s= uch a central part is being ignored... (2) b) Mandating both candidate codecs. Even more folks than under 2)a) wo= uld ignore the standard as written, because one would have to absorb cost a= nd risk for both codecs, and not only for one. Which is not good of the re= asons stated above. Oh, I would not rule out that there are a few bold guy= s who would faithfully implement both-Mozilla has announced that much-and t= hose would be the interop stars. Still, many more IMO would not, so I cann= ot help calling this a failure as well. (3) Instead, the following options should be on the table: (3) a) Mandating "at least one of VP8 / H.264" will slightly improve intero= perability over saying nothing, and the standard will not be ignored by man= y. (3) b) Mandating no video codec may well be the worst option for interopera= bility, but has the advantage of being future-proof. How many folks implem= enting H.323 are unhappy with the requirement to implement H.261 QCIF and G= .711??? (4) Structure of a decision making process I would structure the decision making process as follows: in a first step, see whether we can agree by consensus to overturn the prev= ious consensus that we are to define at least one MTI video codec. (For th= e procedure buffs: I looked at the charter and do not believe that it would= need to be changed. Nothing therein requires us to define an MTI video co= dec. In fact, work item 6 could be interpreted as already achieved (throug= h the audio codec selection), and even if we were not using such an interpr= etation, item 6 leaves us the option of "must or should". That's a lot of = wiggle room. Wise choice at charter time. If such a consensus could be reached, then I would seek consensus between o= ptions 3)a) and 3)b) above. If such consensus cannot be reached, it may indeed be time to invoke the R= FC 3929 processes. Contrary to what I said at the mike, after re-reading 3929, I do not care a= ny more whether the question of invoking 3929 and the question of revoking = previous WG consensus are decoupled and sequentially decided. If the chair= s want to deal with both issues in the same consensus call, that would be f= ine with me. However, I would object if the previous WG consensus is not q= uestioned at all. Thanks for reading all the way down here. Stephan --_000_CEA19328A9A84stewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,

At the mike, I suggested that it is time to reconsider the currently s= tanding WG’s consensus to select at least one mandatory to implement = video codec.  The chairs asked that such positions be stated on the li= st.  Here is my position, as usual as an individual (do I need to mention this?).

(1) Specifying one or more MTI video codecs is IMO desirable ONLY if t= he vast majority of the implementations, including both browser-based imple= mentations and non-browser implementations would follow that requirement, a= nd if the chosen MTI codec is technically suitable.  Both candidates under discussion are probably technically = suitable, while old and reasonably patent-save stuff like H.261 probably is= not.  However, today’s statements and humms show, at least to m= e, rather convincingly that a decision for either of the two candidate codecs will be ignored by a significant part of the i= mplementer community.  An SDO shouldn’t mandate something of whi= ch it is clear that it is going to be widely ignored, for the same reason t= hat no good manager issues orders that he knows will be ignored by the subordinate.

(2) Under the assumption that (1) is supported by rtcweb consensus, I = think we need to take off the table the following options:

(2) a) Mandating one of the two candidate codecs, by RFC 3929.  D= oing so will be painful, and will not lead to interoperability among most o= r all rtcweb devices/browsers, and is therefore a failure.  It will al= so damage the webrtc standard suite as a whole: who knows what else will be ignored when such a central part is being igno= red…

(2) b) Mandating both candidate codecs.  Even more folks than und= er 2)a) would ignore the standard as written, because one would have to abs= orb cost and risk for both codecs, and not only for one.  Which is not= good of the reasons stated above.  Oh, I would not rule out that there are a few bold guys who would faithfully imp= lement both—Mozilla has announced that much—and those would be = the interop stars.  Still, many more IMO would not, so I cannot help c= alling this a failure as well.

(3) Instead, the following options should be on the table:

(3) a) Mandating “at least one of VP8 / H.264” will slight= ly improve interoperability over saying nothing, and the standard will not = be ignored by many.

(3) b) Mandating no video codec may well be the worst option for inter= operability, but has the advantage of being future-proof.  How many fo= lks implementing H.323 are unhappy with the requirement to implement H.261 = QCIF and G.711??? 

(4) Structure of a decision making process
 
I would structure the decision making process as follows: 

in a first step, see whether we can agree by consensus to overturn the= previous consensus that we are to define at least one MTI video codec. &nb= sp;(For the procedure buffs: I looked at the charter and do not believe tha= t it would need to be changed.  Nothing therein requires us to define an MTI video codec.  In fact, work item= 6 could be interpreted as already achieved (through the audio codec select= ion), and even if we were not using such an interpretation, item 6 leaves u= s the option of “must or should”.  That’s a lot of wiggle room.  Wise choice at charter time.   

If such a consensus could be reached, then I would seek consensus betw= een options 3)a) and 3)b) above.

If such  consensus cannot be reached, it may indeed be time to in= voke the RFC 3929 processes.

Contrary to what I said at the mike, after re-reading 3929, I do not c= are any more whether the question of invoking 3929 and the question of revo= king previous WG consensus are decoupled and sequentially decided.  If= the chairs want to deal with both issues in the same consensus call, that would be fine with me.  However, I w= ould object if the previous WG consensus is not questioned at all.

Thanks for reading all the way down here.

Stephan



--_000_CEA19328A9A84stewesteweorg_-- From keith.drage@alcatel-lucent.com Thu Nov 7 18:58:21 2013 Return-Path: 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 EEAC121E8097 for ; Thu, 7 Nov 2013 18:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.533 X-Spam-Level: X-Spam-Status: No, score=-110.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 o7K0O-iQlBFF for ; Thu, 7 Nov 2013 18:58:15 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D92FC21E8119 for ; Thu, 7 Nov 2013 18:58:12 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rA82w9IC006152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Nov 2013 20:58:11 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rA82w9WY030131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Nov 2013 03:58:09 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 8 Nov 2013 03:58:09 +0100 From: "DRAGE, Keith (Keith)" To: "rtcweb@ietf.org" Thread-Topic: Mandatory to implement video codec? Thread-Index: Ac7cLiqalLlZVs40QU+PGyClgL6FtQ== Date: Fri, 8 Nov 2013 02:58:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0CD06D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [rtcweb] Mandatory to implement video codec? X-BeenThere: rtcweb@ietf.org 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 02:58:22 -0000 References have been made to a prior consensus decision to have a mandatory= to implement video codec. I'd like to refresh myself on those discussions and am having difficulty fi= nding them. Can someone remember when they occurred and therefore point me in the right= direction? Regards Keith= From cowwoc@bbs.darktech.org Thu Nov 7 21:56:27 2013 Return-Path: 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 0AD8D11E811A for ; Thu, 7 Nov 2013 21:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.304 X-Spam-Level: X-Spam-Status: No, score=-4.304 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 tpU0Pun4IiZ3 for ; Thu, 7 Nov 2013 21:56:18 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id E902A11E8158 for ; Thu, 7 Nov 2013 21:56:17 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id to1so790401ieb.37 for ; Thu, 07 Nov 2013 21:56:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=skVWRQlp2nlCffock4wnFp+sHls4wX4cUzrx8aTFhzs=; b=Yz4DTsOxhApeGxk9Rr2G44ZWju92OdHbZWRfVoRA9jP9LQ+fSmDWvKG/8PQ96RjVVz BxiP/nT/M92MDmR4So4y85X7VbOnWOqWG8iy1TcnW7dDdbdx2Iyc3I/XVTG8xtMlmiNG cuOmjSQM7P+6rsBpT32h9yEBRm8AbX88EJexIyImnEDJg+ZnIbCV1pJ9H5iMxYNET//B nIcVRjb7ibl5ne4qhHqIY6d/f8PAS/2aEaKahUl78XYuZbq38s27/IVpkBR48HaQp70P 0reReG5zaVA5+XdxXxw/5Nt5+6pglg18YtNE+6YiWMz7tuClsVxhb6M/ko0ye+Fo2H77 6F7Q== X-Gm-Message-State: ALoCoQluubma3Rfjo1+T3DEeBg9f0OAHtoneIlaodbdqJLH4AAP+lTMh/ukxsVxKDa2MvGGuKeDH X-Received: by 10.43.152.78 with SMTP id kv14mr7769644icc.13.1383890176903; Thu, 07 Nov 2013 21:56:16 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f5sm1662646igc.4.2013.11.07.21.56.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 21:56:16 -0800 (PST) Message-ID: <527C7CFE.4080700@bbs.darktech.org> Date: Fri, 08 Nov 2013 00:56:14 -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: rtcweb@ietf.org References: <527C38FF.6040000@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090909070406090707070703" Subject: [rtcweb] H.261 vs No MTI (was: Alternative consensus and MTI video codecs) X-BeenThere: rtcweb@ietf.org 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 05:56:27 -0000 This is a multi-part message in MIME format. --------------090909070406090707070703 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I'll bring up a related point that I brought up a few days ago (I changed to subject to avoid hijacking the thread). 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: * 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? Gili On 07/11/2013 9:22 PM, Gregory Maxwell wrote: > On Thu, Nov 7, 2013 at 5:06 PM, Adam Roach wrote: >> Our situation is radically different: there are a number of actual arguments >> to be made for both options. > We've heard these arguments, at long length, and have, apparently, not > found them sufficiently decisive or we wouldn't be at this juncture. > > I must have failed to make the point I was attempting to make > sufficiently clear. Let me retry: If we believe that an MTI video > codec, regardless of what it is, was an independently important thing > to have then "no MTI" shouldn't be the result of failing to achieve an > MTI in discussion, because there exist _an option_, any option, to > achieve a MTI video codec. So I was hoping to see any support for "no > MTI" (which sounded very popular in the room) to come with arguments > for why an MTI doesn't actually matter. > > Without intending any "push", strong or otherwise, I'll point out that > the apparent difficulty in responding to my message without > allegations of irrational arguments and emotional investments > increases my estimation that locating a set of "randomly selected > neutral parties" which is sufficiently non-partisan to not cloud the > process is not obviously possible. Without that kind of doubt in mind > it's not clear to me if that alternative process could be successful, > which is why I attempted to illustrate my point with the 4.4 coinflip. > Coinflip will produce a result, and the result it will produce will > achieve the goal of selecting an MTI codec (especially in > consideration of substantial support for either option, both on the list > and in the room), and it doesn't require selecting non-partisan > parties. I wasn't trying to say it was _good_ though, only that it > was enough to say failure to pick an MTI alone isn't enough to justify > removing MTI for the sake of MTI from the goals. > > (There are plenty of other arguments that can be made about the > non-optimality of the 3929 panel process— e.g. the requirement to meet > nomcom requirements with physical meeting attendance would generally > make it easy for large corporate contributors, especially ones with > diverse participation, to be over represented. But, to be frank, your > response has made me feel uncomfortable pointing that much out... I > didn't start this thread with an intention to argue against it, but I > wonder after your message if anyone else would dare.) > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090909070406090707070703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

I'll bring up a related point that I brought up a few days ago (I changed to subject to avoid hijacking the thread).

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:
  • 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?

Gili

On 07/11/2013 9:22 PM, Gregory Maxwell wrote:
On Thu, Nov 7, 2013 at 5:06 PM, Adam Roach <adam@nostrum.com> wrote:

Our situation is radically different: there are a number of actual arguments
to be made for both options.

We've heard these arguments, at long length, and have, apparently, not
found them sufficiently decisive or we wouldn't be at this juncture.

I must have failed to make the point I was attempting to make
sufficiently clear.  Let me retry: If we believe that an MTI video
codec, regardless of what it is, was an independently important thing
to have then "no MTI" shouldn't be the result of failing to achieve an
MTI in discussion, because there exist _an option_, any option, to
achieve a MTI video codec.  So I was hoping to see any support for "no
MTI" (which sounded very popular in the room) to come with arguments
for why an MTI doesn't actually matter.

Without intending any "push", strong or otherwise, I'll point out that
the apparent difficulty in responding to my message without
allegations of irrational arguments and emotional investments
increases my estimation that locating a set of "randomly selected
neutral parties" which is sufficiently non-partisan to not cloud the
process is not obviously possible.  Without that kind of doubt in mind
it's not clear to me if that alternative process could be successful,
which is why I attempted to illustrate my point with the 4.4 coinflip.
Coinflip will produce a result, and the result it will produce will
achieve the goal of selecting an MTI codec (especially in
consideration of substantial support for either option, both on the list
and in the room), and it doesn't require selecting non-partisan
parties.  I wasn't trying to say it was _good_ though, only that it
was enough to say failure to pick an MTI alone isn't enough to justify
removing MTI for the sake of MTI from the goals.

(There are plenty of other arguments that can be made about the
non-optimality of the 3929 panel process— e.g. the requirement to meet
nomcom requirements with physical meeting attendance would generally
make it easy for large corporate contributors, especially ones with
diverse participation, to be over represented. But, to be frank, your
response has made me feel uncomfortable pointing that much out... I
didn't start this thread with an intention to argue against it, but I
wonder after your message if anyone else would dare.)
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------090909070406090707070703-- From cowwoc@bbs.darktech.org Thu Nov 7 22:02:20 2013 Return-Path: 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 D023411E817F for ; Thu, 7 Nov 2013 22:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.29 X-Spam-Level: X-Spam-Status: No, score=-4.29 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Ke4n3skApGI8 for ; Thu, 7 Nov 2013 22:02:15 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id A3F3811E811A for ; Thu, 7 Nov 2013 22:02:14 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id aq17so2481110iec.6 for ; Thu, 07 Nov 2013 22:02:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=N8gzFZFSI8M2GAHXelfz893sc9dBNGy3f2reXCtMi88=; b=ePqy2Bm+Ogh+f+SYVRpDLiaW//Qw63w5VAm/f06WU51mZ3OFf7VJUrjziAPh8Jtt+j e7CSQ0rMxztktrL6s3N6W6yQLo1e9HTSRz+P1wu2CWEb5l1fG4OoBZwEcM68EetE2D7P p5UVSl8z5on+F0YNLIAZyW6HfC80bBpdpSzNH/rR7jsWV9n8IIHHtWBX09ONGst7uqh8 0FZNRkS2NBSOWH9RpLn3c77RF/iTPldRVIb5LrgoSJsXbuVUDhBMaGCsHpV9UB0BXu80 st3xt3UKY6haRAJCmDio0wWpH5hG9crIRpziJk7MzVDNPGZWGJEH/yplcy8xoNVzxt9v k+Xw== X-Gm-Message-State: ALoCoQmBcsmSlCHNyRkEs6L9/tZuoGQ5cqLSSVp8oEtiZn5wmxXz+jKZOy+UdpRrvpwfCcYr69FY X-Received: by 10.51.15.130 with SMTP id fo2mr1009320igd.28.1383890532900; Thu, 07 Nov 2013 22:02:12 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id x5sm1674672iga.6.2013.11.07.22.02.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 22:02:12 -0800 (PST) Message-ID: <527C7E61.7050609@bbs.darktech.org> Date: Fri, 08 Nov 2013 01:02:10 -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: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050202040201060301000007" Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929 X-BeenThere: rtcweb@ietf.org 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 06:02:21 -0000 This is a multi-part message in MIME format. --------------050202040201060301000007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/11/2013 9:57 PM, Stephan Wenger wrote: > (3) b) Mandating no video codec may well be the worst option for > interoperability, but has the advantage of being future-proof. How > many folks implementing H.323 are unhappy with the requirement to > implement H.261 QCIF and G.711??? Hi Stephan, Just a point of clarification: I hate dead wood as much as the next guy, so if you see me advocating H.261 as MTI please understand that I am also advocating removing it as MTI the second we have consensus on a credible replacement. I don't think anything in the spec should be written in stone. The list of MTI codecs *should* be updated every 5-10 years. Gili --------------050202040201060301000007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/11/2013 9:57 PM, Stephan Wenger wrote:
(3) b) Mandating no video codec may well be the worst option for interoperability, but has the advantage of being future-proof.  How many folks implementing H.323 are unhappy with the requirement to implement H.261 QCIF and G.711??? 
Hi Stephan,

Just a point of clarification: I hate dead wood as much as the next guy, so if you see me advocating H.261 as MTI please understand that I am also advocating removing it as MTI the second we have consensus on a credible replacement. I don't think anything in the spec should be written in stone. The list of MTI codecs *should* be updated every 5-10 years.

Gili
--------------050202040201060301000007-- From fw@deneb.enyo.de Thu Nov 7 22:19:53 2013 Return-Path: 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 0881A21E818F for ; Thu, 7 Nov 2013 22:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 Qrl3dSBogJ7O for ; Thu, 7 Nov 2013 22:19:48 -0800 (PST) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 822A721E8091 for ; Thu, 7 Nov 2013 22:19:48 -0800 (PST) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1VefQ2-0000mb-NN; Fri, 08 Nov 2013 07:19:46 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1VefQ2-0002pu-Jj; Fri, 08 Nov 2013 07:19:46 +0100 From: Florian Weimer To: David Benham References: Date: Fri, 08 Nov 2013 07:19:46 +0100 In-Reply-To: (David Benham's message of "Thu, 7 Nov 2013 14:40:08 -0800") Message-ID: <87bo1vbekd.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Current H.264 licensing practice X-BeenThere: rtcweb@ietf.org 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 06:19:53 -0000 * David Benham: > Extrapolating from an EULA what one's rtcweb dev/distribution license > rights is likely way off base. I disagree, considering the broad overlap between EULAs from different vendors and very different product categories. > You can read the MPEG-LA's FAQ here ... > http://www.mpegla.com/main/programs/AVC/Documents/AVC_TermsSummary.pdf > Note the graphic and text for "(b) sublicenses" on pages 2 and 3. That document seems to date from 2004 or 2005, despite the metadata timestamp. The Internet was quite different then. Internet video conferencing existed, but was difficult to get to work. Mobile Internet used EDGE, with bandwidths less 500 kbps. > The commercial royalties described are targeted at Service Providers of > on-demand titles and/or broadcast TV over the Internet with greater 100K > subscribers and great remuneration (aka, subscription or ad revenue). > Think the likes of Netflix, Amazon Prime, etc, using the video tag and > *not* the support-desk in your example or commercial, real-time > communications. Uhm, that's not how patent licensing works. You need a license even if the patent owner has no ready-made offering that fits your particular needs. From lgeyser@gmail.com Thu Nov 7 23:32:27 2013 Return-Path: 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 B811711E8215 for ; Thu, 7 Nov 2013 23:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 og5fO3qfYh0p for ; Thu, 7 Nov 2013 23:32:27 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DCA1811E8145 for ; Thu, 7 Nov 2013 23:32:26 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id n7so396510lam.30 for ; Thu, 07 Nov 2013 23:32:25 -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=CKZ2K4P2+sXTLi6OgZvTu9Cg7MIRVRvqjoY4AUyNuiQ=; b=CI56+EDzG796/ddwi3Nzy7VQCd82RPI0pxbUNaxnJmm96J05mbgdcfRoRpfXS+dA/c 6O+5MRPIcnWlWx7gmZ3AAjGWJtAarXzsM18rx9Gr1SHdQdqchsjcYG/27FjZ8qEXhJaF RgKWQGMdQvMLKDzEArwn/OPGpPCwutSh5+fiC6IUVVre8tC6HXWKZZIctyr62A2O3TMK fF8KwMkoiNU7RvkrvcbDA7DevhsyT0I9FEQLX7M8VFS3IiwXJuns7KhYJUvUIigqEPQX m0LcIun0E24yv7T2u+wWVOSAqzKBd5xN+9ducoM62Wq8Jf+ECpX5WLS4nV8p5LnrRT5L 5SJQ== MIME-Version: 1.0 X-Received: by 10.152.5.228 with SMTP id v4mr9541964lav.7.1383895945692; Thu, 07 Nov 2013 23:32:25 -0800 (PST) Received: by 10.114.168.70 with HTTP; Thu, 7 Nov 2013 23:32:25 -0800 (PST) In-Reply-To: <527C7E61.7050609@bbs.darktech.org> References: <527C7E61.7050609@bbs.darktech.org> Date: Fri, 8 Nov 2013 09:32:25 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e013d1a403fc9dc04eaa56220 Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929 X-BeenThere: rtcweb@ietf.org 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 07:32:27 -0000 --089e013d1a403fc9dc04eaa56220 Content-Type: text/plain; charset=ISO-8859-1 +1 H.261 will anyway only be used in a small percentage of cases. Most will implement VP8 or/and H.264 in addition to the MTI. On 8 November 2013 08:02, cowwoc wrote: > On 07/11/2013 9:57 PM, Stephan Wenger wrote: > > (3) b) Mandating no video codec may well be the worst option for > interoperability, but has the advantage of being future-proof. How many > folks implementing H.323 are unhappy with the requirement to implement > H.261 QCIF and G.711??? > > Hi Stephan, > > Just a point of clarification: I hate dead wood as much as the next guy, > so if you see me advocating H.261 as MTI please understand that I am also > advocating removing it as MTI the second we have consensus on a credible > replacement. I don't think anything in the spec should be written in stone. > The list of MTI codecs *should* be updated every 5-10 years. > > Gili > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e013d1a403fc9dc04eaa56220 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1
H.261 will anyway only be used in a small= percentage of cases. Most will implement VP8 or/and H.264 in addition to t= he MTI.


On 8 November 2013 08:02, cowwoc <cowwoc@bbs.darktech.org> wrote:
=20 =20 =20
On 07/11/2013 9:57 PM, Stephan Wenger wrote:
=20 (3) b) Mandating no video codec may well be the worst option for interoperability, but has the advantage of being future-proof. =A0How many folks implementing H.323 are unhappy with the requirement to implement H.261 QCIF and G.711???=A0
Hi Stephan,

Just a point of clarification: I hate dead wood as much as the next guy, so if you see me advocating H.261 as MTI please understand that I am also advocating removing it as MTI the second we have consensus on a credible replacement. I don't think anything in the spec shoul= d be written in stone. The list of MTI codecs *should* be updated every 5-10 years.

Gili

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--089e013d1a403fc9dc04eaa56220-- From duerst@it.aoyama.ac.jp Thu Nov 7 23:46:16 2013 Return-Path: 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 6C0E011E8193 for ; Thu, 7 Nov 2013 23:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[AWL=-1.945, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 ZTdgbKqCD9oL for ; Thu, 7 Nov 2013 23:46:10 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id B924211E821A for ; Thu, 7 Nov 2013 23:46:09 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rA87jqNZ014495; Fri, 8 Nov 2013 16:45:52 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 493a_0c59_caf40650_4849_11e3_969a_001e6722eec2; Fri, 08 Nov 2013 16:45:51 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id EE441BF54D; Fri, 8 Nov 2013 16:45:51 +0900 (JST) Message-ID: <527C96A6.5070008@it.aoyama.ac.jp> Date: Fri, 08 Nov 2013 16:45:42 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: David Singer References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <527A06EF.2070007@bbs.darktech.org> <527A0C4D.7020707@gmail.com> <527A15A3.2090006@bbs.darktech.org> <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com> <527BAA17.40705@bbs.darktech.org> <99C1B7D8-7E90-4FF4-9F31-D18F2F4E4D40@apple.com> In-Reply-To: <99C1B7D8-7E90-4FF4-9F31-D18F2F4E4D40@apple.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 07:46:16 -0000 On 2013/11/08 9:14, David Singer wrote: > For a start, not everyone would have to transcode, only those cases where there the two ends implement only one, and different, codecs. > Secondly, I didn't say it was ideal, I I said it was better than saying nothing. > Third, if you implement both, you would never need to use a transcoder for this reason, but you nonetheless might use a bridge or intermediary for a whole host of other reasons. Would Apple implement both? Would Google implement both? (As I understand it, Mozilla will implement both.) Regards, Martin. From ron@debian.org Fri Nov 8 04:31:21 2013 Return-Path: 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 2AA7A21E80BE for ; Fri, 8 Nov 2013 04:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.212 X-Spam-Level: X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] 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 epKNLPvCDcZO for ; Fri, 8 Nov 2013 04:31:16 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 65BA421E80BB for ; Fri, 8 Nov 2013 04:31:14 -0800 (PST) Received: from ppp121-45-83-213.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.83.213]) by ipmail07.adl2.internode.on.net with ESMTP; 08 Nov 2013 23:01:13 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 4CB9B4F8F3 for ; Fri, 8 Nov 2013 23:01:10 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CO2EqE4+m9IM for ; Fri, 8 Nov 2013 23:01:09 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 4B9724F902; Fri, 8 Nov 2013 23:01:09 +1030 (CST) Date: Fri, 8 Nov 2013 23:01:09 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20131108123109.GF3245@audi.shelbyville.oz> References: <527C38FF.6040000@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527C38FF.6040000@nostrum.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] Alternative consensus and MTI video codecs X-BeenThere: rtcweb@ietf.org 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 12:31:21 -0000 On Thu, Nov 07, 2013 at 05:06:07PM -0800, Adam Roach wrote: > On 11/7/13 16:41, Gregory Maxwell wrote: > >If we still believe from an engineering perspective that WebRTC ought > >to have one MTI video codec it still can, even though the counts were > >split: We can invoke RFC 3929 4.4 and_flip a coin_. > > I do not believe the decision under consideration qualifies for the > process in section 4.4. As that section itself notes, random > selection is only appropriate for something like deciding a > numerical codepoint or a DNS prefix. I agree that there are still too many unanswered objections to declare that both options have equal merit and a random selection of either will therefore suffice. Though I do also agree with Greg's analysis that if this group is going to punt that decision to an outside actor, we will be faced with some difficulty in finding a more unbiased selector. > Our situation is radically different: there are a number of actual > arguments to be made for both options. Yes, there certainly are. And I think our next step needs to be to distill those to the ones that are actually still contentious, and strive to achieve rough consensus on each of those remaining arguments. We already have violent agreement occurring on quite a number of the original selection points. I think we can safely say there is rough consensus on things like "the performance and quality difference is negligible enough that it isn't a deciding factor". Which means we only need to decide on the actually relevant problems that remain outside of that to see if a clear best choice remains. And I really do think that if we take each of those individually and in isolation, that each of them individually and in isolation does have an answer that we can achieve rough consensus on. And that when we then sum the result of those consensus decisions, a clear advantage will remain for just one choice. A large part of the confusion at present appears to be that whenever the Hard Questions are raised, someone then buries achieving any conclusion to them under "what about this other idea that we discussed and dismissed two years ago!!" ... lather, rinse, repeat. It's been said here many times that the IETF does not vote. Yet people are still talking about voting, and what we had today was essentially "just a vote". If it had been conclusive, that would have been great, but it wasn't, and since nobody was required to justify the reasoning for their preference vote, I think it's premature to declare "we have failed to reach rough consensus". The clear disparity between the the majority of the jabber room and the majority of the attendees is a significant piece of information in its own right, and relevant to any decision process that we might employ to establish a working rough consensus. Especially given the principle that IETF decisions are supposed to be made by consensus calls on the working group list. > I think an external review team (section 4.1) is a reasonable way > forward, as it lets the decision rest on the merits that proponents > of each approach have themselves put forth, without allowing > partisan or emotional considerations to get in the way of facts. > > I'll make an even stronger statement: I would contend that any > strong push against the use of an external review team amounts to a > tacit admission by an individual that the arguments for their > preferred position are insufficiently compelling. Superficially, and taken in isolation, that would ordinarily be a fairly compelling argument. But taken in the context of what we saw happen today, I would say that the onus is first on you to demonstrate that we _can_ select a properly neutral and unbiased review team to weigh the arguments on their actual merit. We know FOR A FACT, that there are major problems with the selection of a heavily encumbered, and restrictively licenced MTI codec. The people pushing for choosing that option have acknowledged this and tried to mitigate it by throwing several million dollars at Freebies For Some. Many people replied on the list that "this is wonderful, and we thank you a lot, but it doesn't actually solve the core problem". There was effectively no direct rebuttal to this there. And so far the only answer to those remaining problems was along the lines of "pfft, you're all just little fish, you don't matter". If the candidates for an external review team are going to inherently be biased along the same lines as the physical meeting room was, then a monte-carlo sampling of them isn't going to get us a neutral panel. And if an argument of "but the licence doesn't allow this at all", can be dismissed with "pfft, that doesn't matter", then that would seem to be a tacit admission that no argument could ever be sufficiently compelling to a group espousing that belief. > If anyone believes that their position logically follows from the > known facts, then they would necessarily believe that a > randomly-selected panel of neutral third parties will agree with > them. If such a person thinks that the panel won't, perhaps they > should reevaluate whether their arguments are grounded in facts and > logic, or their own emotional investment in this decision. My belief is that this working group hasn't actually given sufficient and complete consideration to the already known facts to set about abdicating the decision to an external group. There are serious questions raised on the list that are unanswered in any even remotely satisfactory way. Maybe people thought the show of hands today would be decisive and they would not have to answer them. But it wasn't, and so the necessity to either answer them, or admit they are the fundamental blockers that people assert they are, still remains. I think it would be impossible for this group to present this to a group of people that haven't followed the discussion to date, and expect that group to arrive at a well reasoned answer if even we don't yet have reasonable answers to questions of grave concern. We had two presentations today. One was a short and sweet "my argument remains unchanged and stands on its own merit". The other was a great modern adaptation of The Story Of The Reason. If anyone who heard it can remember what the reason actually was, I would invite them to relay it for posterity via answers to the still unanswered questions on the mailing list. Let's break this down into what the showstoppers for either choice really still are today. If we focus on that, I don't think we're actually very many steps from having a sensible decision be quite obvious and undeniable. And from having it broken down into simple things that we can achieve consensus over, step by step -- making the final step seem far less of an insurmountable leap of faith. Attempts to change things that previously had consensus is not a way forward, and we do have consensus that MTI is necessary and crap ancient codecs are not a viable option. Let's worry about what the Real problems with the two choices we have actually are and decide what needs to occur in order to resolve them if they do stand up to scrutiny as actual problems. I don't think we've actually failed at that, we've just had the argument become deeply muddled in sophistry. Having external adjudication on a final consensus may still be necessary, but that's quite different from totally punting on the work needed to establish it. Some time back Adam posted some very interesting thoughts on the mechanisms of rough consensus. I believe that if we follow those, a clear best decision will emerge. Ron From adam@nostrum.com Fri Nov 8 07:19:29 2013 Return-Path: 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 0D26E21E8160 for ; Fri, 8 Nov 2013 07:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 DdBNX6D323xP for ; Fri, 8 Nov 2013 07:19:28 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 595CF21E8140 for ; Fri, 8 Nov 2013 07:19:28 -0800 (PST) Received: from dhcp-9081.meeting.ietf.org (dhcp-9081.meeting.ietf.org [31.133.144.129]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA8FJF1A056649 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 8 Nov 2013 09:19:16 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <527D00F2.4090000@nostrum.com> Date: Fri, 08 Nov 2013 07:19:14 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Gregory Maxwell , "rtcweb@ietf.org" References: <527C38FF.6040000@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 31.133.144.129 is authenticated by a trusted mechanism) Subject: Re: [rtcweb] Alternative consensus and MTI video codecs X-BeenThere: rtcweb@ietf.org 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:19:29 -0000 On 11/7/13 18:22, Gregory Maxwell wrote: > I must have failed to make the point I was attempting to make > sufficiently clear. Let me retry: If we believe that an MTI video > codec, regardless of what it is, was an independently important thing > to have then "no MTI" shouldn't be the result of failing to achieve an > MTI in discussion, because there exist_an option_, any option, to > achieve a MTI video codec. So I was hoping to see any support for "no > MTI" (which sounded very popular in the room) to come with arguments > for why an MTI doesn't actually matter. Thanks for the clarification: I didn't get that out of your first message. For what it's worth, I agree with what you're saying here. What I could make sense of was a suggestion that we turn to complete randomness for the decision at hand. And while that would actually make me happy[1], it struck me as patent nonsense from a process perspective. > There are plenty of other arguments that can be made about the > non-optimality of the 3929 panel process... I tried really hard to make sure that any conversations about 3929 could begin playing out by giving what I think is a rather accessible description of that process back in Paris. /a ___ [1] I just want an MTI [note: singular], and don't strongly care which one is selected. I *do* have a preference, but I don't think the arguments in favor of my preference are actually relevant to the IETF. From cowwoc@bbs.darktech.org Fri Nov 8 07:57:24 2013 Return-Path: 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 31DF211E8247 for ; Fri, 8 Nov 2013 07:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oWEjYRWn-2S for ; Fri, 8 Nov 2013 07:57:14 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E819E11E81AB for ; Fri, 8 Nov 2013 07:57:04 -0800 (PST) Received: by mail-ie0-f172.google.com 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; d=1e100.net; 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 10.50.141.133 with SMTP id ro5mr2806705igb.35.1383926221872; Fri, 08 Nov 2013 07:57:01 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id yt10sm3649158igb.9.2013.11.08.07.57.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 07:57:01 -0800 (PST) Message-ID: <527D09CA.1060703@bbs.darktech.org> 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: <527C38FF.6040000@nostrum.com> <527C7CFE.4080700@bbs.darktech.org> <1E0D9A14-E629-4CB2-AC67-5860B24DB7D7@westhawk.co.uk> In-Reply-To: <1E0D9A14-E629-4CB2-AC67-5860B24DB7D7@westhawk.co.uk> Content-Type: multipart/alternative; boundary="------------060600070203080201070109" Cc: rtcweb@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 15:57:25 -0000 This is a multi-part message in MIME format. --------------060600070203080201070109 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 --------------060600070203080201070109 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
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
--------------060600070203080201070109-- From adam@nostrum.com Fri Nov 8 08:01:37 2013 Return-Path: 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 D3E2A21E8130 for ; Fri, 8 Nov 2013 08:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 W4BuAxVeu391 for ; Fri, 8 Nov 2013 08:01:27 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EB4C521E8140 for ; Fri, 8 Nov 2013 08:01:18 -0800 (PST) Received: from dhcp-9081.meeting.ietf.org (dhcp-9081.meeting.ietf.org [31.133.144.129]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA8G19XV058356 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 8 Nov 2013 10:01:10 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <527D0AC4.1080704@nostrum.com> Date: Fri, 08 Nov 2013 08:01:08 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ron , rtcweb@ietf.org References: <527C38FF.6040000@nostrum.com> <20131108123109.GF3245@audi.shelbyville.oz> In-Reply-To: <20131108123109.GF3245@audi.shelbyville.oz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 31.133.144.129 is authenticated by a trusted mechanism) Subject: [rtcweb] On the form of the question (was Re: Alternative consensus and MTI video codecs) X-BeenThere: rtcweb@ietf.org 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:01:37 -0000 On 11/8/13 04:31, Ron wrote: > ...what we had today was essentially "just a vote". If it had been conclusive, that would have been great, but it wasn't... Well, to be fair, it did involve a rather long discussion of the various factors impacting the decision. The show of hands was ostensibly an attempt to suss out whether the arguments had proven compelling enough to push forward with one codec over the other. Sadly, the form of the question, when combined with the method of measurement, precluded doing so. I'm not claiming that there was consensus in the room. I'm claiming that its presence would not have been detected by the methodology employed. Consider: if everyone in the room raised their hand for both options, Richard would have been compelled to call it "no consensus" even though that result would logically mean that no one objects to either option. Clearly, that didn't happen. On the other hand, what *did* happen was that we had roughly 50% of the room say that they were willing to live with H.264, and roughly 30% of the room say they were willing to live with VP8. This, after the chairs *strongly* *encouraged* people who could live with either option to raise their hands for both options. We didn't explicitly ask for who was in both camps (and those people at the front of the room facing the participants did nothing to gauge overlap), nor did we try to suss out who was abstaining by not raising their hand. As a result, the numbers are meaningless. On one extreme: If those sets of people were completely disjoint, then we're nowhere near consensus. At the other extreme: if the set of people who could accept VP8 were a strict subset of the set of people who could accept H.264, then we would have obvious consensus and could move forward. I know that neither of these scenarios are true, but measuring where the participants fell in that continuum would have been the true measure of the sense of the room. So, sadly, we learned nothing. For the record, and I'm hoping others will follow suit (since, as you pointed out, consensus is measured on the list): I'm of the opinion that either of the two options on the table are acceptable[1][2]. /a ___ [1] I recognize that approaches other than H.264 and VP8 have been casually mentioned on-list; but, if an approach is so unpopular that it hasn't yet found a proponent willing to spend the meager amount of time necessary to type up and submit an internet draft advocating it, then I have to assume that its chances of reaching critical mass are approximately zero. I will not waste my time or yours favoring or rebutting them until someone gets serious about them. [2] Ironically, I'm somewhat regretting that I indicated this in the room: I was trying to be accommodating to both positions, and I know several other people who did the same. Had the indications of support been more partisan, it's possible that one of the two camps would have been revealed to be in the rough. From dabenham@gmail.com Fri Nov 8 08:14:12 2013 Return-Path: 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 EBB6721E80DD for ; Fri, 8 Nov 2013 08:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fvfVquomeSK7 for ; Fri, 8 Nov 2013 08:14:12 -0800 (PST) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CC66921E80B9 for ; Fri, 8 Nov 2013 08:14:11 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id c13so1125249eek.34 for ; Fri, 08 Nov 2013 08:14:10 -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=8b4UqntgDIOAFYshoCndpEOln1Mz7VG6WscFVNXBqZs=; b=B+aHwEtjNR7kDKM75OmqT1A3gxJgnSIAlg9ixGmV7/ysNOx6Zm9CQ9RMCVA+9RGznY Ks3/87o1zydlTObcpBE5DM6VMYrmsSA57LvWlXbGGNdUPogTOI2r01Z19+Uekq1kVV2p GyPD8em54s3hdt5ubSrTvcRp1CDv+kNknDa35adTrgWas1NhlU85VGGsMbnrP4xmzpre +XDCE4F5q/nCdelawRtrdouWefcaqlElTBKd55OkZQEe/5Z22qLRsMgO3qA+Gsm6V7ST GmOxga6Oo61ahw39MNiUzcfakW4e7OrppHzCg9CAcwxzp1RpwvgbO1yqt/5WWy3s33Pj S0Nw== MIME-Version: 1.0 X-Received: by 10.15.61.66 with SMTP id h42mr3499469eex.62.1383927250341; Fri, 08 Nov 2013 08:14:10 -0800 (PST) Received: by 10.15.75.1 with HTTP; Fri, 8 Nov 2013 08:14:10 -0800 (PST) In-Reply-To: <87bo1vbekd.fsf@mid.deneb.enyo.de> References: <87bo1vbekd.fsf@mid.deneb.enyo.de> Date: Fri, 8 Nov 2013 08:14:10 -0800 Message-ID: From: David Benham To: Florian Weimer Content-Type: multipart/alternative; boundary=089e016356b427090b04eaacac92 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Current H.264 licensing practice X-BeenThere: rtcweb@ietf.org 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:14:13 -0000 --089e016356b427090b04eaacac92 Content-Type: text/plain; charset=ISO-8859-1 That's not how most anti-trust friendly patent pools work; certainly not this MPEG-LA one. The T&Cs are what they are and related royalty liabilities, if any, are what they are. They do not change at the whim of a single, major patent owner; instead several dozen must agree. Thus, its very difficult change them, providing lots of stability -- to look at the bright side -- and that makes the summary document you dismissed nearly timeless. The T&Cs and royalty liabilities do not change per licensee (ergo, not negotiated) . They are not dependent on bandwidth rates either. In this case, the licensors also bound themselves to be unable increase royalties by more than 10% every five years (...suspect Cisco can handle that). Providers of on-demand titles and/or broadcast TV over the Internet with greater than 100K subscribers and remuneration (aka, subscription or ad revenue) are the only service providers with royalty liabilities. If still unconvinced, ask for the full license doc and/or call MPEG-LA to seek further clarity. Otherwise, let's wait for the Cisco binary license vs extrapolating from a EULA. On Thu, Nov 7, 2013 at 10:19 PM, Florian Weimer wrote: > * David Benham: > > > Extrapolating from an EULA what one's rtcweb dev/distribution license > > rights is likely way off base. > > I disagree, considering the broad overlap between EULAs from different > vendors and very different product categories. > > > You can read the MPEG-LA's FAQ here ... > > http://www.mpegla.com/main/programs/AVC/Documents/AVC_TermsSummary.pdf > > Note the graphic and text for "(b) sublicenses" on pages 2 and 3. > > That document seems to date from 2004 or 2005, despite the metadata > timestamp. The Internet was quite different then. Internet video > conferencing existed, but was difficult to get to work. Mobile > Internet used EDGE, with bandwidths less 500 kbps. > > > The commercial royalties described are targeted at Service Providers of > > on-demand titles and/or broadcast TV over the Internet with greater 100K > > subscribers and great remuneration (aka, subscription or ad revenue). > > Think the likes of Netflix, Amazon Prime, etc, using the video tag and > > *not* the support-desk in your example or commercial, real-time > > communications. > > Uhm, that's not how patent licensing works. You need a license even > if the patent owner has no ready-made offering that fits your > particular needs. > --089e016356b427090b04eaacac92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That's not how most anti-trust friendly patent po= ols work; certainly not this MPEG-LA one. =A0=A0The T&Cs are what they = are and related royalty liabilities, if any, are what they are. =A0 They do= not change at the whim of a single, major patent owner; instead several do= zen must agree. =A0Thus, its very difficult change them, providing lots of = stability -- to look at the bright side -- and that makes the summary docum= ent you dismissed nearly timeless. =A0

The T&Cs and royalty liabilities do not change per = licensee=A0(ergo, not negotiated)=A0. =A0 They are not dependent on bandwid= th rates either. =A0 In this case, the licensors also bound themselves to b= e unable increase royalties by more than 10% every five years (...suspect C= isco can handle that). =A0 =A0Providers of=A0on-demand title= s and/or broadcast TV over the Internet with greater than 100K=A0subscribers and remuneration (aka, subscription or ad revenue) are the onl= y service providers with=A0royalty liabilities. =A0 If still unconvi= nced, ask for the full license doc and/or call=A0MPEG-LA=A0to seek further = clarity. =A0

Otherwise, let's wait for the Cisco binary license = vs extrapolating from a EULA.



On Thu, Nov 7, 2013 at 10:19 PM, Floria= n Weimer <fw@deneb.enyo.de> wrote:
* David Benham:

> Extrapolating from an EULA what one's rtcweb dev/distribution lice= nse
> rights is likely way off base.

I disagree, considering the broad overlap between EULAs from differen= t
vendors and very different product categories.

> You can read the MPEG-LA's FAQ here ...
> http://www.mpegla.com/main/programs/AVC/Docu= ments/AVC_TermsSummary.pdf
> Note the graphic and text for "(b) sublicenses" on pages 2 a= nd 3.

That document seems to date from 2004 or 2005, despite the metadata timestamp. =A0The Internet was quite different then. =A0Internet video
conferencing existed, but was difficult to get to work. =A0Mobile
Internet used EDGE, with bandwidths less 500 kbps.

> The commercial royalties described are targeted at Service Providers o= f
> on-demand titles and/or broadcast TV over the Internet with greater 10= 0K
> subscribers and great remuneration (aka, subscription or ad revenue).<= br> > Think the likes of Netflix, Amazon Prime, etc, using the video tag and=
> *not* the support-desk in your example or commercial, real-time
> communications.

Uhm, that's not how patent licensing works. =A0You need a license= even
if the patent owner has no ready-made offering that fits your
particular needs.

--089e016356b427090b04eaacac92-- From lgeyser@gmail.com Fri Nov 8 08:32:46 2013 Return-Path: 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 ; 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 ; 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 ; Fri, 8 Nov 2013 08:32:44 -0800 (PST) Received: by mail-lb0-f174.google.com 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; 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: <527C38FF.6040000@nostrum.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: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7b343ef284682704eaacee96 Cc: Tim Panton 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 16:32:46 -0000 --047d7b343ef284682704eaacee96 Content-Type: text/plain; charset=ISO-8859-1 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 > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b343ef284682704eaacee96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Does a draft need to be created to propose H.261 as M= TI?
MPEG-1 Part 2 might also be an option.


On 8 November 2013 17:56, c= owwoc <cowwoc@bbs.darktech.org> wrote:
=20 =20 =20
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 =3D transcoding). Given that choice, I'd rather inconvenien= ce 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=A0
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.=A0
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


--047d7b343ef284682704eaacee96-- From thp@westhawk.co.uk Fri Nov 8 03:34:08 2013 Return-Path: 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 BBAA221E80C6 for ; Fri, 8 Nov 2013 03:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] 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 oXS08kbEuvDz for ; Fri, 8 Nov 2013 03:34:04 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 6A58421E80BE for ; Fri, 8 Nov 2013 03:34:02 -0800 (PST) Received: (qmail 4714 invoked from network); 8 Nov 2013 11:34:01 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 4701 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 8 Nov 2013 11:34:01 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id EB9EC18A0B00; Fri, 8 Nov 2013 11:34:00 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id A733E18A0123; Fri, 8 Nov 2013 11:34:00 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A415A316-3436-4581-855F-029C6751A3A0" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Panton In-Reply-To: <527C7CFE.4080700@bbs.darktech.org> Date: Fri, 8 Nov 2013 11:31:33 +0000 Message-Id: <1E0D9A14-E629-4CB2-AC67-5860B24DB7D7@westhawk.co.uk> References: <527C38FF.6040000@nostrum.com> <527C7CFE.4080700@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Fri, 08 Nov 2013 08:53:56 -0800 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 vs No MTI (was: Alternative consensus and MTI video codecs) X-BeenThere: rtcweb@ietf.org 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 11:34:08 -0000 --Apple-Mail=_A415A316-3436-4581-855F-029C6751A3A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 8 Nov 2013, at 05:56, cowwoc wrote: >=20 > I'll bring up a related point that I brought up a few days ago (I = changed to subject to avoid hijacking the thread). >=20 > 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: > 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? >=20 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.=20 The browser makers have to support and test 2 codecs - one of which they = don't want anyone to use. 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. 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. 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. 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=20 user experience at the same time. Sorry to be so negative.=20 I'll try and come up with a more positive solution next :-) T. > Gili > On 07/11/2013 9:22 PM, Gregory Maxwell wrote: >> On Thu, Nov 7, 2013 at 5:06 PM, Adam Roach wrote: >>> Our situation is radically different: there are a number of actual = arguments >>> to be made for both options. >> We've heard these arguments, at long length, and have, apparently, = not >> found them sufficiently decisive or we wouldn't be at this juncture. >>=20 >> I must have failed to make the point I was attempting to make >> sufficiently clear. Let me retry: If we believe that an MTI video >> codec, regardless of what it is, was an independently important thing >> to have then "no MTI" shouldn't be the result of failing to achieve = an >> MTI in discussion, because there exist _an option_, any option, to >> achieve a MTI video codec. So I was hoping to see any support for = "no >> MTI" (which sounded very popular in the room) to come with arguments >> for why an MTI doesn't actually matter. >>=20 >> Without intending any "push", strong or otherwise, I'll point out = that >> the apparent difficulty in responding to my message without >> allegations of irrational arguments and emotional investments >> increases my estimation that locating a set of "randomly selected >> neutral parties" which is sufficiently non-partisan to not cloud the >> process is not obviously possible. Without that kind of doubt in = mind >> it's not clear to me if that alternative process could be successful, >> which is why I attempted to illustrate my point with the 4.4 = coinflip. >> Coinflip will produce a result, and the result it will produce will >> achieve the goal of selecting an MTI codec (especially in >> consideration of substantial support for either option, both on the = list >> and in the room), and it doesn't require selecting non-partisan >> parties. I wasn't trying to say it was _good_ though, only that it >> was enough to say failure to pick an MTI alone isn't enough to = justify >> removing MTI for the sake of MTI from the goals. >>=20 >> (There are plenty of other arguments that can be made about the >> non-optimality of the 3929 panel process=97 e.g. the requirement to = meet >> nomcom requirements with physical meeting attendance would generally >> make it easy for large corporate contributors, especially ones with >> diverse participation, to be over represented. But, to be frank, your >> response has made me feel uncomfortable pointing that much out... I >> didn't start this thread with an intention to argue against it, but I >> wonder after your message if anyone else would dare.) >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_A415A316-3436-4581-855F-029C6751A3A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 8 Nov 2013, at = 05:56, cowwoc <cowwoc@bbs.darktech.org> = wrote:

=20 =20

I'll bring up a related point that I brought up a few days ago (I changed to subject to avoid hijacking the thread).

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

The browser makers have to = support and test 2 codecs - one of which they don't want anyone to = use.

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.

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.

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.

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.

Sorry to be so = negative. 
I'll try and come up with a more positive = solution next = :-)

T.


Gili

On 07/11/2013 9:22 PM, Gregory Maxwell wrote:
On Thu, Nov 7, 2013 at 5:06 PM, Adam Roach <adam@nostrum.com> wrote:

Our situation is radically different: there are a =
number of actual arguments
to be made for both options.

We've heard these arguments, at long length, and =
have, apparently, not
found them sufficiently decisive or we wouldn't be at this juncture.

I must have failed to make the point I was attempting to make
sufficiently clear.  Let me retry: If we believe that an MTI video
codec, regardless of what it is, was an independently important thing
to have then "no MTI" shouldn't be the result of failing to achieve an
MTI in discussion, because there exist _an option_, any option, to
achieve a MTI video codec.  So I was hoping to see any support for "no
MTI" (which sounded very popular in the room) to come with arguments
for why an MTI doesn't actually matter.

Without intending any "push", strong or otherwise, I'll point out that
the apparent difficulty in responding to my message without
allegations of irrational arguments and emotional investments
increases my estimation that locating a set of "randomly selected
neutral parties" which is sufficiently non-partisan to not cloud the
process is not obviously possible.  Without that kind of doubt in mind
it's not clear to me if that alternative process could be successful,
which is why I attempted to illustrate my point with the 4.4 coinflip.
Coinflip will produce a result, and the result it will produce will
achieve the goal of selecting an MTI codec (especially in
consideration of substantial support for either option, both on the list
and in the room), and it doesn't require selecting non-partisan
parties.  I wasn't trying to say it was _good_ though, only that it
was enough to say failure to pick an MTI alone isn't enough to justify
removing MTI for the sake of MTI from the goals.

(There are plenty of other arguments that can be made about the
non-optimality of the 3929 panel process=97 e.g. the requirement to meet
nomcom requirements with physical meeting attendance would generally
make it easy for large corporate contributors, especially ones with
diverse participation, to be over represented. But, to be frank, your
response has made me feel uncomfortable pointing that much out... I
didn't start this thread with an intention to argue against it, but I
wonder after your message if anyone else would dare.)
_______________________________________________
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

Tim Panton - Web/VoIP = consultant and implementor



= --Apple-Mail=_A415A316-3436-4581-855F-029C6751A3A0-- From thp@westhawk.co.uk Fri Nov 8 03:36:22 2013 Return-Path: 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 C6BA411E8109 for ; Fri, 8 Nov 2013 03:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] 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 hfbL8Ha3H-LN for ; Fri, 8 Nov 2013 03:36:16 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF2C21E80BE for ; Fri, 8 Nov 2013 03:36:11 -0800 (PST) Received: (qmail 36064 invoked from network); 8 Nov 2013 11:36:10 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 4735 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 8 Nov 2013 11:36:10 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 6785618A0B00; Fri, 8 Nov 2013 11:36:10 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 234C118A0123; Fri, 8 Nov 2013 11:36:10 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_5A5715C6-75E1-4775-8FD0-7DD4CE06EE40" From: Tim Panton Resent-Cc: cowwoc Resent-From: Tim Panton In-Reply-To: <527C7CFE.4080700@bbs.darktech.org> Date: Fri, 8 Nov 2013 11:31:33 +0000 Resent-Date: Fri, 8 Nov 2013 11:33:43 +0000 Resent-To: rtcweb@ietf.org References: <527C38FF.6040000@nostrum.com> <527C7CFE.4080700@bbs.darktech.org> Message-Id: <1E0D9A14-E629-4CB2-AC67-5860B24DB7D7@westhawk.co.uk> To: cowwoc X-Mailer: Apple Mail (2.1816) Resent-Message-Id: <20131108113610.234C118A0123@zimbra003.verygoodemail.com> X-Mailman-Approved-At: Fri, 08 Nov 2013 08:53:56 -0800 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] H.261 vs No MTI (was: Alternative consensus and MTI video codecs) X-BeenThere: rtcweb@ietf.org 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 11:36:22 -0000 --Apple-Mail=_5A5715C6-75E1-4775-8FD0-7DD4CE06EE40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 8 Nov 2013, at 05:56, cowwoc wrote: >=20 > I'll bring up a related point that I brought up a few days ago (I = changed to subject to avoid hijacking the thread). >=20 > 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: > 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? >=20 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.=20 The browser makers have to support and test 2 codecs - one of which they = don't want anyone to use. 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. 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. 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. 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=20 user experience at the same time. Sorry to be so negative.=20 I'll try and come up with a more positive solution next :-) T. >=20 > Gili > On 07/11/2013 9:22 PM, Gregory Maxwell wrote: >> On Thu, Nov 7, 2013 at 5:06 PM, Adam Roach wrote: >>> Our situation is radically different: there are a number of actual = arguments >>> to be made for both options. >> We've heard these arguments, at long length, and have, apparently, = not >> found them sufficiently decisive or we wouldn't be at this juncture. >>=20 >> I must have failed to make the point I was attempting to make >> sufficiently clear. Let me retry: If we believe that an MTI video >> codec, regardless of what it is, was an independently important thing >> to have then "no MTI" shouldn't be the result of failing to achieve = an >> MTI in discussion, because there exist _an option_, any option, to >> achieve a MTI video codec. So I was hoping to see any support for = "no >> MTI" (which sounded very popular in the room) to come with arguments >> for why an MTI doesn't actually matter. >>=20 >> Without intending any "push", strong or otherwise, I'll point out = that >> the apparent difficulty in responding to my message without >> allegations of irrational arguments and emotional investments >> increases my estimation that locating a set of "randomly selected >> neutral parties" which is sufficiently non-partisan to not cloud the >> process is not obviously possible. Without that kind of doubt in = mind >> it's not clear to me if that alternative process could be successful, >> which is why I attempted to illustrate my point with the 4.4 = coinflip. >> Coinflip will produce a result, and the result it will produce will >> achieve the goal of selecting an MTI codec (especially in >> consideration of substantial support for either option, both on the = list >> and in the room), and it doesn't require selecting non-partisan >> parties. I wasn't trying to say it was _good_ though, only that it >> was enough to say failure to pick an MTI alone isn't enough to = justify >> removing MTI for the sake of MTI from the goals. >>=20 >> (There are plenty of other arguments that can be made about the >> non-optimality of the 3929 panel process=97 e.g. the requirement to = meet >> nomcom requirements with physical meeting attendance would generally >> make it easy for large corporate contributors, especially ones with >> diverse participation, to be over represented. But, to be frank, your >> response has made me feel uncomfortable pointing that much out... I >> didn't start this thread with an intention to argue against it, but I >> wonder after your message if anyone else would dare.) >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_5A5715C6-75E1-4775-8FD0-7DD4CE06EE40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On 8 Nov 2013, at 05:56, cowwoc <cowwoc@bbs.darktech.org> = wrote:

=20 =20

I'll bring up a related point that I brought up a few days ago (I changed to subject to avoid hijacking the thread).

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

The browser makers have to = support and test 2 codecs - one of which they don't want anyone to = use.

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.

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.

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.

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.

Sorry to be so = negative. 
I'll try and come up with a more positive = solution next = :-)

T.



Gili

On 07/11/2013 9:22 PM, Gregory Maxwell wrote:
On Thu, Nov 7, 2013 at 5:06 PM, Adam Roach <adam@nostrum.com> wrote:

Our situation is radically different: there are a =
number of actual arguments
to be made for both options.

We've heard these arguments, at long length, and =
have, apparently, not
found them sufficiently decisive or we wouldn't be at this juncture.

I must have failed to make the point I was attempting to make
sufficiently clear.  Let me retry: If we believe that an MTI video
codec, regardless of what it is, was an independently important thing
to have then "no MTI" shouldn't be the result of failing to achieve an
MTI in discussion, because there exist _an option_, any option, to
achieve a MTI video codec.  So I was hoping to see any support for "no
MTI" (which sounded very popular in the room) to come with arguments
for why an MTI doesn't actually matter.

Without intending any "push", strong or otherwise, I'll point out that
the apparent difficulty in responding to my message without
allegations of irrational arguments and emotional investments
increases my estimation that locating a set of "randomly selected
neutral parties" which is sufficiently non-partisan to not cloud the
process is not obviously possible.  Without that kind of doubt in mind
it's not clear to me if that alternative process could be successful,
which is why I attempted to illustrate my point with the 4.4 coinflip.
Coinflip will produce a result, and the result it will produce will
achieve the goal of selecting an MTI codec (especially in
consideration of substantial support for either option, both on the list
and in the room), and it doesn't require selecting non-partisan
parties.  I wasn't trying to say it was _good_ though, only that it
was enough to say failure to pick an MTI alone isn't enough to justify
removing MTI for the sake of MTI from the goals.

(There are plenty of other arguments that can be made about the
non-optimality of the 3929 panel process=97 e.g. the requirement to meet
nomcom requirements with physical meeting attendance would generally
make it easy for large corporate contributors, especially ones with
diverse participation, to be over represented. But, to be frank, your
response has made me feel uncomfortable pointing that much out... I
didn't start this thread with an intention to argue against it, but I
wonder after your message if anyone else would dare.)
_______________________________________________
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

Tim Panton - Web/VoIP consultant and implementor

<= /div>

= --Apple-Mail=_5A5715C6-75E1-4775-8FD0-7DD4CE06EE40-- From thp@westhawk.co.uk Fri Nov 8 08:10:55 2013 Return-Path: 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 36D3F21E80B9 for ; Fri, 8 Nov 2013 08:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599] 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 jJiW7Fz2qSzI for ; Fri, 8 Nov 2013 08:10:49 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFEE21E8121 for ; Fri, 8 Nov 2013 08:10:43 -0800 (PST) Received: (qmail 38611 invoked from network); 8 Nov 2013 16:10:42 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10027 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 8 Nov 2013 16:10:42 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 0466518A0A9D; Fri, 8 Nov 2013 16:10:42 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id C46F618A02A0; Fri, 8 Nov 2013 16:10:41 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Panton In-Reply-To: <527D09CA.1060703@bbs.darktech.org> Date: Fri, 8 Nov 2013 16:08:06 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <527C38FF.6040000@nostrum.com> <527C7CFE.4080700@bbs.darktech.org> <1E0D9A14-E629-4CB2-AC67-5860B24DB7D7@westhawk.co.uk> <527D09CA.1060703@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Fri, 08 Nov 2013 08:53:56 -0800 Cc: rtcweb@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 16:10:55 -0000 On 8 Nov 2013, at 15:56, cowwoc wrote: > Hi Tim, >=20 >> 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. >=20 > 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. And that's the key difference between us, and where I changed my mind. = It isn't H261 vs nothing, it is H261 vs flash.=20 I do not want to be in a position where people can legitimately say of = an webRTC browser "it's better if you use flash". Also, more options =3D=3D bad thing. It means more testing, more crufty = code, more errors. The final point against H261 is that it really isn't going to work well = in 3g networks or 'edge of wifi' environments with=20 constrained and lossy networks. That's where the growth is.=20 T. Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk From thp@westhawk.co.uk Fri Nov 8 08:27:35 2013 Return-Path: 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 BDC1621E813B for ; Fri, 8 Nov 2013 08:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=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 Q0vNTux5bkBL for ; Fri, 8 Nov 2013 08:27:30 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 2A93111E8102 for ; Fri, 8 Nov 2013 08:27:30 -0800 (PST) Received: (qmail 51710 invoked from network); 8 Nov 2013 16:27:29 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10323 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 8 Nov 2013 16:27:29 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 08AB118A059E; Fri, 8 Nov 2013 16:27:29 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id AD12C18A043B; Fri, 8 Nov 2013 16:27:28 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_77DCE391-15F6-4937-8505-478BFB683EF4" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Panton new In-Reply-To: Date: Fri, 8 Nov 2013 16:24:53 +0000 Message-Id: <499F0875-C562-4B44-A55D-2691C96C9489@westhawk.co.uk> References: <87bo1vbekd.fsf@mid.deneb.enyo.de> To: David Benham X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Fri, 08 Nov 2013 08:53:56 -0800 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Current H.264 licensing practice X-BeenThere: rtcweb@ietf.org 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:27:35 -0000 --Apple-Mail=_77DCE391-15F6-4937-8505-478BFB683EF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 8 Nov 2013, at 16:14, David Benham wrote: > That's not how most anti-trust friendly patent pools work; certainly = not this MPEG-LA one. The T&Cs are what they are and related royalty = liabilities, if any, are what they are. They do not change at the whim = of a single, major patent owner; instead several dozen must agree. = Thus, its very difficult change them, providing lots of stability -- to = look at the bright side -- and that makes the summary document you = dismissed nearly timeless. =20 >=20 > The T&Cs and royalty liabilities do not change per licensee (ergo, not = negotiated) . They are not dependent on bandwidth rates either. In = this case, the licensors also bound themselves to be unable increase = royalties by more than 10% every five years (...suspect Cisco can handle = that). Providers of on-demand titles and/or broadcast TV over the = Internet with greater than 100K subscribers and remuneration (aka, = subscription or ad revenue) are the only service providers with royalty = liabilities. If still unconvinced, ask for the full license doc and/or = call MPEG-LA to seek further clarity. =20 >=20 Interesting datapoint on the >100K subscribers front. =46rom Flurry - = (via @BenedictEvans) There are at least 800 app developers with > 1M subscribers. So there seem to me to = be quite a few 'Little guys' who may avoid webRTC if it requires an H264 license .=20 http://blog.flurry.com//bid/102208/the-mobile-content-exlposion --Apple-Mail=_77DCE391-15F6-4937-8505-478BFB683EF4 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 8 Nov 2013, at 16:14, David Benham <dabenham@gmail.com> wrote:

That's not how most anti-trust friendly patent pools work; certainly not this MPEG-LA one.   The T&Cs are what they are and related royalty liabilities, if any, are what they are.   They do not change at the whim of a single, major patent owner; instead several dozen must agree.  Thus, its very difficult change them, providing lots of stability -- to look at the bright side -- and that makes the summary document you dismissed nearly timeless.  

The T&Cs and royalty liabilities do not change per licensee (ergo, not negotiated) .   They are not dependent on bandwidth rates either.   In this case, the licensors also bound themselves to be unable increase royalties by more than 10% every five years (...suspect Cisco can handle that).    Providers of on-demand titles and/or broadcast TV over the Internet with greater than 100K subscribers and remuneration (aka, subscription or ad revenue) are the only service providers with royalty liabilities.   If still unconvinced, ask for the full license doc and/or call MPEG-LA to seek further clarity.  



Interesting datapoint on the >100K subscribers front.  From Flurry - (via @BenedictEvans) There are at
least 800 app developers with > 1M subscribers. So there seem to me to be quite a few 'Little guys' who
may avoid webRTC if it requires an H264 license . 



--Apple-Mail=_77DCE391-15F6-4937-8505-478BFB683EF4-- From thp@westhawk.co.uk Fri Nov 8 08:29:17 2013 Return-Path: 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 4C77F21E812D for ; Fri, 8 Nov 2013 08:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HTML_MESSAGE=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 uK0ivaXXPOxi for ; Fri, 8 Nov 2013 08:29:12 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id B434F11E8102 for ; Fri, 8 Nov 2013 08:29:11 -0800 (PST) Received: (qmail 52837 invoked from network); 8 Nov 2013 16:29:10 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10352 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 8 Nov 2013 16:29:10 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id A9E9D18A0608 for ; Fri, 8 Nov 2013 16:29:10 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 86C9618A059E for ; Fri, 8 Nov 2013 16:29:10 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_5DD877A9-2D93-4E84-80DC-E53AB082673C" From: Tim Panton new In-Reply-To: Resent-From: Tim Panton new Date: Fri, 8 Nov 2013 16:24:53 +0000 Resent-Date: Fri, 8 Nov 2013 16:26:35 +0000 Message-Id: <499F0875-C562-4B44-A55D-2691C96C9489@westhawk.co.uk> References: <87bo1vbekd.fsf@mid.deneb.enyo.de> Resent-To: rtcweb@ietf.org To: David Benham X-Mailer: Apple Mail (2.1816) Resent-Message-Id: <20131108162910.86C9618A059E@zimbra003.verygoodemail.com> X-Mailman-Approved-At: Fri, 08 Nov 2013 08:53:56 -0800 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Current H.264 licensing practice X-BeenThere: rtcweb@ietf.org 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:29:17 -0000 --Apple-Mail=_5DD877A9-2D93-4E84-80DC-E53AB082673C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 8 Nov 2013, at 16:14, David Benham wrote: > That's not how most anti-trust friendly patent pools work; certainly = not this MPEG-LA one. The T&Cs are what they are and related royalty = liabilities, if any, are what they are. They do not change at the whim = of a single, major patent owner; instead several dozen must agree. = Thus, its very difficult change them, providing lots of stability -- to = look at the bright side -- and that makes the summary document you = dismissed nearly timeless. =20 >=20 > The T&Cs and royalty liabilities do not change per licensee (ergo, not = negotiated) . They are not dependent on bandwidth rates either. In = this case, the licensors also bound themselves to be unable increase = royalties by more than 10% every five years (...suspect Cisco can handle = that). Providers of on-demand titles and/or broadcast TV over the = Internet with greater than 100K subscribers and remuneration (aka, = subscription or ad revenue) are the only service providers with royalty = liabilities. If still unconvinced, ask for the full license doc and/or = call MPEG-LA to seek further clarity. =20 >=20 Interesting datapoint on the >100K subscribers front. =46rom Flurry - = (via @BenedictEvans) There are at least 800 app developers with > 1M subscribers. So there seem to me to = be quite a few 'Little guys' who may avoid webRTC if it requires an H264 license .=20 http://blog.flurry.com//bid/102208/the-mobile-content-exlposion --Apple-Mail=_5DD877A9-2D93-4E84-80DC-E53AB082673C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On 8 Nov 2013, at 16:14, David Benham = <dabenham@gmail.com> = wrote:

That's not how most anti-trust = friendly patent pools work; certainly not this MPEG-LA one. =   The T&Cs are what they are and related royalty = liabilities, if any, are what they are.   They do not change at the = whim of a single, major patent owner; instead several dozen must agree. =  Thus, its very difficult change them, providing lots of stability = -- to look at the bright side -- and that makes the summary document you = dismissed nearly timeless.  

The T&Cs and royalty liabilities do not change = per licensee (ergo, not negotiated) .   They are not = dependent on bandwidth rates either.   In this case, the licensors = also bound themselves to be unable increase royalties by more than 10% = every five years (...suspect Cisco can handle that).    P= roviders of o= n-demand titles and/or broadcast TV over the Internet with greater than = 100K s= ubscribers and remuneration (aka, subscription or ad revenue) are the = only service providers with royalty liabilities.   If = still unconvinced, ask for the full license doc and/or = call MPEG-LA to seek further clarity.  
=



Inter= esting datapoint on the >100K subscribers front.  =46rom Flurry = - (via @BenedictEvans) There are at
least 800 app developers = with > 1M subscribers. So there seem to me to be quite a few 'Little = guys' who
may avoid webRTC if it requires an H264 license = . 



= --Apple-Mail=_5DD877A9-2D93-4E84-80DC-E53AB082673C-- From lgeyser@gmail.com Fri Nov 8 09:05:21 2013 Return-Path: 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 704ED11E8168 for ; Fri, 8 Nov 2013 09:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3Axy-B9t1Fby for ; Fri, 8 Nov 2013 09:05:20 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 23CB211E80DC for ; Fri, 8 Nov 2013 09:05:19 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id y6so1702245lbh.11 for ; Fri, 08 Nov 2013 09:05:19 -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=lBCaaEdDLqVh28TqyxjpiU22ETxW0S1pABM8g2Ls1UU=; b=KM+Alk7BYcStCLi5zVttaYe/5XdOKiStRALSdwJy/DQfx2h9Rzae2kBE0d0V0Ii3wv 9mbYUw4Fpt1FEQ9JzlGxbFbaOv/dGtcTLoOkWAvzR89ohvDmGTBxiSepqnklkzuFQKs2 680F2Pl0NoCoxl5zUxqKjd3GclpZFsowijh1CYUfDhgGXL+OyGXyNSqBjfnU5+RZbsNm EwhbUWKbOfQqY1iub2J25MPtBOSe9P6X93rwh96ctCYghr+Jcpdfy68jyq8BMxBmhxns kjAC0e1jaDEAWdxS9LpwBAYE0JHRrNkRTQRdJotev4IjRju2g0UsPrVpDRFrGfMrBfb5 76Uw== MIME-Version: 1.0 X-Received: by 10.152.140.7 with SMTP id rc7mr11825743lab.12.1383930318937; Fri, 08 Nov 2013 09:05:18 -0800 (PST) Received: by 10.114.168.70 with HTTP; Fri, 8 Nov 2013 09:05:18 -0800 (PST) In-Reply-To: References: <527C38FF.6040000@nostrum.com> <527C7CFE.4080700@bbs.darktech.org> <1E0D9A14-E629-4CB2-AC67-5860B24DB7D7@westhawk.co.uk> <527D09CA.1060703@bbs.darktech.org> Date: Fri, 8 Nov 2013 19:05:18 +0200 Message-ID: From: Leon Geyser To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113467da0de47d04eaad63ba Cc: Tim Panton 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 17:05:21 -0000 --001a113467da0de47d04eaad63ba Content-Type: text/plain; charset=ISO-8859-1 Hi Tim, So the question is in the small likelihood that VP8/H.264 can't be negotiated and there is no transcoding in-between, is it better to show no video than some video? >>The final point against H261 is that it really isn't going to work well in 3g networks or 'edge of wifi' environments with >>constrained and lossy networks. That's where the growth is. How does dropping frames on H.264/VP8 differ from dropping frames on H.261? Hope it isn't a dumb question. On 8 November 2013 18:08, Tim Panton wrote: > > On 8 Nov 2013, at 15:56, cowwoc wrote: > > > Hi Tim, > > > >> 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. > > > And that's the key difference between us, and where I changed my mind. It > isn't H261 vs nothing, it is H261 vs flash. > I do not want to be in a position where people can legitimately say of an > webRTC browser "it's better if you use flash". > Also, more options == bad thing. It means more testing, more crufty code, > more errors. > > The final point against H261 is that it really isn't going to work well in > 3g networks or 'edge of wifi' environments with > constrained and lossy networks. That's where the growth is. > T. > > > Tim Panton - Web/VoIP consultant and implementor > www.westhawk.co.uk > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113467da0de47d04eaad63ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tim,

So the question is in the s= mall likelihood that VP8/H.264 can't be negotiated and there is no tran= scoding in-between, is it better to show no video than some video?

>>The final point against H261 is that it really isn't g= oing to work well in 3g networks or 'edge of wifi' environments wit= h
>>constrained and lossy networks. That's where the growth is.
=
How does dropping frames on H.264/VP8 differ from dropping frames on = H.261? Hope it isn't a dumb question.



On 8 November 2013 18:08, Tim Panton <= thp@westhawk.co.uk> wrote:

On 8 Nov 2013, at 15:56, cowwoc <cowwoc@bbs.darktech.org> wrote:

> Hi Tim,
>
>> The user gets a totally variable experienc= e based on factors she cant control. There will be lots of dissatisfied use= rs who's
>> first video call happened to be h261 and never go back to the serv= ice - 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 turn= s 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 transcodi= ng. Mandating H.261 as MTI just gives them an extra option they normally wo= uldn't have.


And that's the key difference between us, and where I changed my = mind. It isn't H261 vs nothing, it is H261 vs flash.
I do not want to be in a position where people can legitimately say of an w= ebRTC browser "it's better if you use flash".
Also, more options =3D=3D bad thing. It means more testing, more crufty cod= e, more errors.

The final point against H261 is that it really isn't going to work well= in 3g networks or 'edge of wifi' environments with
constrained and lossy networks. That's where the growth is.
T.


Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk<= /a>



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a113467da0de47d04eaad63ba-- From cb.list6@gmail.com Fri Nov 8 09:25:30 2013 Return-Path: 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 2651711E81A6 for ; Fri, 8 Nov 2013 09:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 Jf5PQCoLc5xn for ; Fri, 8 Nov 2013 09:25:29 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id C615E11E80DC for ; Fri, 8 Nov 2013 09:25:28 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id q59so2327269wes.9 for ; Fri, 08 Nov 2013 09:25:28 -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=NkHztJmR3v6NmMovLH7RC4BCmgMyh03bQXKXl9s/F2I=; b=VF+u96tbe3gInKf5xLe7ZAweTH4y11clqEaXgyb+Bjq6uCi1qOCuQT77nKgCOsgBxM zYPrLEcS2dfiITS9Ptxjlu/yD5CT9CfWpX9GE6P7Ao296U/WsiW8zQjR5r4zKzhsFlUI ImdIbHXMbPCLL8koQjhemLG2Xp2GCx9m3Z9CZHQ3RLZBf1qopDpMHsdlJPXXIiIJsnFc X9mHfH/HFsl35SBPn/QPlHyrINycxBDEE2qQc5EpAnnqULZKdsX3k6JnzXmcRTXRM4mg 8AkKWmTIzynOe2rMQEqUPCWoxydHqtwuUdaCCCjxVl+QaVWYjfgDqDSxWIYj6b/R9aOz htvA== MIME-Version: 1.0 X-Received: by 10.180.79.163 with SMTP id k3mr686716wix.34.1383931527923; Fri, 08 Nov 2013 09:25:27 -0800 (PST) Received: by 10.216.99.68 with HTTP; Fri, 8 Nov 2013 09:25:27 -0800 (PST) Received: by 10.216.99.68 with HTTP; Fri, 8 Nov 2013 09:25:27 -0800 (PST) In-Reply-To: <527D09CA.1060703@bbs.darktech.org> References: <527C38FF.6040000@nostrum.com> <527C7CFE.4080700@bbs.darktech.org> <1E0D9A14-E629-4CB2-AC67-5860B24DB7D7@westhawk.co.uk> <527D09CA.1060703@bbs.darktech.org> Date: Fri, 8 Nov 2013 09:25:27 -0800 Message-ID: From: "cb.list6" To: cowwoc Content-Type: multipart/alternative; boundary=f46d043d65571d8ffc04eaadab26 Cc: rtcweb@ietf.org, Tim Panton 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 17:25:30 -0000 --f46d043d65571d8ffc04eaadab26 Content-Type: text/plain; charset=ISO-8859-1 On Nov 8, 2013 7:57 AM, "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. > I disagree that "no MTI = transcode" There is no scenario I would permit transcoding as normal mode of operations. If sdp cannot find a common codec, fall back to voice-only. And, at the implementation discretion, offer the user advice about choosing a browser. CB >> 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 > --f46d043d65571d8ffc04eaadab26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 8, 2013 7:57 AM, "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 M= TI" means we're forced to do transcoding, whereas H.261 as MTI mea= ns 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 o= r H.264 as MTI (or both) than H.261... but if worse comes to worse, I don&#= 39;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 Par= is, 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 c= an then simply settle on a codec with expired IPR such as H.261. H.261 is t= he codec everyone loves to hate but allow me to point out the following: >
>
> That's the goal :) Really. Making everyone equally unhappy gives t= hem incentive to compromise to get a better experience.
>
>> The browser makers have to support and test 2 codecs - one of whic= h they don't want anyone to use.
>
>
> It's either that or push the pain onto the application developers = (no MTI =3D transcoding). Given that choice, I'd rather inconvenience a= handful of browser developers over hundreds of thousands of application de= velopers.
>

I disagree that "no MTI =3D transcode"

There is no scenario I would permit transcoding as normal mo= de of operations.=A0 If sdp cannot find a common codec, fall back to voice-= only. And, at the implementation discretion, offer the user advice about ch= oosing a browser.=A0

CB
>> 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 t= ranscode 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 g= oals. And again, we're only talking about the minority case where you&#= 39;re forced to fallback on H.261 (think of it as having to fall back on TU= RN).
>
>> The user gets a totally variable experience based on factors she c= ant control. There will be lots of dissatisfied users who's
>> first video call happened to be h261 and never go back to the serv= ice - 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 turn= s 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 transcodi= ng. Mandating H.261 as MTI just gives them an extra option they normally wo= uldn't have.
>
>> Part of the problem is that O/A + SDP isn't a rich enough medi= um 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=A0
>> 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.2= 64. That's painful, whether or not H.261 is MTI.
>
>> Sorry to be so negative.=A0
>> 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.i= etf.org/mailman/listinfo/rtcweb
>

--f46d043d65571d8ffc04eaadab26-- From bernard_aboba@hotmail.com Fri Nov 8 10:19:37 2013 Return-Path: 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 992E721E81E4 for ; Fri, 8 Nov 2013 10:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.326 X-Spam-Level: X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 Bc0tEDG9JriS for ; Fri, 8 Nov 2013 10:19:24 -0800 (PST) Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by ietfa.amsl.com (Postfix) with ESMTP id 52B3E21E81F7 for ; Fri, 8 Nov 2013 10:19:15 -0800 (PST) Received: from BLU169-W133 ([65.55.116.74]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Nov 2013 10:19:15 -0800 X-TMN: [AeQzeFaD0MQWjgRQMe1GJf0x4U4IgdHB] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_e1846537-4d50-4ad7-9c2a-b43c0e57c557_" From: Bernard Aboba To: "rtcweb@ietf.org" Date: Fri, 8 Nov 2013 10:19:14 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Nov 2013 18:19:15.0426 (UTC) FILETIME=[08239420:01CEDCAF] Subject: Re: [rtcweb] External Review Team X-BeenThere: rtcweb@ietf.org 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 18:19:37 -0000 --_e1846537-4d50-4ad7-9c2a-b43c0e57c557_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adam Roach stated: "I'll make an even stronger statement: I would contend that any strong pus= h against the use of an external review team amounts to a tacit admission = by an individual that the arguments for their preferred position are insuf= ficiently compelling." =20 [BA] If the core issues under consideration were technical=2C I'd agree wit= h you.=20 Unfortunately=2C they aren't. The core issue (as Jonathan ably stated) is = the perceived legal risk. Convening an external review team of IETF partic= ipants to evaluate those legal risks is unlikely to persuade the real audie= nce for those recommendations - lawyers.=20 =20 If the goal is to come up with a compelling legal analysis=2C the expert pa= nel should probably be composed of recognized legal experts. Good luck wit= h recruiting such a panel to work pro-bono.=20 =20 =20 = --_e1846537-4d50-4ad7-9c2a-b43c0e57c557_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Adam =3BRoach stated:
"I'll make an even stronger s=
tatement: I would contend that any strong  push against the use of=
 an external review team amounts to a tacit  admission by an indiv=
idual that the arguments for their preferred  position are insuffi=
ciently compelling."
 =3B
[BA] If the core issu=
es under consideration were technical=2C I'd agree with you. 
U=
nfortunately=2C they aren't. =3B The core issue (as Jonathan ably state=
d) is the perceived legal risk. =3B Convening an external review team o=
f IETF participants to evaluate those legal risks is unlikely to persuade t=
he real audience for those recommendations - lawyers. 
&nb=
sp=3B
If the goal is to come up with a compelling legal analysis=2C =
the expert panel should probably be composed of recognized legal experts.&n=
bsp=3B Good luck with recruiting such a panel to work pro-bono. 
 =3B
 =3B
 		 	   		  

=

--_e1846537-4d50-4ad7-9c2a-b43c0e57c557_--

From Markus.Isomaki@nokia.com  Fri Nov  8 10:34:59 2013
Return-Path: 
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 0942321E80B6 for ; Fri,  8 Nov 2013 10:34:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.537
X-Spam-Level: 
X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062,  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 PzcOtmYZug3h for ; Fri,  8 Nov 2013 10:34:53 -0800 (PST)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id D74C021E8099 for ; Fri,  8 Nov 2013 10:34:52 -0800 (PST)
Received: from smtp.mgd.nokia.com ([65.54.30.58]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA8IPXA5026552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 8 Nov 2013 20:25:34 +0200
Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.204]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.03.0136.001; Fri, 8 Nov 2013 18:25:33 +0000
From: 
To: , , 
Thread-Topic: [rtcweb] On the form of the question (was Re: Alternative consensus and MTI video codecs)
Thread-Index: AQHO3JvVnrC6HW0kwUerUYvWzN0KqZobo5PA
Date: Fri, 8 Nov 2013 18:25:33 +0000
Message-ID: 
References:  <527C38FF.6040000@nostrum.com>	<20131108123109.GF3245@audi.shelbyville.oz> <527D0AC4.1080704@nostrum.com>
In-Reply-To: <527D0AC4.1080704@nostrum.com>
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+/nZJb9Kg7ImIT0MuoH3bWel9UYmYeD2CO9QKMysB+NseUiCP4uOnwBs2OgfA0qNY4YN3qLHYaFtAzWt8WdAfZAMGX4pBUrMMfebaUuMjNKC5ieNCdClpAolGVQTgTts1goOg1ilE+FMn9qryh6mBAbv+Ab6KkQCkW2edkm8l1JCiceL3xNE760DBPknWgH9E5L+IOTgx+s5hNngzYY9EPsF2hpDbwfW2YrxBi+cQjMKXskXJNsF0JQ7EQNyo+gYskXfTvDjQXB7xmdc83r4TINFtCmnNE+VbEarSb0Yjd6tJPMWvNH61G
x-originating-ip: [10.163.35.158]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: Re: [rtcweb] On the form of the question (was Re: Alternative consensus and MTI video codecs)
X-BeenThere: rtcweb@ietf.org
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 18:34:59 -0000

Adam Roach wrote:
>=20
> Sadly, the form of the question, when combined with the method of
> measurement, precluded doing so.
>=20
> I'm not claiming that there was consensus in the room. I'm claiming that =
its
> presence would not have been detected by the methodology employed.
> Consider: if everyone in the room raised their hand for both options, Ric=
hard
> would have been compelled to call it "no consensus" even though that resu=
lt
> would logically mean that no one objects to either option.
>

I agree that was the problem with how the questions were set. It was imposs=
ible to determine how many people were actually OK with either codec, and h=
ow many with just one of them. If we are to repeat the consensus call on th=
e list, we will at least learn the distribution between "H.264 and VP8" vs.=
 "Only H.264" vs. "Only VP8". I would suggest that if either of the "Only X=
" groups is relatively small, we could declare rough consensus.=20
=20
> Clearly, that didn't happen.
>=20
> On the other hand, what *did* happen was that we had roughly 50% of the
> room say that they were willing to live with H.264, and roughly 30% of th=
e
> room say they were willing to live with VP8.=20

Yes, so it would be useful to know what the proportion of those people rais=
ing their hands for just one vs. both options actually was.=20

Markus =20

From Markus.Isomaki@nokia.com  Fri Nov  8 10:43:32 2013
Return-Path: 
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 9B6B011E81C1 for ; Fri,  8 Nov 2013 10:43:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.54
X-Spam-Level: 
X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.058,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bCl6vdvXPaxv for ; Fri,  8 Nov 2013 10:43:24 -0800 (PST)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 46CBC11E8112 for ; Fri,  8 Nov 2013 10:43:11 -0800 (PST)
Received: from smtp.mgd.nokia.com ([65.54.30.48]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA8IeAII003439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 8 Nov 2013 20:40:11 +0200
Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.204]) by 008-AM1MMR1-014.mgdnok.nokia.com ([2002:4136:1e30::4136:1e30]) with mapi id 14.03.0136.001; Fri, 8 Nov 2013 18:40:10 +0000
From: 
To: , 
Thread-Topic: [rtcweb] External Review Team
Thread-Index: AQHO3K8czKhyTFdRgk6Qukv+TTIoBpobpqUQ
Date: Fri, 8 Nov 2013 18:40:09 +0000
Message-ID: 
References: 
In-Reply-To: 
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+/nZJb9Kg7IvXcHqzlA8psn+eKtgKP5mXtpVsfI4l2NjmBVbicsXK9soVNFtNenHuyQBbhnJosOUHPwX24yYi4DetqNwQMMaWsQOenxcQEwV6qEV/GYSz5QKUHXTxdjcBKmqIIBpYA+QsykGxwsALVfGMSmWLZAsOEMqBsaNM7zkLrxdphL7zSmA1l5Blg979TbX+GhnGrcKmAo8YHh+MOszn34HoPXAPwSLv2dqEmcWGA7egHpiPo
x-originating-ip: [10.163.35.158]
Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620A10C6A0008AM1MPN1041mg_"
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: Re: [rtcweb] External Review Team
X-BeenThere: rtcweb@ietf.org
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 18:43:32 -0000

--_000_E44893DD4E290745BB608EB23FDDB7620A10C6A0008AM1MPN1041mg_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Also the decision is largely a trade-off between various interests. Various=
 stakeholder groups got mentioned yesterday: small vs. big companies, mobil=
e apps vs. websites, open vs. closed source, companies invested in legacy e=
quipment vs. those who are not, different browser vendors, and so on. What =
is the best outcome for each of these may be different and there is no righ=
t answer how these should be weighed. Plus the legal risk Bernard mentions =
below, which clouds this further, and keeps changing. We have learned quite=
 a lot of new information between early March and now for instance, regardi=
ng both H.264 and VP8.

Markus

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 ext Bernard Aboba
Sent: 08 November, 2013 20:19
To: rtcweb@ietf.org
Subject: Re: [rtcweb] External Review Team

Adam Roach stated:
"I'll make an even stronger statement: I would contend that any strong push=
 against the use of an external review team amounts to a tacit admission by=
 an individual that the arguments for their preferred position are insuffic=
iently compelling."

[BA] If the core issues under consideration were technical, I'd agree with =
you.
Unfortunately, they aren't.  The core issue (as Jonathan ably stated) is th=
e perceived legal risk.  Convening an external review team of IETF particip=
ants to evaluate those legal risks is unlikely to persuade the real audienc=
e for those recommendations - lawyers.

If the goal is to come up with a compelling legal analysis, the expert pane=
l should probably be composed of recognized legal experts.  Good luck with =
recruiting such a panel to work pro-bono.



--_000_E44893DD4E290745BB608EB23FDDB7620A10C6A0008AM1MPN1041mg_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 <=
/p>

Also the decision is larg=
ely a trade-off between various interests. Various stakeholder groups got m=
entioned yesterday: small vs. big companies, mobile apps
 vs. websites, open vs. closed source, companies invested in legacy equipme=
nt vs. those who are not, different browser vendors, and so on. What is the=
 best outcome for each of these may be different and there is no right answ=
er how these should be weighed.
 Plus the legal risk Bernard mentions below, which clouds this further, and=
 keeps changing. We have learned quite a lot of new information between ear=
ly March and now for instance, regarding both H.264 and VP8.


 <=
/p>

Markus<=
/p>

 <=
/p>







From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounce=
s@ietf.org]
On Behalf Of ext Bernard Aboba

Sent: 08 November, 2013 20:19

To: rtcweb@ietf.org

Subject: Re: [rtcweb] External Review Team






 




Adam Roach=
 stated:


"I'll make=
 an even stronger statement: I would contend that any strong push against t=
he use of an external review team amounts to a tacit admission by an indivi=
dual that the arguments for their preferred
 position are insufficiently compelling."

 

[BA] If the core issues under c=
onsideration were technical, I'd agree with you.


Unfortunately, they aren't.&nbs=
p; The core issue (as Jonathan ably stated) is the perceived legal risk.&nb=
sp; Convening an external review team of IETF participants to evaluate thos=
e legal risks is unlikely to persuade the real
 audience for those recommendations - lawyers. 

 

If the goal is to come up with =
a compelling legal analysis, the expert panel should probably be composed o=
f recognized legal experts.  Good luck with recruiting such a panel to=
 work pro-bono.


 

 










--_000_E44893DD4E290745BB608EB23FDDB7620A10C6A0008AM1MPN1041mg_--

From cowwoc@bbs.darktech.org  Fri Nov  8 10:53:45 2013
Return-Path: 
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 83D6711E80E9 for ; Fri,  8 Nov 2013 10:53:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.258
X-Spam-Level: 
X-Spam-Status: No, score=-4.258 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 od4062iIGqmF for ; Fri,  8 Nov 2013 10:53:39 -0800 (PST)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id D4AA721F9FDA for ; Fri,  8 Nov 2013 10:53:36 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id u16so636400iet.34 for ; Fri, 08 Nov 2013 10:53:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7QwQrZ6DBRcsFPJs1eix6OAWhXRWNzjlcxZiWx3wPSE=; b=CgU/g+G+3IFeDU4W2HM0X/WLRUjtv6BEwBjA7OmjUivETZ65jxzMIkZhmapTZ0jw0N YmmwelSDCcsnDDANM0kcjt4enyqMu+pntyHgh7mpJyNfAYlDgOrkqAzN/XMWZ5xK1ebU wZCXpCms2o8M/hhyk4xa1vvbb3gjcT6kSwbYu4TK5q11attZ7VNraK3HvEgCcolqOUBy QkdYPBDQDolIlWQZYCpDr1QgxWNqA5fblS6zbKFgd3w+kKZkv4NPMyxJ7YQjhT7+mHVC 1wY3w51dku2hg+wfL95hwRCVFjSBDPoIL5o/HI7P8GzSa9fQMBu2Ecdnr+eYDtYeGv6u 4fBA==
X-Gm-Message-State: ALoCoQlYwr/oBxmhv43KKMFW+48zgtkjnYRw641iuWIkLokn4dEG3ic6t9ycY8rlOqSNZaBh0MKI
X-Received: by 10.43.138.8 with SMTP id iq8mr10102972icc.37.1383936814917; Fri, 08 Nov 2013 10:53:34 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ka5sm4435413igb.2.2013.11.08.10.53.33 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 10:53:34 -0800 (PST)
Message-ID: <527D332B.8090506@bbs.darktech.org>
Date: Fri, 08 Nov 2013 13:53:31 -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: "cb.list6" 
References: 	<527C38FF.6040000@nostrum.com>		<527C7CFE.4080700@bbs.darktech.org>	<1E0D9A14-E629-4CB2-AC67-5860B24DB7D7@westhawk.co.uk>	<527D09CA.1060703@bbs.darktech.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org, Tim Panton 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Nov 2013 18:53:46 -0000

On 08/11/2013 12:25 PM, cb.list6 wrote:
> I disagree that "no MTI = transcode"
>
> There is no scenario I would permit transcoding as normal mode of 
> operations.  If sdp cannot find a common codec, fall back to 
> voice-only. And, at the implementation discretion, offer the user 
> advice about choosing a browser.
>
> CB
>

:) That doesn't work. Dropping video is equivalent to dropping a call. 
How would you like it if the roles were reversed and we couldn't agree 
on an MTI audio? Would it be acceptable to "simply drop the audio" and 
let the participants mime their way through the call? The entire reason 
I'm starting a WebRTC video call is because I want video. Otherwise, I'd 
pick up the phone.

Also, offering users "advice" about choosing a browser is also a 
non-starter. If 3 people join a call with IE, Firefox, and Chrome 
respectively who is on the "right" browser? One is not necessarily 
better than the other, other than we need them to agree on a codec. Some 
people may not have the necessary permission to switch browsers (work). 
Others are very touchy about their browsers. Asking them to switch isn't 
going to go down well.

Gili

From dabenham@gmail.com  Fri Nov  8 11:15:08 2013
Return-Path: 
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 49DBD11E818D for ; Fri,  8 Nov 2013 11:14:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wdCFXVt4IV1w for ; Fri,  8 Nov 2013 11:14:21 -0800 (PST)
Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1F611E81CF for ; Fri,  8 Nov 2013 11:11:30 -0800 (PST)
Received: by mail-ea0-f171.google.com with SMTP id h15so1089372eak.2 for ; Fri, 08 Nov 2013 11:11:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=584gVfYcUQuCy6qxy4ww4RhW/Z/+G7xL/kzly4jluBc=; b=d4loWyagBqikKusabIoglBhY4iIJe29gfuK4bx45gQTqP9g8Ex5wipIEYcjtSL4XJJ hy8fTY0PGhsxWTClCsgC4p/elBbsY5P+c0AiUXlDhannMYQoXNRAVF7GMAYDn3I+1tUr /wFvrwG3pE3XOwyVLARsPIuiKJ6KhDyJbAQ4r3ueEoyF/w5i0N+G1bnKe0OugEsU2YSF oIhtgTE6ct7zKliqU059offyEoRvl3qh8ytV737ph5BMPeLgL/+daOn+n6OhZDynE+F9 MeU/SkKMeGhtnncQHik9liWRNn7HHogAGiU84BLto5N39xwcvzr3CzaudO+DxxY6lcsZ aaww==
MIME-Version: 1.0
X-Received: by 10.15.61.66 with SMTP id h42mr4442419eex.62.1383937889592; Fri, 08 Nov 2013 11:11:29 -0800 (PST)
Received: by 10.15.75.1 with HTTP; Fri, 8 Nov 2013 11:11:29 -0800 (PST)
Date: Fri, 8 Nov 2013 11:11:29 -0800
Message-ID: 
From: David Benham 
To: Tim Panton new 
Content-Type: multipart/alternative; boundary=089e016356b44ce92704eaaf266d
Cc: rtcweb@ietf.org
Subject: [rtcweb] On demand & Internet TV via rtcweb? (was: Current H.264...)
X-BeenThere: rtcweb@ietf.org
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 19:15:09 -0000

--089e016356b44ce92704eaaf266d
Content-Type: text/plain; charset=ISO-8859-1

Bet the vast majority of those 800 app developers' business model is to
make money off *others* Internet content vs themselves being the provider
of such.  If they are doing that legally, those licenses and
royalties/revenue sharing arrangements are often really complex.

Regardless, how many providers of on-demand titles and broadcast TV over
the Internet would use rtcweb to deliver such no matter which codec was
MTI?

On Fri, Nov 8, 2013 at 8:24 AM, Tim Panton new  wrote:

>
> Interesting datapoint on the >100K subscribers front.  From Flurry - (via
> @BenedictEvans) There are at
> least 800 app developers with > 1M subscribers. So there seem to me to be
> quite a few 'Little guys' who
> may avoid webRTC if it requires an H264 license .
>
> http://blog.flurry.com//bid/102208/the-mobile-content-exlposion
>
>
>

--089e016356b44ce92704eaaf266d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Bet the vast majority of those=A0800 app developers' b=
usiness model is to make money off *others* Internet content vs themselves =
being the provider of such. =A0If they are doing that legally, those licens=
es and royalties/revenue sharing arrangements are often really complex.

Regardless, how many providers of on-demand titles and broad=
cast TV over the Internet would use rtcweb to deliver such no matter which =
codec was MTI?=A0


On Fri, Nov 8, 2013 at 8:24 AM, Tim Panton new <thp@westhawk.co.uk>=
; wrote:



Interesting datapoint on the >100K subscrib=
ers front. =A0From Flurry - (via @BenedictEvans) There are at


least 800 app developers with > 1M subscribers. So there seem to me=
 to be quite a few 'Little guys' who
may avoid webRTC if =
it requires an H264 license .=A0








--089e016356b44ce92704eaaf266d--

From dabenham@gmail.com  Fri Nov  8 12:21:46 2013
Return-Path: 
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 7976911E8226 for ; Fri,  8 Nov 2013 12:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 oimJcGVrbfbU for ; Fri,  8 Nov 2013 12:21:44 -0800 (PST)
Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DE17A11E8220 for ; Fri,  8 Nov 2013 12:21:40 -0800 (PST)
Received: by mail-ee0-f47.google.com with SMTP id c13so1247486eek.20 for ; Fri, 08 Nov 2013 12:21:40 -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=0IVWFOve3goW5o6wWWo2+rLlB4ORKIkb9KS6+dEUtvQ=; b=ARUg/nEN6wDGP6HGvOmjxiC9gyoUmAMV6IMpvve7MHlSLpqnmjrGZVByWY55jInTtO LaOTg306ics2FEPSY0BtmxBQUWZnfVDAPQ30k/9hKUWNxva23YC/0vOQ2mOOXIQr0/tq zL3QJmYPst+qEKV0zmygeWiSna1yZxIEqdWwxEq9m6QQwB3QUF6sXZpjkJTgY39O8Lu0 kZooUCkSIBX/UadYFIzj08+6y979WURbMQ92tOd9tW0zaCxPhsNVY9riFsEgahK5XvoK A/j+Ts3+K+i6h2COy6OL/M38XtVgTsQxTezw/VqeX7LVe5b75Evti0OJs1vrElYZoj+R lHxw==
MIME-Version: 1.0
X-Received: by 10.15.100.198 with SMTP id bn46mr18669956eeb.11.1383942100165;  Fri, 08 Nov 2013 12:21:40 -0800 (PST)
Received: by 10.15.75.1 with HTTP; Fri, 8 Nov 2013 12:21:39 -0800 (PST)
In-Reply-To: 
References:  
Date: Fri, 8 Nov 2013 12:21:39 -0800
Message-ID: 
From: David Benham 
To: tim panton 
Content-Type: multipart/alternative; boundary=089e0163549e45296104eab021fe
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] On demand & Internet TV via rtcweb? (was: Current H.264...)
X-BeenThere: rtcweb@ietf.org
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 20:21:46 -0000

--089e0163549e45296104eab021fe
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Suggesting that walking around your apartment for prospective renters to
see, showing the taxi driver your location or consulting on how to put
icing on a wedding cake during a call have somehow crossed over in to
providing on-demand titles or broadcast TV is, as they say in showbiz,
'jumping the shark.'

Even if we weren't heading down the rfc3929 path, doubt the a goal of
making it attractive to on-demand titles or broadcast TV to use rtcweb vs
other more technically apropos in html5/Internet ways would rank in the
decision criteria.

Yielding the email floor back to that important rfc3929 path discussion.



On Fri, Nov 8, 2013 at 11:24 AM, tim panton  wrote:

>
> On 8 Nov 2013, at 19:11, David Benham  wrote:
>
> Bet the vast majority of those 800 app developers' business model is to
> make money off *others* Internet content vs themselves being the provider
> of such.  If they are doing that legally, those licenses and
> royalties/revenue sharing arrangements are often really complex.
>
>
> Well 50 of them are p2p messaging apps (so called OTT players) - where th=
e
> content is _absolutely_ generated
> by their users.
>
> But I=92m more thinking of the rent-my-appartment app where the owner can=
 do
> a live video tour, or perhaps remote assist for
> using the cooker. The rt-video is a nice-to-have but they certainly won=
=92t
> spend time with the MPEG-LA=92s lawyers
> to add it.
>
> Likewise the summon-a-prepaid taxi app - it might be nice to show the
> driver where you are waiting with live video,
> but it is only spice to the main app purpose. Again these guys won=92t do
> video if it means they have to distract them selves with lawyers when the=
y
> hit the 100k user mark.
>
> Or one of the _infinite_ number of wedding planner apps - perhaps they=92=
d
> add a live consult feature, but not if
> it cost legal time and money to do.
>
>
> Regardless, how many providers of on-demand titles and broadcast TV over
> the Internet would use rtcweb to deliver such no matter which codec was
> MTI?
>
>
> I have no idea, those aren=92t the markets I know about. They are busines=
ses
> where the _key_ point is video delivery,
> I think there are a lot of interesting apps where it is the icing on the
> wedding cake (so to speak), we risk losing those folks from webRTC.
>
>
> On Fri, Nov 8, 2013 at 8:24 AM, Tim Panton new  wrote=
:
>
>>
>> Interesting datapoint on the >100K subscribers front.  From Flurry - (vi=
a
>> @BenedictEvans) There are at
>> least 800 app developers with > 1M subscribers. So there seem to me to b=
e
>> quite a few 'Little guys' who
>> may avoid webRTC if it requires an H264 license .
>>
>> http://blog.flurry.com//bid/102208/the-mobile-content-exlposion
>>
>>
>>
>
>

--089e0163549e45296104eab021fe
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Suggesting that walking around your apartment for prospect=
ive renters to see, showing the taxi driver your location or consulting on =
how to put icing on a wedding cake=A0during a call=A0have=A0somehow crossed=
 over in to providing on-demand titles or broadcast TV is, as they say in s=
howbiz, 'jumping the shark.'



Even if we weren't heading down the rfc3929 path, doubt =
the a goal of making it attractive to on-demand titles or broadcast TV to u=
se rtcweb vs other more technically apropos in html5/Internet ways would ra=
nk in the decision criteria.




Yielding the email floor back to that important rfc3929=
 path discussion.


=

On Fri, Nov 8, 2013 at 11:24 AM, tim panton =
<thp@westhawk.co.uk> wrote:



On 8 Nov 2013, at 19:11, David Benham <dabenham@gmail.com>=
 wrote:


Bet the vast majority of tho=
se=A0800 app developers' business model is to make money off *others* I=
nternet content vs themselves being the provider of such. =A0If they are do=
ing that legally, those licenses and royalties/revenue sharing arrangements=
 are often really complex.



Well 50 of them are p2p messaging apps (s=
o called OTT players) - where the content is _absolutely_ generated
by their users.

But I=92m more thinking of the =
rent-my-appartment app where the owner can do a live video tour, or perhaps=
 remote assist for


using the cooker. The rt-video is a nice-to-have but they certainly wo=
n=92t spend time with the MPEG-LA=92s lawyers=A0
to add it.=A0

Likewise the summon-a-prepaid taxi app - it might be=
 nice to show the driver where you are waiting with live video,


but it is only spice to the main app purpose. Again these guys won=92t=
 do video if it means they have to distract them selves with lawyers when t=
hey hit the 100k user mark.

Or one of the _infinit=
e_ number of wedding planner apps - perhaps they=92d add a live consult fea=
ture, but not if


it cost legal time and money to do.=A0


Regardless, how many providers of on-demand titles and broad=
cast TV over the Internet would use rtcweb to deliver such no matter which =
codec was MTI?=A0


I have no idea, those aren=92t the markets I know about. They are businesse=
s where the _key_ point is video delivery,
I think there are a lo=
t of interesting apps where it is the icing on the wedding cake (so to spea=
k), we risk losing those folks from webRTC.





On Fri, Nov 8, 2013 at 8:24 AM, Tim Panton new <thp@westhawk.co.uk>=
; wrote:




Interesting datapoint on the >100K subscribers front. =A0From=
 Flurry - (via @BenedictEvans) There are at


least 800 app developers with > 1M subscribers. So there seem to me=
 to be quite a few 'Little guys' who
may avoid webRTC if =
it requires an H264 license .=A0













--089e0163549e45296104eab021fe--

From cb.list6@gmail.com  Fri Nov  8 12:25:16 2013
Return-Path: 
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 0D2A911E8211 for ; Fri,  8 Nov 2013 12:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.463
X-Spam-Level: 
X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 f-w1tgjq1JLD for ; Fri,  8 Nov 2013 12:25:15 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id C872411E810E for ; Fri,  8 Nov 2013 12:25:14 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id b13so2466741wgh.27 for ; Fri, 08 Nov 2013 12:25:13 -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=gaFRxYiwat1+bN0WP0CRDM+uez/Bon2l7zulSl0baqc=; b=ojeccqBLHEDANSU8R8FWDKhUfgfM3mKtc1QGCtPec+U0CRMnwUhjc4Mt17t/lHa84Q 7v//SUAFXfftjnRDJicqGgrExRzw5+wyzwTfjyINFMA8c7lznIn/szUB6ZOhADGSohjF 70HUShyqIuUeH16N03Q1sgt2wab+/RTj2FPnha77IFy0iGTfVbSzGD75B81FEcAYGrrp TcXs0jYXfo8qi+L20JXJwO9SZlXm4LLVQfRCoJIn4p3JyKjb95P5gaV5k7r2NgEhUVzZ KvBiiXyMgziF5ZuqNSDSygILs691j+ot+cLbDcxj+2m/BN6GYN2kE77uWk+1/SEkmag8 i3sA==
MIME-Version: 1.0
X-Received: by 10.180.77.19 with SMTP id o19mr3852725wiw.34.1383942313905; Fri, 08 Nov 2013 12:25:13 -0800 (PST)
Received: by 10.216.99.68 with HTTP; Fri, 8 Nov 2013 12:25:13 -0800 (PST)
Received: by 10.216.99.68 with HTTP; Fri, 8 Nov 2013 12:25:13 -0800 (PST)
In-Reply-To: <527D332B.8090506@bbs.darktech.org>
References:  <527C38FF.6040000@nostrum.com>  <527C7CFE.4080700@bbs.darktech.org> <1E0D9A14-E629-4CB2-AC67-5860B24DB7D7@westhawk.co.uk> <527D09CA.1060703@bbs.darktech.org>  <527D332B.8090506@bbs.darktech.org>
Date: Fri, 8 Nov 2013 12:25:13 -0800
Message-ID: 
From: "cb.list6" 
To: cowwoc 
Content-Type: multipart/alternative; boundary=f46d043c7f5402974a04eab02e24
Cc: rtcweb@ietf.org, Tim Panton 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Nov 2013 20:25:16 -0000

--f46d043c7f5402974a04eab02e24
Content-Type: text/plain; charset=ISO-8859-1

On Nov 8, 2013 10:53 AM, "cowwoc"  wrote:
>
> On 08/11/2013 12:25 PM, cb.list6 wrote:
>>
>> I disagree that "no MTI = transcode"
>>
>> There is no scenario I would permit transcoding as normal mode of
operations.  If sdp cannot find a common codec, fall back to voice-only.
And, at the implementation discretion, offer the user advice about choosing
a browser.
>>
>> CB
>>
>
> :) That doesn't work. Dropping video is equivalent to dropping a call.
How would you like it if the roles were reversed and we couldn't agree on
an MTI audio? Would it be acceptable to "simply drop the audio" and let the
participants mime their way through the call? The entire reason I'm
starting a WebRTC video call is because I want video. Otherwise, I'd pick
up the phone.
>

It works today.  Sometimes skype and hangouts offer video, sometimes only
audio.

CB
> Also, offering users "advice" about choosing a browser is also a
non-starter. If 3 people join a call with IE, Firefox, and Chrome
respectively who is on the "right" browser? One is not necessarily better
than the other, other than we need them to agree on a codec. Some people
may not have the necessary permission to switch browsers (work). Others are
very touchy about their browsers. Asking them to switch isn't going to go
down well.
>
> Gili

--f46d043c7f5402974a04eab02e24
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Nov 8, 2013 10:53 AM, "cowwoc" <cowwoc@bbs.darktech.org> wrote:

>

> On 08/11/2013 12:25 PM, cb.list6 wrote:

>>

>> I disagree that "no MTI =3D transcode"

>>

>> There is no scenario I would permit transcoding as normal mode of =
operations. =A0If sdp cannot find a common codec, fall back to voice-only. =
And, at the implementation discretion, offer the user advice about choosing=
 a browser.


>>

>> CB

>>

>

> :) That doesn't work. Dropping video is equivalent to dropping a c=
all. How would you like it if the roles were reversed and we couldn't a=
gree on an MTI audio? Would it be acceptable to "simply drop the audio=
" and let the participants mime their way through the call? The entire=
 reason I'm starting a WebRTC video call is because I want video. Other=
wise, I'd pick up the phone.


>


It works today.=A0 Sometimes skype and hangouts offer video,=
 sometimes only audio. 


CB

> Also, offering users "advice" about choosing a browser is al=
so a non-starter. If 3 people join a call with IE, Firefox, and Chrome resp=
ectively who is on the "right" browser? One is not necessarily be=
tter than the other, other than we need them to agree on a codec. Some peop=
le may not have the necessary permission to switch browsers (work). Others =
are very touchy about their browsers. Asking them to switch isn't going=
 to go down well.


>

> Gili




--f46d043c7f5402974a04eab02e24--

From cowwoc@bbs.darktech.org  Fri Nov  8 14:21:57 2013
Return-Path: 
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 B0DD021E8099 for ; Fri,  8 Nov 2013 14:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.245
X-Spam-Level: 
X-Spam-Status: No, score=-4.245 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 uxXimSoVPqQP for ; Fri,  8 Nov 2013 14:21:51 -0800 (PST)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id B068F21E8092 for ; Fri,  8 Nov 2013 14:21:51 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id ar20so4277051iec.14 for ; Fri, 08 Nov 2013 14:21:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=u4oIInnxucSxncBT9OMwgblBxoYxZNU8kWIXhWm6lH4=; b=PB0fl3b6fsI81fDXzVQUef0hkhmT4fZxrYeOkioUQOA86zhi7oMp/7gWyP8G2EIYkm AqSp+/sLs1lcIE4fWyR6/sS5rbUryHsfzohTJ8pfcSF/buRUUqZTATArVuyhlyytfCqU stXRYGICojQzieW+XVBeeFfmbvn2ukrrF4Pb8UOYQQHt47+UGdgf2oOuuMVTUpJpmPIn q2DpAAxj1FTRNxLN/xO2C01rlpk5z2wMI7kaa9XDSFrIq/N5LC8qC2e7UWaupVnFAsbs r3/6FUetWU8mUUli3ZTEkL4ghDNAOh3RzlYWFGI9Mh3eg0wy3O6UBcTMq17t+MFRB16A 6ASA==
X-Gm-Message-State: ALoCoQltzt2Jtz3vC0wndb8ELs8CRn6rvd8X6Ldbo8Pn40XL8ffIedWHZUh6Jwk6bc4C9DlY6iUl
X-Received: by 10.50.29.4 with SMTP id f4mr4173688igh.11.1383949310837; Fri, 08 Nov 2013 14:21:50 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ft2sm5308778igb.5.2013.11.08.14.21.49 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 14:21:50 -0800 (PST)
Message-ID: <527D63FB.7070203@bbs.darktech.org>
Date: Fri, 08 Nov 2013 17:21:47 -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: "cb.list6" 
References: 	<527C38FF.6040000@nostrum.com>		<527C7CFE.4080700@bbs.darktech.org>	<1E0D9A14-E629-4CB2-AC67-5860B24DB7D7@westhawk.co.uk>	<527D09CA.1060703@bbs.darktech.org>		<527D332B.8090506@bbs.darktech.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080301080508040207070204"
Cc: rtcweb@ietf.org, Tim Panton 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Nov 2013 22:21:57 -0000

This is a multi-part message in MIME format.
--------------080301080508040207070204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 08/11/2013 3:25 PM, cb.list6 wrote:
>
> On Nov 8, 2013 10:53 AM, "cowwoc"  > wrote:
> >
> > On 08/11/2013 12:25 PM, cb.list6 wrote:
> >>
> >> I disagree that "no MTI = transcode"
> >>
> >> There is no scenario I would permit transcoding as normal mode of 
> operations.  If sdp cannot find a common codec, fall back to 
> voice-only. And, at the implementation discretion, offer the user 
> advice about choosing a browser.
> >>
> >> CB
> >>
> >
> > :) That doesn't work. Dropping video is equivalent to dropping a 
> call. How would you like it if the roles were reversed and we couldn't 
> agree on an MTI audio? Would it be acceptable to "simply drop the 
> audio" and let the participants mime their way through the call? The 
> entire reason I'm starting a WebRTC video call is because I want 
> video. Otherwise, I'd pick up the phone.
> >
>
> It works today.  Sometimes skype and hangouts offer video, sometimes 
> only audio.
>

     The only time I was only offered audio was when the user had no 
webcam :) In any case, I'm happy to agree with you on the following:

No Video MTI = No video or transcoding must be used

     If the community believes this is preferable to the alternatives, 
so be it.

Gili

--------------080301080508040207070204
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 08/11/2013 3:25 PM, cb.list6 wrote:

    

    

      
On Nov 8, 2013 10:53 AM, "cowwoc" <cowwoc@bbs.darktech.org>
        wrote:

        >

        > On 08/11/2013 12:25 PM, cb.list6 wrote:

        >>

        >> I disagree that "no MTI = transcode"

        >>

        >> There is no scenario I would permit transcoding as
        normal mode of operations.  If sdp cannot find a common codec,
        fall back to voice-only. And, at the implementation discretion,
        offer the user advice about choosing a browser.

        >>

        >> CB

        >>

        >

        > :) That doesn't work. Dropping video is equivalent to
        dropping a call. How would you like it if the roles were
        reversed and we couldn't agree on an MTI audio? Would it be
        acceptable to "simply drop the audio" and let the participants
        mime their way through the call? The entire reason I'm starting
        a WebRTC video call is because I want video. Otherwise, I'd pick
        up the phone.

        >

      
It works today.  Sometimes skype and hangouts offer
        video, sometimes only audio.

      

    

    

        The only time I was only offered audio was when the user had no
    webcam :) In any case, I'm happy to agree with you on the following:

    

    No Video MTI = No video or transcoding must be used

    

        If the community believes this is preferable to the
    alternatives, so be it.

    

    Gili

  


--------------080301080508040207070204--

From adam@nostrum.com  Fri Nov  8 14:56:03 2013
Return-Path: 
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 0812521E805F for ; Fri,  8 Nov 2013 14:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.522
X-Spam-Level: 
X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 0ZNQRm4gUCwb for ; Fri,  8 Nov 2013 14:56:00 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E53311E80FB for ; Fri,  8 Nov 2013 14:55:59 -0800 (PST)
Received: from dhcp-b7d7.meeting.ietf.org (dhcp-b7d7.meeting.ietf.org [31.133.183.215]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA8Mtr6W074366 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 8 Nov 2013 16:55:56 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <527D6BFA.9090509@nostrum.com>
Date: Fri, 08 Nov 2013 14:55:54 -0800
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Stephan Wenger , "rtcweb@ietf.org" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030901000807040700080604"
Received-SPF: pass (shaman.nostrum.com: 31.133.183.215 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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 22:56:03 -0000

This is a multi-part message in MIME format.
--------------030901000807040700080604
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 11/7/13 18:57, Stephan Wenger wrote:
> ...a decision for either of the two candidate codecs will be ignored 
> by a significant part of the implementer community.

I'm not sure that's true any longer. Indulge me in a bit of armchair 
game theory application.

Let's start by looking at ground zero: the browsers. Considering the 
public statements that have been made, I think it's fairly safe to 
assume that the following can be taken as given:

 1. Chrome will support at least VP8.
 2. Firefox will support both VP8 and H.264.
 3. Internet Explorer is almost certain to support H.264.
 4. Safari (including Mobile Safari) is almost certain to support H.264.


If the codecs are *only* those called out above, then you'll end up with 
an interesting situation in which IE, Safari, and Firefox can all 
mutually interoperate; Chrome and Firefox can interoperate with each 
other; and Chrome cannot interoperate with anything else.

I'm not going to put plans in Google's mouth, but envision yourself in 
the same set of circumstances: you own a fully-paid H.264 license, 
already ship an H.264 codec as part of your browser, and are getting a 
huge black eye for not interoperating with significant major browsers. 
What do you do?

Okay. Now, shift your imagined role: you're a non-browser implementor, 
and discover the facts on the ground to be those described above. You 
can deploy VP8 and work with two of the four major browsers, or you can 
deploy H.264 and work with all four. Yeah, you might not be in love with 
the structural issues involved in integrating the Cisco library [1]  -- 
and I'm certainly not -- but you're not actually precluded from using 
H.264. What do *you* do?

Which is a kind of long way to get to the fact that I think we're in a 
situation where H.264 is a de facto MTI codec anyway [2].

Now, imagine you're working in an SDO with this particular set of 
writing on the wall. You have a solid decision to choose one MTI video 
codec. You can choose one that's going to be functionally MTI regardless 
of what you say, or you can choose one that is quite probably going to 
be ignored by some non-trivial set of implementors.

So. What do *we* do?

/a

____
[1] There's been quite a bit of handwringing around the impact this has 
on iOS developers, as they cannot download modules at runtime. Bear in 
mind that these are curated applications, with a single, 
well-accounted-for distribution point. These are not libre software by a 
long shot, and they don't need to worry about the implications of third 
parties compiling their own versions. So, these implementors statically 
link in the OpenH264 library, and are exempted for the first 100,000 
instances they ship each year. Beyond that point, they're not "small 
fish" any more. Back when I was one of the owners of the company I 
worked at, "complications arising from selling more than 100,000 copies 
a year" is the kind of thing that I would place on a list titled 
"problems I wish I had."

[2] And to be clear, this is *not* the result I would have preferred. 
But I recognize that this isn't about my personal preferences. I find 
myself in the odd position of actually arguing for the position contrary 
to what I think is ideal, simply because I think it is the only 
practical path to success.

--------------030901000807040700080604
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 11/7/13 18:57, Stephan Wenger wrote:

    

    
...a
      decision for either of the two candidate codecs will be ignored by
      a significant part of the implementer community.

    

    I'm not sure that's true any longer. Indulge me in a bit of armchair
    game theory application.

    

    Let's start by looking at ground zero: the browsers. Considering the
    public statements that have been made, I think it's fairly safe to
    assume that the following can be taken as given:

    

    
    
      
  1. Chrome will support at least VP8.
    2. 
      
  2. Firefox will support both VP8 and H.264.
    3. 
      
  3. Internet Explorer is almost certain to support H.264.
    4. 
      
  4. Safari (including Mobile Safari) is almost certain to support
        H.264.
    5. 
    

    

    If the codecs are *only* those called out above, then you'll end up
    with an interesting situation in which IE, Safari, and Firefox can
    all mutually interoperate; Chrome and Firefox can interoperate with
    each other; and Chrome cannot interoperate with anything else.

    

    I'm not going to put plans in Google's mouth, but envision yourself
    in the same set of circumstances: you own a fully-paid H.264
    license, already ship an H.264 codec as part of your browser, and
    are getting a huge black eye for not interoperating with significant
    major browsers. What do you do?

    

    Okay. Now, shift your imagined role: you're a non-browser
    implementor, and discover the facts on the ground to be those
    described above. You can deploy VP8 and work with two of the four
    major browsers, or you can deploy H.264 and work with all four.
    Yeah, you might not be in love with the structural issues involved
    in integrating the Cisco library [1]  -- and I'm certainly not --
    but you're not actually precluded from using H.264. What do *you*
    do?

    

    Which is a kind of long way to get to the fact that I think we're in
    a situation where H.264 is a de facto MTI codec anyway [2].

    

    Now, imagine you're working in an SDO with this particular set of
    writing on the wall. You have a solid decision to choose one MTI
    video codec. You can choose one that's going to be functionally MTI
    regardless of what you say, or you can choose one that is quite
    probably going to be ignored by some non-trivial set of
    implementors.

    

    So. What do *we* do?

    

    /a

    

    ____

    [1] There's been quite a bit of handwringing around the impact this
    has on iOS developers, as they cannot download modules at runtime.
    Bear in mind that these are curated applications, with a single,
    well-accounted-for distribution point. These are not libre software
    by a long shot, and they don't need to worry about the implications
    of third parties compiling their own versions. So, these
    implementors statically link in the OpenH264 library, and are
    exempted for the first 100,000 instances they ship each year. Beyond
    that point, they're not "small fish" any more. Back when I was one
    of the owners of the company I worked at, "complications arising
    from selling more than 100,000 copies a year" is the kind of thing
    that I would place on a list titled "problems I wish I had."

    

    [2] And to be clear, this is *not* the result I would have
    preferred. But I recognize that this isn't about my personal
    preferences. I find myself in the odd position of actually arguing
    for the position contrary to what I think is ideal, simply because I
    think it is the only practical path to success.

  


--------------030901000807040700080604--

From pthatcher@google.com  Fri Nov  8 15:20:51 2013
Return-Path: 
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 E765C11E80DE for ; Fri,  8 Nov 2013 15:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 wsj9vptR9wZI for ; Fri,  8 Nov 2013 15:20:50 -0800 (PST)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E505121F9C8B for ; Fri,  8 Nov 2013 15:20:49 -0800 (PST)
Received: by mail-pd0-f172.google.com with SMTP id w10so2768629pde.3 for ; Fri, 08 Nov 2013 15:20:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=P9LIsWJBKIdStsJQG5ma7K9Jl/cL+DIRiKQNQaejm4Y=; b=Be3FSvybnUfKTor6QLhp+dgTwT56wHdnNTfFdfDNhY1KxU73OGrvKvqss9kBR0O5kz iOgMULkyFgIRBprDtOEWMk0ldHEsCj1QSNJWhEea2OzI0W8d49GWk+/5Le30GjzKdunV 8MTXTy40D0JAB5zgEttAQMW9+/7KySQa9QsrlWI6yOPqNIuB1TaVvJO/DJ4LQeW0C/6M Lj6+UJx2U5/bzFlikRx8TBzn9P8IDRJfqnVbdauUa8HLX04Dttzonq1YG81iQHh6eW2I gS4uEjQ02RBKCEHkytZqWOt+kKOlg7KcmZyCJcelucDrLSzbl6rPoW1gaxy58piL/OjN RJ6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=P9LIsWJBKIdStsJQG5ma7K9Jl/cL+DIRiKQNQaejm4Y=; b=fjA2aaN9AOzRshUXkavuYLnpR6Whxm5R98PMUktu4r3+6oGkZJQpDyerfwFMNyxwTt T6t4MPUA+TJ0aZ7tVJydl//1eNXtb1Gwm/StZgXv+5YiqG20KeHeK1VtUujqKtwgsKsz nDpJm9AEvrkvn2pGKHxs+0CF9kD2vuEhLprCGx4jeCn/o3W9MTjoGnURHkOiFjMg5v7m HgFodzYNZ2eBKiZxqnAYkMUABXImT8QXpDS72/dSrbHLUJmRB+vAXERRUPanIzkVX/Ff L4O93XYVQk41xCYnROQ+SKBrPCwrLP3aWH72Vbuw8yMB/kipsZ7YyoTcIg7XJ8OkRbri Q3Dw==
X-Gm-Message-State: ALoCoQm5UMrpTL1n62w84z1JksQnfVm3FswWT0VZdk56LQLeNHGZDPCeYdgvHaaGdI93wlla16Vb5T/SzFYx9XzCdO7CycL9q0iFrami4T0BGWeWF1Og7qe+/nPWPUR01MGgAaQDINb7Pw3YILXKdQknFjRMl2iW2hp+hwhSkVguQYrQXnNcOcE4BqebP07LrkDCxRqTEvup
X-Received: by 10.68.4.232 with SMTP id n8mr17588948pbn.9.1383952848659; Fri, 08 Nov 2013 15:20:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.66.163.234 with HTTP; Fri, 8 Nov 2013 15:20:08 -0800 (PST)
In-Reply-To: <527D6BFA.9090509@nostrum.com>
References:  <527D6BFA.9090509@nostrum.com>
From: Peter Thatcher 
Date: Fri, 8 Nov 2013 15:20:08 -0800
Message-ID: 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=bcaec5215b07ee437604eab2a1ec
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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 23:20:51 -0000

--bcaec5215b07ee437604eab2a1ec
Content-Type: text/plain; charset=UTF-8

You are responding to a little speculation with a lot of speculation, which
doesn't seem very valuable.  What should *I* do?  Respond with more
speculation, of course.

I will speculate that there is a group of developers that would ignore an
H.264 MTI:  FOSS projects.  They will ignore it because they can't
implement it.  To them, MT(IMPLEMENT) becomes MT(IGNORE_THE_SPEC).  I
speculate this includes FOSS browsers, include the Firefox source code and
(with no extra knowledge from my employer; it's just speculation) Chromium
and FOSS forks of both Firefox and Chromium.  I further speculate this will
include FOSS non-browser RTCWEB endpoints, such as FOSS RTC mobile apps.

So there's my speculation in response to your speculation in response to
Stephan's speculation, probably without value, but perhaps worth reminding
everyone that some people (FOSS projects) will have to ignore the spec if
H.264 is the MTI, because they have no choice (at least in countries where
software patents are enforced).  Of course, you may then speculate in
return that no one cares about FOSS projects and browsers, which I
speculate would be an ironic coming from someone representing a FOSS
project.







On Fri, Nov 8, 2013 at 2:55 PM, Adam Roach  wrote:

>  On 11/7/13 18:57, Stephan Wenger wrote:
>
> ...a decision for either of the two candidate codecs will be ignored by a
> significant part of the implementer community.
>
>
> I'm not sure that's true any longer. Indulge me in a bit of armchair game
> theory application.
>
> Let's start by looking at ground zero: the browsers. Considering the
> public statements that have been made, I think it's fairly safe to assume
> that the following can be taken as given:
>
>
>    1. Chrome will support at least VP8.
>    2. Firefox will support both VP8 and H.264.
>    3. Internet Explorer is almost certain to support H.264.
>    4. Safari (including Mobile Safari) is almost certain to support H.264.
>
>
> If the codecs are *only* those called out above, then you'll end up with
> an interesting situation in which IE, Safari, and Firefox can all mutually
> interoperate; Chrome and Firefox can interoperate with each other; and
> Chrome cannot interoperate with anything else.
>
> I'm not going to put plans in Google's mouth, but envision yourself in the
> same set of circumstances: you own a fully-paid H.264 license, already ship
> an H.264 codec as part of your browser, and are getting a huge black eye
> for not interoperating with significant major browsers. What do you do?
>
> Okay. Now, shift your imagined role: you're a non-browser implementor, and
> discover the facts on the ground to be those described above. You can
> deploy VP8 and work with two of the four major browsers, or you can deploy
> H.264 and work with all four. Yeah, you might not be in love with the
> structural issues involved in integrating the Cisco library [1]  -- and I'm
> certainly not -- but you're not actually precluded from using H.264. What
> do *you* do?
>
> Which is a kind of long way to get to the fact that I think we're in a
> situation where H.264 is a de facto MTI codec anyway [2].
>
> Now, imagine you're working in an SDO with this particular set of writing
> on the wall. You have a solid decision to choose one MTI video codec. You
> can choose one that's going to be functionally MTI regardless of what you
> say, or you can choose one that is quite probably going to be ignored by
> some non-trivial set of implementors.
>
> So. What do *we* do?
>
> /a
>
> ____
> [1] There's been quite a bit of handwringing around the impact this has on
> iOS developers, as they cannot download modules at runtime. Bear in mind
> that these are curated applications, with a single, well-accounted-for
> distribution point. These are not libre software by a long shot, and they
> don't need to worry about the implications of third parties compiling their
> own versions. So, these implementors statically link in the OpenH264
> library, and are exempted for the first 100,000 instances they ship each
> year. Beyond that point, they're not "small fish" any more. Back when I was
> one of the owners of the company I worked at, "complications arising from
> selling more than 100,000 copies a year" is the kind of thing that I would
> place on a list titled "problems I wish I had."
>
> [2] And to be clear, this is *not* the result I would have preferred. But
> I recognize that this isn't about my personal preferences. I find myself in
> the odd position of actually arguing for the position contrary to what I
> think is ideal, simply because I think it is the only practical path to
> success.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--bcaec5215b07ee437604eab2a1ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


You are responding to a little speculation with a lot of specul=
ation, which doesn't seem very valuable. =C2=A0What should *I* do? =C2=
=A0Respond with more speculation, of course.




<=
/div>
=
I will speculate that there is a group of developers that would ignore an H=
.264 MTI: =C2=A0FOSS projects. =C2=A0They will ignore it because they can&#=
39;t implement it. =C2=A0To them, MT(IMPLEMENT) becomes MT(IGNORE_THE_SPEC)=
. =C2=A0I speculate this includes FOSS browsers, include the Firefox source=
 code and (with no extra knowledge from my employer; it's just speculat=
ion) Chromium and FOSS forks of both Firefox and Chromium. =C2=A0I further =
speculate this will include FOSS non-browser RTCWEB endpoints, such as FOSS=
 RTC mobile apps. =C2=A0




<=
/div>
=
So there's my speculation in response to your speculation in response t=
o Stephan's speculation, probably without value, but perhaps worth remi=
nding everyone that some people (FOSS projects) will have to ignore the spe=
c if H.264 is the MTI, because they have no choice (at least in countries w=
here software patents are enforced). =C2=A0Of course, you may then speculat=
e in return that no one cares about FOSS projects and browsers, which I spe=
culate would be an ironic coming from someone representing a FOSS project.<=
/div>



<=
/div>
=









On Fri, Nov 8, 2013 at 2:55 PM, Adam Roach <adam@nostrum.com> wrote:




 =20
   =20
 =20
  

    
On 11/7/13 18:57, Stephan Wenger wrote:

    

    
...a
      decision for either of the two candidate codecs will be ignored by
      a significant part of the implementer community.

    

    I'm not sure that's true any longer. Indulge me in a bit of arm=
chair
    game theory application.

    

    Let's start by looking at ground zero: the browsers. Considering th=
e
    public statements that have been made, I think it's fairly safe to
    assume that the following can be taken as given:

    

    
    
      
  1. Chrome will support at least VP8.
    2. 
      
  2. Firefox will support both VP8 and H.264.
    3. 
      
  3. Internet Explorer is almost certain to support H.264.
    4. 
      
  4. Safari (including Mobile Safari) is almost certain to support
        H.264.
    5. 
    

    

    If the codecs are *only* those called out above, then you'll end up
    with an interesting situation in which IE, Safari, and Firefox can
    all mutually interoperate; Chrome and Firefox can interoperate with
    each other; and Chrome cannot interoperate with anything else.

    

    I'm not going to put plans in Google's mouth, but envision your=
self
    in the same set of circumstances: you own a fully-paid H.264
    license, already ship an H.264 codec as part of your browser, and
    are getting a huge black eye for not interoperating with significant
    major browsers. What do you do?

    

    Okay. Now, shift your imagined role: you're a non-browser
    implementor, and discover the facts on the ground to be those
    described above. You can deploy VP8 and work with two of the four
    major browsers, or you can deploy H.264 and work with all four.
    Yeah, you might not be in love with the structural issues involved
    in integrating the Cisco library [1]=C2=A0 -- and I'm certainly not=
 --
    but you're not actually precluded from using H.264. What do *you*
    do?

    

    Which is a kind of long way to get to the fact that I think we're i=
n
    a situation where H.264 is a de facto MTI codec anyway [2].

    

    Now, imagine you're working in an SDO with this particular set of
    writing on the wall. You have a solid decision to choose one MTI
    video codec. You can choose one that's going to be functionally MTI
    regardless of what you say, or you can choose one that is quite
    probably going to be ignored by some non-trivial set of
    implementors.

    

    So. What do *we* do?

    

    /a

    

    ____

    [1] There's been quite a bit of handwringing around the impact this
    has on iOS developers, as they cannot download modules at runtime.
    Bear in mind that these are curated applications, with a single,
    well-accounted-for distribution point. These are not libre software
    by a long shot, and they don't need to worry about the implications
    of third parties compiling their own versions. So, these
    implementors statically link in the OpenH264 library, and are
    exempted for the first 100,000 instances they ship each year. Beyond
    that point, they're not "small fish" any more. Back when =
I was one
    of the owners of the company I worked at, "complications arising
    from selling more than 100,000 copies a year" is the kind of thing
    that I would place on a list titled "problems I wish I had."<=
br>
    

    [2] And to be clear, this is *not* the result I would have
    preferred. But I recognize that this isn't about my personal
    preferences. I find myself in the odd position of actually arguing
    for the position contrary to what I think is ideal, simply because I
    think it is the only practical path to success.

  



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--bcaec5215b07ee437604eab2a1ec--

From bernard_aboba@hotmail.com  Fri Nov  8 15:32:10 2013
Return-Path: 
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 0791C11E80FB for ; Fri,  8 Nov 2013 15:32:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.339
X-Spam-Level: 
X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 5VGS7RB1F-QC for ; Fri,  8 Nov 2013 15:32:05 -0800 (PST)
Received: from blu0-omc2-s13.blu0.hotmail.com (blu0-omc2-s13.blu0.hotmail.com [65.55.111.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3382221E8085 for ; Fri,  8 Nov 2013 15:31:48 -0800 (PST)
Received: from BLU403-EAS388 ([65.55.111.71]) by blu0-omc2-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Nov 2013 15:31:47 -0800
X-TMN: [SA3IbGf8dEC/V79kmqHM00J0NKNp+dBc]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/related; boundary="_f2714b99-f746-40ff-9672-2f65d1167763_"
Date: Fri, 8 Nov 2013 15:31:45 -0800
From: Bernard Aboba 
To: Peter Thatcher 
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Nov 2013 23:31:47.0336 (UTC) FILETIME=[B125F880:01CEDCDA]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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 23:32:10 -0000

--_f2714b99-f746-40ff-9672-2f65d1167763_
Content-Type: multipart/alternative;
	boundary="_162cb9ec-5b05-496a-8865-f60aa73d6253_"

--_162cb9ec-5b05-496a-8865-f60aa73d6253_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

I cannot resist adding my speculation to everyone else's. I speculate that =
by this time next year=2C no one will care about this debate. This could be=
 either because they have moved on to new (but equally unproductive) argume=
nts about VP9 vs. H.265 OR because the RTCWEB WG adopted no MTI but at the =
same time focused on enabling codec plugability=2C so that codec technology=
 could evolve more easily.

Rules vs. Tools. Take your choice...

Peter Thatcher  wrote:

You are responding to a little speculation with a lot of speculation=2C whi=
ch
doesn't seem very valuable.  What should *I* do?  Respond with more
speculation=2C of course.

I will speculate that there is a group of developers that would ignore an
H.264 MTI:  FOSS projects.  They will ignore it because they can't
implement it.  To them=2C MT(IMPLEMENT) becomes MT(IGNORE_THE_SPEC).  I
speculate this includes FOSS browsers=2C include the Firefox source code an=
d
(with no extra knowledge from my employer=3B it's just speculation) Chromiu=
m
and FOSS forks of both Firefox and Chromium.  I further speculate this will
include FOSS non-browser RTCWEB endpoints=2C such as FOSS RTC mobile apps.

So there's my speculation in response to your speculation in response to
Stephan's speculation=2C probably without value=2C but perhaps worth remind=
ing
everyone that some people (FOSS projects) will have to ignore the spec if
H.264 is the MTI=2C because they have no choice (at least in countries wher=
e
software patents are enforced).  Of course=2C you may then speculate in
return that no one cares about FOSS projects and browsers=2C which I
speculate would be an ironic coming from someone representing a FOSS
project.







On Fri=2C Nov 8=2C 2013 at 2:55 PM=2C Adam Roach  wrote:

>  On 11/7/13 18:57=2C Stephan Wenger wrote:
>
> ...a decision for either of the two candidate codecs will be ignored by a
> significant part of the implementer community.
>
>
> I'm not sure that's true any longer. Indulge me in a bit of armchair game
> theory application.
>
> Let's start by looking at ground zero: the browsers. Considering the
> public statements that have been made=2C I think it's fairly safe to assu=
me
> that the following can be taken as given:
>
>
>    1. Chrome will support at least VP8.
>    2. Firefox will support both VP8 and H.264.
>    3. Internet Explorer is almost certain to support H.264.
>    4. Safari (including Mobile Safari) is almost certain to support H.264=
.
>
>
> If the codecs are *only* those called out above=2C then you'll end up wit=
h
> an interesting situation in which IE=2C Safari=2C and Firefox can all mut=
ually
> interoperate=3B Chrome and Firefox can interoperate with each other=3B an=
d
> Chrome cannot interoperate with anything else.
>
> I'm not going to put plans in Google's mouth=2C but envision yourself in =
the
> same set of circumstances: you own a fully-paid H.264 license=2C already =
ship
> an H.264 codec as part of your browser=2C and are getting a huge black ey=
e
> for not interoperating with significant major browsers. What do you do?
>
> Okay. Now=2C shift your imagined role: you're a non-browser implementor=
=2C and
> discover the facts on the ground to be those described above. You can
> deploy VP8 and work with two of the four major browsers=2C or you can dep=
loy
> H.264 and work with all four. Yeah=2C you might not be in love with the
> structural issues involved in integrating the Cisco library [1]  -- and I=
'm
> certainly not -- but you're not actually precluded from using H.264. What
> do *you* do?
>
> Which is a kind of long way to get to the fact that I think we're in a
> situation where H.264 is a de facto MTI codec anyway [2].
>
> Now=2C imagine you're working in an SDO with this particular set of writi=
ng
> on the wall. You have a solid decision to choose one MTI video codec. You
> can choose one that's going to be functionally MTI regardless of what you
> say=2C or you can choose one that is quite probably going to be ignored b=
y
> some non-trivial set of implementors.
>
> So. What do *we* do?
>
> /a
>
> ____
> [1] There's been quite a bit of handwringing around the impact this has o=
n
> iOS developers=2C as they cannot download modules at runtime. Bear in min=
d
> that these are curated applications=2C with a single=2C well-accounted-fo=
r
> distribution point. These are not libre software by a long shot=2C and th=
ey
> don't need to worry about the implications of third parties compiling the=
ir
> own versions. So=2C these implementors statically link in the OpenH264
> library=2C and are exempted for the first 100=2C000 instances they ship e=
ach
> year. Beyond that point=2C they're not "small fish" any more. Back when I=
 was
> one of the owners of the company I worked at=2C "complications arising fr=
om
> selling more than 100=2C000 copies a year" is the kind of thing that I wo=
uld
> place on a list titled "problems I wish I had."
>
> [2] And to be clear=2C this is *not* the result I would have preferred. B=
ut
> I recognize that this isn't about my personal preferences. I find myself =
in
> the odd position of actually arguing for the position contrary to what I
> think is ideal=2C simply because I think it is the only practical path to
> success.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--_162cb9ec-5b05-496a-8865-f60aa73d6253_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"









I cannot resist adding my speculation to everyone =
else's. I speculate that by this time next year=2C no one will care about t=
his debate. This could be either because they have moved on to new (but equ=
ally unproductive) arguments about VP9
 vs. H.265 OR because the RTCWEB WG adopted no MTI but at the same time foc=
used on enabling codec plugability=2C so that codec technology could evolve=
 more easily.




Rules vs. Tools. Take your choice...



Peter Thatcher <=3Bpthatcher@google.com>=3B wrote:










Y=
ou are responding to a little speculation with a lot of speculation=2C whic=
h doesn't seem very valuable.  =3BWhat should *I* do?  =3BRespond w=
ith more speculation=2C of course.


<=
br>



I=
 will speculate that there is a group of developers that would ignore an H.=
264 MTI:  =3BFOSS projects.  =3BThey will ignore it because they ca=
n't implement it.  =3BTo them=2C MT(IMPLEMENT) becomes MT(IGNORE_THE_SP=
EC).
  =3BI speculate this includes FOSS browsers=2C include the Firefox sou=
rce code and (with no extra knowledge from my employer=3B it's just specula=
tion) Chromium and FOSS forks of both Firefox and Chromium.  =3BI furth=
er speculate this will include FOSS non-browser RTCWEB
 endpoints=2C such as FOSS RTC mobile apps.  =3B


<=
br>



S=
o there's my speculation in response to your speculation in response to Ste=
phan's speculation=2C probably without value=2C but perhaps worth reminding=
 everyone that some people (FOSS projects)
 will have to ignore the spec if H.264 is the MTI=2C because they have no c=
hoice (at least in countries where software patents are enforced).  =3B=
Of course=2C you may then speculate in return that no one cares about FOSS =
projects and browsers=2C which I speculate would
 be an ironic coming from someone representing a FOSS project.


<=
br>



<=
br>



<=
br>



<=
br>



<=
br>








On Fri=2C Nov 8=2C 2013 at 2:55 PM=2C Adam Roa=
ch 
<=3Badam@nostrum.co=
m>=3B wrote:






On 11/7/13 18:57=2C Stephan Wenger wrote:




...a decision for either of the two candidate cod=
ecs will be ignored by a significant part of the implementer community.


I'm not sure that's true any longer. Indulge me in a bit of armchair game t=
heory application.



Let's start by looking at ground zero: the browsers. Considering the public=
 statements that have been made=2C I think it's fairly safe to assume that =
the following can be taken as given:




    

  1. Chrome will support at least VP8. 
  2. Firefox will support both VP=
8 and H.264. 
  3. Internet Explorer is almost certain to support H.264.=
 
  4. Safari (including Mobile Safari) is almost certain to support H.2=
64. 



If the codecs are *only* those called out above=2C then you'll end up with =
an interesting situation in which IE=2C Safari=2C and Firefox can all mutua=
lly interoperate=3B Chrome and Firefox can interoperate with each other=3B =
and Chrome cannot interoperate with anything
 else.



I'm not going to put plans in Google's mouth=2C but envision yourself in th=
e same set of circumstances: you own a fully-paid H.264 license=2C already =
ship an H.264 codec as part of your browser=2C and are getting a huge black=
 eye for not interoperating with significant
 major browsers. What do you do?



Okay. Now=2C shift your imagined role: you're a non-browser implementor=2C =
and discover the facts on the ground to be those described above. You can d=
eploy VP8 and work with two of the four major browsers=2C or you can deploy=
 H.264 and work with all four. Yeah=2C you
 might not be in love with the structural issues involved in integrating th=
e Cisco library [1] =3B -- and I'm certainly not -- but you're not actu=
ally precluded from using H.264. What do *you* do?



Which is a kind of long way to get to the fact that I think we're in a situ=
ation where H.264 is a de facto MTI codec anyway [2].



Now=2C imagine you're working in an SDO with this particular set of writing=
 on the wall. You have a solid decision to choose one MTI video codec. You =
can choose one that's going to be functionally MTI regardless of what you s=
ay=2C or you can choose one that is
 quite probably going to be ignored by some non-trivial set of implementors=
.



So. What do *we* do?



/a



____

[1] There's been quite a bit of handwringing around the impact this has on =
iOS developers=2C as they cannot download modules at runtime. Bear in mind =
that these are curated applications=2C with a single=2C well-accounted-for =
distribution point. These are not libre
 software by a long shot=2C and they don't need to worry about the implicat=
ions of third parties compiling their own versions. So=2C these implementor=
s statically link in the OpenH264 library=2C and are exempted for the first=
 100=2C000 instances they ship each year.
 Beyond that point=2C they're not "=3Bsmall fish"=3B any more. Back=
 when I was one of the owners of the company I worked at=2C "=3Bcomplic=
ations arising from selling more than 100=2C000 copies a year"=3B is th=
e kind of thing that I would place on a list titled "=3Bproblems I wish
 I had."=3B



[2] And to be clear=2C this is *not* the result I would have preferred. But=
 I recognize that this isn't about my personal preferences. I find myself i=
n the odd position of actually arguing for the position contrary to what I =
think is ideal=2C simply because I think
 it is the only practical path to success.





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb


















--_162cb9ec-5b05-496a-8865-f60aa73d6253_--

--_f2714b99-f746-40ff-9672-2f65d1167763_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--_f2714b99-f746-40ff-9672-2f65d1167763_--

From cowwoc@bbs.darktech.org  Fri Nov  8 15:42:53 2013
Return-Path: 
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 B739621E805F for ; Fri,  8 Nov 2013 15:42:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.233
X-Spam-Level: 
X-Spam-Status: No, score=-4.233 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 EnuFlxMFVeBp for ; Fri,  8 Nov 2013 15:42:49 -0800 (PST)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2697811E80DE for ; Fri,  8 Nov 2013 15:42:49 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id ar20so4549378iec.28 for ; Fri, 08 Nov 2013 15:42:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=aguxktsuBCoGiVgnsM+Hv6CIOnI7tGFh3xA3Hz81gPc=; b=b6E/cQ2XJad8kSLy1WOjoANJVDhNuM05lglR76TUbPrM2UZuVmT9JFROwcY54muEWB DdEKfON5lNu7cBZB6FMgCDwHPzxC/gAAADFcnogXONZmdp+2EDzXua+c2QJM+6xt3PwS ulJN8SsuvnJijEjquJ0iNI5aoFRW2cUKUGoLP8wpbY7Yg51SDIa15yLfuMCgKFFiwFqG lyI+NOwOkRHI/9Q5ZIjO11k6+P15qrflTlc4VOIWQvRHqUsfSPJ0+pfx/lfTqCABpXYp +kdZADJgD7QcvJShCnCw+QN+QIfrNgcfzwZGEPZSUH1EyqOACNeKoj03yNBk+6EBWEKO K/ag==
X-Gm-Message-State: ALoCoQmvIgg6/SwUUMFmwsADBxXYR+HVZ1IvITUNox86UFr0X4IJKcSdDsb54UakkdM5K3BR5ReO
X-Received: by 10.50.25.227 with SMTP id f3mr4356816igg.21.1383954168043; Fri, 08 Nov 2013 15:42:48 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id x5sm5644662iga.6.2013.11.08.15.42.46 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 15:42:47 -0800 (PST)
Message-ID: <527D76F4.9090806@bbs.darktech.org>
Date: Fri, 08 Nov 2013 18:42:44 -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: rtcweb@ietf.org
References:  <527D6BFA.9090509@nostrum.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020500040402040802070208"
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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 23:42:53 -0000

This is a multi-part message in MIME format.
--------------020500040402040802070208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


     Allow me to throw some more water on Adam's analysis :)

 1. Chrome = 46% of the market. IE + Safari = 23% of the market. Source:
    http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
     1. It doesn't matter how many browsers you own. What matters is
        market-share. In fact, the more browsers you have to support,
        the more difficult it is to deploy and test the app.
     2. Now... Why would I break my back for 23% of the market *and* pay
        royalties when I can get 46% of the market for very little
        effort (ease of deploying/testing) and pay no royalties?
 2. If what you say is true, it is in Google's best interest to get
    Firefox to drop H.264 and then drop H.264 itself in order to even
    the odds. Now, guess where the vast majority of Firefox's funding
    comes from?

     I don't think these kinds of politics should come into play, but 
clearly the situation is a lot more nuanced than previously mentioned.

Gili

On 08/11/2013 6:20 PM, Peter Thatcher wrote:
> You are responding to a little speculation with a lot of speculation, 
> which doesn't seem very valuable.  What should *I* do?  Respond with 
> more speculation, of course.
>
> I will speculate that there is a group of developers that would ignore 
> an H.264 MTI:  FOSS projects.  They will ignore it because they can't 
> implement it.  To them, MT(IMPLEMENT) becomes MT(IGNORE_THE_SPEC).  I 
> speculate this includes FOSS browsers, include the Firefox source code 
> and (with no extra knowledge from my employer; it's just speculation) 
> Chromium and FOSS forks of both Firefox and Chromium.  I further 
> speculate this will include FOSS non-browser RTCWEB endpoints, such as 
> FOSS RTC mobile apps.
>
> So there's my speculation in response to your speculation in response 
> to Stephan's speculation, probably without value, but perhaps worth 
> reminding everyone that some people (FOSS projects) will have to 
> ignore the spec if H.264 is the MTI, because they have no choice (at 
> least in countries where software patents are enforced).  Of course, 
> you may then speculate in return that no one cares about FOSS projects 
> and browsers, which I speculate would be an ironic coming from someone 
> representing a FOSS project.
>
>
>
>
>
>
>
> On Fri, Nov 8, 2013 at 2:55 PM, Adam Roach  > wrote:
>
>     On 11/7/13 18:57, Stephan Wenger wrote:
>>     ...a decision for either of the two candidate codecs will be
>>     ignored by a significant part of the implementer community.
>
>     I'm not sure that's true any longer. Indulge me in a bit of
>     armchair game theory application.
>
>     Let's start by looking at ground zero: the browsers. Considering
>     the public statements that have been made, I think it's fairly
>     safe to assume that the following can be taken as given:
>
>      1. Chrome will support at least VP8.
>      2. Firefox will support both VP8 and H.264.
>      3. Internet Explorer is almost certain to support H.264.
>      4. Safari (including Mobile Safari) is almost certain to support
>         H.264.
>
>
>     If the codecs are *only* those called out above, then you'll end
>     up with an interesting situation in which IE, Safari, and Firefox
>     can all mutually interoperate; Chrome and Firefox can interoperate
>     with each other; and Chrome cannot interoperate with anything else.
>
>     I'm not going to put plans in Google's mouth, but envision
>     yourself in the same set of circumstances: you own a fully-paid
>     H.264 license, already ship an H.264 codec as part of your
>     browser, and are getting a huge black eye for not interoperating
>     with significant major browsers. What do you do?
>
>     Okay. Now, shift your imagined role: you're a non-browser
>     implementor, and discover the facts on the ground to be those
>     described above. You can deploy VP8 and work with two of the four
>     major browsers, or you can deploy H.264 and work with all four.
>     Yeah, you might not be in love with the structural issues involved
>     in integrating the Cisco library [1]  -- and I'm certainly not --
>     but you're not actually precluded from using H.264. What do *you* do?
>
>     Which is a kind of long way to get to the fact that I think we're
>     in a situation where H.264 is a de facto MTI codec anyway [2].
>
>     Now, imagine you're working in an SDO with this particular set of
>     writing on the wall. You have a solid decision to choose one MTI
>     video codec. You can choose one that's going to be functionally
>     MTI regardless of what you say, or you can choose one that is
>     quite probably going to be ignored by some non-trivial set of
>     implementors.
>
>     So. What do *we* do?
>
>     /a
>
>     ____
>     [1] There's been quite a bit of handwringing around the impact
>     this has on iOS developers, as they cannot download modules at
>     runtime. Bear in mind that these are curated applications, with a
>     single, well-accounted-for distribution point. These are not libre
>     software by a long shot, and they don't need to worry about the
>     implications of third parties compiling their own versions. So,
>     these implementors statically link in the OpenH264 library, and
>     are exempted for the first 100,000 instances they ship each year.
>     Beyond that point, they're not "small fish" any more. Back when I
>     was one of the owners of the company I worked at, "complications
>     arising from selling more than 100,000 copies a year" is the kind
>     of thing that I would place on a list titled "problems I wish I had."
>
>     [2] And to be clear, this is *not* the result I would have
>     preferred. But I recognize that this isn't about my personal
>     preferences. I find myself in the odd position of actually arguing
>     for the position contrary to what I think is ideal, simply because
>     I think it is the only practical path to success.
>
>     _______________________________________________
>     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


--------------020500040402040802070208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    


          Allow me to throw some more water on Adam's analysis :)

      
    
        
  1. Chrome = 46% of the market. IE + Safari = 23% of the market.
          Source: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
    
          
    2. 
        
      
          
    1. It doesn't matter how many browsers you own. What matters
            is market-share. In fact, the more browsers you have to
            support, the more difficult it is to deploy and test the
            app.
      2. 
          
    2. Now... Why would I break my back for 23% of the market
            *and* pay royalties when I can get 46% of the market for
            very little effort (ease of deploying/testing) and pay no
            royalties?
      3. 
        
    
        
  2. If what you say is true, it is in Google's best interest to
          get Firefox to drop H.264 and then drop H.264 itself in order
          to even the odds. Now, guess where the vast majority of
          Firefox's funding comes from?
    
        
    3. 
      

      
    I don't think these kinds of politics should come into
        play, but clearly the situation is a lot more nuanced than
        previously mentioned.

      

      
Gili

      

      On 08/11/2013 6:20 PM, Peter Thatcher wrote:

    

    

      

        
You are responding to a
          little speculation with a lot of speculation, which doesn't
          seem very valuable.  What should *I* do?  Respond with more
          speculation, of course.

        


        

        
I will speculate that
          there is a group of developers that would ignore an H.264 MTI:
           FOSS projects.  They will ignore it because they can't
          implement it.  To them, MT(IMPLEMENT) becomes
          MT(IGNORE_THE_SPEC).  I speculate this includes FOSS browsers,
          include the Firefox source code and (with no extra knowledge
          from my employer; it's just speculation) Chromium and FOSS
          forks of both Firefox and Chromium.  I further speculate this
          will include FOSS non-browser RTCWEB endpoints, such as FOSS
          RTC mobile apps.  

        


        

        
So there's my
          speculation in response to your speculation in response to
          Stephan's speculation, probably without value, but perhaps
          worth reminding everyone that some people (FOSS projects) will
          have to ignore the spec if H.264 is the MTI, because they have
          no choice (at least in countries where software patents are
          enforced).  Of course, you may then speculate in return that
          no one cares about FOSS projects and browsers, which I
          speculate would be an ironic coming from someone representing
          a FOSS project.

        


        

        


        

        


        

        


        

        


        

        


          

          
On Fri, Nov 8, 2013 at 2:55 PM, Adam
            Roach <adam@nostrum.com>
            wrote:

            

              

                
On 11/7/13 18:57, Stephan Wenger wrote:

                

                
...a decision for either of the
                  two candidate codecs will be ignored by a significant
                  part of the implementer community.

                

                I'm not sure that's true any longer. Indulge me in a bit
                of armchair game theory application.

                

                Let's start by looking at ground zero: the browsers.
                Considering the public statements that have been made, I
                think it's fairly safe to assume that the following can
                be taken as given:

                

                
    
                  
  1. Chrome will support at least VP8.
    2. 
                  
  2. Firefox will support both VP8 and H.264.
    3. 
                  
  3. Internet Explorer is almost certain to support
                    H.264.
    4. 
                  
  4. Safari (including Mobile Safari) is almost certain
                    to support H.264.
    5. 
                

                

                If the codecs are *only* those called out above, then
                you'll end up with an interesting situation in which IE,
                Safari, and Firefox can all mutually interoperate;
                Chrome and Firefox can interoperate with each other; and
                Chrome cannot interoperate with anything else.

                

                I'm not going to put plans in Google's mouth, but
                envision yourself in the same set of circumstances: you
                own a fully-paid H.264 license, already ship an H.264
                codec as part of your browser, and are getting a huge
                black eye for not interoperating with significant major
                browsers. What do you do?

                

                Okay. Now, shift your imagined role: you're a
                non-browser implementor, and discover the facts on the
                ground to be those described above. You can deploy VP8
                and work with two of the four major browsers, or you can
                deploy H.264 and work with all four. Yeah, you might not
                be in love with the structural issues involved in
                integrating the Cisco library [1]  -- and I'm certainly
                not -- but you're not actually precluded from using
                H.264. What do *you* do?

                

                Which is a kind of long way to get to the fact that I
                think we're in a situation where H.264 is a de facto MTI
                codec anyway [2].

                

                Now, imagine you're working in an SDO with this
                particular set of writing on the wall. You have a solid
                decision to choose one MTI video codec. You can choose
                one that's going to be functionally MTI regardless of
                what you say, or you can choose one that is quite
                probably going to be ignored by some non-trivial set of
                implementors.

                

                So. What do *we* do?

                

                /a

                

                ____

                [1] There's been quite a bit of handwringing around the
                impact this has on iOS developers, as they cannot
                download modules at runtime. Bear in mind that these are
                curated applications, with a single, well-accounted-for
                distribution point. These are not libre software by a
                long shot, and they don't need to worry about the
                implications of third parties compiling their own
                versions. So, these implementors statically link in the
                OpenH264 library, and are exempted for the first 100,000
                instances they ship each year. Beyond that point,
                they're not "small fish" any more. Back when I was one
                of the owners of the company I worked at, "complications
                arising from selling more than 100,000 copies a year" is
                the kind of thing that I would place on a list titled
                "problems I wish I had."

                

                [2] And to be clear, this is *not* the result I would
                have preferred. But I recognize that this isn't about my
                personal preferences. I find myself in the odd position
                of actually arguing for the position contrary to what I
                think is ideal, simply because I think it is the only
                practical path to success.

              

              

              _______________________________________________

              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


    

    

  


--------------020500040402040802070208--

From adam@nostrum.com  Fri Nov  8 15:48:49 2013
Return-Path: 
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 CBE1D21E8085 for ; Fri,  8 Nov 2013 15:48:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.53
X-Spam-Level: 
X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 zKNhLx-s+nLP for ; Fri,  8 Nov 2013 15:48:49 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 432E121E805F for ; Fri,  8 Nov 2013 15:48:49 -0800 (PST)
Received: from dhcp-b7d7.meeting.ietf.org (dhcp-b7d7.meeting.ietf.org [31.133.183.215]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA8Nmaab076194 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 8 Nov 2013 17:48:37 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <527D7854.1080307@nostrum.com>
Date: Fri, 08 Nov 2013 15:48:36 -0800
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Peter Thatcher 
References:  <527D6BFA.9090509@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 31.133.183.215 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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 23:48:49 -0000

On 11/8/13 15:20, Peter Thatcher wrote:
> [S]ome people (FOSS projects) will have to ignore the spec if H.264 is 
> the MTI, because they have no choice... 

You appear to have somehow missed Cisco's announcement last week.

> Of course, you may then speculate in return that no one cares about 
> FOSS projects and browsers, which I speculate would be an ironic 
> coming from someone representing a FOSS project.

I think your assertion is trivially disproved by the fact that we, as a 
FOSS project, are going to support H.264 for WebRTC.

/a

From pthatcher@google.com  Fri Nov  8 16:17:38 2013
Return-Path: 
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 0B40B21E809D for ; Fri,  8 Nov 2013 16:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Level: 
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 GrStkEfCVqif for ; Fri,  8 Nov 2013 16:17:37 -0800 (PST)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 791E921E8085 for ; Fri,  8 Nov 2013 16:17:37 -0800 (PST)
Received: by mail-pd0-f169.google.com with SMTP id q10so2828439pdj.0 for ; Fri, 08 Nov 2013 16:17:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jtwQUVGQXFje+aKr7/Ev8igQ84ieo5w0wnMFqtdoLq0=; b=KPoyr4tAzbYOns9aI71LR9wB8caJpy9BD8Y6HUop/do8uxOnzzo3WDyXm48mycLslA O72+Pk5X04YPVYi7rLUVTq/fvLb+svMvSaklyodxwKbC5EfUGcNi/lkl+pGcRtWYUtpM pgW/fxjg8b1KmdaWlMRhQmItXKe24BBoCvJRLbX1XKl/iOtVqAp6KOsA7c4AbPutFQ0J ImIrqoQCtKZ89nWckkMkef6JDiR9AHlPDnOqZv4eBcaK40GVE7a2U6l9cy1jXeGH6vv3 0ebxpO5Zf+kNAGoE3+t4CQ+xHOEHL/lbPoDxNnWr+efBwBv/v65NSHitjR2ivKCrWnwG 2NUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jtwQUVGQXFje+aKr7/Ev8igQ84ieo5w0wnMFqtdoLq0=; b=hAr8HT6t1oqhRbWEApCXJCKOSOtlSK8UlbGsB2bmYD30HqZr3uz87w2zu5uhGt6Zqb e+ek/0gSXIPDat1UakH46YjZJ1QjYTzg3cHnoCTXatxp20otR9ieMWK2Rv45pHXxGTaG 9HYs5QlnLKhJkdIY9XjhN2dK1pf81TcvOQ0YjF5Eboyo+Jq6J2p7KZ7aR/B3XvXEBIos vdCNq6ADBL5e73IYTsdk9DB7ot/mv4hGHbf2YQRGdNHSZ8Co5JxCzDw20HpJdmeobfj8 +a6NILQs35GBrz2dVowf+M/sRoMW0KhXcOd2Apb2KVj6D1ImeiTP3Nxzo9sU+vVHsBra LRGw==
X-Gm-Message-State: ALoCoQkEtE/NJ2OVfPiIeApVkoITubBVYHezOpVo9HUTVVouHDy0IbI/idKVtht2omzDYila2jhHtsGCEyYC4+iEW7rX7d1SLjXxEhvcHpa9ucuSlfDebi+3xvHNoKqqhacT7C0SD924/gLzAb/kyhAgcFSQhxCArCImNJz/XXRpid+qHzLSa3DXhhPClEfnZV0izpotQtAj
X-Received: by 10.66.227.39 with SMTP id rx7mr18807052pac.44.1383956257151; Fri, 08 Nov 2013 16:17:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.66.163.234 with HTTP; Fri, 8 Nov 2013 16:16:57 -0800 (PST)
In-Reply-To: <527D7854.1080307@nostrum.com>
References:  <527D6BFA.9090509@nostrum.com>  <527D7854.1080307@nostrum.com>
From: Peter Thatcher 
Date: Fri, 8 Nov 2013 16:16:57 -0800
Message-ID: 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=047d7b111f3f17b20904eab36d77
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 00:17:38 -0000

--047d7b111f3f17b20904eab36d77
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 8, 2013 at 3:48 PM, Adam Roach  wrote:

> On 11/8/13 15:20, Peter Thatcher wrote:
>
>> [S]ome people (FOSS projects) will have to ignore the spec if H.264 is
>> the MTI, because they have no choice...
>>
>
> You appear to have somehow missed Cisco's announcement last week.
>
>
Of course, you may then speculate in return that no one cares about FOSS
>> projects and browsers, which I speculate would be an ironic coming from
>> someone representing a FOSS project.
>>
>
> I think your assertion is trivially disproved by the fact that we, as a
> FOSS project, are going to support H.264 for WebRTC.
>
>
I'll let other FOSS projects speak for themselves (and Debian and Fedora
already have, I believe), but I speculate many of them will disagree with
you.=E2=80=8B
=E2=80=8B
=E2=80=8B


As a long-time FOSS developer myself (in small things; I claim no big
achievements), I personally don't see how the Cisco announcement changes
anything for a FOSS project, Firefox included.  Firefox still can't ship a
plugin-less browser with H.264, and neither can any FOSS project (at least
in nations where software patents are enforced).  But again, I'll let them
speak for themselves rather than claiming that one FOSS proves some
position for all of them.

And for that matter, this is all re-treading all the same arguments.  I
only keep commenting because it seems that FOSS projects (outside of
Firefox) seem poorly represented in this discussion, so I thought someone
should speak up for them a bit at times when they seem to be ignored.  I
hope this will be sufficient.


=E2=80=8B=E2=80=8B


=E2=80=8B=E2=80=8B




> /a
>

--047d7b111f3f17b20904eab36d77
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Fri, Nov 8, 2013 at 3:48 PM, Adam Roach <<=
a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g=
t; wrote:



On 11/8/13 15:20, Peter Thatcher wrote:



[S]ome people (FOSS projects) will have to ignore the spec if H.264 is the =
MTI, because they have no choice... 





You appear to have somehow missed Cisco's announcement last week.
=C2=A0



Of course, you may then sp=
eculate in return that no one cares about FOSS projects and browsers, which=
 I speculate would be an ironic coming from someone representing a FOSS pro=
ject.







I think your assertion is trivially disproved by the fact that we, as a FOS=
S project, are going to support H.264 for WebRTC.



I'll let other FOSS projects speak for themselves (and Debian and Fed=
ora already have, I believe), but I speculate many of them will disagree wi=
th you.=E2=80=8B


=E2=80=8B
=E2=80=8B=
 =C2=A0




=

As a long-time FOSS developer myself (in small things; I claim no=
 big achievements), I personally don't see how the Cisco announcement c=
hanges anything for a FOSS project, Firefox included. =C2=A0Firefox still c=
an't ship a plugin-less browser with H.264, and neither can any FOSS pr=
oject (at least in nations where software patents are enforced). =C2=A0But =
again, I'll let them speak for themselves rather than claiming that one=
 FOSS proves some position for all of them.



=

=



And for that matter, this is all re-treading all the same arguments. =C2=A0=
I only keep commenting because it seems that FOSS projects (outside of Fire=
fox) seem poorly represented in this discussion, so I thought someone shoul=
d speak up for them a bit at times when they seem to be ignored. =C2=A0I ho=
pe this will be sufficient.



=

=




=E2=80=8B=E2=80=8B


=E2=
=80=8B=E2=80=8B




=C2=A0

/a





--047d7b111f3f17b20904eab36d77--

From cowwoc@bbs.darktech.org  Fri Nov  8 16:24:37 2013
Return-Path: 
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 9DE4C11E80FB for ; Fri,  8 Nov 2013 16:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 yXif1AFMhpCl for ; Fri,  8 Nov 2013 16:24:31 -0800 (PST)
Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id B6E5311E80E9 for ; Fri,  8 Nov 2013 16:24:31 -0800 (PST)
Received: by mail-ie0-f177.google.com with SMTP id e14so4467700iej.36 for ; Fri, 08 Nov 2013 16:24:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=20H7Ji66OjIboFHcLwY5hMTKPCWa789f13zdZRFKHAc=; b=D9+FlFG4FqEQbkmUknn43bbjbnK+/i/lgM30dB47xnmM7OB8a4HWfSoFjnhdeyXi4C Eu8OetZhH7GqTBtYZfKy4BCCcLejWUacm00S30n4GmZzYQqWU++AHUR2d6wg/VlgmivK OHlqAtnKT6M/tc6LOfd8b3LEtCk4ZAu875NOE8vtN8Nwz94pSF0C31QsiEl0ygmLToAT fEy+1bGe4m0txlfLIW0PDOFu0+mUA1I14PfwNP4mw0Rb0kHNZxT7077g9vGO0eDoPiSx eufsoCbyyf9w9ATrwy7xva9OOzD/dsEc+Fuou5Y/kl7WyTSM0zlxMF+o9Jy0ZNa/IwKi TgJQ==
X-Gm-Message-State: ALoCoQmSoVgy50V+NPvlsGlYhvlyrmMwI8yh1qyzn+NWT7gJ4AuclpEhqIQqXMXyUJ+IlSxHB5Kc
X-Received: by 10.50.4.105 with SMTP id j9mr4451684igj.52.1383956670800; Fri, 08 Nov 2013 16:24:30 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f19sm5837584igz.1.2013.11.08.16.24.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 16:24:29 -0800 (PST)
Message-ID: <527D80BB.2040909@bbs.darktech.org>
Date: Fri, 08 Nov 2013 19:24:27 -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: rtcweb@ietf.org
References:  <527D6BFA.9090509@nostrum.com>		<527D7854.1080307@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 00:24:37 -0000

On 08/11/2013 7:16 PM, Peter Thatcher wrote:
> And for that matter, this is all re-treading all the same arguments. 
>  I only keep commenting because it seems that FOSS projects (outside 
> of Firefox) seem poorly represented in this discussion, so I thought 
> someone should speak up for them a bit at times when they seem to be 
> ignored.  I hope this will be sufficient.

This is a good point and I think this is equally true for non-browser 
applications, most of which do not have a plugin architecture.

Gili

From juberti@google.com  Fri Nov  8 16:48:23 2013
Return-Path: 
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 52DC111E80FB for ; Fri,  8 Nov 2013 16:48:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.785
X-Spam-Level: 
X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=0.192,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ebK-tVsBH42B for ; Fri,  8 Nov 2013 16:48:22 -0800 (PST)
Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7E611E80E3 for ; Fri,  8 Nov 2013 16:48:22 -0800 (PST)
Received: by mail-ve0-f174.google.com with SMTP id pa12so1990640veb.33 for ; Fri, 08 Nov 2013 16:48:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UCk+50l/yiVAeDcIqjkMRkxdwuv39BoQc/rzwo8r4oI=; b=KwQCjVng/aocVPvYgBn4nWaXYh/6Qed4QHWa/YBgfw7Ov8+HwY7+bK9Md/Meo3WNvI 4VDFKoweh8tr/BEOXo5vEKMqSaPXL2MQIriMseKBBMFcbR/T+O8CBrSZVNSHx3MMqLy4 G1UTRpq4gpCM8rUUgtuZO4Kt4R4yeazZ0OrjWeEbdqXJa8g/AZfpSHXmRZOARXUTkirD zXw1fEoA7PoZY8vObBNDNPV5xtBon97KeS220zfV5q3vhSPj84wppPjWhQTaOytFuOrh 7Jp50C0xCTAIyma8srGYmB8uL+/lv+E4jNHY4EGDCr9zu87suT4yd9ZR5KzuLAY378UU Q61Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UCk+50l/yiVAeDcIqjkMRkxdwuv39BoQc/rzwo8r4oI=; b=dZgJba9pM+M7WK9GVG4VkpydEMQRHSPF76Lo+tN+HPwMdxdBFl/J0fGnqV5HvpJzke oL3cEWkoM7hNYrmWeLdKxkUX0D9PTdkZerTMSugI8CzJ0C4xclVbELx8s9f7NpsOzn8b 3hC/hnHvNzn73XjSD77/51PG+aPgEmyt99ZYprxeleNjK3kcNeho0gdaL5zu7ooJyLwP oX8uBc0TvaNGbSN6XCb+ecJsjAy03H3sWgwPijjt1znCN6qNi0NdDZZijsCU2wwl7Qde TWh+vV4fJteVOSoqPa4MppF6bq0TotWAq3QQZ7RkrJBBEPi/vBnxBtWEXVj4h6JvRTby pwfQ==
X-Gm-Message-State: ALoCoQkQW3PBSSu+IwXJ6d0r57U11Se2ltAzgktj7n729KjAeqOh+Domh975PRciFmJ5iw8npTPp8VGbeqT4l5cyrjRu/oFuOpMuZswoqR8RjjeP4URkIdXTEkoy3DkO6Hi/8UzXvWyLpghTiFoaYvNX8z0pfN4OhbNCO4TzDDEdYAb24XzLYBX+NlHGwS6OOruIsLWXdtem
X-Received: by 10.58.143.17 with SMTP id sa17mr14546786veb.14.1383958101540; Fri, 08 Nov 2013 16:48:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 8 Nov 2013 16:48:01 -0800 (PST)
In-Reply-To: <527D6BFA.9090509@nostrum.com>
References:  <527D6BFA.9090509@nostrum.com>
From: Justin Uberti 
Date: Fri, 8 Nov 2013 16:48:01 -0800
Message-ID: 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=047d7b6d95ee06eae604eab3db7d
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 00:48:23 -0000

--047d7b6d95ee06eae604eab3db7d
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 8, 2013 at 2:55 PM, Adam Roach  wrote:

>  On 11/7/13 18:57, Stephan Wenger wrote:
>
> ...a decision for either of the two candidate codecs will be ignored by a
> significant part of the implementer community.
>
>
> I'm not sure that's true any longer. Indulge me in a bit of armchair game
> theory application.
>
> Let's start by looking at ground zero: the browsers. Considering the
> public statements that have been made, I think it's fairly safe to assume
> that the following can be taken as given:
>
>
>    1. Chrome will support at least VP8.
>    2. Firefox will support both VP8 and H.264.
>    3. Internet Explorer is almost certain to support H.264.
>    4. Safari (including Mobile Safari) is almost certain to support H.264.
>
>
> If the codecs are *only* those called out above, then you'll end up with
> an interesting situation in which IE, Safari, and Firefox can all mutually
> interoperate; Chrome and Firefox can interoperate with each other; and
> Chrome cannot interoperate with anything else.
>
> I'm not going to put plans in Google's mouth, but envision yourself in the
> same set of circumstances: you own a fully-paid H.264 license, already ship
> an H.264 codec as part of your browser, and are getting a huge black eye
> for not interoperating with significant major browsers. What do you do?
>

I'm scratching my head over how the introduction of a new WebRTC
implementation that intentionally doesn't work with Chrome would reflect
poorly on *Google*, especially with the "little guy versus big guy"
narrative that is developing around this issue.


> Okay. Now, shift your imagined role: you're a non-browser implementor, and
> discover the facts on the ground to be those described above. You can
> deploy VP8 and work with two of the four major browsers, or you can deploy
> H.264 and work with all four. Yeah, you might not be in love with the
> structural issues involved in integrating the Cisco library [1]  -- and I'm
> certainly not -- but you're not actually precluded from using H.264. What
> do *you* do?
>
> Which is a kind of long way to get to the fact that I think we're in a
> situation where H.264 is a de facto MTI codec anyway [2].
>
> Now, imagine you're working in an SDO with this particular set of writing
> on the wall. You have a solid decision to choose one MTI video codec. You
> can choose one that's going to be functionally MTI regardless of what you
> say, or you can choose one that is quite probably going to be ignored by
> some non-trivial set of implementors.
>
> So. What do *we* do?
>
> /a
>
> ____
> [1] There's been quite a bit of handwringing around the impact this has on
> iOS developers, as they cannot download modules at runtime. Bear in mind
> that these are curated applications, with a single, well-accounted-for
> distribution point. These are not libre software by a long shot, and they
> don't need to worry about the implications of third parties compiling their
> own versions. So, these implementors statically link in the OpenH264
> library, and are exempted for the first 100,000 instances they ship each
> year. Beyond that point, they're not "small fish" any more. Back when I was
> one of the owners of the company I worked at, "complications arising from
> selling more than 100,000 copies a year" is the kind of thing that I would
> place on a list titled "problems I wish I had."
>
> [2] And to be clear, this is *not* the result I would have preferred. But
> I recognize that this isn't about my personal preferences. I find myself in
> the odd position of actually arguing for the position contrary to what I
> think is ideal, simply because I think it is the only practical path to
> success.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--047d7b6d95ee06eae604eab3db7d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Fri, Nov 8, 2013 at 2:55 PM, Adam Roach <adam@nostrum.com>=
; wrote:




 =20
   =20
 =20
  

    
On 11/7/13 18:57, Stephan Wenger wrote:

    

    
...a
      decision for either of the two candidate codecs will be ignored by
      a significant part of the implementer community.

    

    I'm not sure that's true any longer. Indulge me in a bit of arm=
chair
    game theory application.

    

    Let's start by looking at ground zero: the browsers. Considering th=
e
    public statements that have been made, I think it's fairly safe to
    assume that the following can be taken as given:

    

    
    
      
  1. Chrome will support at least VP8.
    2. 
      
  2. Firefox will support both VP8 and H.264.
    3. 
      
  3. Internet Explorer is almost certain to support H.264.
    4. 
      
  4. Safari (including Mobile Safari) is almost certain to support
        H.264.
    5. 
    

    

    If the codecs are *only* those called out above, then you'll end up
    with an interesting situation in which IE, Safari, and Firefox can
    all mutually interoperate; Chrome and Firefox can interoperate with
    each other; and Chrome cannot interoperate with anything else.

    

    I'm not going to put plans in Google's mouth, but envision your=
self
    in the same set of circumstances: you own a fully-paid H.264
    license, already ship an H.264 codec as part of your browser, and
    are getting a huge black eye for not interoperating with significant
    major browsers. What do you do?

I'm scratching my head over how the introduction of a new WebRTC imp=
lementation that intentionally doesn't work with Chrome would reflect p=
oorly on *Google*, especially with the "little guy versus big guy"=
; narrative that is developing around this issue.





    

    Okay. Now, shift your imagined role: you're a non-browser
    implementor, and discover the facts on the ground to be those
    described above. You can deploy VP8 and work with two of the four
    major browsers, or you can deploy H.264 and work with all four.
    Yeah, you might not be in love with the structural issues involved
    in integrating the Cisco library [1]=C2=A0 -- and I'm certainly not=
 --
    but you're not actually precluded from using H.264. What do *you*
    do?

    

    Which is a kind of long way to get to the fact that I think we're i=
n
    a situation where H.264 is a de facto MTI codec anyway [2].

    

    Now, imagine you're working in an SDO with this particular set of
    writing on the wall. You have a solid decision to choose one MTI
    video codec. You can choose one that's going to be functionally MTI
    regardless of what you say, or you can choose one that is quite
    probably going to be ignored by some non-trivial set of
    implementors.

    

    So. What do *we* do?

    

    /a

    

    ____

    [1] There's been quite a bit of handwringing around the impact this
    has on iOS developers, as they cannot download modules at runtime.
    Bear in mind that these are curated applications, with a single,
    well-accounted-for distribution point. These are not libre software
    by a long shot, and they don't need to worry about the implications
    of third parties compiling their own versions. So, these
    implementors statically link in the OpenH264 library, and are
    exempted for the first 100,000 instances they ship each year. Beyond
    that point, they're not "small fish" any more. Back when =
I was one
    of the owners of the company I worked at, "complications arising
    from selling more than 100,000 copies a year" is the kind of thing
    that I would place on a list titled "problems I wish I had."<=
br>
    

    [2] And to be clear, this is *not* the result I would have
    preferred. But I recognize that this isn't about my personal
    preferences. I find myself in the odd position of actually arguing
    for the position contrary to what I think is ideal, simply because I
    think it is the only practical path to success.

  



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--047d7b6d95ee06eae604eab3db7d--

From ron@debian.org  Fri Nov  8 22:00:06 2013
Return-Path: 
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 8A65F11E80F5 for ; Fri,  8 Nov 2013 22:00:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
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 6BHpIxUWnMUC for ; Fri,  8 Nov 2013 21:59:51 -0800 (PST)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 20CA811E814B for ; Fri,  8 Nov 2013 21:59:38 -0800 (PST)
Received: from ppp14-2-2-76.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.2.76]) by ipmail06.adl6.internode.on.net with ESMTP; 09 Nov 2013 16:29:38 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 969784F8F3 for ; Sat,  9 Nov 2013 16:29:36 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i7Yr8IFp71Xi for ; Sat,  9 Nov 2013 16:29:35 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id BCA154F902; Sat,  9 Nov 2013 16:29:35 +1030 (CST)
Date: Sat, 9 Nov 2013 16:29:35 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20131109055935.GI3245@audi.shelbyville.oz>
References:  <527D6BFA.9090509@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <527D6BFA.9090509@nostrum.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 06:00:06 -0000

On Fri, Nov 08, 2013 at 02:55:54PM -0800, Adam Roach wrote:
> On 11/7/13 18:57, Stephan Wenger wrote:
> >...a decision for either of the two candidate codecs will be
> >ignored by a significant part of the implementer community.
> 
> I'm not sure that's true any longer. Indulge me in a bit of armchair
> game theory application.
> 
> Let's start by looking at ground zero: the browsers. Considering the
> public statements that have been made, I think it's fairly safe to
> assume that the following can be taken as given:
> 
> 1. Chrome will support at least VP8.
> 2. Firefox will support both VP8 and H.264.
> 3. Internet Explorer is almost certain to support H.264.
> 4. Safari (including Mobile Safari) is almost certain to support H.264.

Except the chairs already noted at the meeting that these browser
vendors had all indicated they would support whatever MTI decision
the working group made.

So game theory still says the optimal solution is the one that
doesn't automatically lock out other players though restrictive
licencing.


And the only non-browser, mobile-vendor, implementation that I'm
presently aware of, was, last I looked, still steadfastly pretending
that Opus didn't exist, for whatever that is worth to the game.


For myself personally, I'm likewise kind of torn, since I don't
think either option is perfectly ideal, but since an option that
can't freely be used by anyone is obviously unacceptable for a
standard that hopes to become ubiquitous, that really only leaves
assessing if the other choice does really have some similar issue
that it also would need to resolve before we could choose it.

If both options were equal in that respect, then to me a coin-flip
would be as good a way as any to end the impasse - but I can't see 
how H.264 can possibly dig itself out of the hole it was designed
into in this respect, so the remaining question is what, if anything
would make VP8 still unacceptable.

And that hasn't really been answered except with unsubstantiated
Fears, of unseen threats, that also apply equally or moreso to H.264.


Nobody has answered how Cisco intends to mitigate risk from the Nokia
portfolio that remains outside the MPEG LA pool, which they aren't
licencing for users of their blob.  Pretending that doesn't exist
doesn't make it go away, and nobody doubts it _does_ read on H.264.

And that's before we look at the amusing situation of them declaring
their H.264 IPR against VP8 here, but _not_ against H.264 ...

  Ron



From ron@debian.org  Fri Nov  8 22:50:26 2013
Return-Path: 
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 0DF4A11E811A for ; Fri,  8 Nov 2013 22:50:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
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 SHzj3Dk3rwD8 for ; Fri,  8 Nov 2013 22:50:21 -0800 (PST)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id AE72111E80E7 for ; Fri,  8 Nov 2013 22:50:20 -0800 (PST)
Received: from ppp14-2-2-76.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.2.76]) by ipmail07.adl2.internode.on.net with ESMTP; 09 Nov 2013 17:20:18 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 8C2494F8F3 for ; Sat,  9 Nov 2013 17:07:55 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id p1V8FdLIRpOQ for ; Sat,  9 Nov 2013 17:07:54 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 5A86F4F902; Sat,  9 Nov 2013 17:07:54 +1030 (CST)
Date: Sat, 9 Nov 2013 17:07:54 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20131109063754.GJ3245@audi.shelbyville.oz>
References:  <527C38FF.6040000@nostrum.com> <20131108123109.GF3245@audi.shelbyville.oz> <527D0AC4.1080704@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <527D0AC4.1080704@nostrum.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] On the form of the question (was Re: Alternative consensus and MTI video codecs)
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 06:50:26 -0000

On Fri, Nov 08, 2013 at 08:01:08AM -0800, Adam Roach wrote:
> On 11/8/13 04:31, Ron wrote:
> >...what we had today was essentially "just a vote".  If it had been conclusive, that would have been great, but it wasn't...
> 
> Well, to be fair, it did involve a rather long discussion of the
> various factors impacting the decision. The show of hands was
> ostensibly an attempt to suss out whether the arguments had proven
> compelling enough to push forward with one codec over the other.

Right, I didn't mean that to sound critical of the chairs, I had my
chance to suggest alternatives when they first proposed this too,
I only meant that we tried something, it didn't get us a resolution,
but that failure is not the same thing as the working group reaching
the end of its rope for establishing consensus by more normal means.

We have still unanswered objections, I don't see how invoking any
alternative method can ignore those until they are answered (and
then also seek to call the result consensus).

And since the chairs asked for suggestions on "where to go from here"
I'm suggesting we get answers to those things and continue with a more
usual approach to achieving consensus on the list.  If people can't
answer them in a satisfactory way, they obviously remain blockers to
accepting that option as having consensus.


> On the other hand, what *did* happen was that we had roughly 50% of
> the room say that they were willing to live with H.264, and roughly
> 30% of the room say they were willing to live with VP8. This, after
> the chairs *strongly* *encouraged* people who could live with either
> option to raise their hands for both options. We didn't explicitly
> ask for who was in both camps (and those people at the front of the
> room facing the participants did nothing to gauge overlap), nor did
> we try to suss out who was abstaining by not raising their hand.

The jabber room by contrast, split more like 80/20 in favour of VP8.
And unless I'm missing someone there was no overlap there at all.

(And was endcapped with the comment: "So, those that actually use the
 Internet, by all data, support option #2, VP8."  :)


I still don't think we can call anything conclusive from that, except
the two groups were clearly not representative of each other in any
statistically significant way, and "dance with the one that brung ya"
and all that ...


> As a result, the numbers are meaningless. On one extreme: If those
> sets of people were completely disjoint, then we're nowhere near
> consensus. At the other extreme: if the set of people who could
> accept VP8 were a strict subset of the set of people who could
> accept H.264, then we would have obvious consensus and could move
> forward. I know that neither of these scenarios are true, but
> measuring where the participants fell in that continuum would have
> been the true measure of the sense of the room.
> 
> So, sadly, we learned nothing.
> 
> For the record, and I'm hoping others will follow suit (since, as
> you pointed out, consensus is measured on the list): I'm of the
> opinion that either of the two options on the table are
> acceptable[1][2].

I'd like to reserve my final call until we've seen the answers to
the objections on the list, but a choice with definite unresolved
blockers fairly obviously can't be acceptable as consensus.

  Ron



From mohammedsraad@raadtech.com  Sat Nov  9 00:02:41 2013
Return-Path: 
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 8F2B011E817A for ; Sat,  9 Nov 2013 00:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level: 
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.627,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 iAhc+fdnwIa2 for ; Sat,  9 Nov 2013 00:02:37 -0800 (PST)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id D6B8E11E8131 for ; Sat,  9 Nov 2013 00:02:36 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id ey11so362801wid.7 for ; Sat, 09 Nov 2013 00:02:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=E90arKCXxu/3f9Gn5zwLAga3G/NA8O006yAcsImIK/s=; b=nNEqVUl3qDNFXFNnTDsXuhc7cLjpbIMVqI46EK1sSpIDXROaGjdY5s1AR4Vxgaoa92 uCdZsvxC+AXhhR9u/Hc6oXr8wbDf3R8KyRFrYCCx2fkdmtgVH7OUPRAqzlzpJ2dvs3mR rcy4Wosz2C2BocSg9DcSdBaMQMd6O2X5QlnqvVx2enwb5ktVNj2gBaNKXKpRDZ2Xwun8 XdcnZk/Tuvxh3e2ODBF6Y1D6iyJBETDLFIDlSAPWNlO8XMGL2zgfXSW6sUsDJ96a0Lxm sdRheYA1P2Q8rZeQKRSLBpjPyao2y7p+bXfG4ijLto4Bgl67X38bEQfujx0DS5j66kZq 7g9w==
X-Gm-Message-State: ALoCoQmeKia+li6rvl4FZ9GKfXiS/EZuqs+qXfOuYSRwdPKgSd9AtDAl2GNtZJDzJdfCjlRU8gO/
MIME-Version: 1.0
X-Received: by 10.180.231.6 with SMTP id tc6mr5248204wic.59.1383984155889; Sat, 09 Nov 2013 00:02:35 -0800 (PST)
Received: by 10.194.179.166 with HTTP; Sat, 9 Nov 2013 00:02:35 -0800 (PST)
In-Reply-To: <527D6BFA.9090509@nostrum.com>
References:  <527D6BFA.9090509@nostrum.com>
Date: Sat, 9 Nov 2013 19:02:35 +1100
Message-ID: 
From: Mohammed Raad 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=001a1134d1bafcb8b604eab9ebb8
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 08:02:41 -0000

--001a1134d1bafcb8b604eab9ebb8
Content-Type: text/plain; charset=ISO-8859-1

Hi,

One point that does concern me, is that there seems to be a general
acceptance that VP8 does meet the requirements to be selected as MTI, yet
it is still not acceptable to many in your WG. Added to this the various
attempts to dress up H.264 into something that looks as workable as VP8.

I note here that there is now an attempt to present "market realities" in
such a way as to imply H.264 is a defacto MTI. Of course, the game theory
example given does not include any actual deployment numbers and so doesn't
lead to a sound conclusion.

Nonetheless, I do not think that an SDO should be simply guided by market
deployments, decisions should be based on how to best meet the requirements
of a particular project. I'm not saying market information should be
ignored, I am saying that whether or not a particular solution meets a
project's requirements should be the driver behind adoption.

In this case, two camps have developed around two technologies and both
camps have taken steps to make their preferred solution better aligned with
the project's requirements. In such a case it would be ideal if the
technical merit could be used as the deciding factor, but chasing a
decision on that basis is by definition impractical given that two groups
of technologists have already formed - meaning there is enough ambiguity in
the technical information to allow each group to justify its position.

In such situations, one looks for compromise.

In answering the question "what do we do":

I have suggested one possible way to compromise, a couple of people seemed
supportive, others were not.

BR,
Mohammed
On Nov 9, 2013 9:56 AM, "Adam Roach"  wrote:

>  On 11/7/13 18:57, Stephan Wenger wrote:
>
> ...a decision for either of the two candidate codecs will be ignored by a
> significant part of the implementer community.
>
>
> I'm not sure that's true any longer. Indulge me in a bit of armchair game
> theory application.
>
> Let's start by looking at ground zero: the browsers. Considering the
> public statements that have been made, I think it's fairly safe to assume
> that the following can be taken as given:
>
>
>    1. Chrome will support at least VP8.
>    2. Firefox will support both VP8 and H.264.
>    3. Internet Explorer is almost certain to support H.264.
>    4. Safari (including Mobile Safari) is almost certain to support H.264.
>
>
> If the codecs are *only* those called out above, then you'll end up with
> an interesting situation in which IE, Safari, and Firefox can all mutually
> interoperate; Chrome and Firefox can interoperate with each other; and
> Chrome cannot interoperate with anything else.
>
> I'm not going to put plans in Google's mouth, but envision yourself in the
> same set of circumstances: you own a fully-paid H.264 license, already ship
> an H.264 codec as part of your browser, and are getting a huge black eye
> for not interoperating with significant major browsers. What do you do?
>
> Okay. Now, shift your imagined role: you're a non-browser implementor, and
> discover the facts on the ground to be those described above. You can
> deploy VP8 and work with two of the four major browsers, or you can deploy
> H.264 and work with all four. Yeah, you might not be in love with the
> structural issues involved in integrating the Cisco library [1]  -- and I'm
> certainly not -- but you're not actually precluded from using H.264. What
> do *you* do?
>
> Which is a kind of long way to get to the fact that I think we're in a
> situation where H.264 is a de facto MTI codec anyway [2].
>
> Now, imagine you're working in an SDO with this particular set of writing
> on the wall. You have a solid decision to choose one MTI video codec. You
> can choose one that's going to be functionally MTI regardless of what you
> say, or you can choose one that is quite probably going to be ignored by
> some non-trivial set of implementors.
>
> So. What do *we* do?
>
> /a
>
> ____
> [1] There's been quite a bit of handwringing around the impact this has on
> iOS developers, as they cannot download modules at runtime. Bear in mind
> that these are curated applications, with a single, well-accounted-for
> distribution point. These are not libre software by a long shot, and they
> don't need to worry about the implications of third parties compiling their
> own versions. So, these implementors statically link in the OpenH264
> library, and are exempted for the first 100,000 instances they ship each
> year. Beyond that point, they're not "small fish" any more. Back when I was
> one of the owners of the company I worked at, "complications arising from
> selling more than 100,000 copies a year" is the kind of thing that I would
> place on a list titled "problems I wish I had."
>
> [2] And to be clear, this is *not* the result I would have preferred. But
> I recognize that this isn't about my personal preferences. I find myself in
> the odd position of actually arguing for the position contrary to what I
> think is ideal, simply because I think it is the only practical path to
> success.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a1134d1bafcb8b604eab9ebb8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi,


One point that does concern me, is that there seems to be a general acce=
ptance that VP8 does meet the requirements to be selected as MTI, yet it is=
 still not acceptable to many in your WG. Added to this the various attempt=
s to dress up H.264 into something that looks as workable as VP8.


I note here that there is now an attempt to present "market realiti=
es" in such a way as to imply H.264 is a defacto MTI. Of course, the g=
ame theory example given does not include any actual deployment numbers and=
 so doesn't lead to a sound conclusion.


Nonetheless, I do not think that an SDO should be simply guided by marke=
t deployments, decisions should be based on how to best meet the requiremen=
ts of a particular project. I'm not saying market information should be=
 ignored, I am saying that whether or not a particular solution meets a pro=
ject's requirements should be the driver behind adoption.




In this case, two camps have developed around two technologies and both =
camps have taken steps to make their preferred solution better aligned with=
 the project's requirements. In such a case it would be ideal if the te=
chnical merit could be used as the deciding factor, but chasing a decision =
on that basis is by definition impractical given that two groups of technol=
ogists have already formed - meaning there is enough ambiguity in the techn=
ical information to allow each group to justify its position.




In such situations, one looks for compromise. 
In answering the qu=
estion "what do we do":


I have suggested one possible way to compromise, a couple of people seem=
ed supportive, others were not.




BR,

Mohammed


On Nov 9, 2013 9:56 AM, "Adam Roach" &=
lt;adam@nostrum.com> wrote:




 =20
   =20
 =20
  

    
On 11/7/13 18:57, Stephan Wenger wrote:

    

    
...a
      decision for either of the two candidate codecs will be ignored by
      a significant part of the implementer community.

    

    I'm not sure that's true any longer. Indulge me in a bit of arm=
chair
    game theory application.

    

    Let's start by looking at ground zero: the browsers. Considering th=
e
    public statements that have been made, I think it's fairly safe to
    assume that the following can be taken as given:

    

    
    
      
  1. Chrome will support at least VP8.
    2. 
      
  2. Firefox will support both VP8 and H.264.
    3. 
      
  3. Internet Explorer is almost certain to support H.264.
    4. 
      
  4. Safari (including Mobile Safari) is almost certain to support
        H.264.
    5. 
    

    

    If the codecs are *only* those called out above, then you'll end up
    with an interesting situation in which IE, Safari, and Firefox can
    all mutually interoperate; Chrome and Firefox can interoperate with
    each other; and Chrome cannot interoperate with anything else.

    

    I'm not going to put plans in Google's mouth, but envision your=
self
    in the same set of circumstances: you own a fully-paid H.264
    license, already ship an H.264 codec as part of your browser, and
    are getting a huge black eye for not interoperating with significant
    major browsers. What do you do?

    

    Okay. Now, shift your imagined role: you're a non-browser
    implementor, and discover the facts on the ground to be those
    described above. You can deploy VP8 and work with two of the four
    major browsers, or you can deploy H.264 and work with all four.
    Yeah, you might not be in love with the structural issues involved
    in integrating the Cisco library [1]=A0 -- and I'm certainly not --
    but you're not actually precluded from using H.264. What do *you*
    do?

    

    Which is a kind of long way to get to the fact that I think we're i=
n
    a situation where H.264 is a de facto MTI codec anyway [2].

    

    Now, imagine you're working in an SDO with this particular set of
    writing on the wall. You have a solid decision to choose one MTI
    video codec. You can choose one that's going to be functionally MTI
    regardless of what you say, or you can choose one that is quite
    probably going to be ignored by some non-trivial set of
    implementors.

    

    So. What do *we* do?

    

    /a

    

    ____

    [1] There's been quite a bit of handwringing around the impact this
    has on iOS developers, as they cannot download modules at runtime.
    Bear in mind that these are curated applications, with a single,
    well-accounted-for distribution point. These are not libre software
    by a long shot, and they don't need to worry about the implications
    of third parties compiling their own versions. So, these
    implementors statically link in the OpenH264 library, and are
    exempted for the first 100,000 instances they ship each year. Beyond
    that point, they're not "small fish" any more. Back when =
I was one
    of the owners of the company I worked at, "complications arising
    from selling more than 100,000 copies a year" is the kind of thing
    that I would place on a list titled "problems I wish I had."<=
br>
    

    [2] And to be clear, this is *not* the result I would have
    preferred. But I recognize that this isn't about my personal
    preferences. I find myself in the odd position of actually arguing
    for the position contrary to what I think is ideal, simply because I
    think it is the only practical path to success.

  



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb






--001a1134d1bafcb8b604eab9ebb8--

From cowwoc@bbs.darktech.org  Sat Nov  9 00:09:39 2013
Return-Path: 
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 A39E721E805D for ; Sat,  9 Nov 2013 00:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[AWL=-0.612,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 t+KQzYN+GwpD for ; Sat,  9 Nov 2013 00:09:34 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E64111E817D for ; Sat,  9 Nov 2013 00:09:34 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id tp5so4891028ieb.31 for ; Sat, 09 Nov 2013 00:09:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=ky0PCWN8U3XYLAAGKYn9evASzRF8fTCuJFjaV09aqX4=; b=ku305F0u7uoTF+0qkJYYiGWEPoiJwi8Ttsb51yx+vzK6M13qqmOo63gYzme6KRqmvA eFxND4DxVaHWdMgeKbrPzR6KpenJvJrfCnqu3YhXwvSYAznckeWXPcU9n8eEN9ArP752 IrAU0RathYZ+HCX4L6lCYDOaHp89Cr3jaSfIfJPrRuYn6ieLZUHM8c3KGpsxGMVo/mUp oxXQ+Hz5mL9MygvIB+2OQKJpn+qRUvLZM38d7Om9V4DB/yq2m6dBSFHCgHl99sAZNeXg Fpnl0yGaNqLy8M1wdH4CvYN6hV+IbkhP8bY3C6GthJ4jHBO/CieESQvoVgT+i+6Gc7gZ i92Q==
X-Gm-Message-State: ALoCoQmpGL8RlPokc9TnHzve8oQRqz4O1U+vhRPpPGrwy4zLcPC1++Bnj1sk7nv1WSPWi+I1Hz4f
X-Received: by 10.50.154.101 with SMTP id vn5mr5646929igb.35.1383984573559; Sat, 09 Nov 2013 00:09:33 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ka1sm7465981igb.7.2013.11.09.00.09.32 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Nov 2013 00:09:32 -0800 (PST)
Message-ID: <527DEDBA.5010008@bbs.darktech.org>
Date: Sat, 09 Nov 2013 03:09:30 -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: rtcweb@ietf.org
References: 	<527D6BFA.9090509@nostrum.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040604060402020407060104"
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 08:09:39 -0000

This is a multi-part message in MIME format.
--------------040604060402020407060104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


     Someone should put together a spreadsheet listing everyone who gave 
their feedback, their preference and an explanation (regardless of 
whether we agree with it). At this point I've lost track of who said what.

Gili

On 09/11/2013 3:02 AM, Mohammed Raad wrote:
>
> Hi,
>
> One point that does concern me, is that there seems to be a general 
> acceptance that VP8 does meet the requirements to be selected as MTI, 
> yet it is still not acceptable to many in your WG. Added to this the 
> various attempts to dress up H.264 into something that looks as 
> workable as VP8.
>
> I note here that there is now an attempt to present "market realities" 
> in such a way as to imply H.264 is a defacto MTI. Of course, the game 
> theory example given does not include any actual deployment numbers 
> and so doesn't lead to a sound conclusion.
>
> Nonetheless, I do not think that an SDO should be simply guided by 
> market deployments, decisions should be based on how to best meet the 
> requirements of a particular project. I'm not saying market 
> information should be ignored, I am saying that whether or not a 
> particular solution meets a project's requirements should be the 
> driver behind adoption.
>
> In this case, two camps have developed around two technologies and 
> both camps have taken steps to make their preferred solution better 
> aligned with the project's requirements. In such a case it would be 
> ideal if the technical merit could be used as the deciding factor, but 
> chasing a decision on that basis is by definition impractical given 
> that two groups of technologists have already formed - meaning there 
> is enough ambiguity in the technical information to allow each group 
> to justify its position.
>
> In such situations, one looks for compromise.
>
> In answering the question "what do we do":
>
> I have suggested one possible way to compromise, a couple of people 
> seemed supportive, others were not.
>
> BR,
> Mohammed
>
> On Nov 9, 2013 9:56 AM, "Adam Roach"  > wrote:
>
>     On 11/7/13 18:57, Stephan Wenger wrote:
>>     ...a decision for either of the two candidate codecs will be
>>     ignored by a significant part of the implementer community.
>
>     I'm not sure that's true any longer. Indulge me in a bit of
>     armchair game theory application.
>
>     Let's start by looking at ground zero: the browsers. Considering
>     the public statements that have been made, I think it's fairly
>     safe to assume that the following can be taken as given:
>
>      1. Chrome will support at least VP8.
>      2. Firefox will support both VP8 and H.264.
>      3. Internet Explorer is almost certain to support H.264.
>      4. Safari (including Mobile Safari) is almost certain to support
>         H.264.
>
>
>     If the codecs are *only* those called out above, then you'll end
>     up with an interesting situation in which IE, Safari, and Firefox
>     can all mutually interoperate; Chrome and Firefox can interoperate
>     with each other; and Chrome cannot interoperate with anything else.
>
>     I'm not going to put plans in Google's mouth, but envision
>     yourself in the same set of circumstances: you own a fully-paid
>     H.264 license, already ship an H.264 codec as part of your
>     browser, and are getting a huge black eye for not interoperating
>     with significant major browsers. What do you do?
>
>     Okay. Now, shift your imagined role: you're a non-browser
>     implementor, and discover the facts on the ground to be those
>     described above. You can deploy VP8 and work with two of the four
>     major browsers, or you can deploy H.264 and work with all four.
>     Yeah, you might not be in love with the structural issues involved
>     in integrating the Cisco library [1]  -- and I'm certainly not --
>     but you're not actually precluded from using H.264. What do *you* do?
>
>     Which is a kind of long way to get to the fact that I think we're
>     in a situation where H.264 is a de facto MTI codec anyway [2].
>
>     Now, imagine you're working in an SDO with this particular set of
>     writing on the wall. You have a solid decision to choose one MTI
>     video codec. You can choose one that's going to be functionally
>     MTI regardless of what you say, or you can choose one that is
>     quite probably going to be ignored by some non-trivial set of
>     implementors.
>
>     So. What do *we* do?
>
>     /a
>
>     ____
>     [1] There's been quite a bit of handwringing around the impact
>     this has on iOS developers, as they cannot download modules at
>     runtime. Bear in mind that these are curated applications, with a
>     single, well-accounted-for distribution point. These are not libre
>     software by a long shot, and they don't need to worry about the
>     implications of third parties compiling their own versions. So,
>     these implementors statically link in the OpenH264 library, and
>     are exempted for the first 100,000 instances they ship each year.
>     Beyond that point, they're not "small fish" any more. Back when I
>     was one of the owners of the company I worked at, "complications
>     arising from selling more than 100,000 copies a year" is the kind
>     of thing that I would place on a list titled "problems I wish I had."
>
>     [2] And to be clear, this is *not* the result I would have
>     preferred. But I recognize that this isn't about my personal
>     preferences. I find myself in the odd position of actually arguing
>     for the position contrary to what I think is ideal, simply because
>     I think it is the only practical path to success.
>
>     _______________________________________________
>     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


--------------040604060402020407060104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    


          Someone should put together a spreadsheet listing everyone who
      gave their feedback, their preference and an explanation
      (regardless of whether we agree with it). At this point I've lost
      track of who said what.

      

      Gili

      

      On 09/11/2013 3:02 AM, Mohammed Raad wrote:

    

    

      

        
Hi,

        
One point that does concern me, is that there seems to be a
          general acceptance that VP8 does meet the requirements to be
          selected as MTI, yet it is still not acceptable to many in
          your WG. Added to this the various attempts to dress up H.264
          into something that looks as workable as VP8.

        
I note here that there is now an attempt to present "market
          realities" in such a way as to imply H.264 is a defacto MTI.
          Of course, the game theory example given does not include any
          actual deployment numbers and so doesn't lead to a sound
          conclusion.

        
Nonetheless, I do not think that an SDO should be simply
          guided by market deployments, decisions should be based on how
          to best meet the requirements of a particular project. I'm not
          saying market information should be ignored, I am saying that
          whether or not a particular solution meets a project's
          requirements should be the driver behind adoption.

        
In this case, two camps have developed around two
          technologies and both camps have taken steps to make their
          preferred solution better aligned with the project's
          requirements. In such a case it would be ideal if the
          technical merit could be used as the deciding factor, but
          chasing a decision on that basis is by definition impractical
          given that two groups of technologists have already formed -
          meaning there is enough ambiguity in the technical information
          to allow each group to justify its position.

        
In such situations, one looks for compromise. 

        
In answering the question "what do we do":

        
I have suggested one possible way to compromise, a couple of
          people seemed supportive, others were not.

        
BR,

          Mohammed

        
On Nov 9, 2013 9:56 AM, "Adam Roach"
          <adam@nostrum.com> wrote:

          

            

              
On 11/7/13 18:57, Stephan Wenger wrote:

              

              
...a decision for either of the
                two candidate codecs will be ignored by a significant
                part of the implementer community.

              

              I'm not sure that's true any longer. Indulge me in a bit
              of armchair game theory application.

              

              Let's start by looking at ground zero: the browsers.
              Considering the public statements that have been made, I
              think it's fairly safe to assume that the following can be
              taken as given:

              

              
    
                
  1. Chrome will support at least VP8.
    2. 
                
  2. Firefox will support both VP8 and H.264.
    3. 
                
  3. Internet Explorer is almost certain to support
                  H.264.
    4. 
                
  4. Safari (including Mobile Safari) is almost certain
                  to support H.264.
    5. 
              

              

              If the codecs are *only* those called out above, then
              you'll end up with an interesting situation in which IE,
              Safari, and Firefox can all mutually interoperate; Chrome
              and Firefox can interoperate with each other; and Chrome
              cannot interoperate with anything else.

              

              I'm not going to put plans in Google's mouth, but envision
              yourself in the same set of circumstances: you own a
              fully-paid H.264 license, already ship an H.264 codec as
              part of your browser, and are getting a huge black eye for
              not interoperating with significant major browsers. What
              do you do?

              

              Okay. Now, shift your imagined role: you're a non-browser
              implementor, and discover the facts on the ground to be
              those described above. You can deploy VP8 and work with
              two of the four major browsers, or you can deploy H.264
              and work with all four. Yeah, you might not be in love
              with the structural issues involved in integrating the
              Cisco library [1]  -- and I'm certainly not -- but you're
              not actually precluded from using H.264. What do *you* do?

              

              Which is a kind of long way to get to the fact that I
              think we're in a situation where H.264 is a de facto MTI
              codec anyway [2].

              

              Now, imagine you're working in an SDO with this particular
              set of writing on the wall. You have a solid decision to
              choose one MTI video codec. You can choose one that's
              going to be functionally MTI regardless of what you say,
              or you can choose one that is quite probably going to be
              ignored by some non-trivial set of implementors.

              

              So. What do *we* do?

              

              /a

              

              ____

              [1] There's been quite a bit of handwringing around the
              impact this has on iOS developers, as they cannot download
              modules at runtime. Bear in mind that these are curated
              applications, with a single, well-accounted-for
              distribution point. These are not libre software by a long
              shot, and they don't need to worry about the implications
              of third parties compiling their own versions. So, these
              implementors statically link in the OpenH264 library, and
              are exempted for the first 100,000 instances they ship
              each year. Beyond that point, they're not "small fish" any
              more. Back when I was one of the owners of the company I
              worked at, "complications arising from selling more than
              100,000 copies a year" is the kind of thing that I would
              place on a list titled "problems I wish I had."

              

              [2] And to be clear, this is *not* the result I would have
              preferred. But I recognize that this isn't about my
              personal preferences. I find myself in the odd position of
              actually arguing for the position contrary to what I think
              is ideal, simply because I think it is the only practical
              path to success.

            

            

            _______________________________________________

            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


    

    

  


--------------040604060402020407060104--

From adam@nostrum.com  Sat Nov  9 00:36:01 2013
Return-Path: 
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 9D41B21F9FB1 for ; Sat,  9 Nov 2013 00:36:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 ESZ+G+Uz6qdJ for ; Sat,  9 Nov 2013 00:36:01 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8107121F9EE9 for ; Sat,  9 Nov 2013 00:36:00 -0800 (PST)
Received: from Orochi.local (184-77-219-247.war.clearwire-wmx.net [184.77.219.247]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA98ZkxC094667 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 9 Nov 2013 02:35:48 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <527DF3E3.7090906@nostrum.com>
Date: Sat, 09 Nov 2013 00:35:47 -0800
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Ron , rtcweb@ietf.org
References:  <527D6BFA.9090509@nostrum.com> <20131109055935.GI3245@audi.shelbyville.oz>
In-Reply-To: <20131109055935.GI3245@audi.shelbyville.oz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 184.77.219.247 is authenticated by a trusted mechanism)
Subject: [rtcweb] Who is committed to supporting MTI? (was Re: MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 08:36:01 -0000

On 11/8/13 21:59, Ron wrote:
> [T]he chairs already noted at the meeting that these browser
> vendors had all indicated they would support whatever MTI decision
> the working group made.

I agree with you that one of the chairs indicated that he had personally 
received off-the-record, back-channel indications to this effect. The 
problem is that this assertion conflicts with off-the-record, 
back-channel indications that I have myself received.

Perhaps someone from each of Google, Microsoft, and Apple could stand up 
and confirm the chair's claim. I'll note that Mozilla is already on the 
record in this regard.

/a

From lorenzo@meetecho.com  Sat Nov  9 08:28:06 2013
Return-Path: 
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 3526B21F9D1C for ; Sat,  9 Nov 2013 08:28:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 HGZsaXmc5fth for ; Sat,  9 Nov 2013 08:28:01 -0800 (PST)
Received: from smtpdb12.aruba.it (smtpdb12.aruba.it [62.149.158.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF8621F9D12 for ; Sat,  9 Nov 2013 08:28:00 -0800 (PST)
Received: from lminiero ([88.128.80.2]) by smtpcmd04.ad.aruba.it with bizsmtp id nUTw1m00Z02zm9U01UTxk6; Sat, 09 Nov 2013 17:27:58 +0100
Date: Sat, 9 Nov 2013 17:27:56 +0100
From: Lorenzo Miniero 
To: Adam Roach 
Message-ID: <20131109172756.713c433c@lminiero>
In-Reply-To: <527D6BFA.9090509@nostrum.com>
References:  <527D6BFA.9090509@nostrum.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 16:28:06 -0000

Il giorno Fri, 08 Nov 2013 14:55:54 -0800
Adam Roach  ha scritto:

> On 11/7/13 18:57, Stephan Wenger wrote:
> > ...a decision for either of the two candidate codecs will be
> > ignored by a significant part of the implementer community.
> 
> I'm not sure that's true any longer. Indulge me in a bit of armchair 
> game theory application.
> 
> Let's start by looking at ground zero: the browsers. Considering the 
> public statements that have been made, I think it's fairly safe to 
> assume that the following can be taken as given:
> 
>  1. Chrome will support at least VP8.
>  2. Firefox will support both VP8 and H.264.
>  3. Internet Explorer is almost certain to support H.264.
>  4. Safari (including Mobile Safari) is almost certain to support
> H.264.
> 
> 
> If the codecs are *only* those called out above, then you'll end up
> with an interesting situation in which IE, Safari, and Firefox can
> all mutually interoperate; Chrome and Firefox can interoperate with
> each other; and Chrome cannot interoperate with anything else.
> 
> I'm not going to put plans in Google's mouth, but envision yourself
> in the same set of circumstances: you own a fully-paid H.264 license, 
> already ship an H.264 codec as part of your browser, and are getting
> a huge black eye for not interoperating with significant major
> browsers. What do you do?
> 
> Okay. Now, shift your imagined role: you're a non-browser
> implementor, and discover the facts on the ground to be those
> described above. You can deploy VP8 and work with two of the four
> major browsers, or you can deploy H.264 and work with all four. Yeah,
> you might not be in love with the structural issues involved in
> integrating the Cisco library [1]  -- and I'm certainly not -- but
> you're not actually precluded from using H.264. What do *you* do?
> 


I *would* use a different library, if I could. Which I can't, because
we're talking of a patented library and I'm all at disadvantage here. I
stated several times why the current Cisco plugin, while a nice and
generious offer (funny thing they changed the original "Christmas
release" slide, BTW ;-) ), is not an acceptable option for me. What some
see as an opportunity, I see as a leash, that could (or could not) be
use at any time to either slow me down or stop me entirely. I'd rather
have a free web, please.


> Which is a kind of long way to get to the fact that I think we're in
> a situation where H.264 is a de facto MTI codec anyway [2].
> 


A weird statement, considering I've yet to see an H.264 WebRTC
implementation at all.


> Now, imagine you're working in an SDO with this particular set of 
> writing on the wall. You have a solid decision to choose one MTI
> video codec. You can choose one that's going to be functionally MTI
> regardless of what you say, or you can choose one that is quite
> probably going to be ignored by some non-trivial set of implementors.
> 
> So. What do *we* do?
> 
> /a
> 


The above mentioned non-trivial set of implementors is currently
ignoring the whole spec anyway. Why should I care?


> ____
> [1] There's been quite a bit of handwringing around the impact this
> has on iOS developers, as they cannot download modules at runtime.
> Bear in mind that these are curated applications, with a single, 
> well-accounted-for distribution point. These are not libre software
> by a long shot, and they don't need to worry about the implications
> of third parties compiling their own versions. So, these implementors
> statically link in the OpenH264 library, and are exempted for the
> first 100,000 instances they ship each year. Beyond that point,
> they're not "small fish" any more. Back when I was one of the owners
> of the company I worked at, "complications arising from selling more
> than 100,000 copies a year" is the kind of thing that I would place
> on a list titled "problems I wish I had."
> 


I really can't accept the 100k thing. First of all, it's not at all
clear how they're computed in the first place. Are you consuming one
when you install an app? when you open an encoder/decoder instance? a
mix of the two? what about servers? am I breaking the law every time I
play a video I took with my phone using mplayer, or transcoding it
with streamer/ffmpeg, if I don't tell MPEG LA? as I told EKR on the
chat, I've tried looking several times for information about licensing
in that sense, and have always miserably failed. I may be incredibly
dumb, but apparently I'm in good company, as I've often read posts,
blogs and more by people who tried to do the same to no avail. This
excellent post on librevideo, for instance, is three years old now and
yet so up-to-date:

http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/

I do remember something I read on a post here thats truck me at the
time. I can't remember who wrote that, and so I may be corrected, but
it said something like "just tracking down all the licenses being
consumed, even when you're under the 100k, is almost a full-time job".
For a small (actually tiny) company like mine, devoting a full
resource just for that, especially when you could use it to much
more benefit (like working on actual WebRTC stuff), is inevitably out of
the question. And the fact that other companies can instead just ignore
that and pay the cap as if it were a rounding error to their coffee
budget doesn't make me more symphatethic to the cause.


> [2] And to be clear, this is *not* the result I would have preferred. 
> But I recognize that this isn't about my personal preferences. I find 
> myself in the odd position of actually arguing for the position
> contrary to what I think is ideal, simply because I think it is the
> only practical path to success.


I understand your points, and appreciate the fact you'd rather take a
different way, even if you're doing a really good job at fostering the
other. :-)

Lorenzo

From lorenzo@meetecho.com  Sat Nov  9 08:37:00 2013
Return-Path: 
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 EEF7921F9FB7 for ; Sat,  9 Nov 2013 08:37:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 vOWouF0NkBEA for ; Sat,  9 Nov 2013 08:36:56 -0800 (PST)
Received: from smtpdg7.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by ietfa.amsl.com (Postfix) with ESMTP id C327C21F9FB9 for ; Sat,  9 Nov 2013 08:36:44 -0800 (PST)
Received: from lminiero ([88.128.80.2]) by smtpcmd03.ad.aruba.it with bizsmtp id nUcf1m00602zm9U01UcfFK; Sat, 09 Nov 2013 17:36:41 +0100
Date: Sat, 9 Nov 2013 17:36:38 +0100
From: Lorenzo Miniero 
To: Adam Roach 
Message-ID: <20131109173638.7f551988@lminiero>
In-Reply-To: <527D7854.1080307@nostrum.com>
References:  <527D6BFA.9090509@nostrum.com>  <527D7854.1080307@nostrum.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 16:37:01 -0000
X-List-Received-Date: Sat, 09 Nov 2013 16:37:01 -0000

Il giorno Fri, 08 Nov 2013 15:48:36 -0800
Adam Roach  ha scritto:

> On 11/8/13 15:20, Peter Thatcher wrote:
> > [S]ome people (FOSS projects) will have to ignore the spec if H.264
> > is the MTI, because they have no choice... 
> 
> You appear to have somehow missed Cisco's announcement last week.
> 


What announcement? :-)

Jokes apart, we both know that the allegedly BSD license of the will-be
library means nothing. The fact itself you cannot use a version you
compile yourself will make it unusable. As Peter already pointed out,
developers from Debian and Fedora (incidentally two of the most
widespread distributions, Fedora being my default OS for a long time)
have already clarified how they won't be able to take advantage of it.


> > Of course, you may then speculate in return that no one cares about 
> > FOSS projects and browsers, which I speculate would be an ironic 
> > coming from someone representing a FOSS project.
> 
> I think your assertion is trivially disproved by the fact that we, as
> a FOSS project, are going to support H.264 for WebRTC.
> 


Which won't happen on my Fedora, where the shipped Firefox version
won't have the plugin installed. Or with any other multimedia
application on my Fedora at all, for that matter, for the very same
reason. Lucky thing opus and libvpx are available out of the box,
instead.

Lorenzo


> /a
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From pthatcher@google.com  Sat Nov  9 11:37:30 2013
Return-Path: 
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 D44EB21E8092 for ; Sat,  9 Nov 2013 11:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 D+a81+mJY+9l for ; Sat,  9 Nov 2013 11:37:26 -0800 (PST)
Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 02EC321F9E9D for ; Sat,  9 Nov 2013 11:37:25 -0800 (PST)
Received: by mail-pb0-f42.google.com with SMTP id jt11so3561514pbb.15 for ; Sat, 09 Nov 2013 11:37:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9SCAOwC3BAxAVasR5mcOeC4uvgcwmVaxeCFLM1Pmync=; b=aaGXmoXncEg1A+tZAprxX0AYXBVHJMQnazGM8v5Sz5aktLtXlN3CZF/Em8RHstpMgt wbyoa+AattXWDTn9HrFTJAyBKVjYPv4xjpaJggXjw5IyPxf8IQCqUEOn9eEjQsLylNIU gLomreHIjgAxwpa5por4plpbQ6/egj11b6fYaBehcrgUY3adIu+of8ZJuEdgPdYnSqGj 4p1NfXIg6Bzs4+r1uHnH3GiWzGhIn/ofwq/vo4aU5AgbEG1U7ZC36qMOqZwLQJbcm/Bm Q4831CnpNV8UdhWYeomPxEWH1aP417F5atb9Wl7R/3017PnOZdhWaiOb8w0FJJUEP+Ys sgCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9SCAOwC3BAxAVasR5mcOeC4uvgcwmVaxeCFLM1Pmync=; b=ayUg8vwmwM6hgpJMco8bjI73pk0CgEUONigpLHc87XkWGXKWtq2c5akjc/QUbh3iSd TOrIpqDuTM1BKHqKLl/b/tVq4dVrcBEFKYkhIGxOCMLhmF0rHMdr3b6Z7Hzk+Ln1Mwus 8tCZc1qtY923ERzszfE/SX3C0xcfn4tB6xcodpkhhCudWrfIi6QFP3sPTV0VIVMWlaqt OnSEziL59T/6Z3CO433jJDjg+87aCfzTlnzLxH7uH2V8sqCPHGa4AIA1q6PCgRcdbDh3 5kMdBk7q7aUDF+gWcw0VRz+VWv20SSS77nTwk0CYOU+TTvQ9YIJSmD0wz+891Bw8uEW6 AL7w==
X-Gm-Message-State: ALoCoQkyAGwV3+BZxJ43dS1uFqhyzhN2v+KlVLCojYmT8twCHGrR5sF9WnFN7/VsqyUBwnnrNc0GTeKyXV+T4TGBgnsSCxzbixL6SdMY4NUwfjBy5eNuzPL/qTH7lWykZ54ZGCcRJdnPyXZ0ReqLp1+4al+3Tb0CDZLEku2JU3uzfxxBscw9rFG+kKLDFNTSiOmFoCb7tcUv
X-Received: by 10.68.189.133 with SMTP id gi5mr21705162pbc.57.1384025844490; Sat, 09 Nov 2013 11:37:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.66.163.234 with HTTP; Sat, 9 Nov 2013 11:36:43 -0800 (PST)
In-Reply-To: <527DF3E3.7090906@nostrum.com>
References:  <527D6BFA.9090509@nostrum.com> <20131109055935.GI3245@audi.shelbyville.oz> <527DF3E3.7090906@nostrum.com>
From: Peter Thatcher 
Date: Sat, 9 Nov 2013 11:36:43 -0800
Message-ID: 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=e89a8ff1bfaad23c9404eac3a0c8
Cc: "" 
Subject: Re: [rtcweb] Who is committed to supporting MTI? (was Re: MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 19:37:30 -0000

--e89a8ff1bfaad23c9404eac3a0c8
Content-Type: text/plain; charset=UTF-8

While I appreciate the effort to gather additional information, I am
beginning to notice a trend that some of the big players here are
forgetting about the smaller players.  In particular, there aren't just 4
browsers in the world, and acting like there are only 4 browsers in the
world does not look good from a "big players vs. small players"
perspective.  For example, can we really tell the world that our WG has
concluded "lots of smaller players can't ship codec X, but we're going to
mandate it anyway because the 4 big players are willing to ship it" (which
they haven't, but assuming they did)?

May I remind you that Firefox, the very browser you represent, until very
recently, was on the "small player" side of the fence in the codec debate
and only until very recently (apparently) switched sides?  Perhaps you
could still engender in yourself some lingering empathy for those other
small players that cannot necessarily comply with the mandate of certain
codecs that you are so willingly eager to press upon them.

You may abandon their cause, you may disregard their complaints, and you
may disparage their positions, but at least do not cease to acknowledge
their existence and forget that you were once one them.  There are more
browsers than 4!




On Sat, Nov 9, 2013 at 12:35 AM, Adam Roach  wrote:

> On 11/8/13 21:59, Ron wrote:
>
>> [T]he chairs already noted at the meeting that these browser
>> vendors had all indicated they would support whatever MTI decision
>> the working group made.
>>
>
> I agree with you that one of the chairs indicated that he had personally
> received off-the-record, back-channel indications to this effect. The
> problem is that this assertion conflicts with off-the-record, back-channel
> indications that I have myself received.
>
> Perhaps someone from each of Google, Microsoft, and Apple could stand up
> and confirm the chair's claim. I'll note that Mozilla is already on the
> record in this regard.
>
> /a
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--e89a8ff1bfaad23c9404eac3a0c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


While I appreciate the effort to gather additional information,=
 I am beginning to notice a trend that some of the big players here are for=
getting about the smaller players. =C2=A0In particular, there aren't ju=
st 4 browsers in the world, and acting like there are only 4 browsers in th=
e world does not look good from a "big players vs. small players"=
 perspective. =C2=A0For example, can we really tell the world that our WG h=
as concluded "lots of smaller players can't ship codec X, but we&#=
39;re going to mandate it anyway because the 4 big players are willing to s=
hip it" (which they haven't, but assuming they did)?






<=
/div>
=
May I remind you that Firefox, the very browser you represent, until very r=
ecently, was on the "small player" side of the fence in the codec=
 debate and only until very recently (apparently) switched sides? =C2=A0Per=
haps you could still engender in yourself some lingering empathy for those =
other small players that cannot necessarily comply with the mandate of cert=
ain codecs that you are so willingly eager to press upon them. =C2=A0






<=
/div>
=
You may abandon their cause, you may disregard their complaints, and you ma=
y disparage their positions, but at least do not cease to acknowledge their=
 existence and forget that you were once one them. =C2=A0There are more bro=
wsers than 4!






<=
/div>
=



On =
Sat, Nov 9, 2013 at 12:35 AM, Adam Roach <adam@nostrum.com> w=
rote:





On 11/8/13 21:59, Ron wrote:



[T]he chairs already noted at the meeting that these browser

vendors had all indicated they would support whatever MTI decision

the working group made.





I agree with you that one of the chairs indicated that he had personally re=
ceived off-the-record, back-channel indications to this effect. The problem=
 is that this assertion conflicts with off-the-record, back-channel indicat=
ions that I have myself received.







Perhaps someone from each of Google, Microsoft, and Apple could stand up an=
d confirm the chair's claim. I'll note that Mozilla is already on t=
he record in this regard.



/a

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb





--e89a8ff1bfaad23c9404eac3a0c8--

From cowwoc@bbs.darktech.org  Sat Nov  9 12:08:39 2013
Return-Path: 
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 B670121F9FBA for ; Sat,  9 Nov 2013 12:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[AWL=-0.602,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 6nPBZ61R7qQr for ; Sat,  9 Nov 2013 12:08:35 -0800 (PST)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id D4FEF21F9B5A for ; Sat,  9 Nov 2013 12:08:34 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id qd12so5445801ieb.5 for ; Sat, 09 Nov 2013 12:08:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=BWN/UA1f3+KhhkcTg+47wNjYiYE1GnwBoke7QEanVtU=; b=ZxIG+u4F6JD8ATCh2e9xQ392vj8mpNHg5u5BkPoawCBUFr/a1+ourMKQ4Byw6gknF3 v84s7HIKunMvh5jsISWTUqMi/It4WJtb0V8VZ7xanqHcUQGJvv72N6h3NhhzGUymepSp ahpEL/bTCFzBAGoTLwtYuMk6q0yR9OravhPsj0nLBG/SWW+HJzkITZrq2l1cD2JQqVo6 JJmFNSym62EwILxf925R8u47tEhxAxNa1+ZMFxQWCUuLGhu82Pr1pp7i2/X+m8DdyZsK /HjDZPi3p8yTp9xcDo1C4ei0ceAqudlGt7a5SXeKiWSyP6QWHjDPuX9BEsamvvqG0e1q 9UNw==
X-Gm-Message-State: ALoCoQnxQRSDZItVhrvEx6X56lL1rEB/HNPKoirKTQIEll7X2SbxALGnh5rTQxAlV+LdH+SXxdm5
X-Received: by 10.50.61.35 with SMTP id m3mr7308962igr.56.1384027713948; Sat, 09 Nov 2013 12:08:33 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p5sm9940365igj.10.2013.11.09.12.08.32 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Nov 2013 12:08:33 -0800 (PST)
Message-ID: <527E963F.5040605@bbs.darktech.org>
Date: Sat, 09 Nov 2013 15:08:31 -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: rtcweb@ietf.org
References:  <527D6BFA.9090509@nostrum.com>	<20131109055935.GI3245@audi.shelbyville.oz>	<527DF3E3.7090906@nostrum.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060607060207060704060609"
Subject: Re: [rtcweb] Who is committed to supporting MTI? (was Re: MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Sat, 09 Nov 2013 20:08:39 -0000

This is a multi-part message in MIME format.
--------------060607060207060704060609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


     ... and many more non-browser native applications.

Gili

On 09/11/2013 2:36 PM, Peter Thatcher wrote:
> While I appreciate the effort to gather additional information, I am 
> beginning to notice a trend that some of the big players here are 
> forgetting about the smaller players.  In particular, there aren't 
> just 4 browsers in the world, and acting like there are only 4 
> browsers in the world does not look good from a "big players vs. small 
> players" perspective.  For example, can we really tell the world that 
> our WG has concluded "lots of smaller players can't ship codec X, but 
> we're going to mandate it anyway because the 4 big players are willing 
> to ship it" (which they haven't, but assuming they did)?
>
> May I remind you that Firefox, the very browser you represent, until 
> very recently, was on the "small player" side of the fence in the 
> codec debate and only until very recently (apparently) switched sides? 
>  Perhaps you could still engender in yourself some lingering empathy 
> for those other small players that cannot necessarily comply with the 
> mandate of certain codecs that you are so willingly eager to press 
> upon them.
>
> You may abandon their cause, you may disregard their complaints, and 
> you may disparage their positions, but at least do not cease to 
> acknowledge their existence and forget that you were once one them. 
>  There are more browsers than 4!
>
>
>
>
> On Sat, Nov 9, 2013 at 12:35 AM, Adam Roach  > wrote:
>
>     On 11/8/13 21:59, Ron wrote:
>
>         [T]he chairs already noted at the meeting that these browser
>         vendors had all indicated they would support whatever MTI decision
>         the working group made.
>
>
>     I agree with you that one of the chairs indicated that he had
>     personally received off-the-record, back-channel indications to
>     this effect. The problem is that this assertion conflicts with
>     off-the-record, back-channel indications that I have myself received.
>
>     Perhaps someone from each of Google, Microsoft, and Apple could
>     stand up and confirm the chair's claim. I'll note that Mozilla is
>     already on the record in this regard.
>
>     /a
>     _______________________________________________
>     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


--------------060607060207060704060609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    


          ... and many more non-browser native applications.

      

      Gili

      

      On 09/11/2013 2:36 PM, Peter Thatcher wrote:

    

    

      

        
While I appreciate the
          effort to gather additional information, I am beginning to
          notice a trend that some of the big players here are
          forgetting about the smaller players.  In particular, there
          aren't just 4 browsers in the world, and acting like there are
          only 4 browsers in the world does not look good from a "big
          players vs. small players" perspective.  For example, can we
          really tell the world that our WG has concluded "lots of
          smaller players can't ship codec X, but we're going to mandate
          it anyway because the 4 big players are willing to ship it"
          (which they haven't, but assuming they did)?

        


        

        
May I remind you that
          Firefox, the very browser you represent, until very recently,
          was on the "small player" side of the fence in the codec
          debate and only until very recently (apparently) switched
          sides?  Perhaps you could still engender in yourself some
          lingering empathy for those other small players that cannot
          necessarily comply with the mandate of certain codecs that you
          are so willingly eager to press upon them.  

        


        

        
You may abandon their
          cause, you may disregard their complaints, and you may
          disparage their positions, but at least do not cease to
          acknowledge their existence and forget that you were once one
          them.  There are more browsers than 4!

        


        

        


        

        


          

          
On Sat, Nov 9, 2013 at 12:35 AM, Adam
            Roach <adam@nostrum.com>
            wrote:

            
On
              11/8/13 21:59, Ron wrote:

              

                [T]he chairs already noted at the meeting that these
                browser

                vendors had all indicated they would support whatever
                MTI decision

                the working group made.

              

              

              I agree with you that one of the chairs indicated that he
              had personally received off-the-record, back-channel
              indications to this effect. The problem is that this
              assertion conflicts with off-the-record, back-channel
              indications that I have myself received.

              

              Perhaps someone from each of Google, Microsoft, and Apple
              could stand up and confirm the chair's claim. I'll note
              that Mozilla is already on the record in this regard.

              

              /a

              _______________________________________________

              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


    

    

  


--------------060607060207060704060609--

From singer@apple.com  Sat Nov  9 21:37:18 2013
Return-Path: 
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 13C7621E80FD for ; Sat,  9 Nov 2013 21:37:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 oaO5pbcX9+rt for ; Sat,  9 Nov 2013 21:37:07 -0800 (PST)
Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7286121E80E8 for ; Sat,  9 Nov 2013 21:37:05 -0800 (PST)
Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 33.1D.21841.F7B1F725; Sun, 10 Nov 2013 13:37:03 +0800 (MYT)
X-AuditID: 1152fe11-b7f256d000005551-d3-527f1b7f1b11
Received: from sng-mmpp-sz01.asia.apple.com ( [17.82.200.58]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id 2A.D7.14371.F7B1F725; Sun, 10 Nov 2013 13:37:03 +0800 (MYT)
Received: from [17.85.193.3] (unknown [17.85.193.3]) by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MW100J7A8XQRM20@sng-mmpp-sz01.asia.apple.com> for rtcweb@ietf.org; Sun, 10 Nov 2013 13:37:03 +0800 (SGT)
Content-type: text/plain; charset=iso-8859-1
MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: David Singer 
In-reply-to: 
Date: Sun, 10 Nov 2013 13:37:01 +0800
Content-transfer-encoding: quoted-printable
Message-id: <54B43669-B84A-4B60-BFBB-2D2ECF91D27D@apple.com>
References: 
To: Bernard Aboba 
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUiGHRCSLdeuj7IYNZ2S4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsW7ePPaCO1wVbya2sjYwnuHoYuTkkBAwkTg5ZwEjhC0mceHe erYuRi4OIYHdjBI/X61hgik69PkAK0RiMpPE3a7TzBDOBiaJG/8egVUxC+hI9H7/xgxi8wro Sezcu40VxBYW0JJ4e7kXLM4moCrxYM4xsHWcAtYSV3sPsoHYLEDxhlMbWSDmqEssndzABmFr Szx5d4EVYqaNROO5A2C9QgJWEl/P/QKaycEhIqAr8bfLCOJQWYnT556zgNwmIfCRVWL73fPs ExiFZyE5bxaS82YhWbGAkXkVo3huYmaObmaeoV5icWaiXmJBQU6qXnJ+7iZGcEj/E9zBOHWh 4SFGAQ5GJR7ebddqg4RYE8uKK3MPMUpwMCuJ8M79WBckxJuSWFmVWpQfX1Sak1p8iFGag0VJ nFc0BahaID2xJDU7NbUgtQgmy8TBKdXAGPi119cnrPJ1/ZLuwuIJNu+Tn+w7vTSGO6NQYumj l/uN7yZ3srO94u/hdJO3fFzIsz0ob2L5gYj2Dqsovm2rLd/P2PKiZue9rUdYda1dDNW5Fjvx fWh5KDT/9TMT2/Rfkn1evTtD2BMr2P5NMvyWta8hwyg5/Wy3Jc9hW+v+0trvKdNPtOcrsRRn JBpqMRcVJwIAPru9MGUCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUiGHTCSrdeuj7IYMkRM4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsW7ePPaCO1wVbya2sjYwnuHoYuTkkBAwkTj0+QArhC0mceHe erYuRi4OIYHJTBJ3u04zQzgbmCRu/HvEBFLFLKAj0fv9GzOIzSugJ7Fz7zawbmEBLYm3l3vB 4mwCqhIP5hxjBLE5BawlrvYeZAOxWYDiDac2skDMUZdYOrmBDcLWlnjy7gIrxEwbicZzB8B6 hQSsJL6e+wU0k4NDREBX4m+XEcShshKnzz1nmcAoMAvJRbOQXDQLydQFjMyrGEWLUnMSKw31 EoszE/USCwpyUvWS83M3MUJCUGgH48f9BocYBTgYlXh4C47XBAmxJpYVV+YeYpTgYFYS4Z37 sS5IiDclsbIqtSg/vqg0J7X4EKM0B4uSOG9KSm2QkEB6YklqdmpqQWoRTJaJg1OqgbFmadnX B8190Ynelwpmsend2SJ4JN/aNvPMFvfQNr225TO51x6W1nvrO2leyJyUdHUu9ZTQKEa5xZVT VROFPbot/v/Z/iCq3/az54Vztyz0NBl8i/fm/tvbG+dyJXCz2KdnyyKDmKPPdju63/Zynvj+ Omvk7V4Oq3mvmkqdV8S4nJaqWfQ3SYmlOCPRUIu5qDgRAA2DS4I9AgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] External Review Team
X-BeenThere: rtcweb@ietf.org
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: Sun, 10 Nov 2013 05:37:18 -0000

On Nov 9, 2013, at 2:19 , Bernard Aboba  =
wrote:

> Adam Roach stated:
> "I'll make an even stronger statement: I would contend that any strong =
push against the use of an external review team amounts to a tacit =
admission by an individual that the arguments for their preferred =
position are insufficiently compelling."
> =20
> [BA] If the core issues under consideration were technical, I'd agree =
with you.=20
> Unfortunately, they aren't.  The core issue (as Jonathan ably stated) =
is the perceived legal risk.  Convening an external review team of IETF =
participants to evaluate those legal risks is unlikely to persuade the =
real audience for those recommendations - lawyers.=20
> =20
> If the goal is to come up with a compelling legal analysis, the expert =
panel should probably be composed of recognized legal experts.  Good =
luck with recruiting such a panel to work pro-bono.=20



Yes.

Indeed, I am having a hard time seeing how the IETF could, with a =
straight face, mandate implementation of something for which they have a =
formal "no license" declaration.  In other bodies I know of, this would =
be impossible: the technical committee would be required to re-consider =
the specification and take appropriate action.



David Singer
Multimedia and Software Standards, Apple Inc.


From ron@debian.org  Sat Nov  9 23:05:14 2013
Return-Path: 
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 0593A21E8131 for ; Sat,  9 Nov 2013 23:05:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
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 YRGlRRVtKuEQ for ; Sat,  9 Nov 2013 23:05:09 -0800 (PST)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 9F25321E80CE for ; Sat,  9 Nov 2013 23:05:08 -0800 (PST)
Received: from ppp14-2-2-240.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.2.240]) by ipmail06.adl2.internode.on.net with ESMTP; 10 Nov 2013 17:33:50 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 13C204F903; Sun, 10 Nov 2013 17:33:47 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s0wSfFCcwHX0; Sun, 10 Nov 2013 17:33:45 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 76F664F904; Sun, 10 Nov 2013 17:33:45 +1030 (CST)
Date: Sun, 10 Nov 2013 17:33:45 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20131110070345.GL3245@audi.shelbyville.oz>
References:  <54B43669-B84A-4B60-BFBB-2D2ECF91D27D@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54B43669-B84A-4B60-BFBB-2D2ECF91D27D@apple.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] External Review Team
X-BeenThere: rtcweb@ietf.org
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: Sun, 10 Nov 2013 07:05:14 -0000

Hi David,

On Sun, Nov 10, 2013 at 01:37:01PM +0800, David Singer wrote:
> I am having a hard time seeing how the IETF could, with a straight face,
> mandate implementation of something for which they have a formal "no license"
> declaration.  In other bodies I know of, this would be impossible: the
> technical committee would be required to re-consider the specification and
> take appropriate action.

Could you please clarify what you're referring to here?

It's not clear to me if you are talking about the fact that many people
here have stated it will be impossible for them to licence H.264 according
to its published and uncontested terms - or if you're professing to have
some unique knowledge of the unsubstantiated claims that some H.264 IPR
also somehow applies to VP8.

The history of the IETF is full of 'formal' but utterly bogus declarations.
It's just unfortunate that there is still no requirement or obligation to
also rescind them, even in the face of solid proof of inapplicability.

It would be good if you could distinguish those from undisputed facts, as
all working groups generally need to do.

If you know something that we don't, perhaps a declaration of that is in
order here.

  Thanks!
  Ron



From ron@debian.org  Sat Nov  9 23:05:18 2013
Return-Path: 
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 DC1A621E8135 for ; Sat,  9 Nov 2013 23:05:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
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 7Tg5xq6xiwvf for ; Sat,  9 Nov 2013 23:05:13 -0800 (PST)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 332DF21E80E2 for ; Sat,  9 Nov 2013 23:05:11 -0800 (PST)
Received: from ppp14-2-2-240.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.2.240]) by ipmail06.adl2.internode.on.net with ESMTP; 10 Nov 2013 17:34:00 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 37CA54F8F3 for ; Sun, 10 Nov 2013 17:07:11 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UMNHSR7LZ2n3 for ; Sun, 10 Nov 2013 17:07:10 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 0E5204F902; Sun, 10 Nov 2013 17:07:10 +1030 (CST)
Date: Sun, 10 Nov 2013 17:07:10 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20131110063709.GK3245@audi.shelbyville.oz>
References:  <527D6BFA.9090509@nostrum.com> <20131109055935.GI3245@audi.shelbyville.oz> <527DF3E3.7090906@nostrum.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Who is committed to supporting MTI? (was Re: MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Sun, 10 Nov 2013 07:05:19 -0000

On Sat, Nov 09, 2013 at 11:36:43AM -0800, Peter Thatcher wrote:
> While I appreciate the effort to gather additional information, I am
> beginning to notice a trend that some of the big players here are
> forgetting about the smaller players.  In particular, there aren't just 4
> browsers in the world, and acting like there are only 4 browsers in the
> world does not look good from a "big players vs. small players"
> perspective.  For example, can we really tell the world that our WG has
> concluded "lots of smaller players can't ship codec X, but we're going to
> mandate it anyway because the 4 big players are willing to ship it" (which
> they haven't, but assuming they did)?
> 
> May I remind you that Firefox, the very browser you represent, until very
> recently, was on the "small player" side of the fence in the codec debate
> and only until very recently (apparently) switched sides?  Perhaps you
> could still engender in yourself some lingering empathy for those other
> small players that cannot necessarily comply with the mandate of certain
> codecs that you are so willingly eager to press upon them.
> 
> You may abandon their cause, you may disregard their complaints, and you
> may disparage their positions, but at least do not cease to acknowledge
> their existence and forget that you were once one them.  There are more
> browsers than 4!

Just on this note, if we're strolling down memory lane ...

if there's to be pleas of "Won't somebody think of the industry giants!",
which seemed to be a core motif of the H.264 presentation, it might be
good to pause for a moment and remember the garage startup roots of the
aforesaid giants currently in the spotlight.

While it may be true that some of those giants kickstarted their enterprise
the hard way, with stolen or otherwise questionably acquired IP [1], I don't
think that's a rite of passage the IETF should encourage for the budding
future giants in this application space.

If the market is as big and important as people say it is, then we're quite
likely defining the incubator environment for one or more of them here [2].
Let's not kill our next generation of chickens before they hatch and grow
to take their place in the pecking order on their own merit [3].

If the giants don't think they can compete on a level playing field, then
there are tacit admissions there too, which surely aren't to the advantage
of potential users of this technology.

  Ron



[1] so sayeth wikipedia.

[2] which may of course be a compelling reason for some existing giants
    to be very keen to lock them out as much as possible.

[3] some of them might even contribute to the economy by paying taxes,
    until they grow big enough to hire enough accountants to fix that :)


From singer@apple.com  Sun Nov 10 00:49:44 2013
Return-Path: 
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 E114811E8152 for ; Sun, 10 Nov 2013 00:49:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 hYpnk0gBWSNo for ; Sun, 10 Nov 2013 00:49:35 -0800 (PST)
Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) by ietfa.amsl.com (Postfix) with ESMTP id E985E11E8143 for ; Sun, 10 Nov 2013 00:49:34 -0800 (PST)
Received: from relay3.asia.apple.com ( [17.82.200.17]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 62.FC.03695.D984F725; Sun, 10 Nov 2013 16:49:33 +0800 (MYT)
X-AuditID: 1152fe06-b7f5a6d000000e6f-46-527f489d9674
Received: from echium.asia.apple.com ( [17.82.200.52]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id C7.FC.26194.D984F725; Sun, 10 Nov 2013 16:49:33 +0800 (MYT)
Received: from [17.85.193.3] (unknown [17.85.193.3]) by echium.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MW1004I5HUJ5330@echium.asia.apple.com> for rtcweb@ietf.org; Sun, 10 Nov 2013 16:49:33 +0800 (SGT)
Content-type: text/plain; charset=us-ascii
MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: David Singer 
In-reply-to: <20131110070345.GL3245@audi.shelbyville.oz>
Date: Sun, 10 Nov 2013 16:49:31 +0800
Content-transfer-encoding: quoted-printable
Message-id: <1F5A93A5-A81D-4F83-9C09-C1BADC979AEB@apple.com>
References:  <54B43669-B84A-4B60-BFBB-2D2ECF91D27D@apple.com> <20131110070345.GL3245@audi.shelbyville.oz>
To: Ron 
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUiGHRCUHeuR32QwdReGYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8eb0M6aCtzwV5y/dY21g7ObqYuTkkBAwkVh87ggzhC0mceHe erYuRi4OIYHdjBKPP59nhimad2E5I0Sih0li0YIGdghnMZPE2TePWUCqmAW0JNbvPM4EYvMK 6Ens3LuNFcQWBoq/vdwLNolNQFXiwZxjjCA2p4CFxNL+E2BxFqD4jqYdzBBzhCW+P74HNVNb 4sm7C6wQM20kWjsfM0Esns0ocX/dbLAiEQEJiTfvH0OdKitx+txzFpAiCYG3rBJf1y5nnsAo PAvJgbOQHDgLyZIFjMyrGMVzEzNzdDPzjPQSizMT9RILCnJS9ZLzczcxgsP6H9sOxgWvDQ8x CnAwKvHwHjhfEyTEmlhWXJl7iFGCg1lJhHfux7ogId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxi KbVBQgLpiSWp2ampBalFMFkmDk6pBsZypalafR+N762bXPpnxtIH9YcPz/zHsevK7Teyh1pN pc5nyzN+P9c69eWtV7LO/G/jJqqIPtLL52W/c5hT/EHV9p4/Xa+OtudNTUlsmLZ5lduihHaW 08/85s6LES5NSPBWTuQsyVFY2Z8lJaJ+09lP6r/Bpt5teVuTyjXzFy25ocTcfUV29QElluKM REMt5qLiRADvjZSqZwIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUiGHTCRHeuR32QwYYOSYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8eb0M6aCtzwV5y/dY21g7ObqYuTkkBAwkZh3YTkjhC0mceHe erYuRi4OIYEeJolFCxrYIZzFTBJn3zxmAaliFtCSWL/zOBOIzSugJ7Fz7zZWEFsYKP72ci8z iM0moCrxYM4xsKmcAhYSS/tPgMVZgOI7mnYwQ8wRlvj++B7UTG2JJ+8usELMtJFo7XzMBLF4 NqPE/XWzwYpEBCQk3rx/zAxxqqzE6XPPWSYwCsxCctMsJDfNQjJ3ASPzKkbRotScxEpjvcTi zES9xIKCnFS95PzcTYyQMBTcwfhhquEhRgEORiUe3rj7tUFCrIllxZW5hxglOJiVRHjnfqwL EuJNSaysSi3Kjy8qzUktPsQozcGiJM6bkgJULZCeWJKanZpakFoEk2Xi4JRqYIz2tAzqLzHY nxhzTXfho8bZiU96Jjb4m/KcSni1RIRbo4Nh12Wjl8XWBpsO9V/XN5qyv8DNSHWGSdmcb5v3 rvYJ/63vX3LHirni2eXNpVmX9r/sTYpa7ag2mXX9vKtL38tER77aueBHu3Rcks1ShhmlASfe Jhju0ND7zlnyIiqgfua7uwKhRUosxRmJhlrMRcWJAFIgvkE/AgAA
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] External Review Team
X-BeenThere: rtcweb@ietf.org
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: Sun, 10 Nov 2013 08:49:44 -0000

On Nov 10, 2013, at 15:03 , Ron  wrote:

>=20
> Hi David,
>=20
> On Sun, Nov 10, 2013 at 01:37:01PM +0800, David Singer wrote:
>> I am having a hard time seeing how the IETF could, with a straight =
face,
>> mandate implementation of something for which they have a formal "no =
license"
>> declaration.  In other bodies I know of, this would be impossible: =
the
>> technical committee would be required to re-consider the =
specification and
>> take appropriate action.
>=20
> Could you please clarify what you're referring to here?

https://datatracker.ietf.org/ipr/2035/

> It's not clear to me if you are talking about the fact that many =
people
> here have stated it will be impossible for them to licence H.264 =
according
> to its published and uncontested terms - or if you're professing to =
have
> some unique knowledge of the unsubstantiated claims that some H.264 =
IPR
> also somehow applies to VP8.

I am unaware of any refusal to license that applies to H.264.

> The history of the IETF is full of 'formal' but utterly bogus =
declarations.

Oh, is there an analysis?

> It's just unfortunate that there is still no requirement or obligation =
to
> also rescind them, even in the face of solid proof of inapplicability.
>=20
> It would be good if you could distinguish those from undisputed facts, =
as
> all working groups generally need to do.
>=20
> If you know something that we don't, perhaps a declaration of that is =
in
> order here.


No, I think I am working off the same information.

David Singer
Multimedia and Software Standards, Apple Inc.


From stefan.lk.hakansson@ericsson.com  Sun Nov 10 01:32:48 2013
Return-Path: 
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 5520C21E8064 for ; Sun, 10 Nov 2013 01:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level: 
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 mKGkjDqC4bFx for ; Sun, 10 Nov 2013 01:32:43 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B307421E8056 for ; Sun, 10 Nov 2013 01:32:42 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-18-527f52b48ad4
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7E.4B.03802.4B25F725; Sun, 10 Nov 2013 10:32:36 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Sun, 10 Nov 2013 10:32:35 +0100
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= 
To: Magnus Westerlund , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Proposal for API mapping for RTP
Thread-Index: AQHO2+XFKCOjbayppUaIHGN4PDMgyw==
Date: Sun, 10 Nov 2013 09:32:35 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3D5EF5@ESESSMB209.ericsson.se>
References: <527BD94C.2070900@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+Jvje6WoPogg7mNIhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+mrrawFu9Qq7mw4x9bAeEW+i5GTQ0LARGLp6sssELaYxIV7 69m6GLk4hAQOMUp0tF6GcpYwSiy4u5wZpIpNIFBi674FbCC2iECsxPvZV1lBbGEBM4lrfyax QsTNJWb8XcgCYetJ3F20iAnEZhFQlehb9ZAdxOYV8JW4eHs2WFxIQFtiyYvzjCA2I9AV30+t AYszC4hL3HoynwniOgGJJXvOM0PYohIvH/9jhbCVJBqXPGGFqNeTuDF1ChuErS2xbOFrZohd ghInZz5hmcAoMgvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HKjTYzAAD+45bfqDsY750QOMUpz sCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdEpNoK9aI7vJRPZiOp984Qu+PXt j1k86fL7r/t7HGduqtGwPnFIcz3b7d0flrtqKe74k1u6VHEag+JvJWW56ZLLXv63mFHgvaUp 8Lah8cUdC756sS2dHPdHvfyU5/5dTMGb2n8zmT2Lr/2h9fa1dSZLWMVOiQU+NXpzC5r+Miya tpmh/n5lyVolluKMREMt5qLiRABP7IXRPgIAAA==
Subject: Re: [rtcweb] Proposal for API mapping for RTP
X-BeenThere: rtcweb@ietf.org
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: Sun, 10 Nov 2013 09:32:48 -0000

On 07/11/13 19:18, Magnus Westerlund wrote:=0A=
> WG,=0A=
> (As draft-ietf-rtcweb-rtp-usage Editor)=0A=
=0A=
Magnus,=0A=
=0A=
thanks for this write up. Some comments inline.=0A=
=0A=
>=0A=
> There was discussion yesterday afternoon on the W3C MediaStream to RTP=0A=
> mapping. This did arrive on some conclusions that I here try to word=0A=
> into a proposal for everyones review.=0A=
>=0A=
> A MediaStreamTrack is sent over a source packet stream (one SSRC) and=0A=
> can have additionally redundancy packet streams (SSRCs). These=0A=
> redundnacy streams are RTP retranmission streams or FEC.=0A=
=0A=
Can't there be enhancement packet streams as well (for layered codecs)?=0A=
=0A=
And in some proposals a single MediaStreamTrack can be sent in more than =
=0A=
one encoding (UA - as opposed to JS handled - handled simulcast) - is =0A=
that covered?=0A=
=0A=
>=0A=
> When multiple MediaStreamTracks have the same Media Source, then the=0A=
> fact that one has creaeted multiple MediaStreamTracks and added these=0A=
> through a MediaStream to the PeerConnection is going to result in that=0A=
> each MediaStreamTrack will have its own source packet stream (one SSRC).=
=0A=
> This will be true, even if there are no difference in the configuration=
=0A=
> of the MediaStreamTrack. Thus no optimizations in regards to collapsing=
=0A=
> or aggregating multiple MediaStreamTrack onto a single source packet=0A=
> stream (SSRC). This is done for keeping things simple and straightforward=
.=0A=
=0A=
I think this is the right way to do it.=0A=
=0A=
>=0A=
> When it comes to the use of CNAME, an RTCWEB end-point shall within the=
=0A=
> context of one origin, i.e. a particular JS creating PeerConnections,=0A=
> use the same CNAME in all these PeerConnections, for all outgoing=0A=
> mediaStreamTracks. However, a end-point MUST be capable of receiving=0A=
> multiple different CNAMEs both within and between different RTP sessions=
=0A=
> and PeerConnections. This definition comes from the following observation=
s.=0A=
>=0A=
> A MediaStream contains multiple MediaStreamTrack, and different=0A=
=0A=
s/contains/can contain/=0A=
=0A=
> MediaStreams can share the same MediaStreamTrack. MediaStreamTrack=0A=
> within one MediaStream is synchronized. Thus, at any point the JS=0A=
=0A=
"synchronized _at playout_"?=0A=
> application can create a new MediaStream that includes MediaStreamTrack=
=0A=
> from different context. To avoid needing to change all SSRC and put the=
=0A=
> SSRCs into a single CNAME at that point, we ensure that this can't happen=
.=0A=
=0A=
By stating that all SSRC's originating from an endpoint shall use the =0A=
same CNAME? (Just for clarification)=0A=
=0A=
>=0A=
> MediaStreamTracks that are being received in one PeerConnection and then=
=0A=
> forward by being added to another one will need to be re-synchronzied=0A=
> into the endpoints outgoing. We discussed and came to the agreement on=0A=
> Monday that forwarding would need to be done equivalent of decoding and=
=0A=
> recoding when forwarding. Implementations may do other things, but must=
=0A=
> function equivalent to this.=0A=
>=0A=
> The above have some forward interoperability properties. If one like to=
=0A=
> be able to use multiple CNAMEs that can be added given that W3C API=0A=
> ensures that you don't cause issue with what CNAME a particular SSRC=0A=
> belongs to.=0A=
=0A=
Could you expand a bit? Do you mean that if there is an API to alter =0A=
CNAMEs (and I guess there is: SDP mangling) it must ...do what?=0A=
=0A=
> In addition if one like to optimize the cases where multiple=0A=
> MediaStreamTrack have a common media source that can be added.=0A=
=0A=
This is not so simple. E.g. assuming we will support pause/resume at =0A=
some point, that could be quite complex if you pause one =0A=
MediaStreamTrack but not another - both using the same source.=0A=
=0A=
The application can already optimize by only sending it once (and clone =0A=
- if required - at the receiving end).=0A=
=0A=
Stefan=0A=
=0A=
=0A=
=0A=
>=0A=
> Disagreements, requests for clarifications?=0A=
>=0A=
>=0A=
> Cheers=0A=
>=0A=
> Magnus Westerlund=0A=
>=0A=
> ----------------------------------------------------------------------=0A=
> Multimedia Technologies, Ericsson Research EAB/TVM=0A=
> ----------------------------------------------------------------------=0A=
> Ericsson AB                | Phone  +46 10 7148287=0A=
> F=E4r=F6gatan 6                | Mobile +46 73 0949079=0A=
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com=0A=
> ----------------------------------------------------------------------=0A=
>=0A=
> _______________________________________________=0A=
> rtcweb mailing list=0A=
> rtcweb@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/rtcweb=0A=
>=0A=
=0A=

From keith.drage@alcatel-lucent.com  Sun Nov 10 11:56:20 2013
Return-Path: 
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 7BA8321E808A for ; Sun, 10 Nov 2013 11:56:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.536
X-Spam-Level: 
X-Spam-Status: No, score=-110.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 5EdcLbDt6xxy for ; Sun, 10 Nov 2013 11:56:14 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCBB21E8144 for ; Sun, 10 Nov 2013 11:56:14 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rAAJu9tE000774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 10 Nov 2013 13:56:11 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rAAJu9xS006625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Nov 2013 20:56:09 +0100
Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.84]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sun, 10 Nov 2013 20:56:09 +0100
From: "DRAGE, Keith (Keith)" 
To: Bernard Aboba , Peter Thatcher 
Thread-Topic: [rtcweb] MTI video codec, charter, RFC 3929
Thread-Index: AQHO3NqvKYlhQnrmxU2nAnCXMnJnipoe29og
Date: Sun, 10 Nov 2013 19:56:05 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0D741B@FR712WXCHMBA10.zeu.alcatel-lucent.com>
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0D741BFR712WXCHMBA10zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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: Sun, 10 Nov 2013 19:56:20 -0000

--_000_949EF20990823C4C85C18D59AA11AD8B0D741BFR712WXCHMBA10zeu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Agree

I am at the point where I would prefer to spend the meeting cycles getting =
things we can agree on, rather than where we seem to be at the moment with =
an issue where there are two clear camps and no real sign of a compromise.

Ultimately the market will decide (and some parts of it probably have alrea=
dy decided - which is probably the reason for no progress).

Keith

________________________________
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Bernard Aboba
Sent: 08 November 2013 23:32
To: Peter Thatcher
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929

I cannot resist adding my speculation to everyone else's. I speculate that =
by this time next year, no one will care about this debate. This could be e=
ither because they have moved on to new (but equally unproductive) argument=
s about VP9 vs. H.265 OR because the RTCWEB WG adopted no MTI but at the sa=
me time focused on enabling codec plugability, so that codec technology cou=
ld evolve more easily.

Rules vs. Tools. Take your choice...

Peter Thatcher  wrote:

You are responding to a little speculation with a lot of speculation, which=
 doesn't seem very valuable.  What should *I* do?  Respond with more specul=
ation, of course.

I will speculate that there is a group of developers that would ignore an H=
.264 MTI:  FOSS projects.  They will ignore it because they can't implement=
 it.  To them, MT(IMPLEMENT) becomes MT(IGNORE_THE_SPEC).  I speculate this=
 includes FOSS browsers, include the Firefox source code and (with no extra=
 knowledge from my employer; it's just speculation) Chromium and FOSS forks=
 of both Firefox and Chromium.  I further speculate this will include FOSS =
non-browser RTCWEB endpoints, such as FOSS RTC mobile apps.

So there's my speculation in response to your speculation in response to St=
ephan's speculation, probably without value, but perhaps worth reminding ev=
eryone that some people (FOSS projects) will have to ignore the spec if H.2=
64 is the MTI, because they have no choice (at least in countries where sof=
tware patents are enforced).  Of course, you may then speculate in return t=
hat no one cares about FOSS projects and browsers, which I speculate would =
be an ironic coming from someone representing a FOSS project.







On Fri, Nov 8, 2013 at 2:55 PM, Adam Roach > wrote:
On 11/7/13 18:57, Stephan Wenger wrote:
...a decision for either of the two candidate codecs will be ignored by a s=
ignificant part of the implementer community.

I'm not sure that's true any longer. Indulge me in a bit of armchair game t=
heory application.

Let's start by looking at ground zero: the browsers. Considering the public=
 statements that have been made, I think it's fairly safe to assume that th=
e following can be taken as given:


  1.  Chrome will support at least VP8.
  2.  Firefox will support both VP8 and H.264.
  3.  Internet Explorer is almost certain to support H.264.
  4.  Safari (including Mobile Safari) is almost certain to support H.264.

If the codecs are *only* those called out above, then you'll end up with an=
 interesting situation in which IE, Safari, and Firefox can all mutually in=
teroperate; Chrome and Firefox can interoperate with each other; and Chrome=
 cannot interoperate with anything else.

I'm not going to put plans in Google's mouth, but envision yourself in the =
same set of circumstances: you own a fully-paid H.264 license, already ship=
 an H.264 codec as part of your browser, and are getting a huge black eye f=
or not interoperating with significant major browsers. What do you do?

Okay. Now, shift your imagined role: you're a non-browser implementor, and =
discover the facts on the ground to be those described above. You can deplo=
y VP8 and work with two of the four major browsers, or you can deploy H.264=
 and work with all four. Yeah, you might not be in love with the structural=
 issues involved in integrating the Cisco library [1]  -- and I'm certainly=
 not -- but you're not actually precluded from using H.264. What do *you* d=
o?

Which is a kind of long way to get to the fact that I think we're in a situ=
ation where H.264 is a de facto MTI codec anyway [2].

Now, imagine you're working in an SDO with this particular set of writing o=
n the wall. You have a solid decision to choose one MTI video codec. You ca=
n choose one that's going to be functionally MTI regardless of what you say=
, or you can choose one that is quite probably going to be ignored by some =
non-trivial set of implementors.

So. What do *we* do?

/a

____
[1] There's been quite a bit of handwringing around the impact this has on =
iOS developers, as they cannot download modules at runtime. Bear in mind th=
at these are curated applications, with a single, well-accounted-for distri=
bution point. These are not libre software by a long shot, and they don't n=
eed to worry about the implications of third parties compiling their own ve=
rsions. So, these implementors statically link in the OpenH264 library, and=
 are exempted for the first 100,000 instances they ship each year. Beyond t=
hat point, they're not "small fish" any more. Back when I was one of the ow=
ners of the company I worked at, "complications arising from selling more t=
han 100,000 copies a year" is the kind of thing that I would place on a lis=
t titled "problems I wish I had."

[2] And to be clear, this is *not* the result I would have preferred. But I=
 recognize that this isn't about my personal preferences. I find myself in =
the odd position of actually arguing for the position contrary to what I th=
ink is ideal, simply because I think it is the only practical path to succe=
ss.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



--_000_949EF20990823C4C85C18D59AA11AD8B0D741BFR712WXCHMBA10zeu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable










Agree


 


I am at the point where I would p=
refer to spend the meeting cycles getting things we can agree on, rather th=
an where we seem to be at the moment with an
 issue where there are two clear camps and no real sign of a compromise.


 


Ultimately the market will decide=
 (and some parts of it probably have already decided - which is probably th=
e reason for no progress).


 


Keith









From: rtcweb-bounces@ietf.org [mail=
to:rtcweb-bounces@ietf.org]
On Behalf Of Bernard Aboba

Sent: 08 November 2013 23:32

To: Peter Thatcher

Cc: rtcweb@ietf.org

Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929








I cannot resist adding my speculation to everyone =
else's. I speculate that by this time next year, no one will care about thi=
s debate. This could be either because they have moved on to new (but equal=
ly unproductive) arguments about VP9
 vs. H.265 OR because the RTCWEB WG adopted no MTI but at the same time foc=
used on enabling codec plugability, so that codec technology could evolve m=
ore easily.




Rules vs. Tools. Take your choice...



Peter Thatcher <pthatcher@google.com> wrote:










Yo=
u are responding to a little speculation with a lot of speculation, which d=
oesn't seem very valuable.  What should *I* do?  Respond with mor=
e speculation, of course.






I =
will speculate that there is a group of developers that would ignore an H.2=
64 MTI:  FOSS projects.  They will ignore it because they can't i=
mplement it.  To them, MT(IMPLEMENT) becomes MT(IGNORE_THE_SPEC).
  I speculate this includes FOSS browsers, include the Firefox source =
code and (with no extra knowledge from my employer; it's just speculation) =
Chromium and FOSS forks of both Firefox and Chromium.  I further specu=
late this will include FOSS non-browser RTCWEB
 endpoints, such as FOSS RTC mobile apps.  






So=
 there's my speculation in response to your speculation in response to Step=
han's speculation, probably without value, but perhaps worth reminding ever=
yone that some people (FOSS projects)
 will have to ignore the spec if H.264 is the MTI, because they have no cho=
ice (at least in countries where software patents are enforced).  Of c=
ourse, you may then speculate in return that no one cares about FOSS projec=
ts and browsers, which I speculate would
 be an ironic coming from someone representing a FOSS project.



























On Fri, Nov 8, 2013 at 2:55 PM, Adam Roach 
<adam@nostrum.com<=
/a>> wrote:






On 11/7/13 18:57, Stephan Wenger wrote:




...a decision for either of the two candidate cod=
ecs will be ignored by a significant part of the implementer community.


I'm not sure that's true any longer. Indulge me in a bit of armchair game t=
heory application.



Let's start by looking at ground zero: the browsers. Considering the public=
 statements that have been made, I think it's fairly safe to assume that th=
e following can be taken as given:




    

  1. Chrome will support at least VP8. 
  2. Firefox will support both VP=
8 and H.264. 
  3. Internet Explorer is almost certain to support H.264.=
 
  4. Safari (including Mobile Safari) is almost certain to support H.2=
64. 



If the codecs are *only* those called out above, then you'll end up with an=
 interesting situation in which IE, Safari, and Firefox can all mutually in=
teroperate; Chrome and Firefox can interoperate with each other; and Chrome=
 cannot interoperate with anything
 else.



I'm not going to put plans in Google's mouth, but envision yourself in the =
same set of circumstances: you own a fully-paid H.264 license, already ship=
 an H.264 codec as part of your browser, and are getting a huge black eye f=
or not interoperating with significant
 major browsers. What do you do?



Okay. Now, shift your imagined role: you're a non-browser implementor, and =
discover the facts on the ground to be those described above. You can deplo=
y VP8 and work with two of the four major browsers, or you can deploy H.264=
 and work with all four. Yeah, you
 might not be in love with the structural issues involved in integrating th=
e Cisco library [1]  -- and I'm certainly not -- but you're not actual=
ly precluded from using H.264. What do *you* do?



Which is a kind of long way to get to the fact that I think we're in a situ=
ation where H.264 is a de facto MTI codec anyway [2].



Now, imagine you're working in an SDO with this particular set of writing o=
n the wall. You have a solid decision to choose one MTI video codec. You ca=
n choose one that's going to be functionally MTI regardless of what you say=
, or you can choose one that is
 quite probably going to be ignored by some non-trivial set of implementors=
.



So. What do *we* do?



/a



____

[1] There's been quite a bit of handwringing around the impact this has on =
iOS developers, as they cannot download modules at runtime. Bear in mind th=
at these are curated applications, with a single, well-accounted-for distri=
bution point. These are not libre
 software by a long shot, and they don't need to worry about the implicatio=
ns of third parties compiling their own versions. So, these implementors st=
atically link in the OpenH264 library, and are exempted for the first 100,0=
00 instances they ship each year.
 Beyond that point, they're not "small fish" any more. Back when =
I was one of the owners of the company I worked at, "complications ari=
sing from selling more than 100,000 copies a year" is the kind of thin=
g that I would place on a list titled "problems I wish
 I had."



[2] And to be clear, this is *not* the result I would have preferred. But I=
 recognize that this isn't about my personal preferences. I find myself in =
the odd position of actually arguing for the position contrary to what I th=
ink is ideal, simply because I think
 it is the only practical path to success.





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb




















--_000_949EF20990823C4C85C18D59AA11AD8B0D741BFR712WXCHMBA10zeu_--

From singer@apple.com  Sun Nov 10 17:53:43 2013
Return-Path: 
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 8163D21E81A5 for ; Sun, 10 Nov 2013 17:53:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 I3wVwx2xzY-3 for ; Sun, 10 Nov 2013 17:53:37 -0800 (PST)
Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5CE21E81A4 for ; Sun, 10 Nov 2013 17:53:36 -0800 (PST)
Received: from relay3.asia.apple.com ( [17.82.200.17]) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 11.34.21841.E9830825; Mon, 11 Nov 2013 09:53:34 +0800 (MYT)
X-AuditID: 1152fe11-b7f256d000005551-17-5280389e9077
Received: from galingale.asia.apple.com ( [17.82.200.117]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id ED.53.26194.E9830825; Mon, 11 Nov 2013 09:53:34 +0800 (MYT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from [17.85.194.253] (unknown [17.85.194.253]) by mail.asia.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MW200MRIT99DZ00@mail.asia.apple.com> for rtcweb@ietf.org; Mon, 11 Nov 2013 09:53:34 +0800 (SGT)
From: David Singer 
In-reply-to: <949EF20990823C4C85C18D59AA11AD8B0D741B@FR712WXCHMBA10.zeu.alcatel-lucent.com>
Date: Mon, 11 Nov 2013 09:53:32 +0800
Message-id: <4DBFD52B-BAFF-42BB-906D-728DF9C07F78@apple.com>
References:  <949EF20990823C4C85C18D59AA11AD8B0D741B@FR712WXCHMBA10.zeu.alcatel-lucent.com>
To: "DRAGE, Keith (Keith)" 
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUiGHRCUHeeRUOQwbonFhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro2XNOcaC1WwVh18/ZGtgbGTtYuTgkBAwkXi92raLkRPIFJO4 cG89WxcjF4eQwG5GiaaNL1kgEiYSy+/8Z4dITGCSOPN8AxNIgldAUOLH5HssIIOYBeQlDp6X BQkzC2hJfH/UygJRv5hJYur7f2CDhAUsJBa/6mUHsdkEVCUezDnGCGJzCsRKXFgMEWcBiv94 cIMdYlC1RPfVj4wQu2wkTu/5C3VEL6PE5AePWEESIgLWEq8eb2GDuFRW4vS552CbJQS+skpc O/aGbQKj8Cwkx85COHYWkmMXMDKvYhTPTczM0c3MM9RLLM5M1EssKMhJ1UvOz93ECA7of4I7 GKcuNDzEKMDBqMTDu+1abZAQa2JZcWXuIUYJDmYlEV5vpoYgId6UxMqq1KL8+KLSnNTiQ4zS HCxK4ryiKUDVAumJJanZqakFqUUwWSYOTqkGxpOfEpIuOoe/KF9ZyM98P+bAvRcixfYHFz02 np16UbV67l+5iTzZrSxHzRK/17v8zHAWy92o0XO0b5/FvMuWVQlpDTuFJ3zZ7M1TFN+w/M3s qwwVzuoTLkufiXw0e/+MW7a3f08U2TF16y5l41fFygxtbUo35N/tfFfm6rV4dadI+LHmrZ2t qUosxRmJhlrMRcWJACSGzcZkAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUiGHSiVHeeRUOQwa7VZhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro2XNOcaC1WwVh18/ZGtgbGTtYuTkkBAwkVh+5z87hC0mceHe erYuRi4OIYEJTBJnnm9gAknwCghK/Jh8j6WLkYODWUBe4uB5WZAws4CWxPdHrSwQ9YuZJKa+ /8cCkhAWsJBY/KoXbCibgKrEgznHGEFsToFYiQuLIeIsQPEfD26wQwyqlui++pERYpeNxOk9 f9khhvYySkx+8AjsUhEBa4lXj7ewQVwqK3H63HOWCYwCs5DcNwvhvllI7lvAyLyKUbQoNSex 0lgvsTgzUS+xoCAnVS85P3cTIyQEBXcwfphqeIhRgINRiYc37n5tkBBrYllxZe4hRgkOZiUR Xm+mhiAh3pTEyqrUovz4otKc1OJDjNIcLErivCkpQNUC6YklqdmpqQWpRTBZJg5OqQbGcP7O ZIa+JM0DZoKuHx7Nn7ltneXxU84d+k9ZdY0m/zVnS21k/CO1tvWyvLLCvMgqg41K56KM9YUP nTslphe25LacrpNkWnvcP6mdvRO6VT3uML6YJJQ6b8KM/zGrmluuPE3xeXIwz9TG80qZuN3C ACYWmWBPpfwPT3N2R/TFM4lVpXDePqfEUpyRaKjFXFScCACQuU+1PQIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
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: Mon, 11 Nov 2013 01:53:43 -0000

On Nov 11, 2013, at 3:56 , "DRAGE, Keith (Keith)"  wrote:

> Agree
>  
> I am at the point where I would prefer to spend the meeting cycles getting things we can agree on, rather than where we seem to be at the moment with an issue where there are two clear camps and no real sign of a compromise.
>  

I agree.  I don't think anyone wants to (re-)implement H.261 or something else that old.  I think the best we can do right now is what I suggested: must implement either H.264 CBP or VP8, and should implement both.  It's not perfect, but it may be better than silence.  (And by specifying profile/level of H.264, we are helping convergence.)

I doubt that there is anyone who cannot live with this.


David Singer
Multimedia and Software Standards, Apple Inc.


From magnus.westerlund@ericsson.com  Mon Nov 11 01:24:23 2013
Return-Path: 
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 7ED5821F9F6F for ; Mon, 11 Nov 2013 01:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.265
X-Spam-Level: 
X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=-1.627, BAYES_00=-2.599, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 KncNQJwEMEJF for ; Mon, 11 Nov 2013 01:23:58 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4C621E8213 for ; Mon, 11 Nov 2013 01:11:03 -0800 (PST)
X-AuditID: c1b4fb32-b7f388e0000057e0-03-52809f1d6d00
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 92.A0.22496.D1F90825; Mon, 11 Nov 2013 10:10:55 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.328.9; Mon, 11 Nov 2013 10:10:22 +0100
Message-ID: <52809F33.1020201@ericsson.com>
Date: Mon, 11 Nov 2013 10:11:15 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= ,  "rtcweb@ietf.org" 
References: <527BD94C.2070900@ericsson.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3D5EF5@ESESSMB209.ericsson.se>
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C3D5EF5@ESESSMB209.ericsson.se>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgluLIzCtJLcpLzFFi42KZGfG3Rld+fkOQwfnp+hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr402PdsFak4pZC/wbGOdodTFyckgImEisnniBEcIWk7hwbz1b FyMXh5DACUaJkxeOs0I4yxkl5q87w97FyMHBK6At0bejDKSBRUBV4tqDi2DNbAIWEjd/NLKB 2KICwRLnXy1mB7F5BQQlTs58wgJiiwiUSFw5f4AJxBYWMJO49mcSK4gtJJArMef/F2aQ8ZwC fhJrzlqCmBIC4hI9jUEgFcwCehJTrrYwQtjyEs1bZzNDdGpLNDR1sE5gFJyFZNksJC2zkLQs YGRexShZnFpcnJtuZKCXm55bopdalJlcXJyfp1ecuokRGJoHt/w22sF4co/9IUZpDhYlcd7r rDVBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgdRdIFFm/znLE6usx8quGy8kfbePPTbCXa pc5Ec7Fn8YW9NVBgz1OTKLGf8XDGxxv/azQ/fO2+yP2g9f+Wq2x6M8/+Ybi4aao2YyPb71ed aiyFk/3mvT2wd/77FVPKqy7oh8sHixm3TE76X5mnXejBu+z6qYgQzYynGiKed8+cqD6xwfG4 1DIlluKMREMt5qLiRAAKX5X3GwIAAA==
Subject: Re: [rtcweb] Proposal for API mapping for RTP
X-BeenThere: rtcweb@ietf.org
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: Mon, 11 Nov 2013 09:24:25 -0000

Stefan, WG,

Please see inline

On 2013-11-10 10:32, Stefan Håkansson LK wrote:
> On 07/11/13 19:18, Magnus Westerlund wrote:
>> WG,
>> (As draft-ietf-rtcweb-rtp-usage Editor)
> 
> Magnus,
> 
> thanks for this write up. Some comments inline.
> 
>>
>> There was discussion yesterday afternoon on the W3C MediaStream to RTP
>> mapping. This did arrive on some conclusions that I here try to word
>> into a proposal for everyones review.
>>
>> A MediaStreamTrack is sent over a source packet stream (one SSRC) and
>> can have additionally redundancy packet streams (SSRCs). These
>> redundnacy streams are RTP retranmission streams or FEC.
> 
> Can't there be enhancement packet streams as well (for layered codecs)?

So the enhancement layers if sent as individual packet streams are
called dependent layers in the current RTP taxonomy draft. Yes, they
could also exist. However, as there are no API support for these at the
current day they haven't been defined. If one uses something like SVC
MST, then clearly additions in how to interpret this must be provided.
If this is a single rooted dependency tree then I think additional SSRCs
for dependencies are quite straightforward. There will need to exist a
way of indicating that SSRCs are dependency streams for a source stream
to make handling work well.

> 
> And in some proposals a single MediaStreamTrack can be sent in more than 
> one encoding (UA - as opposed to JS handled - handled simulcast) - is 
> that covered?

So simulcast was discussed, and that would result in more than one
source stream associated with that MediaStreamTrack. This have similar
requirements that the a receiver understands that this is a simulcast of
the same MediaStreamTrack as another encoding version.

For both simulcast and scalable coding, I am happy to make it clear that
these can result in multiple source packet streams, and further have
additional dependency packet streams.

> 
>>
>> When multiple MediaStreamTracks have the same Media Source, then the
>> fact that one has creaeted multiple MediaStreamTracks and added these
>> through a MediaStream to the PeerConnection is going to result in that
>> each MediaStreamTrack will have its own source packet stream (one SSRC).
>> This will be true, even if there are no difference in the configuration
>> of the MediaStreamTrack. Thus no optimizations in regards to collapsing
>> or aggregating multiple MediaStreamTrack onto a single source packet
>> stream (SSRC). This is done for keeping things simple and straightforward.
> 
> I think this is the right way to do it.
> 
>>
>> When it comes to the use of CNAME, an RTCWEB end-point shall within the
>> context of one origin, i.e. a particular JS creating PeerConnections,
>> use the same CNAME in all these PeerConnections, for all outgoing
>> mediaStreamTracks. However, a end-point MUST be capable of receiving
>> multiple different CNAMEs both within and between different RTP sessions
>> and PeerConnections. This definition comes from the following observations.
>>
>> A MediaStream contains multiple MediaStreamTrack, and different
> 
> s/contains/can contain/

Yes

> 
>> MediaStreams can share the same MediaStreamTrack. MediaStreamTrack
>> within one MediaStream is synchronized. Thus, at any point the JS
> 
> "synchronized _at playout_"?

That is not for us in IETF to define. My aim is to enable a receiver to
perform synchronized playout. If it does it or not, I think is up to the
API definition.

>> application can create a new MediaStream that includes MediaStreamTrack
>> from different context. To avoid needing to change all SSRC and put the
>> SSRCs into a single CNAME at that point, we ensure that this can't happen.
> 
> By stating that all SSRC's originating from an endpoint shall use the 
> same CNAME? (Just for clarification)

Yes. but I would change this from "stating" to "REQUIRE".

> 
>>
>> MediaStreamTracks that are being received in one PeerConnection and then
>> forward by being added to another one will need to be re-synchronzied
>> into the endpoints outgoing. We discussed and came to the agreement on
>> Monday that forwarding would need to be done equivalent of decoding and
>> recoding when forwarding. Implementations may do other things, but must
>> function equivalent to this.
>>
>> The above have some forward interoperability properties. If one like to
>> be able to use multiple CNAMEs that can be added given that W3C API
>> ensures that you don't cause issue with what CNAME a particular SSRC
>> belongs to.
> 
> Could you expand a bit? Do you mean that if there is an API to alter 
> CNAMEs (and I guess there is: SDP mangling) it must ...do what?

I think this requires an API, and I question if any SDP mangling should
be allowed to change the CNAME. This due to the privacy concerns. If the
JS can set the CNAME, then it can enforce traceability of users or
end-points at RTP/RTCP level.

I think the API we did discuss was to consider when the
MediaStreamTracks in one MediaStream incoming in one PeerConnection gets
added as outgoing in another PeerConnection the original CNAME could be
maintained. However, that requires explicit lock down preventing one to
create a MediaStream with one of these MediaStreamTracks and any other
MediaStreamTrack comming from another CNAME context.

> 
>> In addition if one like to optimize the cases where multiple
>> MediaStreamTrack have a common media source that can be added.
> 
> This is not so simple. E.g. assuming we will support pause/resume at 
> some point, that could be quite complex if you pause one 
> MediaStreamTrack but not another - both using the same source.

Yes, that was understood in the discussion that such combinations
requires sane unions of settings across multiple MediaStreamTrack. In
your of paused or not, it is quite simple to agree that if any consumer
exists, i.e. not all paused, then it must be delivered.

But, clearly a reasons for the simple rule proposed.

> 
> The application can already optimize by only sending it once (and clone 
> - if required - at the receiving end).
> 

Good,

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Mon Nov 11 05:53:14 2013
Return-Path: 
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 851EF11E8176 for ; Mon, 11 Nov 2013 05:53:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.538
X-Spam-Level: 
X-Spam-Status: No, score=-105.538 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 hSRlaRO2fEZk for ; Mon, 11 Nov 2013 05:53:08 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9695911E80FA for ; Mon, 11 Nov 2013 05:53:07 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-6b-5280e142c883
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A7.76.03802.241E0825; Mon, 11 Nov 2013 14:53:06 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.328.9; Mon, 11 Nov 2013 14:53:05 +0100
Message-ID: <5280E181.20104@ericsson.com>
Date: Mon, 11 Nov 2013 14:54:09 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" , 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFJMWRmVeSWpSXmKPExsUyM+Jvra7Tw4Ygg0VLBS2uzljCbLH2Xzu7 A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJVx8PAX5oJFgRWP9u5lbWC8Z9fFyMkhIWAi MXP+WnYIW0ziwr31bCC2kMAhRok/b+O6GLmA7OWMEo3Xt7N0MXJw8ApoSqw+EQ1SwyKgKnFu 0ROwXjYBC4mbPxrBekUFgiXOv1oMFucVEJQ4OfMJC4gtIhAlMe39bUYQW1jATGLmjy2MICMl BMQlehqDQMLMAnoSU662MELY8hLNW2czQ5yjLdHQ1ME6gZF/FpKps5C0zELSsoCReRUje25i Zk56udEmRmB4HdzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTB KdXAmFjx5mptnO11/ymLtSWzZbXMJk7XWPg3ZzPXoeb/my3uiE5av1HuuZSV6MxbT3Inhjy+ +facEeOdK14/q1tm/TqzM4b/s66bDr96T4piwKwfEjH7Djf9sfKYHhJsqCo2rdvixrF8dx2m bzN7Su7Y3WzV33PxrskpNyfjyez5FsLPi0zP39Q0UWIpzkg01GIuKk4EAFOI+m/9AQAA
Subject: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06
X-BeenThere: rtcweb@ietf.org
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: Mon, 11 Nov 2013 13:53:14 -0000

Hi,

I did review the data channel draft prior to the meeting and thought I
would provide my comments.

1. Usage of RTCWeb vs WebRTC when referring to the whole solution. My
recollection was that we agreed to use WebRTC for this. I think we
should try to align this language. Audio, Security and RTP usage uses
WebRTC, while Data channel, overview and Transport uses RTCWeb.

2. Section 3.2:
   U-C 6:  Renegotiation of the set of media streams in the
      PeerConnection.

What "media streams" are being referred to here. Or is i better to
express this as "Renegotiation of the configuration of the PeerConnection."?

3. Section 3.2:
   U-C 7:  Proxy browsing, where a browser uses data channels of a
      PeerConnection to send and receive HTTP/HTTPS requests and data,
      for example to avoid local internet filtering or monitoring.

Yes, this may be something that is possible, but to express it as a use
cases intended to be supported might not be the best. We are after all
likely talking about circumventing local security policies. I would also
note that "Internet" is with capital I.

4. Section 4:
   Req. 1:   Multiple simultaneous data channels MUST be supported.
      Note that there may 0 or more media streams in parallel with the
      data channels, and the number and state (active/inactive) of the
      media streams may change at any time.

Which "media stream" are you referring to in the above?

5. Section 4:
   Req. 3:   Data channels MUST be congestion controlled; either
      individually, as a class, or in conjunction with the media
      streams, to ensure that data channels don't cause congestion
      problems for the media streams, and that the RTCWeb PeerConnection
      as a whole is fair with competing traffic such as TCP.

A: What "media stream" are you referring to here?

B: "and that the RTCWeb PeerConnection
      as a whole is fair with competing traffic such as TCP."

I don't think it is a MUST requirement. Neither am I convinced that a
PeerConnection needs to be fair with an unspecified number of TCP
traffic. It might be simplest to strike the last part.

6. Section 4:
[ TBD: how this is encoded and what the impact of this is. ]

Didn't we have some direction decisions on how priority was to be
handled at least locally by the end-point. Please add this to the draft.
I also hope that the way of representing priorities can get clearer from
an API perspective.

7. Section 5:
"   o  The congestion control is modifiable for integration with media
      stream congestion control."

I think this is an exaggeration, and not supported by current sets of
specifications, if it is supported please provide a reference.

8. Section 5:
"Using DTLS over UDP in combination with ICE enables NAT traversal in
IPv4 based networks."

I would like to point out that ICE do provide firewall traversal for
firewalls with certain type of filtering rules like the basic stateful
filtering. These apply to IPv6 equally, not only IPv4.

9.  Section 5:
"   Each SCTP user message contains a so called Payload Protocol
   Identifier (PPID) that is passed to SCTP by its upper layer and sent
   to its peer.  This value can be used to multiplex multiple protocols
   over a single SCTP association.  The sender provides for each
   protocol a specific PPID and the receiver can demultiplex the
   messages based on the received PPID."

I have some difficulties in determining the relevance of this in the
context of WebRTC. Can you please provide a clear explanation why PPID
are relevant here. Will not all traffic from an WebRTC endpoint use the
PPIDs associated with the data protocol, rather than any "native" PPIDs?

10. Section 5:

Can you please clarifiy the demultiplexing for WebRTC by discussing
STUN, vs SRTP vs DTLS and secondly that DTLS-SRTP and DTLS frames with
SCTP can co-exist in the same DTLS stack. At least on an level where you
can point to all the relevant sections in other specifications to
explain that these can coexist given certain constraints. This is likely
its own sub-section.

11. Section 5:

   o  shares the DTLS connection with the media channels.

what is "media channels"?

12. Section 5:
"  Since DTLS is typically implemented in user-land, the SCTP stack also
   needs to be a user-land stack."

I wonder what the message of this sentence is? The reason is that I
wonder what it should be saying if one implements DTLS in a kernel, or
similar if one despite a DTLS user-land stack uses a SCTP stack in the
kernel through access to raw sockets.

13. Section 5:
   Incoming ICMP or ICMPv6 messages can't be processed by the SCTP
   layer, since there is no way to identify the corresponding
   association.

Also here I get a bit confused, I assume what you are after is the issue
that incoming ICMP messages will be arriving related to the UDP flow,
not in relation to an kernel SCTP association, thus there is a routing
issue for ICMP to reach the above DTLS existing SCTP association. Not
impossible to solve, just not available with existing APIs.

14. Section 5:
   "This protocol stack MUST support the usage of multiple SCTP streams."

I wonder which layer is affected by this. Isn't this only affecting SCTP
implementation and the higher layers? Can't you be more specific thus?

15. Section 5:
   Using a congestion control
   different from the standard one might improve the impact on the
   parallel SRTP media streams.  Since SCTP does not support the
   negotiation of a congestion control algorithm, alternate congestion
   controls SHOULD only require a different sender side behavior using
   existing information carried in the association.

A: I wonder if adding a "yet" into the second sentence to make clear
that in the future there might be support for negotiating congestion
control.

B: Also, what happens if one violate the SHOULD and require receiver
side information and the peer don't support it. That clearly can't be
acceptable? Can this be formulated in some other way that is tighter
without preventing sender side changes?

16. Section 6.1:
   o  The dynamic address reconfiguration extension defined in [RFC5061]
      MUST be used to signal the support of the stream reset extension
      defined in [RFC6525], other features of [RFC5061] MUST NOT be
      used.

A question, are theses other features, destructive to the SCTP
association, or simply unnecessary to implement? If it is the first,
then I think MUST NOT be used is fine, but if else, why not simple say
that they are NOT REQUIRED to be implemented?


17. Section 6.1:
   o  The partial reliability extension defined in [RFC3758] MUST be
      supported.  In addition to the timed reliability PR-SCTP policy
      defined in [RFC3758], the limited retransmission policy defined in
      [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported.

So what is the status of this individual document, did it get adopted
into TSVWG? I think this is an important question, as it is one thing
where we can consider going forward without the extension and add it
later when ready?

18. Section 6.2:
"  Additionally,
   the negotiation SHOULD include some type of congestion control
   selection. "

Okay, this appears very fuzzy. And what name space or specifications are
you going to use to negotiate what the different options are?

19. Section 6.3:
It will use the DTLS connection selected via SDP;
   typically this will be shared via BUNDLE or equivalent with DTLS
   connections used to key the DTLS-SRTP media streams.

In which way is the DTSL connection "selected" via SDP?

20. Section 6.2:

   When one side wants to open a channel using external negotiation, it
   picks a Stream.  This can be based on the DTLS role (the client picks
   even stream identifiers, the server odd stream identifiers) or done
   in a different way.  However, the application is responsible for
   avoiding collisions with existing Streams.  If it attempts to re-use
   a Stream which is part of an existing Channel, the addition SHOULD
   fail.  In addition to choosing a Stream, the application SHOULD also
   inform the protocol of the options to use for sending messages.  The
   application MUST ensure in an application-specific manner that the
   other side will also inform the protocol that the selected Stream is
   to be used, and the parameters for sending data from that side.

So why is this specified here and not in the Data Protocol? Especially
using RFC 2119 terms, it appears to be colliding or at least overlapping
specifications?

21. Section 6.6
   It is recommended that message size be kept within certain size
   bounds (TBD) as applications will not be able to support arbitrarily-
   large single messages.

I guess this will be resolved by the WG session agreement, or?

22.

Section 8:
              +---------------------+-----------+-----------+
              | Value               | SCTP PPID | Reference |
              +---------------------+-----------+-----------+
              | DOMString Last      | 51        | [RFCXXXX] |
              | Binary Data Partial | 52        | [RFCXXXX] |
              | Binary Data Last    | 53        | [RFCXXXX] |
              | DOMString Partial   | 54        | [RFCXXXX] |
              +---------------------+-----------+-----------+

Where are the definitions of these definitions?

23. Section 10.2:

   [I-D.tuexen-tsvwg-sctp-prpolicies]
              Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
              "Additional Policies for the Partial Delivery Extension of
              the Stream Control Transmission Protocol", draft-tuexen-
              tsvwg-sctp-prpolicies-03 (work in progress), October 2013.

This is a normative reference.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From thp@westhawk.co.uk  Fri Nov  8 11:24:47 2013
Return-Path: 
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 1DCD721E8152 for ; Fri,  8 Nov 2013 11:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.327
X-Spam-Level: 
X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.271,  BAYES_00=-2.599, HTML_MESSAGE=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 GOV-H+1KJ0SU for ; Fri,  8 Nov 2013 11:24:42 -0800 (PST)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE9A11E80FB for ; Fri,  8 Nov 2013 11:24:40 -0800 (PST)
Received: (qmail 31759 invoked from network); 8 Nov 2013 19:24:38 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 11648
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 8 Nov 2013 19:24:38 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 0FB1718A06BF; Fri,  8 Nov 2013 19:24:38 +0000 (GMT)
Received: from [192.168.157.136] (unknown [192.67.4.37]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B927518A03D4;  Fri,  8 Nov 2013 19:24:37 +0000 (GMT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1FBF446D-2A8A-4DBD-95C9-1548BC9E24B7"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: tim panton 
In-Reply-To: 
Date: Fri, 8 Nov 2013 19:24:37 +0000
Message-Id: 
References: 
To: David Benham 
X-Mailer: Apple Mail (2.1816)
X-Mailman-Approved-At: Mon, 11 Nov 2013 06:14:08 -0800
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] On demand & Internet TV via rtcweb? (was: Current H.264...)
X-BeenThere: rtcweb@ietf.org
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 19:24:47 -0000

--Apple-Mail=_1FBF446D-2A8A-4DBD-95C9-1548BC9E24B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On 8 Nov 2013, at 19:11, David Benham  wrote:

> Bet the vast majority of those 800 app developers' business model is =
to make money off *others* Internet content vs themselves being the =
provider of such.  If they are doing that legally, those licenses and =
royalties/revenue sharing arrangements are often really complex.

Well 50 of them are p2p messaging apps (so called OTT players) - where =
the content is _absolutely_ generated
by their users.

But I=92m more thinking of the rent-my-appartment app where the owner =
can do a live video tour, or perhaps remote assist for
using the cooker. The rt-video is a nice-to-have but they certainly =
won=92t spend time with the MPEG-LA=92s lawyers=20
to add it.=20

Likewise the summon-a-prepaid taxi app - it might be nice to show the =
driver where you are waiting with live video,
but it is only spice to the main app purpose. Again these guys won=92t =
do video if it means they have to distract them selves with lawyers when =
they hit the 100k user mark.

Or one of the _infinite_ number of wedding planner apps - perhaps they=92d=
 add a live consult feature, but not if
it cost legal time and money to do.=20

>=20
> Regardless, how many providers of on-demand titles and broadcast TV =
over the Internet would use rtcweb to deliver such no matter which codec =
was MTI?=20

I have no idea, those aren=92t the markets I know about. They are =
businesses where the _key_ point is video delivery,
I think there are a lot of interesting apps where it is the icing on the =
wedding cake (so to speak), we risk losing those folks from webRTC.

>=20
> On Fri, Nov 8, 2013 at 8:24 AM, Tim Panton new  =
wrote:
>=20
> Interesting datapoint on the >100K subscribers front.  =46rom Flurry - =
(via @BenedictEvans) There are at
> least 800 app developers with > 1M subscribers. So there seem to me to =
be quite a few 'Little guys' who
> may avoid webRTC if it requires an H264 license .=20
>=20
> http://blog.flurry.com//bid/102208/the-mobile-content-exlposion
>=20
>=20
>=20


--Apple-Mail=_1FBF446D-2A8A-4DBD-95C9-1548BC9E24B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On 8 Nov 2013, at 19:11, David Benham =
<dabenham@gmail.com> =
wrote:

Bet the vast majority of those 800 =
app developers' business model is to make money off *others* Internet =
content vs themselves being the provider of such.  If they are =
doing that legally, those licenses and royalties/revenue sharing =
arrangements are often really =
complex.

Well 50 of them are p2p =
messaging apps (so called OTT players) - where the content is =
_absolutely_ generated
by their =
users.

But I=92m more thinking of the =
rent-my-appartment app where the owner can do a live video tour, or =
perhaps remote assist for
using the cooker. The rt-video is a =
nice-to-have but they certainly won=92t spend time with the MPEG-LA=92s =
lawyers 
to add =
it. 

Likewise the summon-a-prepaid taxi =
app - it might be nice to show the driver where you are waiting with =
live video,
but it is only spice to the main app purpose. =
Again these guys won=92t do video if it means they have to distract them =
selves with lawyers when they hit the 100k user =
mark.

Or one of the _infinite_ number of =
wedding planner apps - perhaps they=92d add a live consult feature, but =
not if
it cost legal time and money to =
do. 



Regardless, how many providers of on-demand titles and =
broadcast TV over the Internet would use rtcweb to deliver such no =
matter which codec was =
MTI? 

I have no =
idea, those aren=92t the markets I know about. They are businesses where =
the _key_ point is video delivery,
I think there are a lot of =
interesting apps where it is the icing on the wedding cake (so to =
speak), we risk losing those folks from webRTC.



On Fri, Nov 8, 2013 at 8:24 AM, Tim Panton new <thp@westhawk.co.uk> =
wrote:



Interesting datapoint on the >100K =
subscribers front.  =46rom Flurry - (via @BenedictEvans) There are =
at


least 800 app developers with > 1M subscribers. So there seem to =
me to be quite a few 'Little guys' who
may avoid webRTC if it =
requires an H264 license . 


=







=

--Apple-Mail=_1FBF446D-2A8A-4DBD-95C9-1548BC9E24B7--

From ibc@aliax.net  Mon Nov 11 10:12:17 2013
Return-Path: 
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 471B411E8234 for ; Mon, 11 Nov 2013 10:12:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.676
X-Spam-Level: 
X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 XERV5Rgnz+jX for ; Mon, 11 Nov 2013 10:12:12 -0800 (PST)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3815011E8235 for ; Mon, 11 Nov 2013 10:12:01 -0800 (PST)
Received: by mail-qc0-f169.google.com with SMTP id x12so4516069qcv.14 for ; Mon, 11 Nov 2013 10:12:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=vbYYVLMSWr1eKIYaJ07jecOukX0UcRXSDlDmm5WZRFQ=; b=hOklAZVpsharK+NFWLaQG5VcpQy9yh94TVlY9hGrf44T6r+6xdM6v3Q9FkWzWp2kYN PCS2vPKEHwOveA1y3UCoPURxOoq3M7eS4geQSYrqXopk4RDsgwqmylPEOGetfGeixmea akWQtyEDbH10fdyEx+zcqTA6cHi0NBEgIbUnL7p9HJtTaMOL3Caxi1zBqPfMzGnyEsq4 svadyC7NPyOEIDkJSZbdMZVgXAv1Bl4khmnMp8xGPbQ/pVfbmGcBjIBUWaoys4K6TAKM 3KjnZW+teNGmkrC3Ki9PeWbNT/Opz6qgCFaoOzowlK7hmc04L1Owdf1Px32W3FukA5KK im9w==
X-Gm-Message-State: ALoCoQkdile99elg50MC5tch5U7oNsyQcBxEM5T2semCujJNzFfG66FDHQczNuZbacEIkz7plGDd
MIME-Version: 1.0
X-Received: by 10.49.12.111 with SMTP id x15mr49703104qeb.14.1384193521393; Mon, 11 Nov 2013 10:12:01 -0800 (PST)
Received: by 10.96.71.8 with HTTP; Mon, 11 Nov 2013 10:12:01 -0800 (PST)
Received: by 10.96.71.8 with HTTP; Mon, 11 Nov 2013 10:12:01 -0800 (PST)
Date: Mon, 11 Nov 2013 19:12:01 +0100
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=047d7b6d86fe24bb3204eaeaabd7
Subject: [rtcweb] No-Bundle in just one peer
X-BeenThere: rtcweb@ietf.org
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: Mon, 11 Nov 2013 18:12:17 -0000

--047d7b6d86fe24bb3204eaeaabd7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

In case peer A sends a SPD without Bundle support (so it needs to receive
incoming tracks in separate ports and send tracks from separate ports) does
it aslo mean that peer B must not use Bundle? Or could peer A use two local
ports (no Bundle) to send/receive tracks to/from a single port in peer B?

Thanks a lot.

--
I=C3=B1aki Baz Castillo


--047d7b6d86fe24bb3204eaeaabd7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,


In case peer A sends a SPD without Bundle support (so it nee=
ds to receive incoming tracks in separate ports and send tracks from separa=
te ports) does it aslo mean that peer B must not use Bundle? Or could peer =
A use two local ports (no Bundle) to send/receive tracks to/from a single p=
ort in peer B?



Thanks a lot.


--

I=C3=B1aki Baz Castillo

<ibc@aliax.net>


--047d7b6d86fe24bb3204eaeaabd7--

From lorenzo@meetecho.com  Mon Nov 11 10:17:21 2013
Return-Path: 
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 CD10121E8201 for ; Mon, 11 Nov 2013 10:17:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.494
X-Spam-Level: 
X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3]
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 jEesPckKP9iQ for ; Mon, 11 Nov 2013 10:17:16 -0800 (PST)
Received: from smtpdg7.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by ietfa.amsl.com (Postfix) with ESMTP id 7876711E823A for ; Mon, 11 Nov 2013 10:17:15 -0800 (PST)
Received: from lminiero ([143.225.229.166]) by smtpcmd03.ad.aruba.it with bizsmtp id oJHC1m0053c3Lvj01JHC2Q; Mon, 11 Nov 2013 19:17:12 +0100
Date: Mon, 11 Nov 2013 19:17:12 +0100
From: Lorenzo Miniero 
To: =?UTF-8?B?ScOxYWtp?= Baz Castillo 
Message-ID: <20131111191712.59e4e44d@lminiero>
In-Reply-To: 
References: 
Organization: Meetecho
X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No-Bundle in just one peer
X-BeenThere: rtcweb@ietf.org
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: Mon, 11 Nov 2013 18:17:22 -0000

Il giorno Mon, 11 Nov 2013 19:12:01 +0100
I=C3=B1aki Baz Castillo  ha scritto:

> Hi,
>=20
> In case peer A sends a SPD without Bundle support (so it needs to
> receive incoming tracks in separate ports and send tracks from
> separate ports) does it aslo mean that peer B must not use Bundle? Or
> could peer A use two local ports (no Bundle) to send/receive tracks
> to/from a single port in peer B?
>=20
> Thanks a lot.
>=20
> --
> I=C3=B1aki Baz Castillo
> 


Hi I=C3=B1aki,

not sure what the spec currently mandates, but this works already in
existing implementations. Peer A just needs to do the ICE and DTLS
dance twice from its two ports towards the single port in B (twice or
more, in case you're not muxing RTCP either).

Lorenzo =20

From juberti@google.com  Mon Nov 11 13:04:06 2013
Return-Path: 
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 3B0BF11E8103 for ; Mon, 11 Nov 2013 13:04:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level: 
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.179,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 wy+-1GofWQYQ for ; Mon, 11 Nov 2013 13:04:05 -0800 (PST)
Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7E42411E80F9 for ; Mon, 11 Nov 2013 13:04:05 -0800 (PST)
Received: by mail-vb0-f52.google.com with SMTP id f12so3586394vbg.25 for ; Mon, 11 Nov 2013 13:04:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/Ao+PWLqO9ZmVSlBZAuVOPr2DsMU1RJkMvHTW30HDww=; b=hBXXMR9ScZsCzmV4ryIOcFF7woes/Bt0bcktxwmANTwBvp8+40185rQmRExBtX2YGp KQutiapZUO9lztu+hGty0FCGcBhMh9dZX/2bZU0AW4Xh2qy9QXt79xf0f0LrBGdWaLm8 4VzLZh/ZRt3Evf5aMTAagX8dtKUJfWCuZtrKnh3Vm8osv1oiNlSpZmPPYL0giThiF9w4 LHOy26FZLddWaR2MrsJm7457u6eAROEWVD82OUqsKZCdeVWnrJ1GdhiapfbyCvcmjGcU G/I/waCyahv7hb3pLRVrE0P6hK75E2SobGkDD4JF4msb4st4tQnMLB7TXLipGUs+M0B3 Rl9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/Ao+PWLqO9ZmVSlBZAuVOPr2DsMU1RJkMvHTW30HDww=; b=VAERdPBwE1QsrL7Qgj+hcoNbDfzcZ8sWHvcn/sRBIbRZcNS7Wk56JT3xi7mTolRlbT QIGDq/olQKzUisIYJ/TqRWCD6/9hKcsm17Ln75Fot6mfcGed/Ulk6LF83UzZ9x7ILsxL fyU1tOHXW1XbBr5vSOGKgkbnhihaJyMMFG1KmkJCLovNgcQGCUUj84njGRLkbhrdrMWa kvjn3iLWYjxvDFzHaIXyoG63L/rQJYMctk8bXdQbYWiAxuhblQxqx8bNFLU3o15Z7Ilt iwzYGokY47uVPbOdjm9dy8DuZNfjtfdVqNAHWTTTaWZ2LBxH9GDMuWPouIwMEYBgcZSz ay2Q==
X-Gm-Message-State: ALoCoQm9b9rAfYJwjqnS0ETnK7cXHOnKQzAsbh4LYi5bBurrbpSD7VoaCtdLJ0WDt6cirdtJ/mjZ000DwNslBlpQiU5pAgbWcPGllL3OsIDfEEeHWFEbgDHzp8X/CInO6Z4pesklmmwy51fGEpexarl7ltvJLF4BKe71QJqKZEPyTWt4D6nOgbI+7BsEdWyetw91Qj7H4t3v
X-Received: by 10.58.233.98 with SMTP id tv2mr25612719vec.11.1384203844810; Mon, 11 Nov 2013 13:04:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Mon, 11 Nov 2013 13:03:43 -0800 (PST)
In-Reply-To: <20131111191712.59e4e44d@lminiero>
References:  <20131111191712.59e4e44d@lminiero>
From: Justin Uberti 
Date: Mon, 11 Nov 2013 13:03:43 -0800
Message-ID: 
To: Lorenzo Miniero 
Content-Type: multipart/alternative; boundary=089e0115ef9c77906604eaed129f
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] No-Bundle in just one peer
X-BeenThere: rtcweb@ietf.org
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: Mon, 11 Nov 2013 21:04:06 -0000

--089e0115ef9c77906604eaed129f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

No, B cannot BUNDLE if A is not BUNDLEing. There are a number of corner
cases where things don't work right in the situation described above.


On Mon, Nov 11, 2013 at 10:17 AM, Lorenzo Miniero wro=
te:

> Il giorno Mon, 11 Nov 2013 19:12:01 +0100
> I=C3=B1aki Baz Castillo  ha scritto:
>
> > Hi,
> >
> > In case peer A sends a SPD without Bundle support (so it needs to
> > receive incoming tracks in separate ports and send tracks from
> > separate ports) does it aslo mean that peer B must not use Bundle? Or
> > could peer A use two local ports (no Bundle) to send/receive tracks
> > to/from a single port in peer B?
> >
> > Thanks a lot.
> >
> > --
> > I=C3=B1aki Baz Castillo
> > 
>
>
> Hi I=C3=B1aki,
>
> not sure what the spec currently mandates, but this works already in
> existing implementations. Peer A just needs to do the ICE and DTLS
> dance twice from its two ports towards the single port in B (twice or
> more, in case you're not muxing RTCP either).
>
> Lorenzo
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--089e0115ef9c77906604eaed129f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


No, B cannot BUNDLE if A is not BUNDLEing. There are a num=
ber of corner cases where things don't work right in the situation desc=
ribed above.




On Mon, Nov 11, 2013 at 10:17 AM, Lorenzo Miniero <lorenzo@meetecho.com=
> wrote:


Il giorno Mon, 11 Nov 2013 19:12:01 +0100

I=C3=B1aki Baz Castillo <ibc@aliax.net<=
/a>> ha scritto:

Hi I=C3=B1aki,



not sure what the spec currently mandates, but this works already in

existing implementations. Peer A just needs to do the ICE and DTLS

dance twice from its two ports towards the single port in B (twice or

more, in case you're not muxing RTCP either).



Lorenzo

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--089e0115ef9c77906604eaed129f--

From christer.holmberg@ericsson.com  Mon Nov 11 16:54:58 2013
Return-Path: 
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 4580E11E80F6 for ; Mon, 11 Nov 2013 16:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.559
X-Spam-Level: 
X-Spam-Status: No, score=-5.559 tagged_above=-999 required=5 tests=[AWL=0.689,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 UXeyABoLjL8I for ; Mon, 11 Nov 2013 16:54:53 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 74E7721F9A6C for ; Mon, 11 Nov 2013 16:54:52 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-0c-52817c5a160a
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AF.FE.15980.A5C71825; Tue, 12 Nov 2013 01:54:50 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Tue, 12 Nov 2013 01:54:50 +0100
From: Christer Holmberg 
To: Justin Uberti , Lorenzo Miniero 
Thread-Topic: [rtcweb] No-Bundle in just one peer
Thread-Index: AQHO3wmRxZpCSOaXj0uwB1LR1jTfk5ogRaQAgAAuh4CAAFC/4A==
Date: Tue, 12 Nov 2013 00:54:49 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5167D2@ESESSMB209.ericsson.se>
References:  <20131111191712.59e4e44d@lminiero> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C5167D2ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+JvrW5UTWOQwbEXKhZbpwpZbN+ygMli 7b92dgdmjwWbSj2WLPnJ5NHx8D57AHMUl01Kak5mWWqRvl0CV8b2ybtZCnZEVczqWc7awPgn vIuRg0NCwETi5XTVLkZOIFNM4sK99WxdjFwcQgKHGCV+dr5khXCWMErsX3qNCaSBTcBCovuf NkiDiICfxN7Fc9hBbGYBdYk7i8+B2cICBhJvLh9hBykXETCUaL0SC1HuJLHu31NGEJtFQFVi wfd1LCA2r4CvxO9T05khVu1hlPjbf44VJMEpECjR3X+fGcRmBDru+6k1TBC7xCU+HLzODHG0 gMSSPeehbFGJl4//sULYShIrtl9ihKjPl/j45wsTxDJBiZMzn7BMYBSdhWTULCRls5CUzQJ6 gVlAU2L9Ln2IEkWJKd0P2SFsDYnWOXPZkcUXMLKvYmTPTczMSS8338QIjK+DW34b7GDcdF/s EKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjXrZzxyknwaeHP+0emrMsu lHV6LuEWM7X7QlaGe/bewkJrO+OKgwXb/vvvcBdI7NykeMz/4sOs7BLBu/3WX2YuShK8Upjt mWX5fp+71KQLzMd3LTQwvm+4QSj6yLmuvLa7hR32mo9+vv7k+f8Mu0LkqtApghZ7A+/9CHrn 5CI+cyXDCfP5woxKLMUZiYZazEXFiQA1l+spfQIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] No-Bundle in just one peer
X-BeenThere: rtcweb@ietf.org
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: Tue, 12 Nov 2013 00:54:58 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C5167D2ESESSMB209erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCkp1c3RpbiBpcyBjb3JyZWN0Lg0KDQpBdCBvbmUgcG9pbnQgd2UgbWFkZSBhIGRlY2lz
aW9uLCB0aGF0IGVpdGhlciBib3RoIGVuZHBvaW50cyBkbyBCVU5ETEUsIG9yIG5vIGVuZHBvaW50
IGRvZXMgQlVORExFLg0KDQpBLCBub3Qgc3VwcG9ydGluZyBCVU5ETEUsIG1heSBub3QgbGlrZSBy
ZWNlaXZpbmcgYW4gU0RQIEFuc3dlciBmcm9tIEIgd2l0aCBhIHNoYXJlZCBhZGRyZXNzIGFzc2ln
bmVkIHRvIG11bHRpcGxlIG0tIGxpbmVzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkzD
pGhldHTDpGrDpDogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNl
c0BpZXRmLm9yZ10gUHVvbGVzdGEgSnVzdGluIFViZXJ0aQ0KTMOkaGV0ZXR0eTogMTEuIG1hcnJh
c2t1dXRhIDIwMTMgMjM6MDQNClZhc3RhYW5vdHRhamE6IExvcmVuem8gTWluaWVybw0KS29waW86
IHJ0Y3dlYkBpZXRmLm9yZw0KQWloZTogUmU6IFtydGN3ZWJdIE5vLUJ1bmRsZSBpbiBqdXN0IG9u
ZSBwZWVyDQoNCk5vLCBCIGNhbm5vdCBCVU5ETEUgaWYgQSBpcyBub3QgQlVORExFaW5nLiBUaGVy
ZSBhcmUgYSBudW1iZXIgb2YgY29ybmVyIGNhc2VzIHdoZXJlIHRoaW5ncyBkb24ndCB3b3JrIHJp
Z2h0IGluIHRoZSBzaXR1YXRpb24gZGVzY3JpYmVkIGFib3ZlLg0KDQpPbiBNb24sIE5vdiAxMSwg
MjAxMyBhdCAxMDoxNyBBTSwgTG9yZW56byBNaW5pZXJvIDxsb3JlbnpvQG1lZXRlY2hvLmNvbTxt
YWlsdG86bG9yZW56b0BtZWV0ZWNoby5jb20+PiB3cm90ZToNCklsIGdpb3JubyBNb24sIDExIE5v
diAyMDEzIDE5OjEyOjAxICswMTAwDQpJw7Fha2kgQmF6IENhc3RpbGxvIDxpYmNAYWxpYXgubmV0
PG1haWx0bzppYmNAYWxpYXgubmV0Pj4gaGEgc2NyaXR0bzoNCg0KPiBIaSwNCj4NCj4gSW4gY2Fz
ZSBwZWVyIEEgc2VuZHMgYSBTUEQgd2l0aG91dCBCdW5kbGUgc3VwcG9ydCAoc28gaXQgbmVlZHMg
dG8NCj4gcmVjZWl2ZSBpbmNvbWluZyB0cmFja3MgaW4gc2VwYXJhdGUgcG9ydHMgYW5kIHNlbmQg
dHJhY2tzIGZyb20NCj4gc2VwYXJhdGUgcG9ydHMpIGRvZXMgaXQgYXNsbyBtZWFuIHRoYXQgcGVl
ciBCIG11c3Qgbm90IHVzZSBCdW5kbGU/IE9yDQo+IGNvdWxkIHBlZXIgQSB1c2UgdHdvIGxvY2Fs
IHBvcnRzIChubyBCdW5kbGUpIHRvIHNlbmQvcmVjZWl2ZSB0cmFja3MNCj4gdG8vZnJvbSBhIHNp
bmdsZSBwb3J0IGluIHBlZXIgQj8NCj4NCj4gVGhhbmtzIGEgbG90Lg0KPg0KPiAtLQ0KPiBJw7Fh
a2kgQmF6IENhc3RpbGxvDQo+IDxpYmNAYWxpYXgubmV0PG1haWx0bzppYmNAYWxpYXgubmV0Pj4N
Cg0KSGkgScOxYWtpLA0KDQpub3Qgc3VyZSB3aGF0IHRoZSBzcGVjIGN1cnJlbnRseSBtYW5kYXRl
cywgYnV0IHRoaXMgd29ya3MgYWxyZWFkeSBpbg0KZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLiBQ
ZWVyIEEganVzdCBuZWVkcyB0byBkbyB0aGUgSUNFIGFuZCBEVExTDQpkYW5jZSB0d2ljZSBmcm9t
IGl0cyB0d28gcG9ydHMgdG93YXJkcyB0aGUgc2luZ2xlIHBvcnQgaW4gQiAodHdpY2Ugb3INCm1v
cmUsIGluIGNhc2UgeW91J3JlIG5vdCBtdXhpbmcgUlRDUCBlaXRoZXIpLg0KDQpMb3JlbnpvDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1h
aWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo=

--_000_7594FB04B1934943A5C02806D1A2204B1C5167D2ESESSMB209erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5TaGtwb3N0aXR5eWxpMTcNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SnVzdGluIGlzIGNvcnJlY3QuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+QXQgb25lIHBvaW50IHdlIG1hZGUgYSBkZWNpc2lvbiwgdGhh
dCBlaXRoZXIgYm90aCBlbmRwb2ludHMgZG8gQlVORExFLCBvciBubyBlbmRwb2ludCBkb2VzIEJV
TkRMRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QSwgbm90IHN1cHBvcnRp
bmcgQlVORExFLCBtYXkgbm90IGxpa2UgcmVjZWl2aW5nIGFuIFNEUCBBbnN3ZXIgZnJvbSBCIHdp
dGggYSBzaGFyZWQgYWRkcmVzcyBhc3NpZ25lZCB0byBtdWx0aXBsZSBtLSBsaW5lcy48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkzDpGhldHTDpGrDpDo8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0
bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPlB1b2xlc3RhIDwvYj5KdXN0aW4gVWJlcnRp
PGJyPg0KPGI+TMOkaGV0ZXR0eTo8L2I+IDExLiBtYXJyYXNrdXV0YSAyMDEzIDIzOjA0PGJyPg0K
PGI+VmFzdGFhbm90dGFqYTo8L2I+IExvcmVuem8gTWluaWVybzxicj4NCjxiPktvcGlvOjwvYj4g
cnRjd2ViQGlldGYub3JnPGJyPg0KPGI+QWloZTo8L2I+IFJlOiBbcnRjd2ViXSBOby1CdW5kbGUg
aW4ganVzdCBvbmUgcGVlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5v
LCBCIGNhbm5vdCBCVU5ETEUgaWYgQSBpcyBub3QgQlVORExFaW5nLiBUaGVyZSBhcmUgYSBudW1i
ZXIgb2YgY29ybmVyIGNhc2VzIHdoZXJlIHRoaW5ncyBkb24ndCB3b3JrIHJpZ2h0IGluIHRoZSBz
aXR1YXRpb24gZGVzY3JpYmVkIGFib3ZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE5vdiAx
MSwgMjAxMyBhdCAxMDoxNyBBTSwgTG9yZW56byBNaW5pZXJvICZsdDs8YSBocmVmPSJtYWlsdG86
bG9yZW56b0BtZWV0ZWNoby5jb20iIHRhcmdldD0iX2JsYW5rIj5sb3JlbnpvQG1lZXRlY2hvLmNv
bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWwg
Z2lvcm5vIE1vbiwgMTEgTm92IDIwMTMgMTk6MTI6MDEgJiM0MzswMTAwPGJyPg0KScOxYWtpIEJh
eiBDYXN0aWxsbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiPmliY0BhbGlheC5u
ZXQ8L2E+Jmd0OyBoYSBzY3JpdHRvOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCiZndDsg
SGksPGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gY2FzZSBwZWVyIEEgc2VuZHMgYSBTUEQgd2l0aG91
dCBCdW5kbGUgc3VwcG9ydCAoc28gaXQgbmVlZHMgdG88YnI+DQomZ3Q7IHJlY2VpdmUgaW5jb21p
bmcgdHJhY2tzIGluIHNlcGFyYXRlIHBvcnRzIGFuZCBzZW5kIHRyYWNrcyBmcm9tPGJyPg0KJmd0
OyBzZXBhcmF0ZSBwb3J0cykgZG9lcyBpdCBhc2xvIG1lYW4gdGhhdCBwZWVyIEIgbXVzdCBub3Qg
dXNlIEJ1bmRsZT8gT3I8YnI+DQomZ3Q7IGNvdWxkIHBlZXIgQSB1c2UgdHdvIGxvY2FsIHBvcnRz
IChubyBCdW5kbGUpIHRvIHNlbmQvcmVjZWl2ZSB0cmFja3M8YnI+DQomZ3Q7IHRvL2Zyb20gYSBz
aW5nbGUgcG9ydCBpbiBwZWVyIEI/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzIGEgbG90Ljxi
cj4NCiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBJw7Fha2kgQmF6IENhc3RpbGxvPGJyPg0K
Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiPmliY0BhbGlheC5uZXQ8L2E+
Jmd0Ozxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkhpIEnDsWFraSw8YnI+DQo8YnI+DQpub3Qgc3VyZSB3aGF0IHRoZSBzcGVj
IGN1cnJlbnRseSBtYW5kYXRlcywgYnV0IHRoaXMgd29ya3MgYWxyZWFkeSBpbjxicj4NCmV4aXN0
aW5nIGltcGxlbWVudGF0aW9ucy4gUGVlciBBIGp1c3QgbmVlZHMgdG8gZG8gdGhlIElDRSBhbmQg
RFRMUzxicj4NCmRhbmNlIHR3aWNlIGZyb20gaXRzIHR3byBwb3J0cyB0b3dhcmRzIHRoZSBzaW5n
bGUgcG9ydCBpbiBCICh0d2ljZSBvcjxicj4NCm1vcmUsIGluIGNhc2UgeW91J3JlIG5vdCBtdXhp
bmcgUlRDUCBlaXRoZXIpLjxicj4NCjxicj4NCkxvcmVuem88YnI+DQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+
PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3
ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_7594FB04B1934943A5C02806D1A2204B1C5167D2ESESSMB209erics_--

From ibc@aliax.net  Mon Nov 11 16:59:10 2013
Return-Path: 
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 33B2C11E8145 for ; Mon, 11 Nov 2013 16:59:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 iBSxmWXnZWro for ; Mon, 11 Nov 2013 16:59:05 -0800 (PST)
Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id C118421E80C1 for ; Mon, 11 Nov 2013 16:59:05 -0800 (PST)
Received: by mail-qe0-f54.google.com with SMTP id 1so5194477qec.13 for ; Mon, 11 Nov 2013 16:59:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=eBRasLvvzCJrN5ivStqOtPMtvFsAARJVwHVm7s+LGMw=; b=Iu9R+TMlR55NNe13KmmDPSe/2/yY5wIZ+Y/Gep8yJciLUBpYgAWVTckd44OmwGIWhP E6tdPEPZiWFPKZnbFd/R6Fq03cXS8hfVctRRSHQzT/zwtdY46f6ftt3TKuYbSyXdsvDv 3EMWT0bN1n0tQOLqaMGH/aCDW1V/H0Smw9El1jn84/DucKmoSXrhLKjAfLLvwbLNSOxX Tj8hEbu5eSk+weYXAdssNgrBlKqw3/MD7gq9wezDZg5Qys/4T1nCXg2X4+mRbS5B2Fbi UDcmw0efKLUXo63dNgVL4LO1qNqNGvo9EnMhYZMuDTqqQ0NOmv0pN8fNmg/BngYE7fAL Gv6w==
X-Gm-Message-State: ALoCoQl/e/ysfYbu88a1OxAzddvCVweZfvcbuif2ktKnwedPZtiSm+ZxXm4IFTAmvNhzUMBtrLAO
X-Received: by 10.224.36.201 with SMTP id u9mr54084929qad.76.1384217945093; Mon, 11 Nov 2013 16:59:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.71.8 with HTTP; Mon, 11 Nov 2013 16:58:45 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5167D2@ESESSMB209.ericsson.se>
References:  <20131111191712.59e4e44d@lminiero>  <7594FB04B1934943A5C02806D1A2204B1C5167D2@ESESSMB209.ericsson.se>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 12 Nov 2013 01:58:45 +0100
Message-ID: 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] No-Bundle in just one peer
X-BeenThere: rtcweb@ietf.org
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: Tue, 12 Nov 2013 00:59:10 -0000

Clear. Thanks to all.

2013/11/12 Christer Holmberg :
> Hi,
>
>
>
> Justin is correct.
>
>
>
> At one point we made a decision, that either both endpoints do BUNDLE, or=
 no
> endpoint does BUNDLE.
>
>
>
> A, not supporting BUNDLE, may not like receiving an SDP Answer from B wit=
h a
> shared address assigned to multiple m- lines.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> L=C3=A4hett=C3=A4j=C3=A4: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@=
ietf.org] Puolesta
> Justin Uberti
> L=C3=A4hetetty: 11. marraskuuta 2013 23:04
> Vastaanottaja: Lorenzo Miniero
> Kopio: rtcweb@ietf.org
> Aihe: Re: [rtcweb] No-Bundle in just one peer
>
>
>
> No, B cannot BUNDLE if A is not BUNDLEing. There are a number of corner
> cases where things don't work right in the situation described above.
>
>
>
> On Mon, Nov 11, 2013 at 10:17 AM, Lorenzo Miniero 
> wrote:
>
> Il giorno Mon, 11 Nov 2013 19:12:01 +0100
> I=C3=B1aki Baz Castillo  ha scritto:
>
>
>> Hi,
>>
>> In case peer A sends a SPD without Bundle support (so it needs to
>> receive incoming tracks in separate ports and send tracks from
>> separate ports) does it aslo mean that peer B must not use Bundle? Or
>> could peer A use two local ports (no Bundle) to send/receive tracks
>> to/from a single port in peer B?
>>
>> Thanks a lot.
>>
>> --
>> I=C3=B1aki Baz Castillo
>> 
>
> Hi I=C3=B1aki,
>
> not sure what the spec currently mandates, but this works already in
> existing implementations. Peer A just needs to do the ICE and DTLS
> dance twice from its two ports towards the single port in B (twice or
> more, in case you're not muxing RTCP either).
>
> Lorenzo
> _______________________________________________
> 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
>



--=20
I=C3=B1aki Baz Castillo


From magnus.westerlund@ericsson.com  Tue Nov 12 05:44:52 2013
Return-Path: 
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 1229221E80D3 for ; Tue, 12 Nov 2013 05:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.552
X-Spam-Level: 
X-Spam-Status: No, score=-105.552 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 x-tehkLRRWAI for ; Tue, 12 Nov 2013 05:44:45 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4593111E8140 for ; Tue, 12 Nov 2013 05:44:45 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-a0-528230cbdd98
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3E.07.23787.BC032825; Tue, 12 Nov 2013 14:44:44 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Tue, 12 Nov 2013 14:44:43 +0100
Message-ID: <52823111.9010701@ericsson.com>
Date: Tue, 12 Nov 2013 14:45:53 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: , "rtcweb@ietf.org" 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+Jvre4Zg6Ygg2k7eSxWH97LZrH2Xzu7 A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWxdMUkpoInChW3Gt+xNjDulexi5OSQEDCR 6Lt9lBHCFpO4cG89WxcjF4eQwCFGidXzDzBDOMsZJabd3skEUsUroC2x/cx/VhCbRUBV4sj7 O+wgNpuAhcTNH41sILaoQLDE+VeL2SHqBSVOznzCAmKLCERLvF33EqxGWMBcYs6NDUBzOIA2 i0v0NAaBhJkF9CSmXG1hhLDlJZq3zmYGsYWA1jY0dbBOYOSfhWTqLCQts5C0LGBkXsXInpuY mZNebriJERhiB7f81t3BeOqcyCFGaQ4WJXHeD2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUwmp8R/X47dENS3WfZk7s3//Trd14Y8lw46ofYwreTPKrPsgjsmu/edudp36rdH+QPLCha PUe3ttZMLFFXyvGYgcf2t/ZvpuySk10qMzn9lirz7ptv1eTfsBzlF7NeYL/5k5act4hV9hTr hqj1/N3fzYQm7267xxgkkyg5oeebVMiC7aKRtppGSizFGYmGWsxFxYkAo8ZY4P8BAAA=
Subject: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-01
X-BeenThere: rtcweb@ietf.org
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: Tue, 12 Nov 2013 13:44:52 -0000

Hi,

I did review the Data Channel Protocol on my way to IETF, and here are
my comments.

1. Section 4:

   o  the outgoing SCTP stream.

What about incoming SCTP stream?

2. Section 4:
   The data channel protocol uses a two way handshake to open a data
   channel.  The side wanting to open a data channel selects an unused
   Stream and sends a DATA_CHANNEL_OPEN message.  The peer responds with
   a DATA_CHANNEL_ACK message.  Then the data channel is open.  Please
   note that the opening side can send user messages before the
   DATA_CHANNEL_ACK is received.  These data channel messages are sent
   on the same Stream as the user messages belonging to the data
   channel.  The demultiplexing is based on the SCTP payload protocol
   identifier.

I find this paragraph a bit confusing on the following things:

A. Is the DATA_CHANNEL_OPEN message sent on that selected stream?
B. Is the DATA_CHANNEL_ACK sent on the peers corresponding stream number
as the DATA_CHANNEL_OPEN was received on?
C. "These data channel messages" does this refer to
DATA_CHANNEL_OPEN/ACK, maybe be more explicit.
D. "The demultiplexing is based on the SCTP payload protocol
   identifier." Do you mean PPIDs here. And could you be more explicit
about of how this works. Am I wrong in the understanding that you have
have one PPID for this control protocol. But, you are not explicit about
if which PPID user messages could use.

3. Section 4:
   The protocol field is to ease cross-application interoperation
   ("federation") by identifying the data being passed with an IANA-
   registered string, and may be useful for homogenous applications
   which may create more than one type of Channel.

One more case where I think it is fuzzy what is refered to. Is the
"protocol field" an identifier for the PPID to use, or something else?
What type of IANA registered string is being used here? Which registry
and field value are referenced?

4. Section 5.1:
   Priority: 2 bytes (integer)
      The priority of the channel.

What is the definition of the priority field value?

5. Section 5.1:
   Reliability Parameter: 4 bytes

I would recommend that you make a table under this parameter where you
make clear the interpretation of the field under differetn channel types.

6. Section 5.1

   Protocol: Variable Length (sequence of characters)
      The protocol for the channel.  This may be an empty string.  If
      used, it is an IANA-registered protocol (see Section 8.4).

Can you please be explicit about which IANA registry that is relevant
here. What is the meaning of an empty string?

7. Section 6.
What PPID shall be used when sending the user data?

8. Section 6.
Therefore, receiving an
   SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK
   message has been received indicates to the sender of the
   corresponding DATA_CHANNEL_OPEN message the failure of the data
   channel setup procedure.

What is allowed to do after having received the reset on a
DATA_CHANNEL_OPEN? Can one try to send a new OPEN?

9. Section 8.2:
               | Reserved          | 0x00      | [RFCXXXX] |
               | Reserved          | 0x01      | [RFCXXXX] |

Why is these values reserved, please include the motivation for this in
the description of the registry.

10. Section 8.4:
   IANA is requested to create a new registration table "Protocol
   Registry" for the data channel protocol to manage the "Protocol"
   field of type string in DATA_CHANNEL_OPEN messages (see Section 5.1).

"Protocol Registry" is a lousy name on a registry. Secondly, I think the
purpose of this registry needs to be better described.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Tue Nov 12 06:19:25 2013
Return-Path: 
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 D98E211E813D for ; Tue, 12 Nov 2013 06:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.74
X-Spam-Level: 
X-Spam-Status: No, score=-103.74 tagged_above=-999 required=5 tests=[AWL=-1.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 PQLKo2m510CU for ; Tue, 12 Nov 2013 06:19:14 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7414511E815F for ; Tue, 12 Nov 2013 06:19:05 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-1a-528238d87c12
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id FC.DD.27941.8D832825; Tue, 12 Nov 2013 15:19:04 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Tue, 12 Nov 2013 15:19:04 +0100
Message-ID: <5282391D.3050002@ericsson.com>
Date: Tue, 12 Nov 2013 15:20:13 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Harald Tveit Alvestrand , "rtcweb@ietf.org" 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+Jvre4Ni6Ygg2+7xSyO9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGWs2XmDreC7YsW/S7YNjJ+kuhg5OSQETCSa m44zQ9hiEhfurWfrYuTiEBI4wiix5WEbM4SznFFibs8CNpAqXgFtiUe7fzOC2CwCqhKNvVPY QWw2AQuJmz8awWpEBYIlzr9azA5RLyhxcuYTFhBbRCBSYunnrWC9wkCbe+6tZO1i5ADaLC7R 0xgEEmYW0JOYcrWFEcKWl2jeOhvsOCGgtQ1NHawTGPlnIZk6C0nLLCQtCxiZVzFyFKcWJ+Wm GxlsYgSG2MEtvy12MF7+a3OIUZqDRUmc9+Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jPwblinNX15b9CYqITur0ksxpbCBU78qNLj9WQ+/R+SSnivNFYbX+TJr9FQu63SZz7FKSNxk GaDS4OTMol/VV29bVufQzHd1kX9DaqV9kFaAQiBbruWdi3FR397PV9mYHndhuVOV9CFBuaOl XL05gtsaDm7Yun8X4zeG7LxFd6PEJyfL8CuxFGckGmoxFxUnAgDqmIi+/wEAAA==
Subject: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
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: Tue, 12 Nov 2013 14:19:26 -0000

Hi,

Here are my review comments on draft-ietf-rtcweb-transports-01:

1. Front page: I would strongly suggest moving requirements language
into some numbered section.

2. Section 2.1:

   o  TCP.  This is used for HTTP/WebSockets, as well as for TURN/SSL
      and ICE-TCP.

Are there really any need for ICE-TCP? Can't this simply be removed?

3. Section 2.1:
   For both protocols, this specification assumes the ability to set the
   DSCP code point of the sockets opened on a per-packet basis, in order
   to achieve the prioritizations described in [I-D.ietf-rtcweb-qos].

First, I don't think one can assume the ability to set DSCP code points.
I think one should express that it is desirable to do it.

Secondly, I think one has to be aware that setting DSCP on a per packet
basis may be less commonly working than even just marking a flow
consistently.

Thirdly, the I-D.ietf-rtcweb-qos is dead, and if anything it should be
replaced by draft-dhesikan-tsvwg-rtcweb-qos-02.

4. Section 2.1:
   If DSCP code points can only be set on a per-socket basis, not per-
   packet, one loses the ability to have the network discriminate
   reliably between classes of traffic sent over the same transport, but
   this does not prevent communication.

As this means all packets in the flow gets same treatment, one can point
out that using multiple RTP sessions and transport flows allow one to
have multiple different priority levels.

5. Section 2.1:
   This specification does not assume that the implementation will have
   access to ICMP or raw IP.

I think it should point out the advantage of being capable of receiving
ICMP in MTU discovery.

In addition I think you can bring up the benefits from being capable of
setting DF bit.

6. Section 2.2:
   ICE TCP candidates [RFC6062] MAY be supported; this may allow
   applications to achieve peer-to-peer communication across UDP-
   blocking firewalls, but this also requires use of the SRTP/AVPF/TCP
   profile of RTP.

I would question if this at all should be discussed. First of all a
TURN/TCP or TURN/TLS/TCP relay fulfills the needs to cross a only TCP
allowing firewall. Secondly, if one likes to use TCP/TLS/RTP/SAVPF then
one would need to use RFC 4571 framing, or do you have another proposal?
I would also note that such a combination do require us to do a bit of
specification work to bring RFC 4571 up to date to allow us use both
profiles beyond AVP as well as indicating usage of DTLS-SRTP over that
TCP framing. Considering that this appears to be a redundant and less
likely to work mechanism I would propose to remove it from consideration
even for MAY.

7. Section 2.2.:

   o  TURN, including TURN over TCP[RFC5766].

Missing space between TCP and reference.

8. Section 2.2:

   TURN over TLS over TCP MAY be supported.  (QUESTION: SHOULD?  MUST?)

I think MAY is a fine level for this. But it clearly should be an issue
raised to the WG for further debate.

9. Section 2.3:
   The setup protocol for RTCWEB data channels is described in
   [I-D.jesup-rtcweb-data-protocol].

That draft is now a WG draft.

10. Section 2.3:
   RTCWEB implementations MUST support multiplexing of DTLS and RTP over
   the same port pair, as described in the DTLS_SRTP specification
   [RFC5764], section 5.1.2.  Further separation of the DTLS traffic
   into SCTP and "other" is described in .

A. I would note that one actually must be capable of multiplexing DTLS,
RTP and STUN messages on the same port pair.

B. What about that needed reference. I think it is
draft-ietf-rtcweb-data-channel that should have this text.

11. Section 4:

I think this document do need to discuss DSCP and ICMP and the issues
they can cause. Or possibly provide input to the security consideration
document.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Tue Nov 12 06:57:47 2013
Return-Path: 
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 B1B6E11E8169 for ; Tue, 12 Nov 2013 06:57:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.718
X-Spam-Level: 
X-Spam-Status: No, score=-103.718 tagged_above=-999 required=5 tests=[AWL=-1.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 v09jYz5zpgCx for ; Tue, 12 Nov 2013 06:57:39 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A80D511E8143 for ; Tue, 12 Nov 2013 06:57:38 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-b0-528241dce60d
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 41.92.27941.CD142825; Tue, 12 Nov 2013 15:57:33 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Tue, 12 Nov 2013 15:57:32 +0100
Message-ID: <52824222.2000907@ericsson.com>
Date: Tue, 12 Nov 2013 15:58:42 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: , "rtcweb@ietf.org" 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFJMWRmVeSWpSXmKPExsUyM+Jvre5dx6Ygg/kv2CxWPHnEYrH2Xzu7 A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJVxdEZ+Qb9yxf3L7UwNjOekuxg5OSQETCRa //1ghrDFJC7cW8/WxcjFISRwhFHi4KF1LBDOckaJ2zdOADkcHLwC2hJzfkmDmCwCqhKT38SB 9LIJWEjc/NHIBmKLCgRLnH+1mB3E5hUQlDg58wkLiC0ikCJx4tE8sF3CAg4Shw5PYAIZIyEg LtHTGAQSZhbQk5hytYURwpaXaN46G6xcCGhpQ1MH6wRG/llIps5C0jILScsCRuZVjBzFqcVJ uelGBpsYgeF1cMtvix2Ml//aHGKU5mBREuf9+NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAOjjhIXb0mH1tKbTgc7xFQWHzm4aWr23gMSj5o538eErXh/ve2ouq6Y20fVrcKn+1tYbZ4I nXCpNNpoycT+7+R957qDsoz3LSsypRR+zbi30tGZN0SwYmrgp/uert5/F3BUXRC8/brcTj2u b0L7E6XqgpqD7Y99CzTmNBysuu2RuqzX4+uzJaVKLMUZiYZazEXFiQAqGmSR/QEAAA==
Subject: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00
X-BeenThere: rtcweb@ietf.org
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: Tue, 12 Nov 2013 14:57:47 -0000

Hi,

Here are my review comments on draft-ietf-rtcweb-stun-consent-freshness-00

1. General:
I understood one reason for splitting this out in its own document is
that we might have other future users of this mechanism. Thus I think it
should be written to be less WebRTC specific. It is appropriate to use
WebRTC as motivation for requirements etc, but the actual description of
the mechanism should be done in a neutral way.

2. Section 1.
   When a session is first established, WebRTC implementations are
   required to perform STUN connectivity checks as part of ICE
   [RFC5245].  That initial consent is not described further in this
   document.

When generalizing this, I think it is important to make clear that it is
assumed that ICE is being used for that initial consent.

3. Section 1:
"This document describes a new STUN usage with a request and response
   which verifies the remote peer consents to receive traffic, and
   detects loss of liveness."

I am missing a word after "request and response", transaction or
messages maybe?

4. Section 3:
 A
   response is necessary both for consent to continue sending traffic,
   as well as to ensure connectivity.

Is verify rather than "ensure" better?

5. Section 4:
   Consent freshness serves as a circuit breaker (so that if the path or
   remote peer fails the WebRTC browser stops sending all traffic on
   that remote peer), determining session liveness serves the purpose of
   notifying the application of connectivity failure so that the
   application can take appropriate action.

traffic on/traffic to

What is the definition of a peer here? What scope does the stop sending
have?

6. Section 4:
   1.  A consent timer, Tc, whose value is determined by the browser.
       This value MUST be 15 seconds.

I see a contradiction here, should it be determined by the browser or be
15 s? If it is 15, can you please motivate why it is this value, or
point to where it is motivated?

7. Section 4:
   If a valid STUN Binding Response is received, the consent timer is
   reset and fires again Tc seconds later.

Is it reset to the time of receiving it or the time of sending the
initial request this is the response for?

8. Section 4:
   If a valid STUN Binding Response is not received after 500ms, the
   STUN Binding Request is retransmitted (with the same Transaction ID
   and all other fields).  As long as a valid STUN Binding Response is
   not received, this retransmission is repeated every 500ms until Tf
   seconds have elapsed or a valid response is received.

So no exponential back-off on the retransmission timer. I think that is
fine. However, I think it do require you to expand a bit on what happens
when one gets multiple response on the same Transaction ID. For example
additional responses do they or do they not reset the Tc timer?

Then I wonder about the cases where the RTT is above 500 ms, should one
then scale this factor to be once per RTT?

9. Section 4:
"with the same Transaction ID"

Why not use a new transaction ID for each sent packet? It would allow
tracking loss and determine RTT more reliable. All for the small cost of
keeping track of slightly more Transaction IDs?

10. Section 4.
   Liveness timer: If no packets have been received on the local port in
   Tr seconds, the WebRTC browser MUST inform the JavaScript that
   connectivity has been lost.  The JavaScript application will use this
   notification however it desires (e.g., cease transmitting to the
   remote peer, provide a notification to the user, etc.).  Note the
   definition of a received packet is liberal, and includes an SRTP
   packet that fails authentication, a STUN Binding Request with an
   invalid USERNAME or PASSWORD, or any other packet.

I think this requires some considerations in regards to RTT. If the RTT
is 700 ms, high for a real-time app but not unheard of at all. Then a Tr
= 1 second would fire on a single loss.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From rjsparks@nostrum.com  Tue Nov 12 09:55:06 2013
Return-Path: 
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 A69D311E811B for ; Tue, 12 Nov 2013 09:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.507
X-Spam-Level: 
X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 MpCzcwYEvdnZ for ; Tue, 12 Nov 2013 09:55:05 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC6211E810D for ; Tue, 12 Nov 2013 09:55:05 -0800 (PST)
Received: from unnumerable.local (pool-173-57-89-224.dllstx.fios.verizon.net [173.57.89.224]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rACHt361005292 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Tue, 12 Nov 2013 11:55:04 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <52826B77.2010008@nostrum.com>
Date: Tue, 12 Nov 2013 11:55:03 -0600
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: <52602DAE.2010605@nostrum.com>
In-Reply-To: <52602DAE.2010605@nostrum.com>
Content-Type: multipart/alternative; boundary="------------060605040001050100040601"
Received-SPF: pass (shaman.nostrum.com: 173.57.89.224 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] Registration for the second SIP Forum RTCWeb interop test event is open
X-BeenThere: rtcweb@ietf.org
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: Tue, 12 Nov 2013 17:55:06 -0000

This is a multi-part message in MIME format.
--------------060605040001050100040601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The Second RTCWeb-it is next Monday.

If you're planning to attend, but haven't already registered, please do 
so as soon as you can!

RjS

On 10/17/13 1:34 PM, Robert Sparks wrote:
> The Second SIP Forum RTCWeb-it will be hosted by TMC on November 18, 
> 2013.
> The event will be held the Monday before the WebRTC Conference and 
> Expo, in Santa Clara, CA.
> Registration for the Second SIP Forum RTCWeb-it event is open.
> Details about the event can be found at 
> http://www.sipforum.org/content/view/416/294/.
> Please register as soon as possible at http://www.regonline.com/rtcwebit2
>
> RjS
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------060605040001050100040601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
The Second RTCWeb-it is next Monday.

      

      If you're planning to attend, but haven't already registered,
      please do so as soon as you can!

      

      RjS

      

      On 10/17/13 1:34 PM, Robert Sparks wrote:

    

    

      
      
      The Second SIP Forum RTCWeb-it will be hosted by TMC on November
      18, 2013. 

      The event will be held the Monday before the WebRTC Conference and
      Expo, in Santa Clara, CA. 

      Registration for the Second SIP Forum RTCWeb-it event is open. 

      Details about the event can be found at http://www.sipforum.org/content/view/416/294/.
      

      Please register as soon as possible at http://www.regonline.com/rtcwebit2

      

      RjS

      

      

      

      
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


    

    

  


--------------060605040001050100040601--

From parthasarathi.ravindran@nsn.com  Tue Nov 12 10:33:52 2013
Return-Path: 
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 91A2011E8121 for ; Tue, 12 Nov 2013 10:33:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 cN9jGkCeqIF0 for ; Tue, 12 Nov 2013 10:33:48 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 732AF11E8122 for ; Tue, 12 Nov 2013 10:33:34 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rACIXW9s007172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Nov 2013 19:33:32 +0100
Received: from SGSIHTC001.nsn-intra.net ([10.159.225.18]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rACIXUUE021824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 19:33:31 +0100
Received: from SGSIMBX006.nsn-intra.net ([169.254.6.69]) by SGSIHTC001.nsn-intra.net ([10.159.225.18]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 02:33:29 +0800
From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" 
To: ext Magnus Westerlund , "Harald Tveit Alvestrand" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
Thread-Index: AQHO37I3PiD2CpYvFEa5TFD9+s8TOpoh62lQ
Date: Tue, 12 Nov 2013 18:33:29 +0000
Message-ID: <40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net>
References: <5282391D.3050002@ericsson.com>
In-Reply-To: <5282391D.3050002@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.225.119]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 5039
X-purgate-ID: 151667::1384281212-00004A43-EC1DA466/0-0/0-0
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
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: Tue, 12 Nov 2013 18:33:52 -0000

Hi Magnus,

ICE-TCP shall be used by WebRTC gateways and conference scenario. The relat=
ed usecases are discussed in http://www.ietf.org/mail-archive/web/pntaw/cur=
rent/msg00181.html (PNTAW mailing alias). So, it should not be simply be re=
moved.

Thanks
Partha

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 ext Magnus Westerlund
Sent: Tuesday, November 12, 2013 7:50 PM
To: Harald Tveit Alvestrand; rtcweb@ietf.org
Subject: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

Hi,

Here are my review comments on draft-ietf-rtcweb-transports-01:

1. Front page: I would strongly suggest moving requirements language
into some numbered section.

2. Section 2.1:

   o  TCP.  This is used for HTTP/WebSockets, as well as for TURN/SSL
      and ICE-TCP.

Are there really any need for ICE-TCP? Can't this simply be removed?

3. Section 2.1:
   For both protocols, this specification assumes the ability to set the
   DSCP code point of the sockets opened on a per-packet basis, in order
   to achieve the prioritizations described in [I-D.ietf-rtcweb-qos].

First, I don't think one can assume the ability to set DSCP code points.
I think one should express that it is desirable to do it.

Secondly, I think one has to be aware that setting DSCP on a per packet
basis may be less commonly working than even just marking a flow
consistently.

Thirdly, the I-D.ietf-rtcweb-qos is dead, and if anything it should be
replaced by draft-dhesikan-tsvwg-rtcweb-qos-02.

4. Section 2.1:
   If DSCP code points can only be set on a per-socket basis, not per-
   packet, one loses the ability to have the network discriminate
   reliably between classes of traffic sent over the same transport, but
   this does not prevent communication.

As this means all packets in the flow gets same treatment, one can point
out that using multiple RTP sessions and transport flows allow one to
have multiple different priority levels.

5. Section 2.1:
   This specification does not assume that the implementation will have
   access to ICMP or raw IP.

I think it should point out the advantage of being capable of receiving
ICMP in MTU discovery.

In addition I think you can bring up the benefits from being capable of
setting DF bit.

6. Section 2.2:
   ICE TCP candidates [RFC6062] MAY be supported; this may allow
   applications to achieve peer-to-peer communication across UDP-
   blocking firewalls, but this also requires use of the SRTP/AVPF/TCP
   profile of RTP.

I would question if this at all should be discussed. First of all a
TURN/TCP or TURN/TLS/TCP relay fulfills the needs to cross a only TCP
allowing firewall. Secondly, if one likes to use TCP/TLS/RTP/SAVPF then
one would need to use RFC 4571 framing, or do you have another proposal?
I would also note that such a combination do require us to do a bit of
specification work to bring RFC 4571 up to date to allow us use both
profiles beyond AVP as well as indicating usage of DTLS-SRTP over that
TCP framing. Considering that this appears to be a redundant and less
likely to work mechanism I would propose to remove it from consideration
even for MAY.

7. Section 2.2.:

   o  TURN, including TURN over TCP[RFC5766].

Missing space between TCP and reference.

8. Section 2.2:

   TURN over TLS over TCP MAY be supported.  (QUESTION: SHOULD?  MUST?)

I think MAY is a fine level for this. But it clearly should be an issue
raised to the WG for further debate.

9. Section 2.3:
   The setup protocol for RTCWEB data channels is described in
   [I-D.jesup-rtcweb-data-protocol].

That draft is now a WG draft.

10. Section 2.3:
   RTCWEB implementations MUST support multiplexing of DTLS and RTP over
   the same port pair, as described in the DTLS_SRTP specification
   [RFC5764], section 5.1.2.  Further separation of the DTLS traffic
   into SCTP and "other" is described in .

A. I would note that one actually must be capable of multiplexing DTLS,
RTP and STUN messages on the same port pair.

B. What about that needed reference. I think it is
draft-ietf-rtcweb-data-channel that should have this text.

11. Section 4:

I think this document do need to discuss DSCP and ICMP and the issues
they can cause. Or possibly provide input to the security consideration
document.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
F=E4r=F6gatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

From harald@alvestrand.no  Tue Nov 12 11:11:07 2013
Return-Path: 
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 8FA2C21E8091 for ; Tue, 12 Nov 2013 11:11:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 rwnYZZ7gMYcr for ; Tue, 12 Nov 2013 11:11:01 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE3F21E8064 for ; Tue, 12 Nov 2013 11:11:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 28A1939E095; Tue, 12 Nov 2013 20:11:01 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0Ryn5feoX1X; Tue, 12 Nov 2013 20:10:59 +0100 (CET)
Received: from [192.168.10.39] (ip-64-134-136-58.public.wayport.net [64.134.136.58]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 468D939E05D; Tue, 12 Nov 2013 20:10:57 +0100 (CET)
Message-ID: <52827D3B.9000204@alvestrand.no>
Date: Tue, 12 Nov 2013 20:10:51 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Magnus Westerlund ,  "rtcweb@ietf.org" 
References: <5282391D.3050002@ericsson.com>
In-Reply-To: <5282391D.3050002@ericsson.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
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: Tue, 12 Nov 2013 19:11:07 -0000

On 11/12/2013 03:20 PM, Magnus Westerlund wrote:
> Hi,
>
> Here are my review comments on draft-ietf-rtcweb-transports-01:
>
> 1. Front page: I would strongly suggest moving requirements language
> into some numbered section.
>
> 2. Section 2.1:
>
>    o  TCP.  This is used for HTTP/WebSockets, as well as for TURN/SSL
>       and ICE-TCP.
>
> Are there really any need for ICE-TCP? Can't this simply be removed?

This question belongs in 2.2 - it's a MAY requirement there (but there
have been arguments in pntaw that it should be a SHOULD).
In both cases,
>
> 3. Section 2.1:
>    For both protocols, this specification assumes the ability to set the
>    DSCP code point of the sockets opened on a per-packet basis, in order
>    to achieve the prioritizations described in [I-D.ietf-rtcweb-qos].
>
> First, I don't think one can assume the ability to set DSCP code points.
> I think one should express that it is desirable to do it.
>
> Secondly, I think one has to be aware that setting DSCP on a per packet
> basis may be less commonly working than even just marking a flow
> consistently.

References? Is this an assumption, or based on actual
experiments/experiences?

>
> Thirdly, the I-D.ietf-rtcweb-qos is dead, and if anything it should be
> replaced by draft-dhesikan-tsvwg-rtcweb-qos-02.

I will take instructions from the chairs on this point; I think we need
to specify what -qos- used to say, and resurrecting that draft may be
easier/better than adopting a new one.

So far, I have not seen anything from the chairs (before now) that
announces that it's dead.

>
> 4. Section 2.1:
>    If DSCP code points can only be set on a per-socket basis, not per-
>    packet, one loses the ability to have the network discriminate
>    reliably between classes of traffic sent over the same transport, but
>    this does not prevent communication.
>
> As this means all packets in the flow gets same treatment, one can point
> out that using multiple RTP sessions and transport flows allow one to
> have multiple different priority levels.

That's an implication of what this says. The ability to differentiate
between different flows is common enough that it is assumed.

>
> 5. Section 2.1:
>    This specification does not assume that the implementation will have
>    access to ICMP or raw IP.
>
> I think it should point out the advantage of being capable of receiving
> ICMP in MTU discovery.

I think this is not realistic for the browser use case, where the stack
is implemented as an unprivilleged application. I think the requirements
need to be achievable in that situation, which is the point of this
explicit non-assumption.

That means that path MTU discovery for UDP will have to depend on
observing the packet loss patterns, if done at all. I think that's
realistic.

>
> In addition I think you can bring up the benefits from being capable of
> setting DF bit.

Is there a benefit, given the point above?
Is there a common userspace way to achieve this?

>
> 6. Section 2.2:
>    ICE TCP candidates [RFC6062] MAY be supported; this may allow
>    applications to achieve peer-to-peer communication across UDP-
>    blocking firewalls, but this also requires use of the SRTP/AVPF/TCP
>    profile of RTP.
>
> I would question if this at all should be discussed. First of all a
> TURN/TCP or TURN/TLS/TCP relay fulfills the needs to cross a only TCP
> allowing firewall.
The PNTAW discussion seems to indicate that there are scenarios where
this is realistic.
> Secondly, if one likes to use TCP/TLS/RTP/SAVPF then
> one would need to use RFC 4571 framing, or do you have another proposal?

I think the spec has to point to something that defines the framing,
otherwise this won't achieve interoperability. Is RFC 4571 the right
reference?

> I would also note that such a combination do require us to do a bit of
> specification work to bring RFC 4571 up to date to allow us use both
> profiles beyond AVP as well as indicating usage of DTLS-SRTP over that
> TCP framing. Considering that this appears to be a redundant and less
> likely to work mechanism I would propose to remove it from consideration
> even for MAY.

Redundant with what other mechanism?

>
> 7. Section 2.2.:
>
>    o  TURN, including TURN over TCP[RFC5766].
>
> Missing space between TCP and reference.
>
> 8. Section 2.2:
>
>    TURN over TLS over TCP MAY be supported.  (QUESTION: SHOULD?  MUST?)
>
> I think MAY is a fine level for this. But it clearly should be an issue
> raised to the WG for further debate.

This is being debated on PNTAW.

>
> 9. Section 2.3:
>    The setup protocol for RTCWEB data channels is described in
>    [I-D.jesup-rtcweb-data-protocol].
>
> That draft is now a WG draft.
>
> 10. Section 2.3:
>    RTCWEB implementations MUST support multiplexing of DTLS and RTP over
>    the same port pair, as described in the DTLS_SRTP specification
>    [RFC5764], section 5.1.2.  Further separation of the DTLS traffic
>    into SCTP and "other" is described in .
>
> A. I would note that one actually must be capable of multiplexing DTLS,
> RTP and STUN messages on the same port pair.

That is described in RFC 5764 section 5.1.2. Since ICE is completely
useless if it can't be multiplexed over the same port pair as the stuff
it's probing for, I regard the ability to demultiplex STUN packets as
implicit in the statement "we're using ICE".

>
> B. What about that needed reference. I think it is
> draft-ietf-rtcweb-data-channel that should have this text.

I'll check if it does.
>
> 11. Section 4:
>
> I think this document do need to discuss DSCP and ICMP and the issues
> they can cause. Or possibly provide input to the security consideration
> document.

Please send text or pointers.

>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>


-- 
Surveillance is pervasive. Go Dark.


From ml@gondwanaland.com  Tue Nov 12 13:53:23 2013
Return-Path: 
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 D0D0321F9D28 for ; Tue, 12 Nov 2013 13:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 BaeiBx1lMTdL for ; Tue, 12 Nov 2013 13:53:19 -0800 (PST)
Received: from naoi.pair.com (naoi.pair.com [209.68.5.145]) by ietfa.amsl.com (Postfix) with ESMTP id EC8E011E80FE for ; Tue, 12 Nov 2013 13:53:18 -0800 (PST)
Received: from [192.168.1.109] (adsl-76-252-223-163.dsl.pltn13.sbcglobal.net [76.252.223.163]) by naoi.pair.com (Postfix) with ESMTPSA id DCD9F95861 for ; Tue, 12 Nov 2013 16:53:11 -0500 (EST)
Message-ID: <5282A340.7010405@gondwanaland.com>
Date: Tue, 12 Nov 2013 13:53:04 -0800
From: Mike Linksvayer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Thunderbird/25.0
MIME-Version: 1.0
To: rtcweb@ietf.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Tue, 12 Nov 2013 21:53:23 -0000

Hi all,

I was one of the remote attendees last Thursday. Long-time
read-list-via-archives lurker. Interest/excitement because seems
to me WebRTC is the most significant addition to the web in terms
of supporting new types of applications since Ajax, at least. And
specifically the video codec MTI debate, as FLOSS being second class is
a huge burden to projects I'm involved in, as well as being terrible
social policy.

I figured I was contributing by not repeating things that have already
been said many times. :) But it was apparent from the meeting that
posting to the list is valued...

I strongly support VP8 for MTI, and oppose H.264. Undecided on which
of both, either, or neither would be second best. My reason is simply
that FLOSS (and any entity for which users downloading a binary from
Cisco next year is unworkable) is second class at best in the H.264
case, while VP8 is demonstrably acceptable.

I think I appreciate the arguments for H.264, which all (including
those about legal risk) boil down to H.264 having a longer history
and greater adoption in other applications. Those don't flip me,
because, again, FLOSS is my baseline requirement. I realize that some
large companies have different baselines. Frankly, I don't care if the
legal risk to large companies is slightly different for either codec:
if trolls come out after mass implementation of WebRTC, the relevant
companies have resources to fight them, and more incentive to fix the
troll situation and/or end software patents in the interim, the better.

Speaking of now, the interim, and longer term, I was struck by two
brief statements in the meeting.

Jonathan Rosenberg, about 22 minutes into
http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF88_RTCWEB_II&chapter=part_4
> I would love it if all patents evaporated, if all the stuff was
> open  source in ways that we could  use, and we didn’t have to
> deal with any of this mess.

(In the middle of explaining why he thinks H.264 is the best choice
now, given this patent mess.)

Harald Alvestrand, about 48 minutes into
http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF88_RTCWEB_II&chapter=part_9
> Development of codecs has been massively hampered and held back by
> the  fact that it has been done in a fashion that has served to
> maximize the  patent encumbrances on codecs. Sooner or later, we
> should see a way  forward to abandon the dependence on encumbered
> codecs also for video  software. My question, at this juncture,
> is if not now, when?

I didn't hear an answer, but would love to hear one. It is conceivable
I could be convinced of a compromise now, if it were obvious those
individuals and businesses pushing for H.264 were also unambiguously
helping fix the problem in the medium and longer term by helping
next- VP9 and and next-next-generation Daala, and lobbying for the
elimination of software patents.

Mike

From basilgohar@librevideo.org  Tue Nov 12 14:14:33 2013
Return-Path: 
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 B7AC821F9FD5 for ; Tue, 12 Nov 2013 14:14:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 9vC-8qaaSR05 for ; Tue, 12 Nov 2013 14:14:28 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9715721F9FBC for ; Tue, 12 Nov 2013 14:14:28 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id C31D797E0CE for ; Tue, 12 Nov 2013 17:14:27 -0500 (EST)
Message-ID: <5282A840.3030908@librevideo.org>
Date: Tue, 12 Nov 2013 17:14:24 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com>
In-Reply-To: <5282A340.7010405@gondwanaland.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Tue, 12 Nov 2013 22:14:33 -0000

On 11/12/2013 04:53 PM, Mike Linksvayer wrote:
> Hi all,
> 

> 
> I strongly support VP8 for MTI, and oppose H.264. Undecided on which
> of both, either, or neither would be second best. My reason is simply
> that FLOSS (and any entity for which users downloading a binary from
> Cisco next year is unworkable) is second class at best in the H.264
> case, while VP8 is demonstrably acceptable.
> 
> I think I appreciate the arguments for H.264, which all (including
> those about legal risk) boil down to H.264 having a longer history
> and greater adoption in other applications. Those don't flip me,
> because, again, FLOSS is my baseline requirement. I realize that some
> large companies have different baselines. Frankly, I don't care if the
> legal risk to large companies is slightly different for either codec:
> if trolls come out after mass implementation of WebRTC, the relevant
> companies have resources to fight them, and more incentive to fix the
> troll situation and/or end software patents in the interim, the better.

> 
> Mike

For brevity, I snipped the pieces that I thought didn't need repeating
above.  I, for one, simply wanted to say I was thinking of writing
something similar, for basically the same reasons.

By not standing for freedom and openness now, if I may use those terms,
we are becoming complicit in prolonging the stranglehold that the
current patent quagmire that exists today.  By giving in, we are
basically admitting a win.  When even the proponents of the
patent-encumbered format bemoan the problems of the system, we have to
wonder, if their cries are sincere, why they won't also join the FLOSS
folks.

The thing is, there is absolutely nothing that can be done if H.264 is
the standard that cannot be done with VP8, but such a thing is not true
the other way around due to the obvious requirements of licensing needed
for H.264.

And, in fact, there already exists a strong installed based supporting
VP8, so it's not like choosing VP8 will kill the standard.

We cannot change the patent landscape of H.264 as long MPEG-LA and it's
partners operate the way they always have.  However, I would like to
know what, if anything, is stopping the providers that want to use H.264
from choosing VP8, and if we can work toward a solution that way.

The problem is, this involves sincerity from those participating, and we
have no way of guaranteeing that.

I apologize I don't have a solution here, but I know one exists.  We
just haven't found one yet.

-- 
Libre Video
http://librevideo.org

From singer@apple.com  Tue Nov 12 19:59:28 2013
Return-Path: 
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 9FE2321F9FB4 for ; Tue, 12 Nov 2013 19:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 K6-veeXN+ixc for ; Tue, 12 Nov 2013 19:59:23 -0800 (PST)
Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) by ietfa.amsl.com (Postfix) with ESMTP id 80A7021F9F96 for ; Tue, 12 Nov 2013 19:59:22 -0800 (PST)
Received: from relay2.asia.apple.com ( [17.82.200.16]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 2D.DB.03695.919F2825; Wed, 13 Nov 2013 11:59:21 +0800 (MYT)
X-AuditID: 1152fe06-b7f5a6d000000e6f-40-5282f919a4ad
Received: from sng-mmpp-sz01.asia.apple.com ( [17.82.200.58]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.asia.apple.com (Apple Singapore relay) with SMTP id 0F.7A.04639.919F2825; Wed, 13 Nov 2013 11:59:21 +0800 (MYT)
Received: from [17.85.194.165] (unknown [17.85.194.165]) by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MW600AK9OEWJ550@sng-mmpp-sz01.asia.apple.com> for rtcweb@ietf.org; Wed, 13 Nov 2013 11:59:21 +0800 (SGT)
Content-type: text/plain; charset=windows-1252
MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: David Singer 
In-reply-to: <5282A340.7010405@gondwanaland.com>
Date: Wed, 13 Nov 2013 11:59:19 +0800
Content-transfer-encoding: quoted-printable
Message-id: <5056AF7E-5C2C-4094-B77D-1BC52B792C03@apple.com>
References: <5282A340.7010405@gondwanaland.com>
To: Mike Linksvayer 
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUiGHRCQFfyZ1OQwYK7/BZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+7lj2wFU3grljWINzBe5epi5OSQEDCR+Lmvix3CFpO4cG89 WxcjF4eQwG5GiR8HJjLCFPV+Os4EkZjMJLF01ikoZwuTxIv504HaOTiYBfQk7l/UAmngBTJ3 7t3GCmILC/hK/DqwBGwDm4CqxIM5x8CGcgoYSKw++AvMZgGK/5mykQXEZhYQlvj++B6UrS3x 5N0FVoiZNhJHph8GiwsJ6Ev83nOJDWStiICmRMcPPog7ZSVOn3vOAnKahMBXVomNre+YJzAK z0K4bhaS62Yh2bCAkXkVo3huYmaObmaekV5icWaiXmJBQU6qXnJ+7iZGcDD/Y9vBuOC14SFG AQ5GJR7eA+drgoRYE8uKK3MPMUpwMCuJ8Eq/awoS4k1JrKxKLcqPLyrNSS0+xCjNwaIkziuW UhskJJCeWJKanZpakFoEk2Xi4JRqYOyQ7Z0RxfCnl7H/a/sLL4Hv38s3/DmyeW9vnHPljkU8 s+SCD5RJ9QW+n3Et5XfE2QOnpXgz72ZmnzynkO3yQ3TpREH1nuo0m+1FlqwJhxkPn22Tqdo7 y8fUlytlx++Kxq4ZUnHP1yxr8DN+m2z08LPW1j+LTxR8unjhzyVphwkX1sre42ralqvEUpyR aKjFXFScCABQ3QPAYgIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUiGHTCSlfyZ1OQwa2nPBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+7lj2wFU3grljWINzBe5epi5OSQEDCR6P10nAnCFpO4cG89 WxcjF4eQwGQmiaWzTjFBOFuYJF7Mn87excjBwSygJ3H/ohZIAy+QuXPvNlYQW1jAV+LXgSXs IDabgKrEgznHGEFsTgEDidUHf4HZLEDxP1M2soDYzALCEt8f34OytSWevLvACjHTRuLI9MNg cSEBfYnfey6xgawVEdCU6PjBB3GnrMTpc89ZJjAKzEI4aBaSg2YhGbqAkXkVo2hRak5ipZFe YnFmol5iQUFOql5yfu4mRkjwCexgnHXI4BCjAAejEg9vMUddkBBrYllxZe4hRgkOZiURXul3 TUFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeVNSaoOEBNITS1KzU1MLUotgskwcnFINjIVXTied WZUpd6B5qZWeAr+bf9L/It2fH45XM82YknC0KPmlkqLLuYilC3jFdx0/dNUt3KEjbK71l7nG 8mrSL3bdsZ8kkcTuEv996qnZm6V0DVTeH9q+zO1wgPjp59vs9797u+3yg4lZE1dPYdx9s/rn co6O+s2C4pKFL8X4084y6/yXyc0+xaTEUpyRaKjFXFScCACijts3OgIAAA==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 03:59:28 -0000

On Nov 13, 2013, at 5:53 , Mike Linksvayer  wrote:

> Harald Alvestrand, about 48 minutes into
> =
http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=3DIETF8=
8_RTCWEB_II&chapter=3Dpart_9
>> Development of codecs has been massively hampered and held back by
>> the  fact that it has been done in a fashion that has served to
>> maximize the  patent encumbrances on codecs. Sooner or later, we
>> should see a way  forward to abandon the dependence on encumbered
>> codecs also for video  software. My question, at this juncture,
>> is if not now, when?
>=20
> I didn't hear an answer, but would love to hear one. It is conceivable
> I could be convinced of a compromise now, if it were obvious those
> individuals and businesses pushing for H.264 were also unambiguously
> helping fix the problem in the medium and longer term by helping
> next- VP9 and and next-next-generation Daala, and lobbying for the
> elimination of software patents.

MPEG has not one, not two, but three tracks for developing unencumbered =
or RF-only encumbered video, as an experiment.  I think there are a few =
people at MPEG who think that this optimization direction -- for cost of =
license -- is clearly applicable to some cases, and should be followed.

The need or bandwidth-saving at any cost -- the old optimization =
direction -- is slackening, IMHO.  Sometimes you want to optimize =
battery life (complexity), sometimes license cost, and so on.

There are not enough people, in my opinion, working on this at MPEG.  =
Getting involved, helping, would be good.

David Singer
Multimedia and Software Standards, Apple Inc.


From magnus.westerlund@ericsson.com  Tue Nov 12 23:23:09 2013
Return-Path: 
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 09B4121E809A for ; Tue, 12 Nov 2013 23:23:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.536
X-Spam-Level: 
X-Spam-Status: No, score=-105.536 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 TMEtTkK4Op3j for ; Tue, 12 Nov 2013 23:23:04 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2BB21E805F for ; Tue, 12 Nov 2013 23:23:03 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-ac-528328d54ca2
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BA.8E.23787.5D823825; Wed, 13 Nov 2013 08:23:01 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.328.9; Wed, 13 Nov 2013 08:23:01 +0100
Message-ID: <5283291E.7090108@ericsson.com>
Date: Wed, 13 Nov 2013 08:24:14 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , Harald Tveit Alvestrand , "rtcweb@ietf.org" 
References: <5282391D.3050002@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net>
In-Reply-To: <40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VveqRnOQwfZ+XYtjfV1sFs9alzNZ rP3Xzu7A7HFlwhVWjyVLfjJ5/Fx/lT2AOYrLJiU1J7MstUjfLoErY/LPu8wFm7kq5j5ax9bA eJqji5GTQ0LAROLT8teMELaYxIV769m6GLk4hAQOMUr0HPjPDOEsZ5SY/Pw6C0gVr4C2xL6p HUwgNouAqsS1O71gcTYBC4mbPxrZQGxRgWCJ868Ws0PUC0qcnPmEBWSQiMA6RonNjauZQRLC Ao4S82ZMBGsQEsiXmLnjFlgDp0CAxMQ7PUBxDqCTxCV6GoNAwswCehJTrrYwQtjyEs1bZzND tGpLNDR1sE5gFJyFZN0sJC2zkLQsYGRexciem5iZk15uuIkRGKgHt/zW3cF46pzIIUZpDhYl cd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTByL86a3Lb/q5Xvdm+2GNEXFof+zqx8 ov3xnNSN0w0+nrp8NkZuZQIl2TfbAwryhedM/BCu++rGW4aCmK7fggdZj/3hvTyhyjyWl+3d SqOu/9v4RWbd3VW7pd6OqeOWO9dCNoaILLHUSsm+fb/SHrVL7ZDfxmsRduZtunNYmg2XjNZb pkiT30osxRmJhlrMRcWJAPbdsmkiAgAA
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 07:23:09 -0000

Hi Partha

On 2013-11-12 19:33, Ravindran, Parthasarathi (NSN - IN/Bangalore) wrote:
> Hi Magnus,
> 
> ICE-TCP shall be used by WebRTC gateways and conference scenario. The
> related usecases are discussed in
> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html
> (PNTAW mailing alias). So, it should not be simply be removed.
> '

Sorry, I don't understand what your use case is for ICE-TCP. When do you
need to establish an end-to-end TCP connection between two WebRTC
endpoints. I fail to see the motivation for this given that you are
going to establish a PeerConnection across it, with the purpose of
running STUN, RTP, DTLS-SRTP and DTLS/SCTP messages across it.

So please elaborate on why ICE-TCP with an framing for datagrams is not
just redundant from a functionality perspective with TURN/TCP or
TURN/TLS/TCP?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Wed Nov 13 00:24:39 2013
Return-Path: 
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 5C24D21F9F80 for ; Wed, 13 Nov 2013 00:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.555
X-Spam-Level: 
X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_EQ_SE=0.35,  RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 BEGdthy+egVT for ; Wed, 13 Nov 2013 00:24:34 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A749511E80FB for ; Wed, 13 Nov 2013 00:24:33 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-7c-5283373fedee
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1C.CE.15980.F3733825; Wed, 13 Nov 2013 09:24:31 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Wed, 13 Nov 2013 09:24:28 +0100
Message-ID: <52833786.5000606@ericsson.com>
Date: Wed, 13 Nov 2013 09:25:42 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Harald Alvestrand , "rtcweb@ietf.org" 
References: <5282391D.3050002@ericsson.com> <52827D3B.9000204@alvestrand.no>
In-Reply-To: <52827D3B.9000204@alvestrand.no>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3VtfevDnIYHqvrsWxvi42i7X/2tkd mDyuTLjC6rFkyU+mAKYoLpuU1JzMstQifbsEroy+L1/ZCw4EVCyffpm1gfGKfRcjJ4eEgInE /ouHWCFsMYkL99azdTFycQgJHGKUONrbwgrhLGeUuHLxMiNIFa+AtsSazqtMIDaLgKpE+8IH YHE2AQuJmz8a2UBsUYFgifOvFrND1AtKnJz5hAXEFgGK9z5/D1YvDFS/fN9WsLiQgI/E/kfb wOKcAroSC6ZsBrI5gC4Sl+hpDAIJMwvoSUy52sIIYctLNG+dzQzRqi3R0NTBOoFRcBaSbbOQ tMxC0rKAkXkVI3tuYmZOern5JkZgSB7c8ttgB+Om+2KHGKU5WJTEeT+8dQ4SEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwHgy7siELUrmudxHVYLansr0/cv46NQ3W65nX9Uyf4cJnKcLLLj/ ns99Zr33tGbSSUlXrXx73/N/PBcqvrIy5IjLTXmQW35+xor/xb9YPs/kSF42/4zd0+5DL0/Z iadE8GkeicrKy/E+q2bKryt4Z7n+jW3vvikEr+8q+T+bZe1LUb5ru6dkhyuxFGckGmoxFxUn AgD2rDDoFwIAAA==
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 08:24:39 -0000

Hi,

Many follow up comments inline.

On 2013-11-12 20:10, Harald Alvestrand wrote:
> On 11/12/2013 03:20 PM, Magnus Westerlund wrote:
>> Hi,
>>
>> Here are my review comments on draft-ietf-rtcweb-transports-01:
>>
>> 1. Front page: I would strongly suggest moving requirements language
>> into some numbered section.
>>
>> 2. Section 2.1:
>>
>>    o  TCP.  This is used for HTTP/WebSockets, as well as for TURN/SSL
>>       and ICE-TCP.
>>
>> Are there really any need for ICE-TCP? Can't this simply be removed?
> 
> This question belongs in 2.2 - it's a MAY requirement there (but there
> have been arguments in pntaw that it should be a SHOULD).
> In both cases,

Okay, I have responded to Partha's question because I don't understand
his motivation yet.

>>
>> 3. Section 2.1:
>>    For both protocols, this specification assumes the ability to set the
>>    DSCP code point of the sockets opened on a per-packet basis, in order
>>    to achieve the prioritizations described in [I-D.ietf-rtcweb-qos].
>>
>> First, I don't think one can assume the ability to set DSCP code points.
>> I think one should express that it is desirable to do it.
>>
>> Secondly, I think one has to be aware that setting DSCP on a per packet
>> basis may be less commonly working than even just marking a flow
>> consistently.
> 
> References? Is this an assumption, or based on actual
> experiments/experiences?

Hmm, I might have overstated my case here. I can't actually find a
reference to this. My observation digging through some APIs, like
Windows QoS2, and also the regular socket API is that they appear much
easier to use if you just set a DSCP rather than like to juggle it on
per packet basis. But, I can't support they are impossible to use.

> 
>>
>> Thirdly, the I-D.ietf-rtcweb-qos is dead, and if anything it should be
>> replaced by draft-dhesikan-tsvwg-rtcweb-qos-02.
> 
> I will take instructions from the chairs on this point; I think we need
> to specify what -qos- used to say, and resurrecting that draft may be
> easier/better than adopting a new one.
> 
> So far, I have not seen anything from the chairs (before now) that
> announces that it's dead.

Okay, we might not have been public enough on this. It was requested by
the Transport ADs quite some time ago that doing the QoS document in our
WG was not appropriate and requested us to direct the document to TSVWG.
Which was done, and where it hasn't made progress.

You might have noted that James Polk did comment in the milestone part
in the monday session of IETF88 about our QoS milestone should be killed.

> 
>>
>> 4. Section 2.1:
>>    If DSCP code points can only be set on a per-socket basis, not per-
>>    packet, one loses the ability to have the network discriminate
>>    reliably between classes of traffic sent over the same transport, but
>>    this does not prevent communication.
>>
>> As this means all packets in the flow gets same treatment, one can point
>> out that using multiple RTP sessions and transport flows allow one to
>> have multiple different priority levels.
> 
> That's an implication of what this says. The ability to differentiate
> between different flows is common enough that it is assumed.

Sorry, for being picky, but what flow definition are you using in the
above sentence. The one related to the applications flows, like an RTP
packet stream with the same SSRC, or a SCTP Stream, or do you mean all
packets with the same six-tuple, i.e. src addr, src port, dest addr,
dest port, Transport protocol, DSCP?

Even so, are there need to discuss also here the possibility that these
transport level limitations have impact on the default behavior of the
WebRTC implementation on what it suggest given that an application have
requested different priorities.

> 
>>
>> 5. Section 2.1:
>>    This specification does not assume that the implementation will have
>>    access to ICMP or raw IP.
>>
>> I think it should point out the advantage of being capable of receiving
>> ICMP in MTU discovery.
> 
> I think this is not realistic for the browser use case, where the stack
> is implemented as an unprivilleged application. I think the requirements
> need to be achievable in that situation, which is the point of this
> explicit non-assumption.

And my point is that not all WebRTC end-points will have this
limitation. I am all positive in describing the issues when you can't do
it, similar I do like to point out that when one can do it, one should
because it do give an significant advantage.

> 
> That means that path MTU discovery for UDP will have to depend on
> observing the packet loss patterns, if done at all. I think that's
> realistic.

I agree that given no possibility to setting DF and receving ICMP one
will be limited. However, there appear to exist a possibility to read
the currently known IP MTU using the Socket API. This might actually be
relevant when using IPv6, where ICMP much more needs to work.

> 
>>
>> In addition I think you can bring up the benefits from being capable of
>> setting DF bit.
> 
> Is there a benefit, given the point above?

I claim that not all WebRTC endpoints will have this limiation. Either
from being a central conference node with native implementation, or by
being a privileged application.

> Is there a common userspace way to achieve this?

I don't know about common, but some OS do appear to have settings for
it. For example Linux appears to have a setsockopt flag called
IP_MTU_DISCOVER which allows you to force the DF always on IP_PMTUDISC_DO.

> 
>>
>> 6. Section 2.2:
>>    ICE TCP candidates [RFC6062] MAY be supported; this may allow
>>    applications to achieve peer-to-peer communication across UDP-
>>    blocking firewalls, but this also requires use of the SRTP/AVPF/TCP
>>    profile of RTP.
>>
>> I would question if this at all should be discussed. First of all a
>> TURN/TCP or TURN/TLS/TCP relay fulfills the needs to cross a only TCP
>> allowing firewall.
> The PNTAW discussion seems to indicate that there are scenarios where
> this is realistic.

Assuming that the result of the discussion is that it is needed.

>> Secondly, if one likes to use TCP/TLS/RTP/SAVPF then
>> one would need to use RFC 4571 framing, or do you have another proposal?
> 
> I think the spec has to point to something that defines the framing,
> otherwise this won't achieve interoperability. Is RFC 4571 the right
> reference?

It is is one framing that is defined for RTP over TCP. It will be able
to carry also the DTLS and STUN packets over the TCP connection. The
main question is the need to define a signalling name for this,
especially if one likes to consider it as pure datagram service, instead
of specific ones. The alternative is that we will need
TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP as signalling entities in SDP.

> 
>> I would also note that such a combination do require us to do a bit of
>> specification work to bring RFC 4571 up to date to allow us use both
>> profiles beyond AVP as well as indicating usage of DTLS-SRTP over that
>> TCP framing. Considering that this appears to be a redundant and less
>> likely to work mechanism I would propose to remove it from consideration
>> even for MAY.
> 
> Redundant with what other mechanism?

>From my perspective using end to end TCP with ICE-TCP is redundant from
the perspective of getting through restrictive firewalls compared to
TURN/TCP or TURN/TLS/TCP. I will agree with them not being identical,
but I question the motivation for requiring implementation of ICE-TCP
for this case, which anyway are supported by having TURN/TCP.

> 
>>
>> 7. Section 2.2.:
>>
>>    o  TURN, including TURN over TCP[RFC5766].
>>
>> Missing space between TCP and reference.
>>
>> 8. Section 2.2:
>>
>>    TURN over TLS over TCP MAY be supported.  (QUESTION: SHOULD?  MUST?)
>>
>> I think MAY is a fine level for this. But it clearly should be an issue
>> raised to the WG for further debate.
> 
> This is being debated on PNTAW.

I will look there, however I do recommend that the conclusion from that
discussion being posted to the WG list for confirmation.

> 
>>
>> 9. Section 2.3:
>>    The setup protocol for RTCWEB data channels is described in
>>    [I-D.jesup-rtcweb-data-protocol].
>>
>> That draft is now a WG draft.
>>
>> 10. Section 2.3:
>>    RTCWEB implementations MUST support multiplexing of DTLS and RTP over
>>    the same port pair, as described in the DTLS_SRTP specification
>>    [RFC5764], section 5.1.2.  Further separation of the DTLS traffic
>>    into SCTP and "other" is described in .
>>
>> A. I would note that one actually must be capable of multiplexing DTLS,
>> RTP and STUN messages on the same port pair.
> 
> That is described in RFC 5764 section 5.1.2. Since ICE is completely
> useless if it can't be multiplexed over the same port pair as the stuff
> it's probing for, I regard the ability to demultiplex STUN packets as
> implicit in the statement "we're using ICE".

Fine, the reference do include the STUN separation.

> 
>>
>> B. What about that needed reference. I think it is
>> draft-ietf-rtcweb-data-channel that should have this text.
> 
> I'll check if it does. 

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/

Does not appear to have anything about this. But I think this is less
appropriate place to discuss that multiplexing.

>>
>> 11. Section 4:
>>
>> I think this document do need to discuss DSCP and ICMP and the issues
>> they can cause. Or possibly provide input to the security consideration
>> document.
> 
> Please send text or pointers.
> 

Will try.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From tim@phonefromhere.com  Wed Nov 13 02:35:01 2013
Return-Path: 
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 AC9BE11E8100 for ; Wed, 13 Nov 2013 02:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Level: 
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74]
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 AT+Pgy-xxq6U for ; Wed, 13 Nov 2013 02:34:55 -0800 (PST)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 0906311E80E7 for ; Wed, 13 Nov 2013 02:34:54 -0800 (PST)
Received: (qmail 68173 invoked from network); 13 Nov 2013 10:34:52 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 3475
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 13 Nov 2013 10:34:52 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 8230718A04E3; Wed, 13 Nov 2013 10:34:50 +0000 (GMT)
Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 4CD8018A0176;  Wed, 13 Nov 2013 10:34:50 +0000 (GMT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Tim Panton 
In-Reply-To: <5056AF7E-5C2C-4094-B77D-1BC52B792C03@apple.com>
Date: Wed, 13 Nov 2013 10:34:48 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <55F043DB-3AF6-4A33-B504-F5B316273DDB@phonefromhere.com>
References: <5282A340.7010405@gondwanaland.com> <5056AF7E-5C2C-4094-B77D-1BC52B792C03@apple.com>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1816)
Cc: "Cullen Jennings \(fluffy\)" 
Subject: [rtcweb] where that h264 plugin can be used
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 10:35:01 -0000

Since the MTI video codec discussion I've been mulling over the h264 =
plugin kindly offered by cisco.

I think that there are many places where it will be useful, and I thank =
cisco for that.

I've come up with some problems which will need to addressed for it to =
meet the needs of rtcweb.

1) Appstores: No program that is destined to be sold or distributed in =
an app store will be able to use it.
As far as I can tell the Mac, win8, ios and android app stores all =
specifically ban the use of downloaded
plugins.=20
This means that no 3rd party browser can use it - except those browsers =
that have their own distribution channel.
Like it or not, the appstore model is taking over the world. Many people =
don't feel comfortable (or just can't)
install apps that don't come from the official app stores.

This also means that no native app can include webRTC compatible video =
functionality using the plugin, if it wants=20
to be sold/distributed via an app store.

2) Secure platforms: Platforms that only run authorised, signed code, =
(eg OSX by default) may have trouble running this, depending
on exactly how the install-and-download-plugin sequence works. =20

3) Cloud platforms: A common usage in cloud land is to build a server =
image, and then boot multiple clones
of that image as service demand rises, then deleting them as load falls. =
Now consider a cloud video service that uses
the plugin as part of it's code. If I understand it correctly, each =
image boot
would need to separately download and install the plugin or risk =
breaching the license terms. This breaks the=20
easy scalability model of having pre-pickeled images ready to roll.

4) Dark installs: It is common practice in some environments to require =
an install that can be made entirely from a DVD.
This won't be possible with the plugin.

Sure there are possible work arounds for some of these issues, but all =
are somewhat unsatisfactory, and highlight the extent to which
the h264 plugin puts engineering decisions into the hands of lawyers.

Tim.=

From lorenzo@meetecho.com  Wed Nov 13 03:22:55 2013
Return-Path: 
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 14A4121F9EAF for ; Wed, 13 Nov 2013 03:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.479
X-Spam-Level: 
X-Spam-Status: No, score=-0.479 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3]
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 hifU8B1Lo9W1 for ; Wed, 13 Nov 2013 03:22:50 -0800 (PST)
Received: from smtpdg96.aruba.it (smtpdg5.aruba.it [62.149.158.235]) by ietfa.amsl.com (Postfix) with ESMTP id E013621E80CE for ; Wed, 13 Nov 2013 03:22:49 -0800 (PST)
Received: from lminiero ([143.225.229.166]) by smtpcmd05.ad.aruba.it with bizsmtp id ozNm1m0193c3Lvj01zNmKv; Wed, 13 Nov 2013 12:22:47 +0100
Date: Wed, 13 Nov 2013 12:22:46 +0100
From: Lorenzo Miniero 
To: =?UTF-8?B?ScOxYWtp?= Baz Castillo 
Message-ID: <20131113122246.366813a3@lminiero>
In-Reply-To: 
References:  <20131111191712.59e4e44d@lminiero>  <7594FB04B1934943A5C02806D1A2204B1C5167D2@ESESSMB209.ericsson.se> 
Organization: Meetecho
X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] No-Bundle in just one peer
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 11:22:55 -0000

Il giorno Tue, 12 Nov 2013 01:58:45 +0100
I=C3=B1aki Baz Castillo  ha scritto:

> Clear. Thanks to all.
>=20


Thanks Justin and Christer for the clarification (I just did my bundle
catchup reading the draft and MMUSIC posts, mea culpa!) and sorry I=C3=B1aki
for the misinformation. ;-)

Lorenzo


> 2013/11/12 Christer Holmberg :
> > Hi,
> >
> >
> >
> > Justin is correct.
> >
> >
> >
> > At one point we made a decision, that either both endpoints do
> > BUNDLE, or no endpoint does BUNDLE.
> >
> >
> >
> > A, not supporting BUNDLE, may not like receiving an SDP Answer from
> > B with a shared address assigned to multiple m- lines.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Christer
> >
> >
> >
> >
> >
> > L=C3=A4hett=C3=A4j=C3=A4: rtcweb-bounces@ietf.org [mailto:rtcweb-bounce=
s@ietf.org]
> > Puolesta Justin Uberti
> > L=C3=A4hetetty: 11. marraskuuta 2013 23:04
> > Vastaanottaja: Lorenzo Miniero
> > Kopio: rtcweb@ietf.org
> > Aihe: Re: [rtcweb] No-Bundle in just one peer
> >
> >
> >
> > No, B cannot BUNDLE if A is not BUNDLEing. There are a number of
> > corner cases where things don't work right in the situation
> > described above.
> >
> >
> >
> > On Mon, Nov 11, 2013 at 10:17 AM, Lorenzo Miniero
> >  wrote:
> >
> > Il giorno Mon, 11 Nov 2013 19:12:01 +0100
> > I=C3=B1aki Baz Castillo  ha scritto:
> >
> >
> >> Hi,
> >>
> >> In case peer A sends a SPD without Bundle support (so it needs to
> >> receive incoming tracks in separate ports and send tracks from
> >> separate ports) does it aslo mean that peer B must not use Bundle?
> >> Or could peer A use two local ports (no Bundle) to send/receive
> >> tracks to/from a single port in peer B?
> >>
> >> Thanks a lot.
> >>
> >> --
> >> I=C3=B1aki Baz Castillo
> >> 
> >
> > Hi I=C3=B1aki,
> >
> > not sure what the spec currently mandates, but this works already in
> > existing implementations. Peer A just needs to do the ICE and DTLS
> > dance twice from its two ports towards the single port in B (twice
> > or more, in case you're not muxing RTCP either).
> >
> > Lorenzo
> > _______________________________________________
> > 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
> >
>=20
>=20
>=20


From ibc@aliax.net  Wed Nov 13 03:24:28 2013
Return-Path: 
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 EC20621E80DD for ; Wed, 13 Nov 2013 03:24:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 D9KbPjtfonLa for ; Wed, 13 Nov 2013 03:24:23 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8B4421E80CE for ; Wed, 13 Nov 2013 03:24:23 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id t7so128844qcv.3 for ; Wed, 13 Nov 2013 03:24:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=mEfcIszn05wQ/Athupjmsinf9V5tfEOyficJknYaE80=; b=jkQyfy7QIkfRg1+uSdqptoV0MpDfvimh4kJsTxx3eGZ2lmVLOBlGe82X+GBUZENrIX e0zpzyvsU9aFvWHc6d27qStPq6CnnhFBxxYT10s96QHxkJgqhez0iDJDu6EwYlh0+gVT Pl1AlWFdtGGK37raFg3yl/GAmt9RkoS6ZxEZO05HBE68tUbsvjyj2lkvKm0Ua9ledIKV d1ATXlV4ejPDlHRY+jPDvQz+idnDN2+zqFqvy8wRxJRFopm524xDy3XmfOgXqU89LXo5 t27v+Qv8m8xzDiY1qj2fMmf1DqMW8QRdGUv98v2YCT/3NwLnKf0pLAxxubaS4roXbVXh om4g==
X-Gm-Message-State: ALoCoQnHc1B2xuQvUS6MjPbRWHDp5JJsm+nHVmRoIIRUvZ40KJaIbDcYBxean2Q0nWJfKblW51sB
X-Received: by 10.229.219.199 with SMTP id hv7mr64352891qcb.15.1384341863203;  Wed, 13 Nov 2013 03:24:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.71.8 with HTTP; Wed, 13 Nov 2013 03:24:03 -0800 (PST)
In-Reply-To: <20131113122246.366813a3@lminiero>
References:  <20131111191712.59e4e44d@lminiero>  <7594FB04B1934943A5C02806D1A2204B1C5167D2@ESESSMB209.ericsson.se>  <20131113122246.366813a3@lminiero>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 13 Nov 2013 12:24:03 +0100
Message-ID: 
To: Lorenzo Miniero 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] No-Bundle in just one peer
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 11:24:29 -0000

2013/11/13 Lorenzo Miniero :
> Il giorno Tue, 12 Nov 2013 01:58:45 +0100
> I=C3=B1aki Baz Castillo  ha scritto:
>
>> Clear. Thanks to all.
>>
>
>
> Thanks Justin and Christer for the clarification (I just did my bundle
> catchup reading the draft and MMUSIC posts, mea culpa!) and sorry I=C3=B1=
aki
> for the misinformation. ;-)

Not at all! Thanks to you all.


--=20
I=C3=B1aki Baz Castillo


From parthasarathi.ravindran@nsn.com  Wed Nov 13 08:34:17 2013
Return-Path: 
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 6D76421E814A for ; Wed, 13 Nov 2013 08:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 DvbRKVa1EczC for ; Wed, 13 Nov 2013 08:34:13 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 03BDA21E8134 for ; Wed, 13 Nov 2013 08:34:04 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rADGXu7I006554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Nov 2013 17:33:57 +0100
Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rADGXsEV008980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 17:33:55 +0100
Received: from SGSIHTC007.nsn-intra.net (10.159.225.24) by SGSIHTC002.nsn-intra.net (10.159.225.19) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 14 Nov 2013 00:33:53 +0800
Received: from SGSIMBX006.nsn-intra.net ([169.254.6.69]) by SGSIHTC007.nsn-intra.net ([10.159.225.24]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 00:33:53 +0800
From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" 
To: ext Magnus Westerlund , "Harald Tveit Alvestrand" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
Thread-Index: AQHO37I3PiD2CpYvFEa5TFD9+s8TOpoh62lQgABRywCAARYGsA==
Date: Wed, 13 Nov 2013 16:33:52 +0000
Message-ID: <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net>
References: <5282391D.3050002@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net> <5283291E.7090108@ericsson.com>
In-Reply-To: <5283291E.7090108@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.225.123]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2392
X-purgate-ID: 151667::1384360438-00005753-CF4F4233/0-0/0-0
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 16:34:17 -0000

Hi Magnus,

In case of Browser - GW/Server use cases (Sec 3.4 of draft-ietf-rtcweb-use-=
cases-and-requirements-12), the end-to-end TCP connection is between browse=
r & Gateway directly. Here, GW/server acts as RTP endpoint/mixer in the mid=
dle of the network and acts as "RTP relay" [Note 1] to the actual remote en=
dpoint. TURN server (TCP to UDP relay) is becoming "second middle box" in c=
ase GW/server provider has to deploy TURN server as well. ICE-TCP solves th=
e issue as it creates the host candidates from GW/Server.

As Justin indicated in PNTAW, TURN 3rd party authentication is not required=
 in case of ICE-TCP from GW/Server.

Thanks
Partha

Note 1: I could not think of more appropriate IETF terminology.

-----Original Message-----
From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20
Sent: Wednesday, November 13, 2013 12:54 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Harald Tveit Alvestrand;=
 rtcweb@ietf.org
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

Hi Partha

On 2013-11-12 19:33, Ravindran, Parthasarathi (NSN - IN/Bangalore) wrote:
> Hi Magnus,
>=20
> ICE-TCP shall be used by WebRTC gateways and conference scenario. The
> related usecases are discussed in
> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html
> (PNTAW mailing alias). So, it should not be simply be removed.
> '

Sorry, I don't understand what your use case is for ICE-TCP. When do you
need to establish an end-to-end TCP connection between two WebRTC
endpoints. I fail to see the motivation for this given that you are
going to establish a PeerConnection across it, with the purpose of
running STUN, RTP, DTLS-SRTP and DTLS/SCTP messages across it.

So please elaborate on why ICE-TCP with an framing for datagrams is not
just redundant from a functionality perspective with TURN/TCP or
TURN/TLS/TCP?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
F=E4r=F6gatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From john@jlc.net  Wed Nov 13 08:55:33 2013
Return-Path: 
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 C153A11E8162 for ; Wed, 13 Nov 2013 08:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.398
X-Spam-Level: 
X-Spam-Status: No, score=-106.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 qbMYghTuUs3Q for ; Wed, 13 Nov 2013 08:55:28 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 80CDB21F9AE7 for ; Wed, 13 Nov 2013 08:55:28 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 1F50CC94C0; Wed, 13 Nov 2013 11:55:26 -0500 (EST)
Date: Wed, 13 Nov 2013 11:55:26 -0500
From: John Leslie 
To: Mike Linksvayer 
Message-ID: <20131113165526.GA13468@verdi>
References: <5282A340.7010405@gondwanaland.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5282A340.7010405@gondwanaland.com>
User-Agent: Mutt/1.4.1i
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 16:55:33 -0000

Mike Linksvayer  wrote:
> 
> I strongly support VP8 for MTI, and oppose H.264. Undecided on which
> of both, either, or neither would be second best.

   I'm _very_ glad you care which is "second best!"

   I went into last week's session quite prepared to accept either, both
or neither. I came out unwilling to support _either_ as MTI.

   This is mostly because I came to understand the "cisco" postition.

   (Please excuse me for assigning names to the two main positions, but
it will make the discussion _much_ simpler.)

   The "cisco" position is:

- look at all the H.264 hardware out there: we must make use of it;
- if VP8 is MTI, we'll get sued and our customers will get hassled.

   The "linux" position is:

- look at all the VP8 software out there: we must make use of it;
- if H.264 is MTI, we'll get sued and our customers will get hassled.

   And, alas, they're both right.

   What I didn't understand before the presentations was why Cisco
believes they'll get sued over VP8, but not H.264.

   Basically H.264 has quite a consortium to slap down the likes of
Nokia in court should they sue anyone in the consortium. This greatly
reduces the chance of Nokia's lawyer suing.

   But this consortium won't lift a finger if Nokia sues Cisco over
VP8. Cisco is a _very_ attractive target over VP8.

   Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
MTI. They probably won't implement it.

   Conversely, of course, "linux" management would _very_much_ prefer
that H.264 not be MTI. They probably won't implement it.

   Understanding this, I now strongly recommend against making either
H.264 or VP8 MTI. (And I will not consent to a RFC 3929 process limited
to choosing between them.)

   This issue has dragged on long enough already. We need to start
reading the riot act to the folks who claim we "need" either of these
as MTI in order to have "satisfied" users.

   Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
IMHO, will achieve consensus for "MUST implement" status. Yes, this
is a sorry state to find ourselves in. But the marketplace has
sorted out much worse problems in my memory.

   And I claim that both camps are actually more likely to implement
(or allow extensions for) the other side's codec if it is _not_ MTI,
simply because they can back out at the first sign of lawyers.

   I will not go into any details about how VP8 endpoints might talk
to H.264 endpoints, but I'm _very_ confident ways will be found if
we actually _publish_ an RFC saying both are "SHOULD implement".

   (Surely I'm not the _only_ person who'd like to see _both_ H.264
and VP8 legacy devices using our standard...)

--
John Leslie 

From simon.perreault@viagenie.ca  Wed Nov 13 09:40:31 2013
Return-Path: 
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 7F38C11E81A8 for ; Wed, 13 Nov 2013 09:40:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Tu6vyD2wnAYZ for ; Wed, 13 Nov 2013 09:40:30 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E36A321E8151 for ; Wed, 13 Nov 2013 09:39:13 -0800 (PST)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d5d4:b853:2212:f683]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EF541403CF; Wed, 13 Nov 2013 12:38:51 -0500 (EST)
Message-ID: <5283B92B.4080304@viagenie.ca>
Date: Wed, 13 Nov 2013 12:38:51 -0500
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , ext Magnus Westerlund ,  Harald Tveit Alvestrand , "rtcweb@ietf.org" 
References: <5282391D.3050002@ericsson.com>	<40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net>	<5283291E.7090108@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net>
In-Reply-To: <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 17:40:31 -0000

Le 2013-11-13 11:33, Ravindran, Parthasarathi (NSN - IN/Bangalore) a écrit :
> In case of Browser - GW/Server use cases (Sec 3.4 of draft-ietf-rtcweb-use-cases-and-requirements-12), the end-to-end TCP connection is between browser & Gateway directly. Here, GW/server acts as RTP endpoint/mixer in the middle of the network and acts as "RTP relay" [Note 1] to the actual remote endpoint. TURN server (TCP to UDP relay) is becoming "second middle box" in case GW/server provider has to deploy TURN server as well. ICE-TCP solves the issue as it creates the host candidates from GW/Server.

All this relies on the possibility that a TCP peer-to-peer connection 
could be successfully established where a UDP one couldn't. IMHO this is 
very unlikely to happen in practice. So unlikely in fact that any 
possible gain over just falling back on a TURN relay wouldn't be worth 
the additional implementation cost.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From martin.thomson@gmail.com  Wed Nov 13 09:43:50 2013
Return-Path: 
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 412F511E8159 for ; Wed, 13 Nov 2013 09:43:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level: 
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599, 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 mM5EaEnqQpGr for ; Wed, 13 Nov 2013 09:43:49 -0800 (PST)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 97A9611E81A0 for ; Wed, 13 Nov 2013 09:43:49 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id x12so745933wgg.13 for ; Wed, 13 Nov 2013 09:43:48 -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=BAHzDax8k36zsHTus9Hvks2MlfFKrVEK8WU/n/tzncA=; b=vkL3fdxU+JBtTizMpVvAowvMatKDD0Q6PEvVlDGoUTdynDQN146LxWgZqb16p3GWbF eKqhzFD0nnxyVJI+rqGfudSR0MfFUeGHj4ZCQDgEb6Iqy9Vb3dXLNxaj5Bhch+ffE7OQ aHCFi+RRGvATgPC/oxL75F9tlVHvGOtrmGWR1mk4kY4QxaWwu3e2UKqAndeEexJxQWd1 LEtNZCNM+QVNaOAdjT/60QBh94HSD2/vFwoA4F+eoezujLN8yYeI54SsYf+mOUHbIazE aPA0nk9rxtpigEIiZr8RZBm5RI2pZBj7hybtwEzOnPkaBy5QHGM4thMc2QxJ1dhExxmD pYXQ==
MIME-Version: 1.0
X-Received: by 10.180.206.78 with SMTP id lm14mr2549986wic.30.1384364628711; Wed, 13 Nov 2013 09:43:48 -0800 (PST)
Received: by 10.227.101.73 with HTTP; Wed, 13 Nov 2013 09:43:48 -0800 (PST)
In-Reply-To: <55F043DB-3AF6-4A33-B504-F5B316273DDB@phonefromhere.com>
References: <5282A340.7010405@gondwanaland.com> <5056AF7E-5C2C-4094-B77D-1BC52B792C03@apple.com> <55F043DB-3AF6-4A33-B504-F5B316273DDB@phonefromhere.com>
Date: Wed, 13 Nov 2013 09:43:48 -0800
Message-ID: 
From: Martin Thomson 
To: Tim Panton 
Content-Type: text/plain; charset=UTF-8
Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] where that h264 plugin can be used
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 17:43:50 -0000

On 13 November 2013 02:34, Tim Panton  wrote:
> 3) Cloud platforms:

At least for the Microsoft cloud, I don't see this being an issue.
It's pretty standard to have a setup step once an image is deployed.

From parthasarathi.ravindran@nsn.com  Wed Nov 13 10:02:55 2013
Return-Path: 
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 5277111E81A0 for ; Wed, 13 Nov 2013 10:02:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 Ze-Dm3KmsouP for ; Wed, 13 Nov 2013 10:02:50 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 909CE11E813A for ; Wed, 13 Nov 2013 10:02:50 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rADI2lxw024593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Nov 2013 19:02:47 +0100
Received: from SGSIHTC001.nsn-intra.net ([10.159.225.18]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rADI2jJM030585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 19:02:47 +0100
Received: from SGSIMBX006.nsn-intra.net ([169.254.6.69]) by SGSIHTC001.nsn-intra.net ([10.159.225.18]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 02:02:45 +0800
From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" 
To: ext Simon Perreault , ext Magnus Westerlund , Harald Tveit Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
Thread-Index: AQHO37I3PiD2CpYvFEa5TFD9+s8TOpoh62lQgABRywCAARYGsP//lbOAgACJnKA=
Date: Wed, 13 Nov 2013 18:02:45 +0000
Message-ID: <40AFDF4AF1909E4CB42B6D91CE6C419D19C74E3B@SGSIMBX006.nsn-intra.net>
References: <5282391D.3050002@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net> <5283291E.7090108@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net> <5283B92B.4080304@viagenie.ca>
In-Reply-To: <5283B92B.4080304@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.225.123]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2260
X-purgate-ID: 151667::1384365767-00005753-BC8B197A/0-0/0-0
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 18:02:55 -0000

Hi Simon,

Please note that I'm only taking about Gateway/conference/IVR server usecas=
es wherein Gateway/conference/IVR server will not be behind restrictive fir=
ewall and only the browser may be behind the restrictive firewall.=20

TURN server will also make TCP connection to the GW provider in the mention=
ed scenario. So, there is no difference between ICE-TCP/TURN w.r.t TCP conn=
ection creation. In case TCP connection could not made between GW provider =
and the browser, the call will fail irrespective of firewall traversal mech=
anism (TURN/ICE-TCP) used. Also, there is no need of fallback to TURN serve=
r for these usecases. It is one of the reason, I'm asking for the separate =
usecase which clarify the requirements easily.

Thanks
Partha

-----Original Message-----
From: ext Simon Perreault [mailto:simon.perreault@viagenie.ca]=20
Sent: Wednesday, November 13, 2013 11:09 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); ext Magnus Westerlund; H=
arald Tveit Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

Le 2013-11-13 11:33, Ravindran, Parthasarathi (NSN - IN/Bangalore) a =E9cri=
t :
> In case of Browser - GW/Server use cases (Sec 3.4 of draft-ietf-rtcweb-us=
e-cases-and-requirements-12), the end-to-end TCP connection is between brow=
ser & Gateway directly. Here, GW/server acts as RTP endpoint/mixer in the m=
iddle of the network and acts as "RTP relay" [Note 1] to the actual remote =
endpoint. TURN server (TCP to UDP relay) is becoming "second middle box" in=
 case GW/server provider has to deploy TURN server as well. ICE-TCP solves =
the issue as it creates the host candidates from GW/Server.

All this relies on the possibility that a TCP peer-to-peer connection=20
could be successfully established where a UDP one couldn't. IMHO this is=20
very unlikely to happen in practice. So unlikely in fact that any=20
possible gain over just falling back on a TURN relay wouldn't be worth=20
the additional implementation cost.

Simon
--=20
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From adam@nostrum.com  Wed Nov 13 10:18:54 2013
Return-Path: 
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 D7F9621E8162 for ; Wed, 13 Nov 2013 10:18:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 m5O8X8Y2Binf for ; Wed, 13 Nov 2013 10:18:54 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E84DB11E81B2 for ; Wed, 13 Nov 2013 10:18:42 -0800 (PST)
Received: from [33.166.77.12] ([172.56.32.116]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rADIIbrR077276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Nov 2013 12:18:38 -0600 (CST) (envelope-from adam@nostrum.com)
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>
Mime-Version: 1.0 (1.0)
In-Reply-To: <20131113165526.GA13468@verdi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <98F61F8A-5982-44A3-8B2D-977DF26C924F@nostrum.com>
X-Mailer: iPhone Mail (10B350)
From: Adam Roach 
Date: Wed, 13 Nov 2013 10:18:32 -0800
To: John Leslie 
Received-SPF: pass (shaman.nostrum.com: 172.56.32.116 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 18:18:55 -0000

On Nov 13, 2013, at 8:55, John Leslie  wrote:

> VP8 legacy devices


Aside from Firefox and Chrome, what did you have in mind here?

/a

From harald@alvestrand.no  Wed Nov 13 10:45:03 2013
Return-Path: 
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 8256111E8126 for ; Wed, 13 Nov 2013 10:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.499
X-Spam-Level: 
X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 MQkGq4DuR0Xk for ; Wed, 13 Nov 2013 10:44:57 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0745721F9C8E for ; Wed, 13 Nov 2013 10:44:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5861439E1B7; Wed, 13 Nov 2013 19:44:56 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16ORQkcuriWD; Wed, 13 Nov 2013 19:44:55 +0100 (CET)
Received: from [172.30.42.84] (unknown [62.109.39.85]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id F39E939E176; Wed, 13 Nov 2013 19:44:54 +0100 (CET)
Message-ID: <5283C8A5.8030601@alvestrand.no>
Date: Wed, 13 Nov 2013 19:44:53 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Simon Perreault , "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , ext Magnus Westerlund ,  "rtcweb@ietf.org" 
References: <5282391D.3050002@ericsson.com>	<40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net>	<5283291E.7090108@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net> <5283B92B.4080304@viagenie.ca>
In-Reply-To: <5283B92B.4080304@viagenie.ca>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 18:45:03 -0000

On 11/13/2013 06:38 PM, Simon Perreault wrote:
> Le 2013-11-13 11:33, Ravindran, Parthasarathi (NSN - IN/Bangalore) a
> écrit :
>> In case of Browser - GW/Server use cases (Sec 3.4 of
>> draft-ietf-rtcweb-use-cases-and-requirements-12), the end-to-end TCP
>> connection is between browser & Gateway directly. Here, GW/server
>> acts as RTP endpoint/mixer in the middle of the network and acts as
>> "RTP relay" [Note 1] to the actual remote endpoint. TURN server (TCP
>> to UDP relay) is becoming "second middle box" in case GW/server
>> provider has to deploy TURN server as well. ICE-TCP solves the issue
>> as it creates the host candidates from GW/Server.
>
> All this relies on the possibility that a TCP peer-to-peer connection
> could be successfully established where a UDP one couldn't. IMHO this
> is very unlikely to happen in practice. So unlikely in fact that any
> possible gain over just falling back on a TURN relay wouldn't be worth
> the additional implementation cost.

Simon, do you have any numbers on that - how many calls will be going to
servers on the Internet versus how many calls will be going peer-to-peer?
The argument being given only applies to the client-to-gateway usecase
(or to naked destination clients that are not behind a NAT, which
hopefully will become common once IPv6 gets deployed, but aren't common
now).

>
> Simon


-- 
Surveillance is pervasive. Go Dark.


From simon.perreault@viagenie.ca  Wed Nov 13 10:57:40 2013
Return-Path: 
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 0F56C11E8126 for ; Wed, 13 Nov 2013 10:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jpwt9zVjOhvP for ; Wed, 13 Nov 2013 10:57:39 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2530611E8107 for ; Wed, 13 Nov 2013 10:57:39 -0800 (PST)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d5d4:b853:2212:f683]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7DABB403CF; Wed, 13 Nov 2013 13:57:38 -0500 (EST)
Message-ID: <5283CBA2.3060604@viagenie.ca>
Date: Wed, 13 Nov 2013 13:57:38 -0500
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Harald Alvestrand , "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , ext Magnus Westerlund ,  "rtcweb@ietf.org" 
References: <5282391D.3050002@ericsson.com>	<40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net>	<5283291E.7090108@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net> <5283B92B.4080304@viagenie.ca> <5283C8A5.8030601@alvestrand.no>
In-Reply-To: <5283C8A5.8030601@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 18:57:40 -0000

Le 2013-11-13 13:44, Harald Alvestrand a écrit :
>> All this relies on the possibility that a TCP peer-to-peer connection
>> could be successfully established where a UDP one couldn't. IMHO this
>> is very unlikely to happen in practice. So unlikely in fact that any
>> possible gain over just falling back on a TURN relay wouldn't be worth
>> the additional implementation cost.
>
> Simon, do you have any numbers on that - how many calls will be going to
> servers on the Internet versus how many calls will be going peer-to-peer?

Not sure what you mean.

> The argument being given only applies to the client-to-gateway usecase

My point only applied to peer-to-peer connections, not peer-to-server. 
If we're discussing peer-to-server, then I wonder why we're discussing 
that at all.

> (or to naked destination clients that are not behind a NAT, which
> hopefully will become common once IPv6 gets deployed, but aren't common
> now).

If we eliminate NAT, then we're left with firewalls. To benefit from 
ICE-TCP (i.e. ICE-TCP successfully establishing a peer-to-peer TCP 
connection instead of ICE-UDP falling back on TURN-over-TCP), you would 
need both peers to be behind firewalls that block inbound UDP (through 
hole punching or otherwise) but allow inbound TCP (through simultaneous 
open or otherwise). My personal experience is that this kind of firewall 
configuration would be very rare. Now, take that probability and square 
it since it needs to apply to both peers. You get something very very rare.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From harald@alvestrand.no  Wed Nov 13 11:19:21 2013
Return-Path: 
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 9EEFE11E810D for ; Wed, 13 Nov 2013 11:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.524
X-Spam-Level: 
X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 hbrN8C3S1-vD for ; Wed, 13 Nov 2013 11:19:15 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 77DDD11E8107 for ; Wed, 13 Nov 2013 11:19:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E527039E1AC; Wed, 13 Nov 2013 20:19:13 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW1BxZG0DXUh; Wed, 13 Nov 2013 20:19:13 +0100 (CET)
Received: from [172.30.42.84] (unknown [62.109.39.85]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D530839E176; Wed, 13 Nov 2013 20:19:12 +0100 (CET)
Message-ID: <5283D0AF.70305@alvestrand.no>
Date: Wed, 13 Nov 2013 20:19:11 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Simon Perreault , "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , ext Magnus Westerlund ,  "rtcweb@ietf.org" 
References: <5282391D.3050002@ericsson.com>	<40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net>	<5283291E.7090108@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net> <5283B92B.4080304@viagenie.ca> <5283C8A5.8030601@alvestrand.no> <5283CBA2.3060604@viagenie.ca>
In-Reply-To: <5283CBA2.3060604@viagenie.ca>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 19:19:21 -0000

On 11/13/2013 07:57 PM, Simon Perreault wrote:
> Le 2013-11-13 13:44, Harald Alvestrand a écrit :
>>> All this relies on the possibility that a TCP peer-to-peer connection
>>> could be successfully established where a UDP one couldn't. IMHO this
>>> is very unlikely to happen in practice. So unlikely in fact that any
>>> possible gain over just falling back on a TURN relay wouldn't be worth
>>> the additional implementation cost.
>>
>> Simon, do you have any numbers on that - how many calls will be going to
>> servers on the Internet versus how many calls will be going
>> peer-to-peer?
>
> Not sure what you mean.
>
>> The argument being given only applies to the client-to-gateway usecase
>
> My point only applied to peer-to-peer connections, not peer-to-server.
> If we're discussing peer-to-server, then I wonder why we're discussing
> that at all.

Because we agreed to include server-based systems in section 3.4 of the
use cases and requirements" document?

I think we have WG consensus that client-to-server based use cases,
while less important than browser-to-browser use cases, are still important.

-- 
Surveillance is pervasive. Go Dark.


From Markus.Isomaki@nokia.com  Wed Nov 13 11:49:30 2013
Return-Path: 
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 C50BE11E8136 for ; Wed, 13 Nov 2013 11:49:30 -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 5RU2m+2nR16o for ; Wed, 13 Nov 2013 11:49:24 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id A318311E817E for ; Wed, 13 Nov 2013 11:49:21 -0800 (PST)
Received: from smtp.mgd.nokia.com ([65.54.30.21]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rADJhVwA029040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 13 Nov 2013 21:43:32 +0200
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.74]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.03.0136.001; Wed, 13 Nov 2013 19:43:30 +0000
From: 
To: , , , , 
Thread-Topic: Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
Thread-Index: Ac7gpqENKxnuBO9vSm6c7jmb7Ls8IQ==
Date: Wed, 13 Nov 2013 19:43:30 +0000
Message-ID: 
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: bRtCJmKTkquuTioqIWF0acanolSKdHlEDp6iJ5RAVS6z6QSTlNFlSJz4ki/TmxLqE7EXPyCMrfpRcU9oSaRw+/VYMN+LYcY1FhzjV2/bAjsizBADfHQ+bpwBp3oLG9cp0QA8QqBMlW8Ya/IHQPZtWoFo6NgMcqrnGUgO35mnGQTCgi+aPVHswFH97c/zsYSG/8NSEOhJrAe6KaHBPBe/jSNovrNDfiP4+H1ltQSyYczLJ51cXhEvCPZK6e0Ti5TTA1BB4QlDK50gncSnLkL83unLpXRPU0Vtdi2G9xMcE4w=
x-originating-ip: [10.163.173.36]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 19:49:30 -0000

Hi,

See below.=20

Harald Alvestrand wrote:
>=20
> On 11/13/2013 07:57 PM, Simon Perreault wrote:
> > Le 2013-11-13 13:44, Harald Alvestrand a =E9crit :
> >>> All this relies on the possibility that a TCP peer-to-peer
> >>> connection could be successfully established where a UDP one
> >>> couldn't. IMHO this is very unlikely to happen in practice. So
> >>> unlikely in fact that any possible gain over just falling back on a
> >>> TURN relay wouldn't be worth the additional implementation cost.
> >>
> >> Simon, do you have any numbers on that - how many calls will be going
> >> to servers on the Internet versus how many calls will be going
> >> peer-to-peer?
> >
> > Not sure what you mean.
> >
> >> The argument being given only applies to the client-to-gateway
> >> usecase
> >
> > My point only applied to peer-to-peer connections, not peer-to-server.
> > If we're discussing peer-to-server, then I wonder why we're discussing
> > that at all.
>=20
> Because we agreed to include server-based systems in section 3.4 of the u=
se
> cases and requirements" document?
>=20
> I think we have WG consensus that client-to-server based use cases, while
> less important than browser-to-browser use cases, are still important.
>=20

Right. Some amount of WebRTC endpoints will definitely be gateways or centr=
al entities such as conference servers. I have no idea what portion of sess=
ions would be like that, but I don't it will an insignificant amount since =
there is a lot of interest to gateway WebRTC to various "legacy" VoIP and v=
ideo conferencing systems.  So I think those are important use cases.=20

Typically gateways and conf server endpoints would be reachable by TCP. The=
 question is thus how often a  "normal" (browser or mobile app) endpoint wo=
uld be in a network where UDP is blocked but direct outgoing TCP connection=
s are allowed. In that case ICE-TCP would be optimal way for that endpoint =
to connect with a gateway/server endpoint. TURN over TCP would solve the sa=
me case but is less optimal.

So unless people have data that shows that "UDP blocked but direct TCP allo=
wed" is in itself a very rare setup (this is a question, I don't know that =
either), I think ICE-TCP is definitely worthwhile for a WebRTC endpoint to =
support.=20

TURN (over TCP) will still be needed in many cases involving two "normal" e=
ndpoints, and there I agree ICE-TCP has little success.=20

Regards,
	Markus

From pgiralt@cisco.com  Wed Nov 13 11:54:27 2013
Return-Path: 
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 B6B1611E8107 for ; Wed, 13 Nov 2013 11:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 w3VWrlWTp7vt for ; Wed, 13 Nov 2013 11:54:22 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9253121E8096 for ; Wed, 13 Nov 2013 11:54:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2303; q=dns/txt; s=iport; t=1384372462; x=1385582062; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=tRI2YMOruRZb015KkbJgEZl0nHVqFRhFTrKQymMrlhY=; b=Ask4h6CXQHCOhtOuppkriXFH0AoC5vfGm2oiR3sIka/UNmW7UqnARQx0 2qpWzY+58qsRA9DiLQYnwHqg95wPuBO+lvKv8eE3mE8ZNcDaRzdcQCUS5 2xNNQCz2THG8RDvEJMvDjYMivNeLtWCv7JdfTY2d2WKFCOuXPStOm6RDQ o=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFADXYg1KtJV2a/2dsb2JhbABZgwfAN4EoFnSCJQEBAQMBeQULC0ZXGYd7BsBBj18HFoMKgREDiUKGbodgkguBaoFcHg
X-IronPort-AV: E=Sophos;i="4.93,693,1378857600";  d="asc'?scan'208";a="284434002"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 13 Nov 2013 19:54:20 +0000
Received: from pgiralt-macpro.cisco.com (pgiralt-macpro.cisco.com [10.81.96.60]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rADJsIOD018731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 19:54:19 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_7A4F82AC-8FF5-4E58-8ED0-888B5DDBF19F"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Paul Giralt 
In-Reply-To: 
Date: Wed, 13 Nov 2013 14:54:17 -0500
Message-Id: 
References: 
To: Markus.Isomaki@nokia.com
X-Mailer: Apple Mail (2.1812)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 19:54:27 -0000

--Apple-Mail=_7A4F82AC-8FF5-4E58-8ED0-888B5DDBF19F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


On Nov 13, 2013, at 2:43 PM,  =
 wrote:

> Typically gateways and conf server endpoints would be reachable by =
TCP. The question is thus how often a  "normal" (browser or mobile app) =
endpoint would be in a network where UDP is blocked but direct outgoing =
TCP connections are allowed. In that case ICE-TCP would be optimal way =
for that endpoint to connect with a gateway/server endpoint. TURN over =
TCP would solve the same case but is less optimal.
>=20
> So unless people have data that shows that "UDP blocked but direct TCP =
allowed" is in itself a very rare setup (this is a question, I don't =
know that either), I think ICE-TCP is definitely worthwhile for a WebRTC =
endpoint to support.=20

This is actually a very common firewall configuration for enterprise =
customers. Outbound TCP is allowed but UDP is blocked (even if UDP is =
initiated from the inside).=20

-Paul


--Apple-Mail=_7A4F82AC-8FF5-4E58-8ED0-888B5DDBF19F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJSg9jqAAoJEADWV7cDInKsx1YQAJKD++u9FY1z4NyqUNA8MvM3
onRks/zPTDtkwxBjADOMu2Xf9cKvmLd36z9/4SlcW9JBCM+erZSEsRZG4Q3a0NL2
7PPf4r3JNGqJ5pUhOOxhnw4SYO0sLFj25TM2q7TTAWyS4FQEdVJkOwaLz5YxIrZp
uCIoP9bJomD60qlkUNNDALkPUrXqi/mYYhpvUS9sriKUAHdtbXhFmkm+TLjfTMtx
C7Vlp3QFj8H354wRN0jdt93jO8earItbRfmS0cqxgcqaOjfmEMc32/IFsibBy/rc
XK1gkRa90IYvv4OIhuhnszGa/8YgizMtw4j7FRTqtEhqj509sIFbWZZI13cIjz0v
VUTqUsgKx3J23P0w9ZiDqJbZtCDnXdQX15HVPLylkio7bWgvZ9Mlu1+R5i6bvsgr
KkkkgSp1uZkUC5aQmDsiaap3vQ2OfBs7E3u4rsw2BGltW91lbpLa0WlZ6rU9PhTs
IE1bELO3h+tW6MDV9lYHMnfp2Imtb2CSDib3JWLlL/KYkCi/EsuJ/S/tgN1qB3AW
t3SYYtsbK//f4IaoiHqJ0NV74m71GUU0gBDvU0+hMUdROM4uOB2gP7NH4m/Z07dP
uF+/Z45axiBKdKup4ySn6GrlOOTefiG4JaR15OaAMRpU39nc5SsBmfq8bHeg6U7K
JBNLcKQe5Y0KMDxrYYTA
=MTmd
-----END PGP SIGNATURE-----

--Apple-Mail=_7A4F82AC-8FF5-4E58-8ED0-888B5DDBF19F--

From simon.perreault@viagenie.ca  Wed Nov 13 11:58:25 2013
Return-Path: 
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 A5F5C21E80B2 for ; Wed, 13 Nov 2013 11:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WO6MkYHwNMmL for ; Wed, 13 Nov 2013 11:58:24 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5642511E8107 for ; Wed, 13 Nov 2013 11:58:11 -0800 (PST)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d5d4:b853:2212:f683]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B299F403FF; Wed, 13 Nov 2013 14:58:10 -0500 (EST)
Message-ID: <5283D9D2.5030603@viagenie.ca>
Date: Wed, 13 Nov 2013 14:58:10 -0500
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com, harald@alvestrand.no,  parthasarathi.ravindran@nsn.com, magnus.westerlund@ericsson.com,  rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 19:58:25 -0000

Le 2013-11-13 14:43, Markus.Isomaki@nokia.com a écrit :
> So unless people have data that shows that "UDP blocked but direct TCP allowed" is in itself a very rare setup (this is a question, I don't know that either)

A data point: I was a user on such a network not long ago. It was an 
enterprise network and the enterprise in question is one that regularly 
sends people to IETF meetings. The firewall device (which is of a kind 
that is fairly common in enterprise networks) could not do stateful UDP 
connection tracking, so they just decided to block everything. Outbound 
TCP was allowed.

> I think ICE-TCP is definitely worthwhile for a WebRTC endpoint to support.

I get it now. Yes, for client-server connections, ICE-TCP makes sense. 
For peer-to-peer, not so much.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From Markus.Isomaki@nokia.com  Wed Nov 13 12:00:43 2013
Return-Path: 
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 8A78C11E81A9 for ; Wed, 13 Nov 2013 12:00:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.53
X-Spam-Level: 
X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069,  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 t8Z5SN8CGJAJ for ; Wed, 13 Nov 2013 12:00:36 -0800 (PST)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 80D4921E814A for ; Wed, 13 Nov 2013 12:00:33 -0800 (PST)
Received: from smtp.mgd.nokia.com ([65.54.30.47]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rADJvZ2a013820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 13 Nov 2013 21:57:36 +0200
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.74]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.03.0136.001; Wed, 13 Nov 2013 19:57:34 +0000
From: 
To: 
Thread-Topic: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
Thread-Index: Ac7gpqENKxnuBO9vSm6c7jmb7Ls8IQAA4GOAAAAFGRA=
Date: Wed, 13 Nov 2013 19:57:30 +0000
Message-ID: 
References:  
In-Reply-To: 
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+/nZJb9Kg7IjbYxkZuTg+u6rJVgTLbWM4NbqZfy4gjZMCCssTX82f1DJN+H7L6SrZ1bBWTkVeBlPloXyJJ826tQWiBJZy/FLKyr44pIl3GN2ob/skI021hEvDQBiRVcWsnEc7DVSDuvnaUL+f3UpFYFnXoNhw24VqYYtrQnA70VSG9mOzLwPZb3tgTmWFB+tEs2VdK7Es6l3qzZiLedaIYxd341EDAAFLOuUXex/6lT/pD6cmPk0ibo/e5HM2AqciWKohWfuvreWQKAKUX0J4hJGnO/0y5XXPMu9S3IDK7D+uaFsYHwojV
x-originating-ip: [10.163.173.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 20:00:43 -0000

Hi Paul,

> >
> > So unless people have data that shows that "UDP blocked but direct TCP
> allowed" is in itself a very rare setup (this is a question, I don't know=
 that
> either), I think ICE-TCP is definitely worthwhile for a WebRTC endpoint t=
o
> support.
>=20
> This is actually a very common firewall configuration for enterprise
> customers. Outbound TCP is allowed but UDP is blocked (even if UDP is
> initiated from the inside).
>

Yes. UDP is blocked for sure and so is inbound TCP, so only outbound TCP is=
 usable. However in many enterprises direct outbound TCP is not allowed but=
 connection need to be made via an HTTP proxy. Do you (or someone else) hav=
e an estimate how often *direct* outbound TCP connections actually work?
=20
> -Paul

Markus


From harald@alvestrand.no  Wed Nov 13 12:02:42 2013
Return-Path: 
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 9EF0221E80D2 for ; Wed, 13 Nov 2013 12:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.539
X-Spam-Level: 
X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 VER0hDBcsORu for ; Wed, 13 Nov 2013 12:02:36 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4489011E8107 for ; Wed, 13 Nov 2013 12:02:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D92F539E216 for ; Wed, 13 Nov 2013 21:02:35 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DlDdA9-mw0K for ; Wed, 13 Nov 2013 21:02:35 +0100 (CET)
Received: from [172.30.42.84] (unknown [62.109.39.85]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4CA7739E209 for ; Wed, 13 Nov 2013 21:02:35 +0100 (CET)
Message-ID: <5283DADA.2080806@alvestrand.no>
Date: Wed, 13 Nov 2013 21:02:34 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>
In-Reply-To: <20131113165526.GA13468@verdi>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 20:02:42 -0000

On 11/13/2013 05:55 PM, John Leslie wrote:
>    Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
> IMHO, will achieve consensus for "MUST implement" status. Yes, this
> is a sorry state to find ourselves in. But the marketplace has
> sorted out much worse problems in my memory.
>
>    And I claim that both camps are actually more likely to implement
> (or allow extensions for) the other side's codec if it is _not_ MTI,
> simply because they can back out at the first sign of lawyers.
>
>    I will not go into any details about how VP8 endpoints might talk
> to H.264 endpoints, but I'm _very_ confident ways will be found if
> we actually _publish_ an RFC saying both are "SHOULD implement".

I don't know if many noticed it, but one reason for my fiddling with
devices to show Hangouts working on stage at the meeting was to show
that transcoding is in fact working in real services that people are
using on a day-to-day basis.

Sure, it's not optimal. In fact, it hurts. But it's not the end of the
world either.

-- 
Surveillance is pervasive. Go Dark.


From harald@alvestrand.no  Wed Nov 13 12:22:03 2013
Return-Path: 
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 225B611E8180 for ; Wed, 13 Nov 2013 12:22:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.549
X-Spam-Level: 
X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 UHOr+Y3XnzQA for ; Wed, 13 Nov 2013 12:21:57 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 00CA011E8107 for ; Wed, 13 Nov 2013 12:21:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A32339E216; Wed, 13 Nov 2013 21:21:55 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a92hDRTgbnFA; Wed, 13 Nov 2013 21:21:54 +0100 (CET)
Received: from [172.30.42.84] (unknown [62.109.39.85]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8938F39E209; Wed, 13 Nov 2013 21:21:54 +0100 (CET)
Message-ID: <5283DF61.9060807@alvestrand.no>
Date: Wed, 13 Nov 2013 21:21:53 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" , rai-ads@tools.ietf.org,  tsv-ads@tools.ietf.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 20:22:03 -0000

This mail concerns both administrative and technical issues, which is
why it is explicitly copied to the ADs of RAI and TSV. I hope I have
managed to keep them separate in the message.

Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:

> Okay, we might not have been public enough on this. It was requested by
> the Transport ADs quite some time ago that doing the QoS document in our
> WG was not appropriate and requested us to direct the document to TSVWG.
> Which was done, and where it hasn't made progress.
>
> You might have noted that James Polk did comment in the milestone part
> in the monday session of IETF88 about our QoS milestone should be killed.
I want to protest this - both practically and formally.

To get the formal stuff out of the way first:

Changing the deliverables of the working group *without telling the
working group* is totally inappropriate in an open, consensus-driven
process.
Changing the deliverables of the working group *without telling the
working group why* and *without allowing those reasons to be debated* is
totally inappropriate in an open, consensus-driven process.

I protest against this action.

ACTION REQUEST 1: I request that this decision be declared null and
void, and that the relevant ADs send out a message to RTCWEB (and TSVWG
if appropriate) *PROPOSING* such an action, and giving a reasonable
timeline for when they will make a decision based on mailing list feedback.

In practice:

The draft as it existed before its untimely demise consisted of two things:

- A description of how QoS mechanisms could be useful in the RTCWEB use case
- A description of existing mechanisms that could be appropriate for the
RTCWEB use case

The first one is clearly something that needs RTCWEB consensus. It seems
to have no need for, nor likelyhood of gathering interest enough for, a
TSVWG consensus.

There could be some argument that the second part needs TSVWG consensus,
especially if it was redefining any mechanisms, or it was making choices
between mechanisms where TSVWG had strong opinions about which
mechanisms should be chosen, but had not chosen to document that in any
document on which IETF consensus had been declared (that is to say,
existing RFCs).

My archive shows 36 messages where the title refers to this draft. It
shows no messages declaring that feedback has been incorporated and
calling for new review - something that is usually necessary to get a WG
consensus on any document. The debate hasn't been conclusive, but then,
it hasn't been pushed hard either.

The people who know how RTCWEB works are in this working group. Some of
them may be in TSV, but I think the locus of knowledge for saying what
QoS mechanisms are appropriate for RTCWEB are here, not in TSV.

This results in my second request.

ACTION REQUEST 2: I request that the chairs declare that based on the
debate about the QoS functionality so far, the document should be
resurrected, and will continue to be  worked on in the RTCWEB working
group, bringing in advice from TSVWG as required to make sure the
descriptions of underlying mechanisms, and the choice of such
mechanisms, is correct and appropriate.




-- 
Surveillance is pervasive. Go Dark.


From gonzalo.camarillo@ericsson.com  Wed Nov 13 12:24:08 2013
Return-Path: 
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 AA85B21F9BC1 for ; Wed, 13 Nov 2013 12:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.6
X-Spam-Level: 
X-Spam-Status: No, score=-105.6 tagged_above=-999 required=5 tests=[AWL=0.649,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 9GAJXM-FHi2f for ; Wed, 13 Nov 2013 12:24:02 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A45A511E8107 for ; Wed, 13 Nov 2013 12:23:58 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-d0-5283dfdda618
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A6.EE.23787.DDFD3825; Wed, 13 Nov 2013 21:23:57 +0100 (CET)
Received: from [131.160.126.80] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.2.328.9; Wed, 13 Nov 2013 21:23:57 +0100
Message-ID: <5283DFDC.4010906@ericsson.com>
Date: Wed, 13 Nov 2013 21:23:56 +0100
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+Jvre7d+81BBnfvqlqs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAUv+9gKfrFXLHiynamBcQ5bFyMnh4SAicS1Da+YIWwxiQv3 1gPFuTiEBA4xSpxevYEJwlnDKPHh7ztWkCpeAW2JtyemgXWzCKhKPFlyByzOJmAhseXWfRYQ W1QgSmLD9gssEPWCEidnPgGzRQREJV4/ngZWLyygI7Hq2UkWiM2SEltetLOD2MwCehJTrrYw QtjyEtvfzgG7Tgho7/JnLSwTGPlnIRk7C0nLLCQtCxiZVzGy5yZm5qSXG25iBAbUwS2/dXcw njoncohRmoNFSZz3w1vnICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MJY7zDevfnT+6cptA gvFbe/3e5Gtnzgk0qs/iDVwms0P+hWf5vfgdN61lODwTjv/e+Wj19usGL9q1mfrKWiO5/x9U nq8T0TKh3HbS6QlJ98Irg7YqhRpueCeTPKH+bUjNTdlnmgWB0r+CFh98aFz4c31ExlPXPP8r T7cwMlbGdD3rElgayPJJiaU4I9FQi7moOBEAi1lHd/YBAAA=
Subject: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 20:24:08 -0000

Folks,

I hope everybody had a safe trip back home after Vancouver.

As you all know, we need to make progress regarding the selection of the
MTI video codec. The following are some of the alternatives we have on
the table:

 1. All entities MUST support H.264
 2. All entities MUST support VP8
 3. All entities MUST support both H.264 and VP8
 4. Browsers MUST support both H.264 and VP8
 5. All entities MUST support either H.264 or VP8
 6. All entities MUST support H.261
 7. There is no MTI video codec

If you want the group to consider additional alternatives to the ones
above, please let the group know within the following *two weeks*. At
that point, the chairs will be listing all the received alternatives and
proposing a process to select one among them.

Please, send your proposals in an email to the list. You do not need to
write a draft; just send the text you would like to see in the final
document regarding video codecs.

Thanks,

Gonzalo
Responsible AD for this WG


From ron@debian.org  Wed Nov 13 12:29:04 2013
Return-Path: 
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 19CD111E8120 for ; Wed, 13 Nov 2013 12:29:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
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 22U8624FLZBW for ; Wed, 13 Nov 2013 12:28:59 -0800 (PST)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 64E5D11E8107 for ; Wed, 13 Nov 2013 12:28:59 -0800 (PST)
Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail06.adl6.internode.on.net with ESMTP; 14 Nov 2013 06:58:58 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id BC2944F8F3 for ; Thu, 14 Nov 2013 06:58:53 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zVj8h0WOAZDr for ; Thu, 14 Nov 2013 06:58:52 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id BDC7F4F902; Thu, 14 Nov 2013 06:58:52 +1030 (CST)
Date: Thu, 14 Nov 2013 06:58:52 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20131113202852.GP3245@audi.shelbyville.oz>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131113165526.GA13468@verdi>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 20:29:04 -0000

On Wed, Nov 13, 2013 at 11:55:26AM -0500, John Leslie wrote:
> 
>    Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
> MTI. They probably won't implement it.

I don't understand your logic here?  They've said they are all for future
codecs like Daala that will surely have the same FUD spread about them by
the same few belligerent actors.  How is that any different to the current
status of VP8?

Also: http://www.cisco.com/en/US/prod/collateral/video/ps9901/ps10631/data_sheet_c78-565206_ps12130_Products_Data_Sheet.html

... says it supports WebM.

So "probably won't" looks more like "already have" here.


>    Conversely, of course, "linux" management would _very_much_ prefer
> that H.264 not be MTI. They probably won't implement it.

There is a critical difference between "would prefer" and "cannot licence".

The symmetry you seem to suggest here isn't grounded in reality.
"Don't want to" is not even approximately the same as "have no licence to".


  Ron


From pgiralt@cisco.com  Wed Nov 13 12:29:35 2013
Return-Path: 
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 3A22D11E8107 for ; Wed, 13 Nov 2013 12:29:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 FwNcvXm+Vt5f for ; Wed, 13 Nov 2013 12:29:30 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D5BE811E8179 for ; Wed, 13 Nov 2013 12:29:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3675; q=dns/txt; s=iport; t=1384374570; x=1385584170; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=a/wPFVOcj6XwCmGtzziJuawvUxtYUnmynMmFPetlJXg=; b=UoVu6uCQdtr+MBLexV7pabrkPtjA6kIuvOchldCdEeYOgCC1TzIr4yjs 4uE49ILyL1jDbkHdvpSPAwrvoql7UOmHw5Ds2HNZ2TEOYx/mG0H+4ypJs BjsPxBXzRK2P4bJZCLam9QObyxJpV4rms5lSFp11sYCUr3YsGxUrMCcJ9 I=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFANrgg1KtJXG+/2dsb2JhbABZgwc4v3+BKBZ0giUBAQEDAXkFCwtGVxmHewbAO49fBxaDCoERA4lChm6HYJILgWqBXB4
X-IronPort-AV: E=Sophos;i="4.93,693,1378857600";  d="asc'?scan'208";a="284437146"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 13 Nov 2013 20:29:28 +0000
Received: from pgiralt-macpro.cisco.com (pgiralt-macpro.cisco.com [10.81.96.60]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rADKTPnU017373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 20:29:26 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_8021EE31-83A6-4B99-8105-76C2D7D65E33"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Paul Giralt 
In-Reply-To: 
Date: Wed, 13 Nov 2013 15:29:24 -0500
Message-Id: 
References:   
To: Markus.Isomaki@nokia.com
X-Mailer: Apple Mail (2.1812)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 20:29:35 -0000

--Apple-Mail=_8021EE31-83A6-4B99-8105-76C2D7D65E33
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Nov 13, 2013, at 2:57 PM,  =
 wrote:

> Hi Paul,
>=20
>>>=20
>>> So unless people have data that shows that "UDP blocked but direct =
TCP
>> allowed" is in itself a very rare setup (this is a question, I don't =
know that
>> either), I think ICE-TCP is definitely worthwhile for a WebRTC =
endpoint to
>> support.
>>=20
>> This is actually a very common firewall configuration for enterprise
>> customers. Outbound TCP is allowed but UDP is blocked (even if UDP is
>> initiated from the inside).
>>=20
>=20
> Yes. UDP is blocked for sure and so is inbound TCP, so only outbound =
TCP is usable. However in many enterprises direct outbound TCP is not =
allowed but connection need to be made via an HTTP proxy. Do you (or =
someone else) have an estimate how often *direct* outbound TCP =
connections actually work?

If I had to guess it's a significant number of both cases. There is =
probably a majority (> 50%) overall that allow both TCP and UDP, but at =
least a good 30% are more restrictive to some degree. The very =
security-concious customers (think banks and other financial =
institutions as well as large retailers and even universities) usually =
leverage proxies, but there are also plenty of large enterprises that =
allow TCP but block UDP. In these cases, a direct outbound TCP =
connection would be allowed, at least on a well-known port number (e.g. =
80, 443). I think for the case of ICE-TCP, however, we'd have to also =
think about how many would allow an outbound TCP connection to any =
ephemeral TCP port number.=20

In the past, customers had been more concerned about stopping the bad =
guys from getting in, but not as worried about people on the inside =
getting out. Now customers are becoming increasingly worried about =
compromised hosts leaking information out of the network and are taking =
steps to restrict what kinds of things hosts can do going out, hence I =
think you will see these kinds of restrictions increase, not decrease.=20=


As a data point, Cisco's internal network allows outbound TCP only to =
pretty much any port number but does not allow outbound UDP (and uses =
WCCP to pass HTTP traffic through Ironport transparent web proxies for =
security filtering).=20

-Paul



--Apple-Mail=_8021EE31-83A6-4B99-8105-76C2D7D65E33
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJSg+ElAAoJEADWV7cDInKsEDEP/A2K1uDk0tL+bP6vZvSz+mXK
Qrwzxlo4phyccRe711a6NQChbvnOjw4tNeGQlNwx5wAO4v0YJ9ZPNe1hzAtacHcs
E3e8cT61h3KwzT6FshxfcTZ8H79REeRsfmrvTSKTQBnufohFJmu/W5fzoUvmiGRm
jT5nVpCuUjZobfp5iwNFdBmi7xTcGXg/ypA0rOxZYSxU6a9WXBmDRjMsNCVZCbAn
yqaZwDI31AmdD60msiKY14liFnx+S8jKKJ8q2LchOc3r/kq43E7jY/bnxYO00sqD
vt3neFVSmUgmgsSMzWfLJ+8Q94mjbZFGZRaEZL/A+y0TOzh1JDko4rKoOyF6aUrw
BfHR+fyJj6IR9cL5runDIumrKOWzPZ8F/kvkP1WD13ZTpGiiB6kpC4+h+BDm2h8F
qYbgLsY4t/obbfX3XwIdptUZzIeVm7PdDQekmHNPxOkV0afLW18JpnV8NzXWHkoR
K0lrysxhM2FORA4KLeJEkKrGXVNhmWwckJ8fP1/LQwVrc99BW5Tm2g5J99k5Dp7q
40JGE9n9KdxA0O/ktivYAUFdeaDMlj5+XOXsNpbjROnbQt3nxUDBlyLbE8kKWxqE
Z/k1SnysUsGfqXNeMagMQMvRpluukdSyVatV4yzxvtjloF3fY7DQey20H5z4mpeG
RHfZ4tlAdCqKYup/HAII
=jz7q
-----END PGP SIGNATURE-----

--Apple-Mail=_8021EE31-83A6-4B99-8105-76C2D7D65E33--

From cowwoc@bbs.darktech.org  Wed Nov 13 12:47:04 2013
Return-Path: 
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 C230221E80B3 for ; Wed, 13 Nov 2013 12:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level: 
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[AWL=-0.591,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 manthjoa2nru for ; Wed, 13 Nov 2013 12:46:58 -0800 (PST)
Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id CA02C21F9F74 for ; Wed, 13 Nov 2013 12:46:55 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id to1so1378550ieb.1 for ; Wed, 13 Nov 2013 12:46:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nlgCft2lL+k3KsR47bTnlB5I6TX1Krioef3UT/O0IA0=; b=kMq3rvlqf7A04P6+iG1L0zk83xJEy6F86HDoE1PGQTlbeJi8HqVReJQeWlAKAIC9zy Or9tN/NX4LjTjdqHwqHVuvVQnd7qpVGHyxIWkV2xH/ky4cEvyReeONf06MaYdqTC5aTw v4F38mCnxw01uxmQb0tv9J3UH1liT5fKwnYUszXaYMklXE5goa6Hgd2ExIwj9BBrULbr QCfe1vUM4DQ7WapNPsKmLrSU9igziSpg2b81YgrRmFYI36RiWYyMLdp+q25F9mLOi7nI yuJMhiybe8zxK0BJhTaXseVMcIaEUcs9qaYMuQ5n131D1skHG1l08Nueqj6BhsaJmUKN Pkxw==
X-Gm-Message-State: ALoCoQkwFuONQUB/ISaPf2BweOx0L3xbHTlaz/jRTo1ZiRID3SgululZbAOGplu7SD3RlsIacBwU
X-Received: by 10.50.73.74 with SMTP id j10mr19546017igv.50.1384375615348; Wed, 13 Nov 2013 12:46:55 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id w4sm32097977igb.5.2013.11.13.12.46.54 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 12:46:54 -0800 (PST)
Message-ID: <5283E52D.7020007@bbs.darktech.org>
Date: Wed, 13 Nov 2013 15:46:37 -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: rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com>
In-Reply-To: <5283DFDC.4010906@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 20:47:04 -0000

Hi Gonzalo,

I like your proposal, except for #4. I believe that for this to work, 
all entities must follow the same rules, not just the browsers.

Can the person who proposed #4 please explain the reasoning behind it?

Thanks,
Gili

On 13/11/2013 3:23 PM, Gonzalo Camarillo wrote:
> Folks,
>
> I hope everybody had a safe trip back home after Vancouver.
>
> As you all know, we need to make progress regarding the selection of the
> MTI video codec. The following are some of the alternatives we have on
> the table:
>
>   1. All entities MUST support H.264
>   2. All entities MUST support VP8
>   3. All entities MUST support both H.264 and VP8
>   4. Browsers MUST support both H.264 and VP8
>   5. All entities MUST support either H.264 or VP8
>   6. All entities MUST support H.261
>   7. There is no MTI video codec
>
> If you want the group to consider additional alternatives to the ones
> above, please let the group know within the following *two weeks*. At
> that point, the chairs will be listing all the received alternatives and
> proposing a process to select one among them.
>
> Please, send your proposals in an email to the list. You do not need to
> write a draft; just send the text you would like to see in the final
> document regarding video codecs.
>
> Thanks,
>
> Gonzalo
> Responsible AD for this WG
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From cowwoc@bbs.darktech.org  Wed Nov 13 12:47:11 2013
Return-Path: 
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 69FBF11E8136 for ; Wed, 13 Nov 2013 12:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.18
X-Spam-Level: 
X-Spam-Status: No, score=-4.18 tagged_above=-999 required=5 tests=[AWL=-0.581,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 wKv2l4MaMrlz for ; Wed, 13 Nov 2013 12:47:04 -0800 (PST)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDCB21F9FF3 for ; Wed, 13 Nov 2013 12:46:59 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id ar20so1333279iec.19 for ; Wed, 13 Nov 2013 12:46:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aDtMyyVtio/iQp6tsVcsiXi4WFke5G+TGEpheTE0GUg=; b=TI2aOSda2kvkycTApFKe4y3iwDpLEvTwjZ56UXp0O4W75hSrwN2dEphPgTR8/74iGX eFHXawxsdBZyapFkK3J5r4ZBiRIsnkNuHYFeh0Q+/BhiTqUTuL83OSxmLI8+gTYOnrBH xgTpcKERHhIf4lF6TT2BCMBHuCnJG3q5xGyhs3Xuv2DK2OYQ/7cjp40E0mhl9eUU+67u vQs1td9Yu8Opu0CuNEP+Ega39tJRMjBg3AuGWrffBOFAN8PRGlRjM0pnoVBGslzUK1Bk mDKFN4A7TYaTnlaBEeI0ZjNFg9Si3qPWcgTMTUwVrSFd+QaxonLLh9qJ/gjyuAl5SrJN K7tA==
X-Gm-Message-State: ALoCoQlWXKeqFfjRBWsGosxK1YUUZ10wZ6zwgftIjiKfMU6FyM8HJU09NyXVz8ylLxELB9rMqTRI
X-Received: by 10.50.30.229 with SMTP id v5mr19775774igh.27.1384375618831; Wed, 13 Nov 2013 12:46:58 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f5sm32078854igc.4.2013.11.13.12.46.57 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 12:46:58 -0800 (PST)
Message-ID: <5283E530.8000409@bbs.darktech.org>
Date: Wed, 13 Nov 2013 15:46:40 -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: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283DADA.2080806@alvestrand.no>
In-Reply-To: <5283DADA.2080806@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 20:47:11 -0000

On 13/11/2013 3:02 PM, Harald Alvestrand wrote:
> On 11/13/2013 05:55 PM, John Leslie wrote:
>>     Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
>> IMHO, will achieve consensus for "MUST implement" status. Yes, this
>> is a sorry state to find ourselves in. But the marketplace has
>> sorted out much worse problems in my memory.
>>
>>     And I claim that both camps are actually more likely to implement
>> (or allow extensions for) the other side's codec if it is _not_ MTI,
>> simply because they can back out at the first sign of lawyers.
>>
>>     I will not go into any details about how VP8 endpoints might talk
>> to H.264 endpoints, but I'm _very_ confident ways will be found if
>> we actually _publish_ an RFC saying both are "SHOULD implement".
> I don't know if many noticed it, but one reason for my fiddling with
> devices to show Hangouts working on stage at the meeting was to show
> that transcoding is in fact working in real services that people are
> using on a day-to-day basis.
>
> Sure, it's not optimal. In fact, it hurts. But it's not the end of the
> world either.

So... we're throwing P2P out of WebRTC?

If you mandate H.261 as MTI, big business can still do transcoding and 
the rest of us can use H.261. Small business shouldn't have to choose 
between transcoding and dropping the call.

Gili

From cowwoc@bbs.darktech.org  Wed Nov 13 12:54:49 2013
Return-Path: 
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 2215021E80CA for ; Wed, 13 Nov 2013 12:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.17
X-Spam-Level: 
X-Spam-Status: No, score=-4.17 tagged_above=-999 required=5 tests=[AWL=-0.571,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 vfaPl7L6uOKw for ; Wed, 13 Nov 2013 12:54:44 -0800 (PST)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 005C721E80C3 for ; Wed, 13 Nov 2013 12:54:43 -0800 (PST)
Received: by mail-ob0-f182.google.com with SMTP id wp18so1141650obc.13 for ; Wed, 13 Nov 2013 12:54:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=s8ocNr+EgSbI2p0nUppiH30wsUqb9W6tuNWHU37nQk0=; b=JfcRtrL2yt4vaIGjkhQ63guzOSs49ZLB4zDeYZGoaCQ/wj9ZotB30yvltts45NAAhI HDgBcis1N9UGlyDbfftqh2Gi+ZfK5/9sUfPBy3kk9ui1pOeOwsJ11DOYoVGdmjMKRoF9 1OqDWcoztVvdfOcA4NbyrB6nw5D9vHvzpB2BwOFbEYokggWj56nz+UWh3lVj44zxnBoq hxTmpK+4KUeNPoZ0ZxZG3HW/19a29sjs9japk+QNISFzD3VnCCj1v/Tmvd0YEGVWHeQg 5/vAJ/TwXuyrTiEYxVRdqF5sCgFUb6hCkzdtRCW8ZhIX/kxaOqQDHtnBMEQZ+I7LdKtZ 22IA==
X-Gm-Message-State: ALoCoQnafVcA/IqEk/woHsVJbP68hDUJ5yLgafQQpgRoQZDrmgtD/kIIIBlhAoqpgHhKN++TAitC
X-Received: by 10.182.92.138 with SMTP id cm10mr2958716obb.95.1384376083083; Wed, 13 Nov 2013 12:54:43 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id s9sm919633obu.4.2013.11.13.12.54.41 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 12:54:42 -0800 (PST)
Message-ID: <5283E700.5090300@bbs.darktech.org>
Date: Wed, 13 Nov 2013 15:54:24 -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: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>
In-Reply-To: <20131113165526.GA13468@verdi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 20:54:49 -0000

Hi John,

First, thanks for summarize the positions brought up in the meeting.

A few weeks ago I advocated making both H.264 and VP8 MTI with the 
reasoning that if an implementer gets sued they can simply drop the 
codec, notify the community, and have that codec removed en-mass from 
the specification. A few months later we would replace it with another 
MTI codec. According to what you wrote above, Cisco is under the 
impression that once a codec is MTI they cannot drop it even if they get 
sued.

Practically speaking, is that really true? I mean, if the specification 
requires everyone to implement both VP8 and H.264 and one implementer 
temporarily drops one of the codecs, shouldn't things keep on working 
until the lawsuit is over (codec returns) or the community replaces the 
codec with another?

Thanks,
Gili

On 13/11/2013 11:55 AM, John Leslie wrote:
> Mike Linksvayer  wrote:
>> I strongly support VP8 for MTI, and oppose H.264. Undecided on which
>> of both, either, or neither would be second best.
>     I'm _very_ glad you care which is "second best!"
>
>     I went into last week's session quite prepared to accept either, both
> or neither. I came out unwilling to support _either_ as MTI.
>
>     This is mostly because I came to understand the "cisco" postition.
>
>     (Please excuse me for assigning names to the two main positions, but
> it will make the discussion _much_ simpler.)
>
>     The "cisco" position is:
>
> - look at all the H.264 hardware out there: we must make use of it;
> - if VP8 is MTI, we'll get sued and our customers will get hassled.
>
>     The "linux" position is:
>
> - look at all the VP8 software out there: we must make use of it;
> - if H.264 is MTI, we'll get sued and our customers will get hassled.
>
>     And, alas, they're both right.
>
>     What I didn't understand before the presentations was why Cisco
> believes they'll get sued over VP8, but not H.264.
>
>     Basically H.264 has quite a consortium to slap down the likes of
> Nokia in court should they sue anyone in the consortium. This greatly
> reduces the chance of Nokia's lawyer suing.
>
>     But this consortium won't lift a finger if Nokia sues Cisco over
> VP8. Cisco is a _very_ attractive target over VP8.
>
>     Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
> MTI. They probably won't implement it.
>
>     Conversely, of course, "linux" management would _very_much_ prefer
> that H.264 not be MTI. They probably won't implement it.
>
>     Understanding this, I now strongly recommend against making either
> H.264 or VP8 MTI. (And I will not consent to a RFC 3929 process limited
> to choosing between them.)
>
>     This issue has dragged on long enough already. We need to start
> reading the riot act to the folks who claim we "need" either of these
> as MTI in order to have "satisfied" users.
>
>     Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
> IMHO, will achieve consensus for "MUST implement" status. Yes, this
> is a sorry state to find ourselves in. But the marketplace has
> sorted out much worse problems in my memory.
>
>     And I claim that both camps are actually more likely to implement
> (or allow extensions for) the other side's codec if it is _not_ MTI,
> simply because they can back out at the first sign of lawyers.
>
>     I will not go into any details about how VP8 endpoints might talk
> to H.264 endpoints, but I'm _very_ confident ways will be found if
> we actually _publish_ an RFC saying both are "SHOULD implement".
>
>     (Surely I'm not the _only_ person who'd like to see _both_ H.264
> and VP8 legacy devices using our standard...)
>
> --
> John Leslie 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From kaiduanx@gmail.com  Wed Nov 13 13:57:16 2013
Return-Path: 
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 7BDC111E810A for ; Wed, 13 Nov 2013 13:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Level: 
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 1pDTK4+4Mg2E for ; Wed, 13 Nov 2013 13:57:15 -0800 (PST)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id EF41E21E80E3 for ; Wed, 13 Nov 2013 13:57:14 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id u57so570402wes.23 for ; Wed, 13 Nov 2013 13:57:14 -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=2AF5F5BptXfcgUqHSElxF81ZCSGqD8FY/2pSXHS5MQ8=; b=tr/BrIMO6SVt4w3iz276Eal4cwqrxU6SLiPaxNAUbh/rwJi70pFmsUXHk/tv84D6at TznuBI6E1L7XcIOlQoWjWG3iobLSIhChH8f0LowhxNxbjIh3gOZfcYr/o1sIvFzp3x82 4wV9cAtAgvQtukRrOZwxDpTtVJ+oOxZfiZajAoKdUyPS+gllS9dtomgaa4L14RBvkz1k utGmVKM/K9l+KDybHh+WvCVAc3o6ybzPAJ/Dl8Td7jvKjHB2uwhNT/bDHZr6y8QY/4Ps oM2TYZLslxFyvFDNLQIS8WnxC4G6EgnmGhUSkshe9DGHRkSdq8e417Zlm2YhgqMq2fNE BL4A==
MIME-Version: 1.0
X-Received: by 10.194.205.37 with SMTP id ld5mr2044525wjc.67.1384379834236; Wed, 13 Nov 2013 13:57:14 -0800 (PST)
Received: by 10.216.183.202 with HTTP; Wed, 13 Nov 2013 13:57:14 -0800 (PST)
In-Reply-To: <5283E700.5090300@bbs.darktech.org>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283E700.5090300@bbs.darktech.org>
Date: Wed, 13 Nov 2013 16:57:14 -0500
Message-ID: 
From: Kaiduan Xie 
To: cowwoc 
Content-Type: multipart/alternative; boundary=047d7bb70c5841050304eb160ca9
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 21:57:17 -0000

--047d7bb70c5841050304eb160ca9
Content-Type: text/plain; charset=ISO-8859-1

"if an implementer gets sued they can simply drop the codec"

Thing is not that simple as "simply drop the codec", for some case you
still have to pay a lot of money.

/Kaiduan


On Wed, Nov 13, 2013 at 3:54 PM, cowwoc  wrote:

> Hi John,
>
> First, thanks for summarize the positions brought up in the meeting.
>
> A few weeks ago I advocated making both H.264 and VP8 MTI with the
> reasoning that if an implementer gets sued they can simply drop the codec,
> notify the community, and have that codec removed en-mass from the
> specification. A few months later we would replace it with another MTI
> codec. According to what you wrote above, Cisco is under the impression
> that once a codec is MTI they cannot drop it even if they get sued.
>
> Practically speaking, is that really true? I mean, if the specification
> requires everyone to implement both VP8 and H.264 and one implementer
> temporarily drops one of the codecs, shouldn't things keep on working until
> the lawsuit is over (codec returns) or the community replaces the codec
> with another?
>
> Thanks,
> Gili
>
>
> On 13/11/2013 11:55 AM, John Leslie wrote:
>
>> Mike Linksvayer  wrote:
>>
>>> I strongly support VP8 for MTI, and oppose H.264. Undecided on which
>>> of both, either, or neither would be second best.
>>>
>>     I'm _very_ glad you care which is "second best!"
>>
>>     I went into last week's session quite prepared to accept either, both
>> or neither. I came out unwilling to support _either_ as MTI.
>>
>>     This is mostly because I came to understand the "cisco" postition.
>>
>>     (Please excuse me for assigning names to the two main positions, but
>> it will make the discussion _much_ simpler.)
>>
>>     The "cisco" position is:
>>
>> - look at all the H.264 hardware out there: we must make use of it;
>> - if VP8 is MTI, we'll get sued and our customers will get hassled.
>>
>>     The "linux" position is:
>>
>> - look at all the VP8 software out there: we must make use of it;
>> - if H.264 is MTI, we'll get sued and our customers will get hassled.
>>
>>     And, alas, they're both right.
>>
>>     What I didn't understand before the presentations was why Cisco
>> believes they'll get sued over VP8, but not H.264.
>>
>>     Basically H.264 has quite a consortium to slap down the likes of
>> Nokia in court should they sue anyone in the consortium. This greatly
>> reduces the chance of Nokia's lawyer suing.
>>
>>     But this consortium won't lift a finger if Nokia sues Cisco over
>> VP8. Cisco is a _very_ attractive target over VP8.
>>
>>     Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
>> MTI. They probably won't implement it.
>>
>>     Conversely, of course, "linux" management would _very_much_ prefer
>> that H.264 not be MTI. They probably won't implement it.
>>
>>     Understanding this, I now strongly recommend against making either
>> H.264 or VP8 MTI. (And I will not consent to a RFC 3929 process limited
>> to choosing between them.)
>>
>>     This issue has dragged on long enough already. We need to start
>> reading the riot act to the folks who claim we "need" either of these
>> as MTI in order to have "satisfied" users.
>>
>>     Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
>> IMHO, will achieve consensus for "MUST implement" status. Yes, this
>> is a sorry state to find ourselves in. But the marketplace has
>> sorted out much worse problems in my memory.
>>
>>     And I claim that both camps are actually more likely to implement
>> (or allow extensions for) the other side's codec if it is _not_ MTI,
>> simply because they can back out at the first sign of lawyers.
>>
>>     I will not go into any details about how VP8 endpoints might talk
>> to H.264 endpoints, but I'm _very_ confident ways will be found if
>> we actually _publish_ an RFC saying both are "SHOULD implement".
>>
>>     (Surely I'm not the _only_ person who'd like to see _both_ H.264
>> and VP8 legacy devices using our standard...)
>>
>> --
>> John Leslie 
>> _______________________________________________
>> 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
>

--047d7bb70c5841050304eb160ca9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


"if an implementer gets sued they can simply drop th=
e codec"



Thing is not that simple as "simply drop the codec&=
quot;, for some case you still have to pay a lot of money.


/Kaiduan


On We=
d, Nov 13, 2013 at 3:54 PM, cowwoc <cowwoc@bbs.darktech.org><=
/span> wrote:


Hi John,



First, thanks for summarize the positions brought up in the meeting.



A few weeks ago I advocated making both H.264 and VP8 MTI with the reasonin=
g that if an implementer gets sued they can simply drop the codec, notify t=
he community, and have that codec removed en-mass from the specification. A=
 few months later we would replace it with another MTI codec. According to =
what you wrote above, Cisco is under the impression that once a codec is MT=
I they cannot drop it even if they get sued.




Practically speaking, is that really true? I mean, if the specification req=
uires everyone to implement both VP8 and H.264 and one implementer temporar=
ily drops one of the codecs, shouldn't things keep on working until the=
 lawsuit is over (codec returns) or the community replaces the codec with a=
nother?




Thanks,

Gili




On 13/11/2013 11:55 AM, John Leslie wrote:



Mike Linksvayer <ml@gondwanaland.com> wrote:



I strongly support VP8 for MTI, and oppose H.264. Undecided on which

of both, either, or neither would be second best.



=A0 =A0 I'm _very_ glad you care which is "second best!"



=A0 =A0 I went into last week's session quite prepared to accept either=
, both

or neither. I came out unwilling to support _either_ as MTI.



=A0 =A0 This is mostly because I came to understand the "cisco" p=
ostition.



=A0 =A0 (Please excuse me for assigning names to the two main positions, bu=
t

it will make the discussion _much_ simpler.)



=A0 =A0 The "cisco" position is:



- look at all the H.264 hardware out there: we must make use of it;

- if VP8 is MTI, we'll get sued and our customers will get hassled.



=A0 =A0 The "linux" position is:



- look at all the VP8 software out there: we must make use of it;

- if H.264 is MTI, we'll get sued and our customers will get hassled.


=A0 =A0 And, alas, they're both right.



=A0 =A0 What I didn't understand before the presentations was why Cisco=


believes they'll get sued over VP8, but not H.264.



=A0 =A0 Basically H.264 has quite a consortium to slap down the likes of
Nokia in court should they sue anyone in the consortium. This greatly

reduces the chance of Nokia's lawyer suing.



=A0 =A0 But this consortium won't lift a finger if Nokia sues Cisco ove=
r

VP8. Cisco is a _very_ attractive target over VP8.



=A0 =A0 Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
MTI. They probably won't implement it.



=A0 =A0 Conversely, of course, "linux" management would _very_muc=
h_ prefer

that H.264 not be MTI. They probably won't implement it.



=A0 =A0 Understanding this, I now strongly recommend against making either<=
br>
H.264 or VP8 MTI. (And I will not consent to a RFC 3929 process limited

to choosing between them.)



=A0 =A0 This issue has dragged on long enough already. We need to start

reading the riot act to the folks who claim we "need" either of t=
hese

as MTI in order to have "satisfied" users.



=A0 =A0 Both H.264 and VP8 deserve "SHOULD implement" status. Nei=
ther,

IMHO, will achieve consensus for "MUST implement" status. Yes, th=
is

is a sorry state to find ourselves in. But the marketplace has

sorted out much worse problems in my memory.



=A0 =A0 And I claim that both camps are actually more likely to implement
(or allow extensions for) the other side's codec if it is _not_ MTI,
simply because they can back out at the first sign of lawyers.



=A0 =A0 I will not go into any details about how VP8 endpoints might talk
to H.264 endpoints, but I'm _very_ confident ways will be found if

we actually _publish_ an RFC saying both are "SHOULD implement".<=
br>


=A0 =A0 (Surely I'm not the _only_ person who'd like to see _both_ =
H.264

and VP8 legacy devices using our standard...)



--

John Leslie <john@jlc.=
net>

_______________________________________________

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





--047d7bb70c5841050304eb160ca9--

From jmpolk@cisco.com  Wed Nov 13 14:11:41 2013
Return-Path: 
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 8991E21E8178 for ; Wed, 13 Nov 2013 14:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.557
X-Spam-Level: 
X-Spam-Status: No, score=-110.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 pKArAuFV3eLD for ; Wed, 13 Nov 2013 14:11:37 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0062C21F9F77 for ; Wed, 13 Nov 2013 14:11:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4720; q=dns/txt; s=iport; t=1384380697; x=1385590297; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=EXRNNDx0Tlus2iqGM2mjtZV+Vm04/QhGEyuTjZ0Fyt8=; b=HkDD3bVx0pT6YFHCErUnd9rjEw8J+B/qtjOaHWjVQ7sKLhzwLEob1ux5 YSBWIgt+vhydmH35oJ4rzMMVy0xiVKDY43YsfVTGU6tIhzHK8namWipdy y3B0gu3l1En6xxR8BkQO5yCbPWdxO+7woO/vNK1V5xDq2w6IYE8iI5aAq c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAEb4g1KtJXHA/2dsb2JhbABZgwc4vzRLgSgWdIIlAQEBBAEBARobAjQLEAcEGAkVEA8KDjAGE4gBDcAdBI4WEIE5B4MggREDiUKgWYNHHYE1
X-IronPort-AV: E=Sophos;i="4.93,695,1378857600"; d="scan'208";a="284440942"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 13 Nov 2013 22:11:36 +0000
Received: from jmpolk-WS.cisco.com ([10.89.12.165]) (authenticated bits=0) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rADMBaBD011692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Nov 2013 22:11:36 GMT
Message-Id: <201311132211.rADMBaBD011692@rcdn-core2-5.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 13 Nov 2013 16:11:36 -0600
To: Harald Alvestrand 
From: James Polk 
In-Reply-To: <5283DF61.9060807@alvestrand.no>
References: <5283DF61.9060807@alvestrand.no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Authenticated-User: jmpolk
Cc: rai-ads@tools.ietf.org, "rtcweb@ietf.org" , tsv-ads@tools.ietf.org
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 22:11:41 -0000

I, speaking at the mic, was merely pointing out that this draft had 
moved to TSVWG back in the Atlanta timeframe (though, thinking back, 
I think I left the timing piece out of my comment), so it wasn't a 
recent decision. I believe this came directly from talks between the 
above mentioned ADs.

As for RTCweb work being more appropriately inside the RTBweb WG 
instead of another group, I'd like to point out that much of the SDP 
work related to this WG is in fact being done in MMUSIC. Much of the 
RTP work being done by this WG is being done in AVTCORE (or AVTEXT?). 
All of the base SCTP work being done by this WG is being done in TSVWG.

(this is not an attack, but...)

...why are you arguing for something as far away down the stack as 
DSCP assignments to be done in RTCweb, and not where all other 
DiffServ work is being done in the IETF (in TSVWG)? Do you not trust 
that TSVWG will do an appropriate just with a DiffServ ID but you 
will trust TSVWG with SCTP IDs?

Color me confused...

James

BTW - Full disclosure, I'm an listed author of this draft, but had no 
voice in it getting moved between the WGs.

At 02:21 PM 11/13/2013, Harald Alvestrand wrote:
>This mail concerns both administrative and technical issues, which is
>why it is explicitly copied to the ADs of RAI and TSV. I hope I have
>managed to keep them separate in the message.
>
>Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:
>
> > Okay, we might not have been public enough on this. It was requested by
> > the Transport ADs quite some time ago that doing the QoS document in our
> > WG was not appropriate and requested us to direct the document to TSVWG.
> > Which was done, and where it hasn't made progress.
> >
> > You might have noted that James Polk did comment in the milestone part
> > in the monday session of IETF88 about our QoS milestone should be killed.
>I want to protest this - both practically and formally.
>
>To get the formal stuff out of the way first:
>
>Changing the deliverables of the working group *without telling the
>working group* is totally inappropriate in an open, consensus-driven
>process.
>Changing the deliverables of the working group *without telling the
>working group why* and *without allowing those reasons to be debated* is
>totally inappropriate in an open, consensus-driven process.
>
>I protest against this action.
>
>ACTION REQUEST 1: I request that this decision be declared null and
>void, and that the relevant ADs send out a message to RTCWEB (and TSVWG
>if appropriate) *PROPOSING* such an action, and giving a reasonable
>timeline for when they will make a decision based on mailing list feedback.
>
>In practice:
>
>The draft as it existed before its untimely demise consisted of two things:
>
>- A description of how QoS mechanisms could be useful in the RTCWEB use case
>- A description of existing mechanisms that could be appropriate for the
>RTCWEB use case
>
>The first one is clearly something that needs RTCWEB consensus. It seems
>to have no need for, nor likelyhood of gathering interest enough for, a
>TSVWG consensus.
>
>There could be some argument that the second part needs TSVWG consensus,
>especially if it was redefining any mechanisms, or it was making choices
>between mechanisms where TSVWG had strong opinions about which
>mechanisms should be chosen, but had not chosen to document that in any
>document on which IETF consensus had been declared (that is to say,
>existing RFCs).
>
>My archive shows 36 messages where the title refers to this draft. It
>shows no messages declaring that feedback has been incorporated and
>calling for new review - something that is usually necessary to get a WG
>consensus on any document. The debate hasn't been conclusive, but then,
>it hasn't been pushed hard either.
>
>The people who know how RTCWEB works are in this working group. Some of
>them may be in TSV, but I think the locus of knowledge for saying what
>QoS mechanisms are appropriate for RTCWEB are here, not in TSV.
>
>This results in my second request.
>
>ACTION REQUEST 2: I request that the chairs declare that based on the
>debate about the QoS functionality so far, the document should be
>resurrected, and will continue to be  worked on in the RTCWEB working
>group, bringing in advice from TSVWG as required to make sure the
>descriptions of underlying mechanisms, and the choice of such
>mechanisms, is correct and appropriate.
>
>
>
>
>--
>Surveillance is pervasive. Go Dark.
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb


From stewe@stewe.org  Wed Nov 13 14:17:28 2013
Return-Path: 
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 8402C21E8181 for ; Wed, 13 Nov 2013 14:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level: 
X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=0.803,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 anR57bwVeMeD for ; Wed, 13 Nov 2013 14:17:21 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id CF24E21E808A for ; Wed, 13 Nov 2013 14:17:19 -0800 (PST)
Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 13 Nov 2013 22:17:09 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.167]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.167]) with mapi id 15.00.0785.001; Wed, 13 Nov 2013 22:17:08 +0000
From: Stephan Wenger 
To: Gonzalo Camarillo , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Video codec selection - way forward
Thread-Index: AQHO4K5Rz+wX6FYb/UKirjPpKIT5XZojNKuA
Date: Wed, 13 Nov 2013 22:17:07 +0000
Message-ID: 
In-Reply-To: <5283DFDC.4010906@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [24.5.171.95]
x-forefront-prvs: 0029F17A3F
x-forefront-antispam-report: SFV:NSPM; SFS:(164054003)(51704005)(24454002)(189002)(199002)(81816001)(81342001)(46102001)(36756003)(83072001)(80976001)(51856001)(19580405001)(19580395003)(83322001)(53806001)(54356001)(2656002)(87936001)(85306002)(69226001)(81542001)(31966008)(74706001)(74662001)(74876001)(47446002)(74502001)(74366001)(56776001)(63696002)(54316002)(77096001)(79102001)(56816003)(50986001)(77982001)(4396001)(81686001)(76796001)(59766001)(76482001)(66066001)(76176001)(65816001)(80022001)(76786001)(47736001)(561944002)(87266001)(47976001)(49866001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB363; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:24.5.171.95; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en; 
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 22:17:28 -0000

Hi Gonzalo,=20
Re your point 5.: =B3either or=B2 is often understood as an exclusive or.  =
I
don=B9t think anyone proposed that.  A better way to express 5. would be
=B3All entities MUST support at least one of H.264 and VP8=B2.
Stephan

On 11.13.2013, 12:23 , "Gonzalo Camarillo"
 wrote:

>Folks,
>
>I hope everybody had a safe trip back home after Vancouver.
>
>As you all know, we need to make progress regarding the selection of the
>MTI video codec. The following are some of the alternatives we have on
>the table:
>
> 1. All entities MUST support H.264
> 2. All entities MUST support VP8
> 3. All entities MUST support both H.264 and VP8
> 4. Browsers MUST support both H.264 and VP8
> 5. All entities MUST support either H.264 or VP8
> 6. All entities MUST support H.261
> 7. There is no MTI video codec
>
>If you want the group to consider additional alternatives to the ones
>above, please let the group know within the following *two weeks*. At
>that point, the chairs will be listing all the received alternatives and
>proposing a process to select one among them.
>
>Please, send your proposals in an email to the list. You do not need to
>write a draft; just send the text you would like to see in the final
>document regarding video codecs.
>
>Thanks,
>
>Gonzalo
>Responsible AD for this WG
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb


From cowwoc@bbs.darktech.org  Wed Nov 13 14:32:43 2013
Return-Path: 
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 8FA5411E81A3 for ; Wed, 13 Nov 2013 14:32:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.16
X-Spam-Level: 
X-Spam-Status: No, score=-4.16 tagged_above=-999 required=5 tests=[AWL=-0.562,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 WqpLE99vuUYN for ; Wed, 13 Nov 2013 14:32:37 -0800 (PST)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 91C3C21E8091 for ; Wed, 13 Nov 2013 14:32:37 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id u16so1490926iet.6 for ; Wed, 13 Nov 2013 14:32:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=nvUxxQxhsxVdkP3hr/5AdKeTB0VR986NUEOOc/scZGQ=; b=OjtxRILVU2n6/26H/fry114o+l3OmXZu5gfye7vGFEjKHjGQehTWgtYoge5IR/2wgC laUHmrXWb239Puy7Z1IhQpNZbPoQu9GkDDOi6+i4RnVmDbO9/DegAeP70kKbhfgC2mXc 55EBLRnQdwNlpBj36dd819EWiR+JoIgevaaIHExD6yu6B7RTVsZJDk5svbpS69FQRv/q PpTfqzFQkbd4Kc39LzpU3M3mUw+iCymO3TVt03NZ7nIKNefyVfu0vW2BRbf6y05orGI4 VOTz2RocuHGfwAkF2v1r8gVM1w/VFZ+udrNhuII6sCHbYeEVtJVQGcjB+hajFsK1KAcs FyCg==
X-Gm-Message-State: ALoCoQlvZKWTMTqINkgAXBCP+X30xtThVy48Owx9QOzqT3dgoPT+3LqK2LVBaY9bf2h3zMwi3yuk
X-Received: by 10.50.111.74 with SMTP id ig10mr17808575igb.56.1384381957149; Wed, 13 Nov 2013 14:32:37 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id j16sm32587713igf.6.2013.11.13.14.32.35 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 14:32:36 -0800 (PST)
Message-ID: <5283FDF1.8030708@bbs.darktech.org>
Date: Wed, 13 Nov 2013 17:32:17 -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: Kaiduan Xie 
References: <5282A340.7010405@gondwanaland.com>	<20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070601090607040309040306"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 22:32:43 -0000

This is a multi-part message in MIME format.
--------------070601090607040309040306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


I agree. I'm just pointing out that John's argument (quoted below) 
doesn't make any sense. Choosing "no MTI" doesn't make Cisco any more 
likely to implement VP8.

If we choose "No MTI" we will end up with transcoding, plain and simple. 
One crowd will only implement H.264. The other crowd will only implement 
VP8. All the useless middlemen will rejoice, having killed a technology 
that puts them out of business.

Providing "video chat without a plugin" is not revolutionary. Flash is 
already installed on 95% of the market. That's more people than WebRTC 
can reach today, so we're not "liberating" those people from anything.

The real revolution is P2P: massive cost savings, ease of deployment and 
most importantly: cutting out the middle man. The status quo (H.264 over 
Flash) does not do this.

P2P cannot work unless 95% of clients can agree on a common codec. I say 
again: start with H.261 and upgrade to VP8 or H.264. This way everyone 
can be happy:

  * The VP8 crowd can use VP8
  * The H264 crowd can use H264
  * The enterprise crowd can transcode
  * If all of the above fails, we can fallback on H.261.

Yes, this carries the burden of implementing H.261 but this is a 
solved-problem. There are plenty of free implementations and is a much 
easier problem to solve than getting the H.264 and VP8 crowd to agree to 
implement each other's codec.

Start with H.261 and replace it the moment you find something better. 
Forcing us to transcode or drop video calls is not a solution.

Gili

On 13/11/2013 4:57 PM, Kaiduan Xie wrote:
> "if an implementer gets sued they can simply drop the codec"
>
> Thing is not that simple as "simply drop the codec", for some case you 
> still have to pay a lot of money.
>
> /Kaiduan
>
> On 13/11/2013 11:55 AM, John Leslie wrote:
>
>             And I claim that both camps are actually more likely to
>         implement
>         (or allow extensions for) the other side's codec if it is
>         _not_ MTI,
>         simply because they can back out at the first sign of lawyers.
>


--------------070601090607040309040306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    


      I agree. I'm just pointing out that John's argument (quoted below)
      doesn't make any sense. Choosing "no MTI" doesn't make Cisco any
      more likely to implement VP8.

      

      If we choose "No MTI" we will end up with transcoding, plain and
      simple. One crowd will only implement H.264. The other crowd will
      only implement VP8. All the useless middlemen will rejoice, having
      killed a technology that puts them out of business.

      

      Providing "video chat without a plugin" is not revolutionary.
      Flash is already installed on 95% of the market. That's more
      people than WebRTC can reach today, so we're not "liberating"
      those people from anything.

      

      The real revolution is P2P: massive cost savings, ease of
      deployment and most importantly: cutting out the middle man. The
      status quo (H.264 over Flash) does not do this.

      

      P2P cannot work unless 95% of clients can agree on a common codec.
      I say again: start with H.261 and upgrade to VP8 or H.264. This
      way everyone can be happy:

      
    
        
  • The VP8 crowd can use VP8
    • 
        
  • The H264 crowd can use H264
    • 
        
  • The enterprise crowd can transcode
    • 
        
  • If all of the above fails, we can fallback on H.261.
    
        
    • 
      

      
Yes, this carries the burden of implementing H.261 but this is
        a solved-problem. There are plenty of free implementations and
        is a much easier problem to solve than getting the H.264 and VP8
        crowd to agree to implement each other's codec.

      

      
Start with H.261 and replace it the moment you find something
        better. Forcing us to transcode or drop video calls is not a
        solution.

      

      
Gili

      

      On 13/11/2013 4:57 PM, Kaiduan Xie wrote:

    

    

      
"if
          an implementer gets sued they can simply drop the codec"

        


          

        
Thing
            is not that simple as "simply drop the codec", for some case
            you still have to pay a lot of money.

        

          

          

        
/Kaiduan

      

      


        On 13/11/2013 11:55 AM, John Leslie wrote:

        

          

            

              

                

                      And I claim that both camps are actually more
                  likely to implement

                  (or allow extensions for) the other side's codec if it
                  is _not_ MTI,

                  simply because they can back out at the first sign of
                  lawyers.

                

              

            

          

        

      

    

    

  


--------------070601090607040309040306--

From bernard_aboba@hotmail.com  Wed Nov 13 15:06:12 2013
Return-Path: 
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 C262311E812B for ; Wed, 13 Nov 2013 15:06:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.321
X-Spam-Level: 
X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 Tuvz14HOae+O for ; Wed, 13 Nov 2013 15:06:06 -0800 (PST)
Received: from blu0-omc3-s28.blu0.hotmail.com (blu0-omc3-s28.blu0.hotmail.com [65.55.116.103]) by ietfa.amsl.com (Postfix) with ESMTP id B084B11E810C for ; Wed, 13 Nov 2013 15:06:06 -0800 (PST)
Received: from BLU169-W41 ([65.55.116.74]) by blu0-omc3-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 13 Nov 2013 15:06:06 -0800
X-TMN: [dUPzbZLMuwLMPJElUYqxXRJPdJ1wSYlZb+hZ67PQZNQ=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_cda053e0-b035-4b08-89eb-8bd77443ff31_"
From: Bernard Aboba 
To: "rtcweb@ietf.org" 
Date: Wed, 13 Nov 2013 15:06:06 -0800
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Nov 2013 23:06:06.0735 (UTC) FILETIME=[EEF1A9F0:01CEE0C4]
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 23:06:13 -0000

--_cda053e0-b035-4b08-89eb-8bd77443ff31_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Keith Drage said:=20
=20
"Agree
 I am at the point where I would prefer to spend the meeting cycles getting=
 things we can agree on=2C rather than where we seem to be at the moment wi=
th an issue where there are two clear camps and no real sign of a compromis=
e. Ultimately the market will decide (and some parts of it probably have al=
ready decided - which is probably the reason for no progress). Keith" [BA] =
Well said. With most of the RTCWEB WG drafts either having completed WGLC o=
r being candidates for WGLC by the end of the year=2C  with some elbow grea=
se it seems very possible to move the bulk of the documents to IETF last ca=
ll within a few months at most.   Polishing the RTCWEB document set would y=
ield multiple benefits.  Not only would it get us closer to the goal of sta=
ndardizing the WebRTC protocol stack=2C but also might well turn up an issu=
e or two we haven't thought enough about. Also=2C once we move the protocol=
 stack further along=2C we'll have more cycles to spend on operational issu=
es (like monitoring concerns discussed in XRBLOCK)=2C which currently limit=
 the ability to deploy WebRTC at very large scale.   Unfortunately=2C we've=
 been spending so much time on the MTI video codec debate that less glamoro=
us (but ultimately much more important) engineering work is being neglected=
.  This is all by way of seconding your point that there is a real opportun=
ity cost to the never-ending=2C energy sapping MTI codec discussion.  Perso=
nally=2C I'd much rather redirect the work of the Internet Engineering Task=
 Force RTCWEB WG away from amateur lawyering toward engineering where we ac=
tually have expertise and could potentially make a difference. 		 	   		  =

--_cda053e0-b035-4b08-89eb-8bd77443ff31_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Keith Drage said: 
 =3B"Agree
 =3B
I=
 am at the point where I would prefer to spend the meeting cycles getting t=
hings we can agree on=2C rather than where we seem to be at the moment with=
 an issue where there are two clear camps and no real sign of a compromise.=

 =3B
Ultimately the mar=
ket will decide (and some parts of it probably have already decided - which=
 is probably the reason for no progress).
 =3B
Keith"
 =3B
[BA] Well said. =3B=
With most of the RTCWEB WG drafts either having completed WGLC or being can=
didates for WGLC by the end of the year=2C =3B with some elbow grease i=
t seems very possible to move the bulk of the documents to IETF last call w=
ithin a few months at most. =3B =3B Polishing the RTCWEB document s=
et would yield multiple benefits. =3B Not only would it get us closer t=
o =3Bthe goal of standardizing the WebRTC protocol stack=2C but also mi=
ght well turn up an issue or two we haven't thought enough about. Also=2C o=
nce we move the protocol stack further along=2C we'll have more cycles to s=
pend on operational issues (like monitoring concerns discussed in XRBLOCK)=
=2C which currently limit the ability to deploy WebRTC at very large scale.=
 =3B =3B Unfortunately=2C we've been spending so =3Bmuch time o=
n the MTI video codec debate that less glamorous (but ultimately much more =
important) engineering work is being neglected. 
 =3B
This is all by way=
 of seconding your point that there is a real opportunity cost to the never=
-ending=2C energy sapping MTI codec discussion. =3B Personally=2C I'd m=
uch rather redirect the work of the Internet Engineering Task Force RTCWEB =
WG away from amateur lawyering toward engineering where we actually have ex=
pertise and could potentially make a difference.
 		 	   		  

=

--_cda053e0-b035-4b08-89eb-8bd77443ff31_--

From mthornbu@adobe.com  Wed Nov 13 15:33:13 2013
Return-Path: 
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 6D21F11E8128 for ; Wed, 13 Nov 2013 15:33:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.672
X-Spam-Level: 
X-Spam-Status: No, score=-5.672 tagged_above=-999 required=5 tests=[AWL=0.926,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Z4japQNJKtAP for ; Wed, 13 Nov 2013 15:33:05 -0800 (PST)
Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 220F011E810B for ; Wed, 13 Nov 2013 15:33:02 -0800 (PST)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUoQMLUMUN3y3ISNMjLEtUSUJoO3xm6go@postini.com; Wed, 13 Nov 2013 15:33:02 PST
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id rADNTGt2026431; Wed, 13 Nov 2013 15:29:16 -0800 (PST)
Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id rADNX06A020222; Wed, 13 Nov 2013 15:33:00 -0800 (PST)
Received: from nambx08.corp.adobe.com ([10.8.189.94]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Wed, 13 Nov 2013 15:33:00 -0800
From: Michael Thornburgh 
To: cowwoc 
Date: Wed, 13 Nov 2013 15:32:58 -0800
Thread-Topic: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
Thread-Index: Ac7gwE88WKQvVpJCQMqENAsR5FljCgAB00OQ
Message-ID: 
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>  <5283FDF1.8030708@bbs.darktech.org>
In-Reply-To: <5283FDF1.8030708@bbs.darktech.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D9D602D39A98E34D9C43E965BEC7439834E61DE3nambx08corpadob_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 23:33:13 -0000

--_000_D9D602D39A98E34D9C43E965BEC7439834E61DE3nambx08corpadob_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> The real revolution is P2P: massive cost savings, ease of deployment and =
most importantly: cutting out the middle man. The status quo (H.264 over Fl=
ash) does not do this.

note: Flash has had P2P for real time communication since 2009.

-michael thornburgh

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 cowwoc
Sent: Wednesday, November 13, 2013 2:32 PM
To: Kaiduan Xie
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, whe=
n"


I agree. I'm just pointing out that John's argument (quoted below) doesn't =
make any sense. Choosing "no MTI" doesn't make Cisco any more likely to imp=
lement VP8.

If we choose "No MTI" we will end up with transcoding, plain and simple. On=
e crowd will only implement H.264. The other crowd will only implement VP8.=
 All the useless middlemen will rejoice, having killed a technology that pu=
ts them out of business.

Providing "video chat without a plugin" is not revolutionary. Flash is alre=
ady installed on 95% of the market. That's more people than WebRTC can reac=
h today, so we're not "liberating" those people from anything.

The real revolution is P2P: massive cost savings, ease of deployment and mo=
st importantly: cutting out the middle man. The status quo (H.264 over Flas=
h) does not do this.

P2P cannot work unless 95% of clients can agree on a common codec. I say ag=
ain: start with H.261 and upgrade to VP8 or H.264. This way everyone can be=
 happy:

 *   The VP8 crowd can use VP8
 *   The H264 crowd can use H264
 *   The enterprise crowd can transcode
 *   If all of the above fails, we can fallback on H.261.

Yes, this carries the burden of implementing H.261 but this is a solved-pro=
blem. There are plenty of free implementations and is a much easier problem=
 to solve than getting the H.264 and VP8 crowd to agree to implement each o=
ther's codec.

Start with H.261 and replace it the moment you find something better. Forci=
ng us to transcode or drop video calls is not a solution.

Gili
On 13/11/2013 4:57 PM, Kaiduan Xie wrote:
"if an implementer gets sued they can simply drop the codec"

Thing is not that simple as "simply drop the codec", for some case you stil=
l have to pay a lot of money.

/Kaiduan

On 13/11/2013 11:55 AM, John Leslie wrote:
    And I claim that both camps are actually more likely to implement
(or allow extensions for) the other side's codec if it is _not_ MTI,
simply because they can back out at the first sign of lawyers.


--_000_D9D602D39A98E34D9C43E965BEC7439834E61DE3nambx08corpadob_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
> The real revolution is P2P: massive cost savings, ease of deplo=
yment and most importantly: cutting out the middle man. The status quo (H.2=
64 over Flash) does not do this.
=
 
note: Flash =
has had P2P for real time communication since 2009.
 
=
-michael thornburgh
 
<=
span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:wind=
owtext'>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bo=
unces@ietf.org] On Behalf Of cowwoc
Sent: Wednesday, Novem=
ber 13, 2013 2:32 PM
To: Kaiduan Xie
Cc: rtcweb@ietf.or=
g
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated.=
..If not now, when"
 

I agree. I'm just po=
inting out that John's argument (quoted below) doesn't make any sense. Choo=
sing "no MTI" doesn't make Cisco any more likely to implement VP8=
.

If we choose "No MTI" we will end up with transcoding, p=
lain and simple. One crowd will only implement H.264. The other crowd will =
only implement VP8. All the useless middlemen will rejoice, having killed a=
 technology that puts them out of business.

Providing "video ch=
at without a plugin" is not revolutionary. Flash is already installed =
on 95% of the market. That's more people than WebRTC can reach today, so we=
're not "liberating" those people from anything.

The real =
revolution is P2P: massive cost savings, ease of deployment and most import=
antly: cutting out the middle man. The status quo (H.264 over Flash) does n=
ot do this.

P2P cannot work unless 95% of clients can agree on a com=
mon codec. I say again: start with H.261 and upgrade to VP8 or H.264. This =
way everyone can be happy:
  • The VP8 crowd can use VP8
  • The H264 crowd can use H264
  • The enterprise crowd can transcode
  • If all of the above fails, we can fallback on H.261.
Yes, this carries the burden of implementing H.261 but =
this is a solved-problem. There are plenty of free implementations and is a=
 much easier problem to solve than getting the H.264 and VP8 crowd to agree=
 to implement each other's codec.
Start with H.261 and rep=
lace it the moment you find something better. Forcing us to transcode or dr=
op video calls is not a solution.
Gili
On 13/11/2013 4:57 PM, Kaiduan Xie wrote:
"if an implementer gets sued they can simply drop the codec"
 
Thing is not that simple as "simply drop the codec"=
, for some case you still have to pay a lot of money.
=

 
/Kaiduan<=
o:p>

On 13/11/2013 11:55=
 AM, John Leslie wrote:
    And I claim that both camps are a=
ctually more likely to implement
(or allow extensions for) the other sid=
e's codec if it is _not_ MTI,
simply because they can back out at the fi=
rst sign of lawyers.
 
=

--_000_D9D602D39A98E34D9C43E965BEC7439834E61DE3nambx08corpadob_--

From fluffy@cisco.com  Wed Nov 13 15:54:35 2013
Return-Path: 
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 B182421E80BD for ; Wed, 13 Nov 2013 15:54:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.567
X-Spam-Level: 
X-Spam-Status: No, score=-110.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 GRoSXJzP4HBf for ; Wed, 13 Nov 2013 15:54:30 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E853321E8094 for ; Wed, 13 Nov 2013 15:54:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=264; q=dns/txt; s=iport; t=1384386870; x=1385596470; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vr+OBrhE9PtaPHmGyboq+9UoI8Bq7pfiHzF5R2UpVk8=; b=kERnskSSDAPhCQCoKwoOeb8qswUQpZkHkfc4nVopNQHnQJwoji48DZMx e+ltrlZxckQL9XpTrt3V2cHPo5z1ot7FGCD4DGS0ZUTRZmy1Uxp/1FQpz 7aA/fYU9odsoCEvTStsxXyv6FCsgmrRgpOqgqMSpHMPOZyW/trx0wDV6I 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAK8QhFKtJV2c/2dsb2JhbABZgweBC78qgSUWdIIlAQEBAwE6PwULAgEINhAyJQIEDgWHewbAKI8sMweDIIERA5gQkguDKIIq
X-IronPort-AV: E=Sophos;i="4.93,695,1378857600"; d="scan'208";a="284594129"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 13 Nov 2013 23:54:29 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rADNsT5t031729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 23:54:29 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 17:54:29 -0600
From: "Cullen Jennings (fluffy)" 
To: John Leslie 
Thread-Topic: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
Thread-Index: AQHO4MuwVWGOMommSkqggTI6K/sHVQ==
Date: Wed, 13 Nov 2013 23:54:28 +0000
Message-ID: <6EFABF3B-4D97-4B2E-B3B6-0618575B1B0F@cisco.com>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>
In-Reply-To: <20131113165526.GA13468@verdi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <48FE486DAC4D4A4189B2A48488D7C4DD@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Wed, 13 Nov 2013 23:54:35 -0000

On Nov 13, 2013, at 9:55 AM, John Leslie  wrote:

>  Both H.264 and VP8 deserve "SHOULD implement" status.

Just out of curiosity, could you say a bit more about what you see as the d=
ifference between MAY, SHOULD, and MUST in this context?



From silviapfeiffer1@gmail.com  Wed Nov 13 16:04:32 2013
Return-Path: 
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 D403521E8094 for ; Wed, 13 Nov 2013 16:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Level: 
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, 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 sR5KGcFrJ+Ft for ; Wed, 13 Nov 2013 16:04:32 -0800 (PST)
Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 171C421E8090 for ; Wed, 13 Nov 2013 16:04:32 -0800 (PST)
Received: by mail-oa0-f47.google.com with SMTP id i7so1384007oag.20 for ; Wed, 13 Nov 2013 16:04:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5qz8MCGNpU8bx/Zdg7GCV+ZvDFBEVYoRtY+szXd5lvQ=; b=OewWZcxeK21PBqSjCdT+CzPfbWbO16oWSxFR33DvEC8vTxTN3xqjvpMy9+yJjrlq5H sr9sQ8HhdVF7gq9r+gg0lEQZcZziIRn4I1uAQ+qWDd5vnOwO4l7rSfjqEG9t4E29elzY tDgoK7V0U6pMLgYytkbiQ7V/prU4YrfCs31z+pspBBVM4NIp3Mfg63kUvgZ0lW34T/+P 1FiOpPEl9YIVbgkI2JiYlj+Is2Nl3qKgs56ugTr5t/cfn7QFGb9u+hafGwJuYBckgx0A aue8R0K6bT1cdFHkn2dGh01uzKEBluAkGSA2o/7N20+EwiUJ94RJq89JWgejVdM22ust 4T4g==
X-Received: by 10.60.125.138 with SMTP id mq10mr4371872oeb.90.1384387471470; Wed, 13 Nov 2013 16:04:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.68.164 with HTTP; Wed, 13 Nov 2013 16:04:11 -0800 (PST)
In-Reply-To: <20131113165526.GA13468@verdi>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>
From: Silvia Pfeiffer 
Date: Thu, 14 Nov 2013 08:04:11 +0800
Message-ID: 
To: John Leslie 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 00:04:32 -0000

On Thu, Nov 14, 2013 at 12:55 AM, John Leslie  wrote:
> Mike Linksvayer  wrote:
>>
>> I strongly support VP8 for MTI, and oppose H.264. Undecided on which
>> of both, either, or neither would be second best.
>
>    I'm _very_ glad you care which is "second best!"
>
>    I went into last week's session quite prepared to accept either, both
> or neither. I came out unwilling to support _either_ as MTI.
>
>    This is mostly because I came to understand the "cisco" postition.
>
>    (Please excuse me for assigning names to the two main positions, but
> it will make the discussion _much_ simpler.)
>
>    The "cisco" position is:
>
> - look at all the H.264 hardware out there: we must make use of it;
> - if VP8 is MTI, we'll get sued and our customers will get hassled.
>
>    The "linux" position is:
>
> - look at all the VP8 software out there: we must make use of it;
> - if H.264 is MTI, we'll get sued and our customers will get hassled.
>
>    And, alas, they're both right.
>
>    What I didn't understand before the presentations was why Cisco
> believes they'll get sued over VP8, but not H.264.
>
>    Basically H.264 has quite a consortium to slap down the likes of
> Nokia in court should they sue anyone in the consortium. This greatly
> reduces the chance of Nokia's lawyer suing.


What makes you think that? I am not aware of a requirement on MPEG-LA
to get involved in any lawsuit that involves a company suing somebody
over a patent that is part of the H.264 pool.

On the contrary: if you get sued over VP8, you will likely find that
Google has an interest to support you.

Silvia.


>    But this consortium won't lift a finger if Nokia sues Cisco over
> VP8. Cisco is a _very_ attractive target over VP8.
>
>    Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
> MTI. They probably won't implement it.
>
>    Conversely, of course, "linux" management would _very_much_ prefer
> that H.264 not be MTI. They probably won't implement it.
>
>    Understanding this, I now strongly recommend against making either
> H.264 or VP8 MTI. (And I will not consent to a RFC 3929 process limited
> to choosing between them.)
>
>    This issue has dragged on long enough already. We need to start
> reading the riot act to the folks who claim we "need" either of these
> as MTI in order to have "satisfied" users.
>
>    Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
> IMHO, will achieve consensus for "MUST implement" status. Yes, this
> is a sorry state to find ourselves in. But the marketplace has
> sorted out much worse problems in my memory.
>
>    And I claim that both camps are actually more likely to implement
> (or allow extensions for) the other side's codec if it is _not_ MTI,
> simply because they can back out at the first sign of lawyers.
>
>    I will not go into any details about how VP8 endpoints might talk
> to H.264 endpoints, but I'm _very_ confident ways will be found if
> we actually _publish_ an RFC saying both are "SHOULD implement".
>
>    (Surely I'm not the _only_ person who'd like to see _both_ H.264
> and VP8 legacy devices using our standard...)
>
> --
> John Leslie 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From goran.ap.eriksson@ericsson.com  Wed Nov 13 16:42:32 2013
Return-Path: 
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 6BD3621E8095 for ; Wed, 13 Nov 2013 16:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 RzLPfwkv6zLS for ; Wed, 13 Nov 2013 16:42:27 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 47A6F21E80F3 for ; Wed, 13 Nov 2013 16:42:27 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-78-52841c72e704
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C4.5E.27941.27C14825; Thu, 14 Nov 2013 01:42:26 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 01:42:25 +0100
From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= 
To: Bernard Aboba 
Thread-Topic: [rtcweb] opportunity cost (was MTI video codec, charter,	RFC 3929)
Thread-Index: AQHO4MT2Udzz66diJEqTAFzXhZXl5poj4zwx
Date: Thu, 14 Nov 2013 00:42:24 +0000
Message-ID: <0FA5D66F-2680-4C58-A16E-DCE5531837E3@ericsson.com>
References: 
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: sv-SE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_0FA5D66F26804C58A16EDCE5531837E3ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvrW6RTEuQweHzkhb7l1xmtlj7r53d gcnjcc8ZNo8lS34yBTBFcdmkpOZklqUW6dslcGUs33iOsWCTQcXGBxUNjIs1uxg5OSQETCT2 3HrICGGLSVy4t56ti5GLQ0jgCKPEq03ToZwljBJnj00Bq2IT8JaYtuIsaxcjB4eIgK7E3y4j kDCzgLrEncXn2EFsYYFAiVnvT7KA2CICQRKLv65hgrCNJE5P7mQGsVkEVCWOdSwEq+cVsJdo mH2PFcQWErCU+H25EczmFLCSuL3gNdgcRgFZifvf77FA7BKX+Dz3ARPE0QISS/acZ4awRSVe Pv4HdhqzQLLEqc1GEOMFJU7OfMIygVFkFpLuWQhVs5BUQZToSdyYOoUNwtaWWLbwNTOErSsx 498hFmTxBYzsqxg5ilOLk3LTjQw2MQLj5uCW3xY7GC//tTnEKM3BoiTO+/Gtc5CQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGxrZ7i7q+vf7yvSdUMIFbejXbPiH7nXf3d349dS8/Wlj9eFbX 0SSeiYptf/vuMRy0C7obuXHv/EOyNwWEdMsq2iczv3xt1tw5Rdzsygxzp/3qmv2afrvP+Au8 vb0swXyd4YwrDPvef+RxyEqJrHn/WDl77WQ2gWp+nYbi10JRz8+J9P0teLVyuxJLcUaioRZz UXEiACLmWxhpAgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 00:42:32 -0000

--_000_0FA5D66F26804C58A16EDCE5531837E3ericssoncom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1

14 nov 2013 kl. 00:06 skrev "Bernard Aboba" >:

Keith Drage said:

"Agree

I am at the point where I would prefer to spend the meeting cycles getting =
things we can agree on, rather than where we seem to be at the moment with =
an issue where there are two clear camps and no real sign of a compromise.

Ultimately the market will decide (and some parts of it probably have alrea=
dy decided - which is probably the reason for no progress).

Keith"

[BA] Well said. With most of the RTCWEB WG drafts either having completed W=
GLC or being candidates for WGLC by the end of the year,  with some elbow g=
rease it seems very possible to move the bulk of the documents to IETF last=
 call within a few months at most.   Polishing the RTCWEB document set woul=
d yield multiple benefits.  Not only would it get us closer to the goal of =
standardizing the WebRTC protocol stack, but also might well turn up an iss=
ue or two we haven't thought enough about. Also, once we move the protocol =
stack further along, we'll have more cycles to spend on operational issues =
(like monitoring concerns discussed in XRBLOCK), which currently limit the =
ability to deploy WebRTC at very large scale.   Unfortunately, we've been s=
pending so much time on the MTI video codec debate that less glamorous (but=
 ultimately much more important) engineering work is being neglected.

This is all by way of seconding your point that there is a real opportunity=
 cost to the never-ending, energy sapping MTI codec discussion.  Personally=
, I'd much rather redirect the work of the Internet Engineering Task Force =
RTCWEB WG away from amateur lawyering toward engineering where we actually =
have expertise and could potentially make a difference.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--_000_0FA5D66F26804C58A16EDCE5531837E3ericssoncom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







+1




14 nov 2013 kl. 00:06 skrev "Bernard Aboba" <bernard_aboba@hotmail.com>:










Keith Drage said: 

 

"Agree


 


I am at the point where I would p=
refer to spend the meeting cycles getting things we can agree on, rather th=
an where we seem to be at the moment with an
 issue where there are two clear camps and no real sign of a compromise.


 


Ultimately the market will decide=
 (and some parts of it probably have already decided - which is probably th=
e reason for no progress).


 


Keith"


 


[BA] Well said. With most of the RTCWE=
B WG drafts either having completed WGLC or being candidates for WGLC by th=
e end of the year,  with some elbow grease it seems very possible to m=
ove the bulk of the documents to IETF last call
 within a few months at most.   Polishing the RTCWEB document set=
 would yield multiple benefits.  Not only would it get us closer to&nb=
sp;the goal of standardizing the WebRTC protocol stack, but also might well=
 turn up an issue or two we haven't thought enough about.
 Also, once we move the protocol stack further along, we'll have more cycle=
s to spend on operational issues (like monitoring concerns discussed in XRB=
LOCK), which currently limit the ability to deploy WebRTC at very large sca=
le.   Unfortunately, we've been
 spending so much time on the MTI video codec debate that less glamoro=
us (but ultimately much more important) engineering work is being neglected=
.



 


This is all by way of seconding your point =
that there is a real opportunity cost to the never-ending, energy sapping M=
TI codec discussion.  Personally, I'd much rather redirect the work of=
 the Internet Engineering Task Force RTCWEB
 WG away from amateur lawyering toward engineering where we actually have e=
xpertise and could potentially make a difference.










_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.=
ietf.org/mailman/listinfo/rtcweb








--_000_0FA5D66F26804C58A16EDCE5531837E3ericssoncom_--

From elagerway@gmail.com  Wed Nov 13 16:50:59 2013
Return-Path: 
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 ACC2E21E8095 for ; Wed, 13 Nov 2013 16:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Level: 
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 myu29+wM4DPg for ; Wed, 13 Nov 2013 16:50:58 -0800 (PST)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7775A21E8090 for ; Wed, 13 Nov 2013 16:50:58 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id u56so1183319wes.18 for ; Wed, 13 Nov 2013 16:50:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sEZ+qXX9oz1Gf7LcgGKVhbmWOxgwUb4wqGIY69ANV+8=; b=yj9kgQbockqWFjU0osg1XpTWDNhd8KhWSZFC8gAMb7TylwyEASCzM/pBiWGaeSJIpi A1d9rQj0CnY2J37oDX+GrE7fVcggTBSNIY3IpStDVQ6siOXOO511FSW9CoLW/mWrYpIj rWfPZs+jQSUbEiGL5cmWiQ48ES+c+8WaLlCevdCuk/uJKSbCBEIq/5bGeNZL8Ne0FeGj Phh4X903iPtknQBtxADLX14srZ+rA2o3Tw+R4kTAVkiFQPAdC/IV0Bd6Sjsikzkw0Fnz H2McWkP14YvGi+54EU3lVIBAycuh0y/47SaPJdVwW9NIWNlEAuyqE1pC7aj2LO5nyqdQ 5Tcw==
MIME-Version: 1.0
X-Received: by 10.180.9.71 with SMTP id x7mr369938wia.28.1384390257590; Wed, 13 Nov 2013 16:50:57 -0800 (PST)
Sender: elagerway@gmail.com
Received: by 10.216.182.200 with HTTP; Wed, 13 Nov 2013 16:50:57 -0800 (PST)
In-Reply-To: <0FA5D66F-2680-4C58-A16E-DCE5531837E3@ericsson.com>
References:  <0FA5D66F-2680-4C58-A16E-DCE5531837E3@ericsson.com>
Date: Wed, 13 Nov 2013 16:50:57 -0800
X-Google-Sender-Auth: 0sU_9GSaKHDL2vGEnUpvcPalBqE
Message-ID: 
From: Erik Lagerway 
To: =?ISO-8859-1?Q?G=F6ran_Eriksson_AP?= 
Content-Type: multipart/alternative; boundary=001a11c2476488cb0304eb1879b7
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 00:50:59 -0000

--001a11c2476488cb0304eb1879b7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1

*Erik Lagerway  |
*Hookflash* |
1 (855) Hookflash ext. 2 | Twitter
 | WebRTC.is Blog  *


On Wed, Nov 13, 2013 at 4:42 PM, G=F6ran Eriksson AP <
goran.ap.eriksson@ericsson.com> wrote:

>  +1
>
> 14 nov 2013 kl. 00:06 skrev "Bernard Aboba" :
>
>   Keith Drage said:
>
> "Agree
>
> I am at the point where I would prefer to spend the meeting cycles gettin=
g
> things we can agree on, rather than where we seem to be at the moment wit=
h
> an issue where there are two clear camps and no real sign of a compromise=
.
>
> Ultimately the market will decide (and some parts of it probably have
> already decided - which is probably the reason for no progress).
>
> Keith"
>
> [BA] Well said. With most of the RTCWEB WG drafts either having completed
> WGLC or being candidates for WGLC by the end of the year,  with some elbo=
w
> grease it seems very possible to move the bulk of the documents to IETF
> last call within a few months at most.   Polishing the RTCWEB document se=
t
> would yield multiple benefits.  Not only would it get us closer to the go=
al
> of standardizing the WebRTC protocol stack, but also might well turn up a=
n
> issue or two we haven't thought enough about. Also, once we move the
> protocol stack further along, we'll have more cycles to spend on
> operational issues (like monitoring concerns discussed in XRBLOCK), which
> currently limit the ability to deploy WebRTC at very large scale.
> Unfortunately, we've been spending so much time on the MTI video codec
> debate that less glamorous (but ultimately much more important) engineeri=
ng
> work is being neglected.
>
> This is all by way of seconding your point that there is a real
> opportunity cost to the never-ending, energy sapping MTI codec discussion=
.
> Personally, I'd much rather redirect the work of the Internet Engineering
> Task Force RTCWEB WG away from amateur lawyering toward engineering where
> we actually have expertise and could potentially make a difference.
>
>  _______________________________________________
> 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
>
>

--001a11c2476488cb0304eb1879b7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


+1 =A0

<=
div>
Erik Lagerway=A0|=A0=
Hookflash=A0| 1 (855)=A0Hookflash ext. 2 |=A0Twitter=
=A0|=A0WebRTC.is Blog=A0

<=
/span>





On Wed, Nov 13, 2013 at 4:42 PM, G=F6ran=
 Eriksson AP <goran.ap.eriksson@ericsson.com> w=
rote:









+1




14 nov 2013 kl. 00:06 skrev "Bernard Aboba" <bernard_aboba@hotmail.com=
>:










Keith Drage said: 

=A0

"Agree


=A0


I am at the point where I would prefer to spend the meeting cycles gettin=
g things we can agree on, rather than where we seem to be at the moment wit=
h an
 issue where there are two clear camps and no real sign of a compromise.


=A0


Ultimately the market will decide (and some parts of it probably have alr=
eady decided - which is probably the reason for no progress).=




=A0


Keith"


=A0


[BA] Well said.=A0With most of the RTCWEB W=
G drafts either having completed WGLC or being candidates for WGLC by the e=
nd of the year,=A0 with some elbow grease it seems very possible to move th=
e bulk of the documents to IETF last call
 within a few months at most.=A0=A0 Polishing the RTCWEB document set would=
 yield multiple benefits.=A0 Not only would it get us closer to=A0the goal =
of standardizing the WebRTC protocol stack, but also might well turn up an =
issue or two we haven't thought enough about.
 Also, once we move the protocol stack further along, we'll have more c=
ycles to spend on operational issues (like monitoring concerns discussed in=
 XRBLOCK), which currently limit the ability to deploy WebRTC at very large=
 scale.=A0=A0 Unfortunately, we've been
 spending so=A0much time on the MTI video codec debate that less glamorous =
(but ultimately much more important) engineering work is being neglected.



=A0


This is all by way of seconding your point =
that there is a real opportunity cost to the never-ending, energy sapping M=
TI codec discussion.=A0 Personally, I'd much rather redirect the work o=
f the Internet Engineering Task Force RTCWEB
 WG away from amateur lawyering toward engineering where we actually have e=
xpertise and could potentially make a difference.










_______________________________________________

rtcweb mailing list

rtcweb@ietf.org<=
/a>

https://www.ietf.org/mailman/listinfo/rtcweb









_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--001a11c2476488cb0304eb1879b7--

From ron@debian.org  Wed Nov 13 17:01:24 2013
Return-Path: 
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 ED36E21E8157 for ; Wed, 13 Nov 2013 17:01:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
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 6KIZMAfgRvKZ for ; Wed, 13 Nov 2013 17:01:20 -0800 (PST)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 401D321E8090 for ; Wed, 13 Nov 2013 17:01:18 -0800 (PST)
Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 14 Nov 2013 11:31:17 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id AE7E34F8F3 for ; Thu, 14 Nov 2013 11:06:10 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QHkcTwiZ3bVH for ; Thu, 14 Nov 2013 11:06:08 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id AD5284F902; Thu, 14 Nov 2013 11:06:08 +1030 (CST)
Date: Thu, 14 Nov 2013 11:06:08 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20131114003608.GQ3245@audi.shelbyville.oz>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283E700.5090300@bbs.darktech.org>  <5283FDF1.8030708@bbs.darktech.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5283FDF1.8030708@bbs.darktech.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 01:01:25 -0000

On Wed, Nov 13, 2013 at 05:32:17PM -0500, cowwoc wrote:
> Start with H.261 and replace it the moment you find something better.

Except this would essentially be an RFC 6919 MUST (BUT WE KNOW YOU WON"T)
recommendation, since nobody is going to spend development effort on a
thing that gives thumbnail video that wasn't even acceptable for users
in the 80's.

> Forcing us to transcode or drop video calls is not a solution.

... which means you'll still have exactly this problem - no solution.

If MTI video is important, the selected codec does need to be better
than the equivalent of mandating morse as the MTI audio channel.


Either we mandate something that is of good quality and has a licence
that allows anyone to use it - or we accept that the people trying to
hijack the potential ubiquity of this standard have succeeded in that.

Seems like a pretty simple choice to me.

  Ron



From duerst@it.aoyama.ac.jp  Wed Nov 13 17:39:29 2013
Return-Path: 
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 4835821F9CC5 for ; Wed, 13 Nov 2013 17:39:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.69
X-Spam-Level: 
X-Spam-Status: No, score=-101.69 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 Bm2CX6Tp9qKL for ; Wed, 13 Nov 2013 17:39:22 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8D07811E8121 for ; Wed, 13 Nov 2013 17:39:22 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAE1d3X8014862; Thu, 14 Nov 2013 10:39:03 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 1aaa_45c5_8b20ea9c_4ccd_11e3_a724_001e6722eec2; Thu, 14 Nov 2013 10:39:03 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 5B927BFF5D; Thu, 14 Nov 2013 10:39:03 +0900 (JST)
Message-ID: <528429A8.1050407@it.aoyama.ac.jp>
Date: Thu, 14 Nov 2013 10:38:48 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Ron 
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>		<5283FDF1.8030708@bbs.darktech.org> <20131114003608.GQ3245@audi.shelbyville.oz>
In-Reply-To: <20131114003608.GQ3245@audi.shelbyville.oz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 01:39:29 -0000

On 2013/11/14 9:36, Ron wrote:
> On Wed, Nov 13, 2013 at 05:32:17PM -0500, cowwoc wrote:
>> Start with H.261 and replace it the moment you find something better.
>
> Except this would essentially be an RFC 6919 MUST (BUT WE KNOW YOU WON"T)
> recommendation, since nobody is going to spend development effort on a
> thing that gives thumbnail video that wasn't even acceptable for users
> in the 80's.

Is there some place (ideally a Web site) that shows (potentially 
simulated) H.261 side-by-side with H.264 baseline or V8 or both with the 
same bandwidth, so that it's easy to compare?

Regards,   Martin.

From juberti@google.com  Wed Nov 13 17:43:29 2013
Return-Path: 
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 8D6A221E80C4 for ; Wed, 13 Nov 2013 17:43:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.804
X-Spam-Level: 
X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.173,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 tt0TaJcOnhs6 for ; Wed, 13 Nov 2013 17:43:28 -0800 (PST)
Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 77D9221E8090 for ; Wed, 13 Nov 2013 17:43:28 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id c14so1120289vea.4 for ; Wed, 13 Nov 2013 17:43:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8Cx/QERFNNxbnqgPWcC1tizsuhUcCuC8H8d3BPZNMZ0=; b=DSE2pY424PkBY93fSuEyXSDFW8jOsYMLQLzkZEKJEC8EDuZsZw9bzROL9/h5HuCcAX hc5eMInrXcthEgIADRYTGIEWA/P+cy/9XVsa2GcN4t0Fg9EtapcPLipG4pk54K/O8nNr f0w79Sn9wWF2mkpqtDFf7DJlQT0dgpsQqPm5XJwNJb9Az8/gPrvYvMr3Ibnxdeac4qan wMWwiVCeGnOGVRqfCInDi7cgKlVbMOZpmTZ+UnEmNikdORE5qQWAdZ6i549JHFal8nar NFTzWJaTJZL9DoGUEuDxT+mfa+mnEnhxpsJw33cd7MhALZGXkHrdIoxDuN+TDn7P+qYU 2vCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8Cx/QERFNNxbnqgPWcC1tizsuhUcCuC8H8d3BPZNMZ0=; b=XE09SPCBdpiI1BEeHKwFZ/IRH/7OIg43hjGMygWvzsEtFSo4lyUysUi2S+b2iWFKFh 8DEsQNMU+cTpsBPLptmv0XTiRgx+2PHY4o/1fJ7lMFkkU0ZgFJC3wem5AEWGO9butomD l88PkFcXSyX+y9qvXIHfxem7fRpetQ0gh8le8ivSSGMPjNL9Ii+3jluJ7t4oK6u8dEAv s6WzObgjlhaxDZmnJ63BvWaFmHKzZMJrCUP5DSnBJGP9MNkxnq5G/cY50NJqmVGobO8k vZYYwUenn+cvBWhaQllBdYut7flY04HkNpcGQ66/M/65yxxAeinXC3rXt6jebWwlXfMX w8Rw==
X-Gm-Message-State: ALoCoQmOcVIQ4xhDvOLd60GxYVfJvpf1ZTz5kG8F31QgccYUoWu8k3xI2SJAp6V2hZqLI/9ImOF2GDyI2Rf/4fViKbBSJkCyi7ixFRI69vozkapyripfFRQuYB/GBM2k+S9S9l8XKL1HenPdCIMncLVafN17NDHnaqDlCT1WRqyHucW3dUAqAd2705MjsljcbRoVvcYQRxBO
X-Received: by 10.52.35.136 with SMTP id h8mr29854397vdj.6.1384393407411; Wed, 13 Nov 2013 17:43:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Wed, 13 Nov 2013 17:43:06 -0800 (PST)
In-Reply-To: <5283E530.8000409@bbs.darktech.org>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283DADA.2080806@alvestrand.no> <5283E530.8000409@bbs.darktech.org>
From: Justin Uberti 
Date: Wed, 13 Nov 2013 17:43:06 -0800
Message-ID: 
To: cowwoc 
Content-Type: multipart/alternative; boundary=20cf3079bfa247554d04eb1935a5
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 01:43:29 -0000

--20cf3079bfa247554d04eb1935a5
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 13, 2013 at 12:46 PM, cowwoc  wrote:

> On 13/11/2013 3:02 PM, Harald Alvestrand wrote:
>
>> On 11/13/2013 05:55 PM, John Leslie wrote:
>>
>>>     Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
>>> IMHO, will achieve consensus for "MUST implement" status. Yes, this
>>> is a sorry state to find ourselves in. But the marketplace has
>>> sorted out much worse problems in my memory.
>>>
>>>     And I claim that both camps are actually more likely to implement
>>> (or allow extensions for) the other side's codec if it is _not_ MTI,
>>> simply because they can back out at the first sign of lawyers.
>>>
>>>     I will not go into any details about how VP8 endpoints might talk
>>> to H.264 endpoints, but I'm _very_ confident ways will be found if
>>> we actually _publish_ an RFC saying both are "SHOULD implement".
>>>
>> I don't know if many noticed it, but one reason for my fiddling with
>> devices to show Hangouts working on stage at the meeting was to show
>> that transcoding is in fact working in real services that people are
>> using on a day-to-day basis.
>>
>> Sure, it's not optimal. In fact, it hurts. But it's not the end of the
>> world either.
>>
>
> So... we're throwing P2P out of WebRTC?
>
> If you mandate H.261 as MTI, big business can still do transcoding and the
> rest of us can use H.261. Small business shouldn't have to choose between
> transcoding and dropping the call.
>
>
Regarding H.261: Consider the following clip, encoded at 256 kbps using
H.261.
http://www-mobile.ecs.soton.ac.uk/peter/h261/missa.norm.h261.mpg

Do you think this quality (QCIF, grayscale, PSNR of 38) is acceptable for
your users?

--20cf3079bfa247554d04eb1935a5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Nov 13, 2013 at 12:46 PM, cowwoc <cowwoc@bbs.darktec=
h.org> wrote:



On 13/11/2013 3:02 PM, Harald Alvestrand=
 wrote:





On 11/13/2013 05:55 PM, John Leslie wrote:



=C2=A0 =C2=A0 Both H.264 and VP8 deserve "SHOULD implement" statu=
s. Neither,

IMHO, will achieve consensus for "MUST implement" status. Yes, th=
is

is a sorry state to find ourselves in. But the marketplace has

sorted out much worse problems in my memory.



=C2=A0 =C2=A0 And I claim that both camps are actually more likely to imple=
ment

(or allow extensions for) the other side's codec if it is _not_ MTI,
simply because they can back out at the first sign of lawyers.



=C2=A0 =C2=A0 I will not go into any details about how VP8 endpoints might =
talk

to H.264 endpoints, but I'm _very_ confident ways will be found if

we actually _publish_ an RFC saying both are "SHOULD implement".<=
br>


I don't know if many noticed it, but one reason for my fiddling with
devices to show Hangouts working on stage at the meeting was to show

that transcoding is in fact working in real services that people are

using on a day-to-day basis.



Sure, it's not optimal. In fact, it hurts. But it's not the end of =
the

world either.





So... we're throwing P2P out of WebRTC?



If you mandate H.261 as MTI, big business can still do transcoding and the =
rest of us can use H.261. Small business shouldn't have to choose betwe=
en transcoding and dropping the call.




Regarding H.261: Consider =
the following clip, encoded at 256 kbps using H.261.




Do you think this quality (QCIF, grayscale, PSNR of 38)=
 is acceptable for your users?



--20cf3079bfa247554d04eb1935a5--

From tireddy@cisco.com  Wed Nov 13 17:57:04 2013
Return-Path: 
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 898F711E81B1 for ; Wed, 13 Nov 2013 17:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.549
X-Spam-Level: 
X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 nbvjTWcvYnP6 for ; Wed, 13 Nov 2013 17:56:59 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8015711E8145 for ; Wed, 13 Nov 2013 17:56:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1630; q=dns/txt; s=iport; t=1384394219; x=1385603819; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vD9bU5WPC7C1JePSHC1kiSc0lkn037RWoDZTvAJ1KK0=; b=LHX4TaTd8H30vLLPok4VTY4EM+04iatXmkRk1UNG1Uc9dkc9Aohc6dnw f9EZsn+ulD4ffsjSgTMDBL2DG2HKlWtB/C6KHBYPgEdt/NTlh3E438b43 QrNbJFsX47XirLzdp8Wmxg6/PjLXVGuY9dNShUxi5J/pNWagrnpqEMK4e k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAMgshFKtJV2b/2dsb2JhbABZgwc4U75gS4EnFnSCJQEBAQQBAQE3NAsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQiHeQ2/cQSPLjEHBoMagREDqhuBaoE+gio
X-IronPort-AV: E=Sophos;i="4.93,696,1378857600"; d="scan'208";a="284527797"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 14 Nov 2013 01:56:56 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAE1uuZ0007233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 01:56:56 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 19:56:55 -0600
From: "Tirumaleswar Reddy (tireddy)" 
To: "Markus.Isomaki@nokia.com" , "Paul Giralt (pgiralt)" 
Thread-Topic: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
Thread-Index: AQHO4KsuAuDKJP2rokSB4gWh4tKHlZoj9dAg
Date: Thu, 14 Nov 2013 01:56:54 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A24263703@xmb-rcd-x10.cisco.com>
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.42.165]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 01:57:04 -0000

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf =
Of
> Markus.Isomaki@nokia.com
> Sent: Thursday, November 14, 2013 1:28 AM
> To: Paul Giralt (pgiralt)
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-
> rtcweb-transports-01)
>=20
> Hi Paul,
>=20
> > >
> > > So unless people have data that shows that "UDP blocked but direct TC=
P
> > allowed" is in itself a very rare setup (this is a question, I don't kn=
ow
> that
> > either), I think ICE-TCP is definitely worthwhile for a WebRTC endpoint=
 to
> > support.
> >
> > This is actually a very common firewall configuration for enterprise
> > customers. Outbound TCP is allowed but UDP is blocked (even if UDP is
> > initiated from the inside).
> >
>=20
> Yes. UDP is blocked for sure and so is inbound TCP, so only outbound TCP =
is
> usable. However in many enterprises direct outbound TCP is not allowed bu=
t
> connection need to be made via an HTTP proxy. Do you (or someone else) ha=
ve an
> estimate how often *direct* outbound TCP connections actually work ?

I have seen various deployments where customers use split-tunneling and hav=
e firewalls deployed in the Branch office itself. In those deployments *dir=
ect* outbound TCP connections are permitted. UDP traffic is blocked by defa=
ult but allowed because of Firewall SIP ALG.

-Tiru.

>=20
> > -Paul
>=20
> Markus
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From harald@alvestrand.no  Wed Nov 13 18:16:58 2013
Return-Path: 
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 50BF421E80D8 for ; Wed, 13 Nov 2013 18:16:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.556
X-Spam-Level: 
X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 kUgyZLrqQclG for ; Wed, 13 Nov 2013 18:16:45 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DEF7D21E80D9 for ; Wed, 13 Nov 2013 18:16:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F011339E216; Thu, 14 Nov 2013 03:16:42 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX3kJfiwiphq; Thu, 14 Nov 2013 03:16:41 +0100 (CET)
Received: from [172.30.42.84] (unknown [62.109.39.85]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 81CCB39E209; Thu, 14 Nov 2013 03:16:41 +0100 (CET)
Message-ID: <52843288.5000507@alvestrand.no>
Date: Thu, 14 Nov 2013 03:16:40 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: James Polk 
References: <5283DF61.9060807@alvestrand.no> <201311132211.rADMBaBD011692@rcdn-core2-5.cisco.com>
In-Reply-To: <201311132211.rADMBaBD011692@rcdn-core2-5.cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: rai-ads@tools.ietf.org, "rtcweb@ietf.org" , tsv-ads@tools.ietf.org
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 02:16:58 -0000

On 11/13/2013 11:11 PM, James Polk wrote:
> I, speaking at the mic, was merely pointing out that this draft had
> moved to TSVWG back in the Atlanta timeframe (though, thinking back, I
> think I left the timing piece out of my comment), so it wasn't a
> recent decision. I believe this came directly from talks between the
> above mentioned ADs.

This only reinforces my procedural comment. The fact that the decision,
and the reasons for it, has been hidden from the group for 8 (?) months
only makes it worse, not better.

When ADs make decisions by talking among themselves, they have a special
duty to make sure those decisions are public and open to the community.
That duty has not been executed in this case.
I don't know who dropped the ball - the ADs or the chairs. But the ball
was definitely dropped.

>
> As for RTCweb work being more appropriately inside the RTBweb WG
> instead of another group, I'd like to point out that much of the SDP
> work related to this WG is in fact being done in MMUSIC. Much of the
> RTP work being done by this WG is being done in AVTCORE (or AVTEXT?).
> All of the base SCTP work being done by this WG is being done in TSVWG.

I have issues with those too. Especially the speed at which they're
progressing. But those decisions were made and announced in a timely
fashion.

The argument that has been used is that the pieces we need defined
(BUNDLE, MSID, circuit-breakers, RMCAT) have general applicability, and
should therefore be processed by groups that are chartered to define
extensions with general applicability.

>
> (this is not an attack, but...)
>
> ...why are you arguing for something as far away down the stack as
> DSCP assignments to be done in RTCweb, and not where all other
> DiffServ work is being done in the IETF (in TSVWG)? Do you not trust
> that TSVWG will do an appropriate just with a DiffServ ID but you will
> trust TSVWG with SCTP IDs?

My understanding of the QoS draft has always been that it should define
no new codepoints. It should point out the language we need to translate
RTCWEB requirements ("audio should go faster than video, except when the
app says that it should be the other way around") into already-defined
DSCP code points.

I have not seen anyone arguing for new DSCP codepoints, so I really
wonder what work there is for TSVWG to do.

Again, the arguments may be there, but since they were never exposed to
the mailing list, I cannot evaluate them.

>
> Color me confused...
>
> James
>
> BTW - Full disclosure, I'm an listed author of this draft, but had no
> voice in it getting moved between the WGs.

My biggest practical issue with this draft is that it's functionally
dead. I'm getting put in a place where I have to either delay shipping
this feature in product or ship without even the guidance of a live draft.

I want this group to be done. As long as I can't even point to the
document that describes how we do QoS, I have no chance of getting it to
that stage.


>
> At 02:21 PM 11/13/2013, Harald Alvestrand wrote:
>> This mail concerns both administrative and technical issues, which is
>> why it is explicitly copied to the ADs of RAI and TSV. I hope I have
>> managed to keep them separate in the message.
>>
>> Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:
>>
>> > Okay, we might not have been public enough on this. It was
>> requested by
>> > the Transport ADs quite some time ago that doing the QoS document
>> in our
>> > WG was not appropriate and requested us to direct the document to
>> TSVWG.
>> > Which was done, and where it hasn't made progress.
>> >
>> > You might have noted that James Polk did comment in the milestone part
>> > in the monday session of IETF88 about our QoS milestone should be
>> killed.
>> I want to protest this - both practically and formally.
>>
>> To get the formal stuff out of the way first:
>>
>> Changing the deliverables of the working group *without telling the
>> working group* is totally inappropriate in an open, consensus-driven
>> process.
>> Changing the deliverables of the working group *without telling the
>> working group why* and *without allowing those reasons to be debated* is
>> totally inappropriate in an open, consensus-driven process.
>>
>> I protest against this action.
>>
>> ACTION REQUEST 1: I request that this decision be declared null and
>> void, and that the relevant ADs send out a message to RTCWEB (and TSVWG
>> if appropriate) *PROPOSING* such an action, and giving a reasonable
>> timeline for when they will make a decision based on mailing list
>> feedback.
>>
>> In practice:
>>
>> The draft as it existed before its untimely demise consisted of two
>> things:
>>
>> - A description of how QoS mechanisms could be useful in the RTCWEB
>> use case
>> - A description of existing mechanisms that could be appropriate for the
>> RTCWEB use case
>>
>> The first one is clearly something that needs RTCWEB consensus. It seems
>> to have no need for, nor likelyhood of gathering interest enough for, a
>> TSVWG consensus.
>>
>> There could be some argument that the second part needs TSVWG consensus,
>> especially if it was redefining any mechanisms, or it was making choices
>> between mechanisms where TSVWG had strong opinions about which
>> mechanisms should be chosen, but had not chosen to document that in any
>> document on which IETF consensus had been declared (that is to say,
>> existing RFCs).
>>
>> My archive shows 36 messages where the title refers to this draft. It
>> shows no messages declaring that feedback has been incorporated and
>> calling for new review - something that is usually necessary to get a WG
>> consensus on any document. The debate hasn't been conclusive, but then,
>> it hasn't been pushed hard either.
>>
>> The people who know how RTCWEB works are in this working group. Some of
>> them may be in TSV, but I think the locus of knowledge for saying what
>> QoS mechanisms are appropriate for RTCWEB are here, not in TSV.
>>
>> This results in my second request.
>>
>> ACTION REQUEST 2: I request that the chairs declare that based on the
>> debate about the QoS functionality so far, the document should be
>> resurrected, and will continue to be  worked on in the RTCWEB working
>> group, bringing in advice from TSVWG as required to make sure the
>> descriptions of underlying mechanisms, and the choice of such
>> mechanisms, is correct and appropriate.
>>
>>
>>
>>
>> -- 
>> Surveillance is pervasive. Go Dark.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>


-- 
Surveillance is pervasive. Go Dark.


From chris-ietf@chriswendt.net  Wed Nov 13 18:19:38 2013
Return-Path: 
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 6209221E80D8 for ; Wed, 13 Nov 2013 18:19:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 v5U66094dK-z for ; Wed, 13 Nov 2013 18:19:33 -0800 (PST)
Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 59B2821E80CB for ; Wed, 13 Nov 2013 18:19:33 -0800 (PST)
Received: by mail-qe0-f53.google.com with SMTP id cy11so873929qeb.26 for ; Wed, 13 Nov 2013 18:19:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=dpsswkIDLX9yKsquKRleHBRBqk/0EtD9voBVp7ccRuw=; b=YxvKrZq1iqFR+VEUoSv23qLZFyYGiNpbRAfxiNtq9/cbnrDIhCYSgdrlZBBfxkobR1 S+HTxfzOayQ6VTWdG6C9e/bIgkovXXfFNsyj1Bh2X5IT2nOu4E7fAeG9BuUOnik/acE6 85H57nHbwTqNitLLBhSLUTFvCJawszDs8YllkSraZGU0AcCOOMj6q9V2fkK2STqOTo2a YZVt+A6SwVWLn0KJS4UiSOTgYvnFP+MKlPuXZHoPxoC8QKGc2EiWrW+tWK5/RXEfozCG g0r3Sl49/EdaR1Xn2v3ROioi+juTjArKDa7IG6sBi/tWWWLFEWU5snhFzcv11DOxcxiI A+sQ==
X-Gm-Message-State: ALoCoQlHG1lCCOQRiMuQ2to0zjuZNoU9lCoPDYLVtJt6Fy5gPvP4BWwlDt4lTNWeLYgKpnolNTr9
X-Received: by 10.224.89.73 with SMTP id d9mr71718738qam.5.1384395572610; Wed, 13 Nov 2013 18:19:32 -0800 (PST)
Received: from [10.0.1.113] (c-68-83-240-221.hsd1.pa.comcast.net. [68.83.240.221]) by mx.google.com with ESMTPSA id a9sm1254452qed.6.2013.11.13.18.19.31 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 18:19:32 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DBEF57EF-160F-4721-AE14-493858B4711D"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Chris Wendt 
In-Reply-To: 
Date: Wed, 13 Nov 2013 21:19:30 -0500
Message-Id: <0C08339C-A462-4846-818F-3942851E56D8@chriswendt.net>
References: 
To: Bernard Aboba 
X-Mailer: Apple Mail (2.1822)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 02:19:38 -0000

--Apple-Mail=_DBEF57EF-160F-4721-AE14-493858B4711D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

+1=20

On Nov 13, 2013, at 6:06 PM, Bernard Aboba  =
wrote:

> Keith Drage said:=20
> =20
> "Agree
> =20
> I am at the point where I would prefer to spend the meeting cycles =
getting things we can agree on, rather than where we seem to be at the =
moment with an issue where there are two clear camps and no real sign of =
a compromise.
> =20
> Ultimately the market will decide (and some parts of it probably have =
already decided - which is probably the reason for no progress).
> =20
> Keith"
> =20
> [BA] Well said. With most of the RTCWEB WG drafts either having =
completed WGLC or being candidates for WGLC by the end of the year,  =
with some elbow grease it seems very possible to move the bulk of the =
documents to IETF last call within a few months at most.   Polishing the =
RTCWEB document set would yield multiple benefits.  Not only would it =
get us closer to the goal of standardizing the WebRTC protocol stack, =
but also might well turn up an issue or two we haven't thought enough =
about. Also, once we move the protocol stack further along, we'll have =
more cycles to spend on operational issues (like monitoring concerns =
discussed in XRBLOCK), which currently limit the ability to deploy =
WebRTC at very large scale.   Unfortunately, we've been spending so much =
time on the MTI video codec debate that less glamorous (but ultimately =
much more important) engineering work is being neglected.
> =20
> This is all by way of seconding your point that there is a real =
opportunity cost to the never-ending, energy sapping MTI codec =
discussion.  Personally, I'd much rather redirect the work of the =
Internet Engineering Task Force RTCWEB WG away from amateur lawyering =
toward engineering where we actually have expertise and could =
potentially make a difference.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--Apple-Mail=_DBEF57EF-160F-4721-AE14-493858B4711D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

+1 

On Nov 13, =
2013, at 6:06 PM, Bernard Aboba <bernard_aboba@hotmail.com>=
; wrote:

Keith Drage said: 
 
"Agree
 
I am at the point where I would prefer to spend the meeting =
cycles getting things we can agree on, rather than where we seem to be =
at the moment with an issue where there are two clear camps and no real =
sign of a compromise.
 
Ultimately the market will decide (and some =
parts of it probably have already decided - which is probably the reason =
for no progress).
 
Keith"
 
[BA] Well =
said. With most of the RTCWEB WG drafts either having completed =
WGLC or being candidates for WGLC by the end of the year,  with =
some elbow grease it seems very possible to move the bulk of the =
documents to IETF last call within a few months at most.   =
Polishing the RTCWEB document set would yield multiple benefits.  =
Not only would it get us closer to the goal of standardizing the =
WebRTC protocol stack, but also might well turn up an issue or two we =
haven't thought enough about. Also, once we move the protocol stack =
further along, we'll have more cycles to spend on operational issues =
(like monitoring concerns discussed in XRBLOCK), which currently limit =
the ability to deploy WebRTC at very large scale.   =
Unfortunately, we've been spending so much time on the MTI video =
codec debate that less glamorous (but ultimately much more important) =
engineering work is being neglected.
 
This is all by =
way of seconding your point that there is a real opportunity cost to the =
never-ending, energy sapping MTI codec discussion.  Personally, I'd =
much rather redirect the work of the Internet Engineering Task Force =
RTCWEB WG away from amateur lawyering toward engineering where we =
actually have expertise and could potentially make a =
difference.
_______________________________________________
=
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org=
/mailman/listinfo/rtcweb

=

--Apple-Mail=_DBEF57EF-160F-4721-AE14-493858B4711D--

From jdrosen@jdrosen.net  Wed Nov 13 18:26:43 2013
Return-Path: 
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 C31B821E80D9 for ; Wed, 13 Nov 2013 18:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.901
X-Spam-Level: 
X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 WoaOgeh4gZvy for ; Wed, 13 Nov 2013 18:26:36 -0800 (PST)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id C435821E80CB for ; Wed, 13 Nov 2013 18:26:28 -0800 (PST)
Received: from mail-pa0-f47.google.com ([209.85.220.47]:62664) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1VgmdO-000092-37 for rtcweb@ietf.org; Wed, 13 Nov 2013 21:26:27 -0500
Received: by mail-pa0-f47.google.com with SMTP id ld10so1367370pab.20 for ; Wed, 13 Nov 2013 18:26:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l+vmF9Kqjhlu4vL5S4J28pNn1KjCmC4kQHY4Oagthqc=; b=APKa9yTeyrIrOBu2NRScFYd6QCtzNASp6yHIgfqgkDeh5Uvd60pmMWcQ1LV0oQa2Hc T62XoJ2QaLlux/x3YODKMWpRbU939aORNcc9VC9Lmd8GEuRdw11S4rMjAhgPCKGtMUI8 fWpLtedXFImce710n6DpQYclvBLS0MVUtDKNV9e+Gq0r/CCIoxiCOIvgyZeXUWd1W1tG ytm2TkRQYo0VyLOSzdhyb48o5dhvRyyBQ4osT8rY3i5V27RBKSzTtBo3unSq3lUzMZjR nOwLMmk91EIFCIMQKjqb05OM/Ptpwy3+oFaQmLQkYFnEDT9r87yKq7kj++i6C/ObEoaC O3xQ==
MIME-Version: 1.0
X-Received: by 10.66.118.129 with SMTP id km1mr17772263pab.127.1384395977313;  Wed, 13 Nov 2013 18:26:17 -0800 (PST)
Received: by 10.70.49.48 with HTTP; Wed, 13 Nov 2013 18:26:17 -0800 (PST)
In-Reply-To: 
References: <5283DFDC.4010906@ericsson.com> 
Date: Wed, 13 Nov 2013 21:26:17 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: Stephan Wenger 
Content-Type: multipart/alternative; boundary=e89a8ffbab6b74ebed04eb19ceff
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jdrosen.net
X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 02:26:43 -0000

--e89a8ffbab6b74ebed04eb19ceff
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Regarding number 4, here is how I think of it:

If browsers implement both, it means that an application provider wishing
to offer a service (take Hangouts or Skype as examples), can pick the one
they like, implement just that in their native apps (mobile, desktop, etc.)
where the app provider has control over the full stack, and still work with
clients of that service which run in the browser, where the app provider
does not have control over the full stack as the real-time media stack is
provided by the browser and not the web app.

The benefit of this approach is that it enables interoperability between
clients on different platforms for the same provider.

The drawback is, for inter-service federation (which requires much more
than just codecs to be aligned), you might run into a case where a user
using a mobile app from provider 1 (say, Skype) calls a user using a mobile
app from provider 2 (say, Hangouts), and then since each chose a different
video codec, there is no common codec. Of course that assumes the two
providers in question are willing to even federate in the first place.

-Jonathan R.




On Wed, Nov 13, 2013 at 5:17 PM, Stephan Wenger  wrote:

> Hi Gonzalo,
> Re your point 5.: =B3either or=B2 is often understood as an exclusive or.=
  I
> don=B9t think anyone proposed that.  A better way to express 5. would be
> =B3All entities MUST support at least one of H.264 and VP8=B2.
> Stephan
>
> On 11.13.2013, 12:23 , "Gonzalo Camarillo"
>  wrote:
>
> >Folks,
> >
> >I hope everybody had a safe trip back home after Vancouver.
> >
> >As you all know, we need to make progress regarding the selection of the
> >MTI video codec. The following are some of the alternatives we have on
> >the table:
> >
> > 1. All entities MUST support H.264
> > 2. All entities MUST support VP8
> > 3. All entities MUST support both H.264 and VP8
> > 4. Browsers MUST support both H.264 and VP8
> > 5. All entities MUST support either H.264 or VP8
> > 6. All entities MUST support H.261
> > 7. There is no MTI video codec
> >
> >If you want the group to consider additional alternatives to the ones
> >above, please let the group know within the following *two weeks*. At
> >that point, the chairs will be listing all the received alternatives and
> >proposing a process to select one among them.
> >
> >Please, send your proposals in an email to the list. You do not need to
> >write a draft; just send the text you would like to see in the final
> >document regarding video codecs.
> >
> >Thanks,
> >
> >Gonzalo
> >Responsible AD for this WG
> >
> >_______________________________________________
> >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
>



--=20
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net

--e89a8ffbab6b74ebed04eb19ceff
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Regarding number 4, here is how I think of it:

If browsers implement both, it means that an application provider w=
ishing to offer a service (take Hangouts or Skype as examples), can pick th=
e one they like, implement just that in their native apps (mobile, desktop,=
 etc.) where the app provider has control over the full stack, and still wo=
rk with clients of that service which run in the browser, where the app pro=
vider does not have control over the full stack as the real-time media stac=
k is provided by the browser and not the web app.=A0



The benefit of this approach is that it enables i=
nteroperability between clients on different platforms for the same provide=
r.

The drawback is, for inter-service federation (=
which requires much more than just codecs to be aligned), you might run int=
o a case where a user using a mobile app from provider 1 (say, Skype) calls=
 a user using a mobile app from provider 2 (say, Hangouts), and then since =
each chose a different video codec, there is no common codec. Of course tha=
t assumes the two providers in question are willing to even federate in the=
 first place.=A0



-Jonathan R.


<=
div class=3D"gmail_extra">

On Wed, Nov 13=
, 2013 at 5:17 PM, Stephan Wenger <stewe@stewe.org> wrote:


Hi Gonzalo,

Re your point 5.: =B3either or=B2 is often understood as an exclusive or. =
=A0I

don=B9t think anyone proposed that. =A0A better way to express 5. would be<=
br>
=B3All entities MUST support at least one of H.264 and VP8=B2.

Stephan



On 11.13.2013, 12:23 , "Gonzalo Camarillo"


<Gonzalo.Camarillo@ericsson.com> wrote:



>Folks,

>

>I hope everybody had a safe trip back home after Vancouver.

>

>As you all know, we need to make progress regarding the selection of th=
e

>MTI video codec. The following are some of the alternatives we have on<=
br>
>the table:

>

> 1. All entities MUST support H.264

> 2. All entities MUST support VP8

> 3. All entities MUST support both H.264 and VP8

> 4. Browsers MUST support both H.264 and VP8

> 5. All entities MUST support either H.264 or VP8

> 6. All entities MUST support H.261

> 7. There is no MTI video codec

>

>If you want the group to consider additional alternatives to the ones
>above, please let the group know within the following *two weeks*. At
>that point, the chairs will be listing all the received alternatives an=
d

>proposing a process to select one among them.

>

>Please, send your proposals in an email to the list. You do not need to=


>write a draft; just send the text you would like to see in the final
>document regarding video codecs.

>

>Thanks,

>

>Gonzalo

>Responsible AD for this WG

>

>_______________________________________________

>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





-- 
=





--e89a8ffbab6b74ebed04eb19ceff--

From bernard_aboba@hotmail.com  Wed Nov 13 20:02:22 2013
Return-Path: 
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 AAB9721E817D for ; Wed, 13 Nov 2013 20:02:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.333
X-Spam-Level: 
X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 S1JLOSZpxVpY for ; Wed, 13 Nov 2013 20:02:18 -0800 (PST)
Received: from blu0-omc4-s3.blu0.hotmail.com (blu0-omc4-s3.blu0.hotmail.com [65.55.111.142]) by ietfa.amsl.com (Postfix) with ESMTP id E8CEA21E8091 for ; Wed, 13 Nov 2013 20:02:17 -0800 (PST)
Received: from BLU406-EAS97 ([65.55.111.135]) by blu0-omc4-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 13 Nov 2013 20:02:11 -0800
X-TMN: [H+jDXuOccB4JhiEWaP0Fe3dxv5C59nIH]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/related; boundary="_f95510b1-0930-43b3-88af-d43f59cd2afd_"
References: <5283DFDC.4010906@ericsson.com>  
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
In-Reply-To: 
Date: Wed, 13 Nov 2013 20:02:08 -0800
To: Jonathan Rosenberg 
X-OriginalArrivalTime: 14 Nov 2013 04:02:11.0432 (UTC) FILETIME=[4B874E80:01CEE0EE]
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 04:02:22 -0000

--_f95510b1-0930-43b3-88af-d43f59cd2afd_
Content-Type: multipart/alternative;
	boundary="Apple-Mail-84F4C0E3-121E-4704-A243-25C72DC89141"
Content-Transfer-Encoding: 7bit

--Apple-Mail-84F4C0E3-121E-4704-A243-25C72DC89141
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXNzdW1pbmcgd2UgYXJlIHRhbGtpbmcgYWJvdXQgbmF0aXZlIHN1cHBvcnQsIE9wdGlvbiAjNCBt
YXhpbWl6ZXMgbGVnYWwgbGlhYmlsaXR5LiBTaW5jZSB0aGlzIHRoZSBtYWpvciB1bmRlcmx5aW5n
IGlzc3VlIGl0IHdpbGwgYmUgdGhlIGhhcmRlc3Qgb3B0aW9uIHRvIGdldCBwYXN0IHRoZSBsZWdh
bCBkZXBhcnRtZW50LiBJZiB3ZSBhcmVuJ3QgdGFsa2luZyBuYXRpdmUgYnV0IHBsdWdpbnMgdGhl
biBpdCBpcyBtb3JlIGZvcndhcmQgdGhpbmtpbmcgdG8gZm9jdXMgb24gbmV4dCBnZW5lcmF0aW9u
IGNvZGVjIHN1cHBvcnQuIEVpdGhlciB3YXksIE9wdGlvbiA0IGxvc2VzIG91dCB0byBlaXRoZXIg
MSwgMiwgb3IgNy4gDQoNCj4gT24gTm92IDEzLCAyMDEzLCBhdCAxODoyNiwgIkpvbmF0aGFuIFJv
c2VuYmVyZyIgPGpkcm9zZW5AamRyb3Nlbi5uZXQ+IHdyb3RlOg0KPiANCj4gUmVnYXJkaW5nIG51
bWJlciA0LCBoZXJlIGlzIGhvdyBJIHRoaW5rIG9mIGl0Og0KPiANCj4gSWYgYnJvd3NlcnMgaW1w
bGVtZW50IGJvdGgsIGl0IG1lYW5zIHRoYXQgYW4gYXBwbGljYXRpb24gcHJvdmlkZXIgd2lzaGlu
ZyB0byBvZmZlciBhIHNlcnZpY2UgKHRha2UgSGFuZ291dHMgb3IgU2t5cGUgYXMgZXhhbXBsZXMp
LCBjYW4gcGljayB0aGUgb25lIHRoZXkgbGlrZSwgaW1wbGVtZW50IGp1c3QgdGhhdCBpbiB0aGVp
ciBuYXRpdmUgYXBwcyAobW9iaWxlLCBkZXNrdG9wLCBldGMuKSB3aGVyZSB0aGUgYXBwIHByb3Zp
ZGVyIGhhcyBjb250cm9sIG92ZXIgdGhlIGZ1bGwgc3RhY2ssIGFuZCBzdGlsbCB3b3JrIHdpdGgg
Y2xpZW50cyBvZiB0aGF0IHNlcnZpY2Ugd2hpY2ggcnVuIGluIHRoZSBicm93c2VyLCB3aGVyZSB0
aGUgYXBwIHByb3ZpZGVyIGRvZXMgbm90IGhhdmUgY29udHJvbCBvdmVyIHRoZSBmdWxsIHN0YWNr
IGFzIHRoZSByZWFsLXRpbWUgbWVkaWEgc3RhY2sgaXMgcHJvdmlkZWQgYnkgdGhlIGJyb3dzZXIg
YW5kIG5vdCB0aGUgd2ViIGFwcC4gDQo+IA0KPiBUaGUgYmVuZWZpdCBvZiB0aGlzIGFwcHJvYWNo
IGlzIHRoYXQgaXQgZW5hYmxlcyBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gY2xpZW50cyBvbiBk
aWZmZXJlbnQgcGxhdGZvcm1zIGZvciB0aGUgc2FtZSBwcm92aWRlci4NCj4gDQo+IFRoZSBkcmF3
YmFjayBpcywgZm9yIGludGVyLXNlcnZpY2UgZmVkZXJhdGlvbiAod2hpY2ggcmVxdWlyZXMgbXVj
aCBtb3JlIHRoYW4ganVzdCBjb2RlY3MgdG8gYmUgYWxpZ25lZCksIHlvdSBtaWdodCBydW4gaW50
byBhIGNhc2Ugd2hlcmUgYSB1c2VyIHVzaW5nIGEgbW9iaWxlIGFwcCBmcm9tIHByb3ZpZGVyIDEg
KHNheSwgU2t5cGUpIGNhbGxzIGEgdXNlciB1c2luZyBhIG1vYmlsZSBhcHAgZnJvbSBwcm92aWRl
ciAyIChzYXksIEhhbmdvdXRzKSwgYW5kIHRoZW4gc2luY2UgZWFjaCBjaG9zZSBhIGRpZmZlcmVu
dCB2aWRlbyBjb2RlYywgdGhlcmUgaXMgbm8gY29tbW9uIGNvZGVjLiBPZiBjb3Vyc2UgdGhhdCBh
c3N1bWVzIHRoZSB0d28gcHJvdmlkZXJzIGluIHF1ZXN0aW9uIGFyZSB3aWxsaW5nIHRvIGV2ZW4g
ZmVkZXJhdGUgaW4gdGhlIGZpcnN0IHBsYWNlLiANCj4gDQo+IC1Kb25hdGhhbiBSLg0KPiANCj4g
DQo+IA0KPiANCj4+IE9uIFdlZCwgTm92IDEzLCAyMDEzIGF0IDU6MTcgUE0sIFN0ZXBoYW4gV2Vu
Z2VyIDxzdGV3ZUBzdGV3ZS5vcmc+IHdyb3RlOg0KPj4gSGkgR29uemFsbywNCj4+IFJlIHlvdXIg
cG9pbnQgNS46IMKzZWl0aGVyIG9ywrIgaXMgb2Z0ZW4gdW5kZXJzdG9vZCBhcyBhbiBleGNsdXNp
dmUgb3IuICBJDQo+PiBkb27CuXQgdGhpbmsgYW55b25lIHByb3Bvc2VkIHRoYXQuICBBIGJldHRl
ciB3YXkgdG8gZXhwcmVzcyA1LiB3b3VsZCBiZQ0KPj4gwrNBbGwgZW50aXRpZXMgTVVTVCBzdXBw
b3J0IGF0IGxlYXN0IG9uZSBvZiBILjI2NCBhbmQgVlA4wrIuDQo+PiBTdGVwaGFuDQo+PiANCj4+
IE9uIDExLjEzLjIwMTMsIDEyOjIzICwgIkdvbnphbG8gQ2FtYXJpbGxvIg0KPj4gPEdvbnphbG8u
Q2FtYXJpbGxvQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+PiANCj4+ID5Gb2xrcywNCj4+ID4NCj4+
ID5JIGhvcGUgZXZlcnlib2R5IGhhZCBhIHNhZmUgdHJpcCBiYWNrIGhvbWUgYWZ0ZXIgVmFuY291
dmVyLg0KPj4gPg0KPj4gPkFzIHlvdSBhbGwga25vdywgd2UgbmVlZCB0byBtYWtlIHByb2dyZXNz
IHJlZ2FyZGluZyB0aGUgc2VsZWN0aW9uIG9mIHRoZQ0KPj4gPk1USSB2aWRlbyBjb2RlYy4gVGhl
IGZvbGxvd2luZyBhcmUgc29tZSBvZiB0aGUgYWx0ZXJuYXRpdmVzIHdlIGhhdmUgb24NCj4+ID50
aGUgdGFibGU6DQo+PiA+DQo+PiA+IDEuIEFsbCBlbnRpdGllcyBNVVNUIHN1cHBvcnQgSC4yNjQN
Cj4+ID4gMi4gQWxsIGVudGl0aWVzIE1VU1Qgc3VwcG9ydCBWUDgNCj4+ID4gMy4gQWxsIGVudGl0
aWVzIE1VU1Qgc3VwcG9ydCBib3RoIEguMjY0IGFuZCBWUDgNCj4+ID4gNC4gQnJvd3NlcnMgTVVT
VCBzdXBwb3J0IGJvdGggSC4yNjQgYW5kIFZQOA0KPj4gPiA1LiBBbGwgZW50aXRpZXMgTVVTVCBz
dXBwb3J0IGVpdGhlciBILjI2NCBvciBWUDgNCj4+ID4gNi4gQWxsIGVudGl0aWVzIE1VU1Qgc3Vw
cG9ydCBILjI2MQ0KPj4gPiA3LiBUaGVyZSBpcyBubyBNVEkgdmlkZW8gY29kZWMNCj4+ID4NCj4+
ID5JZiB5b3Ugd2FudCB0aGUgZ3JvdXAgdG8gY29uc2lkZXIgYWRkaXRpb25hbCBhbHRlcm5hdGl2
ZXMgdG8gdGhlIG9uZXMNCj4+ID5hYm92ZSwgcGxlYXNlIGxldCB0aGUgZ3JvdXAga25vdyB3aXRo
aW4gdGhlIGZvbGxvd2luZyAqdHdvIHdlZWtzKi4gQXQNCj4+ID50aGF0IHBvaW50LCB0aGUgY2hh
aXJzIHdpbGwgYmUgbGlzdGluZyBhbGwgdGhlIHJlY2VpdmVkIGFsdGVybmF0aXZlcyBhbmQNCj4+
ID5wcm9wb3NpbmcgYSBwcm9jZXNzIHRvIHNlbGVjdCBvbmUgYW1vbmcgdGhlbS4NCj4+ID4NCj4+
ID5QbGVhc2UsIHNlbmQgeW91ciBwcm9wb3NhbHMgaW4gYW4gZW1haWwgdG8gdGhlIGxpc3QuIFlv
dSBkbyBub3QgbmVlZCB0bw0KPj4gPndyaXRlIGEgZHJhZnQ7IGp1c3Qgc2VuZCB0aGUgdGV4dCB5
b3Ugd291bGQgbGlrZSB0byBzZWUgaW4gdGhlIGZpbmFsDQo+PiA+ZG9jdW1lbnQgcmVnYXJkaW5n
IHZpZGVvIGNvZGVjcy4NCj4+ID4NCj4+ID5UaGFua3MsDQo+PiA+DQo+PiA+R29uemFsbw0KPj4g
PlJlc3BvbnNpYmxlIEFEIGZvciB0aGlzIFdHDQo+PiA+DQo+PiA+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5ydGN3ZWIgbWFpbGluZyBsaXN0DQo+
PiA+cnRjd2ViQGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9ydGN3ZWINCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+IHJ0Y3dlYkBpZXRmLm9yZw0K
Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4gDQo+IA0K
PiANCj4gLS0gDQo+IEpvbmF0aGFuIFJvc2VuYmVyZywgUGguRC4NCj4gamRyb3NlbkBqZHJvc2Vu
Lm5ldA0KPiBodHRwOi8vd3d3Lmpkcm9zZW4ubmV0DQo+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gcnRjd2Vi
QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi
DQo=

--Apple-Mail-84F4C0E3-121E-4704-A243-25C72DC89141
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+QXNzdW1p
bmcgd2UgYXJlIHRhbGtpbmcgYWJvdXQgbmF0aXZlIHN1cHBvcnQsIE9wdGlvbiAjNCBtYXhpbWl6
ZXMgbGVnYWwgbGlhYmlsaXR5LiBTaW5jZSB0aGlzIHRoZSBtYWpvciB1bmRlcmx5aW5nIGlzc3Vl
IGl0IHdpbGwgYmUgdGhlIGhhcmRlc3Qgb3B0aW9uIHRvIGdldCBwYXN0IHRoZSBsZWdhbCBkZXBh
cnRtZW50LiBJZiB3ZSBhcmVuJ3QgdGFsa2luZyBuYXRpdmUgYnV0IHBsdWdpbnMgdGhlbiBpdCBp
cyBtb3JlIGZvcndhcmQgdGhpbmtpbmcgdG8gZm9jdXMgb24gbmV4dCBnZW5lcmF0aW9uIGNvZGVj
IHN1cHBvcnQuIEVpdGhlciB3YXksIE9wdGlvbiA0IGxvc2VzIG91dCB0byBlaXRoZXIgMSwgMiwg
b3IgNy4mbmJzcDs8L2Rpdj48ZGl2Pjxicj5PbiBOb3YgMTMsIDIwMTMsIGF0IDE4OjI2LCAiSm9u
YXRoYW4gUm9zZW5iZXJnIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpkcm9zZW5AamRyb3Nlbi5uZXQi
Pmpkcm9zZW5AamRyb3Nlbi5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGRpdiBkaXI9Imx0ciI+UmVnYXJkaW5nIG51bWJlciA0LCBo
ZXJlIGlzIGhvdyBJIHRoaW5rIG9mIGl0OjxkaXY+PGJyPjwvZGl2PjxkaXY+SWYgYnJvd3NlcnMg
aW1wbGVtZW50IGJvdGgsIGl0IG1lYW5zIHRoYXQgYW4gYXBwbGljYXRpb24gcHJvdmlkZXIgd2lz
aGluZyB0byBvZmZlciBhIHNlcnZpY2UgKHRha2UgSGFuZ291dHMgb3IgU2t5cGUgYXMgZXhhbXBs
ZXMpLCBjYW4gcGljayB0aGUgb25lIHRoZXkgbGlrZSwgaW1wbGVtZW50IGp1c3QgdGhhdCBpbiB0
aGVpciBuYXRpdmUgYXBwcyAobW9iaWxlLCBkZXNrdG9wLCBldGMuKSB3aGVyZSB0aGUgYXBwIHBy
b3ZpZGVyIGhhcyBjb250cm9sIG92ZXIgdGhlIGZ1bGwgc3RhY2ssIGFuZCBzdGlsbCB3b3JrIHdp
dGggY2xpZW50cyBvZiB0aGF0IHNlcnZpY2Ugd2hpY2ggcnVuIGluIHRoZSBicm93c2VyLCB3aGVy
ZSB0aGUgYXBwIHByb3ZpZGVyIGRvZXMgbm90IGhhdmUgY29udHJvbCBvdmVyIHRoZSBmdWxsIHN0
YWNrIGFzIHRoZSByZWFsLXRpbWUgbWVkaWEgc3RhY2sgaXMgcHJvdmlkZWQgYnkgdGhlIGJyb3dz
ZXIgYW5kIG5vdCB0aGUgd2ViIGFwcC4mbmJzcDs8YnI+DQo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48
ZGl2PlRoZSBiZW5lZml0IG9mIHRoaXMgYXBwcm9hY2ggaXMgdGhhdCBpdCBlbmFibGVzIGludGVy
b3BlcmFiaWxpdHkgYmV0d2VlbiBjbGllbnRzIG9uIGRpZmZlcmVudCBwbGF0Zm9ybXMgZm9yIHRo
ZSBzYW1lIHByb3ZpZGVyLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhlIGRyYXdiYWNrIGlz
LCBmb3IgaW50ZXItc2VydmljZSBmZWRlcmF0aW9uICh3aGljaCByZXF1aXJlcyBtdWNoIG1vcmUg
dGhhbiBqdXN0IGNvZGVjcyB0byBiZSBhbGlnbmVkKSwgeW91IG1pZ2h0IHJ1biBpbnRvIGEgY2Fz
ZSB3aGVyZSBhIHVzZXIgdXNpbmcgYSBtb2JpbGUgYXBwIGZyb20gcHJvdmlkZXIgMSAoc2F5LCBT
a3lwZSkgY2FsbHMgYSB1c2VyIHVzaW5nIGEgbW9iaWxlIGFwcCBmcm9tIHByb3ZpZGVyIDIgKHNh
eSwgSGFuZ291dHMpLCBhbmQgdGhlbiBzaW5jZSBlYWNoIGNob3NlIGEgZGlmZmVyZW50IHZpZGVv
IGNvZGVjLCB0aGVyZSBpcyBubyBjb21tb24gY29kZWMuIE9mIGNvdXJzZSB0aGF0IGFzc3VtZXMg
dGhlIHR3byBwcm92aWRlcnMgaW4gcXVlc3Rpb24gYXJlIHdpbGxpbmcgdG8gZXZlbiBmZWRlcmF0
ZSBpbiB0aGUgZmlyc3QgcGxhY2UuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj48L2Rpdj48ZGl2Pi1K
b25hdGhhbiBSLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXYg
Y2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBX
ZWQsIE5vdiAxMywgMjAxMyBhdCA1OjE3IFBNLCBTdGVwaGFuIFdlbmdlciA8c3BhbiBkaXI9Imx0
ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpzdGV3ZUBzdGV3ZS5vcmciIHRhcmdldD0iX2JsYW5rIj5z
dGV3ZUBzdGV3ZS5vcmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xh
c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4
ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+SGkgR29uemFsbyw8YnI+DQpSZSB5b3VyIHBv
aW50IDUuOiDCs2VpdGhlciBvcsKyIGlzIG9mdGVuIHVuZGVyc3Rvb2QgYXMgYW4gZXhjbHVzaXZl
IG9yLiAmbmJzcDtJPGJyPg0KZG9uwrl0IHRoaW5rIGFueW9uZSBwcm9wb3NlZCB0aGF0LiAmbmJz
cDtBIGJldHRlciB3YXkgdG8gZXhwcmVzcyA1LiB3b3VsZCBiZTxicj4NCsKzQWxsIGVudGl0aWVz
IE1VU1Qgc3VwcG9ydCBhdCBsZWFzdCBvbmUgb2YgSC4yNjQgYW5kIFZQOMKyLjxicj4NClN0ZXBo
YW48YnI+DQo8YnI+DQpPbiAxMS4xMy4yMDEzLCAxMjoyMyAsICJHb256YWxvIENhbWFyaWxsbyI8
YnI+DQo8ZGl2IGNsYXNzPSJIT0VuWmIiPjxkaXYgY2xhc3M9Img1Ij4mbHQ7PGEgaHJlZj0ibWFp
bHRvOkdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbSI+R29uemFsby5DYW1hcmlsbG9AZXJp
Y3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0O0ZvbGtzLDxicj4NCiZndDs8
YnI+DQomZ3Q7SSBob3BlIGV2ZXJ5Ym9keSBoYWQgYSBzYWZlIHRyaXAgYmFjayBob21lIGFmdGVy
IFZhbmNvdXZlci48YnI+DQomZ3Q7PGJyPg0KJmd0O0FzIHlvdSBhbGwga25vdywgd2UgbmVlZCB0
byBtYWtlIHByb2dyZXNzIHJlZ2FyZGluZyB0aGUgc2VsZWN0aW9uIG9mIHRoZTxicj4NCiZndDtN
VEkgdmlkZW8gY29kZWMuIFRoZSBmb2xsb3dpbmcgYXJlIHNvbWUgb2YgdGhlIGFsdGVybmF0aXZl
cyB3ZSBoYXZlIG9uPGJyPg0KJmd0O3RoZSB0YWJsZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAxLiBB
bGwgZW50aXRpZXMgTVVTVCBzdXBwb3J0IEguMjY0PGJyPg0KJmd0OyAyLiBBbGwgZW50aXRpZXMg
TVVTVCBzdXBwb3J0IFZQODxicj4NCiZndDsgMy4gQWxsIGVudGl0aWVzIE1VU1Qgc3VwcG9ydCBi
b3RoIEguMjY0IGFuZCBWUDg8YnI+DQomZ3Q7IDQuIEJyb3dzZXJzIE1VU1Qgc3VwcG9ydCBib3Ro
IEguMjY0IGFuZCBWUDg8YnI+DQomZ3Q7IDUuIEFsbCBlbnRpdGllcyBNVVNUIHN1cHBvcnQgZWl0
aGVyIEguMjY0IG9yIFZQODxicj4NCiZndDsgNi4gQWxsIGVudGl0aWVzIE1VU1Qgc3VwcG9ydCBI
LjI2MTxicj4NCiZndDsgNy4gVGhlcmUgaXMgbm8gTVRJIHZpZGVvIGNvZGVjPGJyPg0KJmd0Ozxi
cj4NCiZndDtJZiB5b3Ugd2FudCB0aGUgZ3JvdXAgdG8gY29uc2lkZXIgYWRkaXRpb25hbCBhbHRl
cm5hdGl2ZXMgdG8gdGhlIG9uZXM8YnI+DQomZ3Q7YWJvdmUsIHBsZWFzZSBsZXQgdGhlIGdyb3Vw
IGtub3cgd2l0aGluIHRoZSBmb2xsb3dpbmcgKnR3byB3ZWVrcyouIEF0PGJyPg0KJmd0O3RoYXQg
cG9pbnQsIHRoZSBjaGFpcnMgd2lsbCBiZSBsaXN0aW5nIGFsbCB0aGUgcmVjZWl2ZWQgYWx0ZXJu
YXRpdmVzIGFuZDxicj4NCiZndDtwcm9wb3NpbmcgYSBwcm9jZXNzIHRvIHNlbGVjdCBvbmUgYW1v
bmcgdGhlbS48YnI+DQomZ3Q7PGJyPg0KJmd0O1BsZWFzZSwgc2VuZCB5b3VyIHByb3Bvc2FscyBp
biBhbiBlbWFpbCB0byB0aGUgbGlzdC4gWW91IGRvIG5vdCBuZWVkIHRvPGJyPg0KJmd0O3dyaXRl
IGEgZHJhZnQ7IGp1c3Qgc2VuZCB0aGUgdGV4dCB5b3Ugd291bGQgbGlrZSB0byBzZWUgaW4gdGhl
IGZpbmFsPGJyPg0KJmd0O2RvY3VtZW50IHJlZ2FyZGluZyB2aWRlbyBjb2RlY3MuPGJyPg0KJmd0
Ozxicj4NCiZndDtUaGFua3MsPGJyPg0KJmd0Ozxicj4NCiZndDtHb256YWxvPGJyPg0KJmd0O1Jl
c3BvbnNpYmxlIEFEIGZvciB0aGlzIFdHPGJyPg0KJmd0Ozxicj4NCiZndDtfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDtydGN3ZWIgbWFpbGlu
ZyBsaXN0PGJyPg0KJmd0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBp
ZXRmLm9yZzwvYT48YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJy
Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIi
IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0
Y3dlYjwvYT48YnI+DQo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVh
cj0iYWxsIj48ZGl2Pjxicj48L2Rpdj4tLSA8YnI+PGRpdiBkaXI9Imx0ciI+Sm9uYXRoYW4gUm9z
ZW5iZXJnLCBQaC5ELjxicj48YSBocmVmPSJtYWlsdG86amRyb3NlbkBqZHJvc2VuLm5ldCIgdGFy
Z2V0PSJfYmxhbmsiPmpkcm9zZW5AamRyb3Nlbi5uZXQ8L2E+PGJyPjxhIGhyZWY9Imh0dHA6Ly93
d3cuamRyb3Nlbi5uZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lmpkcm9zZW4ubmV0PC9h
PjwvZGl2Pg0KDQo8L2Rpdj4NCjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJj
aXRlIj48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPC9zcGFuPjxicj48c3Bhbj5ydGN3ZWIgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bh
bj48YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PC9z
cGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3J0Y3dlYiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8
L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4=

--Apple-Mail-84F4C0E3-121E-4704-A243-25C72DC89141--

--_f95510b1-0930-43b3-88af-d43f59cd2afd_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--_f95510b1-0930-43b3-88af-d43f59cd2afd_--

From cb.list6@gmail.com  Wed Nov 13 20:11:38 2013
Return-Path: 
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 235AC11E80DE for ; Wed, 13 Nov 2013 20:11:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.459
X-Spam-Level: 
X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 S0FqBArRKMgR for ; Wed, 13 Nov 2013 20:11:30 -0800 (PST)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECD611E812A for ; Wed, 13 Nov 2013 20:11:30 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id x55so1344898wes.27 for ; Wed, 13 Nov 2013 20:11:25 -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=OrT6qzNAeOVwBnrNGuOd4p6KhX8nAmsux4yvKeTPBq0=; b=ZwesNrMK4MXBYbhadHlfxwoNQTUerj7shWCPSnQNUZqkq4Qr7XWAiCn7nlYpobQreh pBKtIYExIaIrzBpMZkspYAuzFQ8eYVcX8Uwia0Ug9/ggKQdf0GOiZPRcIItlYAD7JV8I 2WCPdSdavASNnlzN/7OsP9M2Bc+vwbBQQU0xVP0YZD/T5rNqKGLi6WuGciXytuOGuNgT AITbYsMaLCIzL8sD/bUtXeUiOEP+hkinb3SqPQ0TY946z1HW2I8Kpveu2uP1dpmQYgZy eTSzRsqlWos8ShjaRmI5W9qlN+bbrt8TGWUy3pWehfyFR73g7b14OfoDCfvbgB8cVyIW qp3w==
MIME-Version: 1.0
X-Received: by 10.194.187.101 with SMTP id fr5mr222483wjc.76.1384402285774; Wed, 13 Nov 2013 20:11:25 -0800 (PST)
Received: by 10.216.99.68 with HTTP; Wed, 13 Nov 2013 20:11:25 -0800 (PST)
Received: by 10.216.99.68 with HTTP; Wed, 13 Nov 2013 20:11:25 -0800 (PST)
In-Reply-To: <5283DFDC.4010906@ericsson.com>
References: <5283DFDC.4010906@ericsson.com>
Date: Wed, 13 Nov 2013 20:11:25 -0800
Message-ID: 
From: "cb.list6" 
To: Gonzalo Camarillo 
Content-Type: multipart/alternative; boundary=047d7bd6b9ac784dd404eb1b46e6
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 04:11:38 -0000

--047d7bd6b9ac784dd404eb1b46e6
Content-Type: text/plain; charset=ISO-8859-1

Why no SHOULD implement vp8 and h248? SHOULD means you will do it unless
you have a real good reason.

MUST is too hard for this WG.  Many implementations have a really good
reason to not do vp8 OR h248.

Saying that all webrtc MUST do one or the other or both is disingenuous.

SHOULD for both is as good as we are going to get with this complicated IPR
environment.  Using MUST is simply not going to work and we have 10,000 on
this mailer to back that up.

Cameron
On Nov 13, 2013 12:24 PM, "Gonzalo Camarillo" <
Gonzalo.Camarillo@ericsson.com> wrote:

> Folks,
>
> I hope everybody had a safe trip back home after Vancouver.
>
> As you all know, we need to make progress regarding the selection of the
> MTI video codec. The following are some of the alternatives we have on
> the table:
>
>  1. All entities MUST support H.264
>  2. All entities MUST support VP8
>  3. All entities MUST support both H.264 and VP8
>  4. Browsers MUST support both H.264 and VP8
>  5. All entities MUST support either H.264 or VP8
>  6. All entities MUST support H.261
>  7. There is no MTI video codec
>
> If you want the group to consider additional alternatives to the ones
> above, please let the group know within the following *two weeks*. At
> that point, the chairs will be listing all the received alternatives and
> proposing a process to select one among them.
>
> Please, send your proposals in an email to the list. You do not need to
> write a draft; just send the text you would like to see in the final
> document regarding video codecs.
>
> Thanks,
>
> Gonzalo
> Responsible AD for this WG
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--047d7bd6b9ac784dd404eb1b46e6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Why no SHOULD implement vp8 and h248? SHOULD means you will =
do it unless you have a real good reason.


MUST is too hard for this WG.=A0 Many implementations have a=
 really good reason to not do vp8 OR h248. 


Saying that all webrtc MUST do one or the other or both is d=
isingenuous.


SHOULD for both is as good as we are going to get with this =
complicated IPR environment.=A0 Using MUST is simply not going to work and =
we have 10,000 on this mailer to back that up. 


Cameron


On Nov 13, 2013 12:24 PM, "Gonzalo Camarill=
o" <Gonzalo.Camar=
illo@ericsson.com> wrote:

Folks,



I hope everybody had a safe trip back home after Vancouver.



As you all know, we need to make progress regarding the selection of the
MTI video codec. The following are some of the alternatives we have on

the table:



=A01. All entities MUST support H.264

=A02. All entities MUST support VP8

=A03. All entities MUST support both H.264 and VP8

=A04. Browsers MUST support both H.264 and VP8

=A05. All entities MUST support either H.264 or VP8

=A06. All entities MUST support H.261

=A07. There is no MTI video codec



If you want the group to consider additional alternatives to the ones

above, please let the group know within the following *two weeks*. At

that point, the chairs will be listing all the received alternatives and
proposing a process to select one among them.



Please, send your proposals in an email to the list. You do not need to

write a draft; just send the text you would like to see in the final

document regarding video codecs.



Thanks,



Gonzalo

Responsible AD for this WG



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb




--047d7bd6b9ac784dd404eb1b46e6--

From bernard_aboba@hotmail.com  Wed Nov 13 20:29:36 2013
Return-Path: 
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 F089E21F9C69 for ; Wed, 13 Nov 2013 20:29:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.646
X-Spam-Level: 
X-Spam-Status: No, score=-101.646 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
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 kQ84DUBDjMNF for ; Wed, 13 Nov 2013 20:29:31 -0800 (PST)
Received: from blu0-omc1-s35.blu0.hotmail.com (blu0-omc1-s35.blu0.hotmail.com [65.55.116.46]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDED21F9D56 for ; Wed, 13 Nov 2013 20:29:31 -0800 (PST)
Received: from BLU403-EAS268 ([65.55.116.7]) by blu0-omc1-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 13 Nov 2013 20:29:22 -0800
X-TMN: [Ek32bWse53fm3ipob9sZegMs5Ug0mlbb]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: <5283DF61.9060807@alvestrand.no> <201311132211.rADMBaBD011692@rcdn-core2-5.cisco.com> <52843288.5000507@alvestrand.no>
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
In-Reply-To: <52843288.5000507@alvestrand.no>
Date: Wed, 13 Nov 2013 20:29:19 -0800
To: Harald Alvestrand 
X-OriginalArrivalTime: 14 Nov 2013 04:29:22.0401 (UTC) FILETIME=[17A96D10:01CEE0F2]
Cc: "rtcweb@ietf.org" , "rai-ads@tools.ietf.org" , "tsv-ads@tools.ietf.org" 
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 04:29:36 -0000

> I want this group to be done. As long as I can't even point to the
> document that describes how we do QoS, I have no chance of getting it to
> that stage.

[BA] The approach of dispersing work among half a dozen WGs isn't working in=
 this case, and in fact hasn't worked particularly well in the past either, b=
ecause it generates neither urgency nor focus.=20

At this point, we are probably not much more than a year away from widesprea=
d deployment of  running code. So if a critical dependency is not making pro=
gress toward a WGLC it is time to hit reset. The reality is that there is no=
 reservoir of undiscovered manpower to get this work done, just interested a=
uthors and reviewers who if fed a steady stream of documents without unneces=
sary distractions and bureaucratic impediments can help us rapidly get to cl=
osure.=20

Our current process is akin to shuttling children from one neglectful foster=
 home to another until we lose track of them and realize to our dismay that s=
omething bad has happened. This isn't a plan so much as an accident waiting t=
o happen.




>=20
>=20
>>=20
>> At 02:21 PM 11/13/2013, Harald Alvestrand wrote:
>>> This mail concerns both administrative and technical issues, which is
>>> why it is explicitly copied to the ADs of RAI and TSV. I hope I have
>>> managed to keep them separate in the message.
>>>=20
>>> Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:
>>>=20
>>>> Okay, we might not have been public enough on this. It was
>>> requested by
>>>> the Transport ADs quite some time ago that doing the QoS document
>>> in our
>>>> WG was not appropriate and requested us to direct the document to
>>> TSVWG.
>>>> Which was done, and where it hasn't made progress.
>>>>=20
>>>> You might have noted that James Polk did comment in the milestone part
>>>> in the monday session of IETF88 about our QoS milestone should be
>>> killed.
>>> I want to protest this - both practically and formally.
>>>=20
>>> To get the formal stuff out of the way first:
>>>=20
>>> Changing the deliverables of the working group *without telling the
>>> working group* is totally inappropriate in an open, consensus-driven
>>> process.
>>> Changing the deliverables of the working group *without telling the
>>> working group why* and *without allowing those reasons to be debated* is=

>>> totally inappropriate in an open, consensus-driven process.
>>>=20
>>> I protest against this action.
>>>=20
>>> ACTION REQUEST 1: I request that this decision be declared null and
>>> void, and that the relevant ADs send out a message to RTCWEB (and TSVWG
>>> if appropriate) *PROPOSING* such an action, and giving a reasonable
>>> timeline for when they will make a decision based on mailing list
>>> feedback.
>>>=20
>>> In practice:
>>>=20
>>> The draft as it existed before its untimely demise consisted of two
>>> things:
>>>=20
>>> - A description of how QoS mechanisms could be useful in the RTCWEB
>>> use case
>>> - A description of existing mechanisms that could be appropriate for the=

>>> RTCWEB use case
>>>=20
>>> The first one is clearly something that needs RTCWEB consensus. It seems=

>>> to have no need for, nor likelyhood of gathering interest enough for, a
>>> TSVWG consensus.
>>>=20
>>> There could be some argument that the second part needs TSVWG consensus,=

>>> especially if it was redefining any mechanisms, or it was making choices=

>>> between mechanisms where TSVWG had strong opinions about which
>>> mechanisms should be chosen, but had not chosen to document that in any
>>> document on which IETF consensus had been declared (that is to say,
>>> existing RFCs).
>>>=20
>>> My archive shows 36 messages where the title refers to this draft. It
>>> shows no messages declaring that feedback has been incorporated and
>>> calling for new review - something that is usually necessary to get a WG=

>>> consensus on any document. The debate hasn't been conclusive, but then,
>>> it hasn't been pushed hard either.
>>>=20
>>> The people who know how RTCWEB works are in this working group. Some of
>>> them may be in TSV, but I think the locus of knowledge for saying what
>>> QoS mechanisms are appropriate for RTCWEB are here, not in TSV.
>>>=20
>>> This results in my second request.
>>>=20
>>> ACTION REQUEST 2: I request that the chairs declare that based on the
>>> debate about the QoS functionality so far, the document should be
>>> resurrected, and will continue to be  worked on in the RTCWEB working
>>> group, bringing in advice from TSVWG as required to make sure the
>>> descriptions of underlying mechanisms, and the choice of such
>>> mechanisms, is correct and appropriate.
>>>=20
>>>=20
>>>=20
>>>=20
>>> --=20
>>> Surveillance is pervasive. Go Dark.
>>>=20
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
>=20
> --=20
> Surveillance is pervasive. Go Dark.
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From robin@hookflash.com  Wed Nov 13 20:34:57 2013
Return-Path: 
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 3442A21E8198 for ; Wed, 13 Nov 2013 20:34:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.037
X-Spam-Level: 
X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 ourmR3wnBnA2 for ; Wed, 13 Nov 2013 20:34:52 -0800 (PST)
Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 46D9721E819C for ; Wed, 13 Nov 2013 20:34:50 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id u56so1317545wes.18 for ; Wed, 13 Nov 2013 20:34:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=L7PDFqL3LdaYoWB7kOrnf3V50iz1eJ2UrUQxRRSfkA8=; b=aKuH7RxZlYgVnxu5FuvR3GJFnfKWY3sUXllYrJFQt0km/+RKlHDnOP/yMZ7oXAOd6t 6ZeSKT2mFVdlowdZ8Oo/qO3odedIy10qhfZllpGz4MRh2BGWYCPNDc9ov2BrNRwdFep3 JdNNcH7mwuwB3i8j48oKGahW+eUfKnvvOSIQ3jCsaJU4aRpBGPhajVql6hFoexs0JISI yi6LQL3ZHKFEvi8d1C8e251/O9ssbeMIJmzTHj897sx+S5f+V/KNFsbXVA3haSBnEplW fX3616ogxIBdd1qw72A6XBLAK2bIF7qL7MK86fzSkrjja/wMJGVKPykYDDSxSwqsBRUZ /63w==
X-Gm-Message-State: ALoCoQnEKFzRuwDlmlEQd+phngi2uAFzsL7rPx+H7CjsrUeLrosTRMoKjDhrA8M3Bp9F1jkeZB7E
X-Received: by 10.180.185.130 with SMTP id fc2mr314288wic.43.1384403690210; Wed, 13 Nov 2013 20:34:50 -0800 (PST)
Received: from Robins-MacBook-Pro.local (S010678cd8e61db1f.vn.shawcable.net. [174.7.103.13]) by mx.google.com with ESMTPSA id y20sm2421367wib.0.2013.11.13.20.34.47 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 20:34:49 -0800 (PST)
Message-ID: <528452E5.9010205@hookflash.com>
Date: Wed, 13 Nov 2013 20:34:45 -0800
From: Robin Raymond 
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: "cb.list6" 
References: <5283DFDC.4010906@ericsson.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080406020300090304030508"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 04:34:57 -0000

This is a multi-part message in MIME format.
--------------080406020300090304030508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


+1 to SHOULD option for both VP8 and H264.

MUST is too strong.

I think there's strong reasons why most people would include both and 
that's simply because of market forces and install base. Why be 
incompatible and make your product look weak and incompatible if there 
is a reasonable option. With Cisco's announcement that people who can 
take H264 likely will if they feel comfortable enough with IPR exposure. 
For those whom have IPR issues, they will either license or no amount of 
"mandate" is going to force them to accept exposure they aren't willing 
to risk even listed as an MTI.

"SHOULD" seems reasonable and logical to me with no MTI.

Robin



> cb.list6 
> 13 November, 2013 8:11 PM
>
> Why no SHOULD implement vp8 and h248? SHOULD means you will do it 
> unless you have a real good reason.
>
> MUST is too hard for this WG.  Many implementations have a really good 
> reason to not do vp8 OR h248.
>
> Saying that all webrtc MUST do one or the other or both is disingenuous.
>
> SHOULD for both is as good as we are going to get with this 
> complicated IPR environment.  Using MUST is simply not going to work 
> and we have 10,000 on this mailer to back that up.
>
> Cameron
>
>

--------------080406020300090304030508
Content-Type: multipart/related;
 boundary="------------010901090301060205060800"


--------------010901090301060205060800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit





+1 to SHOULD option for both VP8 and H264.



MUST is too strong.



I think there's strong reasons why most people would include both and 
that's simply because of market forces and install base. Why be 
incompatible and make your product look weak and incompatible if there 
is a reasonable option. With Cisco's announcement that people who can 
take H264 likely will if they feel comfortable enough with IPR exposure.
 For those whom have IPR issues, they will either license or no amount 
of "mandate" is going to force them to accept exposure they aren't 
willing to risk even listed as an MTI.



"SHOULD" seems reasonable and logical to me with no MTI.



Robin









  
 	
      
   
  13 November, 2013
 8:11 PM

  
Why no SHOULD 
implement vp8 and h248? SHOULD means you will do it unless you have a 
real good reason.


MUST is too hard for this WG.  Many implementations have a 
really good reason to not do vp8 OR h248. 


Saying that all webrtc MUST do one or the other or both is 
disingenuous.


SHOULD for both is as good as we are going to get with this
 complicated IPR environment.  Using MUST is simply not going to work 
and we have 10,000 on this mailer to back that up. 


Cameron


  





--------------010901090301060205060800
Content-Type: image/jpeg; x-apple-mail-type=stationery;
 name="compose-unknown-contact.jpg"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="compose-unknown-contact.jpg"

/9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC
AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC
AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR
CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK
BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA
AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA
DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ
VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4
v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx
+a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR
UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab
eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz
hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi
yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y
zqnlfp6FrqbwawG8/9k=
--------------010901090301060205060800--

--------------080406020300090304030508--

From cowwoc@bbs.darktech.org  Wed Nov 13 21:21:13 2013
Return-Path: 
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 7468A21E81B3 for ; Wed, 13 Nov 2013 21:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.151
X-Spam-Level: 
X-Spam-Status: No, score=-4.151 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 YG-EVPj1hHdY for ; Wed, 13 Nov 2013 21:21:07 -0800 (PST)
Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6737121E81B0 for ; Wed, 13 Nov 2013 21:21:07 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id x13so2057108ief.18 for ; Wed, 13 Nov 2013 21:21:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=dyIdEdfuxPR82AmKCeQ7EQ/3MlFyjuMF/LW2zNaHsaI=; b=iiW9KR5c7ROhrY0wfLOOo5UwYHs6V9dHergbLsQfEs8IMGxC8jQ/8zofhx9jAYioch Z1XfUkg++OkNGAZ5VPTlEUkoWgJF5FxjqVWHVfy7kLI1hdQN1fs3krLDmloNZaM6VOOT PJkIxx8yqmg1hSC14vIz5i3YTdWM7mJXcZInH9oCpeB9mZsTmovHrv/xcIICFGVizwt9 0zEFiXV9wt9EBoy+5L+eqirRbdLWNjaZA1w1whuMP9uIbnvEOe4YB5YaDO9vMV1cZCT2 wuLLryB5D+jg/UjRD+brllfoFQm12M+p1yssBBFOtQ6SOgN2tPet7QpvhHLwstT8yYAB Jn2A==
X-Gm-Message-State: ALoCoQmqH+DB+UGaSaWwd686y95HW9Sc3ycrZ2SMmO4lKGHQUvrzyyueE5tAVE5LDXY3UnCiU1ZE
X-Received: by 10.50.78.196 with SMTP id d4mr399255igx.2.1384406466758; Wed, 13 Nov 2013 21:21:06 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ka5sm34585371igb.2.2013.11.13.21.21.05 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 21:21:05 -0800 (PST)
Message-ID: <52845DB0.6040501@bbs.darktech.org>
Date: Thu, 14 Nov 2013 00:20:48 -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: Michael Thornburgh 
References: <5282A340.7010405@gondwanaland.com>	<20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>	 <5283FDF1.8030708@bbs.darktech.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030804050309070006030602"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 05:21:13 -0000

This is a multi-part message in MIME format.
--------------030804050309070006030602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Really? I've never seen a single P2P video chat app in Flash. What 
specifically does "P2P for real time communication" actually mean?

Gili

On 13/11/2013 6:32 PM, Michael Thornburgh wrote:
>
> > The real revolution is P2P: massive cost savings, ease of deployment 
> and most importantly: cutting out the middle man. The status quo 
> (H.264 over Flash) does not do this.
>
> note: Flash has had P2P for real time communication since 2009.
>
> -michael thornburgh
>
> *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On 
> Behalf Of *cowwoc
> *Sent:* Wednesday, November 13, 2013 2:32 PM
> *To:* Kaiduan Xie
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] ~"I'd love it if patents evaporated...If not 
> now, when"
>
>
> I agree. I'm just pointing out that John's argument (quoted below) 
> doesn't make any sense. Choosing "no MTI" doesn't make Cisco any more 
> likely to implement VP8.
>
> If we choose "No MTI" we will end up with transcoding, plain and 
> simple. One crowd will only implement H.264. The other crowd will only 
> implement VP8. All the useless middlemen will rejoice, having killed a 
> technology that puts them out of business.
>
> Providing "video chat without a plugin" is not revolutionary. Flash is 
> already installed on 95% of the market. That's more people than WebRTC 
> can reach today, so we're not "liberating" those people from anything.
>
> The real revolution is P2P: massive cost savings, ease of deployment 
> and most importantly: cutting out the middle man. The status quo 
> (H.264 over Flash) does not do this.
>
> P2P cannot work unless 95% of clients can agree on a common codec. I 
> say again: start with H.261 and upgrade to VP8 or H.264. This way 
> everyone can be happy:
>
>   * The VP8 crowd can use VP8
>   * The H264 crowd can use H264
>   * The enterprise crowd can transcode
>   * If all of the above fails, we can fallback on H.261.
>
> Yes, this carries the burden of implementing H.261 but this is a 
> solved-problem. There are plenty of free implementations and is a much 
> easier problem to solve than getting the H.264 and VP8 crowd to agree 
> to implement each other's codec.
>
> Start with H.261 and replace it the moment you find something better. 
> Forcing us to transcode or drop video calls is not a solution.
>
> Gili
>
> On 13/11/2013 4:57 PM, Kaiduan Xie wrote:
>
>     "if an implementer gets sued they can simply drop the codec"
>
>     Thing is not that simple as "simply drop the codec", for some case
>     you still have to pay a lot of money.
>
>     /Kaiduan
>
>
>     On 13/11/2013 11:55 AM, John Leslie wrote:
>
>                 And I claim that both camps are actually more likely
>             to implement
>             (or allow extensions for) the other side's codec if it is
>             _not_ MTI,
>             simply because they can back out at the first sign of lawyers.
>


--------------030804050309070006030602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    


      Really? I've never seen a single P2P video chat app in Flash. What
      specifically does "P2P for real time communication" actually mean?

      

      Gili

      

      On 13/11/2013 6:32 PM, Michael Thornburgh wrote:

    

    

      
      
      
      

        
>
            The real revolution is P2P: massive cost savings, ease of
            deployment and most importantly: cutting out the middle man.
            The status quo (H.264 over Flash) does not do this.

        
 

        
note:
            Flash has had P2P for real time communication since 2009.

        
 

        
-michael
            thornburgh

        
 

        

          

            

              
From:
                  rtcweb-bounces@ietf.org
                  [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc

                  Sent: Wednesday, November 13, 2013 2:32 PM

                  To: Kaiduan Xie

                  Cc: rtcweb@ietf.org

                  Subject: Re: [rtcweb] ~"I'd love it if patents
                  evaporated...If not now, when"

            

          

          
 

          

            


              I agree. I'm just pointing out that John's argument
              (quoted below) doesn't make any sense. Choosing "no MTI"
              doesn't make Cisco any more likely to implement VP8.

              

              If we choose "No MTI" we will end up with transcoding,
              plain and simple. One crowd will only implement H.264. The
              other crowd will only implement VP8. All the useless
              middlemen will rejoice, having killed a technology that
              puts them out of business.

              

              Providing "video chat without a plugin" is not
              revolutionary. Flash is already installed on 95% of the
              market. That's more people than WebRTC can reach today, so
              we're not "liberating" those people from anything.

              

              The real revolution is P2P: massive cost savings, ease of
              deployment and most importantly: cutting out the middle
              man. The status quo (H.264 over Flash) does not do this.

              

              P2P cannot work unless 95% of clients can agree on a
              common codec. I say again: start with H.261 and upgrade to
              VP8 or H.264. This way everyone can be happy:

            
    
              
  • The VP8 crowd can use VP8
    • 
              
  • The H264 crowd can use H264
    • 
              
  • The enterprise crowd can transcode
    • 
              
  • If all of the above fails, we can fallback
                on H.261.
    • 
            

            
Yes, this carries the burden of implementing H.261 but
              this is a solved-problem. There are plenty of free
              implementations and is a much easier problem to solve than
              getting the H.264 and VP8 crowd to agree to implement each
              other's codec.

            
Start with H.261 and replace it the moment you find
              something better. Forcing us to transcode or drop video
              calls is not a solution.

            
Gili

            
On 13/11/2013 4:57 PM, Kaiduan Xie
              wrote:

          

          

            

              
"if
                  an implementer gets sued they can simply drop the
                  codec"

              

                
 

              

              

                
Thing
                    is not that simple as "simply drop the codec", for
                    some case you still have to pay a lot of money.

              

              

                
 

              

              

                
/Kaiduan

              

            

            

              


                On 13/11/2013 11:55 AM, John Leslie wrote:

              

                

                  

                    

                      

                        
    And I claim that both
                          camps are actually more likely to implement

                          (or allow extensions for) the other side's
                          codec if it is _not_ MTI,

                          simply because they can back out at the first
                          sign of lawyers.

                      

                    

                  

                

              

            

          

          
 

        

      

    

    

  


--------------030804050309070006030602--

From fluffy@cisco.com  Wed Nov 13 21:21:20 2013
Return-Path: 
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 47DCC21E81B2 for ; Wed, 13 Nov 2013 21:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.583
X-Spam-Level: 
X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 7OsAej+56RyP for ; Wed, 13 Nov 2013 21:21:15 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 38BAD21E81BB for ; Wed, 13 Nov 2013 21:21:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6168; q=dns/txt; s=iport; t=1384406475; x=1385616075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V6GRqgr2QJAlJHE64UHHAoiuWn6w7uq5vF/OpKAU0EM=; b=dNHqpdj/pOu7WCVw6LEqe6ZQx5cqqb09+QNPfuXq+DCLpsbqhiA2CbBP qib8bQAvo2CL6CjRFSegYaWz9KLRuJMUS1Zf/E8TCqa1yN+WRi9cDq4rm DsBrgfWCWYhmBVUrz1WWKDFHyamK/nBiBF24H11T1NAU9FXRfgr92aQLj c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FANpchFKtJV2a/2dsb2JhbABZgwc4U6xJkhdLgSkWdIIlAQEBAwEBAQEaHTQGBRACAQgYHhAnCyUCBAENBYdvAwkGDb9DBIxtgSkQgQYzB4MggREDliaBaoxUhTiDKIFxOQ
X-IronPort-AV: E=Sophos;i="4.93,697,1378857600"; d="scan'208";a="284579927"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 14 Nov 2013 05:21:14 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAE5LEVP016192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 05:21:14 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 23:21:14 -0600
From: "Cullen Jennings (fluffy)" 
To: "tsv-ads@tools.ietf.org" , David Black 
Thread-Topic: [rtcweb] Protesting the QoS document decision
Thread-Index: AQHO4PlVPlkJmTapqkioqraFxaneyw==
Date: Thu, 14 Nov 2013 05:21:13 +0000
Message-ID: 
References: <5283DF61.9060807@alvestrand.no> <201311132211.rADMBaBD011692@rcdn-core2-5.cisco.com> <52843288.5000507@alvestrand.no> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9C1E797C3726614DA9AA3857EAB14400@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "rai-ads@tools.ietf.org Area" 
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 05:21:20 -0000

I'm trying to not say much on this whole thread but I wonder if the tsv-ad =
could provide any more insight around why this was appropriate for TSV.=20

It's not assigning any new DSCP, it's simply providing pointers to the exis=
ting codes defined in documents done by TSV that talk about the DSCP to use=
 for audio, video, and such. I think if folks could help people understand =
what transport content was, that would help. (and added David as he has bee=
n involved with this draft )=20

Cullen in my individual contributor role.=20

On Nov 13, 2013, at 9:29 PM, Bernard Aboba  wrot=
e:

>> I want this group to be done. As long as I can't even point to the
>> document that describes how we do QoS, I have no chance of getting it to
>> that stage.
>=20
> [BA] The approach of dispersing work among half a dozen WGs isn't working=
 in this case, and in fact hasn't worked particularly well in the past eith=
er, because it generates neither urgency nor focus.=20
>=20
> At this point, we are probably not much more than a year away from widesp=
read deployment of  running code. So if a critical dependency is not making=
 progress toward a WGLC it is time to hit reset. The reality is that there =
is no reservoir of undiscovered manpower to get this work done, just intere=
sted authors and reviewers who if fed a steady stream of documents without =
unnecessary distractions and bureaucratic impediments can help us rapidly g=
et to closure.=20
>=20
> Our current process is akin to shuttling children from one neglectful fos=
ter home to another until we lose track of them and realize to our dismay t=
hat something bad has happened. This isn't a plan so much as an accident wa=
iting to happen.
>=20
>=20
>=20
>=20
>>=20
>>=20
>>>=20
>>> At 02:21 PM 11/13/2013, Harald Alvestrand wrote:
>>>> This mail concerns both administrative and technical issues, which is
>>>> why it is explicitly copied to the ADs of RAI and TSV. I hope I have
>>>> managed to keep them separate in the message.
>>>>=20
>>>> Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:
>>>>=20
>>>>> Okay, we might not have been public enough on this. It was
>>>> requested by
>>>>> the Transport ADs quite some time ago that doing the QoS document
>>>> in our
>>>>> WG was not appropriate and requested us to direct the document to
>>>> TSVWG.
>>>>> Which was done, and where it hasn't made progress.
>>>>>=20
>>>>> You might have noted that James Polk did comment in the milestone par=
t
>>>>> in the monday session of IETF88 about our QoS milestone should be
>>>> killed.
>>>> I want to protest this - both practically and formally.
>>>>=20
>>>> To get the formal stuff out of the way first:
>>>>=20
>>>> Changing the deliverables of the working group *without telling the
>>>> working group* is totally inappropriate in an open, consensus-driven
>>>> process.
>>>> Changing the deliverables of the working group *without telling the
>>>> working group why* and *without allowing those reasons to be debated* =
is
>>>> totally inappropriate in an open, consensus-driven process.
>>>>=20
>>>> I protest against this action.
>>>>=20
>>>> ACTION REQUEST 1: I request that this decision be declared null and
>>>> void, and that the relevant ADs send out a message to RTCWEB (and TSVW=
G
>>>> if appropriate) *PROPOSING* such an action, and giving a reasonable
>>>> timeline for when they will make a decision based on mailing list
>>>> feedback.
>>>>=20
>>>> In practice:
>>>>=20
>>>> The draft as it existed before its untimely demise consisted of two
>>>> things:
>>>>=20
>>>> - A description of how QoS mechanisms could be useful in the RTCWEB
>>>> use case
>>>> - A description of existing mechanisms that could be appropriate for t=
he
>>>> RTCWEB use case
>>>>=20
>>>> The first one is clearly something that needs RTCWEB consensus. It see=
ms
>>>> to have no need for, nor likelyhood of gathering interest enough for, =
a
>>>> TSVWG consensus.
>>>>=20
>>>> There could be some argument that the second part needs TSVWG consensu=
s,
>>>> especially if it was redefining any mechanisms, or it was making choic=
es
>>>> between mechanisms where TSVWG had strong opinions about which
>>>> mechanisms should be chosen, but had not chosen to document that in an=
y
>>>> document on which IETF consensus had been declared (that is to say,
>>>> existing RFCs).
>>>>=20
>>>> My archive shows 36 messages where the title refers to this draft. It
>>>> shows no messages declaring that feedback has been incorporated and
>>>> calling for new review - something that is usually necessary to get a =
WG
>>>> consensus on any document. The debate hasn't been conclusive, but then=
,
>>>> it hasn't been pushed hard either.
>>>>=20
>>>> The people who know how RTCWEB works are in this working group. Some o=
f
>>>> them may be in TSV, but I think the locus of knowledge for saying what
>>>> QoS mechanisms are appropriate for RTCWEB are here, not in TSV.
>>>>=20
>>>> This results in my second request.
>>>>=20
>>>> ACTION REQUEST 2: I request that the chairs declare that based on the
>>>> debate about the QoS functionality so far, the document should be
>>>> resurrected, and will continue to be  worked on in the RTCWEB working
>>>> group, bringing in advice from TSVWG as required to make sure the
>>>> descriptions of underlying mechanisms, and the choice of such
>>>> mechanisms, is correct and appropriate.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> --=20
>>>> Surveillance is pervasive. Go Dark.
>>>>=20
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>>=20
>> --=20
>> Surveillance is pervasive. Go Dark.
>>=20
>> _______________________________________________
>> 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


From cowwoc@bbs.darktech.org  Wed Nov 13 21:22:41 2013
Return-Path: 
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 F004C21E81BD for ; Wed, 13 Nov 2013 21:22:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.143
X-Spam-Level: 
X-Spam-Status: No, score=-4.143 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 fbGuX-iysdRa for ; Wed, 13 Nov 2013 21:22:36 -0800 (PST)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5A41321E81BC for ; Wed, 13 Nov 2013 21:22:32 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id tp5so2054047ieb.14 for ; Wed, 13 Nov 2013 21:22:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EdYlUE3mYdI9q0esrqMDI77+E4Oq+ZSgRL6N6CTMhZQ=; b=gOd+FZjrMua0bZIq5byXFFjvCUrYmbunBkYRrhRHLmOrogRqLHzT+HdrVOz+f1+dTr +ziJvNu8h9Kzjwd8/OVeJXC9vB5E0Iol+8YawTQnoRmwHC7pb5zXLKF6L5zYCZwu9zel 10ZcR6v5oguaPtRY3rwSqbpQF2Ci7rOiIG1UfZ3/v3bNR/GrwfAXVtyyBvO106aiILpv soeoiY/BUntKUCiO0yX6BRFw5YTOL/1A0utUf34VZdkuYTHqR/EG5AGdEWljoic9tphV nAV7Q4AURjxjaO1FEQ0202SUpCHiAaYrEdd8wAVvujGgp2gMbMUfg9lOkUXvoeOPvImn kvsA==
X-Gm-Message-State: ALoCoQlIUyuWwOVtfxq7Oy/5k7m6CiGekjGxiNkXVEbUV7qlEQpr+DJIYyMjIYwA63JFF9zGpiEv
X-Received: by 10.50.67.51 with SMTP id k19mr344600igt.9.1384406551971; Wed, 13 Nov 2013 21:22:31 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id j16sm34604764igf.6.2013.11.13.21.22.30 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 21:22:31 -0800 (PST)
Message-ID: <52845E06.2000100@bbs.darktech.org>
Date: Thu, 14 Nov 2013 00:22:14 -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: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>		<5283FDF1.8030708@bbs.darktech.org> <20131114003608.GQ3245@audi.shelbyville.oz>
In-Reply-To: <20131114003608.GQ3245@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 05:22:42 -0000

On 13/11/2013 7:36 PM, Ron wrote:
> On Wed, Nov 13, 2013 at 05:32:17PM -0500, cowwoc wrote:
>> Start with H.261 and replace it the moment you find something better.
> Except this would essentially be an RFC 6919 MUST (BUT WE KNOW YOU WON"T)
> recommendation, since nobody is going to spend development effort on a
> thing that gives thumbnail video that wasn't even acceptable for users
> in the 80's.

How realistic is that statement? Today I think I can get 720p (or was it 
1080p, I forget) using VP8 in 1.5Mbps.

How much bandwidth would you need to do the same in H.261? What 
resolution would get you for 1.5Mbps? We need some reasonable comparisons.

>> Forcing us to transcode or drop video calls is not a solution.
> ... which means you'll still have exactly this problem - no solution.
>
> If MTI video is important, the selected codec does need to be better
> than the equivalent of mandating morse as the MTI audio channel.
>
>
> Either we mandate something that is of good quality and has a licence
> that allows anyone to use it - or we accept that the people trying to
> hijack the potential ubiquity of this standard have succeeded in that.
>
> Seems like a pretty simple choice to me.

I think you're exaggerating how bad H.261 is and it's also misleading to 
imply that the vast majority of users would be forced to use H.261. We 
are talking about H.261 as a fallback (if upgrading to VP8 or H.264 
fails). In the 5-10% of cases this happens, I am advocating we get using 
H.261 instead of dropping the call.

Gili

From cowwoc@bbs.darktech.org  Wed Nov 13 21:22:47 2013
Return-Path: 
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 371EC21E81B5 for ; Wed, 13 Nov 2013 21:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.134
X-Spam-Level: 
X-Spam-Status: No, score=-4.134 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 VzRke23Pj32z for ; Wed, 13 Nov 2013 21:22:42 -0800 (PST)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8F28221E81B0 for ; Wed, 13 Nov 2013 21:22:38 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id ar20so2051651iec.33 for ; Wed, 13 Nov 2013 21:22:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=S2L63yw9zT2heztggSZgS9D4epmVg0LEk5AdoOUESPk=; b=fm0QLPLgM01Me5zFB40UKzhyeV5XNAxH6iueXLUgBDZVoTZg6y9gm9gtHx9jOYLOni 99tKI5OklsRWbRcz7v3AEkQrukiHQncDe9oYtcCPB9gKWKLcFk/S3NtVEwqgvVAqLQYq o/8FwNnAe3SfGTyIxI2RVCN9KYLZsMd1CMc/i1YEVAp48c6TZiR4kK+01UGqCX7L7D9V 7gkIehv1MWC1zH/TmUGoLRzVaeJPdHMjHedhI+Y2sePAknQ7341pY80G0aLDfo34Hbwj Q7AVZ1qnz8XTEIzGIx3hQW6h9az09rbwYk0yhtE7oBy2/k3kL9YarM1yx9wgCcTfGqFE SVLg==
X-Gm-Message-State: ALoCoQkiIQAH6uPohqqJoPzoDHgExYTMlerCJrgHum8WI2gZf89ClHcpMZuNJ+3vojYpKFgcFbnv
X-Received: by 10.50.115.35 with SMTP id jl3mr318105igb.37.1384406558146; Wed, 13 Nov 2013 21:22:38 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id c14sm2313362ign.0.2013.11.13.21.22.37 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 21:22:37 -0800 (PST)
Message-ID: <52845E0C.6090703@bbs.darktech.org>
Date: Thu, 14 Nov 2013 00:22:20 -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: Justin Uberti 
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283DADA.2080806@alvestrand.no> <5283E530.8000409@bbs.darktech.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 05:22:47 -0000

On 13/11/2013 8:43 PM, Justin Uberti wrote:
> Regarding H.261: Consider the following clip, encoded at 256 kbps 
> using H.261.
> http://www-mobile.ecs.soton.ac.uk/peter/h261/missa.norm.h261.mpg
>
> Do you think this quality (QCIF, grayscale, PSNR of 38) is acceptable 
> for your users?

That is hardly a scientific comparison.

And again, it is misleading to imply that I am advocating the mass-use 
of H.261. I am only advocating the use of this codec in the 5-10% of 
cases where the clients fail to agree on a common upgrade path (to VP8 
or H.264). In those cases, I'd happily accept H.261 instead of dropping 
the call. You can still transcode, if you so wish.

Gili

From cowwoc@bbs.darktech.org  Wed Nov 13 21:22:55 2013
Return-Path: 
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 6AB2F21E81B0 for ; Wed, 13 Nov 2013 21:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 nimBe-Om5PhO for ; Wed, 13 Nov 2013 21:22:50 -0800 (PST)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1141121E81C1 for ; Wed, 13 Nov 2013 21:22:43 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id u16so1988829iet.20 for ; Wed, 13 Nov 2013 21:22:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=m2q/jTgC3v3UsvlVJZFglCWZOodTdtumCSBAnqauqP0=; b=G8MH+/uC5CVMck7nULwUMnbTPPjzYZdDVbm5b+cnzBGZgKRj9Lz+9YvrpCPQ//mh6D vO4Ek9McTAFtUtJoW+WAMTISoQkb/MrexxMKcOzWvRPtsubu/5nwP9fA+573RcAFb0ih Gca+zTDRx2+N3z9vcGiGTOYypPTPK9/6pJKOTJTnbZF70U/Q7AX2VeBwTDAXmNuON5h/ eAMRBsg9dG6ACrtNj1p3+i3RAwSHmrsB03VXjjN3QQfWxye2uIK9mkfarWvuq560Kjqk 9DRt1QX+cwmHHF6mumLIKIeQaiZ9t/6a9j8+M54/QxNNZ8Eb+G+TjBXA05A8X5/u61QQ rjOg==
X-Gm-Message-State: ALoCoQkMFzIU2PuQ8AigfmWOR5nMPmHPYCqx9qXBoQ5kVJptvB3TRMzvcYHNzKSv2D9OVJKVgkzI
X-Received: by 10.50.30.229 with SMTP id v5mr329250igh.27.1384406563599; Wed, 13 Nov 2013 21:22:43 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id j16sm34605687igf.6.2013.11.13.21.22.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 21:22:43 -0800 (PST)
Message-ID: <52845E12.3000509@bbs.darktech.org>
Date: Thu, 14 Nov 2013 00:22:26 -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: rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com>	 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060203030403040108010908"
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 05:22:55 -0000

This is a multi-part message in MIME format.
--------------060203030403040108010908
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


That's reasonable. Thanks for the clarification :)

Gili

On 13/11/2013 9:26 PM, Jonathan Rosenberg wrote:
> Regarding number 4, here is how I think of it:
>
> If browsers implement both, it means that an application provider 
> wishing to offer a service (take Hangouts or Skype as examples), can 
> pick the one they like, implement just that in their native apps 
> (mobile, desktop, etc.) where the app provider has control over the 
> full stack, and still work with clients of that service which run in 
> the browser, where the app provider does not have control over the 
> full stack as the real-time media stack is provided by the browser and 
> not the web app.
>
> The benefit of this approach is that it enables interoperability 
> between clients on different platforms for the same provider.
>
> The drawback is, for inter-service federation (which requires much 
> more than just codecs to be aligned), you might run into a case where 
> a user using a mobile app from provider 1 (say, Skype) calls a user 
> using a mobile app from provider 2 (say, Hangouts), and then since 
> each chose a different video codec, there is no common codec. Of 
> course that assumes the two providers in question are willing to even 
> federate in the first place.
>
> -Jonathan R.
>
>
>
>
> On Wed, Nov 13, 2013 at 5:17 PM, Stephan Wenger  > wrote:
>
>     Hi Gonzalo,
>     Re your point 5.: ³either or² is often understood as an exclusive
>     or.  I
>     don¹t think anyone proposed that.  A better way to express 5. would be
>     ³All entities MUST support at least one of H.264 and VP8².
>     Stephan
>
>     On 11.13.2013, 12:23 , "Gonzalo Camarillo"
>          > wrote:
>
>     >Folks,
>     >
>     >I hope everybody had a safe trip back home after Vancouver.
>     >
>     >As you all know, we need to make progress regarding the selection
>     of the
>     >MTI video codec. The following are some of the alternatives we
>     have on
>     >the table:
>     >
>     > 1. All entities MUST support H.264
>     > 2. All entities MUST support VP8
>     > 3. All entities MUST support both H.264 and VP8
>     > 4. Browsers MUST support both H.264 and VP8
>     > 5. All entities MUST support either H.264 or VP8
>     > 6. All entities MUST support H.261
>     > 7. There is no MTI video codec
>     >
>     >If you want the group to consider additional alternatives to the ones
>     >above, please let the group know within the following *two weeks*. At
>     >that point, the chairs will be listing all the received
>     alternatives and
>     >proposing a process to select one among them.
>     >
>     >Please, send your proposals in an email to the list. You do not
>     need to
>     >write a draft; just send the text you would like to see in the final
>     >document regarding video codecs.
>     >
>     >Thanks,
>     >
>     >Gonzalo
>     >Responsible AD for this WG
>     >
>     >_______________________________________________
>     >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
>
>
>
>
> -- 
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net 
> http://www.jdrosen.net
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------060203030403040108010908
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    


      That's reasonable. Thanks for the clarification :)

      

      Gili

      

      On 13/11/2013 9:26 PM, Jonathan Rosenberg wrote:

    

    

      
Regarding number 4, here is how I think of it:
        


        

        
If browsers implement both, it means that an application
          provider wishing to offer a service (take Hangouts or Skype as
          examples), can pick the one they like, implement just that in
          their native apps (mobile, desktop, etc.) where the app
          provider has control over the full stack, and still work with
          clients of that service which run in the browser, where the
          app provider does not have control over the full stack as the
          real-time media stack is provided by the browser and not the
          web app. 

        

        


        

        
The benefit of this approach is that it enables
          interoperability between clients on different platforms for
          the same provider.

        


        

        
The drawback is, for inter-service federation (which
          requires much more than just codecs to be aligned), you might
          run into a case where a user using a mobile app from provider
          1 (say, Skype) calls a user using a mobile app from provider 2
          (say, Hangouts), and then since each chose a different video
          codec, there is no common codec. Of course that assumes the
          two providers in question are willing to even federate in the
          first place. 

        


        

        
-Jonathan R.

        


        

        


        

      

      


        

        
On Wed, Nov 13, 2013 at 5:17 PM,
          Stephan Wenger <stewe@stewe.org>
          wrote:

          
Hi
            Gonzalo,

            Re your point 5.: ³either or² is often understood as an
            exclusive or.  I

            don¹t think anyone proposed that.  A better way to express
            5. would be

            ³All entities MUST support at least one of H.264 and VP8².

            Stephan

            

            On 11.13.2013, 12:23 , "Gonzalo Camarillo"

            

              
<Gonzalo.Camarillo@ericsson.com>
                wrote:

                

                >Folks,

                >

                >I hope everybody had a safe trip back home after
                Vancouver.

                >

                >As you all know, we need to make progress regarding
                the selection of the

                >MTI video codec. The following are some of the
                alternatives we have on

                >the table:

                >

                > 1. All entities MUST support H.264

                > 2. All entities MUST support VP8

                > 3. All entities MUST support both H.264 and VP8

                > 4. Browsers MUST support both H.264 and VP8

                > 5. All entities MUST support either H.264 or VP8

                > 6. All entities MUST support H.261

                > 7. There is no MTI video codec

                >

                >If you want the group to consider additional
                alternatives to the ones

                >above, please let the group know within the
                following *two weeks*. At

                >that point, the chairs will be listing all the
                received alternatives and

                >proposing a process to select one among them.

                >

                >Please, send your proposals in an email to the list.
                You do not need to

                >write a draft; just send the text you would like to
                see in the final

                >document regarding video codecs.

                >

                >Thanks,

                >

                >Gonzalo

                >Responsible AD for this WG

                >

                >_______________________________________________

                >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


    

    

  


--------------060203030403040108010908--

From cowwoc@bbs.darktech.org  Wed Nov 13 21:22:56 2013
Return-Path: 
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 480ED21E81B0 for ; Wed, 13 Nov 2013 21:22:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.118
X-Spam-Level: 
X-Spam-Status: No, score=-4.118 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 mgtT7ino3Qqo for ; Wed, 13 Nov 2013 21:22:50 -0800 (PST)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0972C21E81BC for ; Wed, 13 Nov 2013 21:22:41 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id ar20so2056474iec.5 for ; Wed, 13 Nov 2013 21:22:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Pf3WxOGvTpD8AsyqryR82RGZhdiVllHHC/iLOrmJwZM=; b=TyC5modlXOzdjcKkgf3OmdhQ1EdykGDbK1Gnoa1bdb2OWYDvdLjiovJqTIULyKS6a5 71H2mz4/cm7NybstbnX45kqRO4jQ+eD/xXfQ2IQog7ENkUbKEz+c3R70nNmjjW/cKLRJ RpfSeb+JPefe5CiTd4y2pvXXSQ4LUZ8+afaF4TDC+/jn2H1unbNGyRO1jSgVjVM2akP6 JXYA98a/Tw8r2OyoX8WZAyi2XcIE06kcI4K5fnJk7W1Ik+4sVbVW6bmhhDt85zvW42V3 KfQU1lz5CIzUu870sYrxD79DxJOLmcTyXv1Pg8uJBEV0Zl+fiQTG7ElHr/zgj/xRGbhc PAhQ==
X-Gm-Message-State: ALoCoQmeuhfHtFCbhjFSLHyOVDalX2aGHcg6UdT/FATQEpqsUtLJgEEgIPRRTc9Y1coZS0x2+Me7
X-Received: by 10.50.23.103 with SMTP id l7mr346936igf.3.1384406561675; Wed, 13 Nov 2013 21:22:41 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id yt10sm34627638igb.9.2013.11.13.21.22.40 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 21:22:41 -0800 (PST)
Message-ID: <52845E10.4040205@bbs.darktech.org>
Date: Thu, 14 Nov 2013 00:22:24 -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: rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 05:22:56 -0000

On 13/11/2013 11:11 PM, cb.list6 wrote:
>
> Why no SHOULD implement vp8 and h248? SHOULD means you will do it 
> unless you have a real good reason.
>

SHOULD doesn't carry any accountability. Anyone will tell you they have 
a "real good reason" to avoid implementing one codec or another. We've 
heard plenty of excuses on this list of why one party or another 
believes it is legally risky to implement VP8 or H.264, respectively. So 
in that sense, it is meaningless.

> MUST is too hard for this WG.  Many implementations have a really good 
> reason to not do vp8 OR h248.
>
> Saying that all webrtc MUST do one or the other or both is disingenuous.
>
> SHOULD for both is as good as we are going to get with this 
> complicated IPR environment.  Using MUST is simply not going to work 
> and we have 10,000 on this mailer to back that up.
>

What you say is true, but if we accept this (and go with SHOULD) we are 
essentially ending up with "no MTI" which leads to the dark side 
(transcoding or dropped calls).

Rock --> WebRTC <-- Hard place :)

Gili

From ggb@tokbox.com  Wed Nov 13 21:35:42 2013
Return-Path: 
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 AEFBB21E81B4 for ; Wed, 13 Nov 2013 21:35:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 3jNl+uXiqPSi for ; Wed, 13 Nov 2013 21:35:38 -0800 (PST)
Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id B945B21E81B3 for ; Wed, 13 Nov 2013 21:35:37 -0800 (PST)
Received: from mail-ve0-f172.google.com ([209.85.128.172]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUoRhKROcw8kXLq77gLr0ULH+BY2P43nm@postini.com; Wed, 13 Nov 2013 21:35:37 PST
Received: by mail-ve0-f172.google.com with SMTP id oz11so1318938veb.3 for ; Wed, 13 Nov 2013 21:35:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=za38IGNqpKpFhwZFhIp7gASuuqHtdXKBnYJqEbZnVrs=; b=c9+NRiEiYH9YRIjxDWX0f18fraRE3L1IbJ+q/0CawelO5Njrog1RBMI77GQSWhK3kd z8jz6fHK92XWwbohp1HkK6IcQIN9RA/d2z2TZg3YqQZYvJ29liby4/xuj+BdEkRSAov9 lrSlKHr1aNkXjqJdYPijVA1q8pV4PCrD9Dpo7lcvU2J9SBWEplOpOySl2mcs7nlpFc4G sQ8l3mmQGDSOfZ2WyDdxQbljQxI6ShULi86SQHz1Ec89eYGBOvfWSLlqMupO5csqSGRk /5NYB+P0RXjZq221hyGuJUevDFHURxdxo3JqXyILKAqoBrJ9NMwmD2ffNCT5BnSj0cqm f3Xw==
X-Gm-Message-State: ALoCoQmkNLyazTDT6eOWVNXq0KttcFtaP5iR0AZWCFYHV0xup2QtBwZVi55lXoqgWvohtjddOpas+YNVJm6rXoJK4fKengDP/O6blPhO1MYygWJ68ZGBAAu+o33Wo1GoB/dEv9HSswNnUGbjowFcHwqDjpjiRdRVPw==
X-Received: by 10.52.187.138 with SMTP id fs10mr30102726vdc.10.1384407336566;  Wed, 13 Nov 2013 21:35:36 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.52.187.138 with SMTP id fs10mr30102722vdc.10.1384407336463;  Wed, 13 Nov 2013 21:35:36 -0800 (PST)
Received: by 10.58.211.200 with HTTP; Wed, 13 Nov 2013 21:35:36 -0800 (PST)
In-Reply-To: <5283DFDC.4010906@ericsson.com>
References: <5283DFDC.4010906@ericsson.com>
Date: Wed, 13 Nov 2013 21:35:36 -0800
Message-ID: 
From: Gustavo Garcia 
To: Gonzalo Camarillo 
Content-Type: multipart/alternative; boundary=bcaec548a38583c7e704eb1c735c
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 05:35:42 -0000

--bcaec548a38583c7e704eb1c735c
Content-Type: text/plain; charset=ISO-8859-1

8. All entities MUST support VP8 and H.264 is RECOMMENDED to implement

Ensure interoperability with a common codec and avoid transcoding when
interconnecting with non-WebRTC platforms/devices as much as possible.


On Wed, Nov 13, 2013 at 12:23 PM, Gonzalo Camarillo <
Gonzalo.Camarillo@ericsson.com> wrote:

> Folks,
>
> I hope everybody had a safe trip back home after Vancouver.
>
> As you all know, we need to make progress regarding the selection of the
> MTI video codec. The following are some of the alternatives we have on
> the table:
>
>  1. All entities MUST support H.264
>  2. All entities MUST support VP8
>  3. All entities MUST support both H.264 and VP8
>  4. Browsers MUST support both H.264 and VP8
>  5. All entities MUST support either H.264 or VP8
>  6. All entities MUST support H.261
>  7. There is no MTI video codec
>
> If you want the group to consider additional alternatives to the ones
> above, please let the group know within the following *two weeks*. At
> that point, the chairs will be listing all the received alternatives and
> proposing a process to select one among them.
>
> Please, send your proposals in an email to the list. You do not need to
> write a draft; just send the text you would like to see in the final
> document regarding video codecs.
>
> Thanks,
>
> Gonzalo
> Responsible AD for this WG
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--bcaec548a38583c7e704eb1c735c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


8. All entities MUST support VP8 and H.264 is RECOMME=
NDED to implement

Ensure interoperability with a common codec =
and avoid transcoding when interconnecting with non-WebRTC platforms/device=
s as much as possible.




On Wed, Nov 1=
3, 2013 at 12:23 PM, Gonzalo Camarillo <Gonzalo.Camarillo@eri=
csson.com> wrote:


Folks,



I hope everybody had a safe trip back home after Vancouver.



As you all know, we need to make progress regarding the selection of the
MTI video codec. The following are some of the alternatives we have on

the table:



=A01. All entities MUST support H.264

=A02. All entities MUST support VP8

=A03. All entities MUST support both H.264 and VP8

=A04. Browsers MUST support both H.264 and VP8

=A05. All entities MUST support either H.264 or VP8

=A06. All entities MUST support H.261

=A07. There is no MTI video codec



If you want the group to consider additional alternatives to the ones

above, please let the group know within the following *two weeks*. At

that point, the chairs will be listing all the received alternatives and
proposing a process to select one among them.



Please, send your proposals in an email to the list. You do not need to

write a draft; just send the text you would like to see in the final

document regarding video codecs.



Thanks,



Gonzalo

Responsible AD for this WG



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--bcaec548a38583c7e704eb1c735c--

From fippo@goodadvice.pages.de  Wed Nov 13 21:41:21 2013
Return-Path: 
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 593B521E81B0 for ; Wed, 13 Nov 2013 21:41:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.453
X-Spam-Level: 
X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146,  BAYES_00=-2.599]
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 apXmVsYNRFgs for ; Wed, 13 Nov 2013 21:41:10 -0800 (PST)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 7844621E812F for ; Wed, 13 Nov 2013 21:41:10 -0800 (PST)
Received: from [192.168.2.101] (p5497072F.dip0.t-ipconnect.de [84.151.7.47]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id rAE5f5h2024952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Nov 2013 06:41:06 +0100
Message-ID: <5284626C.8050504@goodadvice.pages.de>
Date: Thu, 14 Nov 2013 06:41:00 +0100
From: Philipp Hancke 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com>	<20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>		<5283FDF1.8030708@bbs.darktech.org>	 <52845DB0.6040501@bbs.darktech.org>
In-Reply-To: <52845DB0.6040501@bbs.darktech.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 05:41:21 -0000

> Really? I've never seen a single P2P video chat app in Flash.

You missed chatroulette and it's clones?

>  What specifically does "P2P for real time communication" actually mean?

See the slides from the 2009 MAX presentation.
http://assets.max.adobe.com/files/307/P2P%20on%20the%20Flash%20Platform%20with%20RTMFP.pdf

RTMFP was and is in many ways alot more advanced than webrtc.

From matthew.kaufman@skype.net  Wed Nov 13 21:52:08 2013
Return-Path: 
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 3ACE521E81BC for ; Wed, 13 Nov 2013 21:52:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 ITeJs5rT5s3J for ; Wed, 13 Nov 2013 21:52:01 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 133B221E81BB for ; Wed, 13 Nov 2013 21:51:56 -0800 (PST)
Received: from DM2PR03CA004.namprd03.prod.outlook.com (10.141.52.152) by BN1PR03MB282.namprd03.prod.outlook.com (10.255.200.21) with Microsoft SMTP Server (TLS) id 15.0.820.5; Thu, 14 Nov 2013 05:51:55 +0000
Received: from BN1AFFO11FD028.protection.gbl (2a01:111:f400:7c10::136) by DM2PR03CA004.outlook.office365.com (2a01:111:e400:2414::24) with Microsoft SMTP Server (TLS) id 15.0.820.5 via Frontend Transport; Thu, 14 Nov 2013 05:51:54 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD028.mail.protection.outlook.com (10.58.52.88) with Microsoft SMTP Server (TLS) id 15.0.815.5 via Frontend Transport; Thu, 14 Nov 2013 05:51:54 +0000
Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.187]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0158.002; Thu, 14 Nov 2013 05:51:22 +0000
From: "Matthew Kaufman (SKYPE)" 
To: cowwoc 
Thread-Topic: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
Thread-Index: AQHO3/GgARwJeGanTU6NKdKIjPn3QJojYmkAgABCxACAABGPAIAACcuAgAAQ9ACAAGEvAIAAB5PA
Date: Thu, 14 Nov 2013 05:51:21 +0000
Message-ID: 
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>  <5283FDF1.8030708@bbs.darktech.org>  <52845DB0.6040501@bbs.darktech.org>
In-Reply-To: <52845DB0.6040501@bbs.darktech.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.35]
Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4843D496817TK5EX14MBXC266r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(479174003)(377454003)(24454002)(15975445006)(83072001)(76796001)(512954002)(76786001)(69226001)(15202345003)(33656001)(55846006)(63696002)(20776003)(74366001)(74706001)(56816003)(81816001)(54316002)(85306002)(77096001)(56776001)(19300405004)(59766001)(84326002)(77982001)(74876001)(16236675002)(81686001)(44976005)(83322001)(2656002)(19580405001)(74662001)(19580395003)(47736001)(49866001)(65816001)(50986001)(47976001)(81542001)(81342001)(31966008)(71186001)(80022001)(6806004)(87266001)(4396001)(47446002)(80976001)(74502001)(79102001)(66066001)(87936001)(53806001)(76482001)(54356001)(51856001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB282; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0030839EEE
X-OriginatorOrg: skype.net
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 05:52:08 -0000

--_000_AE1A6B5FD507DC4FB3C5166F3A05A4843D496817TK5EX14MBXC266r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Chatroulette (the top trending search term for 2010 and featured on The Dai=
ly Show) used Flash and RTMFP to do peer-to-peer video chat. The original T=
okbox and their original API was also based on Flash with RTMFP for P2P com=
munications. I'm sure there's others.

Matthew Kaufman

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 cowwoc
Sent: Wednesday, November 13, 2013 9:21 PM
To: Michael Thornburgh
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, whe=
n"


Really? I've never seen a single P2P video chat app in Flash. What specific=
ally does "P2P for real time communication" actually mean?

Gili

On 13/11/2013 6:32 PM, Michael Thornburgh wrote:
> The real revolution is P2P: massive cost savings, ease of deployment and =
most importantly: cutting out the middle man. The status quo (H.264 over Fl=
ash) does not do this.

note: Flash has had P2P for real time communication since 2009.

-michael thornburgh

From: rtcweb-bounces@ietf.org [mailto:rtcwe=
b-bounces@ietf.org] On Behalf Of cowwoc
Sent: Wednesday, November 13, 2013 2:32 PM
To: Kaiduan Xie
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, whe=
n"


I agree. I'm just pointing out that John's argument (quoted below) doesn't =
make any sense. Choosing "no MTI" doesn't make Cisco any more likely to imp=
lement VP8.

If we choose "No MTI" we will end up with transcoding, plain and simple. On=
e crowd will only implement H.264. The other crowd will only implement VP8.=
 All the useless middlemen will rejoice, having killed a technology that pu=
ts them out of business.

Providing "video chat without a plugin" is not revolutionary. Flash is alre=
ady installed on 95% of the market. That's more people than WebRTC can reac=
h today, so we're not "liberating" those people from anything.

The real revolution is P2P: massive cost savings, ease of deployment and mo=
st importantly: cutting out the middle man. The status quo (H.264 over Flas=
h) does not do this.

P2P cannot work unless 95% of clients can agree on a common codec. I say ag=
ain: start with H.261 and upgrade to VP8 or H.264. This way everyone can be=
 happy:

  *   The VP8 crowd can use VP8
  *   The H264 crowd can use H264
  *   The enterprise crowd can transcode
  *   If all of the above fails, we can fallback on H.261.

Yes, this carries the burden of implementing H.261 but this is a solved-pro=
blem. There are plenty of free implementations and is a much easier problem=
 to solve than getting the H.264 and VP8 crowd to agree to implement each o=
ther's codec.

Start with H.261 and replace it the moment you find something better. Forci=
ng us to transcode or drop video calls is not a solution.

Gili
On 13/11/2013 4:57 PM, Kaiduan Xie wrote:
"if an implementer gets sued they can simply drop the codec"

Thing is not that simple as "simply drop the codec", for some case you stil=
l have to pay a lot of money.

/Kaiduan

On 13/11/2013 11:55 AM, John Leslie wrote:
    And I claim that both camps are actually more likely to implement
(or allow extensions for) the other side's codec if it is _not_ MTI,
simply because they can back out at the first sign of lawyers.



--_000_AE1A6B5FD507DC4FB3C5166F3A05A4843D496817TK5EX14MBXC266r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Chatroulette (the top tre=
nding search term for 2010 and featured on The Daily Show) used Flash and R=
TMFP to do peer-to-peer video chat. The original Tokbox
 and their original API was also based on Flash with RTMFP for P2P communic=
ations. I’m sure there’s others.


 <=
/p>



Matthew Kaufman




 <=
/p>







From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@=
ietf.org]
On Behalf Of cowwoc

Sent: Wednesday, November 13, 2013 9:21 PM

To: Michael Thornburgh

Cc: rtcweb@ietf.org

Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If =
not now, when"






 






Really? I've never seen a single P2P video chat app in Flash. What specific=
ally does "P2P for real time communication" actually mean?



Gili



On 13/11/2013 6:32 PM, Michael Thornburgh wrote:






> The real revolution =
is P2P: massive cost savings, ease of deployment and most importantly: cutt=
ing out the middle man. The status quo (H.264 over Flash) does
 not do this.


 <=
/p>

note: Flash has had P2P f=
or real time communication since 2009.


 <=
/p>

-michael thornburgh


 <=
/p>







From:
rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of cowwoc

Sent: Wednesday, November 13, 2013 2:32 PM

To: Kaiduan Xie

Cc: rtcweb@ietf.org

Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If =
not now, when"






 






I agree. I'm just pointing out that John's argument (quoted below) doesn't =
make any sense. Choosing "no MTI" doesn't make Cisco any more lik=
ely to implement VP8.



If we choose "No MTI" we will end up with transcoding, plain and =
simple. One crowd will only implement H.264. The other crowd will only impl=
ement VP8. All the useless middlemen will rejoice, having killed a technolo=
gy that puts them out of business.



Providing "video chat without a plugin" is not revolutionary. Fla=
sh is already installed on 95% of the market. That's more people than WebRT=
C can reach today, so we're not "liberating" those people from an=
ything.



The real revolution is P2P: massive cost savings, ease of deployment and mo=
st importantly: cutting out the middle man. The status quo (H.264 over Flas=
h) does not do this.



P2P cannot work unless 95% of clients can agree on a common codec. I say ag=
ain: start with H.261 and upgrade to VP8 or H.264. This way everyone can be=
 happy:


    

  • 
The VP8 crowd can use VP8
  • 
The H264 crowd can use H264
  • 
If all of the above fails, we can fallback on H.261.


Yes, this carries the burden of implementing H.261 but this is a solved-=
problem. There are plenty of free implementations and is a much easier prob=
lem to solve than getting the H.264 and VP8 crowd to agree to implement eac=
h other's codec.


Start with H.261 and replace it the moment you find something better. Fo=
rcing us to transcode or drop video calls is not a solution.


Gili


On 13/11/2013 4:57 PM, Kaiduan Xie wrote:=









"if an implementer gets sued they can=
 simply drop the codec"




 






Thing is not that simple as "simply d=
rop the codec", for some case you still have to pay a lot of money.






 






/Kaiduan










On 13/11/2013 11:55 AM, John Leslie wrote:












    And I claim that both camps are actual=
ly more likely to implement

(or allow extensions for) the other side's codec if it is _not_ MTI,

simply because they can back out at the first sign of lawyers.















 






 








--_000_AE1A6B5FD507DC4FB3C5166F3A05A4843D496817TK5EX14MBXC266r_--

From matthew.kaufman@skype.net  Wed Nov 13 22:03:54 2013
Return-Path: 
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 AF76711E80DE for ; Wed, 13 Nov 2013 22:03:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 SiJO3-1-Vd37 for ; Wed, 13 Nov 2013 22:03:48 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 101D711E8142 for ; Wed, 13 Nov 2013 22:03:44 -0800 (PST)
Received: from DM2PR03CA003.namprd03.prod.outlook.com (10.141.52.151) by BL2PR03MB274.namprd03.prod.outlook.com (10.255.231.19) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 14 Nov 2013 06:03:43 +0000
Received: from BY2FFO11FD027.protection.gbl (2a01:111:f400:7c0c::191) by DM2PR03CA003.outlook.office365.com (2a01:111:e400:2414::23) with Microsoft SMTP Server (TLS) id 15.0.820.5 via Frontend Transport; Thu, 14 Nov 2013 06:03:43 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD027.mail.protection.outlook.com (10.1.15.216) with Microsoft SMTP Server (TLS) id 15.0.815.5 via Frontend Transport; Thu, 14 Nov 2013 06:03:43 +0000
Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.187]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0158.002; Thu, 14 Nov 2013 06:02:52 +0000
From: "Matthew Kaufman (SKYPE)" 
To: Philipp Hancke , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
Thread-Index: AQHO3/GgARwJeGanTU6NKdKIjPn3QJojYmkAgABCxACAABGPAIAACcuAgAAQ9ACAAGEvAIAABaUAgAAEKIA=
Date: Thu, 14 Nov 2013 06:02:51 +0000
Message-ID: 
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>  <5283FDF1.8030708@bbs.darktech.org>  <52845DB0.6040501@bbs.darktech.org> <5284626C.8050504@goodadvice.pages.de>
In-Reply-To: <5284626C.8050504@goodadvice.pages.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.35]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(189002)(199002)(377454003)(13464003)(77096001)(56816003)(46406003)(76796001)(76786001)(54356001)(15202345003)(83072001)(65816001)(20776003)(47776003)(85306002)(63696002)(80022001)(66066001)(87936001)(74706001)(55846006)(51856001)(56776001)(46102001)(81816001)(81686001)(87266001)(54316002)(79102001)(15975445006)(69226001)(74876001)(76482001)(23726002)(2656002)(77982001)(59766001)(50466002)(6806004)(33656001)(44976005)(81542001)(31966008)(47446002)(74502001)(81342001)(74662001)(80976001)(4396001)(74366001)(53806001)(50986001)(47976001)(19580405001)(83322001)(49866001)(19580395003)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB274; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0030839EEE
X-OriginatorOrg: DuplicateDomain-9e79206f-3253-44e7-9aa6-8e1280886b67.skype.net
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 06:03:54 -0000

We're clearly off topic here, but:

My 2008 MAX presentation is actually more applicable to what RTCWEB can now=
 do, and (if you watch the video) includes a demo of widely-deployed browse=
r-to-browser peer-to-peer video, 5 years ago. Somewhat ahead of its time, I=
'm afraid.

http://tv.adobe.com/en/watch/max-2008-develop/future-of-communication-with-=
rtmfp-by-matthew-kaufman/ is a link to the video... the demo of building an=
d running a peer-to-peer video chat is at 30 minutes in.

Matthew Kaufman

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Philipp Hancke
> Sent: Wednesday, November 13, 2013 9:41 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, w=
hen"
>=20
> > Really? I've never seen a single P2P video chat app in Flash.
>=20
> You missed chatroulette and it's clones?
>=20
> >  What specifically does "P2P for real time communication" actually mean=
?
>=20
> See the slides from the 2009 MAX presentation.
> http://assets.max.adobe.com/files/307/P2P%20on%20the%20Flash%20Platf
> orm%20with%20RTMFP.pdf
>=20
> RTMFP was and is in many ways alot more advanced than webrtc.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From juberti@google.com  Wed Nov 13 22:07:55 2013
Return-Path: 
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 193D221E81CA for ; Wed, 13 Nov 2013 22:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.809
X-Spam-Level: 
X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.168,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 SxedAYlDUh-Q for ; Wed, 13 Nov 2013 22:07:54 -0800 (PST)
Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id F0FFB21E81BC for ; Wed, 13 Nov 2013 22:07:53 -0800 (PST)
Received: by mail-vb0-f41.google.com with SMTP id w8so1269596vbj.28 for ; Wed, 13 Nov 2013 22:07:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oGa6+36+nVITSkBfIruw2mqRfLW0SWhRnoGWt93jrRk=; b=pGavpV/3e/wKXQA2+x0ZmNk1DXzgPPxLaFgcR3CDbnM5S0XSDmgjz7xC01i/iGZmoV quSZ9Z19LAKBDJvgI+2tUma28IIBYy0szZPnAR+t6Jv22cXB1HHNyCNwTDi9B99ByCqT 5HJhmcXAZMRgjpbrXonhUZ1YPKb3Y4jD7Sflcpmk760SC56W0SQMsKPxRN74DnwkgPwK hCNrVt09B3Y6tnN7KambTWnQ8mKF2gcIb6Y1E/lmhM/O8UNgqNkaJPeWyTwUqDH7mYIe IdA1H5cvSUPmOcmG2/rTihctTKuca2LcD84esSJcZMbd4YahFxLpcWVH3PGltskHzWNZ oFAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oGa6+36+nVITSkBfIruw2mqRfLW0SWhRnoGWt93jrRk=; b=VDXOJOMxIHN7KAac3+3QExoYN//TvlK8FqTLWakwm0vrD/jvwps8lqfolqQR9PnusC AcmE6dHNGcGOvzV+UEu891wFSk6zkhjtGhHBVCgE3JYYY/ryECSqdocogqva6ZkIqqLg EMNPGOle4A4uWrwaYAM1pqBPJnaRBkPs0taurSTDy6zmik3t0nHJTu9SKEqQb6nB8W+d 8z7yFPipJxS1L1rgbKhFVWDAevOuncT5twk5fNjz16dPK4g0FZINEKAKwwAy6G+vKoV+ BJwuZUMoY8MMZOkYjObOUlPwKOIY3NZa/SkoFS6usee1/jnXTAdzw/xE8Mk8lWx2E7s7 QoJw==
X-Gm-Message-State: ALoCoQlyRRL85TIIC4qsKGDhL2PeY3miPneMIT2E1dzUppil7F6Ab+ta3Fsng+RbutK6KlOpze+YH+rEDGgR/j/if3IYE5+BhOg6NwN1Pu28KCOBZWGDRjyLQUPQEA8H+RKvj9GraxrcbvHyDtUth4lzF160gpICHdZhHwy4ckmJbhYYpIvqIx4+bkRcSiyikCGglejvzbnV
X-Received: by 10.52.28.110 with SMTP id a14mr250311vdh.79.1384409272343; Wed, 13 Nov 2013 22:07:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Wed, 13 Nov 2013 22:07:32 -0800 (PST)
In-Reply-To: <52845E0C.6090703@bbs.darktech.org>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283DADA.2080806@alvestrand.no> <5283E530.8000409@bbs.darktech.org>  <52845E0C.6090703@bbs.darktech.org>
From: Justin Uberti 
Date: Wed, 13 Nov 2013 22:07:32 -0800
Message-ID: 
To: cowwoc 
Content-Type: multipart/alternative; boundary=20cf3079bc52e7053b04eb1ce6ce
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 06:07:55 -0000

--20cf3079bc52e7053b04eb1ce6ce
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 13, 2013 at 9:22 PM, cowwoc  wrote:

> On 13/11/2013 8:43 PM, Justin Uberti wrote:
>
>> Regarding H.261: Consider the following clip, encoded at 256 kbps using
>> H.261.
>> http://www-mobile.ecs.soton.ac.uk/peter/h261/missa.norm.h261.mpg
>>
>> Do you think this quality (QCIF, grayscale, PSNR of 38) is acceptable for
>> your users?
>>
>
> That is hardly a scientific comparison.
>
> And again, it is misleading to imply that I am advocating the mass-use of
> H.261. I am only advocating the use of this codec in the 5-10% of cases
> where the clients fail to agree on a common upgrade path (to VP8 or H.264).
> In those cases, I'd happily accept H.261 instead of dropping the call. You
> can still transcode, if you so wish.
>
> It is a single example, but I think it illustrates the limits on what you
can achieve with a 25-year-old (really!) coding technology. The page at
http://www-mobile.ecs.soton.ac.uk/peter/h261/ claims that the compression
ratio for the above file is 25:1, with PSNR of 38. Modern codecs achieve
compression ratios of at least 150:1 for similar PSNR with a similar
talking head scene, i.e. H.261 requires at least 6x the bits for the same
quality.

Implementing H.261 in WebRTC has a nontrivial cost. If you think H.261 is a
realistic option, I think you need to show data that indicates it can
deliver decent quality at typical internet bitrates.

--20cf3079bc52e7053b04eb1ce6ce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Nov 13, 2013 at 9:22 PM, cowwoc <cowwoc@bbs.darktech=
.org> wrote:



On 13/11/2013 8:43 PM, Justin Uberti wro=
te:





Regarding H.261: Consider the following clip, encoded at 256 kbps using H.2=
61.

http://www-mobile.ecs.soton.ac.uk/peter/h261/mis=
sa.norm.h261.mpg



Do you think this quality (QCIF, grayscale, PSNR of 38) is acceptable for y=
our users?





That is hardly a scientific comparison.



And again, it is misleading to imply that I am advocating the mass-use of H=
.261. I am only advocating the use of this codec in the 5-10% of cases wher=
e the clients fail to agree on a common upgrade path (to VP8 or H.264). In =
those cases, I'd happily accept H.261 instead of dropping the call. You=
 can still transcode, if you so wish.



It is a single example, but I think it illustrates th=
e limits on what you can achieve with a 25-year-old (really!) coding techno=
logy. The page at=C2=A0http://www-mobile.ecs.soton.ac.uk/peter/h261/ claims that the com=
pression ratio for the above file is 25:1, with PSNR of 38. Modern codecs a=
chieve compression ratios of at least 150:1 for similar PSNR with a similar=
 talking head scene, i.e. H.261 requires at least 6x the bits for the same =
quality.




Implementing H.261 in WebRTC has a nontrivial cost. If =
you think H.261 is a realistic option, I think you need to show data that i=
ndicates it can deliver decent quality at typical internet bitrates.






--20cf3079bc52e7053b04eb1ce6ce--

From duerst@it.aoyama.ac.jp  Wed Nov 13 22:25:52 2013
Return-Path: 
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 814A021E80C1 for ; Wed, 13 Nov 2013 22:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.652
X-Spam-Level: 
X-Spam-Status: No, score=-103.652 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 qELoCjJLOC3v for ; Wed, 13 Nov 2013 22:25:43 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2F511E8106 for ; Wed, 13 Nov 2013 22:25:43 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAE6PZAi008773; Thu, 14 Nov 2013 15:25:35 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 1aa6_8a2c_921608dc_4cf5_11e3_a617_001e6722eec2; Thu, 14 Nov 2013 15:25:34 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id B1FB8BFF5D; Thu, 14 Nov 2013 15:25:34 +0900 (JST)
Message-ID: <52846CCF.9030203@it.aoyama.ac.jp>
Date: Thu, 14 Nov 2013 15:25:19 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: cowwoc 
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>	<5283DADA.2080806@alvestrand.no>	<5283E530.8000409@bbs.darktech.org>	 <52845E0C.6090703@bbs.darktech.org>
In-Reply-To: <52845E0C.6090703@bbs.darktech.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 06:25:52 -0000

On 2013/11/14 14:22, cowwoc wrote:
> On 13/11/2013 8:43 PM, Justin Uberti wrote:
>> Regarding H.261: Consider the following clip, encoded at 256 kbps
>> using H.261.
>> http://www-mobile.ecs.soton.ac.uk/peter/h261/missa.norm.h261.mpg

Thanks for the pointer to the sample.

>> Do you think this quality (QCIF, grayscale, PSNR of 38) is acceptable
>> for your users?
>
> That is hardly a scientific comparison.

True, but that's not what I asked about.

> And again, it is misleading to imply that I am advocating the mass-use
> of H.261. I am only advocating the use of this codec in the 5-10% of
> cases where the clients fail to agree on a common upgrade path (to VP8
> or H.264). In those cases, I'd happily accept H.261 instead of dropping
> the call. You can still transcode, if you so wish.

Having had a look at the sample, I'd say "it depends".

If the video were used to discuss e.g. some details of a new physical 
product, higher resolution and color may be rather important, and H261 
insufficient.

If it's just to get a quick impression of the person at the other end of 
the call, I guess it would be okay, but in that use case, there's a high 
chance I'd overlay it with some other document even if the video quality 
was much better.

If it's one of many videos of participants in a conference call, 
grayscale may be disappointing but better than nothing, the size may be 
just about right, and the (relatively speaking) high bandwidth may not 
be noticed.

Regards,   Martin.

From spencerdawkins.ietf@gmail.com  Wed Nov 13 22:33:02 2013
Return-Path: 
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 E1B9321E80C1 for ; Wed, 13 Nov 2013 22:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NFhm5dFWBgeF for ; Wed, 13 Nov 2013 22:33:01 -0800 (PST)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7393521E8087 for ; Wed, 13 Nov 2013 22:33:01 -0800 (PST)
Received: by mail-wi0-f169.google.com with SMTP id hi5so267755wib.0 for ; Wed, 13 Nov 2013 22:33:00 -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=5FmPx5Zjlc15Sz5uh8Bx2oQ6VlEJACdbGCg37///zTE=; b=Y0G7hOnKK9lEvpzt80Ce3qYTnzWYCMxHo4iUm/z6MTrCSHoNkF5Lo+ZrwXDMuHDaaN GFJ2tBPRIh2Su7c3k6opuv/bdn36zsTD88n/+qkwEw4FvoVe+TwmPDlSuHJDqYUcy6nr Wa6BXhI6ifXBcX9/Vb5ShVXZZ01XFFw5fwPtn4naH04ZlyfvNjEuVwPyGDozC9f1eDPM xek61mPVUafrnb0qHFADhQuFW2u9j3qQcZBw+A4+AO09EzchelM0nHvUGQ4nZR5y3nrH 9WAiUkgzsDPKn550PD2OeidB443XCsMrWB89Jb/GQNkHKm9tv8lLY55TKMVmOI/nulOo PueA==
MIME-Version: 1.0
X-Received: by 10.180.74.15 with SMTP id p15mr653635wiv.63.1384410780589; Wed, 13 Nov 2013 22:33:00 -0800 (PST)
Received: by 10.223.196.9 with HTTP; Wed, 13 Nov 2013 22:33:00 -0800 (PST)
In-Reply-To: 
References: <5283DF61.9060807@alvestrand.no> <201311132211.rADMBaBD011692@rcdn-core2-5.cisco.com> <52843288.5000507@alvestrand.no>  
Date: Thu, 14 Nov 2013 00:33:00 -0600
Message-ID: 
From: Spencer Dawkins at IETF 
To: "Cullen Jennings (fluffy)" 
Content-Type: multipart/alternative; boundary=f46d043be1b0cce6cc04eb1d4011
Cc: "rai-ads@tools.ietf.org Area" , "tsv-ads@tools.ietf.org" , David Black , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 06:33:03 -0000

--f46d043be1b0cce6cc04eb1d4011
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, November 13, 2013, Cullen Jennings (fluffy) wrote:

>
> I'm trying to not say much on this whole thread but I wonder if the tsv-ad
> could provide any more insight around why this was appropriate for TSV.


Probably so, but Martin is on his last week of parental leave - I'll check
with him when he surfaces.

Spencer


>
> It's not assigning any new DSCP, it's simply providing pointers to the
> existing codes defined in documents done by TSV that talk about the DSCP to
> use for audio, video, and such. I think if folks could help people
> understand what transport content was, that would help. (and added David as
> he has been involved with this draft )
>
> Cullen in my individual contributor role.
>
> On Nov 13, 2013, at 9:29 PM, Bernard Aboba 
> wrote:
>
> >> I want this group to be done. As long as I can't even point to the
> >> document that describes how we do QoS, I have no chance of getting it to
> >> that stage.
> >
> > [BA] The approach of dispersing work among half a dozen WGs isn't
> working in this case, and in fact hasn't worked particularly well in the
> past either, because it generates neither urgency nor focus.
> >
> > At this point, we are probably not much more than a year away from
> widespread deployment of  running code. So if a critical dependency is not
> making progress toward a WGLC it is time to hit reset. The reality is that
> there is no reservoir of undiscovered manpower to get this work done, just
> interested authors and reviewers who if fed a steady stream of documents
> without unnecessary distractions and bureaucratic impediments can help us
> rapidly get to closure.
> >
> > Our current process is akin to shuttling children from one neglectful
> foster home to another until we lose track of them and realize to our
> dismay that something bad has happened. This isn't a plan so much as an
> accident waiting to happen.
> >
> >
> >
> >
> >>
> >>
> >>>
> >>> At 02:21 PM 11/13/2013, Harald Alvestrand wrote:
> >>>> This mail concerns both administrative and technical issues, which is
> >>>> why it is explicitly copied to the ADs of RAI and TSV. I hope I have
> >>>> managed to keep them separate in the message.
> >>>>
> >>>> Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:
> >>>>
> >>>>> Okay, we might not have been public enough on this. It was
> >>>> requested by
> >>>>> the Transport ADs quite some time ago that doing the QoS document
> >>>> in our
> >>>>> WG was not appropriate and requested us to direct the document to
> >>>> TSVWG.
> >>>>> Which was done, and where it hasn't made progress.
> >>>>>
> >>>>> You might have noted that James Polk did comment in the milestone
> part
> >>>>> in the monday session of IETF88 about our QoS milestone should be
> >>>> killed.
> >>>> I want to protest this - both practically and formally.
> >>>>
> >>>> To get the formal stuff out of the way first:
> >>>>
> >>>> Changing the deliverables of the working group *without telling the
> >>>> working group* is totally inappropriate in an open, consensus-driven
> >>>> process.
> >>>> Changing the deliverables of the working group *without telling the
> >>>> working group why* and *without allowing those reasons to be debated*
> is
> >>>> totally inappropriate in an open, consensus-driven process.
> >>>>
> >>>> I protest against this action.
> >>>>
> >>>> ACTION REQUEST 1: I request that this decision be declared null and
> >>>> void, and that the relevant ADs send out a message to RTCWEB (and
> TSVWG
> >>>> if appropriate) *PROPOSING* such an action, and giving a reasonable
> >>>> timeline for when they will make a decision based on mailing list
> >>>> feedback.
> >>>>
> >>>> In practice:
> >>>>
> >>>> The draft as it existed before its untimely demise consisted of two
> >>>> things:
> >>>>
> >>>> - A description of how QoS mechanisms could be useful in the RTCWEB
> >>>> use case
> >>>> - A description of existing mechanisms that could be appropriate for
> the
> >>>> RTCWEB use case
> >>>>
> >>>> The first one is clearly something that needs RTCWEB consensus. It
> seems
> >>>> to have no need for, nor likelyhood of gathering interest enough for,
> a
> >>>> TSVWG consensus.
> >>>>
> >>>> There could be some argument that the second part needs TSVWG
> consensus,
> >>>> especially if it was redefining any mechanisms, or it was making
> choices
> >>>> between mechanisms where TSVWG had strong opinions about which
> >>>> mechanisms should be chosen, but had not chosen to document that in
> any
> >>>> document on which IETF consensus had been declared (that is to say,
> >>>> existing RFCs).
> >>>>
> >>>> My archive shows 36 messages w

--f46d043be1b0cce6cc04eb1d4011
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wednesday, November 13, 2013, Cullen Jennings (fluffy)  wrote:


I'm trying to not say much on this whole thread but I wonder if the tsv=
-ad could provide any more insight around why this was appropriate for TSV.=


Probably so, but Martin is on his last wee=
k of parental leave - I'll check with him when he surfaces.



Spencer
=A0=A0



It's not assigning any new DSCP, it's simply providing pointers to =
the existing codes defined in documents done by TSV that talk about the DSC=
P to use for audio, video, and such. I think if folks could help people und=
erstand what transport content was, that would help. (and added David as he=
 has been involved with this draft )




Cullen in my individual contributor role.



On Nov 13, 2013, at 9:29 PM, Bernard Aboba <bernard_aboba@hotmail.com=
> wrote:



>> I want this group to be done. As long as I can't even point to=
 the

>> document that describes how we do QoS, I have no chance of getting=
 it to

>> that stage.

>

> [BA] The approach of dispersing work among half a dozen WGs isn't =
working in this case, and in fact hasn't worked particularly well in th=
e past either, because it generates neither urgency nor focus.

>

> At this point, we are probably not much more than a year away from wid=
espread deployment of =A0running code. So if a critical dependency is not m=
aking progress toward a WGLC it is time to hit reset. The reality is that t=
here is no reservoir of undiscovered manpower to get this work done, just i=
nterested authors and reviewers who if fed a steady stream of documents wit=
hout unnecessary distractions and bureaucratic impediments can help us rapi=
dly get to closure.


>

> Our current process is akin to shuttling children from one neglectful =
foster home to another until we lose track of them and realize to our disma=
y that something bad has happened. This isn't a plan so much as an acci=
dent waiting to happen.


>

>

>

>

>>

>>

>>>

>>> At 02:21 PM 11/13/2013, Harald Alvestrand wrote:

>>>> This mail concerns both administrative and technical issue=
s, which is

>>>> why it is explicitly copied to the ADs of RAI and TSV. I h=
ope I have

>>>> managed to keep them separate in the message.

>>>>

>>>> Magnus said in an email yesterday, concerning draft-ietf-r=
tcweb-qos:

>>>>

>>>>> Okay, we might not have been public enough on this. It=
 was

>>>> requested by

>>>>> the Transport ADs quite some time ago that doing the Q=
oS document

>>>> in our

>>>>> WG was not appropriate and requested us to direct the =
document to

>>>> TSVWG.

>>>>> Which was done, and where it hasn't made progress.=


>>>>>

>>>>> You might have noted that James Polk did comment in th=
e milestone part

>>>>> in the monday session of IETF88 about our QoS mileston=
e should be

>>>> killed.

>>>> I want to protest this - both practically and formally.
>>>>

>>>> To get the formal stuff out of the way first:

>>>>

>>>> Changing the deliverables of the working group *without te=
lling the

>>>> working group* is totally inappropriate in an open, consen=
sus-driven

>>>> process.

>>>> Changing the deliverables of the working group *without te=
lling the

>>>> working group why* and *without allowing those reasons to =
be debated* is

>>>> totally inappropriate in an open, consensus-driven process=
.

>>>>

>>>> I protest against this action.

>>>>

>>>> ACTION REQUEST 1: I request that this decision be declared=
 null and

>>>> void, and that the relevant ADs send out a message to RTCW=
EB (and TSVWG

>>>> if appropriate) *PROPOSING* such an action, and giving a r=
easonable

>>>> timeline for when they will make a decision based on maili=
ng list

>>>> feedback.

>>>>

>>>> In practice:

>>>>

>>>> The draft as it existed before its untimely demise consist=
ed of two

>>>> things:

>>>>

>>>> - A description of how QoS mechanisms could be useful in t=
he RTCWEB

>>>> use case

>>>> - A description of existing mechanisms that could be appro=
priate for the

>>>> RTCWEB use case

>>>>

>>>> The first one is clearly something that needs RTCWEB conse=
nsus. It seems

>>>> to have no need for, nor likelyhood of gathering interest =
enough for, a

>>>> TSVWG consensus.

>>>>

>>>> There could be some argument that the second part needs TS=
VWG consensus,

>>>> especially if it was redefining any mechanisms, or it was =
making choices

>>>> between mechanisms where TSVWG had strong opinions about w=
hich

>>>> mechanisms should be chosen, but had not chosen to documen=
t that in any

>>>> document on which IETF consensus had been declared (that i=
s to say,

>>>> existing RFCs).

>>>>

>>>> My archive shows 36 messages w


--f46d043be1b0cce6cc04eb1d4011--

From cowwoc@bbs.darktech.org  Wed Nov 13 22:46:32 2013
Return-Path: 
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 0635211E81A3 for ; Wed, 13 Nov 2013 22:46:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.154
X-Spam-Level: 
X-Spam-Status: No, score=-4.154 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 0gfCGwVr6M91 for ; Wed, 13 Nov 2013 22:46:20 -0800 (PST)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDA711E80F6 for ; Wed, 13 Nov 2013 22:46:20 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id ar20so2132221iec.33 for ; Wed, 13 Nov 2013 22:46:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hxS1EUTznl47hNSF5pz909bb3YeU6/GR/AcYxjmpJGM=; b=j57Jd49RcCRxSWqQutODi9aMhPd8N9YLMtG5k6xZxFvSywxNUv75PsAm9kNdgDAd14 ZS1xy0A5yRMo4hmh9/ene4m/mwRrKt6PcpqXJm89y+tllpLcfNSxJcVnkFsXlvycauqe bobLXk9Kx+lFNEh7vJFBigS5xMvYfMf13pV3L4g6fKkasgUYZi4/f3f9qTg/D2Ut9vNZ RBUqyKmg04KmmbK4YgoS4QJIhAXnyeLdM6CK9L7mLe70zaRUicbmZtpBFNg5UfjwXkaz rE+c4pCi/daH8tnn91X733DxPl5oAQel0SIAYBij+66Zj+qk4Eld3vkZfeara8TafzLj hicw==
X-Gm-Message-State: ALoCoQl3MAgt+1vDsAy99Rs7KH+x+tf6WcYZe8GQgBd+4osA2CnfilaTAnx65vvnr1BZ4Jf6GdG0
X-Received: by 10.50.176.137 with SMTP id ci9mr467640igc.31.1384411579755; Wed, 13 Nov 2013 22:46:19 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id i11sm34934662igh.0.2013.11.13.22.46.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 22:46:19 -0800 (PST)
Message-ID: <528471AA.4060101@bbs.darktech.org>
Date: Thu, 14 Nov 2013 01:46:02 -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: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com>	<20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>		<5283FDF1.8030708@bbs.darktech.org>		<52845DB0.6040501@bbs.darktech.org> <5284626C.8050504@goodadvice.pages.de>
In-Reply-To: <5284626C.8050504@goodadvice.pages.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 06:46:32 -0000

Okay, so I stand corrected (thank you for pointing this out).

So, I guess my new argument is: WebRTC shouldn't support any less than 
Flash ;)

Gili

On 14/11/2013 12:41 AM, Philipp Hancke wrote:
>> Really? I've never seen a single P2P video chat app in Flash.
>
> You missed chatroulette and it's clones?
>
>>  What specifically does "P2P for real time communication" actually mean?
>
> See the slides from the 2009 MAX presentation.
> http://assets.max.adobe.com/files/307/P2P%20on%20the%20Flash%20Platform%20with%20RTMFP.pdf 
>
>
> RTMFP was and is in many ways alot more advanced than webrtc.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From cowwoc@bbs.darktech.org  Wed Nov 13 23:01:13 2013
Return-Path: 
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 1DEB721E8087 for ; Wed, 13 Nov 2013 23:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.146
X-Spam-Level: 
X-Spam-Status: No, score=-4.146 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 wX1MTym5pBFE for ; Wed, 13 Nov 2013 23:01:08 -0800 (PST)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1C91221E80FA for ; Wed, 13 Nov 2013 23:01:07 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id u16so2217564iet.10 for ; Wed, 13 Nov 2013 23:01:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=wN0Z5AummLtgBx8/TgdkT5c346JtdoEo3ZePMln+N1Q=; b=Tv//9oEEnR0rYqwh2fQz9h2K+zSLBsCuPxanD3FiHU64cpEUhnPJxvLq6s/Oh0uX42 0U0Lo+HZKsNAJ+ua5BGnxdsZTa5zMMVuRAZ956VmO4OCSGUA+5CjuT3lCD+abr/jx74h KusOBKdWBu1omm4eoZWkLxh91aL0SLuvVtynod7sc4YM4iYE7yLY9+G8LRNqLjkvukz2 qoNcOCFYMXnIC0YAHfSyWwvXDzVsDYcUBMjw1UMV5AXm78+MX4IiUNnJYA7rA9Q6B+CD yrr76mI59pEZKgcZE7c+bCsyKL+wd5K6Jj3mc+zwIQVp4j8/2LPrybfMUf7wWu7g5P47 azcg==
X-Gm-Message-State: ALoCoQks6JzXstGn9IO3J1+rkmgFGjMK6X0qlaKcESUbY0OkPfAxcE1EgIpH3P5C38f9/DpEiSYU
X-Received: by 10.50.13.104 with SMTP id g8mr543057igc.30.1384412467503; Wed, 13 Nov 2013 23:01:07 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p5sm2666706igj.10.2013.11.13.23.01.06 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 23:01:06 -0800 (PST)
Message-ID: <52847521.1080701@bbs.darktech.org>
Date: Thu, 14 Nov 2013 02:00:49 -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: Justin Uberti 
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283DADA.2080806@alvestrand.no> <5283E530.8000409@bbs.darktech.org>  <52845E0C.6090703@bbs.darktech.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090608040902020604020304"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 07:01:13 -0000

This is a multi-part message in MIME format.
--------------090608040902020604020304
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 14/11/2013 1:07 AM, Justin Uberti wrote:
>
> On Wed, Nov 13, 2013 at 9:22 PM, cowwoc  > wrote:
>
>     On 13/11/2013 8:43 PM, Justin Uberti wrote:
>
>         Regarding H.261: Consider the following clip, encoded at 256
>         kbps using H.261.
>         http://www-mobile.ecs.soton.ac.uk/peter/h261/missa.norm.h261.mpg
>
>         Do you think this quality (QCIF, grayscale, PSNR of 38) is
>         acceptable for your users?
>
>
>     That is hardly a scientific comparison.
>
>     And again, it is misleading to imply that I am advocating the
>     mass-use of H.261. I am only advocating the use of this codec in
>     the 5-10% of cases where the clients fail to agree on a common
>     upgrade path (to VP8 or H.264). In those cases, I'd happily accept
>     H.261 instead of dropping the call. You can still transcode, if
>     you so wish.
>
> It is a single example, but I think it illustrates the limits on what 
> you can achieve with a 25-year-old (really!) coding technology. The 
> page at http://www-mobile.ecs.soton.ac.uk/peter/h261/ claims that the 
> compression ratio for the above file is 25:1, with PSNR of 38. Modern 
> codecs achieve compression ratios of at least 150:1 for similar PSNR 
> with a similar talking head scene, i.e. H.261 requires at least 6x the 
> bits for the same quality.
>
> Implementing H.261 in WebRTC has a nontrivial cost. If you think H.261 
> is a realistic option, I think you need to show data that indicates it 
> can deliver decent quality at typical internet bitrates.
>

Okay, that's reasonable, though my point remains: how do we want to 
handle the 5-10% of cases where the clients can't agree on a common 
codec? For some businesses, it might very well be preferable to fallback 
to a lower-resolution H.261 feed than to drop the call or use 
transcoding. I don't believe we should make this decision on behalf of 
the client.

Is it fair to assume that a H.261 feed using the same bandwidth as VP8 
would stream roughly 6x less pixels? So say 720p would drop down to 
funky resolution of 404x303? This is definitely not great, but it's 
certainly useable depending on your use-case. Anyway, my argument is 
that this decision is best left up to the developer. There plenty of 
cases (gaming comes to mind) where using H.261 would be "good enough" 
and preferable to dropping the call or transcoding.

Gili

--------------090608040902020604020304
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 14/11/2013 1:07 AM, Justin Uberti
      wrote:

    

      


        

          
On Wed, Nov 13, 2013 at 9:22 PM,
            cowwoc <cowwoc@bbs.darktech.org>
            wrote:

            

              
On 13/11/2013 8:43 PM, Justin Uberti
                wrote:

                
Regarding
                  H.261: Consider the following clip, encoded at 256
                  kbps using H.261.

                  http://www-mobile.ecs.soton.ac.uk/peter/h261/missa.norm.h261.mpg

                  

                  Do you think this quality (QCIF, grayscale, PSNR of
                  38) is acceptable for your users?

                

                

              

              That is hardly a scientific comparison.

              

              And again, it is misleading to imply that I am advocating
              the mass-use of H.261. I am only advocating the use of
              this codec in the 5-10% of cases where the clients fail to
              agree on a common upgrade path (to VP8 or H.264). In those
              cases, I'd happily accept H.261 instead of dropping the
              call. You can still transcode, if you so wish.

              

            

            
It is a single example, but I think it illustrates the
              limits on what you can achieve with a 25-year-old
              (really!) coding technology. The page at http://www-mobile.ecs.soton.ac.uk/peter/h261/
              claims that the compression ratio for the above file is
              25:1, with PSNR of 38. Modern codecs achieve compression
              ratios of at least 150:1 for similar PSNR with a similar
              talking head scene, i.e. H.261 requires at least 6x the
              bits for the same quality.

            


            

            
Implementing H.261 in WebRTC has a nontrivial cost. If
              you think H.261 is a realistic option, I think you need to
              show data that indicates it can deliver decent quality at
              typical internet bitrates.

          

          

        

      

    

    

    Okay, that's reasonable, though my point remains: how do we want to
    handle the 5-10% of cases where the clients can't agree on a common
    codec? For some businesses, it might very well be preferable to
    fallback to a lower-resolution H.261 feed than to drop the call or
    use transcoding. I don't believe we should make this decision on
    behalf of the client.

    

    Is it fair to assume that a H.261 feed using the same bandwidth as
    VP8 would stream roughly 6x less pixels? So say 720p would drop down
    to funky resolution of 404x303? This is definitely not great, but
    it's certainly useable depending on your use-case. Anyway, my
    argument is that this decision is best left up to the developer.
    There plenty of cases (gaming comes to mind) where using H.261 would
    be "good enough" and preferable to dropping the call or transcoding.

    

    Gili

  


--------------090608040902020604020304--

From cowwoc@bbs.darktech.org  Wed Nov 13 23:04:33 2013
Return-Path: 
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 43CE621E80D2 for ; Wed, 13 Nov 2013 23:04:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.988
X-Spam-Level: 
X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 tAFEugaBEfDK for ; Wed, 13 Nov 2013 23:04:27 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4E21E8087 for ; Wed, 13 Nov 2013 23:04:27 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id to1so2150903ieb.31 for ; Wed, 13 Nov 2013 23:04:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wDq9DWugAM3R43w/0u7saTISjtzBd4kVQynjyYUQ05Q=; b=c4+He7BpM4qBbVppFkG2HUBUw3Zx5MqvhaxlA4u4FsewphIe6QZHq188r2XQWQdm9e 8olW6/kn0+6PvCRS1iBzM+Ur6tL8Or9o/fDAYorSf6ZkM80hvXN5zG7jfiiiKMnrD4H/ vwW37wn6oqlKhWgQWvkbJ0CQVE9adv16iazZlhuJqWN/7ot99C6yHmO5XXUKHWV3fSus Z5P1I/WHrcN/Ct+KB7pW00Zohdkioqq8DwqBzB4T0bAHuTqwV8dcKXP68ZCtaO+3PC3v 2qu1FQIrW5Mg/3m70Q/oHDBFQ31jtTSyDteEZh2Q5n463/gm/0T7txd3PEI0sVUFRG8h 2+YQ==
X-Gm-Message-State: ALoCoQmy9Z5f9kfrKEE1Th7J3p+wVCdod75t36h+5VYPvndY1FMmZ81WU8a/U2kjdQZWb0SNpr3H
X-Received: by 10.50.4.105 with SMTP id j9mr528176igj.52.1384412666754; Wed, 13 Nov 2013 23:04:26 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id v2sm2715317igz.3.2013.11.13.23.04.25 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 23:04:26 -0800 (PST)
Message-ID: <528475E8.9050603@bbs.darktech.org>
Date: Thu, 14 Nov 2013 02:04:08 -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: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>	<5283DADA.2080806@alvestrand.no>	<5283E530.8000409@bbs.darktech.org>	 <52845E0C.6090703@bbs.darktech.org> <52846CCF.9030203@it.aoyama.ac.jp>
In-Reply-To: <52846CCF.9030203@it.aoyama.ac.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 07:04:33 -0000

On 14/11/2013 1:25 AM, "Martin J. Dürst" wrote:
> And again, it is misleading to imply that I am advocating the mass-use
>> of H.261. I am only advocating the use of this codec in the 5-10% of
>> cases where the clients fail to agree on a common upgrade path (to VP8
>> or H.264). In those cases, I'd happily accept H.261 instead of dropping
>> the call. You can still transcode, if you so wish.
>
> Having had a look at the sample, I'd say "it depends".
>
> If the video were used to discuss e.g. some details of a new physical 
> product, higher resolution and color may be rather important, and H261 
> insufficient.
>
> If it's just to get a quick impression of the person at the other end 
> of the call, I guess it would be okay, but in that use case, there's a 
> high chance I'd overlay it with some other document even if the video 
> quality was much better.
>
> If it's one of many videos of participants in a conference call, 
> grayscale may be disappointing but better than nothing, the size may 
> be just about right, and the (relatively speaking) high bandwidth may 
> not be noticed.
>
> Regards,   Martin.

Precisely my point. It depends. There are plenty of cases where dropping 
down to H.261 is "good enough" and preferable to dropping the call 
altogether. And again, we're only talking about a minority of cases that 
will ever have to drop down to H.261.

(Note, I'm using H.261 as a placeholder. Are there other candidate 
codecs we should consider?)

Gili

From fippo@goodadvice.pages.de  Wed Nov 13 23:05:59 2013
Return-Path: 
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 DDA0E21E80FA for ; Wed, 13 Nov 2013 23:05:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level: 
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117,  BAYES_00=-2.599]
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 0czFLC2qq+4e for ; Wed, 13 Nov 2013 23:05:53 -0800 (PST)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id A672721E8087 for ; Wed, 13 Nov 2013 23:05:52 -0800 (PST)
Received: from [192.168.2.101] (p5497072F.dip0.t-ipconnect.de [84.151.7.47]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id rAE75luQ026145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Nov 2013 08:05:48 +0100
Message-ID: <52847646.9050203@goodadvice.pages.de>
Date: Thu, 14 Nov 2013 08:05:42 +0100
From: Philipp Hancke 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com>	<20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>		<5283FDF1.8030708@bbs.darktech.org>		<52845DB0.6040501@bbs.darktech.org>	<5284626C.8050504@goodadvice.pages.de> <528471AA.4060101@bbs.darktech.org>
In-Reply-To: <528471AA.4060101@bbs.darktech.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 07:05:59 -0000

> Okay, so I stand corrected (thank you for pointing this out).

heh, I'm always surprised by how many people are completly unaware that 
the innovations webrtc brings aren't new at all.

> So, I guess my new argument is: WebRTC shouldn't support any less than
> Flash ;)

That's a long list of advanced features. I'd leave things like building 
an optimized overlay to the application layer however. Hopefully a 
specification of the RTMFP groups stuff will appear as an internet draft 
so people don't start reinventing that wheel, too.

From lgeyser@gmail.com  Wed Nov 13 23:23:49 2013
Return-Path: 
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 7793321F9FA4 for ; Wed, 13 Nov 2013 23:23:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Level: 
X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 E0IIg954q2Dv for ; Wed, 13 Nov 2013 23:23:48 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 16BE221E81CA for ; Wed, 13 Nov 2013 23:23:41 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id n7so1267139lam.30 for ; Wed, 13 Nov 2013 23:23:41 -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=Hkh78ivAZ0L6/iiiBumGHhnrjpaUbZCX0QrbAxgL8ao=; b=eUKmmvtptDK19+jYS1bYIYwijGuSyIlaQNvU6wYTA8/YEMFTnIl4weqrAMU4pJVMQq BvYhFjEcfVlIQVISlaCU8olw7ns/BRWf+crCzZuBkaLN1yfZapiG8S/bpZmC7+KSm2R7 fgkl8CvOsXyPuC61SSEWweWfd9kPmUot9jFud1p5RX0Z9pfaPog8WXzzjFfqmBpmVgyF mSBuf2sgbSPulmLmcbQwvN6XtiuRHUfwFN9YzHP/FV+/Z1R3I1amWovebbHS+JzAy1xX n8m3LikJ+UVjGFEWXdFSXe7qneFbH7qpyqi1Fbk+7s8WLn4mTAl4QGBVdMY9bj9SLmJo c62A==
MIME-Version: 1.0
X-Received: by 10.112.159.231 with SMTP id xf7mr27255lbb.18.1384413820800; Wed, 13 Nov 2013 23:23:40 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Wed, 13 Nov 2013 23:23:40 -0800 (PST)
In-Reply-To: <52845E10.4040205@bbs.darktech.org>
References: <5283DFDC.4010906@ericsson.com>  <52845E10.4040205@bbs.darktech.org>
Date: Thu, 14 Nov 2013 09:23:40 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c3c4fe02d6b404eb1df619
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 07:23:49 -0000

--001a11c3c4fe02d6b404eb1df619
Content-Type: text/plain; charset=ISO-8859-1

>>SHOULD doesn't carry any accountability. Anyone will tell you they have a
"real good reason" to avoid implementing one >>codec or another. We've
heard plenty of excuses on this list of why one party or another believes
it is legally risky to >>implement VP8 or H.264, respectively. So in that
sense, it is meaningless.

I agree. SHOULD is just like 'no MTI' and point 5 also implies 'no MTI'


On 14 November 2013 07:22, cowwoc  wrote:

> On 13/11/2013 11:11 PM, cb.list6 wrote:
>
>>
>> Why no SHOULD implement vp8 and h248? SHOULD means you will do it unless
>> you have a real good reason.
>>
>>
> SHOULD doesn't carry any accountability. Anyone will tell you they have a
> "real good reason" to avoid implementing one codec or another. We've heard
> plenty of excuses on this list of why one party or another believes it is
> legally risky to implement VP8 or H.264, respectively. So in that sense, it
> is meaningless.
>
>
>  MUST is too hard for this WG.  Many implementations have a really good
>> reason to not do vp8 OR h248.
>>
>> Saying that all webrtc MUST do one or the other or both is disingenuous.
>>
>> SHOULD for both is as good as we are going to get with this complicated
>> IPR environment.  Using MUST is simply not going to work and we have 10,000
>> on this mailer to back that up.
>>
>>
> What you say is true, but if we accept this (and go with SHOULD) we are
> essentially ending up with "no MTI" which leads to the dark side
> (transcoding or dropped calls).
>
> Rock --> WebRTC <-- Hard place :)
>
> Gili
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--001a11c3c4fe02d6b404eb1df619
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


>>SHOULD doesn't carry any accountability. Anyon=
e will tell you they have a
 "real good reason" to avoid implementing one >>codec or an=
other. We've=20
heard plenty of excuses on this list of why one party or another=20
believes it is legally risky to >>implement VP8 or H.264, respectivel=
y. So
 in that sense, it is meaningless.

I agree. SHOULD is just like '=
;no MTI' and point 5 also implies 'no MTI'


On 14 November 2013 07:22, cow=
woc <cowwoc@bbs.darktech.org> wrote:


On 13/1=
1/2013 11:11 PM, cb.list6 wrote:





Why no SHOULD implement vp8 and h248? SHOULD means you will do it unless yo=
u have a real good reason.







SHOULD doesn't carry any accountability. Anyone will tell you they have=
 a "real good reason" to avoid implementing one codec or another.=
 We've heard plenty of excuses on this list of why one party or another=
 believes it is legally risky to implement VP8 or H.264, respectively. So i=
n that sense, it is meaningless.







MUST is too hard for this WG. =A0Many implementations have a really good re=
ason to not do vp8 OR h248.



Saying that all webrtc MUST do one or the other or both is disingenuous.


SHOULD for both is as good as we are going to get with this complicated IPR=
 environment. =A0Using MUST is simply not going to work and we have 10,000 =
on this mailer to back that up.







What you say is true, but if we accept this (and go with SHOULD) we are ess=
entially ending up with "no MTI" which leads to the dark side (tr=
anscoding or dropped calls).



Rock --> WebRTC <-- Hard place :)



Gili


_______________________________________________

rtcweb mailing list

rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb





--001a11c3c4fe02d6b404eb1df619--

From gonzalo.camarillo@ericsson.com  Wed Nov 13 23:38:29 2013
Return-Path: 
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 25FDA11E811D for ; Wed, 13 Nov 2013 23:38:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.614
X-Spam-Level: 
X-Spam-Status: No, score=-105.614 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 BaeGfY4Jf5uk for ; Wed, 13 Nov 2013 23:38:24 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 97A3E11E8116 for ; Wed, 13 Nov 2013 23:38:23 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-62-52847dec8f8e
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B9.DC.15980.CED74825; Thu, 14 Nov 2013 08:38:21 +0100 (CET)
Received: from [131.160.126.80] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Thu, 14 Nov 2013 08:38:20 +0100
Message-ID: <52847DEC.2020406@ericsson.com>
Date: Thu, 14 Nov 2013 09:38:20 +0200
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Stephan Wenger 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvre7b2pYgg9UvFSzW/mtnt7jeuInd gcljyZKfTB6L179nDGCK4rJJSc3JLEst0rdL4Mr4ea+ZpeAIb8W2A63sDYw3uLoYOTkkBEwk Pjz5xw5hi0lcuLeerYuRi0NI4BCjxPbLc5khnDWMEvtWPQCr4hXQlujon8UKYrMIqEq0vj3M AmKzCVhIbLl1H8wWFYiS2LD9AgtEvaDEyZlPwGwRARWJQzd/gNnMAuoSdxafA5rJwSEsYClx 4bgJSFhIQEfi4KfHYKs4BXQl7l+dzARxnKTElhft7BCtehJTrrYwQtjyEs1bZzND9GpLLH/W wjKBUWgWks2zkLTMQtKygJF5FSN7bmJmTnq5+SZGYKge3PLbYAfjpvtihxilOViUxHk/vHUO EhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cB45IiV8MSXciderV8ncOzC7YpbU2TnHVXU8FS6 wczpk9vuVHHNTWlxSYSq0aYH212X5EtPlJggMstxA9cjua+zr0fN2x7xsOi1Vbj8vR7Be+3p UlXM/KtztkU8N4tVWmgtO6+s5McKXU+e17K/+pc+VinS2eKW+5FN5Z8X5+NtHIfv60XzCgQq sRRnJBpqMRcVJwIA2334OCMCAAA=
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 07:38:29 -0000

Hi Stephan,

yes, the wording you suggest captures the idea in a clearer way.

Thanks,

Gonzalo

On 14/11/2013 12:17 AM, Stephan Wenger wrote:
> Hi Gonzalo, 
> Re your point 5.: ³either or² is often understood as an exclusive or.  I
> don¹t think anyone proposed that.  A better way to express 5. would be
> ³All entities MUST support at least one of H.264 and VP8².
> Stephan
> 
> On 11.13.2013, 12:23 , "Gonzalo Camarillo"
>  wrote:
> 
>> Folks,
>>
>> I hope everybody had a safe trip back home after Vancouver.
>>
>> As you all know, we need to make progress regarding the selection of the
>> MTI video codec. The following are some of the alternatives we have on
>> the table:
>>
>> 1. All entities MUST support H.264
>> 2. All entities MUST support VP8
>> 3. All entities MUST support both H.264 and VP8
>> 4. Browsers MUST support both H.264 and VP8
>> 5. All entities MUST support either H.264 or VP8
>> 6. All entities MUST support H.261
>> 7. There is no MTI video codec
>>
>> If you want the group to consider additional alternatives to the ones
>> above, please let the group know within the following *two weeks*. At
>> that point, the chairs will be listing all the received alternatives and
>> proposing a process to select one among them.
>>
>> Please, send your proposals in an email to the list. You do not need to
>> write a draft; just send the text you would like to see in the final
>> document regarding video codecs.
>>
>> Thanks,
>>
>> Gonzalo
>> Responsible AD for this WG
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 


From gonzalo.camarillo@ericsson.com  Thu Nov 14 00:10:56 2013
Return-Path: 
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 08F7311E8178 for ; Thu, 14 Nov 2013 00:10:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.628
X-Spam-Level: 
X-Spam-Status: No, score=-105.628 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 rlPp3U0FQtbF for ; Thu, 14 Nov 2013 00:10:48 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D8E6311E811D for ; Thu, 14 Nov 2013 00:10:47 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-43-5284858331ac
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EA.EB.03802.38584825; Thu, 14 Nov 2013 09:10:43 +0100 (CET)
Received: from [131.160.126.80] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.328.9; Thu, 14 Nov 2013 09:10:43 +0100
Message-ID: <52848582.1070408@ericsson.com>
Date: Thu, 14 Nov 2013 10:10:42 +0200
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Harald Alvestrand 
References: <5283DF61.9060807@alvestrand.no>
In-Reply-To: <5283DF61.9060807@alvestrand.no>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+JvrW5za0uQwdol1hbH+rrYLPZun8do sfZfO7vFtHkfGR1YPK5MuMLqsWTJTyaPL5c/swUwR3HZpKTmZJalFunbJXBlXD39ib1guWzF 6e8fmBoYZ4l3MXJySAiYSLS0H2KBsMUkLtxbz9bFyMUhJHCIUeLS8Q2sEM4aRomrc7axgVTx CmhLLFvwnwnEZhFQlZhyZj1YN5uAhcSWW/fBbFGBKIkN2y+wQNQLSpyc+QTMFhHQkXi4vwGs l1kgVuLrhLVgtrCAocTF2+/BaoSAanY9eg62i1NAV2LOlxeMENdJSmx50c4O0asnMeVqCyOE LS+x/e0cZohebYnlz1pYJjAKzUKyehaSlllIWhYwMq9iZM9NzMxJLzfaxAgM5YNbfqvuYLxz TuQQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGLest05UT7jAsGhV9rVX RlITdig3MYdJKRvfi1/K0Nnw+t2d9UvqMqWNa1NnPLxqeuV31KwtHyp+l+r3PVv8JVHakNEt Y7rMkhvuK30zojpbzpy0/TI747vJvT8KVbK1iwpYKh5se9YZLzfzVMT7dW9UqpgimDSPXeg4 PsuNf0uqC3+0wvNVjUosxRmJhlrMRcWJADIFp6UzAgAA
Cc: rai-ads@tools.ietf.org, "rtcweb@ietf.org" , tsv-ads@tools.ietf.org
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 08:10:57 -0000

Hi Harald,

thanks for your email. I will touch base with the TSV ADs and with Wes
(former TSV AD) and get a status update on this piece of work. It will
take a few days, though (when Martin will be back, as Spencer also
mentioned in this thread). We will keep the group posted.

Cheers,

Gonzalo

On 13/11/2013 10:21 PM, Harald Alvestrand wrote:
> This mail concerns both administrative and technical issues, which is
> why it is explicitly copied to the ADs of RAI and TSV. I hope I have
> managed to keep them separate in the message.
> 
> Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:
> 
>> Okay, we might not have been public enough on this. It was requested by
>> the Transport ADs quite some time ago that doing the QoS document in our
>> WG was not appropriate and requested us to direct the document to TSVWG.
>> Which was done, and where it hasn't made progress.
>>
>> You might have noted that James Polk did comment in the milestone part
>> in the monday session of IETF88 about our QoS milestone should be killed.
> I want to protest this - both practically and formally.
> 
> To get the formal stuff out of the way first:
> 
> Changing the deliverables of the working group *without telling the
> working group* is totally inappropriate in an open, consensus-driven
> process.
> Changing the deliverables of the working group *without telling the
> working group why* and *without allowing those reasons to be debated* is
> totally inappropriate in an open, consensus-driven process.
> 
> I protest against this action.
> 
> ACTION REQUEST 1: I request that this decision be declared null and
> void, and that the relevant ADs send out a message to RTCWEB (and TSVWG
> if appropriate) *PROPOSING* such an action, and giving a reasonable
> timeline for when they will make a decision based on mailing list feedback.
> 
> In practice:
> 
> The draft as it existed before its untimely demise consisted of two things:
> 
> - A description of how QoS mechanisms could be useful in the RTCWEB use case
> - A description of existing mechanisms that could be appropriate for the
> RTCWEB use case
> 
> The first one is clearly something that needs RTCWEB consensus. It seems
> to have no need for, nor likelyhood of gathering interest enough for, a
> TSVWG consensus.
> 
> There could be some argument that the second part needs TSVWG consensus,
> especially if it was redefining any mechanisms, or it was making choices
> between mechanisms where TSVWG had strong opinions about which
> mechanisms should be chosen, but had not chosen to document that in any
> document on which IETF consensus had been declared (that is to say,
> existing RFCs).
> 
> My archive shows 36 messages where the title refers to this draft. It
> shows no messages declaring that feedback has been incorporated and
> calling for new review - something that is usually necessary to get a WG
> consensus on any document. The debate hasn't been conclusive, but then,
> it hasn't been pushed hard either.
> 
> The people who know how RTCWEB works are in this working group. Some of
> them may be in TSV, but I think the locus of knowledge for saying what
> QoS mechanisms are appropriate for RTCWEB are here, not in TSV.
> 
> This results in my second request.
> 
> ACTION REQUEST 2: I request that the chairs declare that based on the
> debate about the QoS functionality so far, the document should be
> resurrected, and will continue to be  worked on in the RTCWEB working
> group, bringing in advice from TSVWG as required to make sure the
> descriptions of underlying mechanisms, and the choice of such
> mechanisms, is correct and appropriate.
> 
> 
> 
> 


From tim@phonefromhere.com  Thu Nov 14 00:50:07 2013
Return-Path: 
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 C4A9911E817B for ; Thu, 14 Nov 2013 00:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Level: 
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, HTML_MESSAGE=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 0D0aDLFvFgjP for ; Thu, 14 Nov 2013 00:50:01 -0800 (PST)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id D681611E8172 for ; Thu, 14 Nov 2013 00:50:00 -0800 (PST)
Received: (qmail 57307 invoked from network); 14 Nov 2013 08:49:52 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 1200
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 14 Nov 2013 08:49:52 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id F288A18A0411; Thu, 14 Nov 2013 08:49:51 +0000 (GMT)
Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 6503918A0379;  Thu, 14 Nov 2013 08:49:51 +0000 (GMT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_77DAE0E4-47E1-445F-BA27-9AFF21C19133"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Tim Panton 
In-Reply-To: <20131113165526.GA13468@verdi>
Date: Thu, 14 Nov 2013 08:49:10 +0000
Message-Id: <73223543-696E-48B4-A293-1EE075DD78DD@phonefromhere.com>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1816)
Cc: Neil Stratford 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 08:50:07 -0000

--Apple-Mail=_77DAE0E4-47E1-445F-BA27-9AFF21C19133
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On 13 Nov 2013, at 16:55, John Leslie  wrote:

>  Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
> IMHO, will achieve consensus for "MUST implement" status. Yes, this
> is a sorry state to find ourselves in. But the marketplace has
> sorted out much worse problems in my memory.
>=20
>   And I claim that both camps are actually more likely to implement
> (or allow extensions for) the other side's codec if it is _not_ MTI,
> simply because they can back out at the first sign of lawyers.
>=20
>   I will not go into any details about how VP8 endpoints might talk
> to H.264 endpoints, but I'm _very_ confident ways will be found if
> we actually _publish_ an RFC saying both are "SHOULD implement".
>=20
>   (Surely I'm not the _only_ person who'd like to see _both_ H.264
> and VP8 legacy devices using our standard...)

I'm coming around to this POV. With the possible slight variant that we =
should clarify
that this applies to _browsers_ not rtcweb compatible endpoints.

Ideally we'd see browsers implementing both VP8 and H264 - but single =
purpose=20
endpoints (doorbells, prison video phones, baby alarms, smart-fashion =
mirrors, video mixers etc) using whichever
codec suits their hardware/legal/usecase needs best, and exchanging =
rtcweb media with
a browser at the far end.=20

Non browser endpoints need to be confident they can talk to any browser =
and browsers need to
be able to talk to anything.

I think that's what is behind the option #4 in Gonzalo's proposal.=20
>  4. Browsers MUST support both H.264 and VP8

- What this highlights is that we've created a media protocol that will =
be used by things that aren't browsers,
we need to address that requirement, without just seeing it as legacy =
support.

Tim.

Tip of the Hat to @nstratford for helping clarify my thinking on this.



--Apple-Mail=_77DAE0E4-47E1-445F-BA27-9AFF21C19133
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On 13 Nov 2013, at 16:55, John Leslie =
<john@jlc.net> wrote:

 Both H.264 and VP8 deserve "SHOULD implement" status. =
Neither,
IMHO, will achieve consensus for "MUST implement" status. =
Yes, this
is a sorry state to find ourselves in. But the marketplace =
has
sorted out much worse problems in my memory.

  And I claim that =
both camps are actually more likely to implement
(or allow extensions for) the other side's codec if it is =
_not_ MTI,
simply because they can back out at the first sign of =
lawyers.

  I will not go into any details about how VP8 =
endpoints might talk
to H.264 endpoints, but I'm _very_ =
confident ways will be found if
we actually _publish_ an RFC =
saying both are "SHOULD implement".

  (Surely I'm not the =
_only_ person who'd like to see _both_ H.264
and VP8 legacy devices using our standard...)

I'm =
coming around to this POV. With the possible slight variant that we =
should clarify
that this applies to _browsers_ not rtcweb =
compatible endpoints.

Ideally we'd see browsers =
implementing both VP8 and H264 - but single =
purpose 
endpoints (doorbells, prison video phones, baby =
alarms, smart-fashion mirrors, video mixers etc) using =
whichever
codec suits their hardware/legal/usecase needs best, =
and exchanging rtcweb media with
a browser at the far =
end. 

Non browser endpoints need to be =
confident they can talk to any browser and browsers need to
be =
able to talk to anything.

I think that's what =
is behind the option #4 in Gonzalo's =
proposal. 
 4. Browsers =
MUST support both H.264 and VP8

- What =
this highlights is that we've created a media protocol that will be used =
by things that aren't browsers,
we need to address that =
requirement, without just seeing it as legacy =
support.

Tim.

Tip of the =
Hat to @nstratford for helping clarify my thinking on this.



=

--Apple-Mail=_77DAE0E4-47E1-445F-BA27-9AFF21C19133--

From magnus.westerlund@ericsson.com  Thu Nov 14 00:56:17 2013
Return-Path: 
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 7A67E21E8087 for ; Thu, 14 Nov 2013 00:56:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.526
X-Spam-Level: 
X-Spam-Status: No, score=-105.526 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 95h8pJnX-IcY for ; Thu, 14 Nov 2013 00:56:11 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8369121E814A for ; Thu, 14 Nov 2013 00:56:10 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-04-5284902792c0
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E6.C1.03802.72094825; Thu, 14 Nov 2013 09:56:07 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.328.9; Thu, 14 Nov 2013 09:56:06 +0100
Message-ID: <52849076.4020605@ericsson.com>
Date: Thu, 14 Nov 2013 09:57:26 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: 
References: <5283DFDC.4010906@ericsson.com>	 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvra76hJYgg+eTZC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqxl8gUblSpu7VnK1MC4SKqLkZNDQsBE4snvi4wQtpjEhXvr 2boYuTiEBA4xSlw7vQnKWc4oce/rXSaQKl4BbYm/O0+xgdgsAqoSjzpXsoLYbAIWEjd/NILF RQWCJc6/WswOUS8ocXLmExYQW0RAVOL142lA9RwcwgKWEheOm0DMn8go8e3je7ArOAUCJRa8 6QarkRAQl+hpDAIJMwvoSUy52sIIYctLNG+dzQxiCwGd09DUwTqBUXAWkm2zkLTMQtKygJF5 FSN7bmJmTnq50SZGYPAd3PJbdQfjnXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cAo7LvCJfdUtJfJF/OirS9ZZ3K/+x7PEGPvrnPNungby9RbhhwJ/2c5vV/EfND4 sNPNzKwPZgY39/tceSYSquzd7RZ5yP128sYNHR/eWvzoybXR6zRnTHA+s0fg6Q2rcy9mKv39 dkq0SXNusdOtAJseyXT7OXdl5PrFu2X4+PnK5KKVKm+4T1diKc5INNRiLipOBABorLQ1DAIA AA==
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 08:56:17 -0000

Hi,

If no one is protesting I would suggest that we update four to say:

4. Browsers MUST support both H.264 and VP8, other entities MUST support
at least one of H.264 and VP8

This makes this alternative clearer I believe.

Cheers

Magnus


On 2013-11-14 03:26, Jonathan Rosenberg wrote:
> Regarding number 4, here is how I think of it:
> 
> If browsers implement both, it means that an application provider
> wishing to offer a service (take Hangouts or Skype as examples), can
> pick the one they like, implement just that in their native apps
> (mobile, desktop, etc.) where the app provider has control over the full
> stack, and still work with clients of that service which run in the
> browser, where the app provider does not have control over the full
> stack as the real-time media stack is provided by the browser and not
> the web app. 
> 
> The benefit of this approach is that it enables interoperability between
> clients on different platforms for the same provider.
> 
> The drawback is, for inter-service federation (which requires much more
> than just codecs to be aligned), you might run into a case where a user
> using a mobile app from provider 1 (say, Skype) calls a user using a
> mobile app from provider 2 (say, Hangouts), and then since each chose a
> different video codec, there is no common codec. Of course that assumes
> the two providers in question are willing to even federate in the first
> place. 
> 
> -Jonathan R.
> 
> 
> 
> 
> On Wed, Nov 13, 2013 at 5:17 PM, Stephan Wenger  > wrote:
> 
>     Hi Gonzalo,
>     Re your point 5.: ³either or² is often understood as an exclusive or.  I
>     don¹t think anyone proposed that.  A better way to express 5. would be
>     ³All entities MUST support at least one of H.264 and VP8².
>     Stephan
> 
>     On 11.13.2013, 12:23 , "Gonzalo Camarillo"
>          > wrote:
> 
>     >Folks,
>     >
>     >I hope everybody had a safe trip back home after Vancouver.
>     >
>     >As you all know, we need to make progress regarding the selection
>     of the
>     >MTI video codec. The following are some of the alternatives we have on
>     >the table:
>     >
>     > 1. All entities MUST support H.264
>     > 2. All entities MUST support VP8
>     > 3. All entities MUST support both H.264 and VP8
>     > 4. Browsers MUST support both H.264 and VP8
>     > 5. All entities MUST support either H.264 or VP8
>     > 6. All entities MUST support H.261
>     > 7. There is no MTI video codec
>     >
>     >If you want the group to consider additional alternatives to the ones
>     >above, please let the group know within the following *two weeks*. At
>     >that point, the chairs will be listing all the received
>     alternatives and
>     >proposing a process to select one among them.
>     >
>     >Please, send your proposals in an email to the list. You do not need to
>     >write a draft; just send the text you would like to see in the final
>     >document regarding video codecs.
>     >
>     >Thanks,
>     >
>     >Gonzalo
>     >Responsible AD for this WG
>     >
>     >_______________________________________________
>     >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
> 
> 
> 
> 
> -- 
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net 
> http://www.jdrosen.net
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Thu Nov 14 01:07:15 2013
Return-Path: 
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 AC98C21E8174 for ; Thu, 14 Nov 2013 01:07:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.713
X-Spam-Level: 
X-Spam-Status: No, score=-103.713 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 H9pa2FjXGqDI for ; Thu, 14 Nov 2013 01:07:07 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 263EC21E8116 for ; Thu, 14 Nov 2013 01:06:33 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-23-52849298a81b
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C7.B5.27941.89294825; Thu, 14 Nov 2013 10:06:33 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Thu, 14 Nov 2013 10:06:32 +0100
Message-ID: <528492E8.8020202@ericsson.com>
Date: Thu, 14 Nov 2013 10:07:52 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: 
References: <5283DFDC.4010906@ericsson.com>
In-Reply-To: <5283DFDC.4010906@ericsson.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvre7MSS1BBuv3sFqs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEl7jzEV3OaveHP9DGsD4y6eLkZODgkBE4nnLZ9ZIWwxiQv3 1rN1MXJxCAkcYZQ49fwMM4SznFFi2vKPTF2MHBy8AtoSk1s0QRpYBFQlTl09ygRiswlYSNz8 0cgGYosKBEucf7WYHcTmFRCUODnzCQuILSIgKvH68TRWkDHCApYSF46bgISFgCa275wA1sop oCOx5fViNpASCQFxiZ7GIJAws4CexJSrLYwQtrxE89bZzDCtDU0drBMYBWchWTYLScssJC0L GJlXMXIUpxYn5aYbGWxiBAbfwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2Mt41LDjHtXm2upM7i//TOcfOW3ZY6JV9Xl5jp5gnns3382+k0zzi87uCZ aVkp9iZW107HnUydsUhRnX8he/QXq0Orpi4uao7hmeCsdltz3ourm+/Gq0QuPLc9vHneCmH2 xfvi7xde5fysuewrh+25mYs9vp7e3RkaXqnOvzHqqfNv/arZh99KKrEUZyQaajEXFScCAId+ 2k0MAgAA
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 09:07:16 -0000

WG,

I have put the given video codec selection alternatives on this wikipage:

http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart

It is not acceptable to simply add things on this list. You need to send
email to the list.

Cheers

Magnus


On 2013-11-13 21:23, Gonzalo Camarillo wrote:
> Folks,
> 
> I hope everybody had a safe trip back home after Vancouver.
> 
> As you all know, we need to make progress regarding the selection of the
> MTI video codec. The following are some of the alternatives we have on
> the table:
> 
>  1. All entities MUST support H.264
>  2. All entities MUST support VP8
>  3. All entities MUST support both H.264 and VP8
>  4. Browsers MUST support both H.264 and VP8
>  5. All entities MUST support either H.264 or VP8
>  6. All entities MUST support H.261
>  7. There is no MTI video codec
> 
> If you want the group to consider additional alternatives to the ones
> above, please let the group know within the following *two weeks*. At
> that point, the chairs will be listing all the received alternatives and
> proposing a process to select one among them.
> 
> Please, send your proposals in an email to the list. You do not need to
> write a draft; just send the text you would like to see in the final
> document regarding video codecs.
> 
> Thanks,
> 
> Gonzalo
> Responsible AD for this WG
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From lgeyser@gmail.com  Thu Nov 14 01:37:18 2013
Return-Path: 
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 007DE21E81DB for ; Thu, 14 Nov 2013 01:37:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.368
X-Spam-Level: 
X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 muJXvp01IgUc for ; Thu, 14 Nov 2013 01:37:17 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B92FF21E819A for ; Thu, 14 Nov 2013 01:37:16 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id n7so1326392lam.2 for ; Thu, 14 Nov 2013 01:37:15 -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=FwMwmrRyCF5DhW+EWLhrxTUMgPBeBjNSRQTOF2cdZxU=; b=QSIlxg5ZCSb2mRlPryTFoSeZ1J+wHrbXCphC0seZGIx3Rf5BMqU5iiyKpT14Te2z5q IohET9qEEnIghmH/0uQxFazFpCWkUKc/a4VNE+BdpQLc82cxNuxFW0WIpMjvZbULPepk aXa7YG1qPRqD38p/AYGxXhmmzTIwPf9V+1fM1uH8lvKGLSqIADlbWTJmi+3ckIKYaXt/ tM9XtNU8nVvtp5RdbGHPy8ZTw3IK3DeYtA15MOiivVZeMG/GcEIMhe+bZhdbImuEOGYn OP7164oSVC3X5UI7ihwGfRR0Gbtl6CPxp+kUX7QKBSe/Ai6ILgqfLlpU2xxsKunvR1nH mg2w==
MIME-Version: 1.0
X-Received: by 10.152.120.73 with SMTP id la9mr259946lab.3.1384421835464; Thu, 14 Nov 2013 01:37:15 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 14 Nov 2013 01:37:15 -0800 (PST)
In-Reply-To: <528492E8.8020202@ericsson.com>
References: <5283DFDC.4010906@ericsson.com> <528492E8.8020202@ericsson.com>
Date: Thu, 14 Nov 2013 11:37:15 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e011766e5b8e54c04eb1fd362
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 09:37:18 -0000

--089e011766e5b8e54c04eb1fd362
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Point 6 can change to:
All entities MUST support H.261 and all entities MUST support at least one
of H.264 and VP8
or it can be made a new point?

I don't like point 5 at all since it doesn't really help with negotiation
failure IMO. Implement the codec that you want to implement =3D No MTI.


On 14 November 2013 11:07, Magnus Westerlund  wrote:

> WG,
>
> I have put the given video codec selection alternatives on this wikipage:
>
> http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart
>
> It is not acceptable to simply add things on this list. You need to send
> email to the list.
>
> Cheers
>
> Magnus
>
>
> On 2013-11-13 21:23, Gonzalo Camarillo wrote:
> > Folks,
> >
> > I hope everybody had a safe trip back home after Vancouver.
> >
> > As you all know, we need to make progress regarding the selection of th=
e
> > MTI video codec. The following are some of the alternatives we have on
> > the table:
> >
> >  1. All entities MUST support H.264
> >  2. All entities MUST support VP8
> >  3. All entities MUST support both H.264 and VP8
> >  4. Browsers MUST support both H.264 and VP8
> >  5. All entities MUST support either H.264 or VP8
> >  6. All entities MUST support H.261
> >  7. There is no MTI video codec
> >
> > If you want the group to consider additional alternatives to the ones
> > above, please let the group know within the following *two weeks*. At
> > that point, the chairs will be listing all the received alternatives an=
d
> > proposing a process to select one among them.
> >
> > Please, send your proposals in an email to the list. You do not need to
> > write a draft; just send the text you would like to see in the final
> > document regarding video codecs.
> >
> > Thanks,
> >
> > Gonzalo
> > Responsible AD for this WG
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> F=E4r=F6gatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--089e011766e5b8e54c04eb1fd362
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Point 6 can change to:
All entities MUST supp=
ort H.261 and all entities MUST support at least one of H.264 and VP8
or it can be made a new point?

I don't like point 5 at=
 all since it doesn't really help with negotiation failure IMO. Impleme=
nt the codec that you want to implement =3D No MTI.




On 14 N=
ovember 2013 11:07, Magnus Westerlund <magnus.westerlund@eric=
sson.com> wrote:


WG,



I have put the given video codec selection alternatives on this wikipage:


http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart


It is not acceptable to simply add things on this list. You need to send
email to the list.



Cheers



Magnus






On 2013-11-13 21:23, Gonzalo Camarillo wrote:

> Folks,

>

> I hope everybody had a safe trip back home after Vancouver.

>

> As you all know, we need to make progress regarding the selection of t=
he

> MTI video codec. The following are some of the alternatives we have on=


> the table:

>

> =A01. All entities MUST support H.264

> =A02. All entities MUST support VP8

> =A03. All entities MUST support both H.264 and VP8

> =A04. Browsers MUST support both H.264 and VP8

> =A05. All entities MUST support either H.264 or VP8

> =A06. All entities MUST support H.261

> =A07. There is no MTI video codec

>

> If you want the group to consider additional alternatives to the ones<=
br>
> above, please let the group know within the following *two weeks*. At<=
br>
> that point, the chairs will be listing all the received alternatives a=
nd

> proposing a process to select one among them.

>

> Please, send your proposals in an email to the list. You do not need t=
o

> write a draft; just send the text you would like to see in the final
> document regarding video codecs.

>

> Thanks,

>

> Gonzalo

> Responsible AD for this WG

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>






--



Magnus Westerlund



----------------------------------------------------------------------

Multimedia Technologies, Ericsson Research EAB/TVM

----------------------------------------------------------------------

Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287

F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com

----------------------------------------------------------------------




_____________________________=
__________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--089e011766e5b8e54c04eb1fd362--

From gonzalo.camarillo@ericsson.com  Thu Nov 14 01:51:59 2013
Return-Path: 
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 A67A121E81DD for ; Thu, 14 Nov 2013 01:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.816
X-Spam-Level: 
X-Spam-Status: No, score=-103.816 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 B9Ga4BrrS8KJ for ; Thu, 14 Nov 2013 01:51:54 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 210ED21E8092 for ; Thu, 14 Nov 2013 01:51:53 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-01-52849d38221e
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 48.BB.27941.83D94825; Thu, 14 Nov 2013 10:51:52 +0100 (CET)
Received: from [131.160.126.80] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Thu, 14 Nov 2013 10:51:51 +0100
Message-ID: <52849D37.9030601@ericsson.com>
Date: Thu, 14 Nov 2013 11:51:51 +0200
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: 
References: <5283DFDC.4010906@ericsson.com>
In-Reply-To: <5283DFDC.4010906@ericsson.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvra7F3JYgg71HVCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsztiQVtAhWPHx5jb2C8ydPFyMkhIWAi8XtSByOELSZx4d56 ti5GLg4hgSOMEk/+bmWCcNYwSsy/9p0NpIpXQFvi1PR+li5GDg4WAVWJM9sTQMJsAhYSW27d ZwGxRQWiJDZsv8ACUS4ocXLmEzBbREBU4vXjaawgrcIClhIXjpuAhIWAJrbvnAA2nVNAR2LL 68VsEPdISmx50c4OYjML6ElMudrCCGHLS2x/O4cZpnf5sxaWCYyCs5Bsm4WkZRaSlgWMzKsY OYpTi5Ny040MNjECg+/glt8WOxgv/7U5xCjNwaIkzvvxrXOQkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBkZv447mbQIiv6ecPc08a2O/q2LNxjPV//MvFJy55n2P935+QlBf5AR1zsL8ny61 5xo/ejedu/z9YYiM079Q7i3TThcVLHqwjXlx2WSmk64fHOcdXHl62eqv919+XhjQ1nKF4+xU 8YeKhvE5gouMM36KfGc5Gtk8Y+av3Y63dQt+RlorTjRf/W+9EktxRqKhFnNRcSIAgTQfggwC AAA=
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 09:51:59 -0000

Hi,

with respect to what types of alternatives will be considered, at this
point I would prefer to focus on agreeing on a MUST-level statement.
Once we do that, we can consider SHOULD-level statements if the group
considers them important.

Additionally, there have been a few suggestions related to combining
several options. For example, 4+5 or 5+6. I would suggest to keep these
combinations separate and not to treat them as completely new options
for clarity. Such separation would help us decide among atomic options
(which is already difficult enough) as opposed to deciding among
more-complex combinations.

In any case, these are just my preferences. As usual, I will let the
chairs manage this process with the inputs of the WG.

Cheers

Gonzalo

On 13/11/2013 10:23 PM, Gonzalo Camarillo wrote:
> Folks,
> 
> I hope everybody had a safe trip back home after Vancouver.
> 
> As you all know, we need to make progress regarding the selection of the
> MTI video codec. The following are some of the alternatives we have on
> the table:
> 
>  1. All entities MUST support H.264
>  2. All entities MUST support VP8
>  3. All entities MUST support both H.264 and VP8
>  4. Browsers MUST support both H.264 and VP8
>  5. All entities MUST support either H.264 or VP8
>  6. All entities MUST support H.261
>  7. There is no MTI video codec
> 
> If you want the group to consider additional alternatives to the ones
> above, please let the group know within the following *two weeks*. At
> that point, the chairs will be listing all the received alternatives and
> proposing a process to select one among them.
> 
> Please, send your proposals in an email to the list. You do not need to
> write a draft; just send the text you would like to see in the final
> document regarding video codecs.
> 
> Thanks,
> 
> Gonzalo
> Responsible AD for this WG
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 


From silviapfeiffer1@gmail.com  Thu Nov 14 02:08:29 2013
Return-Path: 
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 B80E421E80AC for ; Thu, 14 Nov 2013 02:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, 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 yk2jT1IjYD2G for ; Thu, 14 Nov 2013 02:08:29 -0800 (PST)
Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2B00F21E808D for ; Thu, 14 Nov 2013 02:08:29 -0800 (PST)
Received: by mail-oa0-f45.google.com with SMTP id m1so1970588oag.32 for ; Thu, 14 Nov 2013 02:08:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FbWYJb8CDZAWYE/9BFV7QCkArj17//KiEgEa5BNbkiE=; b=Eb7eqWBqMke6UhRalshIV9hJFrrDODeo2K5d8IT54l5QjjZ3dX/rbq7HCm98h7VQCY cwMQb6K2FoOadymMlER7KuRkMjGke8S+E/7gZiSCynlCiAV3fiAULH4e99rZeRcQ88IM gTNYx0XN8ASUpCoSHrE1xv3xmum51lPe8EJX6xWQR5fm9gR4zuTgHvtWsbCzhTmes5Bg AUpa4NEGs2kXXQRs6owLFOJaiJNiJKSoyvqLbyS99PWMPnPLK7HLCS5ekJ/btv3Wk0Wt FUy0ebJCJQXcs0t727M9HNps9ahWgOPBCyydCIHGhdlOYPKGXAXa6dOkJtdodByA3wgb poaA==
X-Received: by 10.182.18.9 with SMTP id s9mr520314obd.15.1384423707394; Thu, 14 Nov 2013 02:08:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.68.164 with HTTP; Thu, 14 Nov 2013 02:08:07 -0800 (PST)
In-Reply-To: <52847646.9050203@goodadvice.pages.de>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283E700.5090300@bbs.darktech.org>  <5283FDF1.8030708@bbs.darktech.org>  <52845DB0.6040501@bbs.darktech.org> <5284626C.8050504@goodadvice.pages.de> <528471AA.4060101@bbs.darktech.org> <52847646.9050203@goodadvice.pages.de>
From: Silvia Pfeiffer 
Date: Thu, 14 Nov 2013 18:08:07 +0800
Message-ID: 
To: Philipp Hancke 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 10:08:29 -0000

On Thu, Nov 14, 2013 at 3:05 PM, Philipp Hancke
 wrote:
>> Okay, so I stand corrected (thank you for pointing this out).
>
>
> heh, I'm always surprised by how many people are completly unaware that the
> innovations webrtc brings aren't new at all.

Right. HTML is just another word processing format, too. :-)
Silvia.

From magnus.westerlund@ericsson.com  Thu Nov 14 02:18:22 2013
Return-Path: 
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 E985A21E81E9 for ; Thu, 14 Nov 2013 02:18:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.52
X-Spam-Level: 
X-Spam-Status: No, score=-105.52 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 PU3+7S3jtlWN for ; Thu, 14 Nov 2013 02:18:17 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 586D921E81DF for ; Thu, 14 Nov 2013 02:18:17 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-d8-5284a363ae9e
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F1.0D.03802.363A4825; Thu, 14 Nov 2013 11:18:11 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Thu, 14 Nov 2013 11:18:11 +0100
Message-ID: <5284A3B3.2090504@ericsson.com>
Date: Thu, 14 Nov 2013 11:19:31 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Leon Geyser , "rtcweb@ietf.org" 
References: <5283DFDC.4010906@ericsson.com>	<528492E8.8020202@ericsson.com> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Vjd5cUuQwcczJhbdq2exWaz9187u wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGVsu9HFUjBPoeLa1ZvsDYwNEl2MnBwSAiYS zY+OskHYYhIX7q0Hsrk4hAQOMUosvdgG5SxnlFjwawYjSBWvgLbEjt71YDaLgKrE0QVXwbrZ BCwkbv5oBLNFBYIlzr9azA5RLyhxcuYTFhBbRMBDYsa11axdjBwcwgKWEheOm0DMn8AosfoC xBxOgUCJZ59bGUFqJATEJXoag0DCzAJ6ElOutjBC2PISzVtnM4PYQkDnNDR1sE5gFJyFZNss JC2zkLQsYGRexciem5iZk15utIkRGJIHt/xW3cF455zIIUZpDhYlcd4Pb52DhATSE0tSs1NT C1KL4otKc1KLDzEycXBKNTBq3N4S82GZj75LoUXMtHLfhw6N6/dYfZFwKijdb7xvvcbPnBVM /LmiKuJbUtQNxH5Hbgi4EcfzVXz6sq/brSIX1yyb/SNwyfkFEoUGXPHv9d89P3JaWDhFTLE9 7r7k+xcvvyV7z3ofl/wqRfm1eFDkKhnOd8LtJ/293B/99peYK1BrZWJlNFWJpTgj0VCLuag4 EQCjX4QQFwIAAA==
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 10:18:23 -0000

On 2013-11-14 10:37, Leon Geyser wrote:
> Point 6 can change to:
> All entities MUST support H.261 and all entities MUST support at least
> one of H.264 and VP8
> or it can be made a new point?

I think that would be a new point. It has a significantly different
implications than the current 6. I will add it as 9. to the list.
Unless you like to withdraw it from consideration.


> 
> I don't like point 5 at all since it doesn't really help with
> negotiation failure IMO. Implement the codec that you want to implement
> = No MTI.

I agree that is not an MTI. However, it reduces the space of possible
video codec implementations a transcoder absolutely need to support to
only two, instead of any. Thus, I has merit in the set of proposals for
alternatives.

Cheers

Magnus

> 
> 
> On 14 November 2013 11:07, Magnus Westerlund
> >
> wrote:
> 
>     WG,
> 
>     I have put the given video codec selection alternatives on this
>     wikipage:
> 
>     http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart
> 
>     It is not acceptable to simply add things on this list. You need to send
>     email to the list.
> 
>     Cheers
> 
>     Magnus
> 
> 
>     On 2013-11-13 21:23, Gonzalo Camarillo wrote:
>     > Folks,
>     >
>     > I hope everybody had a safe trip back home after Vancouver.
>     >
>     > As you all know, we need to make progress regarding the selection
>     of the
>     > MTI video codec. The following are some of the alternatives we have on
>     > the table:
>     >
>     >  1. All entities MUST support H.264
>     >  2. All entities MUST support VP8
>     >  3. All entities MUST support both H.264 and VP8
>     >  4. Browsers MUST support both H.264 and VP8
>     >  5. All entities MUST support either H.264 or VP8
>     >  6. All entities MUST support H.261
>     >  7. There is no MTI video codec
>     >
>     > If you want the group to consider additional alternatives to the ones
>     > above, please let the group know within the following *two weeks*. At
>     > that point, the chairs will be listing all the received
>     alternatives and
>     > proposing a process to select one among them.
>     >
>     > Please, send your proposals in an email to the list. You do not
>     need to
>     > write a draft; just send the text you would like to see in the final
>     > document regarding video codecs.
>     >
>     > Thanks,
>     >
>     > Gonzalo
>     > Responsible AD for this WG
>     >
>     > _______________________________________________
>     > rtcweb mailing list
>     > rtcweb@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/rtcweb
>     >
>     >
> 
> 
>     --
> 
>     Magnus Westerlund
> 
>     ----------------------------------------------------------------------
>     Multimedia Technologies, Ericsson Research EAB/TVM
>     ----------------------------------------------------------------------
>     Ericsson AB                | Phone  +46 10 7148287
>     
>     Färögatan 6                | Mobile +46 73 0949079
>     
>     SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>     
>     ----------------------------------------------------------------------
> 
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org 
>     https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Thu Nov 14 02:22:18 2013
Return-Path: 
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 43F9A21E80B9 for ; Thu, 14 Nov 2013 02:22:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.707
X-Spam-Level: 
X-Spam-Status: No, score=-103.707 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 UXcKfdS6TLMC for ; Thu, 14 Nov 2013 02:22:13 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id B3E8D21E815A for ; Thu, 14 Nov 2013 02:22:12 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-af-5284a453ed57
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id DD.DF.27941.354A4825; Thu, 14 Nov 2013 11:22:11 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.2.328.9; Thu, 14 Nov 2013 11:22:11 +0100
Message-ID: <5284A4A2.3050107@ericsson.com>
Date: Thu, 14 Nov 2013 11:23:30 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Leon Geyser , "rtcweb@ietf.org" 
References: <5283DFDC.4010906@ericsson.com>		<52845E10.4040205@bbs.darktech.org> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3Vjd4SUuQwZ9l0hbdq2exWaz9187u wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGVc+vSNpeCbeMWdbVNZGhgXCXUxcnJICJhI XFjaywZhi0lcuLceyObiEBI4wijxZ/9kFghnOaPE0Y1/mECqeAW0Jeb1fGMFsVkEVCVO/TvF AmKzCVhI3PzRCDZJVCBY4vyrxewQ9YISJ2c+AasREfCQmHFtNVAvB4ewgKXEheMmEPNvMkr8 eHIDbCanQKDE/rfn2EBqJATEJXoag0DCzAJ6ElOutjBC2PISzVtnM4PYQkDnNDR1sE5gFJyF ZNssJC2zkLQsYGRexchRnFqclJtuZLCJERiUB7f8ttjBePmvzSFGaQ4WJXHej2+dg4QE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwzryR9P9m+7yXr/K3G11nbJUvvMsVu136j4rGB0stSYvm GT95rU1F/Pf4CJz8/PbR2+eyVbf4L041jb2wo2PucRPvCqVzRxI05FkXJnDmVq+73fLo7K2y qW+XelutrJDp9vK3Wmh26PDpukn/41XzixQb3q+emb7x58Ne8d9uJ2ImRpt8P5/7UYmlOCPR UIu5qDgRALvpKesYAgAA
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 10:22:18 -0000

Hi,

I have currently not added this SHOULD alternative to the list.

I think the important question is what alternatives in regard to what
will be required to implement, i.e. Mandatory to Implement.

After we have run this process regarding mandatory to implement we can
consider additional recommendations that the WG likes to make.

Cheers

Magnus

On 2013-11-14 08:23, Leon Geyser wrote:
>>>SHOULD doesn't carry any accountability. Anyone will tell you they
> have a "real good reason" to avoid implementing one >>codec or another.
> We've heard plenty of excuses on this list of why one party or another
> believes it is legally risky to >>implement VP8 or H.264, respectively.
> So in that sense, it is meaningless.
> 
> I agree. SHOULD is just like 'no MTI' and point 5 also implies 'no MTI'
> 
> 
> On 14 November 2013 07:22, cowwoc  > wrote:
> 
>     On 13/11/2013 11:11 PM, cb.list6 wrote:
> 
> 
>         Why no SHOULD implement vp8 and h248? SHOULD means you will do
>         it unless you have a real good reason.
> 
> 
>     SHOULD doesn't carry any accountability. Anyone will tell you they
>     have a "real good reason" to avoid implementing one codec or
>     another. We've heard plenty of excuses on this list of why one party
>     or another believes it is legally risky to implement VP8 or H.264,
>     respectively. So in that sense, it is meaningless.
> 
> 
>         MUST is too hard for this WG.  Many implementations have a
>         really good reason to not do vp8 OR h248.
> 
>         Saying that all webrtc MUST do one or the other or both is
>         disingenuous.
> 
>         SHOULD for both is as good as we are going to get with this
>         complicated IPR environment.  Using MUST is simply not going to
>         work and we have 10,000 on this mailer to back that up.
> 
> 
>     What you say is true, but if we accept this (and go with SHOULD) we
>     are essentially ending up with "no MTI" which leads to the dark side
>     (transcoding or dropped calls).
> 
>     Rock --> WebRTC <-- Hard place :)
> 
>     Gili
> 
>     _________________________________________________
>     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
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Thu Nov 14 02:24:03 2013
Return-Path: 
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 0A94721F99DC for ; Thu, 14 Nov 2013 02:24:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.514
X-Spam-Level: 
X-Spam-Status: No, score=-105.514 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 uf1vXKG+Gecm for ; Thu, 14 Nov 2013 02:23:57 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1B85621F9A0C for ; Thu, 14 Nov 2013 02:23:53 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-06-5284a4b1845e
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 4D.C8.15980.1B4A4825; Thu, 14 Nov 2013 11:23:45 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.328.9; Thu, 14 Nov 2013 11:23:43 +0100
Message-ID: <5284A4FD.1090505@ericsson.com>
Date: Thu, 14 Nov 2013 11:25:01 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Gustavo Garcia , Gonzalo Camarillo 
References: <5283DFDC.4010906@ericsson.com> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupiluLIzCtJLcpLzFFi42KZGfG3VnfLkpYggxNnBS0mT93JaLH2Xzu7 A5PHkiU/mTxu3L3JFMAUxWWTkpqTWZZapG+XwJVxelEPe8EnkYo7K0MaGHsFuhg5OCQETCSW X+TsYuQEMsUkLtxbzwZiCwkcYpToX2zUxcgFZC9nlDi6dw47SIJXQFti180uFhCbRUBV4tL8 V0wgNpuAhcTNH41gzaICwRLnXy2GqheUODnzCVi9iECkxJoVrxhBbGYBdYk7i8+xg9wgLGAp ceG4CYgpJFAgsWNKFYjJKRAo0d5tBXGkuERPYxBEn57ElKstUDPkJZq3zmaGOFhboqGpg3UC o9AsJGtnIWmZhaRlASPzKkb23MTMnPRy802MwPA8uOW3wQ7GTffFDjFKc7AoifN+eOscJCSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoEx/6T47KRJjdNvxdXLNs/d8H8XQ9jZxsWmNX/VRYpv zTyYF39QWby/tSGNobc40bPK1SKr0Sv8ov7dJVPfNOzINlPQXm51M7pjxcXA/1uz3Pj+mfQV 52Y89d/PGjlf3mbSl7WpU4Vn3PsZ8TTVbp5K6amUyomrfv31u8V4zJPvoLt4ivdy/slKLMUZ iYZazEXFiQBgRMSKHQIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 10:24:03 -0000

Gustavo,

I will remove this alternative from the list. I request all alternatives
to be focused on only what is Mandatory to Implement. We can discuss
recommendations or should levels after we have made a decision on the
mandatory level.

Cheers

Magnus

On 2013-11-14 06:35, Gustavo Garcia wrote:
> 8. All entities MUST support VP8 and H.264 is RECOMMENDED to implement
> 
> Ensure interoperability with a common codec and avoid transcoding when
> interconnecting with non-WebRTC platforms/devices as much as possible.
> 
> 
> On Wed, Nov 13, 2013 at 12:23 PM, Gonzalo Camarillo
> >
> wrote:
> 
>     Folks,
> 
>     I hope everybody had a safe trip back home after Vancouver.
> 
>     As you all know, we need to make progress regarding the selection of the
>     MTI video codec. The following are some of the alternatives we have on
>     the table:
> 
>      1. All entities MUST support H.264
>      2. All entities MUST support VP8
>      3. All entities MUST support both H.264 and VP8
>      4. Browsers MUST support both H.264 and VP8
>      5. All entities MUST support either H.264 or VP8
>      6. All entities MUST support H.261
>      7. There is no MTI video codec
> 
>     If you want the group to consider additional alternatives to the ones
>     above, please let the group know within the following *two weeks*. At
>     that point, the chairs will be listing all the received alternatives and
>     proposing a process to select one among them.
> 
>     Please, send your proposals in an email to the list. You do not need to
>     write a draft; just send the text you would like to see in the final
>     document regarding video codecs.
> 
>     Thanks,
> 
>     Gonzalo
>     Responsible AD for this WG
> 
>     _______________________________________________
>     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
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From maikmerten@googlemail.com  Thu Nov 14 02:51:24 2013
Return-Path: 
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 8E93E21E81B2 for ; Thu, 14 Nov 2013 02:51:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 bkhU5U-xcG81 for ; Thu, 14 Nov 2013 02:51:23 -0800 (PST)
Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 826E011E8131 for ; Thu, 14 Nov 2013 02:51:23 -0800 (PST)
Received: by mail-bk0-f46.google.com with SMTP id e11so945985bkh.19 for ; Thu, 14 Nov 2013 02:51:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=/UXydmyRkSiQxCmDTCxO4fgORKHu4RWP8EpKiww6/Do=; b=ADhPbdbsu2EgIaRs/4qPcj3oXmFZwHkBYgjIg5BoQVts6b9qoOpE7dYIDz8Z57+L5u kwKjkKsezRp1eLeEv1TV+ODRQZsUyVbuuuX+UcVga3sgvYpRlIlSSbVVL2B+iE8ACxCN L3vSFsxCAxJj6Q7AEI+rLT2WyUgv3RlHcVCbvxMJuABz4rpQUKWi+rUaC6Jceb8NsBFh A7eVOtSieNENzyl1QaRJEn4F9vM75sZBE8tjf2xpVGJ5GkpMX4s4FjHdss5dlkJAfrSO AK5dpVsWaVCYbvNuClbabvEVa2TA/6i8Af1Ta/DMwMIm98KxeNRM3AFNYsT9CcYIc0Lg FFvg==
X-Received: by 10.205.78.5 with SMTP id zk5mr1078779bkb.25.1384426282086; Thu, 14 Nov 2013 02:51:22 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id on10sm2358862bkb.13.2013.11.14.02.51.19 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 02:51:20 -0800 (PST)
Message-ID: <5284AB73.5030505@googlemail.com>
Date: Thu, 14 Nov 2013 11:52:35 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 10:51:24 -0000

Hello all,

in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html a 
sample of H.261 video was provided, connected to a (rhetorical?) 
question if this provided quality would be acceptable for users. Clearly 
that provided sample is of very low and unacceptable quality.

Just for comparison, here are two CIF samples at roughly 256k created by 
a somewhat modern encoder (ffmpeg with rate/distortion optimization):


https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg

https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg


(encoded as MPEG-1 video, as the "h261" encoder in ffmpeg crashes when 
using rate/distortion optimization. I understand MPEG-1 if used without 
b-frames is similar to H.261 in coding efficiency, but mostly adds more 
flexibility regarding frame sizes.

ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd -trellis 2 -cmp 
2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )

Even without formal testing it is obvious that H.261 and/or MPEG-1 video 
is clearly outperformed in terms of coding efficiency by H.264 and VP8. 
However, personally, speaking as an end-user, I would very much prefer 
this video quality over audio-only calls (in cases where transcoding is 
not available), as the video produced still carries useful information. 
Also H.261/MPEG-1 is blazingly fast, can be dealt with in software, and 
is not exceedingly difficult to implement.

Of course a MTI codec with higher coding performance is much preferable. 
However, if no such high-performance codec with licensing terms that are 
acceptable for all communities can be agreed on I think it may be wise 
to seriously evaluate the option of implementing an outdated codec for 
the sake of interoperability. In practice, most calls will negotiate to 
H.264 and VP8 anyways, but sporadic negotiation failures that are 
difficult to account for by the user are still to be expected if no MTI 
codec is defined at all.



Best regards,

Maik

From jeremy.fuller@genband.com  Thu Nov 14 03:38:04 2013
Return-Path: 
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 5201F21E81B2 for ; Thu, 14 Nov 2013 03:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 vIKfa2KQ-oG1 for ; Thu, 14 Nov 2013 03:37:58 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 57CBE21E8095 for ; Thu, 14 Nov 2013 03:37:58 -0800 (PST)
Received: from mail109-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE022.bigfish.com (10.243.66.85) with Microsoft SMTP Server id 14.1.225.22; Thu, 14 Nov 2013 11:37:57 +0000
Received: from mail109-co1 (localhost [127.0.0.1])	by mail109-co1-R.bigfish.com (Postfix) with ESMTP id A3A65D60501	for ; Thu, 14 Nov 2013 11:37:57 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:63.149.188.7; KIP:(null); UIP:(null); IPV:NLI; H:owa.genband.com; RD:63-149-188-7.dia.static.qwest.net; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhzz1f42h2148h208ch1ee6h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1b2fh1bceh224fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h1155h)
Received-SPF: pass (mail109-co1: domain of genband.com designates 63.149.188.7 as permitted sender) client-ip=63.149.188.7; envelope-from=jeremy.fuller@genband.com; helo=owa.genband.com ; .genband.com ; 
Received: from mail109-co1 (localhost.localdomain [127.0.0.1]) by mail109-co1 (MessageSwitch) id 1384429075816008_17848; Thu, 14 Nov 2013 11:37:55 +0000 (UTC)
Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.249])	by mail109-co1.bigfish.com (Postfix) with ESMTP id B9A7A30003F	for ; Thu, 14 Nov 2013 11:37:55 +0000 (UTC)
Received: from owa.genband.com (63.149.188.7) by CO1EHSMHS030.bigfish.com (10.243.66.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 14 Nov 2013 11:37:55 +0000
Received: from GBPLMAIL03.genband.com ([fe80::cc33:96c3:49a1:aa21]) by GBEX01.genband.com ([::1]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 05:37:54 -0600
From: Jeremy Fuller 
To: "rtcweb@ietf.org" 
Thread-Topic: Re: Video codec selection - way forward 
Thread-Index: Ac7hK8ukTfQjcL8nT66qZ+XigA9SjQ==
Date: Thu, 14 Nov 2013 11:37:54 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.21.173]
Content-Type: multipart/alternative; boundary="_000_D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1gbplmail03gen_"
MIME-Version: 1.0
X-OriginatorOrg: genband.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 11:38:04 -0000

--_000_D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1gbplmail03gen_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Gaining IETF consensus on making it mandatory to support only H.264 or only=
 VP8 has clearly failed. I would welcome anyone to share their thoughts on =
why they believe this situation will change anytime in the next few years. =
 Therefore, can I suggest that we remove items 1 and 2 from the list. Hopef=
ully this will speed up the process by focusing efforts towards gaining agr=
eement on one of the remaining options.


The following alternatives has been proposed:
1.      All entities MUST support H.264
2.      All entities MUST support VP8
3.      All entities MUST support both H.264 and VP8
4.      Browsers MUST support both H.264 and VP8, other entities MUST suppo=
rt at least one of H.264 and VP8
5.      All entities MUST support at least one of H.264 and VP8
6.      All entities MUST support H.261
7.      There is no MTI video codec
8.      All entities MUST support H.261 and all entities MUST support at le=
ast one of H.264 and VP8
Regards,
Jeremy Fuller


--_000_D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1gbplmail03gen_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi, 


 


Gaining IETF consensus on making it mandatory to support only H.264 or=
 only VP8 has clearly failed. I would welcome anyone to share their thought=
s on why they believe this situation will change anytime in the next few ye=
ars.  Therefore, can I suggest that
we remove items 1 and 2 from the list. Hopefully this will speed up the pro=
cess by focusing efforts towards gaining agreement on one of the remaining =
options. 


 


The following alternative=
s has been proposed:


    


  1. All entities MUST support H=
.264
  2. All entities MUST =
support VP8
  3. All entitie=
s MUST support both H.264 and VP8
  4. Browsers MUST support both H.264 and VP8, other entities MUST su=
pport at least one of H.264 and VP8
  5. All entities MUST support at least one of H.264 and VP8
    6. All entities MUST support H.2=
61
  6. There is no MTI vide=
o codec
  7. All entities MU=
ST support H.261 and all entities MUST support at least one of H.264 and VP=
8
    8. 



Regards,


Jeremy Fuller


 





--_000_D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1gbplmail03gen_--

From jdrosen@jdrosen.net  Thu Nov 14 07:57:32 2013
Return-Path: 
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 5515811E80F2 for ; Thu, 14 Nov 2013 07:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.916
X-Spam-Level: 
X-Spam-Status: No, score=-101.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 gyFSLofX5R4X for ; Thu, 14 Nov 2013 07:57:28 -0800 (PST)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id CBF4411E80E0 for ; Thu, 14 Nov 2013 07:57:27 -0800 (PST)
Received: from mail-pb0-f45.google.com ([209.85.160.45]:55856) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1VgzIG-0005TF-T9 for rtcweb@ietf.org; Thu, 14 Nov 2013 10:57:25 -0500
Received: by mail-pb0-f45.google.com with SMTP id mc8so2213626pbc.32 for ; Thu, 14 Nov 2013 07:57:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/rJvvWNGHKga/Av6yclJcPa7V9YmMZBYM+SNmn+1jF8=; b=hr1tdSpvAAJ8pYCLSQUVZpe7oB9v6splJbqOB8I/TY8YkQxRNXtrnBwe6N6CULN9zu apAmRty7g9wLEMDZvDWdmst8GhFUo43VTwTjUBqn2E77TzvGokIgxqngTrUiPios5JPz Vq7B1wDFPKYMOgCtqU8iMgjoUkph4Y/nG4/38MDMiBTn1vDVTElSmH7PhsPDIQFAWS1p Sl7vJt6qfyQV1mp3VfjSDlv5+w11x2fOSbhMKR2BvkwMm0D8Ns3SH1myOhuCHVOqoPos 6gZFoGbmEwN1OkFKIhs+98Dhwr1qAGvvSHpM1gGKjQQzcwnt/3wsqbKzGkvJz8trOnZj f8qw==
MIME-Version: 1.0
X-Received: by 10.68.40.169 with SMTP id y9mr1962750pbk.193.1384444640433; Thu, 14 Nov 2013 07:57:20 -0800 (PST)
Received: by 10.70.49.48 with HTTP; Thu, 14 Nov 2013 07:57:20 -0800 (PST)
In-Reply-To: 
References: 
Date: Thu, 14 Nov 2013 10:57:20 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: Jeremy Fuller 
Content-Type: multipart/alternative; boundary=bcaec51a754601287d04eb252319
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jdrosen.net
X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 15:57:32 -0000

--bcaec51a754601287d04eb252319
Content-Type: text/plain; charset=ISO-8859-1

I agree with others that SHOULD implement both, or other variations on
SHOULD, are not helpful. They will anyway be ignored and amount to more or
less the no-interop situation we're in if we continue on the current path
and have no consensus.  No consensus means the various players doing as
they prefer, which is what they'd do if there is a SHOULD.


On Thu, Nov 14, 2013 at 6:37 AM, Jeremy Fuller wrote:

>  Hi,
>
> Gaining IETF consensus on making it mandatory to support only H.264 or
> only VP8 has clearly failed. I would welcome anyone to share their thoughts
> on why they believe this situation will change anytime in the next few
> years.  Therefore, can I suggest that we remove items 1 and 2 from the
> list. Hopefully this will speed up the process by focusing efforts towards
> gaining agreement on one of the remaining options.
>
> The following alternatives has been proposed:
>
>     1. All entities MUST support H.264
>    2. All entities MUST support VP8
>    3. All entities MUST support both H.264 and VP8
>    4. Browsers MUST support both H.264 and VP8, other entities MUST
>    support at least one of H.264 and VP8
>    5. All entities MUST support at least one of H.264 and VP8
>    6. All entities MUST support H.261
>    7. There is no MTI video codec
>    8. All entities MUST support H.261 and all entities MUST support at
>    least one of H.264 and VP8
>
> Regards,
> Jeremy Fuller
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>


-- 
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net

--bcaec51a754601287d04eb252319
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I agree with others that SHOULD implement both, or other v=
ariations on SHOULD, are not helpful. They will anyway be ignored and amoun=
t to more or less the no-interop situation we're in if we continue on t=
he current path and have no consensus. =A0No consensus means the various pl=
ayers doing as they prefer, which is what they'd do if there is a SHOUL=
D.




On Thu, Nov 1=
4, 2013 at 6:37 AM, Jeremy Fuller <jeremy.fuller@genband.com&g=
t; wrote:













Hi, 


=A0


Gaining IETF consensus on making it mandatory to support only H.264 or=
 only VP8 has clearly failed. I would welcome anyone to share their thought=
s on why they believe this situation will change anytime in the next few ye=
ars.=A0 Therefore, can I suggest that
we remove items 1 and 2 from the list. Hopefully this will speed up the pro=
cess by focusing efforts towards gaining agreement on one of the remaining =
options. 


=A0


The following alternatives =
has been proposed:


    
=

    

  1. All entities MUST support H.=
264
  2. All entities MUST support VP8
  3. 
All entities MUST support both H.264 and VP8
  4. Browsers MUST support both H.264 and VP8, other =
entities MUST support at least one of H.264 and VP8
    5. <=
li style=3D"margin-top:5pt;margin-bottom:5pt">
All entities MUST support at least one of H.264 and VP8
  5. All entities MUST s=
upport H.261
  6. 
There is no MTI video codec
  7. All entities MUST support H.261 and all entitie=
s MUST support at least one of H.264 and VP8
    8. 



Regards,


Jeremy Fuller


=A0






_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





-- 





--bcaec51a754601287d04eb252319--

From wes@mti-systems.com  Thu Nov 14 09:19:59 2013
Return-Path: 
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 7D3D821E80D2 for ; Thu, 14 Nov 2013 09:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Level: 
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.757,  BAYES_00=-2.599]
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 9Tl+Wfm2YTMh for ; Thu, 14 Nov 2013 09:19:54 -0800 (PST)
Received: from atl4mhob16.myregisteredsite.com (atl4mhob16.myregisteredsite.com [209.17.115.54]) by ietfa.amsl.com (Postfix) with ESMTP id AD3A921E8056 for ; Thu, 14 Nov 2013 09:19:54 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob16.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id rAEHJr20026496 for ; Thu, 14 Nov 2013 12:19:53 -0500
Received: (qmail 6580 invoked by uid 0); 14 Nov 2013 17:19:53 -0000
X-TCPREMOTEIP: 107.45.110.113
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.110.113) by 0 with ESMTPA; 14 Nov 2013 17:19:52 -0000
Message-ID: <5285062F.9070204@mti-systems.com>
Date: Thu, 14 Nov 2013 12:19:43 -0500
From: Wesley Eddy 
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Gonzalo Camarillo , Harald Alvestrand 
References: <5283DF61.9060807@alvestrand.no> <52848582.1070408@ericsson.com>
In-Reply-To: <52848582.1070408@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" , rai-ads@tools.ietf.org, tsv-ads@tools.ietf.org
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 17:19:59 -0000

On 11/14/2013 3:10 AM, Gonzalo Camarillo wrote:
> Hi Harald,
> 
> thanks for your email. I will touch base with the TSV ADs and with Wes
> (former TSV AD) and get a status update on this piece of work. It will
> take a few days, though (when Martin will be back, as Spencer also
> mentioned in this thread). We will keep the group posted.
> 


I was mostly guilty for advocating that this be moved over, so
no need to bother Martin in order to explain the history.

It was creating some confusion between multiple WGs at the IETF
meeting, particularly with regard to what RMCAT was doing, what
RTCWEB was doing, and how DiffServ actually works.  So we had a
quick discussion about moving it to TSVWG between the available
set of:
- authors
- RTCWEB chairs
- TSVWG chairs
- RAI ADs
- TSV ADs

At the time that it was moved over to TSVWG, I had sent the
TSVWG a description of why:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg11631.html

I agree that this obviously should have also been discussed in
the RTCWEB WG.  If all interested people weren't aware of the
move, then that is bad, and should be corrected now.

As for the current status, the document does not yet address
core issues that have been pointed out.  See, for instance:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg12042.html

People interested should work on this in TSVWG.  There does not
seem to be any reason for RTCWEB to be gated on it, as it has zero
impact on interoperability or the protocol.  Having a normative
reference to it is not correct and is easy to fix.

-- 
Wes Eddy
MTI Systems


From rmohanr@cisco.com  Thu Nov 14 09:23:50 2013
Return-Path: 
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 7736921F9C55 for ; Thu, 14 Nov 2013 09:23:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8]
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 9rCFrajAA-G7 for ; Thu, 14 Nov 2013 09:23:44 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B3B6621F9A7D for ; Thu, 14 Nov 2013 09:23:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6656; q=dns/txt; s=iport; t=1384449823; x=1385659423; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=4if+Vm5opCkbp6k+EZMMzyp4JXMBE/stETYuWU7YWow=; b=jhVvn1DZ9CBXrV6pcGdql5zD/+73AOD/qD0d0EzKmj4U/YNNYT6yStBJ SxP05insP9C+AnDKRe1dwheDqrUVj8B9/3bcqTPRh41fnMXW1CqxpgJbd MXwga7lR95QPRQLabfT9XIoaExV995dVdxn76kEAXM+MstBE8iVd2130t w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAAwGhVKtJXG+/2dsb2JhbABagweBC78hgSAWdIIlAQEBBAx5AgQBCBEDAQIZDyIXFAkIAgQBEogBwEMEjhKBUAYShBkDiQqKYoQkkgyDKIFxOQ
X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="284863178"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 14 Nov 2013 17:23:43 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAEHNhq0019562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 17:23:43 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.193]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 11:23:42 -0600
From: "Ram Mohan R (rmohanr)" 
To: Magnus Westerlund , "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" 
Thread-Topic: Comments on draft-ietf-rtcweb-stun-consent-freshness-00
Thread-Index: AQHO4V5D8ro8smXte0emoSniQAx1Dw==
Date: Thu, 14 Nov 2013 17:23:42 +0000
Message-ID: 
In-Reply-To: <52824222.2000907@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.65.51.158]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 17:23:50 -0000

Hi Magnus,

Thanks for your comments. Please see inline for responses.


-----Original Message-----
From: Magnus Westerlund 
Date: Tuesday, 12 November 2013 8:28 PM
To: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org"
,
"rtcweb@ietf.org" 
Subject: Comments on draft-ietf-rtcweb-stun-consent-freshness-00
Resent-From: 
Resent-To: , , Cisco Employee
, 
Resent-Date: Tuesday, 12 November 2013 8:27 PM

>Hi,
>
>Here are my review comments on draft-ietf-rtcweb-stun-consent-freshness-00
>
>1. General:
>I understood one reason for splitting this out in its own document is
>that we might have other future users of this mechanism. Thus I think it
>should be written to be less WebRTC specific. It is appropriate to use
>WebRTC as motivation for requirements etc, but the actual description of
>the mechanism should be done in a neutral way.

Ok. We will add text in Abstract/Introduction to reflect this point.

>
>2. Section 1.
>   When a session is first established, WebRTC implementations are
>   required to perform STUN connectivity checks as part of ICE
>   [RFC5245].  That initial consent is not described further in this
>   document.
>
>When generalizing this, I think it is important to make clear that it is
>assumed that ICE is being used for that initial consent.


Yes. We will add text to make it clear.

>
>3. Section 1:
>"This document describes a new STUN usage with a request and response
>   which verifies the remote peer consents to receive traffic, and
>   detects loss of liveness."
>
>I am missing a word after "request and response", transaction or
>messages maybe?

NEW:
This document describes a new STUN usage with a request and response
messages which verifies the remote peer consents to receive traffic, and
detects loss of liveness.



>
>4. Section 3:
> A
>   response is necessary both for consent to continue sending traffic,
>   as well as to ensure connectivity.
>
>Is verify rather than "ensure" better?

Agree will replace with "verify"

>
>5. Section 4:
>   Consent freshness serves as a circuit breaker (so that if the path or
>   remote peer fails the WebRTC browser stops sending all traffic on
>   that remote peer), determining session liveness serves the purpose of
>   notifying the application of connectivity failure so that the
>   application can take appropriate action.
>
>traffic on/traffic to

Thanks. will fix this.


>
>What is the definition of a peer here?

Peer is the sink for the traffic originated from the sender for that flow
(5 tuple). If a browser uses different 5 tuple for each stream(Audio,
video, data) it sends then it should do consent for each flow. If it uses
same 5-tuple (mux case) then there will be only one consent.



>What scope does the stop sending
>have?

The stream that is being sent on a flow(5 tuple) for which a consent has
failed will be stopped. If all the streams are muxed on a same 5 tuple the
entire traffic will be stopped.

>
>6. Section 4:
>   1.  A consent timer, Tc, whose value is determined by the browser.
>       This value MUST be 15 seconds.
>
>I see a contradiction here, should it be determined by the browser or be
>15 s? If it is 15, can you please motivate why it is this value, or
>point to where it is motivated?

The default value of 15 was some thing that EKR and Justin gave us based
on the implementation/testing and fine tuning they have done on their
browsers. I agree we can have some text around it that explains how this
number is arrived. We will add the same.


>
>7. Section 4:
>   If a valid STUN Binding Response is received, the consent timer is
>   reset and fires again Tc seconds later.
>
>Is it reset to the time of receiving it or the time of sending the
>initial request this is the response for?

Consent timer is reset to the time of receiving it


>
>8. Section 4:
>   If a valid STUN Binding Response is not received after 500ms, the
>   STUN Binding Request is retransmitted (with the same Transaction ID
>   and all other fields).  As long as a valid STUN Binding Response is
>   not received, this retransmission is repeated every 500ms until Tf
>   seconds have elapsed or a valid response is received.
>
>So no exponential back-off on the retransmission timer. I think that is
>fine. However, I think it do require you to expand a bit on what happens
>when one gets multiple response on the same Transaction ID. For example
>additional responses do they or do they not reset the Tc timer?

Additional responses MUST reset the Tc timer.


>
>Then I wonder about the cases where the RTT is above 500 ms, should one
>then scale this factor to be once per RTT?
>
>9. Section 4:
>"with the same Transaction ID"
>
>Why not use a new transaction ID for each sent packet? It would allow
>tracking loss and determine RTT more reliable. All for the small cost of
>keeping track of slightly more Transaction IDs?

Yes, new transaction ID will help to determine the packet loss and RTT.



>
>10. Section 4.
>   Liveness timer: If no packets have been received on the local port in
>   Tr seconds, the WebRTC browser MUST inform the JavaScript that
>   connectivity has been lost.  The JavaScript application will use this
>   notification however it desires (e.g., cease transmitting to the
>   remote peer, provide a notification to the user, etc.).  Note the
>   definition of a received packet is liberal, and includes an SRTP
>   packet that fails authentication, a STUN Binding Request with an
>   invalid USERNAME or PASSWORD, or any other packet.
>
>I think this requires some considerations in regards to RTT. If the RTT
>is 700 ms, high for a real-time app but not unheard of at all. Then a Tr
>=3D 1 second would fire on a single loss.

Ok.  will start a discussion for this item in a separate email.


Regards,
Ram


>
>Cheers
>
>Magnus Westerlund
>
>----------------------------------------------------------------------
>Multimedia Technologies, Ericsson Research EAB/TVM
>----------------------------------------------------------------------
>Ericsson AB                | Phone  +46 10 7148287
>F=E4r=F6gatan 6                | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>----------------------------------------------------------------------
>


From ted.ietf@gmail.com  Thu Nov 14 10:38:26 2013
Return-Path: 
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 AEE9811E80F7 for ; Thu, 14 Nov 2013 10:38:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Level: 
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LvCtGdOylQpP for ; Thu, 14 Nov 2013 10:38:17 -0800 (PST)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8E411E8133 for ; Thu, 14 Nov 2013 10:38:12 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id fb10so3131204wid.0 for ; Thu, 14 Nov 2013 10:38:12 -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=v/1aO780h5LQhZLFspvBbR7Hbzz9kMv3vhBiXLzU0VA=; b=BB2H+JB0HbpAZlxOGNpSsB5j3dTYBjZwnYhkqSi7vmJ3ZlR2zxwtKKsar5yGaDqrMa y5UtSm8Pm0eYkaW6pqpjX6vjTcPIF2vDdwGaW6FGhenymEAyVfcDgwHJyDCBbihRsD9f 32npXjuGMLSpiHZqoGvHQOVQdJKVD0Y+Xip6SYr+IQ4B583xa7a6ZBe0L6EIiKlrHm2+ 3oty9raPe6hzHhOyRaBsDRCzFOJEqPsWvZBzjwhRRsRAIeKl5OcgkVXfbs2uTu8YGSwe M8vnr6GsIyM78o5Rmk/bYQUS8OAkhpNr8tmPCaqV2AFxUd4GQZxAsJmd9n4NjhflP98X +syg==
MIME-Version: 1.0
X-Received: by 10.194.240.129 with SMTP id wa1mr3292483wjc.31.1384454292253; Thu, 14 Nov 2013 10:38:12 -0800 (PST)
Received: by 10.227.205.131 with HTTP; Thu, 14 Nov 2013 10:38:12 -0800 (PST)
In-Reply-To: <5285062F.9070204@mti-systems.com>
References: <5283DF61.9060807@alvestrand.no> <52848582.1070408@ericsson.com> <5285062F.9070204@mti-systems.com>
Date: Thu, 14 Nov 2013 10:38:12 -0800
Message-ID: 
From: Ted Hardie 
To: Wesley Eddy 
Content-Type: multipart/alternative; boundary=089e013d1db24c34d204eb27623f
Cc: "rai-ads@tools.ietf.org" , "rtcweb@ietf.org" , tsv-ads@tools.ietf.org
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 18:38:26 -0000

--089e013d1db24c34d204eb27623f
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 14, 2013 at 9:19 AM, Wesley Eddy  wrote:

> On 11/14/2013 3:10 AM, Gonzalo Camarillo wrote:
> As for the current status, the document does not yet address
> core issues that have been pointed out.  See, for instance:
> http://www.ietf.org/mail-archive/web/tsvwg/current/msg12042.html
>
> People interested should work on this in TSVWG.  There does not
> seem to be any reason for RTCWEB to be gated on it, as it has zero
> impact on interoperability or the protocol.  Having a normative
> reference to it is not correct and is easy to fix.
>
> --
> Wes Eddy
> MTI Systems
>


Hi Wes,

The issue raised isn't that there is an RTCWEB document gated on it, but
that shipping code does require this to be resolved.  The message you point
to above notes a core issue, which I assume is this:

That said, I think the interesting facet of this document is that
packets within the same flow (defined by 5-tuple of address-port
pairs and protocol number) are receiving different codepoints, and
the implications of that for a CC that may be on top of them need
to be delved into.


I think the authors may not have seen "interesting facet"
as a clear enough signal that they were blocked on this.
Can you restate this problem to them, so that they understand either
where in the document they should raise the issue or where there is
work they can reference
for incorporation?

You may want to include pointers on why having this situation,

versus multiple flows going between the same end points in

other contexts, is a problem.  I'm kind of concerned as well
that they will take the simple solution (use the most stringent

QoS), which is clear enough from a congestion control perspective

but bad from other perspectives.

regards,


Ted

--089e013d1db24c34d204eb27623f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Nov 14, 2013 at 9:19 AM, Wesley Eddy <wes@mti-s=
ystems.com> wrote:



On 11/14/2013 3:10 A=
M, Gonzalo Camarillo wrote:

As for the current status, the document does not yet address

core issues that have been pointed out. =A0See, for instance:

http://www.ietf.org/mail-archive/web/tsvwg/current/msg1=
2042.html



People interested should work on this in TSVWG. =A0There does not

seem to be any reason for RTCWEB to be gated on it, as it has zero

impact on interoperability or the protocol. =A0Having a normative

reference to it is not correct and is easy to fix.



--

Wes Eddy

MTI Systems


Hi Wes,
The issue raised isn't that there is an RTCWEB document gated on =
it, but that shipping code does require this to be resolved.=A0 The message=
 you point to above notes a core issue, which I assume is this:



That said, I think the interesting facet of this document is that
packets within the same flow (defined by 5-tuple of address-port
pairs and protocol number) are receiving different codepoints, and
the implications of that for a CC that may be on top of them need
to be delved into. 


I think the authors may not have =
seen "interesting facet" 
as a clear enough signal that they w=
ere blocked on this.  
Can you restate this problem to them, so that the=
y understand either
where in the document they should raise the issue or where there is work th=
ey can reference
for incorporation?

You may want to in=
clude pointers on why having this situation,
versus multiple =
flows going between the same end points in


other contexts, is a problem.  I'm kind of concerned as well=

that they will take the simple solution (use the most stringent
QoS), which is clear enough from a congestion control perspective

but bad from other perspectives.

regards,


Ted<=
br>


--089e013d1db24c34d204eb27623f--

From maikmerten@googlemail.com  Thu Nov 14 11:12:41 2013
Return-Path: 
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 CA8A711E8133 for ; Thu, 14 Nov 2013 11:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 7wEwF9NBbe66 for ; Thu, 14 Nov 2013 11:12:41 -0800 (PST)
Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C9B9111E80FA for ; Thu, 14 Nov 2013 11:12:40 -0800 (PST)
Received: by mail-bk0-f41.google.com with SMTP id v15so1289724bkz.0 for ; Thu, 14 Nov 2013 11:12:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ammfCUowo5U2AYLwGrVKjDzpYtdb1foJ/adPpMyMwrU=; b=B93W50Z74ClJBKeHS/NTLVTYAB6N63qh+PDpsdqs+/jxKs6sNc+WNDcyed5B7JGj/A QSRM+YvbURkuCnCSf0DVRasxYEYNdu9oAiTTIlI73rQxhiigzgfnNqFadR5ah2sWgSuL Tl1dp4lB5xCHHy+ttWIIoSGprow3S3ELySv14h8ijBl5PuaIoVJrww3+UjjsI5QTtQ9P hXB2v4QsFYx6QpVLAtW/38aw8EPasFHE50GZQ9HaWQbua2kWP+Erdh0oJi5Lh9VGAAVP 9ke1kefChPF6GdOVF1xxWpurYRgnoeyAlftCRZ/irQOjqPWi8R7ZG5Htk2vtZtLuENuo SodA==
X-Received: by 10.205.35.204 with SMTP id sx12mr600713bkb.49.1384456354392; Thu, 14 Nov 2013 11:12:34 -0800 (PST)
Received: from [192.168.2.101] (dslb-088-078-139-230.pools.arcor-ip.net. [88.78.139.230]) by mx.google.com with ESMTPSA id pk7sm4451819bkb.2.2013.11.14.11.12.32 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 11:12:33 -0800 (PST)
Message-ID: <5285209D.7020407@googlemail.com>
Date: Thu, 14 Nov 2013 20:12:29 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com>
In-Reply-To: <5284AB73.5030505@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 19:12:41 -0000

Hello again,

to allow for having a quick look at some test sequences I put together a 
very very sloppy overview page at

https://dl.dropboxusercontent.com/u/14053306/mpeg1/index.html


This includes a completely JavaScript-based MPEG-1 player for those that 
don't happen to have a fitting decoder installed (also, yay, JavaScript 
is fast enough now for simple video decoders!). I recreated the encoded 
files to ensure there are no b-frames and documented the encoder 
settings accordingly.

Best regards,

Maik


Am 14.11.2013 11:52, schrieb Maik Merten:
> Hello all,
>
> in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html a
> sample of H.261 video was provided, connected to a (rhetorical?)
> question if this provided quality would be acceptable for users. Clearly
> that provided sample is of very low and unacceptable quality.
>
> Just for comparison, here are two CIF samples at roughly 256k created by
> a somewhat modern encoder (ffmpeg with rate/distortion optimization):
>
>
> https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg
>
> https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg
>
>
> (encoded as MPEG-1 video, as the "h261" encoder in ffmpeg crashes when
> using rate/distortion optimization. I understand MPEG-1 if used without
> b-frames is similar to H.261 in coding efficiency, but mostly adds more
> flexibility regarding frame sizes.
>
> ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd -trellis 2 -cmp
> 2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )
>
> Even without formal testing it is obvious that H.261 and/or MPEG-1 video
> is clearly outperformed in terms of coding efficiency by H.264 and VP8.
> However, personally, speaking as an end-user, I would very much prefer
> this video quality over audio-only calls (in cases where transcoding is
> not available), as the video produced still carries useful information.
> Also H.261/MPEG-1 is blazingly fast, can be dealt with in software, and
> is not exceedingly difficult to implement.
>
> Of course a MTI codec with higher coding performance is much preferable.
> However, if no such high-performance codec with licensing terms that are
> acceptable for all communities can be agreed on I think it may be wise
> to seriously evaluate the option of implementing an outdated codec for
> the sake of interoperability. In practice, most calls will negotiate to
> H.264 and VP8 anyways, but sporadic negotiation failures that are
> difficult to account for by the user are still to be expected if no MTI
> codec is defined at all.
>
>
>
> Best regards,
>
> Maik


From gonzalo.camarillo@ericsson.com  Thu Nov 14 11:28:00 2013
Return-Path: 
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 D08F521E80BE for ; Thu, 14 Nov 2013 11:28:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.803
X-Spam-Level: 
X-Spam-Status: No, score=-103.803 tagged_above=-999 required=5 tests=[AWL=-1.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Hl3wm09L17Hf for ; Thu, 14 Nov 2013 11:27:55 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6197E21E8098 for ; Thu, 14 Nov 2013 11:27:41 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-74-5285242b7f7e
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.42.27941.B2425825; Thu, 14 Nov 2013 20:27:40 +0100 (CET)
Received: from [131.160.126.80] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Thu, 14 Nov 2013 20:27:39 +0100
Message-ID: <5285242A.4050103@ericsson.com>
Date: Thu, 14 Nov 2013 21:27:38 +0200
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ted Hardie 
References: <5283DF61.9060807@alvestrand.no> <52848582.1070408@ericsson.com> <5285062F.9070204@mti-systems.com> 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvra6OSmuQQftGJotjfV1sFnu3z2O0 WPuvnd3iwepzrBaNc+0sps37yGhx/Tu7A7vHlQlXWD2m/N7I6rFz1l12jyVLfjJ5nDzVy+bx 5fJntgC2KC6blNSczLLUIn27BK6MpzOnsxbsE6y4/3MTWwPjEt4uRk4OCQETiaMNV1khbDGJ C/fWs3UxcnEICRxhlHj7fDY7hLOGUeLTzSZGkCpeAW2JA93HWEBsFgFViablu9hAbDYBC4kt t+6DxUUFoiQ2bL/AAlEvKHFy5hMwW0RAWWLvlR1gG5gFfjJK3HzziBkkISxgJfHg1kmo1VsY JfbuewfWwSkQKPHrdhs7xH2SEltetIPZzAJ6ElOutjBC2PIS29/OARskBHTd8mctLBMYhWYh WT4LScssJC0LGJlXMXIUpxYn5aYbGWxiBEbCwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2MCXG8xvtzFlYcn2IxtWLChAuvfVVKfJIkYuvU/5qnvevd wrMrTu2DwOnt0UaOe454JIfdLWAyvlI4X1WR6VXBzggZnxOa02KVpaWFf+gt7dzBylvfGdEc kGaSlhcb8u1pkdrvb0tWvvO27fv82oRHRupfoPT1jL8VZzd93//0I//FJ/fEn75VYinOSDTU Yi4qTgQAE/ur1VICAAA=
Cc: "rai-ads@tools.ietf.org" , tsv-ads@tools.ietf.org, "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 19:28:00 -0000

Hi,

[adding Subha, the main author of the draft, to the cc:]

Subha intends to revise the draft before the end of this month. She will
try and address the comments below from Wes.

Cheers,

Gonzalo

On 14/11/2013 8:38 PM, Ted Hardie wrote:
> On Thu, Nov 14, 2013 at 9:19 AM, Wesley Eddy  > wrote:
> 
>     On 11/14/2013 3:10 AM, Gonzalo Camarillo wrote:
>     As for the current status, the document does not yet address
>     core issues that have been pointed out.  See, for instance:
>     http://www.ietf.org/mail-archive/web/tsvwg/current/msg12042.html
> 
>     People interested should work on this in TSVWG.  There does not
>     seem to be any reason for RTCWEB to be gated on it, as it has zero
>     impact on interoperability or the protocol.  Having a normative
>     reference to it is not correct and is easy to fix.
> 
>     --
>     Wes Eddy
>     MTI Systems
> 
> 
> 
> Hi Wes,
> 
> The issue raised isn't that there is an RTCWEB document gated on it, but
> that shipping code does require this to be resolved.  The message you
> point to above notes a core issue, which I assume is this:
> 
> That said, I think the interesting facet of this document is that
> packets within the same flow (defined by 5-tuple of address-port
> pairs and protocol number) are receiving different codepoints, and
> the implications of that for a CC that may be on top of them need
> to be delved into. 
> 
> 
> I think the authors may not have seen "interesting facet" 
> as a clear enough signal that they were blocked on this.  
> Can you restate this problem to them, so that they understand either
> where in the document they should raise the issue or where there is work they can reference
> for incorporation?
> 
> You may want to include pointers on why having this situation,
> 
> versus multiple flows going between the same end points in
> 
> other contexts, is a problem.  I'm kind of concerned as well
> that they will take the simple solution (use the most stringent
> 
> QoS), which is clear enough from a congestion control perspective
> 
> but bad from other perspectives.
> 
> regards,
> 
> 
> Ted
> 


From jmpolk@cisco.com  Thu Nov 14 11:31:24 2013
Return-Path: 
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 7177B21E80C3 for ; Thu, 14 Nov 2013 11:31:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.563
X-Spam-Level: 
X-Spam-Status: No, score=-110.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 ZTf67XUOOXlZ for ; Thu, 14 Nov 2013 11:31:13 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 229C321E8105 for ; Thu, 14 Nov 2013 11:31:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9062; q=dns/txt; s=iport; t=1384457472; x=1385667072; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=CiMfjoc3bJXH9aTbMnxN4SxURj8SgP7gnHr6OaxPG0o=; b=ltE5AgpNOZMXV35Datp3dfnhxKsQWE14ItdwluC7ui2co3k2WNP0Q1pT dYWKf/owldW4V5Z3hILRwhimrhJLWg4Yfdz61JoQ8CqHSR+i/G53eKP44 5LMwX0gkRLe69/0G8GXIqkOo8sAuS9uESUr1OeRcEg4L9sbR8Y+CA+ReM Q=;
X-IronPort-AV: E=Sophos;i="4.93,701,1378857600"; d="scan'208";a="284934264"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 14 Nov 2013 19:31:11 +0000
Received: from jmpolk-WS.cisco.com ([10.89.12.165]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAEJVBn2004230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Nov 2013 19:31:11 GMT
Message-Id: <201311141931.rAEJVBn2004230@rcdn-core-3.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 14 Nov 2013 13:31:11 -0600
To: Harald Alvestrand , James Polk 
From: James Polk 
In-Reply-To: <52843288.5000507@alvestrand.no>
References: <5283DF61.9060807@alvestrand.no> <201311132211.rADMBaBD011692@rcdn-core2-5.cisco.com> <52843288.5000507@alvestrand.no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Authenticated-User: jmpolk
Cc: Gorry Fairhurst , rai-ads@tools.ietf.org, "Black, David" , "rtcweb@ietf.org" , tsv-ads@tools.ietf.org
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 19:31:24 -0000

At 08:16 PM 11/13/2013, Harald Alvestrand wrote:
>On 11/13/2013 11:11 PM, James Polk wrote:
> > I, speaking at the mic, was merely pointing out that this draft had
> > moved to TSVWG back in the Atlanta timeframe (though, thinking back, I
> > think I left the timing piece out of my comment), so it wasn't a
> > recent decision. I believe this came directly from talks between the
> > above mentioned ADs.
>
>This only reinforces my procedural comment. The fact that the decision,
>and the reasons for it, has been hidden from the group for 8 (?) months
>only makes it worse, not better.

it was mentioned during the chair's review of RTCweb documents during 
the Orlando RTCweb meeting. I was there in the front row...


>When ADs make decisions by talking among themselves, they have a special
>duty to make sure those decisions are public and open to the community.
>That duty has not been executed in this case.
>I don't know who dropped the ball - the ADs or the chairs. But the ball
>was definitely dropped.

I think this was announced on the list, but was part of a larger 
email, and not the main topic (i.e., "subject" line)... making 
searching for it difficult at best.


> >
> > As for RTCweb work being more appropriately inside the RTBweb WG
> > instead of another group, I'd like to point out that much of the SDP
> > work related to this WG is in fact being done in MMUSIC. Much of the
> > RTP work being done by this WG is being done in AVTCORE (or AVTEXT?).
> > All of the base SCTP work being done by this WG is being done in TSVWG.
>
>I have issues with those too. Especially the speed at which they're
>progressing. But those decisions were made and announced in a timely
>fashion.

I figured this was part of the problem, and have nothing good to add here.


>The argument that has been used is that the pieces we need defined
>(BUNDLE, MSID, circuit-breakers, RMCAT) have general applicability, and
>should therefore be processed by groups that are chartered to define
>extensions with general applicability.

it was RMCAT (also in Transport) that was the main interaction from 
my pov, and I think from the TSVWG chairs pov, as RMCAT's chairs said 
to TSVWG (paraphrasing) "we don't think we're going to need anything 
new or existing work wrt DiffServ to solve RMCAT's solution". This 
effective told the TSVWG chairs they could table/postpone/whatever 
the DiffServ draft from RTCweb until RMCAT was through deciding which 
solution they were going to go with. I think, perhaps, the TSVWG 
chairs (me included) thought there was more of a direct link between 
RMCAT and RTCweb than there really was. If there was, and we were 
talking past each other, then  apologize, as I clearly didn't get that memo.


> >
> > (this is not an attack, but...)
> >
> > ...why are you arguing for something as far away down the stack as
> > DSCP assignments to be done in RTCweb, and not where all other
> > DiffServ work is being done in the IETF (in TSVWG)? Do you not trust
> > that TSVWG will do an appropriate just with a DiffServ ID but you will
> > trust TSVWG with SCTP IDs?
>
>My understanding of the QoS draft has always been that it should define
>no new codepoints.

It shouldn't and doesn't, it's merely a profile doc for RTCweb (said 
as an author and as a TSVWG chair).

>It should point out the language we need to translate
>RTCWEB requirements ("audio should go faster than video, except when the
>app says that it should be the other way around") into already-defined
>DSCP code points.

that's my understanding (of the requirements) too


>I have not seen anyone arguing for new DSCP codepoints

nor should they have

>, so I really
>wonder what work there is for TSVWG to do.

to make sure that no one specifies anything stupid in the profile.

What RTCweb doesn't know, except for Magnus and Colin, is that TSVWG 
is in the process of bis-ing our DiffServ guidelines RFC (4594). 
We've reached WG consensus on most of the proposed changes, by the 
author/editor has a couple of changes he hasn't reach WG consensus with/on.


>Again, the arguments may be there, but since they were never exposed to
>the mailing list, I cannot evaluate them.

"never" is, I think, not true.

I'll give you 'announced along with 50m other things in RTCweb 
(buried in the background noise) ...


> >
> > Color me confused...
> >
> > James
> >
> > BTW - Full disclosure, I'm an listed author of this draft, but had no
> > voice in it getting moved between the WGs.
>
>My biggest practical issue with this draft is that it's functionally
>dead.

see above for the confusion

>I'm getting put in a place where I have to either delay shipping
>this feature in product or ship without even the guidance of a live draft.

I can certainly appreciate that


>I want this group to be done. As long as I can't even point to the
>document that describes how we do QoS, I have no chance of getting it to
>that stage.

again, I can certainly appreciate that

James



> >
> > At 02:21 PM 11/13/2013, Harald Alvestrand wrote:
> >> This mail concerns both administrative and technical issues, which is
> >> why it is explicitly copied to the ADs of RAI and TSV. I hope I have
> >> managed to keep them separate in the message.
> >>
> >> Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:
> >>
> >> > Okay, we might not have been public enough on this. It was
> >> requested by
> >> > the Transport ADs quite some time ago that doing the QoS document
> >> in our
> >> > WG was not appropriate and requested us to direct the document to
> >> TSVWG.
> >> > Which was done, and where it hasn't made progress.
> >> >
> >> > You might have noted that James Polk did comment in the milestone part
> >> > in the monday session of IETF88 about our QoS milestone should be
> >> killed.
> >> I want to protest this - both practically and formally.
> >>
> >> To get the formal stuff out of the way first:
> >>
> >> Changing the deliverables of the working group *without telling the
> >> working group* is totally inappropriate in an open, consensus-driven
> >> process.
> >> Changing the deliverables of the working group *without telling the
> >> working group why* and *without allowing those reasons to be debated* is
> >> totally inappropriate in an open, consensus-driven process.
> >>
> >> I protest against this action.
> >>
> >> ACTION REQUEST 1: I request that this decision be declared null and
> >> void, and that the relevant ADs send out a message to RTCWEB (and TSVWG
> >> if appropriate) *PROPOSING* such an action, and giving a reasonable
> >> timeline for when they will make a decision based on mailing list
> >> feedback.
> >>
> >> In practice:
> >>
> >> The draft as it existed before its untimely demise consisted of two
> >> things:
> >>
> >> - A description of how QoS mechanisms could be useful in the RTCWEB
> >> use case
> >> - A description of existing mechanisms that could be appropriate for the
> >> RTCWEB use case
> >>
> >> The first one is clearly something that needs RTCWEB consensus. It seems
> >> to have no need for, nor likelyhood of gathering interest enough for, a
> >> TSVWG consensus.
> >>
> >> There could be some argument that the second part needs TSVWG consensus,
> >> especially if it was redefining any mechanisms, or it was making choices
> >> between mechanisms where TSVWG had strong opinions about which
> >> mechanisms should be chosen, but had not chosen to document that in any
> >> document on which IETF consensus had been declared (that is to say,
> >> existing RFCs).
> >>
> >> My archive shows 36 messages where the title refers to this draft. It
> >> shows no messages declaring that feedback has been incorporated and
> >> calling for new review - something that is usually necessary to get a WG
> >> consensus on any document. The debate hasn't been conclusive, but then,
> >> it hasn't been pushed hard either.
> >>
> >> The people who know how RTCWEB works are in this working group. Some of
> >> them may be in TSV, but I think the locus of knowledge for saying what
> >> QoS mechanisms are appropriate for RTCWEB are here, not in TSV.
> >>
> >> This results in my second request.
> >>
> >> ACTION REQUEST 2: I request that the chairs declare that based on the
> >> debate about the QoS functionality so far, the document should be
> >> resurrected, and will continue to be  worked on in the RTCWEB working
> >> group, bringing in advice from TSVWG as required to make sure the
> >> descriptions of underlying mechanisms, and the choice of such
> >> mechanisms, is correct and appropriate.
> >>
> >>
> >>
> >>
> >> --
> >> Surveillance is pervasive. Go Dark.
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >
>
>
>--
>Surveillance is pervasive. Go Dark.


From lgeyser@gmail.com  Thu Nov 14 11:35:47 2013
Return-Path: 
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 B94D711E8127 for ; Thu, 14 Nov 2013 11:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.249
X-Spam-Level: 
X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 gRz7rj3yz9zq for ; Thu, 14 Nov 2013 11:35:41 -0800 (PST)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFBC21E8137 for ; Thu, 14 Nov 2013 11:35:39 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id el20so1957130lab.23 for ; Thu, 14 Nov 2013 11:35:32 -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=/OfyS0GH93lUQ3PvWAno8VkiprZAn5iqnWMvmGsNwA4=; b=CIUAnJLMnyYRyI/d+02ANzCOdOetUL6xV6hE+5JpYmTzAR2rAnr78NeFQfewNiKwV4 bBdBTLhA3wynbTcYaOpT9P4g6aosAIrOW9BgRk4QoEYzZVpslJSWPgSaBXb2/dJYsUzU bl7GdfkMwG1Josn+q/VIbph6yj/xt1xXtEi94Wh6quLgcfTa2JqAVKueM8cDi1mWkwys +5ot7/KxiPHpc9q2FMDAmB3ldZ6MlLj2GupZVeNDJO9qGaEEgKOTckyg7z33Ulp5OGwu GT/KUzPxG4xEC1lfJkH2Jv/8/es0+OYuqgnsq95VlzIUcpWJ0nJk//MafxqSkA5ZrGx/ gU4Q==
MIME-Version: 1.0
X-Received: by 10.152.1.70 with SMTP id 6mr668917lak.60.1384457732538; Thu, 14 Nov 2013 11:35:32 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 14 Nov 2013 11:35:32 -0800 (PST)
In-Reply-To: <5285209D.7020407@googlemail.com>
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>
Date: Thu, 14 Nov 2013 21:35:32 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e013c670e5ac94104eb282f01
Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 19:35:47 -0000

--089e013c670e5ac94104eb282f01
Content-Type: text/plain; charset=ISO-8859-1

>>This includes a completely JavaScript-based MPEG-1 player for those that
don't happen to have a fitting decoder installed >>(also, yay, JavaScript
is fast enough now for simple video decoders!). I recreated the encoded
files to ensure there are no >>b-frames and documented the encoder settings
accordingly.
Thanks for sharing. Looks better than what I expected.

On 14 November 2013 21:12, Maik Merten  wrote:

> Hello again,
>
> to allow for having a quick look at some test sequences I put together a
> very very sloppy overview page at
>
> https://dl.dropboxusercontent.com/u/14053306/mpeg1/index.html
>
>
> This includes a completely JavaScript-based MPEG-1 player for those that
> don't happen to have a fitting decoder installed (also, yay, JavaScript is
> fast enough now for simple video decoders!). I recreated the encoded files
> to ensure there are no b-frames and documented the encoder settings
> accordingly.
>
> Best regards,
>
> Maik
>
>
> Am 14.11.2013 11:52, schrieb Maik Merten:
>
>  Hello all,
>>
>> in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html a
>> sample of H.261 video was provided, connected to a (rhetorical?)
>> question if this provided quality would be acceptable for users. Clearly
>> that provided sample is of very low and unacceptable quality.
>>
>> Just for comparison, here are two CIF samples at roughly 256k created by
>> a somewhat modern encoder (ffmpeg with rate/distortion optimization):
>>
>>
>> https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg
>>
>> https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg
>>
>>
>> (encoded as MPEG-1 video, as the "h261" encoder in ffmpeg crashes when
>> using rate/distortion optimization. I understand MPEG-1 if used without
>> b-frames is similar to H.261 in coding efficiency, but mostly adds more
>> flexibility regarding frame sizes.
>>
>> ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd -trellis 2 -cmp
>> 2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )
>>
>> Even without formal testing it is obvious that H.261 and/or MPEG-1 video
>> is clearly outperformed in terms of coding efficiency by H.264 and VP8.
>> However, personally, speaking as an end-user, I would very much prefer
>> this video quality over audio-only calls (in cases where transcoding is
>> not available), as the video produced still carries useful information.
>> Also H.261/MPEG-1 is blazingly fast, can be dealt with in software, and
>> is not exceedingly difficult to implement.
>>
>> Of course a MTI codec with higher coding performance is much preferable.
>> However, if no such high-performance codec with licensing terms that are
>> acceptable for all communities can be agreed on I think it may be wise
>> to seriously evaluate the option of implementing an outdated codec for
>> the sake of interoperability. In practice, most calls will negotiate to
>> H.264 and VP8 anyways, but sporadic negotiation failures that are
>> difficult to account for by the user are still to be expected if no MTI
>> codec is defined at all.
>>
>>
>>
>> Best regards,
>>
>> Maik
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--089e013c670e5ac94104eb282f01
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


>>This includes a completely JavaScript-based M=
PEG-1 player for those that
 don't happen to have a fitting decoder installed >>(also, yay, J=
avaScript
 is fast enough now for simple video decoders!). I recreated the encoded
 files to ensure there are no >>b-frames and documented the encoder=
=20
settings accordingly.
Thanks for sharing. Looks better than what I=
 expected.

On 14 November 2013 21:12, Maik Merten <maikmerten@googlema=
il.com> wrote:


Hello again,



to allow for having a quick look at some test sequences I put together a ve=
ry very sloppy overview page at



https://dl.dropboxusercontent.com/u/14053306/mpeg1/=
index.html





This includes a completely JavaScript-based MPEG-1 player for those that do=
n't happen to have a fitting decoder installed (also, yay, JavaScript i=
s fast enough now for simple video decoders!). I recreated the encoded file=
s to ensure there are no b-frames and documented the encoder settings accor=
dingly.




Best regards,



Maik





Am 14.11.2013 11:52, schrieb Maik Merten:
=




Hello all,



in http://www.ietf.org/mail-archive/web/rtcweb/=
current/msg09721.html a

sample of H.261 video was provided, connected to a (rhetorical?)

question if this provided quality would be acceptable for users. Clearly
that provided sample is of very low and unacceptable quality.



Just for comparison, here are two CIF samples at roughly 256k created by
a somewhat modern encoder (ffmpeg with rate/distortion optimization):





https://dl.dropboxusercontent.com/u/14053306/mp=
eg1/irene-256k.mpg



https://dl.dropboxusercontent.com/u/14053306/m=
peg1/mad900-256k.mpg





(encoded as MPEG-1 video, as the "h261" encoder in ffmpeg crashes=
 when

using rate/distortion optimization. I understand MPEG-1 if used without

b-frames is similar to H.261 in coding efficiency, but mostly adds more

flexibility regarding frame sizes.



ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd -trellis 2 -cmp

2 -subcmp 2 -g 100 =A0-vb 256k irene-256k.mpg )



Even without formal testing it is obvious that H.261 and/or MPEG-1 video
is clearly outperformed in terms of coding efficiency by H.264 and VP8.

However, personally, speaking as an end-user, I would very much prefer

this video quality over audio-only calls (in cases where transcoding is

not available), as the video produced still carries useful information.

Also H.261/MPEG-1 is blazingly fast, can be dealt with in software, and

is not exceedingly difficult to implement.



Of course a MTI codec with higher coding performance is much preferable.
However, if no such high-performance codec with licensing terms that are
acceptable for all communities can be agreed on I think it may be wise

to seriously evaluate the option of implementing an outdated codec for

the sake of interoperability. In practice, most calls will negotiate to

H.264 and VP8 anyways, but sporadic negotiation failures that are

difficult to account for by the user are still to be expected if no MTI

codec is defined at all.







Best regards,



Maik





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb





--089e013c670e5ac94104eb282f01--

From jdrosen@jdrosen.net  Thu Nov 14 11:42:08 2013
Return-Path: 
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 759A221F9A5F for ; Thu, 14 Nov 2013 11:42:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.926
X-Spam-Level: 
X-Spam-Status: No, score=-101.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 SFXXbnhEzBVa for ; Thu, 14 Nov 2013 11:42:04 -0800 (PST)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id EE77E11E80FA for ; Thu, 14 Nov 2013 11:42:03 -0800 (PST)
Received: from mail-pd0-f171.google.com ([209.85.192.171]:56945) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1Vh2nZ-0000Iq-1J for rtcweb@ietf.org; Thu, 14 Nov 2013 14:42:03 -0500
Received: by mail-pd0-f171.google.com with SMTP id z10so872624pdj.2 for ; Thu, 14 Nov 2013 11:41:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vk8z8TEfHqf4zCgyxbHbSwcTCjCDaiSMOOY3n9VyQ58=; b=lEj6XxH/B5sXbpwElV3GyNFde5365pvZHDqtrySg826ITLFgtyu43WHG0cOG+YUIFD uKIAHNoUf04lIDitjCNdYNYvZ/y+s29Trfkeh/IeRIQqv8eYL/DidOrJtUUgf3YWmoj/ YOlnwnorqo81rLc3sNfrl53tQQiGarJZaj2UjCYgriInWna7GS67V0hklfgVO6zdnbep LtIDTWkECiXEBI0WBgP1B2S9fyEZhBBZHEOuK38YBSDhC3OYIq3ETC+5AXiPqebnZ8uN O3y1i8z6+jLEO/jx9C3NNBJfXsrpg1+WdNPY8V5LiS9/vNwEzrcbcg+YsFD3ZdZIothI Sfbg==
MIME-Version: 1.0
X-Received: by 10.66.142.193 with SMTP id ry1mr3120264pab.150.1384458112514; Thu, 14 Nov 2013 11:41:52 -0800 (PST)
Received: by 10.70.49.48 with HTTP; Thu, 14 Nov 2013 11:41:52 -0800 (PST)
In-Reply-To: 
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283E700.5090300@bbs.darktech.org>  <5283FDF1.8030708@bbs.darktech.org>  <52845DB0.6040501@bbs.darktech.org> <5284626C.8050504@goodadvice.pages.de> <528471AA.4060101@bbs.darktech.org> <52847646.9050203@goodadvice.pages.de> 
Date: Thu, 14 Nov 2013 14:41:52 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: Silvia Pfeiffer 
Content-Type: multipart/alternative; boundary=001a113450c200c1e804eb284652
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jdrosen.net
X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 19:42:08 -0000

--001a113450c200c1e804eb284652
Content-Type: text/plain; charset=ISO-8859-1

An important drawback of H.261 as MTI is interop with existing installed
base. Very old conferencing systems and products may still have it since
its easier to keep the code than delete it, but new platforms in the last
few years will not have H.261.

I also disagree with the assertion that H.261 video is better than audio
only. Video quality matters and I believe the higher quality we've been
able to achieve in recent years due to the combo of better tech (ala H.264)
along with faster networks is a material factor in the acceptance of video
by end users. I think folks writing the apps should decide whether lousy
video is good enough, and for business usage the answer is no.

Finally, don't overestimate the typical upstream bandwidth that is
available to users across the Internet. Many of us here on this list
probably have nice speedy high speed connections (I have fiber with 85/35
service) and that is not the norm for the rest of the world.



On Thu, Nov 14, 2013 at 5:08 AM, Silvia Pfeiffer
wrote:

> On Thu, Nov 14, 2013 at 3:05 PM, Philipp Hancke
>  wrote:
> >> Okay, so I stand corrected (thank you for pointing this out).
> >
> >
> > heh, I'm always surprised by how many people are completly unaware that
> the
> > innovations webrtc brings aren't new at all.
>
> Right. HTML is just another word processing format, too. :-)
> Silvia.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



-- 
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net

--001a113450c200c1e804eb284652
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


An important drawback of H.261 as MTI is interop with exis=
ting installed base. Very old conferencing systems and products may still h=
ave it since its easier to keep the code than delete it, but new platforms =
in the last few years will not have H.261.=A0


I also disagree with the assertion that H.261 video is bette=
r than audio only. Video quality matters and I believe the higher quality w=
e've been able to achieve in recent years due to the combo of better te=
ch (ala H.264) along with faster networks is a material factor in the accep=
tance of video by end users. I think folks writing the apps should decide w=
hether lousy video is good enough, and for business usage the answer is no.=




Finally, don't overestimate the typical upstream ba=
ndwidth that is available to users across the Internet. Many of us here on =
this list probably have nice speedy high speed connections (I have fiber wi=
th 85/35 service) and that is not the norm for the rest of the world.





On Thu, Nov 14, 2013 at 5:08 AM, Silvia Pfeiffer =
<silviapf=
eiffer1@gmail.com> wrote:


On Thu, Nov 14, 2013 at 3:=
05 PM, Philipp Hancke

<fippo@goodadvice.pages.de<=
/a>> wrote:

>> Okay, so I stand corrected (thank you for pointing this out).

>

>

> heh, I'm always surprised by how many people are completly unaware=
 that the

> innovations webrtc brings aren't new at all.




Right. HTML is just another word processing format, too. :-)

Silvia.


_____________________=
__________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





-- 
=





--001a113450c200c1e804eb284652--

From cowwoc@bbs.darktech.org  Thu Nov 14 11:49:06 2013
Return-Path: 
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 C8DBE21E80BE for ; Thu, 14 Nov 2013 11:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.379
X-Spam-Level: 
X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 U3oOex0lLKwM for ; Thu, 14 Nov 2013 11:49:02 -0800 (PST)
Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2372821E811E for ; Thu, 14 Nov 2013 11:48:52 -0800 (PST)
Received: by mail-ie0-f181.google.com with SMTP id tp5so3248118ieb.26 for ; Thu, 14 Nov 2013 11:48:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=2HydnY2jTI/TLCBEYRMDrIptS/mZQyLfbV8DyZMg8KA=; b=e9kFxrv/2AEBFUjFe0Pyt3Qg0yNjlPmTv1QZGLLozgjbKZ2mSHEX2rcaxj9iqx3tHQ /K3MtfPI1RHHjEIbt9ECLqnprnYSwwSAfQfki9ZUTMx5zF9ePHUhx9xG4q2DifgTQcuA QFuWwmcDS3CfGikMLoM7vAmFI0PWi7wwmwdFp7QZDQfOnT8vhb1pII4swr2aiauPcTW0 SG+SWX1NeRNpsV8cymio5BRkASaxIbYbohUv54hcpVG2oFWr3vGDGqBzEqBOK4BaPbd6 /C+xMhx9hyXwPrtrW1pw8KQMTx54vmxOS2tCzSUZSUX4rD2F0KoITLoLekOxHK5dt8zf W1Ag==
X-Gm-Message-State: ALoCoQmSNm7y1BeBa1SAMURRcoVpL9GT5iMA56wGh/BXd33pcOfo5AocN98mD7cu/HZLtutQaaaf
X-Received: by 10.50.152.39 with SMTP id uv7mr2506383igb.13.1384458529094; Thu, 14 Nov 2013 11:48:49 -0800 (PST)
Received: from [192.168.42.25] (out-pq-159.wireless.telus.com. [216.218.29.159]) by mx.google.com with ESMTPSA id da14sm2389765igc.1.2013.11.14.11.48.43 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 11:48:48 -0800 (PST)
Message-ID: <52852910.9090508@bbs.darktech.org>
Date: Thu, 14 Nov 2013 14:48:32 -0500
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040603040800020804040901"
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 19:49:06 -0000

This is a multi-part message in MIME format.
--------------040603040800020804040901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Just a reminder: Native applications don't necessarily have access to 
Javascript (they're running outside of a browser) so a Javascript-based 
solution sounds problematic to me. Everything we need should be 
accessible from WebRTC's Native API. If that happens to include a 
Javascript engine under the hood, so be it, but I just want to make sure 
this is understood.

Thanks,
Gili

On 14/11/2013 2:35 PM, Leon Geyser wrote:
> >>This includes a completely JavaScript-based MPEG-1 player for those 
> that don't happen to have a fitting decoder installed >>(also, yay, 
> JavaScript is fast enough now for simple video decoders!). I recreated 
> the encoded files to ensure there are no >>b-frames and documented the 
> encoder settings accordingly.
> Thanks for sharing. Looks better than what I expected.
>
> On 14 November 2013 21:12, Maik Merten  > wrote:
>
>     Hello again,
>
>     to allow for having a quick look at some test sequences I put
>     together a very very sloppy overview page at
>
>     https://dl.dropboxusercontent.com/u/14053306/mpeg1/index.html
>
>
>     This includes a completely JavaScript-based MPEG-1 player for
>     those that don't happen to have a fitting decoder installed (also,
>     yay, JavaScript is fast enough now for simple video decoders!). I
>     recreated the encoded files to ensure there are no b-frames and
>     documented the encoder settings accordingly.
>
>     Best regards,
>
>     Maik
>
>
>     Am 14.11.2013 11:52, schrieb Maik Merten:
>
>         Hello all,
>
>         in
>         http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html
>         a
>         sample of H.261 video was provided, connected to a (rhetorical?)
>         question if this provided quality would be acceptable for
>         users. Clearly
>         that provided sample is of very low and unacceptable quality.
>
>         Just for comparison, here are two CIF samples at roughly 256k
>         created by
>         a somewhat modern encoder (ffmpeg with rate/distortion
>         optimization):
>
>
>         https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg
>
>         https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg
>
>
>         (encoded as MPEG-1 video, as the "h261" encoder in ffmpeg
>         crashes when
>         using rate/distortion optimization. I understand MPEG-1 if
>         used without
>         b-frames is similar to H.261 in coding efficiency, but mostly
>         adds more
>         flexibility regarding frame sizes.
>
>         ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd
>         -trellis 2 -cmp
>         2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )
>
>         Even without formal testing it is obvious that H.261 and/or
>         MPEG-1 video
>         is clearly outperformed in terms of coding efficiency by H.264
>         and VP8.
>         However, personally, speaking as an end-user, I would very
>         much prefer
>         this video quality over audio-only calls (in cases where
>         transcoding is
>         not available), as the video produced still carries useful
>         information.
>         Also H.261/MPEG-1 is blazingly fast, can be dealt with in
>         software, and
>         is not exceedingly difficult to implement.
>
>         Of course a MTI codec with higher coding performance is much
>         preferable.
>         However, if no such high-performance codec with licensing
>         terms that are
>         acceptable for all communities can be agreed on I think it may
>         be wise
>         to seriously evaluate the option of implementing an outdated
>         codec for
>         the sake of interoperability. In practice, most calls will
>         negotiate to
>         H.264 and VP8 anyways, but sporadic negotiation failures that are
>         difficult to account for by the user are still to be expected
>         if no MTI
>         codec is defined at all.
>
>
>
>         Best regards,
>
>         Maik
>
>
>     _______________________________________________
>     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


--------------040603040800020804040901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    Just a reminder: Native applications don't necessarily have access
    to Javascript (they're running outside of a browser) so a
    Javascript-based solution sounds problematic to me. Everything we
    need should be accessible from WebRTC's Native API. If that happens
    to include a Javascript engine under the hood, so be it, but I just
    want to make sure this is understood.

    

    Thanks,

    Gili

    

    
On 14/11/2013 2:35 PM, Leon Geyser
      wrote:

    

    

      

        
>>This includes a completely JavaScript-based MPEG-1
          player for those that don't happen to have a fitting decoder
          installed >>(also, yay, JavaScript is fast enough now
          for simple video decoders!). I recreated the encoded files to
          ensure there are no >>b-frames and documented the
          encoder settings accordingly.

        

        Thanks for sharing. Looks better than what I expected.

        

          

            


              
On 14 November 2013 21:12, Maik
                Merten <maikmerten@googlemail.com>
                wrote:

                
Hello again,

                  

                  to allow for having a quick look at some test
                  sequences I put together a very very sloppy overview
                  page at

                  

                  https://dl.dropboxusercontent.com/u/14053306/mpeg1/index.html

                  

                  

                  This includes a completely JavaScript-based MPEG-1
                  player for those that don't happen to have a fitting
                  decoder installed (also, yay, JavaScript is fast
                  enough now for simple video decoders!). I recreated
                  the encoded files to ensure there are no b-frames and
                  documented the encoder settings accordingly.

                  

                  Best regards,

                  

                  Maik

                  

                  

                  Am 14.11.2013 11:52, schrieb Maik Merten:
                  

                    


                      

                        Hello all,

                        

                        in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html
                        a

                        sample of H.261 video was provided, connected to
                        a (rhetorical?)

                        question if this provided quality would be
                        acceptable for users. Clearly

                        that provided sample is of very low and
                        unacceptable quality.

                        

                        Just for comparison, here are two CIF samples at
                        roughly 256k created by

                        a somewhat modern encoder (ffmpeg with
                        rate/distortion optimization):

                        

                        

                        https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg

                        

                        https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg

                        

                        

                        (encoded as MPEG-1 video, as the "h261" encoder
                        in ffmpeg crashes when

                        using rate/distortion optimization. I understand
                        MPEG-1 if used without

                        b-frames is similar to H.261 in coding
                        efficiency, but mostly adds more

                        flexibility regarding frame sizes.

                        

                        ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video
                        -mbd rd -trellis 2 -cmp

                        2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )

                        

                        Even without formal testing it is obvious that
                        H.261 and/or MPEG-1 video

                        is clearly outperformed in terms of coding
                        efficiency by H.264 and VP8.

                        However, personally, speaking as an end-user, I
                        would very much prefer

                        this video quality over audio-only calls (in
                        cases where transcoding is

                        not available), as the video produced still
                        carries useful information.

                        Also H.261/MPEG-1 is blazingly fast, can be
                        dealt with in software, and

                        is not exceedingly difficult to implement.

                        

                        Of course a MTI codec with higher coding
                        performance is much preferable.

                        However, if no such high-performance codec with
                        licensing terms that are

                        acceptable for all communities can be agreed on
                        I think it may be wise

                        to seriously evaluate the option of implementing
                        an outdated codec for

                        the sake of interoperability. In practice, most
                        calls will negotiate to

                        H.264 and VP8 anyways, but sporadic negotiation
                        failures that are

                        difficult to account for by the user are still
                        to be expected if no MTI

                        codec is defined at all.

                        

                        

                        

                        Best regards,

                        

                        Maik

                      

                      

                      _______________________________________________

                      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


    

    

  


--------------040603040800020804040901--

From cowwoc@bbs.darktech.org  Thu Nov 14 11:52:27 2013
Return-Path: 
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 7014411E80FA for ; Thu, 14 Nov 2013 11:52:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.68
X-Spam-Level: 
X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 3ts5dFOJt2b0 for ; Thu, 14 Nov 2013 11:52:21 -0800 (PST)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6E511E810D for ; Thu, 14 Nov 2013 11:52:21 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id tp5so3488365ieb.0 for ; Thu, 14 Nov 2013 11:52:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/jnttbTzBoWThiEcO1MpywZ4Xge35MnHsx+Uc3n8NO8=; b=Eqh6W47P4p10wpBbVXDJ4oMJrf7AWwXMHjcseJCSVg7ismCQwlA2+0BJCq6Mn1faE1 BUvF5OawMOBqLEHWOvbMwVVqvinASIgk3KEClgfeYrfGMA5qbENALHVO2BW0ZUOTDobG oJMUM946XRCqJaR58ytRv5Ebkf5zGq+DK6HzJvkOBXYAXIwcX6ZvjnpDb9TycfbD9Nvq A8UzuFu/bX62/tVlXl+tquvzHAe3Ql4vKQ0T0nMNF28YDQAjRIKR2U6XoNUQnJ8rOSlv SWCrpHC23n6BDFqTsSkZ8iHX+Lk8hJ3uVgnDkwaBZ1dhZS8W///koN0ziV2V9mqg9+X+ GC3w==
X-Gm-Message-State: ALoCoQnb4HgskCjXQojGOWFYLKRqPhxu4MjT7ZtlquO5HfPlaIwOzmkEURBdTiBw8xf4kn6zCxL+
X-Received: by 10.50.72.33 with SMTP id a1mr2484368igv.58.1384458740900; Thu, 14 Nov 2013 11:52:20 -0800 (PST)
Received: from [192.168.42.25] (out-pq-159.wireless.telus.com. [216.218.29.159]) by mx.google.com with ESMTPSA id w7sm6294627igp.1.2013.11.14.11.52.19 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 11:52:20 -0800 (PST)
Message-ID: <528529EB.6000101@bbs.darktech.org>
Date: Thu, 14 Nov 2013 14:52:11 -0500
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>		<5283FDF1.8030708@bbs.darktech.org>		<52845DB0.6040501@bbs.darktech.org>	<5284626C.8050504@goodadvice.pages.de>	<528471AA.4060101@bbs.darktech.org>	<52847646.9050203@goodadvice.pages.de>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 19:52:27 -0000

Hi,

On 14/11/2013 2:41 PM, Jonathan Rosenberg wrote:
> An important drawback of H.261 as MTI is interop with existing 
> installed base. Very old conferencing systems and products may still 
> have it since its easier to keep the code than delete it, but new 
> platforms in the last few years will not have H.261.

If older platforms had working implementations, it could always be added 
back in. Meaning, there should be plenty of mature implementation out in 
the wild.

> I also disagree with the assertion that H.261 video is better than 
> audio only. Video quality matters and I believe the higher quality 
> we've been able to achieve in recent years due to the combo of better 
> tech (ala H.264) along with faster networks is a material factor in 
> the acceptance of video by end users. I think folks writing the apps 
> should decide whether lousy video is good enough, and for business 
> usage the answer is no.

I don't think that's for the specification to say. Let the developer 
decide which is better. I provided plenty of examples where a 
lower-resolution H.261 feed is preferable to audio-only (e.g. video 
games). The specification should give developers the option to choose.

Furthermore, I'll repeat again, we're not choosing between H.264 and 
H.261. We're choosing between H.261 and no video, for only the 5-10% of 
calls where there is no agreement on a higher-end codec (VP8 or H.264).

> Finally, don't overestimate the typical upstream bandwidth that is 
> available to users across the Internet. Many of us here on this list 
> probably have nice speedy high speed connections (I have fiber with 
> 85/35 service) and that is not the norm for the rest of the world.

Again, this is up to the developers to choose. I don't necessarily need 
a high-resolution video for gaming.

Gili

From maikmerten@googlemail.com  Thu Nov 14 11:54:21 2013
Return-Path: 
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 0C70D21F9CBF for ; Thu, 14 Nov 2013 11:54:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 i56Z-1OlCCj7 for ; Thu, 14 Nov 2013 11:54:20 -0800 (PST)
Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id CF60B21F9D8B for ; Thu, 14 Nov 2013 11:54:19 -0800 (PST)
Received: by mail-bk0-f41.google.com with SMTP id v15so1288481bkz.14 for ; Thu, 14 Nov 2013 11:54:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=vuZYuTdO1kksHqDAmelwSsJjt7lvcShg4SXTXNA/1mc=; b=B0wvp+hJ3zEN+WRYwgZoedukNcJc/e/K/mibMVwkWkYlWiGERUzKjcQwSc2hByHd9N B1AM+/+4w3U7hcdDERDnz+uSwN/6xwqC+KIpSGdON9dTc7XOjf1/pvsgEWlvOUCrkaxF 3wypBU0v27goRZRJ9YutH4Gt81CdI9UhF3kibOob+K1eOMf0XykD82Kusgs0eaN5WaUQ AMysjgDObJLb1pC+1kQUaB5+2Z4qt561LEvpoCZwylon0GrkDUFEQdbScdEvA8x21HSX QgL38qbeKCcSL4uGdz4fMNP2e35N7zkZJbVb9uxEpkSG8JqqRJJ5//6A7kdFg1vmlDQi fUgg==
X-Received: by 10.205.35.204 with SMTP id sx12mr650840bkb.49.1384458858939; Thu, 14 Nov 2013 11:54:18 -0800 (PST)
Received: from [192.168.2.101] (dslb-088-078-139-230.pools.arcor-ip.net. [88.78.139.230]) by mx.google.com with ESMTPSA id l5sm4581202bko.7.2013.11.14.11.54.17 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 11:54:18 -0800 (PST)
Message-ID: <52852A67.2090008@googlemail.com>
Date: Thu, 14 Nov 2013 20:54:15 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>	 <52852910.9090508@bbs.darktech.org>
In-Reply-To: <52852910.9090508@bbs.darktech.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 19:54:21 -0000

I included the JavaScript MPEG decoder so that people can have a quick 
look. I don't propose that videos should be decoded in JavaScript for 
WebRTC. If anything this merely demonstrates that old codecs have low 
processing requirements (duh!).

Maik

Am 14.11.2013 20:48, schrieb Gili:
>
> Just a reminder: Native applications don't necessarily have access to
> Javascript (they're running outside of a browser) so a Javascript-based
> solution sounds problematic to me. Everything we need should be
> accessible from WebRTC's Native API. If that happens to include a
> Javascript engine under the hood, so be it, but I just want to make sure
> this is understood.
>
> Thanks,
> Gili
>
> On 14/11/2013 2:35 PM, Leon Geyser wrote:
>> >>This includes a completely JavaScript-based MPEG-1 player for those
>> that don't happen to have a fitting decoder installed >>(also, yay,
>> JavaScript is fast enough now for simple video decoders!). I recreated
>> the encoded files to ensure there are no >>b-frames and documented the
>> encoder settings accordingly.
>> Thanks for sharing. Looks better than what I expected.
>>
>> On 14 November 2013 21:12, Maik Merten > > wrote:
>>
>>     Hello again,
>>
>>     to allow for having a quick look at some test sequences I put
>>     together a very very sloppy overview page at
>>
>>     https://dl.dropboxusercontent.com/u/14053306/mpeg1/index.html
>>
>>
>>     This includes a completely JavaScript-based MPEG-1 player for
>>     those that don't happen to have a fitting decoder installed (also,
>>     yay, JavaScript is fast enough now for simple video decoders!). I
>>     recreated the encoded files to ensure there are no b-frames and
>>     documented the encoder settings accordingly.
>>
>>     Best regards,
>>
>>     Maik
>>
>>
>>     Am 14.11.2013 11:52, schrieb Maik Merten:
>>
>>         Hello all,
>>
>>         in
>>         http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html
>>         a
>>         sample of H.261 video was provided, connected to a (rhetorical?)
>>         question if this provided quality would be acceptable for
>>         users. Clearly
>>         that provided sample is of very low and unacceptable quality.
>>
>>         Just for comparison, here are two CIF samples at roughly 256k
>>         created by
>>         a somewhat modern encoder (ffmpeg with rate/distortion
>>         optimization):
>>
>>
>>         https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg
>>
>>         https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg
>>
>>
>>         (encoded as MPEG-1 video, as the "h261" encoder in ffmpeg
>>         crashes when
>>         using rate/distortion optimization. I understand MPEG-1 if
>>         used without
>>         b-frames is similar to H.261 in coding efficiency, but mostly
>>         adds more
>>         flexibility regarding frame sizes.
>>
>>         ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd
>>         -trellis 2 -cmp
>>         2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )
>>
>>         Even without formal testing it is obvious that H.261 and/or
>>         MPEG-1 video
>>         is clearly outperformed in terms of coding efficiency by H.264
>>         and VP8.
>>         However, personally, speaking as an end-user, I would very
>>         much prefer
>>         this video quality over audio-only calls (in cases where
>>         transcoding is
>>         not available), as the video produced still carries useful
>>         information.
>>         Also H.261/MPEG-1 is blazingly fast, can be dealt with in
>>         software, and
>>         is not exceedingly difficult to implement.
>>
>>         Of course a MTI codec with higher coding performance is much
>>         preferable.
>>         However, if no such high-performance codec with licensing
>>         terms that are
>>         acceptable for all communities can be agreed on I think it may
>>         be wise
>>         to seriously evaluate the option of implementing an outdated
>>         codec for
>>         the sake of interoperability. In practice, most calls will
>>         negotiate to
>>         H.264 and VP8 anyways, but sporadic negotiation failures that are
>>         difficult to account for by the user are still to be expected
>>         if no MTI
>>         codec is defined at all.
>>
>>
>>
>>         Best regards,
>>
>>         Maik
>>
>>
>>     _______________________________________________
>>     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
>


From juberti@google.com  Thu Nov 14 12:00:01 2013
Return-Path: 
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 5334C21E80B6 for ; Thu, 14 Nov 2013 12:00:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.681
X-Spam-Level: 
X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 nqhbue9OxV9i for ; Thu, 14 Nov 2013 12:00:00 -0800 (PST)
Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 237CB11E80FA for ; Thu, 14 Nov 2013 12:00:00 -0800 (PST)
Received: by mail-vc0-f170.google.com with SMTP id hv10so1091199vcb.29 for ; Thu, 14 Nov 2013 11:59:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ERuXueJ3BU3l6+N0Dq4Y8NLWQSon8CUqFk/KtyBWna4=; b=aESKJDIOktrNcxNdGdlLeyiaN6KGkqfFMpCn69qTKvjipQvJBiGUaaYgVqwoty6/PG qbBDSM8nMHcFvpG1c/2QSbElZ4FxZWpcq2/skSI8fz8JApH1RXCEeke7P4dPx5r/sLXB 1gDznjNiKjf71ECC/4BCQbfDRQiVp3N7nbBjGFTV3ua9tQF+rlhmPGUydEyBWJLbfiCz sNH60T1AQapyeaTSsS1+fDGZW3fZxLYu7IOX80eQM8zG9V1ShtzSDwEt21aZDqV9Euxr 2zbQ9QqafB0AFJdPds+3QKSerK338LWWEd/IdRcn5zJ750fFIfTVGE5iviqyDkPtIAgn m8vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ERuXueJ3BU3l6+N0Dq4Y8NLWQSon8CUqFk/KtyBWna4=; b=Q5EzIN73hw7TXylqDa5lN7ekv5VesdD/RAZKXbeMquTh3EmcMSnQLY0cYs2gCN9dMf PU4V7lwhfo8itmi4ZAkHbWhA3meMy1FTl4fTSBuCvPp5thR5kqtJY/3cb3lxhjrBU41X zcVi0S1yQHVzUqJATA+p/oQ0HlW/A+rH6W67mCgzkkUi+Aa+deLDtkFNdSRldeYPcfSR bKk9VXhfcMRxPQsrdqHguD3WV0UcyEx80UGbiM/+J1OcNsbwu9NXp5us9T6AAZJHQqmN Q93sUZQWWuhQCqo7jy3gRtRyAhRoQZHxpvBgibLTd9gnnaFj1myBxVn7AosuXKdHm/Mq m18g==
X-Gm-Message-State: ALoCoQnLF4EM/mEefVqKxYoTnkp5zhb5KH8WwPHt4ydtEiUNTNH+Isy6cXs6jFwvN4rCLbtJN4GFoPoXa1hYZ9izeS3xihoq0GWogMjvaY/gP1etTAI7SbHVTUFEqb1113XRvB11MZajOFnU/mN5blBVD/ObU4I6F1jDNaf2yAb4dHOb4ZJiyArgT+fsUnsEaVSTOwxBbPrR
X-Received: by 10.58.210.39 with SMTP id mr7mr1820052vec.18.1384459199494; Thu, 14 Nov 2013 11:59:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Thu, 14 Nov 2013 11:59:39 -0800 (PST)
In-Reply-To: 
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com> 
From: Justin Uberti 
Date: Thu, 14 Nov 2013 11:59:39 -0800
Message-ID: 
To: Leon Geyser 
Content-Type: multipart/alternative; boundary=047d7bd6c5d0cae08504eb288691
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:00:01 -0000

--047d7bd6c5d0cae08504eb288691
Content-Type: text/plain; charset=UTF-8

Thanks, this is interesting. Is the ffmpeg 261 encoder limited to CIF/QCIF,
or can you specify arbitrary sizes?


On Thu, Nov 14, 2013 at 11:35 AM, Leon Geyser  wrote:

> >>This includes a completely JavaScript-based MPEG-1 player for those that
> don't happen to have a fitting decoder installed >>(also, yay, JavaScript
> is fast enough now for simple video decoders!). I recreated the encoded
> files to ensure there are no >>b-frames and documented the encoder settings
> accordingly.
> Thanks for sharing. Looks better than what I expected.
>
>
> On 14 November 2013 21:12, Maik Merten  wrote:
>
>> Hello again,
>>
>> to allow for having a quick look at some test sequences I put together a
>> very very sloppy overview page at
>>
>> https://dl.dropboxusercontent.com/u/14053306/mpeg1/index.html
>>
>>
>> This includes a completely JavaScript-based MPEG-1 player for those that
>> don't happen to have a fitting decoder installed (also, yay, JavaScript is
>> fast enough now for simple video decoders!). I recreated the encoded files
>> to ensure there are no b-frames and documented the encoder settings
>> accordingly.
>>
>> Best regards,
>>
>> Maik
>>
>>
>> Am 14.11.2013 11:52, schrieb Maik Merten:
>>
>>  Hello all,
>>>
>>> in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html a
>>> sample of H.261 video was provided, connected to a (rhetorical?)
>>> question if this provided quality would be acceptable for users. Clearly
>>> that provided sample is of very low and unacceptable quality.
>>>
>>> Just for comparison, here are two CIF samples at roughly 256k created by
>>> a somewhat modern encoder (ffmpeg with rate/distortion optimization):
>>>
>>>
>>> https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg
>>>
>>> https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg
>>>
>>>
>>> (encoded as MPEG-1 video, as the "h261" encoder in ffmpeg crashes when
>>> using rate/distortion optimization. I understand MPEG-1 if used without
>>> b-frames is similar to H.261 in coding efficiency, but mostly adds more
>>> flexibility regarding frame sizes.
>>>
>>> ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd -trellis 2 -cmp
>>> 2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )
>>>
>>> Even without formal testing it is obvious that H.261 and/or MPEG-1 video
>>> is clearly outperformed in terms of coding efficiency by H.264 and VP8.
>>> However, personally, speaking as an end-user, I would very much prefer
>>> this video quality over audio-only calls (in cases where transcoding is
>>> not available), as the video produced still carries useful information.
>>> Also H.261/MPEG-1 is blazingly fast, can be dealt with in software, and
>>> is not exceedingly difficult to implement.
>>>
>>> Of course a MTI codec with higher coding performance is much preferable.
>>> However, if no such high-performance codec with licensing terms that are
>>> acceptable for all communities can be agreed on I think it may be wise
>>> to seriously evaluate the option of implementing an outdated codec for
>>> the sake of interoperability. In practice, most calls will negotiate to
>>> H.264 and VP8 anyways, but sporadic negotiation failures that are
>>> difficult to account for by the user are still to be expected if no MTI
>>> codec is defined at all.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Maik
>>>
>>
>> _______________________________________________
>> 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
>
>

--047d7bd6c5d0cae08504eb288691
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks, this is interesting. Is the ffmpeg 261 encoder lim=
ited to CIF/QCIF, or can you specify arbitrary sizes?


On Thu, Nov 14, 2013 at 11:35 AM, L=
eon Geyser <lgeyser@gmail.com> wrote:




>>This incl=
udes a completely JavaScript-based MPEG-1 player for those that
 don't happen to have a fitting decoder installed >>(also, yay, J=
avaScript
 is fast enough now for simple video decoders!). I recreated the encoded
 files to ensure there are no >>b-frames and documented the encoder=
=20
settings accordingly.
Thanks for sharing. Looks better than =
what I expected.


On 14 November 2013 21:12, Maik Merten <mai=
kmerten@googlemail.com> wrote:





Hello again,



to allow for having a quick look at some test sequences I put together a ve=
ry very sloppy overview page at



https://dl.dropboxusercontent.com/u/14053306/mpeg1/=
index.html





This includes a completely JavaScript-based MPEG-1 player for those that do=
n't happen to have a fitting decoder installed (also, yay, JavaScript i=
s fast enough now for simple video decoders!). I recreated the encoded file=
s to ensure there are no b-frames and documented the encoder settings accor=
dingly.







Best regards,



Maik





Am 14.11.2013 11:52, schrieb Maik Merten:




Hello all,



in http://www.ietf.org/mail-archive/web/rtcweb/=
current/msg09721.html a

sample of H.261 video was provided, connected to a (rhetorical?)

question if this provided quality would be acceptable for users. Clearly
that provided sample is of very low and unacceptable quality.



Just for comparison, here are two CIF samples at roughly 256k created by
a somewhat modern encoder (ffmpeg with rate/distortion optimization):





https://dl.dropboxusercontent.com/u/14053306/mp=
eg1/irene-256k.mpg



https://dl.dropboxusercontent.com/u/14053306/m=
peg1/mad900-256k.mpg





(encoded as MPEG-1 video, as the "h261" encoder in ffmpeg crashes=
 when

using rate/distortion optimization. I understand MPEG-1 if used without

b-frames is similar to H.261 in coding efficiency, but mostly adds more

flexibility regarding frame sizes.



ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd -trellis 2 -cmp

2 -subcmp 2 -g 100 =C2=A0-vb 256k irene-256k.mpg )



Even without formal testing it is obvious that H.261 and/or MPEG-1 video
is clearly outperformed in terms of coding efficiency by H.264 and VP8.

However, personally, speaking as an end-user, I would very much prefer

this video quality over audio-only calls (in cases where transcoding is

not available), as the video produced still carries useful information.

Also H.261/MPEG-1 is blazingly fast, can be dealt with in software, and

is not exceedingly difficult to implement.



Of course a MTI codec with higher coding performance is much preferable.
However, if no such high-performance codec with licensing terms that are
acceptable for all communities can be agreed on I think it may be wise

to seriously evaluate the option of implementing an outdated codec for

the sake of interoperability. In practice, most calls will negotiate to

H.264 and VP8 anyways, but sporadic negotiation failures that are

difficult to account for by the user are still to be expected if no MTI

codec is defined at all.







Best regards,



Maik





_______________________________________________

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





--047d7bd6c5d0cae08504eb288691--

From wes@mti-systems.com  Thu Nov 14 12:19:09 2013
Return-Path: 
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 7CD8B11E810D for ; Thu, 14 Nov 2013 12:19:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.937
X-Spam-Level: 
X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.662,  BAYES_00=-2.599]
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 mgXz4MPXgYjA for ; Thu, 14 Nov 2013 12:19:04 -0800 (PST)
Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id A696D11E8119 for ; Thu, 14 Nov 2013 12:19:04 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id rAEKJ1ad018536 for ; Thu, 14 Nov 2013 15:19:01 -0500
Received: (qmail 7467 invoked by uid 0); 14 Nov 2013 20:19:01 -0000
X-TCPREMOTEIP: 107.45.110.113
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.110.113) by 0 with ESMTPA; 14 Nov 2013 20:19:00 -0000
Message-ID: <5285302A.2040903@mti-systems.com>
Date: Thu, 14 Nov 2013 15:18:50 -0500
From: Wesley Eddy 
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Ted Hardie 
References: <5283DF61.9060807@alvestrand.no>	<52848582.1070408@ericsson.com>	<5285062F.9070204@mti-systems.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "rai-ads@tools.ietf.org" , "rtcweb@ietf.org" , tsv-ads@tools.ietf.org
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:19:09 -0000

On 11/14/2013 1:38 PM, Ted Hardie wrote:
> 
> The issue raised isn't that there is an RTCWEB document gated on it, but
> that shipping code does require this to be resolved.


Hi Ted, it probably doesn't matter if I don't understand, but
it seems dubious to me that any shipping code could be held
up over this.  Codebases don't need to set DSCP in the same
way, plus we've always been told that RTCWEB codebases are
easy to upgrade.  Anyone can ship code setting the DSCPs in
whatever way they want to, and there will be no interop issues.


> The message you
> point to above notes a core issue, which I assume is this:
> 
> ...


Actually, there are others.  It was pointed out on the TSVWG list
that the actual mappings recommended in the document are not going
to work well.  For instance, see:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg12072.html


> I think the authors may not have seen "interesting facet" 
> as a clear enough signal that they were blocked on this.


I don't know if they're really "blocked" on this though ... I've
just brought it up as a comment.


> Can you restate this problem to them, so that they understand either
> where in the document they should raise the issue or where there is work they can reference
> for incorporation?


IMO, this is a fundamental issue with the recommendation that
differs from the way that DiffServ is implemented and thought
about.  Classifiers operate based on flow-level n-tuple
information generally.  The document pretends that what it's
prescribing is perfectly normal, which I don't think is the case,
and I don't know if it's even something the IETF wants to do.


-- 
Wes Eddy
MTI Systems

From maikmerten@googlemail.com  Thu Nov 14 12:20:30 2013
Return-Path: 
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 1EDA821E8132 for ; Thu, 14 Nov 2013 12:20:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
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 pk4jdvYhlfl9 for ; Thu, 14 Nov 2013 12:20:29 -0800 (PST)
Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2D39021E8115 for ; Thu, 14 Nov 2013 12:20:28 -0800 (PST)
Received: by mail-bk0-f44.google.com with SMTP id d7so1302113bkh.31 for ; Thu, 14 Nov 2013 12:20:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3iktQk55y1l6JqN+qPu+3NsY8tY2MhbyfaEBzS4JxwM=; b=NjgPwCsWoI23882G1wCEiNSYnMw5WoXlOuVof3YaEDd3Q08uV34WabmfrnwvPbNexr h8zZZq6GHKFagrs/FMZF6PI+h8OsymGWrtOcs0lNVa+cfqVFQn8zOIspqUUvcMZw8q5L lf+hKjp2HKO5LzeKyNFB9b7kQhfATdRIdSALLSfBd+CqYDY756NelruM7z4hvUCAnmR3 Nef6zCLEqwHMLpCtPCUU5pmKS6+goDqoNuJGq87YwQHZ7+yaO33POjtyR5CAoVOYVJnL U9R2yxxVBMGtfzQq0c9h+2Z885Kf3jSzA6kXYOuDjwcJdatg6EmXrmuPF7i7Dt944Q5N 8cig==
X-Received: by 10.205.106.193 with SMTP id dv1mr677302bkc.95.1384460428229; Thu, 14 Nov 2013 12:20:28 -0800 (PST)
Received: from [192.168.2.101] (dslb-088-078-139-230.pools.arcor-ip.net. [88.78.139.230]) by mx.google.com with ESMTPSA id m1sm127925bkr.10.2013.11.14.12.20.26 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 12:20:27 -0800 (PST)
Message-ID: <52853089.2050204@googlemail.com>
Date: Thu, 14 Nov 2013 21:20:25 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>		<5283FDF1.8030708@bbs.darktech.org>		<52845DB0.6040501@bbs.darktech.org>	<5284626C.8050504@goodadvice.pages.de>	<528471AA.4060101@bbs.darktech.org>	<52847646.9050203@goodadvice.pages.de>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:20:30 -0000

Am 14.11.2013 20:41, schrieb Jonathan Rosenberg:
> I also disagree with the assertion that H.261 video is better than audio
> only. Video quality matters and I believe the higher quality we've been
> able to achieve in recent years due to the combo of better tech (ala
> H.264) along with faster networks is a material factor in the acceptance
> of video by end users. I think folks writing the apps should decide
> whether lousy video is good enough, and for business usage the answer is no.

Well, as long as there is a MTI video codec, even if it is H.261 or 
MPEG-1, users at least have a *choice* if the transferred video content 
suits their needs. There can always be a "mute video" option for 
situations where the video content is not useful, no matter what the reason.

Also codecs such as H.261/MPEG-1 would only be chosen during negotiation 
if everything else has failed. IMO they at least cover the "talking 
head" scenario quite decently, even with bitrates in the region of 
256-384 kbit/s. For me, this is "G.711, but for video" and often more 
useful than "no video at all" - albeit not always (e.g., in your 
business use case).

(Personally, I'd even prefer ASCII-video over "no video forced onto the 
user in case of negotiation failure" - although I'd choose 
PETSCII-video, based on the character set of Commodore's 8-bit computers 
for added awesome. PETSCII has some well designed graphical symbols 
which may prove useful in a number of scenarios.)


Best regards,

Maik


From goran.ap.eriksson@ericsson.com  Thu Nov 14 12:21:24 2013
Return-Path: 
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 EF2C221E80F7 for ; Thu, 14 Nov 2013 12:21:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.123
X-Spam-Level: 
X-Spam-Status: No, score=-4.123 tagged_above=-999 required=5 tests=[AWL=1.825,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 BMaubUuK04eg for ; Thu, 14 Nov 2013 12:21:20 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC15E21E80BD for ; Thu, 14 Nov 2013 12:21:19 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-d9-528530be38a7
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5F.80.23787.EB035825; Thu, 14 Nov 2013 21:21:19 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 21:21:18 +0100
From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= 
To: Jonathan Rosenberg 
Thread-Topic: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
Thread-Index: AQHO4XGdGQjKQ3DwiUm0TG1WZ3ky9JolK0NJ
Date: Thu, 14 Nov 2013 20:21:17 +0000
Message-ID: <6B5C94E8-4A3A-49D8-A772-A20B459CA221@ericsson.com>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>  <5283FDF1.8030708@bbs.darktech.org>  <52845DB0.6040501@bbs.darktech.org>	<5284626C.8050504@goodadvice.pages.de> <528471AA.4060101@bbs.darktech.org>	<52847646.9050203@goodadvice.pages.de> , 
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: sv-SE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_6B5C94E84A3A49D8A772A20B459CA221ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre5+g9Ygg+1b2S2any9jt1j7r53d YuWtCywOzB47Z91l91iy5CeTR+v6mYwBzFFcNimpOZllqUX6dglcGatmWRVcM6q4vvExYwPj BO0uRk4OCQETif6/+9ggbDGJC/fWA9lcHEIChxglVhzfwgThLGGU6O3+zApSxSbgLTFtxVkw W0RAR2Lr3SOMIDazQJhEz6mtTCC2sICvxK8DS9i7GDmAagIktp6WgCg3kvh68QTYMhYBVYkL 0zayg9i8AvYSL48+ZYbYdZpFon3iQjaQXk6BQIn7t8VAahgFZCXuf7/HArFKXOLz3AdMEEcL SCzZc54ZwhaVePn4HytETbLE8w+rGSHmC0qcnPmEZQKjyCwk7bOQlM1CUgYR15O4MXUKG4St LbFs4WtmCFtXYsa/QyzI4gsY2VcxsucmZuaklxtuYgRG08Etv3V3MJ46J3KIUZqDRUmc98Nb 5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjOzt03lvxc132+pwxvhZUbvuTcNVX/WCU8wW dwklHE/dqrkj6fdGuYsv3ygIT0/nSI58LS/4TC42c9rJ5w5cUjZ/zt6/EvM0gFcwreDkzRjL GNHe/VUW03sT1dPsd65pqt4QbcuT8zJi5zVPEyH/1T+Do+X3+Yoqbp+QzvI0INRz9dJDESKv lFiKMxINtZiLihMBcB+jfHQCAAA=
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:21:25 -0000

--_000_6B5C94E84A3A49D8A772A20B459CA221ericssoncom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



14 nov 2013 kl. 20:42 skrev "Jonathan Rosenberg" >:

An important drawback of H.261 as MTI is interop with existing installed ba=
se. Very old conferencing systems and products may still have it since its =
easier to keep the code than delete it, but new platforms in the last few y=
ears will not have H.261.

I also disagree with the assertion that H.261 video is better than audio on=
ly. Video quality matters and I believe the higher quality we've been able =
to achieve in recent years due to the combo of better tech (ala H.264) alon=
g with faster networks is a material factor in the acceptance of video by e=
nd users. I think folks writing the apps should decide whether lousy video =
is good enough, and for business usage the answer is no.

Finally, don't overestimate the typical upstream bandwidth that is availabl=
e to users across the Internet. Many of us here on this list probably have =
nice speedy high speed connections (I have fiber with 85/35 service) and th=
at is not the norm for the rest of the world.

And if we consider cellular access to Internet, upstream bandwidth may be e=
ven more limited. An MTI making mobile WEBRTC difficult is not easy to embr=
ace wholeheartedly considering we already have it WEBRTC in some mobile bro=
wsers.






On Thu, Nov 14, 2013 at 5:08 AM, Silvia Pfeiffer > wrote:
On Thu, Nov 14, 2013 at 3:05 PM, Philipp Hancke
> wrote:
>> Okay, so I stand corrected (thank you for pointing this out).
>
>
> heh, I'm always surprised by how many people are completly unaware that t=
he
> innovations webrtc brings aren't new at all.

Right. HTML is just another word processing format, too. :-)
Silvia.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



--
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--_000_6B5C94E84A3A49D8A772A20B459CA221ericssoncom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














14 nov 2013 kl. 20:42 skrev "Jonathan Rosenberg" <jdrosen@jdrosen.net>:










An important drawback of H.261 as MTI is interop with exis=
ting installed base. Very old conferencing systems and products may still h=
ave it since its easier to keep the code than delete it, but new platforms =
in the last few years will not have
 H.261. 






I also disagree with the assertion that H.261 video is better than aud=
io only. Video quality matters and I believe the higher quality we've been =
able to achieve in recent years due to the combo of better tech (ala H.264)=
 along with faster networks is a
 material factor in the acceptance of video by end users. I think folks wri=
ting the apps should decide whether lousy video is good enough, and for bus=
iness usage the answer is no.







Finally, don't overestimate the typical upstream bandwidth that is ava=
ilable to users across the Internet. Many of us here on this list probably =
have nice speedy high speed connections (I have fiber with 85/35 service) a=
nd that is not the norm for the
 rest of the world.













And if we consider cellular access to Internet, upstream bandwidth may=
 be even more limited. An MTI making mobile WEBRTC difficult is not easy to=
 embrace wholeheartedly considering we already have it WEBRTC in some mobil=
e browsers.





















_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.=
ietf.org/mailman/listinfo/rtcweb








--_000_6B5C94E84A3A49D8A772A20B459CA221ericssoncom_--

From cowwoc@bbs.darktech.org  Thu Nov 14 12:24:32 2013
Return-Path: 
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 4BE6511E810D for ; Thu, 14 Nov 2013 12:24:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.046
X-Spam-Level: 
X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 wzfHTZ0QlSYi for ; Thu, 14 Nov 2013 12:24:27 -0800 (PST)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD0221F9C1D for ; Thu, 14 Nov 2013 12:24:27 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id u16so3581352iet.34 for ; Thu, 14 Nov 2013 12:24:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=DtBU+0SbbfSX4G01iBNi/QAHs3/fsA/KjNfyn58SyuE=; b=Lnq1JlSnAoHgwQWNIDIxlGG+yHHr/KzMrsNo+c/uigVPXMLpotle58ZsZkaNdg9GJa moHTI+WKjKuM+NO5DqNKBr0ZrqLyVFQcuW7CN5LkbRCUi2VRjkTPKYczxJ/9KnoLl08f IJYOs8CtR5AEGq9v+8SM25mhbjoAbR2Hgz87dB6cZ4NnvyW1WUmy17Eq39jYMHOnQi5I uN7D2l58KMvvR2z2iDvmkVtRd/7Uz1+a94/0u7sSl4Ikl0E/zm9oB3JCdMxovQLW3hPO DTVDFPPBW5UHilRHE2VnNL/crIPjb/mdrL0bntlOot+yIzEslDYE78f3Sos0f9Y4YWnW 38LQ==
X-Gm-Message-State: ALoCoQk/YV8MvIYiy6O3iKIpa1swf6bLiqupOF7ixRuJB9vH+djnjUR+aWI5vCyaiJiOf8e0DKta
X-Received: by 10.50.73.201 with SMTP id n9mr2580381igv.8.1384460666771; Thu, 14 Nov 2013 12:24:26 -0800 (PST)
Received: from [192.168.42.220] (out-pq-194.wireless.telus.com. [216.218.29.194]) by mx.google.com with ESMTPSA id m1sm38830098igj.10.2013.11.14.12.24.24 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 12:24:26 -0800 (PST)
Message-ID: <52853171.5050306@bbs.darktech.org>
Date: Thu, 14 Nov 2013 15:24:17 -0500
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com>	<528492E8.8020202@ericsson.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040208020204090908070601"
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:24:32 -0000

This is a multi-part message in MIME format.
--------------040208020204090908070601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

I would argue this should be a new point. I am advocating H.261 as MTI 
and all other codecs are optional and I want this option to stand in its 
own right. I don't think we need to mandate what other codecs vendors 
must implement (I'm not sure it would make a practical difference anyway).

Gili

On 14/11/2013 4:37 AM, Leon Geyser wrote:
> Point 6 can change to:
> All entities MUST support H.261 and all entities MUST support at least 
> one of H.264 and VP8
> or it can be made a new point?
>
> I don't like point 5 at all since it doesn't really help with 
> negotiation failure IMO. Implement the codec that you want to 
> implement = No MTI.
>
>
> On 14 November 2013 11:07, Magnus Westerlund 
>  > wrote:
>
>     WG,
>
>     I have put the given video codec selection alternatives on this
>     wikipage:
>
>     http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart
>
>     It is not acceptable to simply add things on this list. You need
>     to send
>     email to the list.
>
>     Cheers
>
>     Magnus
>
>
>     On 2013-11-13 21:23, Gonzalo Camarillo wrote:
>     > Folks,
>     >
>     > I hope everybody had a safe trip back home after Vancouver.
>     >
>     > As you all know, we need to make progress regarding the
>     selection of the
>     > MTI video codec. The following are some of the alternatives we
>     have on
>     > the table:
>     >
>     >  1. All entities MUST support H.264
>     >  2. All entities MUST support VP8
>     >  3. All entities MUST support both H.264 and VP8
>     >  4. Browsers MUST support both H.264 and VP8
>     >  5. All entities MUST support either H.264 or VP8
>     >  6. All entities MUST support H.261
>     >  7. There is no MTI video codec
>     >
>     > If you want the group to consider additional alternatives to the
>     ones
>     > above, please let the group know within the following *two
>     weeks*. At
>     > that point, the chairs will be listing all the received
>     alternatives and
>     > proposing a process to select one among them.
>     >
>     > Please, send your proposals in an email to the list. You do not
>     need to
>     > write a draft; just send the text you would like to see in the final
>     > document regarding video codecs.
>     >
>     > Thanks,
>     >
>     > Gonzalo
>     > Responsible AD for this WG
>     >
>     > _______________________________________________
>     > rtcweb mailing list
>     > rtcweb@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/rtcweb
>     >
>     >
>
>
>     --
>
>     Magnus Westerlund
>
>     ----------------------------------------------------------------------
>     Multimedia Technologies, Ericsson Research EAB/TVM
>     ----------------------------------------------------------------------
>     Ericsson AB                | Phone +46 10 7148287
>     
>     Färögatan 6                | Mobile +46 73 0949079
>     
>     SE-164 80 Stockholm, Sweden| mailto:
>     magnus.westerlund@ericsson.com 
>     ----------------------------------------------------------------------
>
>     _______________________________________________
>     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


--------------040208020204090908070601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I would argue this should be a new point. I am advocating H.261 as
    MTI and all other codecs are optional and I want this option to
    stand in its own right. I don't think we need to mandate what other
    codecs vendors must implement (I'm not sure it would make a
    practical difference anyway).

    

    Gili

    

    
On 14/11/2013 4:37 AM, Leon Geyser
      wrote:

    

    

      

        

          
Point 6 can change to:

            All entities MUST support H.261 and all entities MUST
            support at least one of H.264 and VP8

          

          or it can be made a new point?

          

        

        I don't like point 5 at all since it doesn't really help with
        negotiation failure IMO. Implement the codec that you want to
        implement = No MTI.

      

      


        

        
On 14 November 2013 11:07, Magnus
          Westerlund <magnus.westerlund@ericsson.com>
          wrote:

          
WG,

            

            I have put the given video codec selection alternatives on
            this wikipage:

            

            http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart

            

            It is not acceptable to simply add things on this list. You
            need to send

            email to the list.

            

            Cheers

            

                Magnus

              
            

              


                

                On 2013-11-13 21:23, Gonzalo Camarillo wrote:

                > Folks,

                >

                > I hope everybody had a safe trip back home after
                Vancouver.

                >

                > As you all know, we need to make progress regarding
                the selection of the

                > MTI video codec. The following are some of the
                alternatives we have on

                > the table:

                >

                >  1. All entities MUST support H.264

                >  2. All entities MUST support VP8

                >  3. All entities MUST support both H.264 and VP8

                >  4. Browsers MUST support both H.264 and VP8

                >  5. All entities MUST support either H.264 or VP8

                >  6. All entities MUST support H.261

                >  7. There is no MTI video codec

                >

                > If you want the group to consider additional
                alternatives to the ones

                > above, please let the group know within the
                following *two weeks*. At

                > that point, the chairs will be listing all the
                received alternatives and

                > proposing a process to select one among them.

                >

                > Please, send your proposals in an email to the
                list. You do not need to

                > write a draft; just send the text you would like to
                see in the final

                > document regarding video codecs.

                >

                > Thanks,

                >

                > Gonzalo

                > Responsible AD for this WG

                >

                > _______________________________________________

                > rtcweb mailing list

                > rtcweb@ietf.org

                > https://www.ietf.org/mailman/listinfo/rtcweb

                >

                >

                

                

              

            

            
--

              

              Magnus Westerlund

              

----------------------------------------------------------------------

              Multimedia Technologies, Ericsson Research EAB/TVM

----------------------------------------------------------------------

              Ericsson AB                | Phone  +46 10 7148287

              Färögatan 6                | Mobile +46 73 0949079

              SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com

----------------------------------------------------------------------

              

            

            

              
_______________________________________________

                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


    

    

  


--------------040208020204090908070601--

From maikmerten@googlemail.com  Thu Nov 14 12:30:03 2013
Return-Path: 
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 034F721F9EED for ; Thu, 14 Nov 2013 12:30:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599]
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 ItfUJsiX1nBz for ; Thu, 14 Nov 2013 12:30:02 -0800 (PST)
Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 25CD911E8119 for ; Thu, 14 Nov 2013 12:30:01 -0800 (PST)
Received: by mail-bk0-f49.google.com with SMTP id w14so1505598bkz.36 for ; Thu, 14 Nov 2013 12:30:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GMkOaA+xNVohIG5Lr7IDP/S0ckzaSJiCvDOcYoMI7pY=; b=ZTsMs4y/jejP+8NeHWNRRr1luFDvucVITDV/RKHta91FaqjzrUpKQDvbvV9uxYUmDS RWn6JUdyiSo/fJuD5OkJPpE4CiIyX1ldgjz1kRMUI4Jxqa8RWvfoYFZlncQsDxFcJmWH UFZFKEc6z4po7YxajM2hPWrIYVCz3HGaPNy725JYQ2M5Q8Fm7WIrwVgzeNNRjjrku9B7 ttG1xrnPttcxqcGAhgpKCDrJlz0xqzicjux9RtmZn8gj+W7AgclG+AzZ52ulwaMDwMu3 HhVX7DGkExXbu76NwQsmPUUCPYvlQfj6QR5z884+4STntaiA1KvnEBPusIJd/fKg+c6S XRow==
X-Received: by 10.205.23.194 with SMTP id rb2mr685479bkb.112.1384461001083; Thu, 14 Nov 2013 12:30:01 -0800 (PST)
Received: from [192.168.2.101] (dslb-088-078-139-230.pools.arcor-ip.net. [88.78.139.230]) by mx.google.com with ESMTPSA id on10sm4715814bkb.13.2013.11.14.12.29.59 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 12:30:00 -0800 (PST)
Message-ID: <528532C6.1060406@googlemail.com>
Date: Thu, 14 Nov 2013 21:29:58 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:30:03 -0000

Am 14.11.2013 20:59, schrieb Justin Uberti:
> Thanks, this is interesting. Is the ffmpeg 261 encoder limited to
> CIF/QCIF, or can you specify arbitrary sizes?

As far as I know CIF/QCIF is hardcoded into the H.261 bitstream format, 
so there is nothing ffmpeg can do about it. The bitstream format of 
MPEG-1 Part 2 lifts this restriction.


Maik


From lgeyser@gmail.com  Thu Nov 14 12:30:32 2013
Return-Path: 
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 E1E5421E8130 for ; Thu, 14 Nov 2013 12:30:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.328
X-Spam-Level: 
X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YLlnFjRhcghS for ; Thu, 14 Nov 2013 12:30:31 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 23A1A21E8128 for ; Thu, 14 Nov 2013 12:30:28 -0800 (PST)
Received: by mail-lb0-f175.google.com with SMTP id p9so1964791lbv.6 for ; Thu, 14 Nov 2013 12:30:24 -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=c+wZVsF7t2dE/kNuPBR4hG2eXJDoWmhpkkFWcDJpTvI=; b=fVDoZfUZxIQLDzq5Ay/3YeJuC1G6V3JLN334wxqjkTgNxxjJ67rucAZEE0lguTz7tl 26esaZ+L5q6i4nOqmEIyWFkTQfijkh0ae5cbF2PlwXhpRqClV7aGhiB0i1D/hf9raNkR 5YkBpokubKpvv+Lf+4LoSLAVm5727BuVUqk05+EYwkrWoJVCgtGENbj3DbloYAKxBxqt OYB37xXV4t07QlN26gA/33m9JesVgxPoa7dGFb4DW+kV9FALQ6A3vQ3WgPOhLCJrSV+z 3cnqjqiI1oY9tP1z5Kuk9CRjipBT6R4UCBvzpDU/Qkiq7Yhzu/1oeKKlv7jbxMvMdIP+ 7IYg==
MIME-Version: 1.0
X-Received: by 10.152.44.133 with SMTP id e5mr776267lam.58.1384461024371; Thu, 14 Nov 2013 12:30:24 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 14 Nov 2013 12:30:24 -0800 (PST)
In-Reply-To: <6B5C94E8-4A3A-49D8-A772-A20B459CA221@ericsson.com>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283E700.5090300@bbs.darktech.org>  <5283FDF1.8030708@bbs.darktech.org>  <52845DB0.6040501@bbs.darktech.org> <5284626C.8050504@goodadvice.pages.de> <528471AA.4060101@bbs.darktech.org> <52847646.9050203@goodadvice.pages.de>   <6B5C94E8-4A3A-49D8-A772-A20B459CA221@ericsson.com>
Date: Thu, 14 Nov 2013 22:30:24 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0160a478902a9f04eb28f3cf
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:30:33 -0000

--089e0160a478902a9f04eb28f3cf
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>>And if we consider cellular access to Internet, upstream bandwidth may be
even more limited. An MTI making mobile WEBRTC difficult is >>not easy to
embrace wholeheartedly considering we already have it WEBRTC in some mobile
browsers.

Technically H.261 can work at as low as 64Kbps. I doubt the upstream will
be lower than that.


On 14 November 2013 22:21, G=F6ran Eriksson AP  wrote:

>
>
> 14 nov 2013 kl. 20:42 skrev "Jonathan Rosenberg" :
>
>   An important drawback of H.261 as MTI is interop with existing
> installed base. Very old conferencing systems and products may still have
> it since its easier to keep the code than delete it, but new platforms in
> the last few years will not have H.261.
>
>  I also disagree with the assertion that H.261 video is better than audio
> only. Video quality matters and I believe the higher quality we've been
> able to achieve in recent years due to the combo of better tech (ala H.26=
4)
> along with faster networks is a material factor in the acceptance of vide=
o
> by end users. I think folks writing the apps should decide whether lousy
> video is good enough, and for business usage the answer is no.
>
>  Finally, don't overestimate the typical upstream bandwidth that is
> available to users across the Internet. Many of us here on this list
> probably have nice speedy high speed connections (I have fiber with 85/35
> service) and that is not the norm for the rest of the world.
>
>
>  And if we consider cellular access to Internet, upstream bandwidth may
> be even more limited. An MTI making mobile WEBRTC difficult is not easy t=
o
> embrace wholeheartedly considering we already have it WEBRTC in some mobi=
le
> browsers.
>
>
>
>
>
>
> On Thu, Nov 14, 2013 at 5:08 AM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com> wrote:
>
>> On Thu, Nov 14, 2013 at 3:05 PM, Philipp Hancke
>>  wrote:
>> >> Okay, so I stand corrected (thank you for pointing this out).
>> >
>> >
>> > heh, I'm always surprised by how many people are completly unaware tha=
t
>> the
>> > innovations webrtc brings aren't new at all.
>>
>>  Right. HTML is just another word processing format, too. :-)
>> Silvia.
>>  _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
>
>  --
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>
>  _______________________________________________
> 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
>
>

--089e0160a478902a9f04eb28f3cf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


>>And if we consider cellular access to Internet, up=
stream bandwidth may=20
be even more limited. An MTI making mobile WEBRTC difficult is >>not =
easy=20
to embrace wholeheartedly considering we already have it WEBRTC in some=20
mobile browsers.

Technically H.261 can work at as low as 64Kbps. I d=
oubt the upstream will be lower than that.


On 14 November 2013 22:21, G=F6ran E=
riksson AP <goran.ap.eriksson@ericsson.com> wro=
te:
















14 nov 2013 kl. 20:42 skrev "Jonathan Rosenberg" <jdrosen@jdrosen.net>:









An important drawback of H.261 as MTI is interop with exis=
ting installed base. Very old conferencing systems and products may still h=
ave it since its easier to keep the code than delete it, but new platforms =
in the last few years will not have
 H.261.=A0






I also disagree with the assertion that H.261 video is better than aud=
io only. Video quality matters and I believe the higher quality we've b=
een able to achieve in recent years due to the combo of better tech (ala H.=
264) along with faster networks is a
 material factor in the acceptance of video by end users. I think folks wri=
ting the apps should decide whether lousy video is good enough, and for bus=
iness usage the answer is no.







Finally, don't overestimate the typical upstream bandwidth that is=
 available to users across the Internet. Many of us here on this list proba=
bly have nice speedy high speed connections (I have fiber with 85/35 servic=
e) and that is not the norm for the
 rest of the world.













And if we consider cellular access to Internet, upstream bandwid=
th may be even more limited. An MTI making mobile WEBRTC difficult is not e=
asy to embrace wholeheartedly considering we already have it WEBRTC in some=
 mobile browsers.


































On Thu, Nov 14, 2013 at 5:08 AM, Silvia Pfeiffer=
 
<silviapf=
eiffer1@gmail.com> wrote:




On Thu, Nov 14, 2013 at 3:05 PM, Philipp Hancke

<fippo@go=
odadvice.pages.de> wrote:

>> Okay, so I stand corrected (thank you for pointing this out).

>

>

> heh, I'm always surprised by how many people are completly unaware=
 that the

> innovations webrtc brings aren't new at all.





Right. HTML is just another word processing format, too. :-)

Silvia.





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb


















-- 











_______________________________________________

rtcweb mailing list

rtcweb@ietf.org<=
/a>

https://www.ietf.org/mailman/listinfo/rtcweb









_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--089e0160a478902a9f04eb28f3cf--

From cowwoc@bbs.darktech.org  Thu Nov 14 12:31:50 2013
Return-Path: 
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 25C9811E810D for ; Thu, 14 Nov 2013 12:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.48
X-Spam-Level: 
X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=-1.100,  BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 60yQxVGsUjjY for ; Thu, 14 Nov 2013 12:31:45 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B267011E8119 for ; Thu, 14 Nov 2013 12:31:45 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id to1so3596759ieb.3 for ; Thu, 14 Nov 2013 12:31:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lr70W2kR2XHLZ6nPGmptjLuA46VoNJ36/tjofEua5yg=; b=JscXDOrVB2oF96VdyIeC+uRXlJ5BHS/Fgbt8AATrtNK6H0IeWz1SabioYRxn/xtvqL +uiH8CZE0rwiBEfuZ1gXFjLM0Dr/Lta7Gy63yhEp6TE7O8uKzgjx6g9WzOkZ3kQ0NYyD 9i+Gve5XT5OwbQqXRC7EdYq08P3+DnT2+8381AKlIEqF/0Yyk9y/U26DpUz9H7Hu4YlP 1wjzA74qrvr4MwfDPMKkN5S7lBbSskMzDr1L9/cNp/c8QsLyBuDzFZ0mjhImlqoGM4jF G3DAuEV5gLmDIpsSvPwYxJdQJWMPDxo2mN7UetnKQPWhUSpYM//vwt7kvL+NhMRxnjZb ExVA==
X-Gm-Message-State: ALoCoQk1VcXHfugoOuQwEKYSznnT5Wsrg7z5Npz1vNWQ8/miReC9g4k9SGbFxPgSl2bYW5WQrmhc
X-Received: by 10.50.4.35 with SMTP id h3mr2619311igh.19.1384461105137; Thu, 14 Nov 2013 12:31:45 -0800 (PST)
Received: from [192.168.42.220] (out-pq-194.wireless.telus.com. [216.218.29.194]) by mx.google.com with ESMTPSA id j16sm38792429igf.6.2013.11.14.12.31.43 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 12:31:44 -0800 (PST)
Message-ID: <52853325.5030805@bbs.darktech.org>
Date: Thu, 14 Nov 2013 15:31:33 -0500
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com>	<5285209D.7020407@googlemail.com>		<52852910.9090508@bbs.darktech.org> <52852A67.2090008@googlemail.com>
In-Reply-To: <52852A67.2090008@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:31:50 -0000

In that case, excellent point :)

Gili

On 14/11/2013 2:54 PM, Maik Merten wrote:
> I included the JavaScript MPEG decoder so that people can have a quick 
> look. I don't propose that videos should be decoded in JavaScript for 
> WebRTC. If anything this merely demonstrates that old codecs have low 
> processing requirements (duh!).
>
> Maik
>
> Am 14.11.2013 20:48, schrieb Gili:
>>
>> Just a reminder: Native applications don't necessarily have access to
>> Javascript (they're running outside of a browser) so a Javascript-based
>> solution sounds problematic to me. Everything we need should be
>> accessible from WebRTC's Native API. If that happens to include a
>> Javascript engine under the hood, so be it, but I just want to make sure
>> this is understood.
>>
>> Thanks,
>> Gili
>>
>> On 14/11/2013 2:35 PM, Leon Geyser wrote:
>>> >>This includes a completely JavaScript-based MPEG-1 player for those
>>> that don't happen to have a fitting decoder installed >>(also, yay,
>>> JavaScript is fast enough now for simple video decoders!). I recreated
>>> the encoded files to ensure there are no >>b-frames and documented the
>>> encoder settings accordingly.
>>> Thanks for sharing. Looks better than what I expected.
>>>
>>> On 14 November 2013 21:12, Maik Merten >> > wrote:
>>>
>>>     Hello again,
>>>
>>>     to allow for having a quick look at some test sequences I put
>>>     together a very very sloppy overview page at
>>>
>>> https://dl.dropboxusercontent.com/u/14053306/mpeg1/index.html
>>>
>>>
>>>     This includes a completely JavaScript-based MPEG-1 player for
>>>     those that don't happen to have a fitting decoder installed (also,
>>>     yay, JavaScript is fast enough now for simple video decoders!). I
>>>     recreated the encoded files to ensure there are no b-frames and
>>>     documented the encoder settings accordingly.
>>>
>>>     Best regards,
>>>
>>>     Maik
>>>
>>>
>>>     Am 14.11.2013 11:52, schrieb Maik Merten:
>>>
>>>         Hello all,
>>>
>>>         in
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html
>>>         a
>>>         sample of H.261 video was provided, connected to a 
>>> (rhetorical?)
>>>         question if this provided quality would be acceptable for
>>>         users. Clearly
>>>         that provided sample is of very low and unacceptable quality.
>>>
>>>         Just for comparison, here are two CIF samples at roughly 256k
>>>         created by
>>>         a somewhat modern encoder (ffmpeg with rate/distortion
>>>         optimization):
>>>
>>>
>>> https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg
>>>
>>> https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg
>>>
>>>
>>>         (encoded as MPEG-1 video, as the "h261" encoder in ffmpeg
>>>         crashes when
>>>         using rate/distortion optimization. I understand MPEG-1 if
>>>         used without
>>>         b-frames is similar to H.261 in coding efficiency, but mostly
>>>         adds more
>>>         flexibility regarding frame sizes.
>>>
>>>         ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd
>>>         -trellis 2 -cmp
>>>         2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )
>>>
>>>         Even without formal testing it is obvious that H.261 and/or
>>>         MPEG-1 video
>>>         is clearly outperformed in terms of coding efficiency by H.264
>>>         and VP8.
>>>         However, personally, speaking as an end-user, I would very
>>>         much prefer
>>>         this video quality over audio-only calls (in cases where
>>>         transcoding is
>>>         not available), as the video produced still carries useful
>>>         information.
>>>         Also H.261/MPEG-1 is blazingly fast, can be dealt with in
>>>         software, and
>>>         is not exceedingly difficult to implement.
>>>
>>>         Of course a MTI codec with higher coding performance is much
>>>         preferable.
>>>         However, if no such high-performance codec with licensing
>>>         terms that are
>>>         acceptable for all communities can be agreed on I think it may
>>>         be wise
>>>         to seriously evaluate the option of implementing an outdated
>>>         codec for
>>>         the sake of interoperability. In practice, most calls will
>>>         negotiate to
>>>         H.264 and VP8 anyways, but sporadic negotiation failures 
>>> that are
>>>         difficult to account for by the user are still to be expected
>>>         if no MTI
>>>         codec is defined at all.
>>>
>>>
>>>
>>>         Best regards,
>>>
>>>         Maik
>>>
>>>
>>>     _______________________________________________
>>>     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


From cowwoc@bbs.darktech.org  Thu Nov 14 12:45:24 2013
Return-Path: 
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 BB71911E80FA for ; Thu, 14 Nov 2013 12:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.046
X-Spam-Level: 
X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 bIUk53O2oUVY for ; Thu, 14 Nov 2013 12:45:19 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D10A911E8127 for ; Thu, 14 Nov 2013 12:45:18 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id to1so3633805ieb.17 for ; Thu, 14 Nov 2013 12:45:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=ZYYNvxEyRIYazQfV8wojzkg89vmcJDSe4f45IIOamCI=; b=O3gI2WrG4C+G8ywAMsws1vZPJN+k4qvDMHPaKXlezkq/tGCtco78hZhzO9KAmg84H2 54NWbpJoSjaxOrIupxTg6JQ/ax3JeOB6ERnP71eULA3s8uIjd+qgJwakLR9dku1X6vRn edgqj2jR/XBmLuYhgLdpzym+SdMUGkUh1QUSYom9d7yadyPsKQwxR3OeCdAQ2ASvbPhL Lrjz51E0Jwtl901imz5QtB/bQfyCXe24GYp7+C7n3CoRjtZW9/HfHkVukiUwyfRwUeel 2KIMlPH6KW8POvtza8JAbWm7yUzWYj6UAYPTWYrQe834BtRqEYZfAiOh0wpuW05qC6xH EswA==
X-Gm-Message-State: ALoCoQkMBVzjPBjCSy4+OsWmirrKQ+bOBw+S/VfzUvqP8h1OT+G19sfyPBvfblXVrgCFODb1cm64
X-Received: by 10.50.154.66 with SMTP id vm2mr2597550igb.57.1384461918323; Thu, 14 Nov 2013 12:45:18 -0800 (PST)
Received: from [192.168.42.220] (out-pq-194.wireless.telus.com. [216.218.29.194]) by mx.google.com with ESMTPSA id v2sm6555598igz.3.2013.11.14.12.45.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 12:45:17 -0800 (PST)
Message-ID: <52853654.1060304@bbs.darktech.org>
Date: Thu, 14 Nov 2013 15:45:08 -0500
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com>	<20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>		<5283FDF1.8030708@bbs.darktech.org>		<52845DB0.6040501@bbs.darktech.org>	<5284626C.8050504@goodadvice.pages.de>	<528471AA.4060101@bbs.darktech.org>	<52847646.9050203@goodadvice.pages.de>	,  <6B5C94E8-4A3A-49D8-A772-A20B459CA221@ericsson.com>
In-Reply-To: <6B5C94E8-4A3A-49D8-A772-A20B459CA221@ericsson.com>
Content-Type: multipart/alternative; boundary="------------040209010103070505060407"
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:45:24 -0000

This is a multi-part message in MIME format.
--------------040209010103070505060407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 14/11/2013 3:21 PM, Göran Eriksson AP wrote:
>
>
> 14 nov 2013 kl. 20:42 skrev "Jonathan Rosenberg"  >:
>
>> An important drawback of H.261 as MTI is interop with existing 
>> installed base. Very old conferencing systems and products may still 
>> have it since its easier to keep the code than delete it, but new 
>> platforms in the last few years will not have H.261.
>>
>> I also disagree with the assertion that H.261 video is better than 
>> audio only. Video quality matters and I believe the higher quality 
>> we've been able to achieve in recent years due to the combo of better 
>> tech (ala H.264) along with faster networks is a material factor in 
>> the acceptance of video by end users. I think folks writing the apps 
>> should decide whether lousy video is good enough, and for business 
>> usage the answer is no.
>>
>> Finally, don't overestimate the typical upstream bandwidth that is 
>> available to users across the Internet. Many of us here on this list 
>> probably have nice speedy high speed connections (I have fiber with 
>> 85/35 service) and that is not the norm for the rest of the world.
>
> And if we consider cellular access to Internet, upstream bandwidth may 
> be even more limited. An MTI making mobile WEBRTC difficult is not 
> easy to embrace wholeheartedly considering we already have it WEBRTC 
> in some mobile browsers.

 1. The situation is only improving over time (meaning, the pipes are
    getting bigger).
 2. There should be enough bandwidth for the "talking head" scenario today.
 3. You still have the option of dropping to audio-only. At least you
    have the choice of using H.261 if it fits your use-case.

Gili


--------------040209010103070505060407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 14/11/2013 3:21 PM, Göran Eriksson AP wrote:

    

      
      


      

      


        14 nov 2013 kl. 20:42 skrev "Jonathan Rosenberg" <jdrosen@jdrosen.net>:

        

      

      

        

          
An important drawback of H.261 as MTI is
            interop with existing installed base. Very old conferencing
            systems and products may still have it since its easier to
            keep the code than delete it, but new platforms in the last
            few years will not have H.261. 
            


            

            
I also disagree with the assertion that H.261 video is
              better than audio only. Video quality matters and I
              believe the higher quality we've been able to achieve in
              recent years due to the combo of better tech (ala H.264)
              along with faster networks is a material factor in the
              acceptance of video by end users. I think folks writing
              the apps should decide whether lousy video is good enough,
              and for business usage the answer is no.

            


            

            
Finally, don't overestimate the typical upstream
              bandwidth that is available to users across the Internet.
              Many of us here on this list probably have nice speedy
              high speed connections (I have fiber with 85/35 service)
              and that is not the norm for the rest of the world.

          

        

      

      


      

      
And if we consider cellular access to Internet, upstream
        bandwidth may be even more limited. An MTI making mobile WEBRTC
        difficult is not easy to embrace wholeheartedly considering we
        already have it WEBRTC in some mobile browsers.

      

    

    
    
      
  1. The situation is only improving over time (meaning, the pipes
        are getting bigger).
    2. 
      
  2. There should be enough bandwidth for the "talking head"
        scenario today.
    3. 
      
  3. You still have the option of dropping to audio-only. At least
        you have the choice of using H.261 if it fits your use-case.
    4. 
    

    
Gili

    

  


--------------040209010103070505060407--

From john@jlc.net  Thu Nov 14 12:47:17 2013
Return-Path: 
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 2B32711E80FA for ; Thu, 14 Nov 2013 12:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.409
X-Spam-Level: 
X-Spam-Status: No, score=-106.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Z1GI-+0dTmsj for ; Thu, 14 Nov 2013 12:47:11 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id EA91911E8125 for ; Thu, 14 Nov 2013 12:47:09 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id D54C6C94C1; Thu, 14 Nov 2013 15:47:06 -0500 (EST)
Date: Thu, 14 Nov 2013 15:47:06 -0500
From: John Leslie 
To: "Cullen Jennings (fluffy)" 
Message-ID: <20131114204706.GC13468@verdi>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <6EFABF3B-4D97-4B2E-B3B6-0618575B1B0F@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6EFABF3B-4D97-4B2E-B3B6-0618575B1B0F@cisco.com>
User-Agent: Mutt/1.4.1i
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:47:17 -0000

Cullen Jennings (fluffy)  wrote:
> On Nov 13, 2013, at 9:55 AM, John Leslie  wrote:
> 
> >  Both H.264 and VP8 deserve "SHOULD implement" status.
> 
> Just out of curiosity, could you say a bit more about what you see
> as the difference between MAY, SHOULD, and MUST in this context?

   I'd be happy to (though I don't intend the slightest departure from
word-for-word RFC2119).

   MAY is simply a warning label -- that the authors expect some folks
to do this.

   SHOULD means it's intended as an integral part of the standard, but
the authors recognize that some implementations may not comply. The
chief difference from MAY is that anyone can hassle the implementors
which don't comply, demanding their reasons and publicly ridiculing
any reasons which are weak.

   MUST means if you don't implement it, you're not compliant with
the standard. Presumably you could be sued for false advertising if
you claim to comply to the standard but don't satisfy all the MUSTs.

--
John Leslie 

From john@jlc.net  Thu Nov 14 12:54:03 2013
Return-Path: 
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 09C9111E80FA for ; Thu, 14 Nov 2013 12:54:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.418
X-Spam-Level: 
X-Spam-Status: No, score=-106.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 7wHHsHtJeuqi for ; Thu, 14 Nov 2013 12:53:58 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id DDB9B21F9339 for ; Thu, 14 Nov 2013 12:53:57 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 27C85C94C1; Thu, 14 Nov 2013 15:53:55 -0500 (EST)
Date: Thu, 14 Nov 2013 15:53:55 -0500
From: John Leslie 
To: Silvia Pfeiffer 
Message-ID: <20131114205355.GD13468@verdi>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.1i
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:54:03 -0000

Silvia Pfeiffer  wrote:
> On Thu, Nov 14, 2013 at 12:55 AM, John Leslie  wrote:
>>
>> Basically H.264 has quite a consortium to slap down the likes of
>> Nokia in court should they sue anyone in the consortium. This greatly
>> reduces the chance of Nokia's lawyer suing.
> 
> 
> What makes you think that? I am not aware of a requirement on MPEG-LA
> to get involved in any lawsuit that involves a company suing somebody
> over a patent that is part of the H.264 pool.

   I didn't mean to say the _consortium_ has a legal obligation to get
involved in a lawsuit against one of their members -- but they do have
an incentive to do so.

   In fact, I suspect it's other _members_ of the consortium which
will pay their lawyers to get involved.

   My point was that suing one member of the consortium looks less
attractive when other members are likely to support each other.

> On the contrary: if you get sued over VP8, you will likely find that
> Google has an interest to support you.

   I sincerely hope they would -- but there is nothing to convince Nokia
lawyers not to file suit in the first place.

--
John Leslie 

From sdhesika@cisco.com  Thu Nov 14 12:54:37 2013
Return-Path: 
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 9270A11E810D for ; Thu, 14 Nov 2013 12:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 551Kz-3rjINM for ; Thu, 14 Nov 2013 12:54:32 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE0911E8133 for ; Thu, 14 Nov 2013 12:54:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4206; q=dns/txt; s=iport; t=1384462473; x=1385672073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/rLdVOi5RXN5jJFM7shz98dgFPIHBcokLVMCewXgkdA=; b=YXcY5que38Vb/aP8bT2euJOr//kSS3h1BQ2YRWEXxyBquLJCJej7NAzR ngk1KfdhxlMZ+VMrRtaZPRWx/MhqlqDOh2AcYsCmX+T4nl7VoKeJSuOfx CXZmsQ4ri+Zf9gsu4ZYQ6CXqUKA/9GCt5EydkiWguWgjj2XdKZqiwgLhF U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAMM3hVKtJV2b/2dsb2JhbABbgwc4U78dgSEWdIIlAQEBBDo/DAQCAQgRBAEBAQoLCQkHMhQJCAIEAQ0FCAESh2YNwFqOFhCBCDECBQYEgxaBEQOqHIMogXE5
X-IronPort-AV: E=Sophos;i="4.93,701,1378857600"; d="scan'208";a="281968984"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 14 Nov 2013 20:54:32 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAEKsV3K005459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 20:54:31 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.125]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 14:54:31 -0600
From: "Subha Dhesikan (sdhesika)" 
To: Gonzalo Camarillo , Ted Hardie 
Thread-Topic: [rtcweb] Protesting the QoS document decision
Thread-Index: AQHO4K4H0BNLMGJiikOjB/idNYrD5pokxT4AgACZZYCAABXuAIAADdAA//+nyBA=
Date: Thu, 14 Nov 2013 20:54:30 +0000
Message-ID: 
References: <5283DF61.9060807@alvestrand.no> <52848582.1070408@ericsson.com> <5285062F.9070204@mti-systems.com>  <5285242A.4050103@ericsson.com>
In-Reply-To: <5285242A.4050103@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.24.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "rai-ads@tools.ietf.org" , "tsv-ads@tools.ietf.org" 
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 20:54:37 -0000

Thanks Gonzalo.  I am sorry I am coming in late ...

- I was asked to move the document from RTCWEB to TSVWG and here is an emai=
l I posted to announce that it has moved in TSVWG.=20
http://www.ietf.org/mail-archive/web/tsvwg/current/msg11609.html
It seems like I did not post a similar thread to RTCWEB.  =20

- I am aware that there are concerns regarding the draft due to the bundlin=
g of flows.  I did not update the draft for Vancouver because I was looking=
 for the outcome or discussions regarding bundling in RTCWeb.  The update I=
 am looking to provide (but will have discussions with people who have expr=
essed this objection) is that this QoS draft will not get into bundling iss=
ues. The application will provide the priority, the suggestion of how to tr=
anslate them into the DSCP value  or other values will be the focus of the =
draft. =20
In the bundling discussion, Dan Drutta, co-author of this draft raised an i=
ssue that bundling should take priority into account. That viewpoint will c=
ontinued to be expressed but outside this draft.

- The other reason that this draft was not updated is because we were waiti=
ng on the priority tags to be defined from the application to the browser. =
This was done recently in W3C.=20

So, a new draft will go out by the end of the month. I would very much like=
 to understand why/how this draft has caused a dependency on implementation=
s. I am happy to work with other authors to remove any roadblocks this draf=
t is causing.

Regards,
Subha

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20
Sent: Thursday, November 14, 2013 11:28 AM
To: Ted Hardie
Cc: Wesley Eddy; Harald Alvestrand; rtcweb@ietf.org; rai-ads@tools.ietf.org=
; tsv-ads@tools.ietf.org; Subha Dhesikan (sdhesika)
Subject: Re: [rtcweb] Protesting the QoS document decision

Hi,

[adding Subha, the main author of the draft, to the cc:]

Subha intends to revise the draft before the end of this month. She will tr=
y and address the comments below from Wes.

Cheers,

Gonzalo

On 14/11/2013 8:38 PM, Ted Hardie wrote:
> On Thu, Nov 14, 2013 at 9:19 AM, Wesley Eddy  > wrote:
>=20
>     On 11/14/2013 3:10 AM, Gonzalo Camarillo wrote:
>     As for the current status, the document does not yet address
>     core issues that have been pointed out.  See, for instance:
>     http://www.ietf.org/mail-archive/web/tsvwg/current/msg12042.html
>=20
>     People interested should work on this in TSVWG.  There does not
>     seem to be any reason for RTCWEB to be gated on it, as it has zero
>     impact on interoperability or the protocol.  Having a normative
>     reference to it is not correct and is easy to fix.
>=20
>     --
>     Wes Eddy
>     MTI Systems
>=20
>=20
>=20
> Hi Wes,
>=20
> The issue raised isn't that there is an RTCWEB document gated on it,=20
> but that shipping code does require this to be resolved.  The message=20
> you point to above notes a core issue, which I assume is this:
>=20
> That said, I think the interesting facet of this document is that=20
> packets within the same flow (defined by 5-tuple of address-port pairs=20
> and protocol number) are receiving different codepoints, and the=20
> implications of that for a CC that may be on top of them need to be=20
> delved into.
>=20
>=20
> I think the authors may not have seen "interesting facet"=20
> as a clear enough signal that they were blocked on this. =20
> Can you restate this problem to them, so that they understand either=20
> where in the document they should raise the issue or where there is=20
> work they can reference for incorporation?
>=20
> You may want to include pointers on why having this situation,
>=20
> versus multiple flows going between the same end points in
>=20
> other contexts, is a problem.  I'm kind of concerned as well that they=20
> will take the simple solution (use the most stringent
>=20
> QoS), which is clear enough from a congestion control perspective
>=20
> but bad from other perspectives.
>=20
> regards,
>=20
>=20
> Ted
>=20


From randell-ietf@jesup.org  Thu Nov 14 13:54:58 2013
Return-Path: 
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 1B46C21E80BD for ; Thu, 14 Nov 2013 13:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.374
X-Spam-Level: 
X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225,  BAYES_00=-2.599]
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 E+ths-yaombJ for ; Thu, 14 Nov 2013 13:54:52 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 3E97B21E80B3 for ; Thu, 14 Nov 2013 13:54:52 -0800 (PST)
Received: from pool-173-59-53-40.phlapa.fios.verizon.net ([173.59.53.40]:1452 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Vh4sF-0008q8-6A for rtcweb@ietf.org; Thu, 14 Nov 2013 15:54:51 -0600
Message-ID: <52854666.9030700@jesup.org>
Date: Thu, 14 Nov 2013 16:53:42 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5282A340.7010405@gondwanaland.com> <5056AF7E-5C2C-4094-B77D-1BC52B792C03@apple.com> <55F043DB-3AF6-4A33-B504-F5B316273DDB@phonefromhere.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] where that h264 plugin can be used
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 21:54:58 -0000

On 11/13/2013 12:43 PM, Martin Thomson wrote:
> On 13 November 2013 02:34, Tim Panton  wrote:
>> 3) Cloud platforms:
> At least for the Microsoft cloud, I don't see this being an issue.
> It's pretty standard to have a setup step once an image is deployed.

I'm not an expert on AWS/etc, but I imagine predictable and fast startup 
of instances is important.  With a plugin download (even from Cisco), it 
would seem to be worrisome for a cloud service developer to rely on this 
completing "quickly" and not having an error *ever* - and they can't 
host it themselves.  I think Cisco would have to say that (at least) 
certain versions of the binary (warts, bugs and all) MUST remain 
available for immediate download .  And anything (lawsuit) 
that for any reason forced Cisco to even temporarily stop distributing 
it would be disaster for them; so I think they'd need to bite the bullet 
and sign a license - which has costs even if you stay under 100K (and 
you have to reliably count uses, etc).

Also, if they're encoding videos in H.264 and charging money to see them 
(or for a service that includes them, and this might include even an 
answering-system I'm-away video message), they wouldn't fall into the 
Cisco-paid cap category (perhaps; IANAPL).

-- 
Randell Jesup -- rjesup a t mozilla d o t com


From mzanaty@cisco.com  Thu Nov 14 14:16:35 2013
Return-Path: 
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 AAD6D21E80E2 for ; Thu, 14 Nov 2013 14:16:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.496
X-Spam-Level: 
X-Spam-Status: No, score=-10.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 q47j0hIdQRb7 for ; Thu, 14 Nov 2013 14:16:28 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3CD21E80D1 for ; Thu, 14 Nov 2013 14:16:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2654; q=dns/txt; s=iport; t=1384467383; x=1385676983; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TA6Jh0pTDLf+dbAfxDdy4jFjxtFGaIrCLHdjNqPlsfk=; b=ltqc6yf59xKVdQOw7qk7INIKMKIGTWGtSh65O8EXeELDtHAi7Bjt57aA lS4cAk3VFEWtQCDWIU3l6lOZxTz+nmvH8mAZLW53oZd+mz2MBvUsW2zP0 QcRh5mb6e4KmqPy9ewEKvDjg5sBnOSpsboa3gIqclaAgRsuXJQw2woGqG g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhUXAMVKhVKtJXHA/2dsb2JhbABbgwc4U75SS0FgFnSCJQEBAQMBAQEBawUGBQ0BCBhPBgslAgQBDQWHbwMJBg23AQ2JVQSMbYJyB4QxA4kKjRuBa4xUhTiDKIIq
X-IronPort-AV: E=Sophos;i="4.93,702,1378857600"; d="scan'208";a="282001388"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 14 Nov 2013 22:16:21 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAEMGLNn006747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 22:16:21 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 16:16:20 -0600
From: "Mo Zanaty (mzanaty)" 
To: John Leslie , Silvia Pfeiffer 
Thread-Topic: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
Thread-Index: AQHO4Ycl1Qdmxuo/mE2sPB/OuV9rNw==
Date: Thu, 14 Nov 2013 22:16:20 +0000
Message-ID: 
In-Reply-To: <20131114205355.GD13468@verdi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [10.150.30.48]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <4B2C9DB2B2BCBE4F9A536BF39C8E950F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 22:16:35 -0000

You don=B9t have to speculate. Motorola (now Google) sued Microsoft over
H.264 patents. No one intervened, so there is no obligation nor incentive
to do so. However, because this involved standards-essential patents, and
Motorola participated in the standards, it has FRAND obligations for those
SEPs, with a clear precedent for FRAND royalty rates established by MPEG
LA for that standard. The result was Microsoft has to pay half a cent in
royalties per product they ship containing an H.264 codec, but Motorola
must pay $15M for breaching SEP/FRAND obligations (by demanding $4B). If
Nokia sued anyone over H.264, a similar result is likely.

This is what people mean when they say H.264 IPR risk is low. Everyone
that participated in the standard is bound by SEP/FRAND obligations, and
can=B9t demand much more than they would get if they were licensors in the
MPEG LA pool. For all the hate MPEG LA gets, here is an example where its
existence actually limits the extent anyone can leverage patents to demand
unreasonable royalties.

VP8 does not yet offer such SEP/FRAND protection. If it infringes any
patent, the patent holder may demand unreasonable royalties (or even no
license terms, in the case of Nokia).

Mo


On 11/14/13, 3:53 PM, John Leslie  wrote:

Silvia Pfeiffer  wrote:
> On Thu, Nov 14, 2013 at 12:55 AM, John Leslie  wrote:
>>
>> Basically H.264 has quite a consortium to slap down the likes of
>> Nokia in court should they sue anyone in the consortium. This greatly
>> reduces the chance of Nokia's lawyer suing.
>=20
>=20
> What makes you think that? I am not aware of a requirement on MPEG-LA
> to get involved in any lawsuit that involves a company suing somebody
> over a patent that is part of the H.264 pool.

   I didn't mean to say the _consortium_ has a legal obligation to get
involved in a lawsuit against one of their members -- but they do have
an incentive to do so.

   In fact, I suspect it's other _members_ of the consortium which
will pay their lawyers to get involved.

   My point was that suing one member of the consortium looks less
attractive when other members are likely to support each other.

> On the contrary: if you get sued over VP8, you will likely find that
> Google has an interest to support you.

   I sincerely hope they would -- but there is nothing to convince Nokia
lawyers not to file suit in the first place.

--
John Leslie 
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


From gorry@erg.abdn.ac.uk  Thu Nov 14 14:12:01 2013
Return-Path: 
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 BCF8C11E80F2 for ; Thu, 14 Nov 2013 14:12:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.459
X-Spam-Level: 
X-Spam-Status: No, score=-106.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 BhY8Lc8pbkTr for ; Thu, 14 Nov 2013 14:11:57 -0800 (PST)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id B594611E8107 for ; Thu, 14 Nov 2013 14:11:49 -0800 (PST)
Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id B421A2B453B; Thu, 14 Nov 2013 22:11:48 +0000 (GMT)
Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id A5B0A2B43B3; Thu, 14 Nov 2013 22:11:42 +0000 (GMT)
Message-ID: <52854A9E.1010506@erg.abdn.ac.uk>
Date: Thu, 14 Nov 2013 22:11:42 +0000
From: Gorry Fairhurst 
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683. 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: James Polk ,  Harald Alvestrand 
References: <5283DF61.9060807@alvestrand.no> <201311132211.rADMBaBD011692@rcdn-core2-5.cisco.com> <52843288.5000507@alvestrand.no> <201311141931.rAEJVBn2004230@rcdn-core-3.cisco.com>
In-Reply-To: <201311141931.rAEJVBn2004230@rcdn-core-3.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 14 Nov 2013 14:29:07 -0800
Cc: rai-ads@tools.ietf.org, "Black, David" , "rtcweb@ietf.org" , tsv-ads@tools.ietf.org
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
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: Thu, 14 Nov 2013 22:12:01 -0000

We don't need to keep hearing from people how much they want this done - 
we need to hear from people who say they'll do this, or speak to people 
who understand the issues and get new text to go into this draft.

The draft was discussed at length in Berlin. Cullen presented to TSVWG - 
it received feedback, comments, and a request to address the comments on 
the list or in the draft. We followed-up with announcement to RMCAT in 
Berlin, and a tiny bit of feedback. Cullen who presented, also Chairs 
RMCAT - so surely can't be "hidden" from RMCAT?

In TSVWG, there was interest recorded in doing such work, and there's 
surely expertise to work on DSCP-related issues. However, I saw no 
discussion following Berlin on the list or responses from the authors, 
sorry. We did see need for various other things (SCTP-related) by RMCAT, 
and promptly adopted and also prioritized these.

I hoped there would be an updated draft - but there was no presentation 
requested and there had been no document update in response to the 
comments. IF Cullen had wanted to come back and say more (or anyone 
else) they could have done.

If people *are* interested - and people keep saying they are - then 
please listen to the feedback being given and either update the draft or 
propose another draft that addresses the comments. If the comments don't 
apply for some reason, then bring up the topic on the list. If the 
feedback isn't clear enough to act upon, and it may not be after time, 
we can surely help...

We're listening...

Gorry
(wearing TSVWG chair hat)



On 14/11/2013 19:31, James Polk wrote:
> At 08:16 PM 11/13/2013, Harald Alvestrand wrote:
>> On 11/13/2013 11:11 PM, James Polk wrote:
>> > I, speaking at the mic, was merely pointing out that this draft had
>> > moved to TSVWG back in the Atlanta timeframe (though, thinking back, I
>> > think I left the timing piece out of my comment), so it wasn't a
>> > recent decision. I believe this came directly from talks between the
>> > above mentioned ADs.
>>
>> This only reinforces my procedural comment. The fact that the decision,
>> and the reasons for it, has been hidden from the group for 8 (?) months
>> only makes it worse, not better.
>
> it was mentioned during the chair's review of RTCweb documents during
> the Orlando RTCweb meeting. I was there in the front row...
>
>
>> When ADs make decisions by talking among themselves, they have a special
>> duty to make sure those decisions are public and open to the community.
>> That duty has not been executed in this case.
>> I don't know who dropped the ball - the ADs or the chairs. But the ball
>> was definitely dropped.
>
> I think this was announced on the list, but was part of a larger email,
> and not the main topic (i.e., "subject" line)... making searching for it
> difficult at best.
>
>> > As for RTCweb work being more appropriately inside the RTBweb WG
>> > instead of another group, I'd like to point out that much of the SDP
>> > work related to this WG is in fact being done in MMUSIC. Much of the
>> > RTP work being done by this WG is being done in AVTCORE (or AVTEXT?).
>> > All of the base SCTP work being done by this WG is being done in TSVWG.
>>
>> I have issues with those too. Especially the speed at which they're
>> progressing. But those decisions were made and announced in a timely
>> fashion.
>
> I figured this was part of the problem, and have nothing good to add here.
>
>
>> The argument that has been used is that the pieces we need defined
>> (BUNDLE, MSID, circuit-breakers, RMCAT) have general applicability, and
>> should therefore be processed by groups that are chartered to define
>> extensions with general applicability.
>
> it was RMCAT (also in Transport) that was the main interaction from my
> pov, and I think from the TSVWG chairs pov, as RMCAT's chairs said to
> TSVWG (paraphrasing) "we don't think we're going to need anything new or
> existing work wrt DiffServ to solve RMCAT's solution". This effective
> told the TSVWG chairs they could table/postpone/whatever the DiffServ
> draft from RTCweb until RMCAT was through deciding which solution they
> were going to go with. I think, perhaps, the TSVWG chairs (me included)
> thought there was more of a direct link between RMCAT and RTCweb than
> there really was. If there was, and we were talking past each other,
> then  apologize, as I clearly didn't get that memo.
>
>
>> >
>> > (this is not an attack, but...)
>> >
>> > ...why are you arguing for something as far away down the stack as
>> > DSCP assignments to be done in RTCweb, and not where all other
>> > DiffServ work is being done in the IETF (in TSVWG)? Do you not trust
>> > that TSVWG will do an appropriate just with a DiffServ ID but you will
>> > trust TSVWG with SCTP IDs?
>>
>> My understanding of the QoS draft has always been that it should define
>> no new codepoints.
>
> It shouldn't and doesn't, it's merely a profile doc for RTCweb (said as
> an author and as a TSVWG chair).
>
>> It should point out the language we need to translate
>> RTCWEB requirements ("audio should go faster than video, except when the
>> app says that it should be the other way around") into already-defined
>> DSCP code points.
>
> that's my understanding (of the requirements) too
>
>
>> I have not seen anyone arguing for new DSCP codepoints
>
> nor should they have
>
>> , so I really
>> wonder what work there is for TSVWG to do.
>
> to make sure that no one specifies anything stupid in the profile.
>
> What RTCweb doesn't know, except for Magnus and Colin, is that TSVWG is
> in the process of bis-ing our DiffServ guidelines RFC (4594). We've
> reached WG consensus on most of the proposed changes, by the
> author/editor has a couple of changes he hasn't reach WG consensus with/on.
>
>
>> Again, the arguments may be there, but since they were never exposed to
>> the mailing list, I cannot evaluate them.
>
> "never" is, I think, not true.
>
> I'll give you 'announced along with 50m other things in RTCweb (buried
> in the background noise) ...
>
>
>> >
>> > Color me confused...
>> >
>> > James
>> >
>> > BTW - Full disclosure, I'm an listed author of this draft, but had no
>> > voice in it getting moved between the WGs.
>>
>> My biggest practical issue with this draft is that it's functionally
>> dead.
>
> see above for the confusion
>
>> I'm getting put in a place where I have to either delay shipping
>> this feature in product or ship without even the guidance of a live
>> draft.
>
> I can certainly appreciate that
>
>
>> I want this group to be done. As long as I can't even point to the
>> document that describes how we do QoS, I have no chance of getting it to
>> that stage.
>
> again, I can certainly appreciate that
>
> James
>
>
>
>> >
>> > At 02:21 PM 11/13/2013, Harald Alvestrand wrote:
>> >> This mail concerns both administrative and technical issues, which is
>> >> why it is explicitly copied to the ADs of RAI and TSV. I hope I have
>> >> managed to keep them separate in the message.
>> >>
>> >> Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:
>> >>
>> >> > Okay, we might not have been public enough on this. It was
>> >> requested by
>> >> > the Transport ADs quite some time ago that doing the QoS document
>> >> in our
>> >> > WG was not appropriate and requested us to direct the document to
>> >> TSVWG.
>> >> > Which was done, and where it hasn't made progress.
>> >> >
>> >> > You might have noted that James Polk did comment in the milestone
>> part
>> >> > in the monday session of IETF88 about our QoS milestone should be
>> >> killed.
>> >> I want to protest this - both practically and formally.
>> >>
>> >> To get the formal stuff out of the way first:
>> >>
>> >> Changing the deliverables of the working group *without telling the
>> >> working group* is totally inappropriate in an open, consensus-driven
>> >> process.
>> >> Changing the deliverables of the working group *without telling the
>> >> working group why* and *without allowing those reasons to be
>> debated* is
>> >> totally inappropriate in an open, consensus-driven process.
>> >>
>> >> I protest against this action.
>> >>
>> >> ACTION REQUEST 1: I request that this decision be declared null and
>> >> void, and that the relevant ADs send out a message to RTCWEB (and
>> TSVWG
>> >> if appropriate) *PROPOSING* such an action, and giving a reasonable
>> >> timeline for when they will make a decision based on mailing list
>> >> feedback.
>> >>
>> >> In practice:
>> >>
>> >> The draft as it existed before its untimely demise consisted of two
>> >> things:
>> >>
>> >> - A description of how QoS mechanisms could be useful in the RTCWEB
>> >> use case
>> >> - A description of existing mechanisms that could be appropriate
>> for the
>> >> RTCWEB use case
>> >>
>> >> The first one is clearly something that needs RTCWEB consensus. It
>> seems
>> >> to have no need for, nor likelyhood of gathering interest enough
>> for, a
>> >> TSVWG consensus.
>> >>
>> >> There could be some argument that the second part needs TSVWG
>> consensus,
>> >> especially if it was redefining any mechanisms, or it was making
>> choices
>> >> between mechanisms where TSVWG had strong opinions about which
>> >> mechanisms should be chosen, but had not chosen to document that in
>> any
>> >> document on which IETF consensus had been declared (that is to say,
>> >> existing RFCs).
>> >>
>> >> My archive shows 36 messages where the title refers to this draft. It
>> >> shows no messages declaring that feedback has been incorporated and
>> >> calling for new review - something that is usually necessary to get
>> a WG
>> >> consensus on any document. The debate hasn't been conclusive, but
>> then,
>> >> it hasn't been pushed hard either.
>> >>
>> >> The people who know how RTCWEB works are in this working group.
>> Some of
>> >> them may be in TSV, but I think the locus of knowledge for saying what
>> >> QoS mechanisms are appropriate for RTCWEB are here, not in TSV.
>> >>
>> >> This results in my second request.
>> >>
>> >> ACTION REQUEST 2: I request that the chairs declare that based on the
>> >> debate about the QoS functionality so far, the document should be
>> >> resurrected, and will continue to be  worked on in the RTCWEB working
>> >> group, bringing in advice from TSVWG as required to make sure the
>> >> descriptions of underlying mechanisms, and the choice of such
>> >> mechanisms, is correct and appropriate.
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Surveillance is pervasive. Go Dark.
>> >>
>> >> _______________________________________________
>> >> rtcweb mailing list
>> >> rtcweb@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>>
>>
>> --
>> Surveillance is pervasive. Go Dark.
>


From ron@debian.org  Thu Nov 14 15:09:46 2013
Return-Path: 
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 C676A21E80EC for ; Thu, 14 Nov 2013 15:09:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
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 i0SiXR-l5Mpc for ; Thu, 14 Nov 2013 15:09:40 -0800 (PST)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 70A8121E80B3 for ; Thu, 14 Nov 2013 15:09:30 -0800 (PST)
Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Nov 2013 09:39:30 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 3664F4F8F3 for ; Fri, 15 Nov 2013 09:26:35 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uYdyefMU0aRN for ; Fri, 15 Nov 2013 09:26:33 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 4BD424F902; Fri, 15 Nov 2013 09:26:33 +1030 (CST)
Date: Fri, 15 Nov 2013 09:26:33 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20131114225633.GR3245@audi.shelbyville.oz>
References: <20131114205355.GD13468@verdi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 23:09:46 -0000

On Thu, Nov 14, 2013 at 10:16:20PM +0000, Mo Zanaty (mzanaty) wrote:
> You don¹t have to speculate. Motorola (now Google) sued Microsoft over
> H.264 patents. No one intervened, so there is no obligation nor incentive
> to do so. However, because this involved standards-essential patents, and
> Motorola participated in the standards, it has FRAND obligations for those
> SEPs, with a clear precedent for FRAND royalty rates established by MPEG
> LA for that standard. The result was Microsoft has to pay half a cent in
> royalties per product they ship containing an H.264 codec, but Motorola
> must pay $15M for breaching SEP/FRAND obligations (by demanding $4B). If
> Nokia sued anyone over H.264, a similar result is likely.

Except the proposed Cisco binary deal isn't licencing the Nokia patents,
or the Motorola patents, or any others, so they'd all still be free to
sue anyone using that.

How is this known and proven liability somehow less of a problem than the
absence of any such thing overshadowing VP8?

If we're giving credit to MPEG LA, we can also credit them for trying very
hard, and failing, to create a pool that reads on VP8.


If people are going to stand on that FUD, maybe a 25 year old codec is
the best answer here after all.

  Ron



From adam@nostrum.com  Thu Nov 14 15:17:00 2013
Return-Path: 
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 B010321E809F for ; Thu, 14 Nov 2013 15:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.517
X-Spam-Level: 
X-Spam-Status: No, score=-101.517 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, MISSING_HEADERS=1.292, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 mNzQ0Ay3rYht for ; Thu, 14 Nov 2013 15:16:58 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9070711E8112 for ; Thu, 14 Nov 2013 15:16:54 -0800 (PST)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAENGrfU051050 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 14 Nov 2013 17:16:53 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <528559E4.3020903@nostrum.com>
Date: Thu, 14 Nov 2013 17:16:52 -0600
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
CC: "rtcweb@ietf.org" 
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>	 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050603090208050009030701"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 23:17:00 -0000

This is a multi-part message in MIME format.
--------------050603090208050009030701
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

I sent a reply to this earlier, but just now realized that it went only 
to Justin, not to the list.


On 11/14/13 13:59, Justin Uberti wrote:
> Thanks, this is interesting. Is the ffmpeg 261 encoder limited to 
> CIF/QCIF, or can you specify arbitrary sizes?

It looks like the ffmpeg mpeg-1 coder works for arbitrary sizes. I'm not 
sure what the difference between mpeg-1 and H.261 are, though, so we 
could be talking apples and oranges (or at least apples and pears) here. 
I'll note that mpeg-1 came out in 1991, which is a good 22 years in the 
past. I'm not drawing IPR conclusions for you, but invite you to ponder 
the implications yourself.

Following Maik's lead with the mpeg-1 js decoder, I put this together:

https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html

...with this commandline:

   ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp rd -subcmp 
rd -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k maven.mpg

I don't really understand most of those options (I just cribbed them 
from Maik's example) or whether any of them would introduce more latency 
than is reasonable for a real-time conversation, but I will observe:

 1. The encoder claims that it was performing on the order of 90 - 100
    fps on my (admittedly modern) system;
 2. The resolution is 640x360 (somewhat larger than DCIF);
 3. The video is not, to my eye, unusable (draw your own conclusions, as
    it's clearly not as nice as modern codecs);
 4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works
    out to 508 kbits/second total.


Source video here, and NASA is acknowledged as the source of the 
material contained therein: http://www.youtube.com/watch?v=ijAO0FFExx0

/a


--------------050603090208050009030701
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    I sent a reply to this earlier, but just now realized that it went
    only to Justin, not to the list.

    

    

    

      
On 11/14/13 13:59, Justin Uberti
        wrote:

      

      

        
Thanks, this is interesting. Is the ffmpeg 261
          encoder limited to CIF/QCIF, or can you specify arbitrary
          sizes?

      

      

      It looks like the ffmpeg mpeg-1 coder works for arbitrary sizes.
      I'm not sure what the difference between mpeg-1 and H.261 are,
      though, so we could be talking apples and oranges (or at least
      apples and pears) here. I'll note that mpeg-1 came out in 1991,
      which is a good 22 years in the past. I'm not drawing IPR
      conclusions for you, but invite you to ponder the implications
      yourself.

      

      Following Maik's lead with the mpeg-1 js decoder, I put this
      together:

      

      https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html

      

      ...with this commandline:

      

        ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp rd
      -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k
      maven.mpg

      

      I don't really understand most of those options (I just cribbed
      them from Maik's example) or whether any of them would introduce
      more latency than is reasonable for a real-time conversation, but
      I will observe:

      
    
        
  1. The encoder claims that it was performing on the order of 90
          - 100 fps on my (admittedly modern) system;
    
        
    2. 
        
  2. The resolution is 640x360 (somewhat larger than DCIF);
    3. 
        
  3. The video is not, to my eye, unusable (draw your own
          conclusions, as it's clearly not as nice as modern codecs);
    
        
    4. 
        
  4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
          encoding works out to 508 kbits/second total.
    5. 
      

      


      

      Source video here, and NASA is acknowledged as the source of the
      material contained therein:
      http://www.youtube.com/watch?v=ijAO0FFExx0

      

      /a

    

    

  


--------------050603090208050009030701--

From adam@nostrum.com  Thu Nov 14 15:22:31 2013
Return-Path: 
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 0D75111E8123 for ; Thu, 14 Nov 2013 15:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.445
X-Spam-Level: 
X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 U9s0HzagPKb4 for ; Thu, 14 Nov 2013 15:22:30 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB5011E8112 for ; Thu, 14 Nov 2013 15:22:30 -0800 (PST)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAENMT8b051256 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 14 Nov 2013 17:22:29 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <52855B35.3080605@nostrum.com>
Date: Thu, 14 Nov 2013 17:22:29 -0600
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>	  <528559E4.3020903@nostrum.com>
In-Reply-To: <528559E4.3020903@nostrum.com>
Content-Type: multipart/alternative; boundary="------------010208090601090700030205"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Thu, 14 Nov 2013 23:22:31 -0000

This is a multi-part message in MIME format.
--------------010208090601090700030205
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 11/14/13 17:16, Adam Roach wrote:
> # At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works 
> out to 508 kbits/second total.

Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime 
seems to divide it by two for some reason, although the javascript 
decode does the right thing). This works out to 254 kbps.

/a

--------------010208090601090700030205
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 11/14/13 17:16, Adam Roach wrote:

    

    

      
  • At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding
        works out to 508 kbits/second total.
    • 
    
    
    
    
    Whoops, I messed up my math. It's 148 seconds long, not 74
    (Quicktime seems to divide it by two for some reason, although the
    javascript decode does the right thing). This works out to 254 kbps.
    
    
    
    /a
    
  


--------------010208090601090700030205--

From stewe@stewe.org  Thu Nov 14 17:38:01 2013
Return-Path: 
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 9DC7A21E80FB for ; Thu, 14 Nov 2013 17:38:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.197
X-Spam-Level: 
X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.401,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 6fO69v5v4qZJ for ; Thu, 14 Nov 2013 17:37:55 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB1321E80F5 for ; Thu, 14 Nov 2013 17:37:55 -0800 (PST)
Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 15 Nov 2013 01:37:47 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.167]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.208]) with mapi id 15.00.0785.001; Fri, 15 Nov 2013 01:37:47 +0000
From: Stephan Wenger 
To: Adam Roach , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] H261/MPEG-1 video quality
Thread-Index: AQHO4ZBo/cp8alr3tUycNfSA10qUd5ok/UYA
Date: Fri, 15 Nov 2013 01:37:46 +0000
Message-ID: 
In-Reply-To: <52855B35.3080605@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [24.5.171.95]
x-forefront-prvs: 0031A0FFAF
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(24454002)(479174003)(51856001)(63696002)(85306002)(54356001)(66066001)(53806001)(83072001)(16236675002)(59766001)(76482001)(77982001)(54316002)(76176001)(56776001)(36756003)(69226001)(74706001)(2656002)(31966008)(19580395003)(47446002)(74662001)(74876001)(74366001)(83322001)(74502001)(19580405001)(87936001)(87266001)(4396001)(81542001)(81342001)(65816001)(46102001)(80022001)(81816001)(79102001)(56816003)(77096001)(81686001)(76786001)(76796001)(47736001)(49866001)(47976001)(50986001)(80976001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:24.5.171.95; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_CEAAB858AA2AFstewesteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 01:38:01 -0000

--_000_CEAAB858AA2AFstewesteweorg_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Folks,
Please don't consider H.261 and MPEG-1 part 2 as being in the same league i=
n terms of coding efficiency or network friendliness.  They clearly are not=
.
H.261 is what many call the first generation video coding standard.  MPEG-1=
 (and MPEG-2) are second generation.
MPEG-1 has half-pel motion compensation.  H.261 has not.
MPEG-1 has B frames.  H.261 has not.
MPEG-1 has (arbitrary sized) slices that can be used for MTU size matching =
(although they are not commonly used for that purpose).  H.261 has not.  In=
stead, H.261 has the Group Of Block picture segmentation mechanism, that is=
 clearly more optimized for parallel processing than for MTU size matching.
MPEG-1 allows for significantly larger motion vectors (necessitated by B fr=
ames and the resulting longer prediction interval, but can be used even in =
P frame only coding).
MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF, and 4CIF (in "=
still image" mode, designed for low frame rate application; could run at hi=
gh frame rate though).
H.261 was ratified (in its first version) in 1988, and in the for all pract=
ical purposes final version in 1989.  Most people believe that all related =
patents have expired.
MPEG-1 was ratified in late 1992.  Its "bug fix" successor MPEG-2 (which ad=
ds interlace support) was ratified less than a year later.  There are at le=
ast two major disputes going on today regarding technology allegedly infrin=
ged by a compliant implementation of MPEG-2.  Based on my technical underst=
anding, one of these technologies is not in any way related to interlaced.
Draw your own conclusions.
Regards,
Stephan




From: Adam Roach >
Date: Thursday, 14 November, 2013 at 15:22
To: "rtcweb@ietf.org" >
Subject: Re: [rtcweb] H261/MPEG-1 video quality

On 11/14/13 17:16, Adam Roach wrote:
  *   At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works =
out to 508 kbits/second total.

Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime seems=
 to divide it by two for some reason, although the javascript decode does t=
he right thing). This works out to 254 kbps.

/a

--_000_CEAAB858AA2AFstewesteweorg_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <7005A8F46D3BD7458182B6AC7E5FFDC0@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







    Folks,
    

    Please don’t consider H.261 and MPEG-1 part 2 as being in the sa=
me league in terms of coding efficiency or network friendliness.  They=
 clearly are not.
    

    H.261 is what many call the first generation video coding standard. &n=
bsp;MPEG-1 (and MPEG-2) are second generation.
    

    MPEG-1 has half-pel motion compensation.  H.261 has not.
    

    MPEG-1 has B frames.  H.261 has not.
    

    MPEG-1 has (arbitrary sized) slices that can be used for MTU size matc=
hing (although they are not commonly used for that purpose).  H.261 ha=
s not.  Instead, H.261 has the Group Of Block picture segmentation mec=
hanism, that is clearly more optimized for
 parallel processing than for MTU size matching.
    

    MPEG-1 allows for significantly larger motion vectors (necessitated by=
 B frames and the resulting longer prediction interval, but can be used eve=
n in P frame only coding).
    

    MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF, and =
4CIF (in “still image” mode, designed for low frame rate applic=
ation; could run at high frame rate though).
    

    H.261 was ratified (in its first version) in 1988, and in the for all =
practical purposes final version in 1989.  Most people believe that al=
l related patents have expired.
    

    MPEG-1 was ratified in late 1992.  Its “bug fix” succ=
essor MPEG-2 (which adds interlace support) was ratified less than a year l=
ater.  There are at least two major disputes going on today regarding =
technology allegedly infringed by a compliant implementation
 of MPEG-2.  Based on my technical understanding, one of these technol=
ogies is not in any way related to interlaced.  
    

    Draw your own conclusions.
    

    Regards,
    

    Stephan
    


    

    


    

    


    

    


    

    


    
From: Adam Roach <adam@nostrum.com>
    
Date: Thursday, 14 November, 2013 a=
t 15:22 
    
To: "rtcweb@ietf.org" <=
rtcweb@ietf.org>
    
Subject: Re: [rtcweb] H261/MPEG-1 v=
ideo quality
    

    


    

    

    

    

    On 11/14/13 17:16, Adam Roach wrote:
    

    

    

  • At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works ou=
t to 508 kbits/second total.

    • 

    
Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime seems=
 to divide it by two for some reason, although the javascript decode does t=
he right thing). This works out to 254 kbps.
    

    
/a
    

    

    
    



--_000_CEAAB858AA2AFstewesteweorg_--

From singer@apple.com  Thu Nov 14 18:26:15 2013
Return-Path: 
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 7BE3911E8169 for ; Thu, 14 Nov 2013 18:26:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level: 
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 m5He0z5wXmcI for ; Thu, 14 Nov 2013 18:26:10 -0800 (PST)
Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) by ietfa.amsl.com (Postfix) with ESMTP id A997711E8167 for ; Thu, 14 Nov 2013 18:26:06 -0800 (PST)
Received: from relay3.asia.apple.com ( [17.82.200.17]) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id B3.0F.21841.A9285825; Fri, 15 Nov 2013 10:10:34 +0800 (MYT)
X-AuditID: 1152fe11-b7f256d000005551-98-5285829aa011
Received: from sng-mmpp-sz01.asia.apple.com ( [17.82.200.58]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id D7.90.26194.A9285825; Fri, 15 Nov 2013 10:10:34 +0800 (MYT)
Received: from [17.85.192.135] (unknown [17.85.192.135]) by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MWA00KOX8PK6W20@sng-mmpp-sz01.asia.apple.com> for rtcweb@ietf.org; Fri, 15 Nov 2013 10:10:34 +0800 (SGT)
Content-type: text/plain; charset=windows-1252
MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: David Singer 
In-reply-to: 
Date: Fri, 15 Nov 2013 10:10:32 +0800
Content-transfer-encoding: quoted-printable
Message-id: <4A450D6F-603B-4A9D-9C1F-531D176F465A@apple.com>
References:  
To: Jonathan Rosenberg 
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUiGHRCUHdWU2uQweyDShZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr40/bJLaC18IVf24+ZW1gfMvfxcjJISFgInF55RMWCFtM4sK9 9WxdjFwcQgK7GSX6pkxmhylaue0EI0RiMpPEgf93oaq2MEnMnLWAqYuRg4NZQE/i/kUtkAZe IHPn3m2sIGFhAUuJC8dNQMJsAqoSD+YcYwQJcwoESyw5WgoSZgEKb3m1jRHEZhYIkbjc/oYJ wtaWePLuAivERBuJY6/vs0JsncYocaN5KTNIQkRAR2Lr3SOMEHfKSpw+95wFpEhC4COrxJxN 7xgnMArPQrhuFpLrZiHZsYCReRWjeG5iZo5uZp6hXmJxZqJeYkFBTqpecn7uJkZwOP8T3ME4 daHhIUYBDkYlHt69P1uChFgTy4orcw8xSnAwK4nwPktoDRLiTUmsrEotyo8vKs1JLT7EKM3B oiTOK5pSGyQkkJ5YkpqdmlqQWgSTZeLglGpgLHDfram9Sf6AbKOFcj7HlS/vvb/f+avpY/Pi 4tbbl/6v2it2VWfGO8PFh82al5bd9F5e361RzZzcUjEhc1FdUferm0HTdX/cePs5nc/0ZM6i g6Fb5t2a+3zuac9GtTzZQz0hs3evf/I+5Mst0ccsVn9P8q2ICftsKS+yytZLt/XlmaOc66Md NJRYijMSDbWYi4oTAW3OPjVjAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUiGHTCSndWU2uQweI98hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr40/bJLaC18IVf24+ZW1gfMvfxcjJISFgIrFy2wlGCFtM4sK9 9WxdjFwcQgKTmSQO/L8L5Wxhkpg5awFTFyMHB7OAnsT9i1ogDbxA5s6921hBwsIClhIXjpuA hNkEVCUezDnGCBLmFAiWWHK0FCTMAhTe8mob2CpmgRCJy+1vmCBsbYkn7y6wQky0kTj2+j4r xNZpjBI3mpcygyREBHQktt49AnWnrMTpc89ZJjAKzEI4aBaSg2YhGbuAkXkVo2hRak5ipbFe YnFmol5iQUFOql5yfu4mRkj4Ce5g/DDV8BCjAAejEg9v3P3aICHWxLLiytxDjBIczEoivM8S WoOEeFMSK6tSi/Lji0pzUosPMUpzsCiJ86akAFULpCeWpGanphakFsFkmTg4pRoYvQ44X1QI D+9zrhD3fvww5pH+7r7ZPlZ79wQu2ygdt6cw+Hb3m2xzX7dvtVIZszZlVzBknV603tZV+Oxd 5kXfjMJ/PbzYOTsxbe3ndkZfp3/X2qbwmTEo3O57PWWrq9CTL3O2nJ//5M5V79+71zPyiTCI MN4VYt7UysaZaBHXrFGwQNGlUGefEktxRqKhFnNRcSIAtMfMEzsCAAA=
Cc: Jeremy Fuller , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 02:26:15 -0000

On Nov 14, 2013, at 23:57 , Jonathan Rosenberg  =
wrote:

> I agree with others that SHOULD implement both, or other variations on =
SHOULD, are not helpful. They will anyway be ignored and amount to more =
or less the no-interop situation we're in if we continue on the current =
path and have no consensus.  No consensus means the various players =
doing as they prefer, which is what they'd do if there is a SHOULD.

I don't agree.  I think that MUST implement at least one of them, and =
SHOULD do both, provides both clear guidance as to the interop points, =
and clear pressure to implement both.  I think it's as close to interop =
as we are likely to get. =20

I have no idea why browsers should be singled out for special pain, nor =
whether that is remotely reasonable, nor whether there is a good =
definition of one (look at the places where projects such as webkit are =
embedded, for example).


>=20
>=20
> On Thu, Nov 14, 2013 at 6:37 AM, Jeremy Fuller =
 wrote:
> Hi,
> =20
> Gaining IETF consensus on making it mandatory to support only H.264 or =
only VP8 has clearly failed. I would welcome anyone to share their =
thoughts on why they believe this situation will change anytime in the =
next few years.  Therefore, can I suggest that we remove items 1 and 2 =
from the list. Hopefully this will speed up the process by focusing =
efforts towards gaining agreement on one of the remaining options.
> =20
> The following alternatives has been proposed:
> 	=95 All entities MUST support H.264
> 	=95 All entities MUST support VP8
> 	=95 All entities MUST support both H.264 and VP8
> 	=95 Browsers MUST support both H.264 and VP8, other entities =
MUST support at least one of H.264 and VP8
> 	=95 All entities MUST support at least one of H.264 and VP8
> 	=95 All entities MUST support H.261
> 	=95 There is no MTI video codec
> 	=95 All entities MUST support H.261 and all entities MUST =
support at least one of H.264 and VP8
> Regards,
> Jeremy Fuller
> =20
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
>=20
>=20
>=20
> --=20
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

David Singer
Multimedia and Software Standards, Apple Inc.


From mzanaty@cisco.com  Thu Nov 14 20:46:52 2013
Return-Path: 
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 B08A811E8181 for ; Thu, 14 Nov 2013 20:46:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.204
X-Spam-Level: 
X-Spam-Status: No, score=-5.204 tagged_above=-999 required=5 tests=[MIME_BASE64_TEXT=2.796, RCVD_IN_DNSWL_HI=-8]
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 iveoOfQ33b3F for ; Thu, 14 Nov 2013 20:46:43 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0169A11E813B for ; Thu, 14 Nov 2013 20:46:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3064; q=dns/txt; s=iport; t=1384490801; x=1385700401; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=/WVlSspy68yULqRSLT82BZzScVpD82mSjU8+C/oj8bM=; b=EvSqvBsC84QDR7kXkZWPnd8m+Iaw1UKj5K0jqIzwE/Db+n9wh1BIqV5J HiwFLeDbdFu/i+M/ZAyzgU2nSBJPoWAKA+aXIHdlWl1TlJ/+NLPWkc4ow 5L4Bmv+7WBSZKfH2tES6wBlmvMssNp65lmeqVOHdyZDCoHDzvINFCdBb+ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuAZAJ6mhVKtJXG//2dsb2JhbAA/GoMHOFOCdrwpGClhFnSCJQEBAQMBNBM3DQEIGAQoBDAlAgQBEod7Bg02kXWbVgaEEY5AgSOODBgigmWBTAOYEJIMgyh5gTE
X-IronPort-AV: E=Sophos;i="4.93,704,1378857600"; d="scan'208";a="285109526"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 15 Nov 2013 04:46:40 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAF4keMR020246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 04:46:40 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 22:46:40 -0600
From: "Mo Zanaty (mzanaty)" 
To: Ron , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
Thread-Index: AQHO4b2s7s1CjEdztke8hr5q2lUVJw==
Date: Fri, 15 Nov 2013 04:46:39 +0000
Message-ID: 
In-Reply-To: <20131114225633.GR3245@audi.shelbyville.oz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [10.82.214.97]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <37BE720F2C3E8B4B99FEE5F003758AB6@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 04:46:52 -0000

T24gMTEvMTQvMTMsIDU6NTYgUE0sIFJvbiA8cm9uQGRlYmlhbi5vcmc+IHdyb3RlOg0KT24gVGh1
LCBOb3YgMTQsIDIwMTMgYXQgMTA6MTY6MjBQTSArMDAwMCwgTW8gWmFuYXR5IChtemFuYXR5KSB3
cm90ZToNCj4gWW91IGRvbqn2dCBoYXZlIHRvIHNwZWN1bGF0ZS4gTW90b3JvbGEgKG5vdyBHb29n
bGUpIHN1ZWQgTWljcm9zb2Z0IG92ZXINCj4gSC4yNjQgcGF0ZW50cy4gTm8gb25lIGludGVydmVu
ZWQsIHNvIHRoZXJlIGlzIG5vIG9ibGlnYXRpb24gbm9yIGluY2VudGl2ZQ0KPiB0byBkbyBzby4g
SG93ZXZlciwgYmVjYXVzZSB0aGlzIGludm9sdmVkIHN0YW5kYXJkcy1lc3NlbnRpYWwgcGF0ZW50
cywgYW5kDQo+IE1vdG9yb2xhIHBhcnRpY2lwYXRlZCBpbiB0aGUgc3RhbmRhcmRzLCBpdCBoYXMg
RlJBTkQgb2JsaWdhdGlvbnMgZm9yDQo+dGhvc2UNCj4gU0VQcywgd2l0aCBhIGNsZWFyIHByZWNl
ZGVudCBmb3IgRlJBTkQgcm95YWx0eSByYXRlcyBlc3RhYmxpc2hlZCBieSBNUEVHDQo+IExBIGZv
ciB0aGF0IHN0YW5kYXJkLiBUaGUgcmVzdWx0IHdhcyBNaWNyb3NvZnQgaGFzIHRvIHBheSBoYWxm
IGEgY2VudCBpbg0KPiByb3lhbHRpZXMgcGVyIHByb2R1Y3QgdGhleSBzaGlwIGNvbnRhaW5pbmcg
YW4gSC4yNjQgY29kZWMsIGJ1dCBNb3Rvcm9sYQ0KPiBtdXN0IHBheSAkMTVNIGZvciBicmVhY2hp
bmcgU0VQL0ZSQU5EIG9ibGlnYXRpb25zIChieSBkZW1hbmRpbmcgJDRCKS4gSWYNCj4gTm9raWEg
c3VlZCBhbnlvbmUgb3ZlciBILjI2NCwgYSBzaW1pbGFyIHJlc3VsdCBpcyBsaWtlbHkuDQoNCj4g
RXhjZXB0IHRoZSBwcm9wb3NlZCBDaXNjbyBiaW5hcnkgZGVhbCBpc24ndCBsaWNlbmNpbmcgdGhl
IE5va2lhIHBhdGVudHMsDQpvciB0aGUgTW90b3JvbGEgcGF0ZW50cywgb3IgYW55IG90aGVycywg
c28gdGhleSdkIGFsbCBzdGlsbCBiZSBmcmVlIHRvDQpzdWUgYW55b25lIHVzaW5nIHRoYXQuDQoN
Ck5vIGxpY2Vuc29yIC8gbGljZW5zZWUgaW4gdGhlIE1QRUcgTEEgcG9vbCBjYW4gc3VlIGFueW9u
ZSBvdmVyIEguMjY0Lg0KR29vZ2xlIGlzIGEgbGljZW5zZWUsIHNvIE1vdG9yb2xhIGNhbiBubyBs
b25nZXIgc3VlIGFueW9uZSBvdmVyIEguMjY0Lg0KTm9raWEgKGxpa2UgdGhlIG9sZCBNb3Rvcm9s
YSkgaXMgbmVpdGhlciBhIGxpY2Vuc29yIG5vciBsaWNlbnNlZSwgc28gaXQNCmNhbiBzdWUuDQpC
dXQgTm9raWEgaGFzIEZSQU5EIG9ibGlnYXRpb25zIGZvciBILjI2NCBzaW5jZSBpdCBwYXJ0aWNp
cGF0ZWQgaW4gdGhlDQpzdGFuZGFyZCwNCndoaWxlIGl0IGhhcyBubyBzdWNoIG9ibGlnYXRpb25z
IGZvciBWUDguIElmIGl0IHN1ZXMgb3ZlciBILjI2NCwgaXQgbGlrZWx5DQpjYW6hr3QgZ2V0DQpt
b3JlIHRoYW4gaGFsZiBhIGNlbnQgbGlrZSBNb3Rvcm9sYS4gSWYgaXQgc3VlcyBvdmVyIFZQOCwg
YW5kIHdpbnMsIGl0IGNhbg0KZ2V0DQphIHBlcm1hbmVudCBpbmp1bmN0aW9uLg0KDQo+IEhvdyBp
cyB0aGlzIGtub3duIGFuZCBwcm92ZW4gbGlhYmlsaXR5IHNvbWVob3cgbGVzcyBvZiBhIHByb2Js
ZW0gdGhhbiB0aGUNCmFic2VuY2Ugb2YgYW55IHN1Y2ggdGhpbmcgb3ZlcnNoYWRvd2luZyBWUDg/
DQoNCkhhbGYgYSBjZW50IGlzIGxlc3Mgb2YgYSBwcm9ibGVtIHRoYW4gYSBwZXJtYW5lbnQgaW5q
dW5jdGlvbi4NCg0KPiBJZiB3ZSdyZSBnaXZpbmcgY3JlZGl0IHRvIE1QRUcgTEEsIHdlIGNhbiBh
bHNvIGNyZWRpdCB0aGVtIGZvciB0cnlpbmcNCj52ZXJ5DQpoYXJkLCBhbmQgZmFpbGluZywgdG8g
Y3JlYXRlIGEgcG9vbCB0aGF0IHJlYWRzIG9uIFZQOC4NCg0KSSBuZXZlciBzYWlkIGl0IGRlc2Vy
dmVzIGNyZWRpdCwganVzdCB0aGF0IGluIG9uZSBjYXNlIGl0IHByZXZlbnRlZA0KdW5yZWFzb25h
YmxlIHJveWFsdGllcy4NCg0KPiBJZiBwZW9wbGUgYXJlIGdvaW5nIHRvIHN0YW5kIG9uIHRoYXQg
RlVELCBtYXliZSBhIDI1IHllYXIgb2xkIGNvZGVjIGlzDQp0aGUgYmVzdCBhbnN3ZXIgaGVyZSBh
ZnRlciBhbGwuDQoNCk5vIEZVRCBpbnRlbmRlZC4gSWYgeW91IHdhbnQgdG8gaGVscCBjbGVhciB0
aGUgRlVELCBoZWxwIGFuYWx5emUgdGhlDQpwYXRlbnRzLg0KaHR0cDovL3d3dy5ncm9rbGF3Lm5l
dC9hcnRpY2xlLnBocD9zdG9yeT0yMDEzMDMyNDE2MjkwMjE3Nw0KDQpJIHJlYWxseSBob3BlIHdl
IGNhbiBkbyBiZXR0ZXIgdGhhbiBILjI2MS4gVGhhdCB3b3VsZCBiZSBhIGZhaWx1cmUgdG8gbWUu
DQoNCj4gIFJvbg0KDQo=

From lgeyser@gmail.com  Thu Nov 14 21:33:47 2013
Return-Path: 
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 E3E0E11E8128 for ; Thu, 14 Nov 2013 21:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ctmV54i-m-cj for ; Thu, 14 Nov 2013 21:33:47 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D14B211E8119 for ; Thu, 14 Nov 2013 21:33:43 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id eh20so2395785lab.18 for ; Thu, 14 Nov 2013 21:33:42 -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=7jUhAq+mM6Z+2rXNml4TSX3f/+xQBDGlaxh8bsqdzSc=; b=JnBXPvvQngxtXMF2/DTVRV6EoYGJtOBjW1k0rv5FiT/Mv0QysfEuAnFn9qJDPLy8U2 /Rs+PThv5hQVxel9S66vRfxWYlhFiGoK0fsr6V4MrWHD5mA9mvLZtwz0C33Np914tPd0 T5d0uoHuvjSEqDEHBP8GOCybmifonjmCf1oKO7YqE99CiSI+xQ0UYmUqJbBm8eZIsWtM A4NmGsNEdIvdrMur0TzAX773sEIyj3JlZh6z0PabgmR8koT6MFbF+XCqvz795QhTGgYB IqMBHa3lYLEFy9fnq20s8Bk88xxx/Hq81wIZiaMxWW++8x9JMVOw68ijgjRPcxHGS84n pbYQ==
MIME-Version: 1.0
X-Received: by 10.152.18.131 with SMTP id w3mr40910lad.47.1384493622740; Thu, 14 Nov 2013 21:33:42 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 14 Nov 2013 21:33:42 -0800 (PST)
In-Reply-To: 
References: <52855B35.3080605@nostrum.com> 
Date: Fri, 15 Nov 2013 07:33:42 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e014942ee93cbf604eb308a3b
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 05:33:48 -0000

--089e014942ee93cbf604eb308a3b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi everyone,
Maybe MPEG-1 Part 2 would be a better alternative to H.261. How can we
figure out if all the patents have expired for MPEG-1 Part 2?


On 15 November 2013 03:37, Stephan Wenger  wrote:

>  Folks,
> Please don=92t consider H.261 and MPEG-1 part 2 as being in the same leag=
ue
> in terms of coding efficiency or network friendliness.  They clearly are
> not.
> H.261 is what many call the first generation video coding standard.
>  MPEG-1 (and MPEG-2) are second generation.
> MPEG-1 has half-pel motion compensation.  H.261 has not.
> MPEG-1 has B frames.  H.261 has not.
> MPEG-1 has (arbitrary sized) slices that can be used for MTU size matchin=
g
> (although they are not commonly used for that purpose).  H.261 has not.
>  Instead, H.261 has the Group Of Block picture segmentation mechanism, th=
at
> is clearly more optimized for parallel processing than for MTU size
> matching.
> MPEG-1 allows for significantly larger motion vectors (necessitated by B
> frames and the resulting longer prediction interval, but can be used even
> in P frame only coding).
> MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF, and 4CIF (in
> =93still image=94 mode, designed for low frame rate application; could ru=
n at
> high frame rate though).
> H.261 was ratified (in its first version) in 1988, and in the for all
> practical purposes final version in 1989.  Most people believe that all
> related patents have expired.
> MPEG-1 was ratified in late 1992.  Its =93bug fix=94 successor MPEG-2 (wh=
ich
> adds interlace support) was ratified less than a year later.  There are a=
t
> least two major disputes going on today regarding technology allegedly
> infringed by a compliant implementation of MPEG-2.  Based on my technical
> understanding, one of these technologies is not in any way related to
> interlaced.
> Draw your own conclusions.
> Regards,
> Stephan
>
>
>
>
>   From: Adam Roach 
> Date: Thursday, 14 November, 2013 at 15:22
> To: "rtcweb@ietf.org" 
> Subject: Re: [rtcweb] H261/MPEG-1 video quality
>
>   On 11/14/13 17:16, Adam Roach wrote:
>
> At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works out
> to 508 kbits/second total.
>
>
> Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime
> seems to divide it by two for some reason, although the javascript decode
> does the right thing). This works out to 254 kbps.
>
> /a
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--089e014942ee93cbf604eb308a3b
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


    Hi everyone,
    Maybe MPEG-1 Part 2 would be a =
better alternative to H.261. How can we figure out if all the patents have =
expired for MPEG-1 Part 2?


    
On 15 November 2013 03:37, Stephan Wenger <stewe@stewe.org> wr=
ote:
    





    

    Folks,
    

    Please don=92t consider H.261 and MPEG-1 part 2 as being in the same l=
eague in terms of coding efficiency or network friendliness. =A0They clearl=
y are not.
    

    H.261 is what many call the first generation video coding standard. =
=A0MPEG-1 (and MPEG-2) are second generation.
    

    MPEG-1 has half-pel motion compensation. =A0H.261 has not.
    

    MPEG-1 has B frames. =A0H.261 has not.
    

    MPEG-1 has (arbitrary sized) slices that can be used for MTU size matc=
hing (although they are not commonly used for that purpose). =A0H.261 has n=
ot. =A0Instead, H.261 has the Group Of Block picture segmentation mechanism=
, that is clearly more optimized for
 parallel processing than for MTU size matching.
    

    MPEG-1 allows for significantly larger motion vectors (necessitated by=
 B frames and the resulting longer prediction interval, but can be used eve=
n in P frame only coding).
    

    MPEG-1 has arbitrary picture sizes. =A0H.261 allows QCIF, CIF, and 4CI=
F (in =93still image=94 mode, designed for low frame rate application; coul=
d run at high frame rate though).
    

    H.261 was ratified (in its first version) in 1988, and in the for all =
practical purposes final version in 1989. =A0Most people believe that all r=
elated patents have expired.
    

    MPEG-1 was ratified in late 1992. =A0Its =93bug fix=94 successor MPEG-=
2 (which adds interlace support) was ratified less than a year later. =A0Th=
ere are at least two major disputes going on today regarding technology all=
egedly infringed by a compliant implementation
 of MPEG-2. =A0Based on my technical understanding, one of these technologi=
es is not in any way related to interlaced. =A0
    

    Draw your own conclusions.
    

    Regards,
    

    Stephan
    


    

    


    

    


    

    


    

    


    

From: Adam Roach <adam@nostrum.com>
    
Date: Thursday, 14 November, 2013 a=
t 15:22 
    
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
    
Subject: Re: [rtcweb] H261/MPEG-1 v=
ideo quality
    

    


    

    

    

    

    On 11/14/13 17:16, Adam Roach wrote:
    

    

    

  • At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works ou=
t to 508 kbits/second total.

    • 

    
Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime s=
eems to divide it by two for some reason, although the javascript decode do=
es the right thing). This works out to 254 kbps.
    

    
/a
    

    

    

    

    


    _______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--089e014942ee93cbf604eb308a3b--

From xiphmont@gmail.com  Thu Nov 14 21:39:09 2013
Return-Path: 
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 CE14211E810A for ; Thu, 14 Nov 2013 21:39:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 l4Mtx1FddeOT for ; Thu, 14 Nov 2013 21:39:09 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id F359111E80FA for ; Thu, 14 Nov 2013 21:39:08 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id ea20so2417408lab.12 for ; Thu, 14 Nov 2013 21:39:08 -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:content-transfer-encoding; bh=NWuyou+hnaThMoY9fGlfO0NQlbfgGeffdlN69MsNB/o=; b=rReVUHaBZovIQkHxa7mrgCiU7NRXRIwLYjsfuBMpevp1O1yTHEZUPLgO6M9MtUsg2w b4ltrd6ZkD7ltqodsjNrFYtgX+lEHEhR3LQCah1q3OGr8KJNXZu7Pz7Z8xYIvsNG9kl9 TBTXv8+4O3U+l+4Hr9kFqkjPipMTI0wT31+vlJGx5r5JkHqOZwexscGKWZ8A8RDW7/Am 2g7vF/yaQKpXLGsaVhMaShQO7qOEJv+XL/+HYb3JmfGAaHq90CR/WGHyuEJfWnGzvMGv oI74O2aDPtHyxPt7hzCdTJRkbcTFcs4l8AotHZIPDVpOyXPoYXP3/9krri9oSdi5CnO5 iAng==
MIME-Version: 1.0
X-Received: by 10.152.22.228 with SMTP id h4mr32497laf.71.1384493947904; Thu, 14 Nov 2013 21:39:07 -0800 (PST)
Received: by 10.112.128.226 with HTTP; Thu, 14 Nov 2013 21:39:07 -0800 (PST)
In-Reply-To: 
References: <52855B35.3080605@nostrum.com>  
Date: Fri, 15 Nov 2013 00:39:07 -0500
Message-ID: 
From: Monty Montgomery 
To: Leon Geyser 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 05:39:09 -0000

Stephan just implied strongly they haven't, despite the 20 years.

And, BTW, I was serious when I mentioned Theora earlier as well.

Monty

On Fri, Nov 15, 2013 at 12:33 AM, Leon Geyser  wrote:
> Hi everyone,
> Maybe MPEG-1 Part 2 would be a better alternative to H.261. How can we
> figure out if all the patents have expired for MPEG-1 Part 2?
>
>
> On 15 November 2013 03:37, Stephan Wenger  wrote:
>>
>> Folks,
>> Please don=92t consider H.261 and MPEG-1 part 2 as being in the same lea=
gue
>> in terms of coding efficiency or network friendliness.  They clearly are
>> not.
>> H.261 is what many call the first generation video coding standard.
>> MPEG-1 (and MPEG-2) are second generation.
>> MPEG-1 has half-pel motion compensation.  H.261 has not.
>> MPEG-1 has B frames.  H.261 has not.
>> MPEG-1 has (arbitrary sized) slices that can be used for MTU size matchi=
ng
>> (although they are not commonly used for that purpose).  H.261 has not.
>> Instead, H.261 has the Group Of Block picture segmentation mechanism, th=
at
>> is clearly more optimized for parallel processing than for MTU size
>> matching.
>> MPEG-1 allows for significantly larger motion vectors (necessitated by B
>> frames and the resulting longer prediction interval, but can be used eve=
n in
>> P frame only coding).
>> MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF, and 4CIF (i=
n
>> =93still image=94 mode, designed for low frame rate application; could r=
un at
>> high frame rate though).
>> H.261 was ratified (in its first version) in 1988, and in the for all
>> practical purposes final version in 1989.  Most people believe that all
>> related patents have expired.
>> MPEG-1 was ratified in late 1992.  Its =93bug fix=94 successor MPEG-2 (w=
hich
>> adds interlace support) was ratified less than a year later.  There are =
at
>> least two major disputes going on today regarding technology allegedly
>> infringed by a compliant implementation of MPEG-2.  Based on my technica=
l
>> understanding, one of these technologies is not in any way related to
>> interlaced.
>> Draw your own conclusions.
>> Regards,
>> Stephan
>>
>>
>>
>>
>> From: Adam Roach 
>> Date: Thursday, 14 November, 2013 at 15:22
>> To: "rtcweb@ietf.org" 
>> Subject: Re: [rtcweb] H261/MPEG-1 video quality
>>
>> On 11/14/13 17:16, Adam Roach wrote:
>>
>> At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works out
>> to 508 kbits/second total.
>>
>>
>> Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime
>> seems to divide it by two for some reason, although the javascript decod=
e
>> does the right thing). This works out to 254 kbps.
>>
>> /a
>>
>> _______________________________________________
>> 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
>

From lgeyser@gmail.com  Thu Nov 14 21:57:41 2013
Return-Path: 
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 5FDDA11E810A for ; Thu, 14 Nov 2013 21:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Wg9H8vh4WK9r for ; Thu, 14 Nov 2013 21:57:38 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5F311E8109 for ; Thu, 14 Nov 2013 21:57:33 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id eh20so2366295lab.5 for ; Thu, 14 Nov 2013 21:57:32 -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=miMKWT2jWQ5ISH1aw91dOgEwcsh/ABy0WZZI+Mzrf1Y=; b=lsxwFZrLXNVcKTTg5gKb784innjEkec+8dcnFc28igyBkojderX5AfrLw+6k6J2/Dc HOdtCXAzQ3aJ0JbRwyoU6Yg9Jt6HxhitsLzCvt6euzlaruX5LTyQZehzqNiGZB/roExl Wz34m/eeRDoH74wyeIstequ2zHFEE4APIchqXFbvtD7v0jp1j5hnkkUoio7zGomivyHZ 0RoX0uPhKq1Miu7ilZdqc0FfkPCCehesiV6AcRLYIE2VpTL3AZB8yZ+QRConWuolWZzx E0UU7fr72xfJ2SU0owQ1UfzJ8yOM51u4jKmQKX6MUJfZsaUF/OdAfPdNS3TYPSxVmIgK 9sFg==
MIME-Version: 1.0
X-Received: by 10.152.27.164 with SMTP id u4mr33361lag.82.1384495052791; Thu, 14 Nov 2013 21:57:32 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 14 Nov 2013 21:57:32 -0800 (PST)
In-Reply-To: 
References: <52855B35.3080605@nostrum.com>   
Date: Fri, 15 Nov 2013 07:57:32 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0160ba54d0a47304eb30df40
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 05:57:41 -0000

--089e0160ba54d0a47304eb30df40
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Monty,

I do like Theora; it compares well against MPEG-4 Part 2:ASP, but won't the
reasons why some people don't want to implement VP8 be the same for Theora?


On 15 November 2013 07:39, Monty Montgomery  wrote:

> Stephan just implied strongly they haven't, despite the 20 years.
>
> And, BTW, I was serious when I mentioned Theora earlier as well.
>
> Monty
>
> On Fri, Nov 15, 2013 at 12:33 AM, Leon Geyser  wrote:
> > Hi everyone,
> > Maybe MPEG-1 Part 2 would be a better alternative to H.261. How can we
> > figure out if all the patents have expired for MPEG-1 Part 2?
> >
> >
> > On 15 November 2013 03:37, Stephan Wenger  wrote:
> >>
> >> Folks,
> >> Please don=92t consider H.261 and MPEG-1 part 2 as being in the same
> league
> >> in terms of coding efficiency or network friendliness.  They clearly a=
re
> >> not.
> >> H.261 is what many call the first generation video coding standard.
> >> MPEG-1 (and MPEG-2) are second generation.
> >> MPEG-1 has half-pel motion compensation.  H.261 has not.
> >> MPEG-1 has B frames.  H.261 has not.
> >> MPEG-1 has (arbitrary sized) slices that can be used for MTU size
> matching
> >> (although they are not commonly used for that purpose).  H.261 has not=
.
> >> Instead, H.261 has the Group Of Block picture segmentation mechanism,
> that
> >> is clearly more optimized for parallel processing than for MTU size
> >> matching.
> >> MPEG-1 allows for significantly larger motion vectors (necessitated by=
 B
> >> frames and the resulting longer prediction interval, but can be used
> even in
> >> P frame only coding).
> >> MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF, and 4CIF
> (in
> >> =93still image=94 mode, designed for low frame rate application; could=
 run
> at
> >> high frame rate though).
> >> H.261 was ratified (in its first version) in 1988, and in the for all
> >> practical purposes final version in 1989.  Most people believe that al=
l
> >> related patents have expired.
> >> MPEG-1 was ratified in late 1992.  Its =93bug fix=94 successor MPEG-2 =
(which
> >> adds interlace support) was ratified less than a year later.  There ar=
e
> at
> >> least two major disputes going on today regarding technology allegedly
> >> infringed by a compliant implementation of MPEG-2.  Based on my
> technical
> >> understanding, one of these technologies is not in any way related to
> >> interlaced.
> >> Draw your own conclusions.
> >> Regards,
> >> Stephan
> >>
> >>
> >>
> >>
> >> From: Adam Roach 
> >> Date: Thursday, 14 November, 2013 at 15:22
> >> To: "rtcweb@ietf.org" 
> >> Subject: Re: [rtcweb] H261/MPEG-1 video quality
> >>
> >> On 11/14/13 17:16, Adam Roach wrote:
> >>
> >> At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works o=
ut
> >> to 508 kbits/second total.
> >>
> >>
> >> Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime
> >> seems to divide it by two for some reason, although the javascript
> decode
> >> does the right thing). This works out to 254 kbps.
> >>
> >> /a
> >>
> >> _______________________________________________
> >> 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
> >
>

--089e0160ba54d0a47304eb30df40
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


    Hi Monty,

    I do like Theora; it compares =
well against MPEG-4 Part 2:ASP, but won't the reasons why some people d=
on't want to implement VP8 be the same for Theora?
    


    On 15 November 2013 07:39, Monty Montgom=
ery <xiphmont@gmail.com> wrote:
    
Stephan just implied strongly they haven't, despite the 20 years.
    

    
And, BTW, I was serious when I mentioned Theora earlier as well.
    

    
Monty
    


    
On Fri, Nov 15, 2013 at 12:33 AM, Leon Geyser <lgeyser@gmail.com> wrote:
    
> Hi everyone,
    
> Maybe MPEG-1 Part 2 would be a better alternative to H.261. How can we=

    
> figure out if all the patents have expired for MPEG-1 Part 2?
    
>
    
>
    
> On 15 November 2013 03:37, Stephan Wenger <stewe@stewe.org> wrote:
    
>>
    
>> Folks,
    
>> Please don=92t consider H.261 and MPEG-1 part 2 as being in the sa=
me league
    
>> in terms of coding efficiency or network friendliness. =A0They cle=
arly are
    
>> not.
    
>> H.261 is what many call the first generation video coding standard=
.
    
>> MPEG-1 (and MPEG-2) are second generation.
    
>> MPEG-1 has half-pel motion compensation. =A0H.261 has not.
    
>> MPEG-1 has B frames. =A0H.261 has not.
    
>> MPEG-1 has (arbitrary sized) slices that can be used for MTU size =
matching
    
>> (although they are not commonly used for that purpose). =A0H.261 h=
as not.
    
>> Instead, H.261 has the Group Of Block picture segmentation mechani=
sm, that
    
>> is clearly more optimized for parallel processing than for MTU siz=
e
    
>> matching.
    
>> MPEG-1 allows for significantly larger motion vectors (necessitate=
d by B
    
>> frames and the resulting longer prediction interval, but can be us=
ed even in
    
>> P frame only coding).
    
>> MPEG-1 has arbitrary picture sizes. =A0H.261 allows QCIF, CIF, and=
 4CIF (in
    
>> =93still image=94 mode, designed for low frame rate application; c=
ould run at
    
>> high frame rate though).
    
>> H.261 was ratified (in its first version) in 1988, and in the for =
all
    
>> practical purposes final version in 1989. =A0Most people believe t=
hat all
    
>> related patents have expired.
    
>> MPEG-1 was ratified in late 1992. =A0Its =93bug fix=94 successor M=
PEG-2 (which
    
>> adds interlace support) was ratified less than a year later. =A0Th=
ere are at
    
>> least two major disputes going on today regarding technology alleg=
edly
    
>> infringed by a compliant implementation of MPEG-2. =A0Based on my =
technical
    
>> understanding, one of these technologies is not in any way related=
 to
    
>> interlaced.
    
>> Draw your own conclusions.
    
>> Regards,
    
>> Stephan
    
>>
    
>>
    
>>
    
>>
    
>> From: Adam Roach <adam@nost=
rum.com>
    
>> Date: Thursday, 14 November, 2013 at 15:22
    
>> To: "rtcweb@ietf.org&q=
uot; <rtcweb@ietf.org>
    
>> Subject: Re: [rtcweb] H261/MPEG-1 video quality
    
>>
    
>> On 11/14/13 17:16, Adam Roach wrote:
    
>>
    
>> At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding wor=
ks out
    
>> to 508 kbits/second total.
    
>>
    
>>
    
>> Whoops, I messed up my math. It's 148 seconds long, not 74 (Qu=
icktime
    
>> seems to divide it by two for some reason, although the javascript=
 decode
    
>> does the right thing). This works out to 254 kbps.
    
>>
    
>> /a
    
>>
    
>> _______________________________________________
    
>> 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
    
>
    


    

--089e0160ba54d0a47304eb30df40--

From mstura@ooredoo.com  Thu Nov 14 22:46:15 2013
Return-Path: 
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 F265B11E8102 for ; Thu, 14 Nov 2013 22:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 ZT+pUTWHboib for ; Thu, 14 Nov 2013 22:46:09 -0800 (PST)
Received: from koala.qtel.com.qa (koala.qtel.com.qa [212.77.203.181]) by ietfa.amsl.com (Postfix) with ESMTP id CA1EA11E80FE for ; Thu, 14 Nov 2013 22:46:06 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,704,1378846800"; d="scan'208,217";a="42869264"
Received: from Rock7.qtel.ad.pri ([169.254.2.245]) by SEEMA1.qtel.ad.pri ([172.16.224.85]) with mapi id 14.02.0347.000; Fri, 15 Nov 2013 09:46:02 +0300
From: Marco Stura 
To: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= 
Thread-Topic: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
Thread-Index: AQHO4XGeQmLWC4AveEa15PaCj3zGeJok+PeAgADg2Ag=
Date: Fri, 15 Nov 2013 06:46:02 +0000
Message-ID: 
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>	<5283E700.5090300@bbs.darktech.org>  <5283FDF1.8030708@bbs.darktech.org>  <52845DB0.6040501@bbs.darktech.org>	<5284626C.8050504@goodadvice.pages.de> <528471AA.4060101@bbs.darktech.org>	<52847646.9050203@goodadvice.pages.de> , , <6B5C94E8-4A3A-49D8-A772-A20B459CA221@ericsson.com>
In-Reply-To: <6B5C94E8-4A3A-49D8-A772-A20B459CA221@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-exclaimer-md-config: e2f59e9d-2ace-4eb8-ad46-dee98c3fdea5
Content-Type: multipart/alternative; boundary="_000_fkvupto08c2y2lisq8p6ttim1384497595235emailandroidcom_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 06:46:15 -0000

--_000_fkvupto08c2y2lisq8p6ttim1384497595235emailandroidcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Are you thinking to use webrtc over 2g? AFAIK the minimum target mobile acc=
ess should be 3g and a codec that technically could work at 64k is not a pr=
oblem in uplink....


Sent from Huawei Mobile

G=F6ran Eriksson AP  wrote:



14 nov 2013 kl. 20:42 skrev "Jonathan Rosenberg" >:

An important drawback of H.261 as MTI is interop with existing installed ba=
se. Very old conferencing systems and products may still have it since its =
easier to keep the code than delete it, but new platforms in the last few y=
ears will not have H.261.

I also disagree with the assertion that H.261 video is better than audio on=
ly. Video quality matters and I believe the higher quality we've been able =
to achieve in recent years due to the combo of better tech (ala H.264) alon=
g with faster networks is a material factor in the acceptance of video by e=
nd users. I think folks writing the apps should decide whether lousy video =
is good enough, and for business usage the answer is no.

Finally, don't overestimate the typical upstream bandwidth that is availabl=
e to users across the Internet. Many of us here on this list probably have =
nice speedy high speed connections (I have fiber with 85/35 service) and th=
at is not the norm for the rest of the world.

And if we consider cellular access to Internet, upstream bandwidth may be e=
ven more limited. An MTI making mobile WEBRTC difficult is not easy to embr=
ace wholeheartedly considering we already have it WEBRTC in some mobile bro=
wsers.






On Thu, Nov 14, 2013 at 5:08 AM, Silvia Pfeiffer > wrote:
On Thu, Nov 14, 2013 at 3:05 PM, Philipp Hancke
> wrote:
>> Okay, so I stand corrected (thank you for pointing this out).
>
>
> heh, I'm always surprised by how many people are completly unaware that t=
he
> innovations webrtc brings aren't new at all.

Right. HTML is just another word processing format, too. :-)
Silvia.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



--
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

________________________________

The information in this email and any attachments thereto may contain infor=
mation that is confidential, protected by intellectual property rights, and=
 may be legally privileged. It is intended solely for the addressee(s). Acc=
ess to this email by anyone else is unauthorized. Any use, disclosure, copy=
ing, or distribution of the information contained herein by persons other t=
han the designated addressee is unauthorized and may be unlawful. If you ar=
e not the intended recipient, you should delete the message immediately fro=
m your system. If you believe that you have received this email in error, p=
lease contact the sender. Any views expressed in this email and its attachm=
ents are those of the individual sender except where the sender expressly s=
tates them to be the views of Ooredoo.

--_000_fkvupto08c2y2lisq8p6ttim1384497595235emailandroidcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Are you thinking to use webrtc over 2g? AFAIK the minimum target mobile acc=
ess should be 3g and a codec that technically could work at 64k is not a pr=
oblem in uplink....
    

    

    
Sent from Huawei Mobile
    

    
G=F6ran Eriksson AP <goran.ap.eriksson@ericsson.com> wrote:
    

    

    


    

    


    
14 nov 2013 kl. 20:42 skrev "Jonathan Rosenberg" <jdrosen@jdrosen.net>:
    

    

    

    

    

    An important drawback of H.261 as MTI is interop with exis=
ting installed base. Very old conferencing systems and products may still h=
ave it since its easier to keep the code than delete it, but new platforms =
in the last few years will not have
 H.261. 


    

    

    I also disagree with the assertion that H.261 video is better than aud=
io only. Video quality matters and I believe the higher quality we've been =
able to achieve in recent years due to the combo of better tech (ala H.264)=
 along with faster networks is a
 material factor in the acceptance of video by end users. I think folks wri=
ting the apps should decide whether lousy video is good enough, and for bus=
iness usage the answer is no.
    


    

    

    Finally, don't overestimate the typical upstream bandwidth that is ava=
ilable to users across the Internet. Many of us here on this list probably =
have nice speedy high speed connections (I have fiber with 85/35 service) a=
nd that is not the norm for the
 rest of the world.
    

    

    

    


    

    

    And if we consider cellular access to Internet, upstream bandwidth may=
 be even more limited. An MTI making mobile WEBRTC difficult is not easy to=
 embrace wholeheartedly considering we already have it WEBRTC in some mobil=
e browsers.
    


    

    


    

    

    

    


    

    

    _______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
https://www.=
ietf.org/mailman/listinfo/rtcweb
    

    

    

    

    

    

    
The information in this email and any attachments thereto may contain infor=
mation that is confidential, protected by intellectual property rights, and=
 may be legally privileged. It is intended solely for the addressee(s). Acc=
ess to this email by anyone else
 is unauthorized. Any use, disclosure, copying, or distribution of the info=
rmation contained herein by persons other than the designated addressee is =
unauthorized and may be unlawful. If you are not the intended recipient, yo=
u should delete the message immediately
 from your system. If you believe that you have received this email in erro=
r, please contact the sender. Any views expressed in this email and its att=
achments are those of the individual sender except where the sender express=
ly states them to be the views of
 Ooredoo.
    
    



--_000_fkvupto08c2y2lisq8p6ttim1384497595235emailandroidcom_--

From magnus.westerlund@ericsson.com  Thu Nov 14 23:27:25 2013
Return-Path: 
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 782EA21F967A for ; Thu, 14 Nov 2013 23:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 CYia15XFGZRw for ; Thu, 14 Nov 2013 23:27:19 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B931C21F99E9 for ; Thu, 14 Nov 2013 23:27:18 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-5d-5285cccf127d
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CE.4C.15980.FCCC5825; Fri, 15 Nov 2013 08:27:11 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Fri, 15 Nov 2013 08:27:10 +0100
Message-ID: <5285CCCE.6040906@ericsson.com>
Date: Fri, 15 Nov 2013 08:27:10 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Monty Montgomery , Leon Geyser 
References: <52855B35.3080605@nostrum.com> 	 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+Jvre75M61BBvenq1h0r57FZrH2Xzu7 xdvHnxkdmD12zrrL7rFkyU+mAKYoLpuU1JzMstQifbsErowNrzayF3xjqzh3+wJTA+M11i5G Tg4JAROJtZ9eM0HYYhIX7q1n62Lk4hASOMQo8XriN0YIZzmjxKGzX9lAqngFtCWmneoD62YR UJU4MOMkC4jNJmAhcfNHI1iNqECwxPlXi9kh6gUlTs58AlYjIuAlsW3vbEYQm1lAXeLO4nNg NcIC+hJtc1cyQyy7yihx7utqsCJOgUCJ53e+ADVzAJ0nLtHTGATRayBxZNEcVghbXqJ562xm EFsI6LaGpg7WCYxCs5CsnoWkZRaSlgWMzKsY2XMTM3PSy803MQLD9uCW3wY7GDfdFzvEKM3B oiTO++Gtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRt1Kzajzbr9N7heaeXpdcbvu8+bh LceF6S/mcp+9+f9n7Yz521++aTapzenlXPAjmbmoYmpK342F6esrgwze3dwjpjfpV2KBo4X8 Ap3qvEcGuswHZUJmrZsTv/hXoujFKVOzPIRnHq0XN+oo+FlfNMXN+cPxRMU4zevt9dfYuOtP hr6NeMLirsRSnJFoqMVcVJwIABDtcs4pAgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 07:27:25 -0000

On 2013-11-15 06:39, Monty Montgomery wrote:
> Stephan just implied strongly they haven't, despite the 20 years.
> 
> And, BTW, I was serious when I mentioned Theora earlier as well.

If you want this on the list of alternatives, please send an email in
the other thread with the MUST statement. I would also request that you
include a reference to the codec, and any needed scoping of your proposal.

Regards

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From maikmerten@googlemail.com  Thu Nov 14 23:38:58 2013
Return-Path: 
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 0E40311E80F6 for ; Thu, 14 Nov 2013 23:38:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 yBdof718sJ-S for ; Thu, 14 Nov 2013 23:38:57 -0800 (PST)
Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BA5B311E8109 for ; Thu, 14 Nov 2013 23:38:47 -0800 (PST)
Received: by mail-bk0-f43.google.com with SMTP id mz13so1493678bkb.2 for ; Thu, 14 Nov 2013 23:38:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=a4xeeP+N6dFK/q4Mgqy7Z88t02DSudCP2U6u0BS3m/o=; b=e25PkEyyDZ9f08GVhYgz9Vedgaih0EgL2gUKZxrdQrg9KXkORzYmf7C5KciNBn1E7l JRkyUeZMv/fiKY54X5e+6seikMWr2MO3jcdwevT69PVpYMqlDi7SM4YaRh8pwEWTz7rj gwNIVYbeV2ErAUt9O82ffRJpio4pF6tZz9Lyh5B/F7GZKEQCmmm5IdoU8mZnifytqdh/ 7cwo1vpsvro/zet3n6udRUgos3Zqysr0kIlND33A7RrQpLUoNOWjkbtVWQ9A9EwP1JnN 5bXS8QaZDYLbHcYowX38yJ/nx8VNMfgxrh8sst/yTHt2x46wjDZkPN9JGDfwAboEuZGM 1xHw==
X-Received: by 10.205.20.74 with SMTP id qn10mr252514bkb.46.1384501126781; Thu, 14 Nov 2013 23:38:46 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id zl3sm5992267bkb.4.2013.11.14.23.38.45 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 23:38:45 -0800 (PST)
Message-ID: <5285CFCF.7000409@googlemail.com>
Date: Fri, 15 Nov 2013 08:39:59 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52855B35.3080605@nostrum.com> 	 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 07:38:58 -0000

Am 15.11.2013 06:39, schrieb Monty Montgomery:
> Stephan just implied strongly they haven't, despite the 20 years.

Would sure be nice what those disputes Stephan mentions are actually about.

After all, a major premise of IVC (one of MPEG's efforts to get a RF 
codec) is that MPEG-1 video is considered free by now and I see some 
people being active there that are quite IP-aware.

MPEG-2, in contrast, is clearly a worthy target for disputes, being 
mandatory for DVD and BluRay, and there, e.g., appear to be a swath of 
somewhat "meh" IP claims targeting exactly that application and being 
filed or re-filed or re-re-filed long after the coding technology itself 
was ratified.

I see stuff like

"This is a continuation of application Ser. No. *****, filed Apr. **, 
2009, which is a continuation of application Ser. No. ******, filed Jun. 
**, 2005, now U.S. Pat. No. *****, which is a continuation of 
application Ser. No. *******, filed Apr. **, 1996, now U.S. Pat. No. 
*****, which is a continuation of application Ser. No. ******, filed 
Jan. **, 1994, now abandoned, which is entitled to the priority filing 
date of Japanese application ****** filed on Jan. **, 1993, the entirety 
all of which are incorporated herein by reference."

It's unclear to me what this *means* regarding the usability of old MPEG 
technology.


> And, BTW, I was serious when I mentioned Theora earlier as well.

Theora would clearly be preferable over H.261 or MPEG-1. It has a nice, 
widely deployed and tested implementation with BSD-style license, a 
well-written specification, has better coding efficiency than H.261 or 
MPEG-1 and is quite frugal regarding computation.


Maik

From maikmerten@googlemail.com  Thu Nov 14 23:53:07 2013
Return-Path: 
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 E5CE521F9FB4 for ; Thu, 14 Nov 2013 23:53:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 1GYybKCQ-+6o for ; Thu, 14 Nov 2013 23:53:07 -0800 (PST)
Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E995B21F9FA3 for ; Thu, 14 Nov 2013 23:53:06 -0800 (PST)
Received: by mail-bk0-f43.google.com with SMTP id mz13so1498507bkb.2 for ; Thu, 14 Nov 2013 23:53:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4Uaw1wUMAQJoGc8fQck6OPEOEScXO54fjfnEsPkBuXA=; b=aCx6tO/rPCvvzAmI9fyuVVYMES3vYdqti8o6VaArocdfd6BXtAi44zKY6KfdL8jhQ8 u3m7bp5ns+SSVqM1Slro96wR8WvbEyBD6R/ARlyk5WP06FIAGOJaziROmEfyMuooLn8u sqHPEz0rGacO5vw7U93shfLepnc3HdRboRsLmdkoR1mxQEXKsier73dTaZf1lpk9YXia pdTy6nmB5h11unzGyHKpX7QIiYVKnythmiMJOjtLgTJTBK/wtBT/qvPqNQnLylhuVNG5 07velBnuN4j8KdfH8xwHhNoAeS0CTKYKVDSUSnBUMncS+BnX5FcmA3RBUYCHTPEeLSqD oB1Q==
X-Received: by 10.204.68.142 with SMTP id v14mr3404752bki.18.1384501985919; Thu, 14 Nov 2013 23:53:05 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id pn6sm6089112bkb.14.2013.11.14.23.53.04 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 23:53:05 -0800 (PST)
Message-ID: <5285D32B.605@googlemail.com>
Date: Fri, 15 Nov 2013 08:54:19 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 07:53:08 -0000

Dear Stephan,

thanks for highlighting the differences between H.261 and MPEG-1 Part 2.

Regarding just coding efficiency, I guess that apart from the refined 
coding tools in MPEG-1 much of the difference in practice would stem 
from outdated or buggy implementations: I simply cannot find a modern 
H.261 encoder with, e.g., rd optimization on mode decisions or trellis 
quantization (ffmpeg has these options, but crashes when enabling them 
for H.261). H.261 has clearly been neglected in this regard, making it 
difficult to assess the quality that actually can be achieved.


Best regards,

Maik

Am 15.11.2013 02:37, schrieb Stephan Wenger:
> Folks,
> Please don’t consider H.261 and MPEG-1 part 2 as being in the same
> league in terms of coding efficiency or network friendliness.  They
> clearly are not.
> H.261 is what many call the first generation video coding standard.
>   MPEG-1 (and MPEG-2) are second generation.
> MPEG-1 has half-pel motion compensation.  H.261 has not.
> MPEG-1 has B frames.  H.261 has not.
> MPEG-1 has (arbitrary sized) slices that can be used for MTU size
> matching (although they are not commonly used for that purpose).  H.261
> has not.  Instead, H.261 has the Group Of Block picture segmentation
> mechanism, that is clearly more optimized for parallel processing than
> for MTU size matching.
> MPEG-1 allows for significantly larger motion vectors (necessitated by B
> frames and the resulting longer prediction interval, but can be used
> even in P frame only coding).
> MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF, and 4CIF
> (in “still image” mode, designed for low frame rate application; could
> run at high frame rate though).
> H.261 was ratified (in its first version) in 1988, and in the for all
> practical purposes final version in 1989.  Most people believe that all
> related patents have expired.
> MPEG-1 was ratified in late 1992.  Its “bug fix” successor MPEG-2 (which
> adds interlace support) was ratified less than a year later.  There are
> at least two major disputes going on today regarding technology
> allegedly infringed by a compliant implementation of MPEG-2.  Based on
> my technical understanding, one of these technologies is not in any way
> related to interlaced.
> Draw your own conclusions.
> Regards,
> Stephan
>
>
>
>
> From: Adam Roach >
> Date: Thursday, 14 November, 2013 at 15:22
> To: "rtcweb@ietf.org "  >
> Subject: Re: [rtcweb] H261/MPEG-1 video quality
>
> On 11/14/13 17:16, Adam Roach wrote:
>> # At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works
>> out to 508 kbits/second total.
>
> Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime
> seems to divide it by two for some reason, although the javascript
> decode does the right thing). This works out to 254 kbps.
>
> /a
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From lars@netapp.com  Fri Nov 15 00:51:54 2013
Return-Path: 
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 0105921F9FB4 for ; Fri, 15 Nov 2013 00:51:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.932
X-Spam-Level: 
X-Spam-Status: No, score=-10.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 MWWSyX3BDz30 for ; Fri, 15 Nov 2013 00:51:49 -0800 (PST)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 02C7921F969F for ; Fri, 15 Nov 2013 00:51:49 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,706,1378882800";  d="asc'?scan'208";a="115893561"
Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx12-out.netapp.com with ESMTP; 15 Nov 2013 00:51:47 -0800
Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 00:51:47 -0800
From: "Eggert, Lars" 
To: Wesley Eddy 
Thread-Topic: [rtcweb] Protesting the QoS document decision
Thread-Index: AQHO4K4KYVoKeLlMI0yCV4m8SvuejZok5sYAgACZZICAABXuAIAAHB4AgADSWwA=
Date: Fri, 15 Nov 2013 08:51:45 +0000
Message-ID: <6149C92B-220E-474B-910F-12FB2063BF11@netapp.com>
References: <5283DF61.9060807@alvestrand.no>	<52848582.1070408@ericsson.com> <5285062F.9070204@mti-systems.com>  <5285302A.2040903@mti-systems.com>
In-Reply-To: <5285302A.2040903@mti-systems.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.104.60.117]
Content-Type: multipart/signed; boundary="Apple-Mail=_1A83C850-A99F-48A2-A80A-E8CA002FE8E3"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "rai-ads@tools.ietf.org" , "tsv-ads@tools.ietf.org" 
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 08:51:54 -0000

--Apple-Mail=_1A83C850-A99F-48A2-A80A-E8CA002FE8E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 2013-11-14, at 21:18, Wesley Eddy  wrote:
> IMO, this is a fundamental issue with the recommendation that
> differs from the way that DiffServ is implemented and thought
> about.  Classifiers operate based on flow-level n-tuple
> information generally.  The document pretends that what it's
> prescribing is perfectly normal, which I don't think is the case,
> and I don't know if it's even something the IETF wants to do.

+1

This really needs some deep thinking by the DiffServ folks. (And they =
don't hang out in RTCWEB.)

Lars

--Apple-Mail=_1A83C850-A99F-48A2-A80A-E8CA002FE8E3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQCVAwUBUoXgoNZcnpRveo1xAQJSZAP/V+sm1rAH5inKiWMKGJ53nOjyNCcGDjlS
8RJc+Dm2ama4h5iV8FQi3a9luH0GqZ5z71dccRdwlZLEp4MVOT6soHrYgPftrOQK
SXWZmTZ4JICc6LJ0ilvssT178aST6ozbdCW87wPXarNleEqNRfwFJ5blhfgtwNWu
HQ1gI76PO9Q=
=AYkf
-----END PGP SIGNATURE-----

--Apple-Mail=_1A83C850-A99F-48A2-A80A-E8CA002FE8E3--

From lars@netapp.com  Fri Nov 15 00:52:52 2013
Return-Path: 
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 4E08321F9FB7 for ; Fri, 15 Nov 2013 00:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.849
X-Spam-Level: 
X-Spam-Status: No, score=-10.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 uQLlAk9lxILL for ; Fri, 15 Nov 2013 00:52:48 -0800 (PST)
Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 2C34321F9FB4 for ; Fri, 15 Nov 2013 00:52:48 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,706,1378882800";  d="asc'?scan'208";a="292334426"
Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx1-out.netapp.com with ESMTP; 15 Nov 2013 00:52:48 -0800
Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 00:52:45 -0800
From: "Eggert, Lars" 
To: Gorry Fairhust 
Thread-Topic: [rtcweb] Protesting the QoS document decision
Thread-Index: AQHO4K4KYVoKeLlMI0yCV4m8SvuejZokP2MAgABEeACAASEKgIAALNoAgACzEAA=
Date: Fri, 15 Nov 2013 08:52:44 +0000
Message-ID: 
References: <5283DF61.9060807@alvestrand.no> <201311132211.rADMBaBD011692@rcdn-core2-5.cisco.com> <52843288.5000507@alvestrand.no> <201311141931.rAEJVBn2004230@rcdn-core-3.cisco.com> <52854A9E.1010506@erg.abdn.ac.uk>
In-Reply-To: <52854A9E.1010506@erg.abdn.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.104.60.117]
Content-Type: multipart/signed; boundary="Apple-Mail=_1CDB0124-7B1E-4952-ADC5-65EDB8AA3302"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: "rai-ads@tools.ietf.org" , "tsv-ads@tools.ietf.org" , "Black, David" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 08:52:52 -0000

--Apple-Mail=_1CDB0124-7B1E-4952-ADC5-65EDB8AA3302
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

s/RMCAT/RTCWEB/g

Otherwise, +1

On 2013-11-14, at 23:11, Gorry Fairhurst  wrote:

> We don't need to keep hearing from people how much they want this done =
- we need to hear from people who say they'll do this, or speak to =
people who understand the issues and get new text to go into this draft.
>=20
> The draft was discussed at length in Berlin. Cullen presented to TSVWG =
- it received feedback, comments, and a request to address the comments =
on the list or in the draft. We followed-up with announcement to RMCAT =
in Berlin, and a tiny bit of feedback. Cullen who presented, also Chairs =
RMCAT - so surely can't be "hidden" from RMCAT?
>=20
> In TSVWG, there was interest recorded in doing such work, and there's =
surely expertise to work on DSCP-related issues. However, I saw no =
discussion following Berlin on the list or responses from the authors, =
sorry. We did see need for various other things (SCTP-related) by RMCAT, =
and promptly adopted and also prioritized these.
>=20
> I hoped there would be an updated draft - but there was no =
presentation requested and there had been no document update in response =
to the comments. IF Cullen had wanted to come back and say more (or =
anyone else) they could have done.
>=20
> If people *are* interested - and people keep saying they are - then =
please listen to the feedback being given and either update the draft or =
propose another draft that addresses the comments. If the comments don't =
apply for some reason, then bring up the topic on the list. If the =
feedback isn't clear enough to act upon, and it may not be after time, =
we can surely help...
>=20
> We're listening...
>=20
> Gorry
> (wearing TSVWG chair hat)
>=20
>=20
>=20
> On 14/11/2013 19:31, James Polk wrote:
>> At 08:16 PM 11/13/2013, Harald Alvestrand wrote:
>>> On 11/13/2013 11:11 PM, James Polk wrote:
>>> > I, speaking at the mic, was merely pointing out that this draft =
had
>>> > moved to TSVWG back in the Atlanta timeframe (though, thinking =
back, I
>>> > think I left the timing piece out of my comment), so it wasn't a
>>> > recent decision. I believe this came directly from talks between =
the
>>> > above mentioned ADs.
>>>=20
>>> This only reinforces my procedural comment. The fact that the =
decision,
>>> and the reasons for it, has been hidden from the group for 8 (?) =
months
>>> only makes it worse, not better.
>>=20
>> it was mentioned during the chair's review of RTCweb documents during
>> the Orlando RTCweb meeting. I was there in the front row...
>>=20
>>=20
>>> When ADs make decisions by talking among themselves, they have a =
special
>>> duty to make sure those decisions are public and open to the =
community.
>>> That duty has not been executed in this case.
>>> I don't know who dropped the ball - the ADs or the chairs. But the =
ball
>>> was definitely dropped.
>>=20
>> I think this was announced on the list, but was part of a larger =
email,
>> and not the main topic (i.e., "subject" line)... making searching for =
it
>> difficult at best.
>>=20
>>> > As for RTCweb work being more appropriately inside the RTBweb WG
>>> > instead of another group, I'd like to point out that much of the =
SDP
>>> > work related to this WG is in fact being done in MMUSIC. Much of =
the
>>> > RTP work being done by this WG is being done in AVTCORE (or =
AVTEXT?).
>>> > All of the base SCTP work being done by this WG is being done in =
TSVWG.
>>>=20
>>> I have issues with those too. Especially the speed at which they're
>>> progressing. But those decisions were made and announced in a timely
>>> fashion.
>>=20
>> I figured this was part of the problem, and have nothing good to add =
here.
>>=20
>>=20
>>> The argument that has been used is that the pieces we need defined
>>> (BUNDLE, MSID, circuit-breakers, RMCAT) have general applicability, =
and
>>> should therefore be processed by groups that are chartered to define
>>> extensions with general applicability.
>>=20
>> it was RMCAT (also in Transport) that was the main interaction from =
my
>> pov, and I think from the TSVWG chairs pov, as RMCAT's chairs said to
>> TSVWG (paraphrasing) "we don't think we're going to need anything new =
or
>> existing work wrt DiffServ to solve RMCAT's solution". This effective
>> told the TSVWG chairs they could table/postpone/whatever the DiffServ
>> draft from RTCweb until RMCAT was through deciding which solution =
they
>> were going to go with. I think, perhaps, the TSVWG chairs (me =
included)
>> thought there was more of a direct link between RMCAT and RTCweb than
>> there really was. If there was, and we were talking past each other,
>> then  apologize, as I clearly didn't get that memo.
>>=20
>>=20
>>> >
>>> > (this is not an attack, but...)
>>> >
>>> > ...why are you arguing for something as far away down the stack as
>>> > DSCP assignments to be done in RTCweb, and not where all other
>>> > DiffServ work is being done in the IETF (in TSVWG)? Do you not =
trust
>>> > that TSVWG will do an appropriate just with a DiffServ ID but you =
will
>>> > trust TSVWG with SCTP IDs?
>>>=20
>>> My understanding of the QoS draft has always been that it should =
define
>>> no new codepoints.
>>=20
>> It shouldn't and doesn't, it's merely a profile doc for RTCweb (said =
as
>> an author and as a TSVWG chair).
>>=20
>>> It should point out the language we need to translate
>>> RTCWEB requirements ("audio should go faster than video, except when =
the
>>> app says that it should be the other way around") into =
already-defined
>>> DSCP code points.
>>=20
>> that's my understanding (of the requirements) too
>>=20
>>=20
>>> I have not seen anyone arguing for new DSCP codepoints
>>=20
>> nor should they have
>>=20
>>> , so I really
>>> wonder what work there is for TSVWG to do.
>>=20
>> to make sure that no one specifies anything stupid in the profile.
>>=20
>> What RTCweb doesn't know, except for Magnus and Colin, is that TSVWG =
is
>> in the process of bis-ing our DiffServ guidelines RFC (4594). We've
>> reached WG consensus on most of the proposed changes, by the
>> author/editor has a couple of changes he hasn't reach WG consensus =
with/on.
>>=20
>>=20
>>> Again, the arguments may be there, but since they were never exposed =
to
>>> the mailing list, I cannot evaluate them.
>>=20
>> "never" is, I think, not true.
>>=20
>> I'll give you 'announced along with 50m other things in RTCweb =
(buried
>> in the background noise) ...
>>=20
>>=20
>>> >
>>> > Color me confused...
>>> >
>>> > James
>>> >
>>> > BTW - Full disclosure, I'm an listed author of this draft, but had =
no
>>> > voice in it getting moved between the WGs.
>>>=20
>>> My biggest practical issue with this draft is that it's functionally
>>> dead.
>>=20
>> see above for the confusion
>>=20
>>> I'm getting put in a place where I have to either delay shipping
>>> this feature in product or ship without even the guidance of a live
>>> draft.
>>=20
>> I can certainly appreciate that
>>=20
>>=20
>>> I want this group to be done. As long as I can't even point to the
>>> document that describes how we do QoS, I have no chance of getting =
it to
>>> that stage.
>>=20
>> again, I can certainly appreciate that
>>=20
>> James
>>=20
>>=20
>>=20
>>> >
>>> > At 02:21 PM 11/13/2013, Harald Alvestrand wrote:
>>> >> This mail concerns both administrative and technical issues, =
which is
>>> >> why it is explicitly copied to the ADs of RAI and TSV. I hope I =
have
>>> >> managed to keep them separate in the message.
>>> >>
>>> >> Magnus said in an email yesterday, concerning =
draft-ietf-rtcweb-qos:
>>> >>
>>> >> > Okay, we might not have been public enough on this. It was
>>> >> requested by
>>> >> > the Transport ADs quite some time ago that doing the QoS =
document
>>> >> in our
>>> >> > WG was not appropriate and requested us to direct the document =
to
>>> >> TSVWG.
>>> >> > Which was done, and where it hasn't made progress.
>>> >> >
>>> >> > You might have noted that James Polk did comment in the =
milestone
>>> part
>>> >> > in the monday session of IETF88 about our QoS milestone should =
be
>>> >> killed.
>>> >> I want to protest this - both practically and formally.
>>> >>
>>> >> To get the formal stuff out of the way first:
>>> >>
>>> >> Changing the deliverables of the working group *without telling =
the
>>> >> working group* is totally inappropriate in an open, =
consensus-driven
>>> >> process.
>>> >> Changing the deliverables of the working group *without telling =
the
>>> >> working group why* and *without allowing those reasons to be
>>> debated* is
>>> >> totally inappropriate in an open, consensus-driven process.
>>> >>
>>> >> I protest against this action.
>>> >>
>>> >> ACTION REQUEST 1: I request that this decision be declared null =
and
>>> >> void, and that the relevant ADs send out a message to RTCWEB (and
>>> TSVWG
>>> >> if appropriate) *PROPOSING* such an action, and giving a =
reasonable
>>> >> timeline for when they will make a decision based on mailing list
>>> >> feedback.
>>> >>
>>> >> In practice:
>>> >>
>>> >> The draft as it existed before its untimely demise consisted of =
two
>>> >> things:
>>> >>
>>> >> - A description of how QoS mechanisms could be useful in the =
RTCWEB
>>> >> use case
>>> >> - A description of existing mechanisms that could be appropriate
>>> for the
>>> >> RTCWEB use case
>>> >>
>>> >> The first one is clearly something that needs RTCWEB consensus. =
It
>>> seems
>>> >> to have no need for, nor likelyhood of gathering interest enough
>>> for, a
>>> >> TSVWG consensus.
>>> >>
>>> >> There could be some argument that the second part needs TSVWG
>>> consensus,
>>> >> especially if it was redefining any mechanisms, or it was making
>>> choices
>>> >> between mechanisms where TSVWG had strong opinions about which
>>> >> mechanisms should be chosen, but had not chosen to document that =
in
>>> any
>>> >> document on which IETF consensus had been declared (that is to =
say,
>>> >> existing RFCs).
>>> >>
>>> >> My archive shows 36 messages where the title refers to this =
draft. It
>>> >> shows no messages declaring that feedback has been incorporated =
and
>>> >> calling for new review - something that is usually necessary to =
get
>>> a WG
>>> >> consensus on any document. The debate hasn't been conclusive, but
>>> then,
>>> >> it hasn't been pushed hard either.
>>> >>
>>> >> The people who know how RTCWEB works are in this working group.
>>> Some of
>>> >> them may be in TSV, but I think the locus of knowledge for saying =
what
>>> >> QoS mechanisms are appropriate for RTCWEB are here, not in TSV.
>>> >>
>>> >> This results in my second request.
>>> >>
>>> >> ACTION REQUEST 2: I request that the chairs declare that based on =
the
>>> >> debate about the QoS functionality so far, the document should be
>>> >> resurrected, and will continue to be  worked on in the RTCWEB =
working
>>> >> group, bringing in advice from TSVWG as required to make sure the
>>> >> descriptions of underlying mechanisms, and the choice of such
>>> >> mechanisms, is correct and appropriate.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Surveillance is pervasive. Go Dark.
>>> >>
>>> >> _______________________________________________
>>> >> rtcweb mailing list
>>> >> rtcweb@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/rtcweb
>>> >
>>>=20
>>>=20
>>> --
>>> Surveillance is pervasive. Go Dark.
>>=20
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--Apple-Mail=_1CDB0124-7B1E-4952-ADC5-65EDB8AA3302
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQCVAwUBUoXg1NZcnpRveo1xAQJlowP/c205SFYRDMLCzAXB4ihrZVGdjLy5em1l
3S4UpFvu+DNgv1g8OjZYmGr2QlQJuUi/QYlXa7iUJTtPRkJGDd7Jen56PXI5yvr2
TfpJ5NkYyvgVDBoqF+mjZf/astnNRjZlB6jB4Mvb9HMHr8lvxVfwe6If/4eVcE7P
NFMDrTBi+8o=
=bWEd
-----END PGP SIGNATURE-----

--Apple-Mail=_1CDB0124-7B1E-4952-ADC5-65EDB8AA3302--

From magnus.westerlund@ericsson.com  Fri Nov 15 01:02:24 2013
Return-Path: 
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 9736D11E8102 for ; Fri, 15 Nov 2013 01:02:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.949
X-Spam-Level: 
X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 CvPmeNfX9Bi9 for ; Fri, 15 Nov 2013 01:02:18 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C4A6811E8109 for ; Fri, 15 Nov 2013 01:02:17 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-e8-5285e318c967
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C3.CE.23787.813E5825; Fri, 15 Nov 2013 10:02:16 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Fri, 15 Nov 2013 10:02:16 +0100
Message-ID: <5285E318.3090006@ericsson.com>
Date: Fri, 15 Nov 2013 10:02:16 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Ram Mohan R (rmohanr)" , "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3VlficWuQwdYz+hYrnjxisVjetYPR Yu2/dnYHZo8pvzeyeixZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGXuXn2Et+KpdcWHzZ6YG xrlKXYycHBICJhKLvhxhhLDFJC7cW8/WxcjFISRwiFFi6b497BDOckaJJf9/soJU8QpoS3w9 2cfcxcjBwSKgKvH8tCdImE3AQuLmj0Y2EFtUIFji/KvF7BDlghInZz5hAbFFBM4zShz5LgRi Cwu4SCyecZIZxBYS0JP48OUxE4jNKaAvcXvqTVaQ8RIC4hI9jUEgYWagkilXWxghbHmJ5q2z oVq1JRqaOlgnMArOQrJtFpKWWUhaFjAyr2Jkz03MzEkvN9zECAzSg1t+6+5gPHVO5BCjNAeL kjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYRVIdOWUuTIu4JesrsX5fznHmJ3qG 4btsrvx/o/TnkOa/8G1d3ftkc7puXhZV09Lz73eXq7th1nNuc8pGx2QfNe/m36csp3dNWfG4 wN9kyb4s/djU6xs2qQhV+h5f5zXnQNLeFWw/7be9FVu1zXblzLNCfrxMJhEf68+t4F/+qF9b 9m/u2+lvlViKMxINtZiLihMBvwo7/iACAAA=
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 09:02:24 -0000

Hi,

Removing things where I am in agreement or like your response.

On 2013-11-14 18:23, Ram Mohan R (rmohanr) wrote:
> Hi Magnus,
> 
> Thanks for your comments. Please see inline for responses.
> 
> 
> -----Original Message-----
> From: Magnus Westerlund 
> Date: Tuesday, 12 November 2013 8:28 PM

>>
>> 3. Section 1:
>> "This document describes a new STUN usage with a request and response
>>   which verifies the remote peer consents to receive traffic, and
>>   detects loss of liveness."
>>
>> I am missing a word after "request and response", transaction or
>> messages maybe?
> 
> NEW:
> This document describes a new STUN usage with a request and response
> messages which verifies the remote peer consents to receive traffic, and
> detects loss of liveness.

Isn't it either "which verifies the remote peer's consent to" or "which
verifies that the remote peer consents to"?



>
>>
>> 5. Section 4:
>>   Consent freshness serves as a circuit breaker (so that if the path or
>>   remote peer fails the WebRTC browser stops sending all traffic on
>>   that remote peer), determining session liveness serves the purpose of
>>   notifying the application of connectivity failure so that the
>>   application can take appropriate action.
>>
> 
>>
>> What is the definition of a peer here?
> 
> Peer is the sink for the traffic originated from the sender for that flow
> (5 tuple). If a browser uses different 5 tuple for each stream(Audio,
> video, data) it sends then it should do consent for each flow. If it uses
> same 5-tuple (mux case) then there will be only one consent.

Please be explicit about this. I think it is easy to interpret that this
would apply to all flows from one end-point to a given destination address.

> 
> 
> 
>> What scope does the stop sending
>> have?
> 
> The stream that is being sent on a flow(5 tuple) for which a consent has
> failed will be stopped. If all the streams are muxed on a same 5 tuple the
> entire traffic will be stopped.
> 

I am fine with this, as long as the document is explicit about this
being the scope.


>>
>> 6. Section 4:
>>   1.  A consent timer, Tc, whose value is determined by the browser.
>>       This value MUST be 15 seconds.
>>
>> I see a contradiction here, should it be determined by the browser or be
>> 15 s? If it is 15, can you please motivate why it is this value, or
>> point to where it is motivated?
> 
> The default value of 15 was some thing that EKR and Justin gave us based
> on the implementation/testing and fine tuning they have done on their
> browsers. I agree we can have some text around it that explains how this
> number is arrived. We will add the same.

Good, I think it is important we understand the considerations of why
this is a reasonable choice.


>>
>> 8. Section 4:
>>   If a valid STUN Binding Response is not received after 500ms, the
>>   STUN Binding Request is retransmitted (with the same Transaction ID
>>   and all other fields).  As long as a valid STUN Binding Response is
>>   not received, this retransmission is repeated every 500ms until Tf
>>   seconds have elapsed or a valid response is received.
>>
>> So no exponential back-off on the retransmission timer. I think that is
>> fine. However, I think it do require you to expand a bit on what happens
>> when one gets multiple response on the same Transaction ID. For example
>> additional responses do they or do they not reset the Tc timer?
> 
> Additional responses MUST reset the Tc timer.
> 

Okay, that appears fine.

> 
>>
>> Then I wonder about the cases where the RTT is above 500 ms, should one
>> then scale this factor to be once per RTT?

What about this question?

>>
>> 9. Section 4:
>> "with the same Transaction ID"
>>
>> Why not use a new transaction ID for each sent packet? It would allow
>> tracking loss and determine RTT more reliable. All for the small cost of
>> keeping track of slightly more Transaction IDs?
> 
> Yes, new transaction ID will help to determine the packet loss and RTT.
> 

Yes, so what is preferable here? Doing cloned retransmission, or
generating new TIDs for each outgoing request?

> 
> 
>>
>> 10. Section 4.
>>   Liveness timer: If no packets have been received on the local port in
>>   Tr seconds, the WebRTC browser MUST inform the JavaScript that
>>   connectivity has been lost.  The JavaScript application will use this
>>   notification however it desires (e.g., cease transmitting to the
>>   remote peer, provide a notification to the user, etc.).  Note the
>>   definition of a received packet is liberal, and includes an SRTP
>>   packet that fails authentication, a STUN Binding Request with an
>>   invalid USERNAME or PASSWORD, or any other packet.
>>
>> I think this requires some considerations in regards to RTT. If the RTT
>> is 700 ms, high for a real-time app but not unheard of at all. Then a Tr
>> = 1 second would fire on a single loss.
> 
> Ok.  will start a discussion for this item in a separate email.
> 

Good

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From ron@debian.org  Fri Nov 15 04:13:02 2013
Return-Path: 
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 B64C611E8194 for ; Fri, 15 Nov 2013 04:13:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level: 
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, SARE_MILLIONSOF=0.315]
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 OAatB6f-gDox for ; Fri, 15 Nov 2013 04:12:57 -0800 (PST)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 664BC11E819F for ; Fri, 15 Nov 2013 04:12:56 -0800 (PST)
Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Nov 2013 22:42:55 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 2A61F4F8F3 for ; Fri, 15 Nov 2013 22:42:52 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6XOW2xYAql2j for ; Fri, 15 Nov 2013 22:42:49 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id C95594F902; Fri, 15 Nov 2013 22:42:49 +1030 (CST)
Date: Fri, 15 Nov 2013 22:42:49 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20131115121249.GS3245@audi.shelbyville.oz>
References: <20131114225633.GR3245@audi.shelbyville.oz> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 12:13:02 -0000

On Fri, Nov 15, 2013 at 04:46:39AM +0000, Mo Zanaty (mzanaty) wrote:
> On 11/14/13, 5:56 PM, Ron  wrote:
> 
> > Except the proposed Cisco binary deal isn't licencing the Nokia patents,
> or the Motorola patents, or any others, so they'd all still be free to
> sue anyone using that.
> 
> No licensor / licensee in the MPEG LA pool can sue anyone over H.264.
> Google is a licensee, so Motorola can no longer sue anyone over H.264.
> Nokia (like the old Motorola) is neither a licensor nor licensee, so it
> can sue.

Ah, thanks for the clarification on that.

> > How is this known and proven liability somehow less of a problem than
> > the absence of any such thing overshadowing VP8?
> 
> Half a cent is less of a problem than a permanent injunction.

It's only half a cent after you've shelled out the 6+ figures for the
high powered lawyers though - and even then only if you 'win'.

And it still means that anyone wanting to take advantage of the Cisco
offer _is_ going to need to negotiate a separate licence from them.
So I still don't see how this changes the original problem (even if
we ignore the other remaining problems).


Half a cent for each of millions of unpaying users is still effectively
a permanent injunction (or worse) for many of the projects that would
otherwise deploy WebRTC.


I'll consider it a sad outcome if we are forced into choosing H.261 here
too, but if it's the only option that "makes the patents evaporate" in a
way that satisfies the objectors to VP8, then it's not worse than an
outcome which limits video (and compliant WebRTC implementation) to only
people that the H.264 patent holders approve of or turn a blind eye to.

  Ron



From derhoermi@gmx.net  Fri Nov 15 04:50:07 2013
Return-Path: 
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 3676411E811D for ; Fri, 15 Nov 2013 04:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 iGRPmlkpeXDE for ; Fri, 15 Nov 2013 04:50:02 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8215B11E8116 for ; Fri, 15 Nov 2013 04:50:02 -0800 (PST)
Received: from netb ([47.67.181.38]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0M0Kp7-1VRHYy1rfJ-00uWqb for ; Fri, 15 Nov 2013 13:50:01 +0100
From: Bjoern Hoehrmann 
To: Gonzalo Camarillo 
Date: Fri, 15 Nov 2013 13:50:05 +0100
Message-ID: <5e5c891jdb3sam85hb1485ru3r5hj0pclg@hive.bjoern.hoehrmann.de>
References: <5283DFDC.4010906@ericsson.com>
In-Reply-To: <5283DFDC.4010906@ericsson.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:6eMNcONhJ6LvTEV9n2gIDbcY5B4BTPMraMg1fH5nQJrpPlsJNzs oi14EJDYtrs1A7M5hXjAb/SHUGMQCmx26tTufuaWcXJXQBFIUfxVI9CPbIOPIfdZdBHUOan gzSA6BZq/5gAjbvyRgvFSCOuo3Zgmc5oD9JCZY+YC2RDjKwsnZkAph0GklMoQOblRuLuR/x 6AiTNWLk3bLeKtIHUGcow==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 12:50:07 -0000

* Gonzalo Camarillo wrote:
>As you all know, we need to make progress regarding the selection of the
>MTI video codec. The following are some of the alternatives we have on
>the table:
>
> 1. All entities MUST support H.264
> 2. All entities MUST support VP8
> 3. All entities MUST support both H.264 and VP8
> 4. Browsers MUST support both H.264 and VP8
> 5. All entities MUST support either H.264 or VP8
> 6. All entities MUST support H.261
> 7. There is no MTI video codec
>
>If you want the group to consider additional alternatives to the ones
>above, please let the group know within the following *two weeks*.

Whatever the Working Group will eventually decide, I think it would be
bad if people could easily say "But they did not consider Theora!", so
I think it would be good to either list Theora as an alternative, or to
make sure any such a list for consideration by the Working Group does
mention Theora in some other form, like explaining why it is not listed
as an alternative.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From lgeyser@gmail.com  Fri Nov 15 05:03:04 2013
Return-Path: 
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 447D711E80F9 for ; Fri, 15 Nov 2013 05:03:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 27Mf2St+LQS1 for ; Fri, 15 Nov 2013 05:03:03 -0800 (PST)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 18FC611E80F1 for ; Fri, 15 Nov 2013 05:03:02 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id ep20so2775508lab.31 for ; Fri, 15 Nov 2013 05:03:02 -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=HDe6ioWS5mfrn+jZxqhTBZuDd+drtWf/ChWDgCQv33I=; b=StpKHvu5DAeMYC68sPmRa5HGLy/X4rJ6rMPbnB7mGjU8VnrDWsGSxlh5SOVBVvNCx1 jbyYpF2EQm3tr/jpQe4d309gfhNXauomiKH7nbM6nYSZBmacdgepqb1G+3M9qGcbv2Xa VR4rSZLSIKw/Md0lU7TDxwkgvBwCaYFtNVau2yQlFO1NxTvNDkV8wwRERI0JDVtQAuYt ziLeB51hWnxkH9oPoiZLQ5gCsLSQauGxFyyxlo7q9Do+C+Xrgh9PttGYEdLQ30sD2+oK sSl1By+COVWkwfxvAys5VuGpLMnCTchh9/LAD4/vkx7yO0GlJ9MPryatmoY+hYCwAMn+ PqZg==
MIME-Version: 1.0
X-Received: by 10.152.121.3 with SMTP id lg3mr4300222lab.0.1384520581900; Fri, 15 Nov 2013 05:03:01 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Fri, 15 Nov 2013 05:03:01 -0800 (PST)
In-Reply-To: <5e5c891jdb3sam85hb1485ru3r5hj0pclg@hive.bjoern.hoehrmann.de>
References: <5283DFDC.4010906@ericsson.com> <5e5c891jdb3sam85hb1485ru3r5hj0pclg@hive.bjoern.hoehrmann.de>
Date: Fri, 15 Nov 2013 15:03:01 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0112d16477ef6004eb36d181
Cc: Bjoern Hoehrmann 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 13:03:04 -0000

--089e0112d16477ef6004eb36d181
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1, Theora should be in the list.


On 15 November 2013 14:50, Bjoern Hoehrmann  wrote:

> * Gonzalo Camarillo wrote:
> >As you all know, we need to make progress regarding the selection of the
> >MTI video codec. The following are some of the alternatives we have on
> >the table:
> >
> > 1. All entities MUST support H.264
> > 2. All entities MUST support VP8
> > 3. All entities MUST support both H.264 and VP8
> > 4. Browsers MUST support both H.264 and VP8
> > 5. All entities MUST support either H.264 or VP8
> > 6. All entities MUST support H.261
> > 7. There is no MTI video codec
> >
> >If you want the group to consider additional alternatives to the ones
> >above, please let the group know within the following *two weeks*.
>
> Whatever the Working Group will eventually decide, I think it would be
> bad if people could easily say "But they did not consider Theora!", so
> I think it would be good to either list Theora as an alternative, or to
> make sure any such a list for consideration by the Working Group does
> mention Theora in some other form, like explaining why it is not listed
> as an alternative.
> --
> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr=
mann.de
> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld=
.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev=
.de/
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--089e0112d16477ef6004eb36d181
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    +1, Theora should be in the list.


    On 15 November 2013 14:50, B=
joern Hoehrmann <derhoermi@gmx.net> wrote:
    

    * Gonzalo Camarillo wrote:=

    
>As you all know, we need to make progress regarding the selection of th=
e
    
>MTI video codec. The following are some of the alternatives we have on<=
br>
>the table:
    
>
    
> 1. All entities MUST support H.264
    
> 2. All entities MUST support VP8
    
> 3. All entities MUST support both H.264 and VP8
    
> 4. Browsers MUST support both H.264 and VP8
    
> 5. All entities MUST support either H.264 or VP8
    
> 6. All entities MUST support H.261
    
> 7. There is no MTI video codec
    
>
    
>If you want the group to consider additional alternatives to the ones
>above, please let the group know within the following *two weeks*.
    

    

    Whatever the Working Group will eventually decide, I think it would b=
e
    
bad if people could easily say "But they did not consider Theora!"=
;, so
    
I think it would be good to either list Theora as an alternative, or to
    
make sure any such a list for consideration by the Working Group does
    
mention Theora in some other form, like explaining why it is not listed
    
as an alternative.
    
--
    
Bj=F6rn H=F6hrmann =B7 mailto:bjoern=
@hoehrmann.de =B7 http://bjoern.hoehrmann.de
    
Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.de
    
25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/
    

    _____________________=
__________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--089e0112d16477ef6004eb36d181--

From cowwoc@bbs.darktech.org  Fri Nov 15 05:43:33 2013
Return-Path: 
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 549D311E81A3 for ; Fri, 15 Nov 2013 05:43:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 Eqm0K4WFGkJZ for ; Fri, 15 Nov 2013 05:43:28 -0800 (PST)
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7E55E11E8185 for ; Fri, 15 Nov 2013 05:43:28 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id aq17so4737217iec.37 for ; Fri, 15 Nov 2013 05:43:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=VBARTe2SFrf0IXvHsPpFFj4jQ4mCLSvJlI3LFHPkoZM=; b=cu5XUloRJYDBqyuqICDW8acO07AXzKSS+e8LeYF4XCpe3PFlvTz9FgWiqNHObFFnkf 7e756IdOlfG7JI9dg17K2hvGQSzgJILbFvkCk1jv1stacH4n5rOShTTHspLayvPcN552 +KwsWcCPkhk8O0oKWXhFP9RP07wP+yqsyRlM3FhRIZ8eA5ROZ9/24TtltnxX3vBtZtqt J4oTegLup0IrZVMzxVHELrxOrgg+czJOB7mX2EgvghM/deZ1PnlEbgkW/yFYfXKRHJzG vi1dy/1vBass3sgYcJ8qDNdPEU25472H8Fh2A60Ew+Nl9jodTVWN3vHXLWD8R+IRsp3U 0sOA==
X-Gm-Message-State: ALoCoQl9FruHnuTeVXrux4UqLDueKJ865q94g+yeef+VcQMx+iRtsvcY6gWMXvOLJauF97F3sEXX
X-Received: by 10.50.13.9 with SMTP id d9mr4569713igc.25.1384523007777; Fri, 15 Nov 2013 05:43:27 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id v2sm3205849igz.3.2013.11.15.05.43.26 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 05:43:26 -0800 (PST)
Message-ID: <528624ED.1030801@bbs.darktech.org>
Date: Fri, 15 Nov 2013 08:43:09 -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: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080600000308050200080205"
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 13:43:33 -0000

This is a multi-part message in MIME format.
--------------080600000308050200080205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


As I've stated multiple times before in my own posts, "H.261" is a 
placeholder for "any codec for which IPR has expired".

Feel free to propose alternate codecs, and I believe this detail should 
be explicitly mentioned in the upcoming "vote". Meaning, the option that 
talks about H.261 being MTI should clarify we're talking about a 
placeholder.

Gili

On 14/11/2013 8:37 PM, Stephan Wenger wrote:
> Folks,
> Please don't consider H.261 and MPEG-1 part 2 as being in the same 
> league in terms of coding efficiency or network friendliness.  They 
> clearly are not.
> H.261 is what many call the first generation video coding standard. 
>  MPEG-1 (and MPEG-2) are second generation.
> MPEG-1 has half-pel motion compensation.  H.261 has not.
> MPEG-1 has B frames.  H.261 has not.
> MPEG-1 has (arbitrary sized) slices that can be used for MTU size 
> matching (although they are not commonly used for that purpose). 
>  H.261 has not.  Instead, H.261 has the Group Of Block picture 
> segmentation mechanism, that is clearly more optimized for parallel 
> processing than for MTU size matching.
> MPEG-1 allows for significantly larger motion vectors (necessitated by 
> B frames and the resulting longer prediction interval, but can be used 
> even in P frame only coding).
> MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF, and 4CIF 
> (in "still image" mode, designed for low frame rate application; could 
> run at high frame rate though).
> H.261 was ratified (in its first version) in 1988, and in the for all 
> practical purposes final version in 1989.  Most people believe that 
> all related patents have expired.
> MPEG-1 was ratified in late 1992.  Its "bug fix" successor MPEG-2 
> (which adds interlace support) was ratified less than a year later. 
>  There are at least two major disputes going on today regarding 
> technology allegedly infringed by a compliant implementation of 
> MPEG-2.  Based on my technical understanding, one of these 
> technologies is not in any way related to interlaced.
> Draw your own conclusions.
> Regards,
> Stephan
>
>
>
>
> From: Adam Roach >
> Date: Thursday, 14 November, 2013 at 15:22
> To: "rtcweb@ietf.org "  >
> Subject: Re: [rtcweb] H261/MPEG-1 video quality
>
> On 11/14/13 17:16, Adam Roach wrote:
>> # At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works 
>> out to 508 kbits/second total.
>
> Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime 
> seems to divide it by two for some reason, although the javascript 
> decode does the right thing). This works out to 254 kbps.
>
> /a
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------080600000308050200080205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
      As I've stated multiple times before in my own posts, "H.261" is a
      placeholder for "any codec for which IPR has expired".
    
      
    
      Feel free to propose alternate codecs, and I believe this detail
      should be explicitly mentioned in the upcoming "vote". Meaning,
      the option that talks about H.261 being MTI should clarify we're
      talking about a placeholder.
    
      
    
      Gili
    
      
    
      On 14/11/2013 8:37 PM, Stephan Wenger wrote:
    
    
    
    
    
      
      
    Folks,
    
      
    Please don’t consider H.261 and MPEG-1 part 2 as being in the
        same league in terms of coding efficiency or network
        friendliness.  They clearly are not.
    
      
    H.261 is what many call the first generation video coding
        standard.  MPEG-1 (and MPEG-2) are second generation.
    
      
    MPEG-1 has half-pel motion compensation.  H.261 has not.
    
      
    MPEG-1 has B frames.  H.261 has not.
    
      
    MPEG-1 has (arbitrary sized) slices that can be used for MTU
        size matching (although they are not commonly used for that
        purpose).  H.261 has not.  Instead, H.261 has the Group Of Block
        picture segmentation mechanism, that is clearly more optimized
        for parallel processing than for MTU size matching.
    
      
    MPEG-1 allows for significantly larger motion vectors
        (necessitated by B frames and the resulting longer prediction
        interval, but can be used even in P frame only coding).
    
      
    MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF,
        and 4CIF (in “still image” mode, designed for low frame rate
        application; could run at high frame rate though).
    
      
    H.261 was ratified (in its first version) in 1988, and in the
        for all practical purposes final version in 1989.  Most people
        believe that all related patents have expired.
    
      
    MPEG-1 was ratified in late 1992.  Its “bug fix” successor
        MPEG-2 (which adds interlace support) was ratified less than a
        year later.  There are at least two major disputes going on
        today regarding technology allegedly infringed by a compliant
        implementation of MPEG-2.  Based on my technical understanding,
        one of these technologies is not in any way related to
        interlaced.  
    
      
    Draw your own conclusions.
    
      
    Regards,
    
      
    Stephan
    
      

    
      
    
      

    
      
    
      

    
      
    
      

    
      
    
      
        
    
          From: Adam Roach <adam@nostrum.com>
    
          Date: Thursday, 14
          November, 2013 at 15:22 
    
          To: "rtcweb@ietf.org"
          <rtcweb@ietf.org>
    
          Subject: Re: [rtcweb]
          H261/MPEG-1 video quality
    
        
    
        

    
        
    
        
    
          
    
            
    On 11/14/13 17:16, Adam Roach
              wrote:
    
            
    
            
    
              
  • At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
                encoding works out to 508 kbits/second total.
              
    • 
            
    
            
    
            Whoops, I messed up my math. It's 148 seconds long, not 74
            (Quicktime seems to divide it by two for some reason,
            although the javascript decode does the right thing). This
            works out to 254 kbps.
    
            
    
            /a
    
          
    
        
    
          
      
    
      
    
      
    
      
    _______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

    
    
    
    
    
  


--------------080600000308050200080205--

From harald@alvestrand.no  Fri Nov 15 05:44:13 2013
Return-Path: 
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 5704F11E81A4 for ; Fri, 15 Nov 2013 05:44:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 C22NhSg6m-X2 for ; Fri, 15 Nov 2013 05:44:08 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F57311E81B1 for ; Fri, 15 Nov 2013 05:44:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6597139E333 for ; Fri, 15 Nov 2013 14:44:03 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj6dGskh0gS5 for ; Fri, 15 Nov 2013 14:44:02 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6FC5639E31B for ; Fri, 15 Nov 2013 14:44:02 +0100 (CET)
Message-ID: <52862521.9090706@alvestrand.no>
Date: Fri, 15 Nov 2013 14:44:01 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 	 <4A450D6F-603B-4A9D-9C1F-531D176F465A@apple.com>
In-Reply-To: <4A450D6F-603B-4A9D-9C1F-531D176F465A@apple.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 13:44:13 -0000

On 11/15/2013 03:10 AM, David Singer wrote:
> On Nov 14, 2013, at 23:57 , Jonathan Rosenberg  wrote:
>
>> I agree with others that SHOULD implement both, or other variations on SHOULD, are not helpful. They will anyway be ignored and amount to more or less the no-interop situation we're in if we continue on the current path and have no consensus.  No consensus means the various players doing as they prefer, which is what they'd do if there is a SHOULD.
> I don't agree.  I think that MUST implement at least one of them, and SHOULD do both, provides both clear guidance as to the interop points, and clear pressure to implement both.  I think it's as close to interop as we are likely to get.

I agree that the addition of SHOULD statements makes a difference in 
perception.

There's been a push at times to have SHOULD statements accompanied with 
descriptions of the conditions under which they apply; in this case, one 
could imagine a statement like "MUST implement VP8, and SHOULD implement 
H.264 (MUST unless using a business model where it's impossible to 
comply with the requirements of the available licenses for H.264 IPR)".

Focusing on the naked MUST statements seems to me to be a strategy that 
emphasizes the battle lines.



From cowwoc@bbs.darktech.org  Fri Nov 15 05:47:38 2013
Return-Path: 
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 34ED411E81A7 for ; Fri, 15 Nov 2013 05:47:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 vaK4zgDqTsKV for ; Fri, 15 Nov 2013 05:47:32 -0800 (PST)
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id DBDDE11E81A2 for ; Fri, 15 Nov 2013 05:47:31 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id aq17so4881489iec.9 for ; Fri, 15 Nov 2013 05:47:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rBsEacv8rjGxESI/3vI9gNu9HP04SGBNpY/S2zDMdBs=; b=jpiiIC+nTLnxxmK8z+e96G07Yzw9IsgivKBWtvt4UOZdGv+SIsYK22RJ3emfk1vmnc 5RslfEOOrQ/7s2aj2gNAHyTX6tMvv+XFzEwT4zWLzq3JVDG9ovvZW39tThiYCJWXpglZ Xjcb3r0snJmZ0BISUusNzlWNwi85XL6zxCKis/LmNSVpMVLDxzf/jblWZm7g6J8JXwMa C/yrI9XV8Iro61YF58HVDyUwg6QttiYNR1l8JRu/RQgBjGycyVOUkWHq/wHKMxzk3y1x zbmSRrY2eBF1WTLs7L9MWGMiIudVbnxxMG5TYRvz4XE7wVCzaM8GDLXDPC51qBone91P 1xUw==
X-Gm-Message-State: ALoCoQmp/7ij099p7VV077Metd2gfZKsQeHO6FVCPOjzhVpQQ9oZQKR+j+a75BZC7U2eqaioMgYm
X-Received: by 10.50.27.104 with SMTP id s8mr4552020igg.4.1384523251332; Fri, 15 Nov 2013 05:47:31 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id y10sm3269262igl.4.2013.11.15.05.47.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 05:47:30 -0800 (PST)
Message-ID: <528625E0.1030203@bbs.darktech.org>
Date: Fri, 15 Nov 2013 08:47:12 -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: rtcweb@ietf.org
References: <52855B35.3080605@nostrum.com>			 <5285CCCE.6040906@ericsson.com>
In-Reply-To: <5285CCCE.6040906@ericsson.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 13:47:38 -0000

Magnus,

Couldn't we alter the option with H.261 to state that we're proposing an 
IPR-expired codec *like* H.261? I don't think we need to decide at this 
moment which precise codec that would be.

Gili

On 15/11/2013 2:27 AM, Magnus Westerlund wrote:
> On 2013-11-15 06:39, Monty Montgomery wrote:
>> Stephan just implied strongly they haven't, despite the 20 years.
>>
>> And, BTW, I was serious when I mentioned Theora earlier as well.
> If you want this on the list of alternatives, please send an email in
> the other thread with the MUST statement. I would also request that you
> include a reference to the codec, and any needed scoping of your proposal.
>
> Regards
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From cowwoc@bbs.darktech.org  Fri Nov 15 05:52:14 2013
Return-Path: 
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 D15A611E81A2 for ; Fri, 15 Nov 2013 05:52:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 SkKFW7-1h4qN for ; Fri, 15 Nov 2013 05:52:10 -0800 (PST)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 982C911E818C for ; Fri, 15 Nov 2013 05:52:10 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id u16so4538670iet.6 for ; Fri, 15 Nov 2013 05:52:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=o5TvLMhceygdcdvRclTqbs53v+3bQ+iZA1rJZOMmVKM=; b=lAshD/aMaBEZwdQG3uL19dH9bqgIqc0IC54S0/ju+Ip0YjVmzPBhWHGxtQO6RtS6VM 0/dRpGSc1RUBRbxoSEtVWgu7P3CTE1JsJk/bJBwOLgY1eKFb5w77RHqK/r8LjTqlb/zi wxB2q8WliPupHSI2MV0cNN8qAcMOjQ6oAf2143sfbGMAr5loSt/qAkRQhMtmx6J4voGA hKNbsykCLYwZOuW2NY7HVAfqszo1VgAPmiOQW3kyX1l044xJgmVr6aMkKrQdod1TGqGM frpIvC8IQE+X/44QZDxA64Gesc4NxN8oG3OcBn4f2vlYFpJvcXxEJVOV+LgXNsxD/f0Y cPig==
X-Gm-Message-State: ALoCoQksCzhTbmR7JL6udWJky+VlLPZsIF/t02rjSvs6BAkZBtt3HAeAKfCcNQorMChjwUHMEAca
X-Received: by 10.50.4.65 with SMTP id i1mr3797464igi.9.1384523529996; Fri, 15 Nov 2013 05:52:09 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id l7sm3247481igx.2.2013.11.15.05.52.08 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 05:52:09 -0800 (PST)
Message-ID: <528626F7.1050101@bbs.darktech.org>
Date: Fri, 15 Nov 2013 08:51:51 -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: rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com>	<5e5c891jdb3sam85hb1485ru3r5hj0pclg@hive.bjoern.hoehrmann.de> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090105000206030305060909"
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 13:52:14 -0000

This is a multi-part message in MIME format.
--------------090105000206030305060909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


+1 with the caveat that I think option 6 should simply state:

6. All entities MUST support a specific IPR-expired codec (to be decided 
at a later meeting) such as H.261 or Theora.

The goal remains the same. I don't think people voting for this option 
need to know up-front what the specific codec would be so long as we 
explain that we'll try to pick the best codec possible. Correct me if 
I'm wrong :)

Gili

On 15/11/2013 8:03 AM, Leon Geyser wrote:
> +1, Theora should be in the list.
>
>
> On 15 November 2013 14:50, Bjoern Hoehrmann  > wrote:
>
>     * Gonzalo Camarillo wrote:
>     >As you all know, we need to make progress regarding the selection
>     of the
>     >MTI video codec. The following are some of the alternatives we
>     have on
>     >the table:
>     >
>     > 1. All entities MUST support H.264
>     > 2. All entities MUST support VP8
>     > 3. All entities MUST support both H.264 and VP8
>     > 4. Browsers MUST support both H.264 and VP8
>     > 5. All entities MUST support either H.264 or VP8
>     > 6. All entities MUST support H.261
>     > 7. There is no MTI video codec
>     >
>     >If you want the group to consider additional alternatives to the ones
>     >above, please let the group know within the following *two weeks*.
>
>     Whatever the Working Group will eventually decide, I think it would be
>     bad if people could easily say "But they did not consider Theora!", so
>     I think it would be good to either list Theora as an alternative,
>     or to
>     make sure any such a list for consideration by the Working Group does
>     mention Theora in some other form, like explaining why it is not
>     listed
>     as an alternative.
>     --
>     Björn Höhrmann · mailto:bjoern@hoehrmann.de
>      · http://bjoern.hoehrmann.de
>     Am Badedeich 7 · Telefon: +49(0)160/4415681
>      · http://www.bjoernsworld.de
>     25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·
>     http://www.websitedev.de/
>     _______________________________________________
>     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


--------------090105000206030305060909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
      +1 with the caveat that I think option 6 should simply state:
    
      
    
      6. All entities MUST support a specific IPR-expired codec (to be
      decided at a later meeting) such as H.261 or Theora.
    
      
    
      The goal remains the same. I don't think people voting for this
      option need to know up-front what the specific codec would be so
      long as we explain that we'll try to pick the best codec possible.
      Correct me if I'm wrong :)
    
      
    
      Gili
    
      
    
      On 15/11/2013 8:03 AM, Leon Geyser wrote:
    
    
    
    
    
      
    +1, Theora should be in the list.
    
      
    
      

    
        
    
        
    On 15 November 2013 14:50, Bjoern
          Hoehrmann <derhoermi@gmx.net>
          wrote:
    
          
    
            
    * Gonzalo Camarillo wrote:
    
              >As you all know, we need to make progress regarding
              the selection of the
    
              >MTI video codec. The following are some of the
              alternatives we have on
    
              >the table:
    
              >
    
              > 1. All entities MUST support H.264
    
              > 2. All entities MUST support VP8
    
              > 3. All entities MUST support both H.264 and VP8
    
              > 4. Browsers MUST support both H.264 and VP8
    
              > 5. All entities MUST support either H.264 or VP8
    
              > 6. All entities MUST support H.261
    
              > 7. There is no MTI video codec
    
              >
    
              >If you want the group to consider additional
              alternatives to the ones
    
              >above, please let the group know within the following
              *two weeks*.
    
              
    
            
    
            Whatever the Working Group will eventually decide, I think
            it would be
    
            bad if people could easily say "But they did not consider
            Theora!", so
    
            I think it would be good to either list Theora as an
            alternative, or to
    
            make sure any such a list for consideration by the Working
            Group does
    
            mention Theora in some other form, like explaining why it is
            not listed
    
            as an alternative.
    
            --
    
                Björn Höhrmann · mailto:bjoern@hoehrmann.de
                · http://bjoern.hoehrmann.de
    
                Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
    
                25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
    
                  
            
    
              
    _______________________________________________
    
                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

    
    
    
    
    
  


--------------090105000206030305060909--

From cowwoc@bbs.darktech.org  Fri Nov 15 05:53:06 2013
Return-Path: 
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 271AA11E81A2 for ; Fri, 15 Nov 2013 05:53:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1]
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 kSFK4ezYvVfh for ; Fri, 15 Nov 2013 05:53:02 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1CC111E818C for ; Fri, 15 Nov 2013 05:53:01 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id to1so4731248ieb.31 for ; Fri, 15 Nov 2013 05:53:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=vNT3bywsQKqxPMqaghpnmc6XSOPEepnAM3ovzVuFSCE=; b=UnPN/jeaDGl5VoaDXVruAgF6ZR1ESmXw//aoKZfu32zq7f9FTopTJUbGT+4n73Vnf9 59dQnDjYFcrfBIUfykNmUdbV8s6sAqNaeLMxdvwwD3IuI9ZaGQRIB42jBpvoCnPMjSe/ i48T1qVK9t5rhPaQE7sdfgsS8g8KQVsG8wMeRMu2ONb3mCXGSW7+j1L3zLxNUcnwe1wW c1kEVZpAb2ljsS5t7V4/GdTJJJOWk8Ns4OxLOWerc2Z/5yGK9DV2u+q141rm0f3Hj2oE 0swIcsEI5hrTx8jWKnA+itOE4+bOZE4NhfeY+MwAHvpY6puVi73EWlPm3X3gQwMwM7Tv Hm7g==
X-Gm-Message-State: ALoCoQmNFFgH8jEowOR+px2Z6TQElc/jRIvVPiZESGXRv6lQMmiaKHxztTML1OvIAGl3QMColUS2
X-Received: by 10.50.141.133 with SMTP id ro5mr4499493igb.35.1384523581452; Fri, 15 Nov 2013 05:53:01 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id hv5sm3214008igb.9.2013.11.15.05.53.00 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 05:53:00 -0800 (PST)
Message-ID: <5286272B.5000005@bbs.darktech.org>
Date: Fri, 15 Nov 2013 08:52:43 -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: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com>	<5285209D.7020407@googlemail.com>		 <528559E4.3020903@nostrum.com>
In-Reply-To: <528559E4.3020903@nostrum.com>
Content-Type: multipart/alternative; boundary="------------090605020506010408070303"
Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 13:53:06 -0000

This is a multi-part message in MIME format.
--------------090605020506010408070303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Excellent work Adam. I can't speak for others, but at 254 kbps 
(corrected figure from your follow-up post) H.261 is definitely "good 
enough" and better than an audio-only connection.

Gili

On 14/11/2013 6:16 PM, Adam Roach wrote:
> I sent a reply to this earlier, but just now realized that it went 
> only to Justin, not to the list.
>
>
> On 11/14/13 13:59, Justin Uberti wrote:
>> Thanks, this is interesting. Is the ffmpeg 261 encoder limited to 
>> CIF/QCIF, or can you specify arbitrary sizes?
>
> It looks like the ffmpeg mpeg-1 coder works for arbitrary sizes. I'm 
> not sure what the difference between mpeg-1 and H.261 are, though, so 
> we could be talking apples and oranges (or at least apples and pears) 
> here. I'll note that mpeg-1 came out in 1991, which is a good 22 years 
> in the past. I'm not drawing IPR conclusions for you, but invite you 
> to ponder the implications yourself.
>
> Following Maik's lead with the mpeg-1 js decoder, I put this together:
>
> https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>
> ...with this commandline:
>
>   ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp rd 
> -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k maven.mpg
>
> I don't really understand most of those options (I just cribbed them 
> from Maik's example) or whether any of them would introduce more 
> latency than is reasonable for a real-time conversation, but I will 
> observe:
>
>  1. The encoder claims that it was performing on the order of 90 - 100
>     fps on my (admittedly modern) system;
>  2. The resolution is 640x360 (somewhat larger than DCIF);
>  3. The video is not, to my eye, unusable (draw your own conclusions,
>     as it's clearly not as nice as modern codecs);
>  4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding
>     works out to 508 kbits/second total.
>
>
> Source video here, and NASA is acknowledged as the source of the 
> material contained therein: http://www.youtube.com/watch?v=ijAO0FFExx0
>
> /a
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------090605020506010408070303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
      Excellent work Adam. I can't speak for others, but at 254 kbps
      (corrected figure from your follow-up post) H.261 is definitely
      "good enough" and better than an audio-only connection.
    
      
    
      Gili
    
      
    
      On 14/11/2013 6:16 PM, Adam Roach wrote:
    
    
    
    
    
      
      I sent a reply to this earlier, but just now realized that it went
      only to Justin, not to the list.
    
      
    
      
    
      
    
        
    On 11/14/13 13:59, Justin Uberti
          wrote:
    
        
    
        
    
          
    Thanks, this is interesting. Is the ffmpeg 261
            encoder limited to CIF/QCIF, or can you specify arbitrary
            sizes?
    
        
    
        
    
        It looks like the ffmpeg mpeg-1 coder works for arbitrary sizes.
        I'm not sure what the difference between mpeg-1 and H.261 are,
        though, so we could be talking apples and oranges (or at least
        apples and pears) here. I'll note that mpeg-1 came out in 1991,
        which is a good 22 years in the past. I'm not drawing IPR
        conclusions for you, but invite you to ponder the implications
        yourself.
    
        
    
        Following Maik's lead with the mpeg-1 js decoder, I put this
        together:
    
        
    
        https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
    
        
    
        ...with this commandline:
    
        
    
          ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp rd
        -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k
        maven.mpg
    
        
    
        I don't really understand most of those options (I just cribbed
        them from Maik's example) or whether any of them would introduce
        more latency than is reasonable for a real-time conversation,
        but I will observe:
    
        
      
          
    1. The encoder claims that it was performing on the order of
            90 - 100 fps on my (admittedly modern) system;
      
          
      2. 
          
    2. The resolution is 640x360 (somewhat larger than DCIF);
      3. 
          
    3. The video is not, to my eye, unusable (draw your own
            conclusions, as it's clearly not as nice as modern codecs);
      
          
      4. 
          
    4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
            encoding works out to 508 kbits/second total.
      5. 
        
    
        

    
        
    
        Source video here, and NASA is acknowledged as the source of the
        material contained therein: http://www.youtube.com/watch?v=ijAO0FFExx0
    
        
    
        /a
    
      
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

    
    
    
    
    
  


--------------090605020506010408070303--

From harald@alvestrand.no  Fri Nov 15 06:22:16 2013
Return-Path: 
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 77F1211E8147 for ; Fri, 15 Nov 2013 06:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 Dc9VCpGlO84Y for ; Fri, 15 Nov 2013 06:22:11 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4B62511E80F5 for ; Fri, 15 Nov 2013 06:22:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EBD5139E336 for ; Fri, 15 Nov 2013 15:22:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtO0Us8CjVIh for ; Fri, 15 Nov 2013 15:22:10 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 401BC39E31B for ; Fri, 15 Nov 2013 15:22:10 +0100 (CET)
Message-ID: <52862E10.8000506@alvestrand.no>
Date: Fri, 15 Nov 2013 15:22:08 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52855B35.3080605@nostrum.com>				<5285CCCE.6040906@ericsson.com> <528625E0.1030203@bbs.darktech.org>
In-Reply-To: <528625E0.1030203@bbs.darktech.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 14:22:16 -0000

On 11/15/2013 02:47 PM, cowwoc wrote:
> Magnus,
>
> Couldn't we alter the option with H.261 to state that we're proposing 
> an IPR-expired codec *like* H.261? I don't think we need to decide at 
> this moment which precise codec that would be.

If the proposal isn't for a concrete codec, it's impossible to evaluate.

Please - if you want this option to be on the table, make it a real 
option, not a "someone else should do the work necessary to figure out 
if it's a real option".




From magnus.westerlund@ericsson.com  Fri Nov 15 06:23:02 2013
Return-Path: 
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 CE6F711E80F5 for ; Fri, 15 Nov 2013 06:23:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.274
X-Spam-Level: 
X-Spam-Status: No, score=-104.274 tagged_above=-999 required=5 tests=[AWL=-1.675, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 evtEMbK4ME2w for ; Fri, 15 Nov 2013 06:22:56 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63921F99FD for ; Fri, 15 Nov 2013 06:22:56 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-95-52862e3e0a53
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D7.D6.27941.E3E26825; Fri, 15 Nov 2013 15:22:55 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.328.9; Fri, 15 Nov 2013 15:22:54 +0100
Message-ID: <52862E34.50309@ericsson.com>
Date: Fri, 15 Nov 2013 15:22:44 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: cowwoc , 
References: <5283DFDC.4010906@ericsson.com>	<5e5c891jdb3sam85hb1485ru3r5hj0pclg@hive.bjoern.hoehrmann.de>	 <528626F7.1050101@bbs.darktech.org>
In-Reply-To: <528626F7.1050101@bbs.darktech.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3Vtdery3I4McXZoszN/+zW6z9187u wOTxZMJ0do8lS34yBTBFcdmkpOZklqUW6dslcGW8WrqeqeAcX8X1nkXsDYxPuLsYOTkkBEwk Fvz5zwJhi0lcuLeerYuRi0NI4AijxL8rPSwQznJGidMH1rCBVPEKaEoc2L+IGcRmEVCV6Dsx lRXEZhOwkLj5oxGsRlQgWOL8q8XsEPWCEidnPgEaxMEhImAu8ehuJYgpLGApceG4CcT4S4wS W25NByvhFDCQmNKhD2JKCIhL9DQGgQxhFtCTmHK1hRHClpdo3job7AAhAW2JhqYO1gmMgrOQ 7JqFpGUWkpYFjMyrGDmKU4uTctONDDYxAgPy4JbfFjsYL/+1OcQozcGiJM778a1zkJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbG7c1CGl/+32jmS1T9sO79DIfJ5yMF1dTKHSVEZza5O4il VwVZH1/RlZXFKvE7p3l+tOyltpnf/Q6F67SrH/XQCXIU/MR0TCpJ+9SGyw+es893VYnpWVZ1 63HtpV+75tSq9kk/9/qfpj7z+kyRb6lH3aKt2AtOxp/Rcu6ZEXy++HmZ08Iz0UlKLMUZiYZa zEXFiQBlH46+FgIAAA==
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 14:23:02 -0000

On 2013-11-15 14:51, cowwoc wrote:
> 
> +1 with the caveat that I think option 6 should simply state:
> 
> 6. All entities MUST support a specific IPR-expired codec (to be decided
> at a later meeting) such as H.261 or Theora.
> 
> The goal remains the same. I don't think people voting for this option
> need to know up-front what the specific codec would be so long as we
> explain that we'll try to pick the best codec possible. Correct me if
> I'm wrong :)

I would believe there are a lot of people in the WG that consider the
IPR risks between Theora and H.261 significantly different. I realize
that list each alternative code will result in a significantly longer
list, but at the same time, I don't see how the above MUST statement
allows the WG to conclude on video codec selection. If we would agree on
the above, we would spend another year discussing our IPR beliefs around
various codecs. From that perspective I do think there is better to have
the individuals in the WG form their own opinions regarding an explicit
proposal.

At the same time, I would recommend that the people who believe in the
above option, coming to an agreement now, before the process starts, on
which codec alternative they want to support. This is after all also a
question of how to best trade IPR risk vs capability and quality per
bit. Thus improving that options chance.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From kaiduanx@gmail.com  Fri Nov 15 06:51:03 2013
Return-Path: 
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 290AA11E8145 for ; Fri, 15 Nov 2013 06:51:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Level: 
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315]
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 15YJJ9u824Ml for ; Fri, 15 Nov 2013 06:51:02 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD3111E8117 for ; Fri, 15 Nov 2013 06:51:02 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id f4so2541287wiw.1 for ; Fri, 15 Nov 2013 06:51:01 -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=E2UkF2vut8f8W3+SL6p3ND5G0vezDeQjPtXQPz8MgY4=; b=Tji8Oxo/mV2gay6PiGWAwHo9HeejeIVSZSbDIIvc4Ua6mFydGUqr7otYjjY15Wpp2N Yz2WiVxDwQP67apZ0uYcF3mlf99d2GG+kltb+tHQdqcM1L063D2Es2pHM648HJDBp0Nf ShYQLprAc60a/eg5fRzRInY/9dAg0ADkLodC0cLUTKZZfaJAeJdG9ZAlsvQbsva5t+ba OXrXkC0MXTsPtRbffAupfU7eKDpnjwHxqHIEIYLL45NuBH+qj9s7EuCOQWUXXrMpVc4h xhWOt1YQnTRnJAeBYWt97cY5mWXtOAT+gynG3UFFgOLcf09B6K9xuF7xbToxGUw1N/4z xzKw==
MIME-Version: 1.0
X-Received: by 10.180.107.193 with SMTP id he1mr7628858wib.50.1384527061163; Fri, 15 Nov 2013 06:51:01 -0800 (PST)
Received: by 10.216.183.202 with HTTP; Fri, 15 Nov 2013 06:51:01 -0800 (PST)
In-Reply-To: <20131115121249.GS3245@audi.shelbyville.oz>
References: <20131114225633.GR3245@audi.shelbyville.oz>  <20131115121249.GS3245@audi.shelbyville.oz>
Date: Fri, 15 Nov 2013 09:51:01 -0500
Message-ID: 
From: Kaiduan Xie 
To: Ron 
Content-Type: multipart/alternative; boundary=e89a8f234c03a9bee904eb3853cd
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 14:51:03 -0000

--e89a8f234c03a9bee904eb3853cd
Content-Type: text/plain; charset=ISO-8859-1

For all the projects/products built upon webrtc, they better focus on more
how to grow their own business to become profitable and sustainable first.
If you get sued in the future, congratulations to you, your business has
become big enough.

/Kaiduan


On Fri, Nov 15, 2013 at 7:12 AM, Ron  wrote:

> On Fri, Nov 15, 2013 at 04:46:39AM +0000, Mo Zanaty (mzanaty) wrote:
> > On 11/14/13, 5:56 PM, Ron  wrote:
> >
> > > Except the proposed Cisco binary deal isn't licencing the Nokia
> patents,
> > or the Motorola patents, or any others, so they'd all still be free to
> > sue anyone using that.
> >
> > No licensor / licensee in the MPEG LA pool can sue anyone over H.264.
> > Google is a licensee, so Motorola can no longer sue anyone over H.264.
> > Nokia (like the old Motorola) is neither a licensor nor licensee, so it
> > can sue.
>
> Ah, thanks for the clarification on that.
>
> > > How is this known and proven liability somehow less of a problem than
> > > the absence of any such thing overshadowing VP8?
> >
> > Half a cent is less of a problem than a permanent injunction.
>
> It's only half a cent after you've shelled out the 6+ figures for the
> high powered lawyers though - and even then only if you 'win'.
>
> And it still means that anyone wanting to take advantage of the Cisco
> offer _is_ going to need to negotiate a separate licence from them.
> So I still don't see how this changes the original problem (even if
> we ignore the other remaining problems).
>
>
> Half a cent for each of millions of unpaying users is still effectively
> a permanent injunction (or worse) for many of the projects that would
> otherwise deploy WebRTC.
>
>
> I'll consider it a sad outcome if we are forced into choosing H.261 here
> too, but if it's the only option that "makes the patents evaporate" in a
> way that satisfies the objectors to VP8, then it's not worse than an
> outcome which limits video (and compliant WebRTC implementation) to only
> people that the H.264 patent holders approve of or turn a blind eye to.
>
>   Ron
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--e89a8f234c03a9bee904eb3853cd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    For all the projects/products built upon webrtc, they bett=
er focus on more how to grow their own business to become profitable and su=
stainable first. If you get sued in the future, congratulations to you, you=
r business has become big enough.
    

    /Kaiduan


    On Fri, Nov 15, 2013 at 7:12 AM, Ron <ron@debian.org> wrote:
    

    On Fri, Nov 15, 2013 at 04=
:46:39AM +0000, Mo Zanaty (mzanaty) wrote:
    
> On 11/14/13, 5:56 PM, Ron <    ron@de=
bian.org> wrote:
    
>
    

    > > Except the proposed Cisco binary deal isn=
't licencing the Nokia patents,
    
> or the Motorola patents, or any others, so they'd all still be fre=
e to
    
> sue anyone using that.
    
>
    
> No licensor / licensee in the MPEG LA pool can sue anyone over H.264.<=
br>
> Google is a licensee, so Motorola can no longer sue anyone over H.264.=

    
> Nokia (like the old Motorola) is neither a licensor nor licensee, so i=
t
    
> can sue.
    

    

    Ah, thanks for the clarification on that.
    


    
> > How is this known and proven liability somehow less of a problem =
than
    
> > the absence of any such thing overshadowing VP8?
    
>
    
> Half a cent is less of a problem than a permanent injunction.
    

    

    It's only half a cent after you've shelled out the 6+ figures=
 for the
    
high powered lawyers though - and even then only if you 'win'.
    

    
And it still means that anyone wanting to take advantage of the Cisco
    
offer _is_ going to need to negotiate a separate licence from them.
    
So I still don't see how this changes the original problem (even if
    
we ignore the other remaining problems).
    

    

    
Half a cent for each of millions of unpaying users is still effectively
    
a permanent injunction (or worse) for many of the projects that would
    
otherwise deploy WebRTC.
    

    

    
I'll consider it a sad outcome if we are forced into choosing H.261 her=
e
    
too, but if it's the only option that "makes the patents evaporate=
" in a
    
way that satisfies the objectors to VP8, then it's not worse than an
outcome which limits video (and compliant WebRTC implementation) to only
people that the H.264 patent holders approve of or turn a blind eye to.
    


    
=A0 Ron
    

    

    
_______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--e89a8f234c03a9bee904eb3853cd--

From maikmerten@googlemail.com  Fri Nov 15 07:17:17 2013
Return-Path: 
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 B47A211E80F5 for ; Fri, 15 Nov 2013 07:17:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 v066V6fu2xVS for ; Fri, 15 Nov 2013 07:17:17 -0800 (PST)
Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8E08F11E80E7 for ; Fri, 15 Nov 2013 07:17:16 -0800 (PST)
Received: by mail-bk0-f51.google.com with SMTP id my10so1037117bkb.10 for ; Fri, 15 Nov 2013 07:17:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=OuYF8FO/xvt4QE7E0SREOzfdxaniUxanZTXADDPOppY=; b=JFO6s217+8vXYSzaxXOX/aCxwcCXfYAAYaTLXQOiHZ8sP7qujSXWUTTnC89uWN5kCG FpJqXQkiaAwSQKjhcM9TXqF8pDgesSGSbgk0bEGZ8hH814p8z2e4cMXsNeujJfvpJFtZ wh6rq2MYXQStDqLZPliw2I4mnth24mjmRnHGhXkKVKJ/nsndvM7U3YbY9q8Xu8rV2Rwh 5GXVQQrU1b9vInDJ/1BXNPT4taUQxE0Okoh5WgzZjT/SZdzGlCrTkRgAqrId9hrUssgK hIXxWKXe3WAUy+aWA5vCKF1mOwSM0uCOxjS/1fvCnxmRIWBTuRsU64IfQP00pbuUIHZz VPOQ==
X-Received: by 10.204.247.10 with SMTP id ma10mr62924bkb.63.1384528635530; Fri, 15 Nov 2013 07:17:15 -0800 (PST)
Received: from [192.168.2.101] (dslb-088-078-139-230.pools.arcor-ip.net. [88.78.139.230]) by mx.google.com with ESMTPSA id pk7sm7331769bkb.2.2013.11.15.07.17.13 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 07:17:14 -0800 (PST)
Message-ID: <52863AF8.1060200@googlemail.com>
Date: Fri, 15 Nov 2013 16:17:12 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com>	<5285209D.7020407@googlemail.com>			<528559E4.3020903@nostrum.com> <5286272B.5000005@bbs.darktech.org>
In-Reply-To: <5286272B.5000005@bbs.darktech.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 15:17:17 -0000

As pointed out by Stephan and after investigating a bit on the format 
specifics I feel compelled to state that H.261 and MPEG-1 are indeed 
different enough from each another so that performance evaluations on 
one codec cannot directly be transferred to the other. I'm still tempted 
to assume that CIF H.261 can deliver acceptable quality for talking head 
scenarios at ~256 kbit/s - however, I've yet to find a reliable H.261 
encoder implementation with up-to-date psychovisual optimizations to 
generate actual test vectors.

Best regards,

Maik

Am 15.11.2013 14:52, schrieb cowwoc:
>
> Excellent work Adam. I can't speak for others, but at 254 kbps
> (corrected figure from your follow-up post) H.261 is definitely "good
> enough" and better than an audio-only connection.
>
> Gili
>
> On 14/11/2013 6:16 PM, Adam Roach wrote:
>> I sent a reply to this earlier, but just now realized that it went
>> only to Justin, not to the list.
>>
>>
>> On 11/14/13 13:59, Justin Uberti wrote:
>>> Thanks, this is interesting. Is the ffmpeg 261 encoder limited to
>>> CIF/QCIF, or can you specify arbitrary sizes?
>>
>> It looks like the ffmpeg mpeg-1 coder works for arbitrary sizes. I'm
>> not sure what the difference between mpeg-1 and H.261 are, though, so
>> we could be talking apples and oranges (or at least apples and pears)
>> here. I'll note that mpeg-1 came out in 1991, which is a good 22 years
>> in the past. I'm not drawing IPR conclusions for you, but invite you
>> to ponder the implications yourself.
>>
>> Following Maik's lead with the mpeg-1 js decoder, I put this together:
>>
>> https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>>
>> ...with this commandline:
>>
>>   ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp rd
>> -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k maven.mpg
>>
>> I don't really understand most of those options (I just cribbed them
>> from Maik's example) or whether any of them would introduce more
>> latency than is reasonable for a real-time conversation, but I will
>> observe:
>>
>>  1. The encoder claims that it was performing on the order of 90 - 100
>>     fps on my (admittedly modern) system;
>>  2. The resolution is 640x360 (somewhat larger than DCIF);
>>  3. The video is not, to my eye, unusable (draw your own conclusions,
>>     as it's clearly not as nice as modern codecs);
>>  4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding
>>     works out to 508 kbits/second total.
>>
>>
>> Source video here, and NASA is acknowledged as the source of the
>> material contained therein: http://www.youtube.com/watch?v=ijAO0FFExx0
>>
>> /a
>>
>>
>>
>> _______________________________________________
>> 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
>


From cowwoc@bbs.darktech.org  Fri Nov 15 07:39:34 2013
Return-Path: 
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 5894811E8211 for ; Fri, 15 Nov 2013 07:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level: 
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 6xxp1fJvmwpB for ; Fri, 15 Nov 2013 07:39:28 -0800 (PST)
Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id 108BE11E81F0 for ; Fri, 15 Nov 2013 07:37:29 -0800 (PST)
Received: by mail-ie0-f176.google.com with SMTP id x13so5107509ief.35 for ; Fri, 15 Nov 2013 07:37:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hUpPgIsVEMCm1MLcENybjiuymtwh9X95VuuvIAPYuUM=; b=EQUzVEIE8We8Sf8mVHqE5Az7FKdDvVd7kO4cOYpBk7uYYfSt7wJopz4A6tKNt9wftd coNi3kVcvzZTzZibUCXfy9kTE0+WtPKFBoiZpve9KxlAV9s2Axz7qFAcYbdtV9QJSQUm CTg2PKJ+moFIzJSvd0BAYZH1A16XaZWCIG8N0wxexr1wr9+dvYK82CIN2nN90YTUwbkg uC00HslxzpYJDuyckbEruyxFtCxV5PAYQTzzg49A9BAjKi+0Hg4eeR8OZG4qhIXmvwSs TiRbwK8NhsJFGl482Gv6b2SLNjdo0s17kZL3NGG6lyf0hvpTcqZdjhsvFksWnb+IV751 4VoQ==
X-Gm-Message-State: ALoCoQn2CGY8t7kbOz+a/hrIRUvDtek7O5bmzAm2nToQL+KZczj1douflGYz94VEPemn+hDZa/r6
X-Received: by 10.50.29.114 with SMTP id j18mr4054329igh.24.1384529839543; Fri, 15 Nov 2013 07:37:19 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id j16sm3728343igf.6.2013.11.15.07.37.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 07:37:18 -0800 (PST)
Message-ID: <52863F9D.9090103@bbs.darktech.org>
Date: Fri, 15 Nov 2013 10:37:01 -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: rtcweb@ietf.org
References: <52855B35.3080605@nostrum.com>				<5285CCCE.6040906@ericsson.com>	<528625E0.1030203@bbs.darktech.org> <52862E10.8000506@alvestrand.no>
In-Reply-To: <52862E10.8000506@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 15:39:34 -0000

On 15/11/2013 9:22 AM, Harald Alvestrand wrote:
> On 11/15/2013 02:47 PM, cowwoc wrote:
>> Magnus,
>>
>> Couldn't we alter the option with H.261 to state that we're proposing 
>> an IPR-expired codec *like* H.261? I don't think we need to decide at 
>> this moment which precise codec that would be.
>
> If the proposal isn't for a concrete codec, it's impossible to evaluate.
>
> Please - if you want this option to be on the table, make it a real 
> option, not a "someone else should do the work necessary to figure out 
> if it's a real option".

Agreed. I'll reply to Magnus's thread.

Gili

From cowwoc@bbs.darktech.org  Fri Nov 15 07:44:52 2013
Return-Path: 
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 95F2411E81B3 for ; Fri, 15 Nov 2013 07:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.538
X-Spam-Level: 
X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 7LZfbefBr42z for ; Fri, 15 Nov 2013 07:44:41 -0800 (PST)
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 485CE11E8209 for ; Fri, 15 Nov 2013 07:43:12 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id aq17so5109665iec.9 for ; Fri, 15 Nov 2013 07:43:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=6eh8T7wlmeVcKfClCpvvmThVdHsavOmhiGjZnIFviqM=; b=eCEscZMuWfo39yiBqxe21VKyuGm8FQUmn/oHWIXZTxFEJc4b+froauHoA9KAX3fwnF Yfeb5y5N/AjbFan4hG+OxIP9F3urk26BrVmbX4qlpLdZuWZxrBrJvA0X6K9znjDoie5l XNrSSnY7sHv3LYwwWg8URydTAnQdoYrAWL69t1tYGtOwQAQMkCFYiptunfPqS9uNGEp4 VGtwX4wJ99Mwn8Gxt+MBnRJ6+wTMBs16yIQttEWQRKOlDGrzAYxVUEqHuMpbQjn5beYU wtMeTf1xv8av2wWIaHZhIsZ4F43gkB46D2x2fJcvUKgkU1y9E8eAnjtzQoNkcOsph4x6 kT/w==
X-Gm-Message-State: ALoCoQn7TR5t29bGlwN/7YKy6Bmj1MplU/LFh8b1EK/Lrmb4TFB3hcmNrpyYmGKNsRNMXrs65dXU
X-Received: by 10.50.29.4 with SMTP id f4mr4932655igh.11.1384530191574; Fri, 15 Nov 2013 07:43:11 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id cl4sm3855255igc.1.2013.11.15.07.43.10 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 07:43:10 -0800 (PST)
Message-ID: <528640FC.9010905@bbs.darktech.org>
Date: Fri, 15 Nov 2013 10:42:52 -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: Magnus Westerlund , rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com>	<5e5c891jdb3sam85hb1485ru3r5hj0pclg@hive.bjoern.hoehrmann.de>	 <528626F7.1050101@bbs.darktech.org> <52862E34.50309@ericsson.com>
In-Reply-To: <52862E34.50309@ericsson.com>
Content-Type: multipart/alternative; boundary="------------030902020207040906060100"
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 15:44:53 -0000

This is a multi-part message in MIME format.
--------------030902020207040906060100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Magnus,

In light of Harald and your responses, I'm in favor of two separate 
options for H.261 and Theora respectively. If we find a narrow those 
options down to one within the next two weeks, great, but otherwise I'd 
list them as separate options.

Also, how would the "voting" work exactly? I was imagining the following 
mechanism:

  * Each person is given the 10 or so options we'll end up with in 2 weeks.
  * The person throws out all options they don't consider acceptable
    under any circumstances
  * They sort the remaining options in order of preference
  * We tabulate the results across everyone, assigning a decreasing
    number of points to the options as the priority decreases (meaning,
    1st choice gets the most points, 2nd choice less, and so on)
  * We publish the results, how many "points" each option had and if
    there is a huge margin for the top one, it wins.

Gili

On 15/11/2013 9:22 AM, Magnus Westerlund wrote:
> On 2013-11-15 14:51, cowwoc wrote:
>> +1 with the caveat that I think option 6 should simply state:
>>
>> 6. All entities MUST support a specific IPR-expired codec (to be decided
>> at a later meeting) such as H.261 or Theora.
>>
>> The goal remains the same. I don't think people voting for this option
>> need to know up-front what the specific codec would be so long as we
>> explain that we'll try to pick the best codec possible. Correct me if
>> I'm wrong :)
> I would believe there are a lot of people in the WG that consider the
> IPR risks between Theora and H.261 significantly different. I realize
> that list each alternative code will result in a significantly longer
> list, but at the same time, I don't see how the above MUST statement
> allows the WG to conclude on video codec selection. If we would agree on
> the above, we would spend another year discussing our IPR beliefs around
> various codecs. From that perspective I do think there is better to have
> the individuals in the WG form their own opinions regarding an explicit
> proposal.
>
> At the same time, I would recommend that the people who believe in the
> above option, coming to an agreement now, before the process starts, on
> which codec alternative they want to support. This is after all also a
> question of how to best trade IPR risk vs capability and quality per
> bit. Thus improving that options chance.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>


--------------030902020207040906060100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
    Magnus,
    
      
    
      In light of Harald and your responses, I'm in favor of two
      separate options for H.261 and Theora respectively. If we find a
      narrow those options down to one within the next two weeks, great,
      but otherwise I'd list them as separate options.
    
      
    
      Also, how would the "voting" work exactly? I was imagining the
      following mechanism:
    
      
      
        
    • Each person is given the 10 or so options we'll end up with
          in 2 weeks.
      • 
        
    • The person throws out all options they don't consider
          acceptable under any circumstances
      • 
        
    • They sort the remaining options in order of preference
      • 
        
    • We tabulate the results across everyone, assigning a
          decreasing number of points to the options as the priority
          decreases (meaning, 1st choice gets the most points, 2nd
          choice less, and so on)
      • 
        
    • We publish the results, how many "points" each option had
          and if there is a huge margin for the top one, it wins.
      
        
      • 
      
    
      Gili
    
      
    
      On 15/11/2013 9:22 AM, Magnus Westerlund wrote:
    
    
    
    
    
      
    On 2013-11-15 14:51, cowwoc wrote:

    
      
    
        
    +1 with the caveat that I think option 6 should simply state:

6. All entities MUST support a specific IPR-expired codec (to be decided
at a later meeting) such as H.261 or Theora.

The goal remains the same. I don't think people voting for this option
need to know up-front what the specific codec would be so long as we
explain that we'll try to pick the best codec possible. Correct me if
I'm wrong :)

    
      
    
      
    I would believe there are a lot of people in the WG that consider the
IPR risks between Theora and H.261 significantly different. I realize
that list each alternative code will result in a significantly longer
list, but at the same time, I don't see how the above MUST statement
allows the WG to conclude on video codec selection. If we would agree on
the above, we would spend another year discussing our IPR beliefs around
various codecs. From that perspective I do think there is better to have
the individuals in the WG form their own opinions regarding an explicit
proposal.

At the same time, I would recommend that the people who believe in the
above option, coming to an agreement now, before the process starts, on
which codec alternative they want to support. This is after all also a
question of how to best trade IPR risk vs capability and quality per
bit. Thus improving that options chance.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


    
    
    
    
    
  


--------------030902020207040906060100--

From ekr@rtfm.com  Fri Nov 15 08:24:19 2013
Return-Path: 
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 5A1FC21F9CC5 for ; Fri, 15 Nov 2013 08:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 1pBgPYqqX8Vt for ; Fri, 15 Nov 2013 08:24:14 -0800 (PST)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id A223421F9FAE for ; Fri, 15 Nov 2013 08:23:51 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id n12so3736251wgh.15 for ; Fri, 15 Nov 2013 08:23:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xjEMFEnZxKEK/z7KUqHmwhFHWQvjs9GiGsTqXtqKrYI=; b=PU2lczH/Y6XLfzSutaqMjb2lP8MBZv+1fsQ0F/+zmKkSnZmBu40tuyb8mKSnOmIzWq xWvHECY/RjcfeRUECT3U4V6XHpWZ5eSVu3R62KOi6MMIoV2A7TNGVXWUqS5H4ED7V1Oc tpj/ympuR0L2YRyXr4Lmf8Er6Ye2kXbC3vtQOlIyjY4dyqTa/F3leazY63HcDBgwtCtv r6Siu415qItpdQOo82No3obuK85B6sUlUTq84yNj87gC5SK+vt55yQN56tF4t+X4sYGj npA6Ompzt7YUtyVtsm4SYm8bDO3M3B22InDl+MyOS4ckJyZxipr3lqmlsAfWZSUlYov4 AYkQ==
X-Gm-Message-State: ALoCoQmCVf7otc+RFF78Ox5M38vPQ7W1ThjS7Lm36mXTk07ddN78Z7k4It7pa0c0gBv3ABRq5Asw
X-Received: by 10.194.237.99 with SMTP id vb3mr7541326wjc.28.1384532630601; Fri, 15 Nov 2013 08:23:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Fri, 15 Nov 2013 08:23:10 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <528640FC.9010905@bbs.darktech.org>
References: <5283DFDC.4010906@ericsson.com> <5e5c891jdb3sam85hb1485ru3r5hj0pclg@hive.bjoern.hoehrmann.de>  <528626F7.1050101@bbs.darktech.org> <52862E34.50309@ericsson.com> <528640FC.9010905@bbs.darktech.org>
From: Eric Rescorla 
Date: Fri, 15 Nov 2013 08:23:10 -0800
Message-ID: 
To: cowwoc 
Content-Type: multipart/alternative; boundary=089e01494224a0a1bc04eb399f29
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 16:24:19 -0000

--089e01494224a0a1bc04eb399f29
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 15, 2013 at 7:42 AM, cowwoc  wrote:

>  Magnus,
>
> In light of Harald and your responses, I'm in favor of two separate
> options for H.261 and Theora respectively. If we find a narrow those
> options down to one within the next two weeks, great, but otherwise I'd
> list them as separate options.
>
> Also, how would the "voting" work exactly? I was imagining the following
> mechanism:
>
>    - Each person is given the 10 or so options we'll end up with in 2
>    weeks.
>    - The person throws out all options they don't consider acceptable
>    under any circumstances
>    - They sort the remaining options in order of preference
>    - We tabulate the results across everyone, assigning a decreasing
>    number of points to the options as the priority decreases (meaning, 1s=
t
>    choice gets the most points, 2nd choice less, and so on)
>    - We publish the results, how many "points" each option had and if
>    there is a huge margin for the top one, it wins.
>
>
Please please please let's not try to invent new voting systems on this
mailing list. This is an incredibly technical area
(see http://en.wikipedia.org/wiki/Arrow's_impossibility_theorem if you're
not convinced).

-Ekr


>    - Gili
>
>
>
> On 15/11/2013 9:22 AM, Magnus Westerlund wrote:
>
> On 2013-11-15 14:51, cowwoc wrote:
>
>  +1 with the caveat that I think option 6 should simply state:
>
> 6. All entities MUST support a specific IPR-expired codec (to be decided
> at a later meeting) such as H.261 or Theora.
>
> The goal remains the same. I don't think people voting for this option
> need to know up-front what the specific codec would be so long as we
> explain that we'll try to pick the best codec possible. Correct me if
> I'm wrong :)
>
>  I would believe there are a lot of people in the WG that consider the
> IPR risks between Theora and H.261 significantly different. I realize
> that list each alternative code will result in a significantly longer
> list, but at the same time, I don't see how the above MUST statement
> allows the WG to conclude on video codec selection. If we would agree on
> the above, we would spend another year discussing our IPR beliefs around
> various codecs. From that perspective I do think there is better to have
> the individuals in the WG form their own opinions regarding an explicit
> proposal.
>
> At the same time, I would recommend that the people who believe in the
> above option, coming to an agreement now, before the process starts, on
> which codec alternative they want to support. This is after all also a
> question of how to best trade IPR risk vs capability and quality per
> bit. Thus improving that options chance.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> F=E4r=F6gatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--089e01494224a0a1bc04eb399f29
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





    On Fri, Nov 15, 2013 at 7:42 AM, cowwoc <cowwoc@bbs.darktech=
.org> wrote:
    


    
 =20
   =20
 =20
  
    
    
    Magnus,
    
      
    
      In light of Harald and your responses, I'm in favor of two
      separate options for H.261 and Theora respectively. If we find a
      narrow those options down to one within the next two weeks, great,
      but otherwise I'd list them as separate options.
    
      
    
      Also, how would the "voting" work exactly? I was imagining =
the
      following mechanism:
    
      
      
        
    • Each person is given the 10 or so options we'll end up with
          in 2 weeks.
      • 
        
    • The person throws out all options they don't consider
          acceptable under any circumstances
      • 
        
    • They sort the remaining options in order of preference
      • 
        
    • We tabulate the results across everyone, assigning a
          decreasing number of points to the options as the priority
          decreases (meaning, 1st choice gets the most points, 2nd
          choice less, and so on)
      • 
        
    • We publish the results, how many "points" each option=
 had
          and if there is a huge margin for the top one, it wins.
    =


    Please please please let's=
 not try to invent new voting systems on this
    mailing list. This =
is an incredibly technical area=A0
    




    


    • Gili

    
      
    
      On 15/11/2013 9:22 AM, Magnus Westerlund wrote:
    
    
    
    
    
      
    On 2013-11-15 14:51, cowwoc wrote:

    
      
    
        
    +1 with the caveat that I think option 6 should simply state:

6. All entities MUST support a specific IPR-expired codec (to be decided
at a later meeting) such as H.261 or Theora.

The goal remains the same. I don't think people voting for this option
need to know up-front what the specific codec would be so long as we
explain that we'll try to pick the best codec possible. Correct me if
I'm wrong :)

    
      
    
      
    I would believe there are a lot of people in the WG that conside=
r the
IPR risks between Theora and H.261 significantly different. I realize
that list each alternative code will result in a significantly longer
list, but at the same time, I don't see how the above MUST statement
allows the WG to conclude on video codec selection. If we would agree on
the above, we would spend another year discussing our IPR beliefs around
various codecs. From that perspective I do think there is better to have
the individuals in the WG form their own opinions regarding an explicit
proposal.

At the same time, I would recommend that the people who believe in the
above option, coming to an agreement now, before the process starts, on
which codec alternative they want to support. This is after all also a
question of how to best trade IPR risk vs capability and quality per
bit. Thus improving that options chance.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
F=E4r=F6gatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


    
    
    
    
    
  
    


    _______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--089e01494224a0a1bc04eb399f29--

From magnus.westerlund@ericsson.com  Fri Nov 15 08:38:33 2013
Return-Path: 
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 92EF911E81A5 for ; Fri, 15 Nov 2013 08:38:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.262
X-Spam-Level: 
X-Spam-Status: No, score=-105.262 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 eIb1cKDE7OMM for ; Fri, 15 Nov 2013 08:38:25 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 836DA11E81B3 for ; Fri, 15 Nov 2013 08:38:10 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-81-52864df0ba08
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 92.3E.23787.0FD46825; Fri, 15 Nov 2013 17:38:08 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.2.328.9; Fri, 15 Nov 2013 17:38:08 +0100
Message-ID: <52864DEE.9000506@ericsson.com>
Date: Fri, 15 Nov 2013 17:38:06 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: cowwoc , 
References: <5283DFDC.4010906@ericsson.com>	<5e5c891jdb3sam85hb1485ru3r5hj0pclg@hive.bjoern.hoehrmann.de>	 <528626F7.1050101@bbs.darktech.org> <52862E34.50309@ericsson.com> <528640FC.9010905@bbs.darktech.org>
In-Reply-To: <528640FC.9010905@bbs.darktech.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3VveDb1uQweOTphZnbv5nt1j7r53d gcnjyYTp7B5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4+PcVe8FDnor2SQuYGhhbuboYOTgkBEwk 5j6v62LkBDLFJC7cW8/WxcjFISRwiFHi1f6HUM5yRoljMxczgVTxCmhL/Pl2mhnEZhFQlfg3 /zAriM0mYCFx80cjG4gtKhAscf7VYnaIekGJkzOfsIAsExEwl3h0txLEFBawlLhw3ARi/BQm ic37N4G1cgoYSCy7v5AZ4jZxiZ7GIJAws4CexJSrLYwQtrxE89bZYBcIAV3T0NTBOoFRcBaS ZbOQtMxC0rKAkXkVI3tuYmZOernhJkZgOB7c8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwMhg2Jw8n6/vOue640dMOsJ2fRXTNu9S+eCzZZeKcm6YZ3hE nzb3yme8N4vV1QS2RnF+sOvS9+Vq5nKq2m+gZaidK8alOrUq+9uaNTUdW9b/7J558+myLcJH t57QqbgQzZ5ZY6lmVHBhYZiFyf6JkeJtYXunBC8R3vf4QfOes0FHlqyqT1meq8RSnJFoqMVc VJwIAKIg7yQVAgAA
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 16:38:33 -0000

On 2013-11-15 16:42, cowwoc wrote:
> Magnus,
> 
> In light of Harald and your responses, I'm in favor of two separate
> options for H.261 and Theora respectively. If we find a narrow those
> options down to one within the next two weeks, great, but otherwise I'd
> list them as separate options.
> 
> Also, how would the "voting" work exactly? I was imagining the following
> mechanism:
> 
>   * Each person is given the 10 or so options we'll end up with in 2 weeks.
>   * The person throws out all options they don't consider acceptable
>     under any circumstances
>   * They sort the remaining options in order of preference
>   * We tabulate the results across everyone, assigning a decreasing
>     number of points to the options as the priority decreases (meaning,
>     1st choice gets the most points, 2nd choice less, and so on)
>   * We publish the results, how many "points" each option had and if
>     there is a huge margin for the top one, it wins.
> 

We chairs are working on a proposal for a process for the selection for
the WG to review and do a consensus call on to use. We hope to have
something next week.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From cowwoc@bbs.darktech.org  Fri Nov 15 09:20:36 2013
Return-Path: 
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 B9A1B11E81B6 for ; Fri, 15 Nov 2013 09:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.548
X-Spam-Level: 
X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 ZApLmKDFFuIn for ; Fri, 15 Nov 2013 09:20:31 -0800 (PST)
Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id A382311E81AF for ; Fri, 15 Nov 2013 09:20:31 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id e14so5315090iej.13 for ; Fri, 15 Nov 2013 09:20:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=iYqbKHUmfsmLCfRgU98lW6ThWELiaS07dRf9Y6JszJc=; b=hV2E8U3+6dS6SQaQ6RIP6jFXSgRlmj9zsNDpjUorZeUl1jrXAiXfiTWGUayUT8gbAj vg4JlG9y28P28HrnM45USvQWEUelzupdRjYWk7HD5W72DWhnlNYO23bfEjQclyHOzeBs Mha86FELsr/GsFB5KdXOZs7MRhr2ML/MvWbaBRrG4axW3i1JkFIhYWbFN3/BaIFTiODt 9swxC8PJXKjDsV4+XgKyFCzLhOt4MJ62MeLPADxkKH5UiOVn/9Q9r2STTKUd0S2ctehF BYeixA20n6QccV0TOK6/akwdrFH168+ju6CFe5JWBaJ8jX8z7SGnJ2+1ejYCwb686D5v +rUg==
X-Gm-Message-State: ALoCoQkovTklXYd6h+i0gC2nTZv+7OqMynITlQQp4TZTz0emCvYiye1m9f24UkCQQdlHbWl8xQUz
X-Received: by 10.50.176.137 with SMTP id ci9mr5180320igc.31.1384536021506; Fri, 15 Nov 2013 09:20:21 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id x5sm4144988iga.6.2013.11.15.09.20.20 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 09:20:20 -0800 (PST)
Message-ID: <528657C2.9040600@bbs.darktech.org>
Date: Fri, 15 Nov 2013 12:20:02 -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: Eric Rescorla 
References: <5283DFDC.4010906@ericsson.com> <5e5c891jdb3sam85hb1485ru3r5hj0pclg@hive.bjoern.hoehrmann.de>  <528626F7.1050101@bbs.darktech.org> <52862E34.50309@ericsson.com> <528640FC.9010905@bbs.darktech.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040407000600090808000700"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 17:20:36 -0000

This is a multi-part message in MIME format.
--------------040407000600090808000700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 15/11/2013 11:23 AM, Eric Rescorla wrote:
> On Fri, Nov 15, 2013 at 7:42 AM, cowwoc  > wrote:
>
>     Magnus,
>
>     In light of Harald and your responses, I'm in favor of two
>     separate options for H.261 and Theora respectively. If we find a
>     narrow those options down to one within the next two weeks, great,
>     but otherwise I'd list them as separate options.
>
>     Also, how would the "voting" work exactly? I was imagining the
>     following mechanism:
>
>       * Each person is given the 10 or so options we'll end up with in
>         2 weeks.
>       * The person throws out all options they don't consider
>         acceptable under any circumstances
>       * They sort the remaining options in order of preference
>       * We tabulate the results across everyone, assigning a
>         decreasing number of points to the options as the priority
>         decreases (meaning, 1st choice gets the most points, 2nd
>         choice less, and so on)
>       * We publish the results, how many "points" each option had and
>         if there is a huge margin for the top one, it wins.
>
>
> Please please please let's not try to invent new voting systems on this
> mailing list. This is an incredibly technical area
> (see http://en.wikipedia.org/wiki/Arrow's_impossibility_theorem 
>  if you're
> not convinced).
Eric,

I'm not trying to achieve what is mentioned in that Wikipedia post. 
Meaning, I believe it is acceptable for the resulting tally to violate 
the wishes of individual priorities.

But anyway, let's say you still object, what is your counter-proposal? 
What were we planning to do?

Gili

--------------040407000600090808000700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
    On 15/11/2013 11:23 AM, Eric Rescorla
      wrote:
    
    
    
    
    
      
    On Fri, Nov 15, 2013 at 7:42 AM, cowwoc <cowwoc@bbs.darktech.org>
        wrote:
    
        
    
          
    
            
    
              
    
                
    Magnus,
    
                  
    
                  In light of Harald and your responses, I'm in favor of
                  two separate options for H.261 and Theora
                  respectively. If we find a narrow those options down
                  to one within the next two weeks, great, but otherwise
                  I'd list them as separate options.
    
                  
    
                  Also, how would the "voting" work exactly? I was
                  imagining the following mechanism:
    
                  
      
                    
    • Each person is given the 10 or so options we'll
                      end up with in 2 weeks.
      • 
                    
    • The person throws out all options they don't
                      consider acceptable under any circumstances
      • 
                    
    • They sort the remaining options in order of
                      preference
      • 
                    
    • We tabulate the results across everyone,
                      assigning a decreasing number of points to the
                      options as the priority decreases (meaning, 1st
                      choice gets the most points, 2nd choice less, and
                      so on)
      • 
                    
    • We publish the results, how many "points" each
                      option had and if there is a huge margin for the
                      top one, it wins.
      • 
                  
    
                
    
              
    
            
    
            

    
            
    
            
    Please please please let's not try to invent new voting
              systems on this
    
            
    mailing list. This is an incredibly technical area 
    
            
            
    not convinced).
    
          
    
        
    
      
    
    
    
    Eric,
    
    
    
    I'm not trying to achieve what is mentioned in that Wikipedia post.
    Meaning, I believe it is acceptable for the resulting tally to
    violate the wishes of individual priorities.
    
    
    
    But anyway, let's say you still object, what is your
    counter-proposal? What were we planning to do?
    
    
    
    Gili
    
  


--------------040407000600090808000700--

From cowwoc@bbs.darktech.org  Fri Nov 15 09:23:14 2013
Return-Path: 
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 13D2011E8123 for ; Fri, 15 Nov 2013 09:23:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.556
X-Spam-Level: 
X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 mL+K8E6fZ66X for ; Fri, 15 Nov 2013 09:23:08 -0800 (PST)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id EA6BC11E81A9 for ; Fri, 15 Nov 2013 09:23:03 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id ar20so5124582iec.5 for ; Fri, 15 Nov 2013 09:23:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jE9NMguNHJRd8ed64OPV38WNh8m/zQdWX49abZgE70M=; b=fGdoB1FJP+Oz5AxroxL2UrfwO+xeyBFSxLBaSnYaGr4HQI9xMq0UzKR6ODFQ9ZPAgV YndZ4s3Y+BukyI66ta17y07W8DpHrm3kzaVLxoHGUIzHjncbIo0F+VhwFMh+imTtgvup DuctJfMsPi7zsgyKvd91CHYIpRnjxdAAJcWk+FIONjALzWK4/WxaFrSNE7dZ8y5ofBQ6 TJhuDVfUWAba7WEpfLWcPnIjgwspceU0NLJp7tTYLQXOgAZ6HeVHoMbFb96iQVTSUGCO /1WHWe94uCf/VoyLLbAqb6GB/Jk/Uh1/6Bq5LxbqdspVfs2qRuFLISe/0WPFgSX40H9Q 64lw==
X-Gm-Message-State: ALoCoQmxIzfTUTfjeb5VZ+AcRqLWfZtkbpB12oav96/QISc6LWJ6Q9vkBTEexgvUy5UcmDbkxBaq
X-Received: by 10.50.39.45 with SMTP id m13mr5315121igk.14.1384536183220; Fri, 15 Nov 2013 09:23:03 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f5sm4166822igc.4.2013.11.15.09.23.01 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 09:23:02 -0800 (PST)
Message-ID: <52865864.40207@bbs.darktech.org>
Date: Fri, 15 Nov 2013 12:22:44 -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: Magnus Westerlund , rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com>	<5e5c891jdb3sam85hb1485ru3r5hj0pclg@hive.bjoern.hoehrmann.de>	 <528626F7.1050101@bbs.darktech.org> <52862E34.50309@ericsson.com> <528640FC.9010905@bbs.darktech.org> <52864DEE.9000506@ericsson.com>
In-Reply-To: <52864DEE.9000506@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 17:23:14 -0000

On 15/11/2013 11:38 AM, Magnus Westerlund wrote:
> We chairs are working on a proposal for a process for the selection for
> the WG to review and do a consensus call on to use. We hope to have
> something next week.

Okay, got it. Eric, please disregard my last post.

Thanks,
Gili

From ekr@rtfm.com  Fri Nov 15 09:28:32 2013
Return-Path: 
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 DDF9711E820D for ; Fri, 15 Nov 2013 09:28:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Rpt4BXCSprUH for ; Fri, 15 Nov 2013 09:28:27 -0800 (PST)
Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7C43D11E81BC for ; Fri, 15 Nov 2013 09:28:27 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id x55so172100wes.26 for ; Fri, 15 Nov 2013 09:28:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yek4WK90++5sCQSRKhuV1QpiYZ5wLVepCluZy3reCts=; b=DNFIe+QXuRQiC0bw20jIKLhLKVBQwD5nBvWobd+pZoKTiYimIpC9m0KlUVbx22dYRq iHq1g6Vl62zrFT1/fX9YvQfphKG6kXyeXvSOVO6MTv3NLGy7K3axI/7E9HU/JHOBVUvn XzdF4JoIBp4/z5b5IU8vxjI6rKvAOriykIdhpHoTCcW4W/VzGMQ5B75TcI9otUMiaVb4 d8U5zRzurwTjCCKgygfDG6CaIQiU5njd8vQl8Q1oWSXXXm1yHUO6TZ96HfvvAJWoQDNL /yKXko/kdF4qTB20cfED12HdvLjrugymbkQcA1eofoIABPcSVZZC9UR6BCJVIhAEY5x8 1FDQ==
X-Gm-Message-State: ALoCoQlQjWOh2MvjkBsV4Kqxbl2IhKZ8NeiJsJVmtyd96aHIXyvLS+XSbH8WiAoZS5YArUvqgyem
X-Received: by 10.180.221.38 with SMTP id qb6mr8055662wic.8.1384536506636; Fri, 15 Nov 2013 09:28:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Fri, 15 Nov 2013 09:27:46 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <528657C2.9040600@bbs.darktech.org>
References: <5283DFDC.4010906@ericsson.com> <5e5c891jdb3sam85hb1485ru3r5hj0pclg@hive.bjoern.hoehrmann.de>  <528626F7.1050101@bbs.darktech.org> <52862E34.50309@ericsson.com> <528640FC.9010905@bbs.darktech.org>  <528657C2.9040600@bbs.darktech.org>
From: Eric Rescorla 
Date: Fri, 15 Nov 2013 09:27:46 -0800
Message-ID: 
To: cowwoc 
Content-Type: multipart/alternative; boundary=001a1134d2daa8351904eb3a8625
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 17:28:33 -0000

--001a1134d2daa8351904eb3a8625
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 15, 2013 at 9:20 AM, cowwoc  wrote:

>  On 15/11/2013 11:23 AM, Eric Rescorla wrote:
>
> On Fri, Nov 15, 2013 at 7:42 AM, cowwoc  wrote:
>
>>  Magnus,
>>
>> In light of Harald and your responses, I'm in favor of two separate
>> options for H.261 and Theora respectively. If we find a narrow those
>> options down to one within the next two weeks, great, but otherwise I'd
>> list them as separate options.
>>
>> Also, how would the "voting" work exactly? I was imagining the following
>> mechanism:
>>
>>    - Each person is given the 10 or so options we'll end up with in 2
>>    weeks.
>>    - The person throws out all options they don't consider acceptable
>>    under any circumstances
>>    - They sort the remaining options in order of preference
>>    - We tabulate the results across everyone, assigning a decreasing
>>    number of points to the options as the priority decreases (meaning, 1st
>>    choice gets the most points, 2nd choice less, and so on)
>>    - We publish the results, how many "points" each option had and if
>>    there is a huge margin for the top one, it wins.
>>
>>
>  Please please please let's not try to invent new voting systems on this
> mailing list. This is an incredibly technical area
> (see http://en.wikipedia.org/wiki/Arrow's_impossibility_theorem if you're
> not convinced).
>
> Eric,
>
> I'm not trying to achieve what is mentioned in that Wikipedia post.
>

I have no idea what you think you are trying to do, then. What you
described is
precisely a voting system (though not a good one) and so we have all the
usual
problems.



> Meaning, I believe it is acceptable for the resulting tally to violate the
> wishes of individual priorities.
>

I don't know what you mean by "violate the wishes of individual priorities".
The task here is to try to come to an overall decision that aggregates
people's individual preferences. That's hard for the reasons I indicated.



>  But anyway, let's say you still object, what is your counter-proposal?
> What were we planning to do?
>

I was planning to let the chairs propose something.

With that said, there's a huge literature on voting systems so no doubt one
of the many
well-known systems (Approval, IRV, ...) can be used without the need for us
to invent
something new.

-Ekr

--001a1134d2daa8351904eb3a8625
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





    On Fri, Nov 15, 2013 at 9:20 AM, cowwoc <cowwoc@bbs.darktech=
.org> wrote:
    


    
 =20
   =20
 =20
  
    
    
    On 15/11/2013 11:23 AM, Eric Rescorla
      wrote:
    
    
    
    
    
      
    On Fri, Nov 15, 2013 at 7:42 AM, cowwoc <coww=
oc@bbs.darktech.org>
        wrote:
    
        
    
          
    
            
    
              
    
                
    Magnus,
    
                  
    
                  In light of Harald and your responses, I'm in favor o=
f
                  two separate options for H.261 and Theora
                  respectively. If we find a narrow those options down
                  to one within the next two weeks, great, but otherwise
                  I'd list them as separate options.
    
                  
    
                  Also, how would the "voting" work exactly? I wa=
s
                  imagining the following mechanism:
    
                  
      
                    
    • Each person is given the 10 or so options we'll
                      end up with in 2 weeks.
      • 
                    
    • The person throws out all options they don't
                      consider acceptable under any circumstances
      • 
                    
    • They sort the remaining options in order of
                      preference
      • 
                    
    • We tabulate the results across everyone,
                      assigning a decreasing number of points to the
                      options as the priority decreases (meaning, 1st
                      choice gets the most points, 2nd choice less, and
                      so on)
      • 
                    
    • We publish the results, how many "points"=
 each
                      option had and if there is a huge margin for the
                      top one, it wins.
      • 
                  
    
                
    
              
    
            
    
            

    
            
    
            
    Please please please let's not try to invent new votin=
g
              systems on this
    
            
    mailing list. This is an incredibly technical area=A0
            
            
    not convinced).
    
          
    
        
    
      
    
    
    
    Eric,
    
    
    
    I'm not trying to achieve what is mentioned in that Wikipedia post.


    I have no idea what you think you ar=
e trying to do, then. What you described is=A0
    precisely a voting=
 system (though not a good one) and so we have all the usual
    prob=
lems.
    



    =A0
        Meaning, I believe it is acceptable for the =
resulting tally to
    violate the wishes of individual priorities.

    I don't know what you mean by "violate the wishes =
of individual priorities".
    The task here is to try to come t=
o an overall decision that aggregates
    


    people's individual preferences. That's hard for the reasons I=
 indicated.

    =A0
    


    
    But anyway, let's say you still object, what is your
    counter-proposal? What were we planning to do?

    I was planning to let the chairs propose something.
    =


    With that said, there's a huge literature on voting=
 systems so no doubt one of the many
    


    well-known systems (Approval, IRV, ...) can be used without the need f=
or us to invent
    something new.

    -Ekr


    

--001a1134d2daa8351904eb3a8625--

From simon.perreault@viagenie.ca  Fri Nov 15 12:27:12 2013
Return-Path: 
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 50C6711E8128; Fri, 15 Nov 2013 12:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599]
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 vkVm7tx7-ICS; Fri, 15 Nov 2013 12:27:11 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 50DDE11E80E0; Fri, 15 Nov 2013 12:27:08 -0800 (PST)
Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8A20B403CB; Fri, 15 Nov 2013 15:27:07 -0500 (EST)
Message-ID: <5286839B.8050305@viagenie.ca>
Date: Fri, 15 Nov 2013 15:27:07 -0500
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" , pntaw@ietf.org,  "behave@ietf.org" , mmusic@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tram@ietf.org
Subject: [rtcweb] Turn Revised And Modernized (tram)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: tram@ietf.org
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, 15 Nov 2013 20:27:12 -0000

All,

A few of us have been working on a proposal for a new working group that 
would focus on enhancements to STUN and TURN. The proposed name is TRAM 
(Turn Revised And Modernized) and discussion is happening in 
.
Subscribe link: 

Here is the charter we have been working on. If you would like to 
comment and/or get involved, please do so on the TRAM mailing list.

Simon (and many others!)

> Turn Revised And Modernized (tram)
> ----------------------------------
>
> Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April
> 2010.  Until recently the protocol had only a rather limited deployment.  This
> is primarily because its primary use case is as one of the NAT traversal
> methods of the Interactive Connectivity Establishment (ICE) framework (RFC
> 5245).  This inherent dependency on ICE combined with the fact that ICE itself
> was slow to achieve widespread adoption because other alternative mechanisms
> were historically used by the VoIP industry were the causes of the initial
> lack of interest.  This situation has changed drastically as ICE, and
> consequently TURN, are mandatory to implement in WebRTC, which is a set of
> technologies developed at the IETF and W3C aiming to enable Real Time
> Communication on the Web.
>
> Because of the ubiquity of the Web and of the new opportunities created by the
> arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidenced by
> the recent work updating the ICE framework, as well as standardizing the URIs
> used to access a STUN [RFC7064] or TURN [RFC7065] server.
>
> The goal of the TRAM Working Group is to consolidate the various initiatives
> to update TURN and STUN, including the definition of new transport and
> authentication mechanisms that make STUN and TURN more suitable for the WebRTC
> environment.  The Working Group will closely coordinate with the appropriate
> Working Groups, including RTCWEB, MMUSIC, and HTTPBIS.
>
> The current list of deliverable is:
>
> - DTLS transport for TURN
>
>   Candidate draft: draft-petithuguenin-tram-turn-dtls
>
>   TURN defines three transports: UDP, TCP, and TLS. A straightforward extension
>   of this set is DTLS, enabling secure datagram-oriented transport.
>
> - New authentication mechanism for TURN
>
>   Problem analysis: draft-reddy-behave-turn-auth
>   Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been suggested
>
>   The current authentication mechanism for TURN, which is reused from STUN, has
>   been designed with a SIP account database in mind. The new RTCWEB usages,
>   which are mostly based on web applications, do not fit that model. A new
>   authentication mechanism optimized for such web applications will be created.
>
> - TURN server auto-discovery mechanism for enterprise and ISPs
>
>   Candidate draft: TBD
>
>   Current TURN server discovery is based on the presence of SRV and/or NAPTR DNS
>   records. These records are usually under the administrative control of the
>   application or service provider, not the enterprise or the ISP on whose
>   network the client is situated. Enterprises or ISPs wishing to provide their
>   own TURN server, in an attempt to reduce so-called "triangle routing", need a
>   new auto-discovery mechanism.
>
> - STUN-bis
>
>   Candidate draft: TBD
>
>   A new revision of RFC 5389 will contain:
>
>   - Various bug fixes
>   - STUN hash algorithm agility (currently only SHA-1 is allowed)
>
> - TURN-bis
>
>   Candidate draft: TBD
>
>   A new revision of RFC 5766 will contain:
>
>   - Various bug fixes
>   - Support for multi-tenant servers
>     (Servers always send the same REALM attribute. No realm negotiation phase
>      currently exists.)
>
> Goals and Milestones:
>
> [TBD]

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From basilgohar@librevideo.org  Fri Nov 15 13:56:47 2013
Return-Path: 
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 BE2BE21F9D8E for ; Fri, 15 Nov 2013 13:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.682
X-Spam-Level: 
X-Spam-Status: No, score=0.682 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_MONEYTERMS=0.681]
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 ps3Qr6Lt+9qN for ; Fri, 15 Nov 2013 13:56:42 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id D401121F9DC7 for ; Fri, 15 Nov 2013 13:56:37 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id B3B1F65A7DC for ; Fri, 15 Nov 2013 16:56:36 -0500 (EST)
Message-ID: <52869891.7010100@librevideo.org>
Date: Fri, 15 Nov 2013 16:56:33 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com> <528492E8.8020202@ericsson.com>
In-Reply-To: <528492E8.8020202@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 21:56:47 -0000

I am forwarding the following on behalf of Hervé.  You can consider this
also a +1 from me for the proposal, for what it's worth:

> Proposal for MTI video codec: All entities MUST support Theora.
> 
> Theora was derived from VP3 (a codec from 2000).
> Theora bitstream format freeze in June 2004.
> 
> Theora documentation (including link to spec pdf) : http://theora.org/doc/
> 
> If you want to try out the codec, rather than write your own from scratch, please consider using the reference implementation's latest sources (rather than version 1.1) : http://git.xiph.org/?p=mirrors/theora.git
> 
> There have been several commercial products that apparently weren't sued into bankruptcy: http://wiki.xiph.org/Games_that_use_Theora
> 
> No license fees are owed to Xiph for implementation.
> 
> See also:
> http://wiki.xiph.org/TheoraSoftwarePlayers
> http://wiki.xiph.org/Theora_Hardware
> http://wiki.xiph.org/TheoraSoftwareEncoders
> http://wiki.xiph.org/TheoraDecoders
> http://wiki.xiph.org/TheoraEncoders
> 
> 
> - Hervé

-- 
Libre Video
http://librevideo.org

From juberti@google.com  Fri Nov 15 14:01:13 2013
Return-Path: 
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 A5B0D11E81BD for ; Fri, 15 Nov 2013 14:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.844
X-Spam-Level: 
X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=0.533,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=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 G22rgDR+htyk for ; Fri, 15 Nov 2013 14:01:12 -0800 (PST)
Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6F08411E8164 for ; Fri, 15 Nov 2013 14:01:11 -0800 (PST)
Received: by mail-vb0-f46.google.com with SMTP id i3so1191531vbh.5 for ; Fri, 15 Nov 2013 14:01:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BVVuRmLBivkNGm8z9OEP3DDve147cfd+weyE5bF9GZA=; b=U4plrW5wGFdUV3LPAsgWtOjGEm1TmkSgzIF0cbvZn83ShuzN6E44EawmxU3w/lMdax 57gN6ABs4uVznUGNEiTtXQ1pAKsYaiID4GVcfjQByV5ODiHRO1fkeY0w8LB7du3DQqO9 nGAvUA0o+1bIkP0jWiBS3nf/V3HwFI+bCxFv4C1NvBU2cX/Rm2M7GMpJAJu7zlXYLZnr 0sS7F8rkrwO6/GDzgwB8epGAb1NkKsih6oh8wZVrdslpW/QGEUNkFIrZc0dWAadCyvhf PEBurbEY8NYX0UTWLOfUztNF3x5g8RNu1OhD73CvxIk4XUgRpDyFoHjYYS/koN1RYJQh +R1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BVVuRmLBivkNGm8z9OEP3DDve147cfd+weyE5bF9GZA=; b=d/prmYF9FO71RemcYExAghQrTY9SJLIq6daoIu/VLdCM6yYzf00f/+tFNxQH63siH5 hCn1ebKhOwVmFscqKPYjUjmXjhLuEljnvUioesuzfqk15P4fZEUqInRJeeeN8yPGUtxz fOiIUoRM44oD8qvdAiYZpF7DOeXab+Jns6zSgKUOT5USDJ1iRlyS9xdfuiotc/T0b9PC FAjipozaxznzK9AGADSXLecvTQRyi03O3a7QpGOwnq54zQmLWagn57YZlFeKdbWcbSUr u7tBnO44VqgZs9Mx3Va8As+Ik0aVdEplSYpJmdlz3U9HnL3g0/olP0XG9XJcstRKaX2p dkhA==
X-Gm-Message-State: ALoCoQkMsuJc4P40w274J+eyQ+7Vq0ZfATo47DeNStLucS+ssSTF2MnKq/z3ZE80qII9kf6TTpl2xM5zOskbR76Ifa7UbEd41+aXK9zNlioYdhxAilG2WJTbQ24nh4WiRuMGPPfQS2DRijF64XkhIitJf3e3MOnCrmCAJ1rbDhFMgMh7TkjsI6mOsnIxkU0FgWJMFxIbw77Z
X-Received: by 10.52.74.74 with SMTP id r10mr165319vdv.78.1384552870582; Fri, 15 Nov 2013 14:01:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 15 Nov 2013 14:00:50 -0800 (PST)
In-Reply-To: <5286272B.5000005@bbs.darktech.org>
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>   <528559E4.3020903@nostrum.com> <5286272B.5000005@bbs.darktech.org>
From: Justin Uberti 
Date: Fri, 15 Nov 2013 14:00:50 -0800
Message-ID: 
To: cowwoc 
Content-Type: multipart/alternative; boundary=20cf307cff2006381b04eb3e5692
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 22:01:13 -0000

--20cf307cff2006381b04eb3e5692
Content-Type: text/plain; charset=UTF-8

>From what I understand, the clip from this thread was encoded using MPEG-1,
not H.261. Aside from http://www-mobile.ecs.soton.ac.uk/peter/h261/, I
don't think we have seen any samples of actual H.261 output that give a
good indication of its suitability.


On Fri, Nov 15, 2013 at 5:52 AM, cowwoc  wrote:

>
> Excellent work Adam. I can't speak for others, but at 254 kbps (corrected
> figure from your follow-up post) H.261 is definitely "good enough" and
> better than an audio-only connection.
>
> Gili
>
>
> On 14/11/2013 6:16 PM, Adam Roach wrote:
>
> I sent a reply to this earlier, but just now realized that it went only to
> Justin, not to the list.
>
>
>  On 11/14/13 13:59, Justin Uberti wrote:
>
> Thanks, this is interesting. Is the ffmpeg 261 encoder limited to
> CIF/QCIF, or can you specify arbitrary sizes?
>
>
> It looks like the ffmpeg mpeg-1 coder works for arbitrary sizes. I'm not
> sure what the difference between mpeg-1 and H.261 are, though, so we could
> be talking apples and oranges (or at least apples and pears) here. I'll
> note that mpeg-1 came out in 1991, which is a good 22 years in the past.
> I'm not drawing IPR conclusions for you, but invite you to ponder the
> implications yourself.
>
> Following Maik's lead with the mpeg-1 js decoder, I put this together:
>
> https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>
> ...with this commandline:
>
>   ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp rd -subcmp rd
> -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k maven.mpg
>
> I don't really understand most of those options (I just cribbed them from
> Maik's example) or whether any of them would introduce more latency than is
> reasonable for a real-time conversation, but I will observe:
>
>    1. The encoder claims that it was performing on the order of 90 - 100
>    fps on my (admittedly modern) system;
>     2. The resolution is 640x360 (somewhat larger than DCIF);
>    3. The video is not, to my eye, unusable (draw your own conclusions,
>    as it's clearly not as nice as modern codecs);
>     4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding
>    works out to 508 kbits/second total.
>
>
>  Source video here, and NASA is acknowledged as the source of the material
> contained therein: http://www.youtube.com/watch?v=ijAO0FFExx0
>
> /a
>
>
>
> _______________________________________________
> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--20cf307cff2006381b04eb3e5692
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    From what I understand, the clip from this thread was enco=
ded using MPEG-1, not H.261. Aside from http://www-mobile.ecs.soton.ac.uk/peter/h261/, I=
 don't think we have seen any samples of actual H.261 output that give =
a good indication of its suitability.
    




    On Fri, Nov 1=
5, 2013 at 5:52 AM, cowwoc <cowwoc@bbs.darktech.org> w=
rote:
    


    
 =20
   =20
 =20
  
    
    

    
      Excellent work Adam. I can't speak for others, but at 254 kbps
      (corrected figure from your follow-up post) H.261 is definitely
      "good enough" and better than an audio-only connection.
    
      
    
      Gili

    
      
    
      On 14/11/2013 6:16 PM, Adam Roach wrote:
    
    
    
    
    
     =20
      I sent a reply to this earlier, but just now realized that it went
      only to Justin, not to the list.
    
      
    
      
    
      
    
        
    On 11/14/13 13:59, Justin Uberti
          wrote:
    
        
    
        
    
          
    Thanks, this is interesting. Is the ffmpeg 261
            encoder limited to CIF/QCIF, or can you specify arbitrary
            sizes?
    
        
    
        
    
        It looks like the ffmpeg mpeg-1 coder works for arbitrary sizes.
        I'm not sure what the difference between mpeg-1 and H.261 are,
        though, so we could be talking apples and oranges (or at least
        apples and pears) here. I'll note that mpeg-1 came out in 1991,
        which is a good 22 years in the past. I'm not drawing IPR
        conclusions for you, but invite you to ponder the implications
        yourself.
    
        
    
        Following Maik's lead with the mpeg-1 js decoder, I put this
        together:
    
        
    
        https://dl.dropboxusercontent.com/u/53717247/mpg/mav=
en.html
    
        
    
        ...with this commandline:
    
        
    
        =C2=A0 ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp r=
d
        -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k
        maven.mpg
    
        
    
        I don't really understand most of those options (I just cribbed
        them from Maik's example) or whether any of them would introduc=
e
        more latency than is reasonable for a real-time conversation,
        but I will observe:
    
        
      
          
    1. The encoder claims that it was performing on the order of
            90 - 100 fps on my (admittedly modern) system;
      
          
      2. 
          
    2. The resolution is 640x360 (somewhat larger than DCIF);
      3. 
          
    3. The video is not, to my eye, unusable (draw your own
            conclusions, as it's clearly not as nice as modern codecs);=

      
          
      4. 
          
    4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
            encoding works out to 508 kbits/second total.
      5. 
        
    
        

    
        
    
        Source video here, and NASA is acknowledged as the source of the
        material contained therein: http://www.youtube.com/watch?v=3DijAO0F=
FExx0
    
        
    
        /a
    
      
    
      
    
      
    
      
    
      
    
      
    __________________________________=
_____________
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
    


    

--20cf307cff2006381b04eb3e5692--

From adam@nostrum.com  Fri Nov 15 14:23:52 2013
Return-Path: 
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 09B5221F9FB4 for ; Fri, 15 Nov 2013 14:23:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 UbeUG-mFTaOq for ; Fri, 15 Nov 2013 14:23:51 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6C711E8117 for ; Fri, 15 Nov 2013 14:23:50 -0800 (PST)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAFMNhNf009037 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 15 Nov 2013 16:23:44 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <52869EEA.8000408@nostrum.com>
Date: Fri, 15 Nov 2013 16:23:38 -0600
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: cowwoc , rtcweb@ietf.org
References: <52855B35.3080605@nostrum.com>				<5285CCCE.6040906@ericsson.com>	<528625E0.1030203@bbs.darktech.org>	<52862E10.8000506@alvestrand.no> <52863F9D.9090103@bbs.darktech.org>
In-Reply-To: <52863F9D.9090103@bbs.darktech.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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, 15 Nov 2013 22:23:52 -0000

On 11/15/13 09:37, cowwoc wrote:
> On 15/11/2013 9:22 AM, Harald Alvestrand wrote:
>> On 11/15/2013 02:47 PM, cowwoc wrote:
>>> Magnus,
>>>
>>> Couldn't we alter the option with H.261 to state that we're 
>>> proposing an IPR-expired codec *like* H.261? I don't think we need 
>>> to decide at this moment which precise codec that would be.
>>
>> If the proposal isn't for a concrete codec, it's impossible to evaluate.
>>
>> Please - if you want this option to be on the table, make it a real 
>> option, not a "someone else should do the work necessary to figure 
>> out if it's a real option".
>
> Agreed. I'll reply to Magnus's thread.

Honestly, there aren't really a lot of contenders here. There's really 
not much that predates H.261 (H.120 did, but it is *actually* unusable, 
as opposed to merely whine-worthy). Here's a realistic list of codecs to 
think about, with H.120 added just as an historical backstop to indicate 
"digital video didn't realistically exist before this point in time":

Codec           | Date | Quality (comparable to)
----------------+------+---------------------------
VP8             | 2008 | Broadcast HDTV
H.264           | 2003 | Broadcast HDTV
Theora/VP3/VP4  | 2000 | DivX-encoded movies
H.263           | 1995 | RealVideo circa 2000
H.262/MPEG2     | 1995 | DVDs
MPEG1           | 1993 | CD Videodisc
H.261           | 1988 | Early "videophones"
H.120           | 1984 | Belt-sanding your eyeballs
----------------+------+---------------------------

/a

From juberti@google.com  Fri Nov 15 18:18:31 2013
Return-Path: 
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 E729C11E812B for ; Fri, 15 Nov 2013 18:18:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.872
X-Spam-Level: 
X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=0.205,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, 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 z29P7zS05mek for ; Fri, 15 Nov 2013 18:18:30 -0800 (PST)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0325A11E81DC for ; Fri, 15 Nov 2013 18:18:29 -0800 (PST)
Received: by mail-ve0-f172.google.com with SMTP id oz11so3573598veb.3 for ; Fri, 15 Nov 2013 18:18:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MUkAIQYQ2iur4SSH6a1PMF/L2BsGuedAHdiC+HHTj9s=; b=FCUCzLVuUNFXqle8UzhYRSnYwsGk5rvH4VKCCi668nVaTNJheFCTqn0JLJXXfmsqRr 9jiRmjtTAByLQeQg+Yd7pn9I7lNAd8sC87p5RXBe7BzrZj3E0KNMAvSOXJAW6jP4zLqG KdIyjrIOYszr0HsmIg7Dqh5ZMVE9iXt5+hYhtGwrrn0PsVIngeLjrRriPgGVyHz5kh1e n/CEYup1KBj9hy1cfHZJ+KPayc81Iwy0i0aYNqDP6ZpuvC8tYYKUw6V+67ae7XSHOGtb 5GRNchnpUqju8Q1nqQWphEKda0lzv+xKqvkmAnsysNUf+6V5Tob09Xw2/oVwrgrB5Iyp kLXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MUkAIQYQ2iur4SSH6a1PMF/L2BsGuedAHdiC+HHTj9s=; b=jU/174jY0QOkOCEHRoYApaMAF06IsBsBloSX8q3tC97hydIQgLCFVL7Vve/rk9ftQi pSYdqbPNDMYrj9Gdpq95JtSBwdY7p8c68HMs+1dX/EGAUpw/l/jN/eUbo1+gN2IEXadV +0tD39nhLigVKkpLZy254PAv1Dspohf7xpMi4vP7atsOgrbb2ds8fhfsjM8saYGjHUyT gxcz2k8/Ll5cSaUcRtOeGLMBETuA5UNE8ZKvPSMJ16VxDbZc4N8GOcUShoj54bfkFdt4 EBh1vEN+M//AwlG1nUVBwN7lkVtZq+IWGi1mSNFEPiPfQ0lVAPz9yF2whXnwlMRJ+DF5 GcMw==
X-Gm-Message-State: ALoCoQn4zus3K3umueuvEUe8Ky0cJheNTj2nLK19N0/iN2RHcV8sqXz6uaH4wzgPBT22FFsRZgu339W2YjVe0alO/9Md7qxnNd30/B0C4TxiQhYqEIowaKbs+Brwdd6AUZ8IwDcaCu9+HCAorzkhIqejrtJUqjhrBi31Ta6GM39HcE4dCQGKKMOJ+KILfnHX73C2Ruynfdhl
X-Received: by 10.58.146.71 with SMTP id ta7mr3321160veb.23.1384568307902; Fri, 15 Nov 2013 18:18:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 15 Nov 2013 18:18:07 -0800 (PST)
In-Reply-To: 
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>   <528559E4.3020903@nostrum.com> <5286272B.5000005@bbs.darktech.org>  
From: Justin Uberti 
Date: Fri, 15 Nov 2013 18:18:07 -0800
Message-ID: 
To: =?UTF-8?B?SGVydsOpIFcu?= 
Content-Type: multipart/alternative; boundary=047d7b5d4a3029106204eb41eead
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)
X-BeenThere: rtcweb@ietf.org
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: Sat, 16 Nov 2013 02:18:32 -0000

--047d7b5d4a3029106204eb41eead
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
understand where things go from bad to good.


On Fri, Nov 15, 2013 at 3:42 PM, Herv=C3=A9 W.  wrote:

>    
> http://ge.tt/2bp1Zrz
>
> options used:
> mencoder.exe -ovc lavc -lavcopts vcodec=3Dh261:vbitrate=3D256 -o
> irene-256k.h261.avi sign_irene_cif.y4m
>
> mencoder.exe -ovc lavc -lavcopts
> vcodec=3Dh261:vbitrate=3D256:last_pred=3D3:predia=3D2:dia=3D2:precmp=3D2:=
cmp=3D2:subcmp=3D2:preme=3D2:mbd=3D0
> -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
>
> mencoder.exe -ovc lavc -lavcopts
> vcodec=3Dh261:vbitrate=3D15999:last_pred=3D3:predia=3D2:dia=3D2:precmp=3D=
2:cmp=3D2:subcmp=3D2:preme=3D2:mbd=3D0
> -o irene-highbitrate.h261.avi sign_irene_cif.y4m
>
> You can probably derive ffmpeg/avconv options from those.
>
> Notes
>
>    - There's a ticket open about h261
>    
>    https://trac.ffmpeg.org/ticket/3143
>    - 15999 kbps was not the bitrate irene-highbitrate ended up using;
>    that was more like 1933 kbps
>    - My untrained eye did not see any difference between
>    irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but maybe most=
 of
>    those options are (rightly) ignored for h261.
>
>
> - Herv=C3=A9
>
> ------------------------------
> From: juberti@google.com
> Date: Fri, 15 Nov 2013 14:00:50 -0800
> To: cowwoc@bbs.darktech.org
> CC: rtcweb@ietf.org
> Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
> patents evaporated)
>
>
> From what I understand, the clip from this thread was encoded using
> MPEG-1, not H.261. Aside from
> http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have seen
> any samples of actual H.261 output that give a good indication of its
> suitability.
>
>
> On Fri, Nov 15, 2013 at 5:52 AM, cowwoc  wrote:
>
>
> Excellent work Adam. I can't speak for others, but at 254 kbps (corrected
> figure from your follow-up post) H.261 is definitely "good enough" and
> better than an audio-only connection.
>
> Gili
>
>
> On 14/11/2013 6:16 PM, Adam Roach wrote:
>
> I sent a reply to this earlier, but just now realized that it went only t=
o
> Justin, not to the list.
>
>
>  On 11/14/13 13:59, Justin Uberti wrote:
>
> Thanks, this is interesting. Is the ffmpeg 261 encoder limited to
> CIF/QCIF, or can you specify arbitrary sizes?
>
>
> It looks like the ffmpeg mpeg-1 coder works for arbitrary sizes. I'm not
> sure what the difference between mpeg-1 and H.261 are, though, so we coul=
d
> be talking apples and oranges (or at least apples and pears) here. I'll
> note that mpeg-1 came out in 1991, which is a good 22 years in the past.
> I'm not drawing IPR conclusions for you, but invite you to ponder the
> implications yourself.
>
> Following Maik's lead with the mpeg-1 js decoder, I put this together:
>
> https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>
> ...with this commandline:
>
>   ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp rd -subcmp r=
d
> -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k maven.mpg
>
> I don't really understand most of those options (I just cribbed them from
> Maik's example) or whether any of them would introduce more latency than =
is
> reasonable for a real-time conversation, but I will observe:
>
>    1. The encoder claims that it was performing on the order of 90 - 100
>    fps on my (admittedly modern) system;
>     2. The resolution is 640x360 (somewhat larger than DCIF);
>    3. The video is not, to my eye, unusable (draw your own conclusions,
>    as it's clearly not as nice as modern codecs);
>     4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding
>    works out to 508 kbits/second total.
>
>
>
> Source video here, and NASA is acknowledged as the source of the material
> contained therein: http://www.youtube.com/watch?v=3DijAO0FFExx0
>
> /a
>
>
>
> _______________________________________________
> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r=
tcweb
>
>
>
> _______________________________________________
> 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
>

--047d7b5d4a3029106204eb41eead
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Thanks. Performance at 256 kbps is clearly unacceptable, 1=
933 kbps is pretty decent. Would be great to see a 512 kbps and 1024 kbps v=
ersion to understand where things go from bad to good.
    



    On Fri, Nov 15, 2013 at 3:42 PM, Herv=C3=
=A9 W. <h_o_w_@hotmail.com> wrote:
    





    



    http://ge.tt/2bp1Zrz
    


    options used:
    mencoder.exe -ovc lavc -lavcopts vcodec=3Dh261:vbitrat=
e=3D256 -o irene-256k.h261.avi sign_irene_cif.y4m

    mencoder.exe -ovc =
lavc -lavcopts vcodec=3Dh261:vbitrate=3D256:last_pred=3D3:predia=3D2:dia=3D=
2:precmp=3D2:cmp=3D2:subcmp=3D2:preme=3D2:mbd=3D0 -o irene-256k.h261.miscop=
tions.avi sign_irene_cif.y4m
    


    mencoder.exe -ovc lavc -lavcopts vcodec=3Dh261:vbitrate=3D15999:last_pr=
ed=3D3:predia=3D2:dia=3D2:precmp=3D2:cmp=3D2:subcmp=3D2:preme=3D2:mbd=3D0 -=
o irene-highbitrate.h261.avi sign_irene_cif.y4m

    You can probably der=
ive ffmpeg/avconv options from those.
    


    Notes
    • There's a ticket open about h261 https://trac.ffmpeg.org/ticket/=
3143
      • 


    • 15999 kbps was not the bitrate irene-highbitrate ended up using; that w=
as more like 1933 kbps
    • My untrained eye did not see any difference =
between irene-256k.h261.avi=20
and irene-256k.h261.miscoptions.avi but maybe most of those options are (ri=
ghtly)=20
ignored for h261.

    - Herv=C3=A9

    From: juberti@google.com
    =
Date: Fri, 15 Nov 2013 14:00:50 -0800
    To: cowwoc@bbs.darktech.org
    

CC: rtcweb@ietf.org
    Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it =
if patents	evaporated)


    From =
what I understand, the clip from this thread was encoded using MPEG-1, not =
H.261. Aside from http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don=
't think we have seen any samples of actual H.261 output that give a go=
od indication of its suitability.
    






    On Fri, Nov 15, 2013 at 5:52 AM, cowwoc <cowwoc@bb=
s.darktech.org> wrote:
    


    
 =20
   =20
 =20
  
    
    

    
      Excellent work Adam. I can't speak for others, but at 254 kbps
      (corrected figure from your follow-up post) H.261 is definitely
      "good enough" and better than an audio-only connection.
    
      
    
      Gili

    
      
    
      On 14/11/2013 6:16 PM, Adam Roach wrote:
    
    
    
    
    
     =20
      I sent a reply to this earlier, but just now realized that it went
      only to Justin, not to the list.
    
      
    
      
    
      
    
        
    On 11/14/13 13:59, Justin Uberti
          wrote:
    
        
    
        
    
          
    Thanks, this is interesting. Is the ffmpeg 261
            encoder limited to CIF/QCIF, or can you specify arbitrary
            sizes?
    
        
    
        
    
        It looks like the ffmpeg mpeg-1 coder works for arbitrary sizes.
        I'm not sure what the difference between mpeg-1 and H.261 are,
        though, so we could be talking apples and oranges (or at least
        apples and pears) here. I'll note that mpeg-1 came out in 1991,
        which is a good 22 years in the past. I'm not drawing IPR
        conclusions for you, but invite you to ponder the implications
        yourself.
    
        
    
        Following Maik's lead with the mpeg-1 js decoder, I put this
        together:
    
        
    
        https://dl.dropboxusercontent.com/u/53717247/mpg/mav=
en.html
    
        
    
        ...with this commandline:
    
        
    
        =C2=A0 ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp r=
d
        -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k
        maven.mpg
    
        
    
        I don't really understand most of those options (I just cribbed
        them from Maik's example) or whether any of them would introduc=
e
        more latency than is reasonable for a real-time conversation,
        but I will observe:
    
        
      
          
    1. The encoder claims that it was performing on the order of
            90 - 100 fps on my (admittedly modern) system;
      
          
      2. 
          
    2. The resolution is 640x360 (somewhat larger than DCIF);
      3. 
          
    3. The video is not, to my eye, unusable (draw your own
            conclusions, as it's clearly not as nice as modern codecs);=

      
          
      4. 
          
    4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
            encoding works out to 508 kbits/second total.
      5. 
        
    
        
    
        
    
        Source video here, and NASA is acknowledged as the source of the
        material contained therein: http://www.youtube.com/watch?v=3DijAO0F=
FExx0
    
        
    
        /a
    
      
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
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
    
 		 	   		  
    


    

--047d7b5d4a3029106204eb41eead--

From maikmerten@googlemail.com  Sat Nov 16 05:22:08 2013
Return-Path: 
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 6FEE311E8192 for ; Sat, 16 Nov 2013 05:22:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 kl+IKglb8boC for ; Sat, 16 Nov 2013 05:22:07 -0800 (PST)
Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 705BE11E8172 for ; Sat, 16 Nov 2013 05:22:06 -0800 (PST)
Received: by mail-ee0-f41.google.com with SMTP id t10so333451eei.28 for ; Sat, 16 Nov 2013 05:22:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kvmsUmfvmYTrOWWxLLVE1uXA404+K3D3GKb2hhpAx5I=; b=ikeJUvnkHEizw+bWImD1h1mCgwzyJ+1SscOvJR7KMmhF8bQZY7OQla0N/h71SDuO3h 3yeuYLZLbFDyu829Ak0n/XGun8bnc068ZcBd+ZNrWCtBd5RI4Cp+CIFYzeua/x7yIg6p phvIuCOZNPD51uB6qhev9DdRsVrGmIfZpXRM5mSnQ90rUqUJgg2xB3xcm51EWKDiPWBh qXvNITHr8c9s3j4TO7fEfcgK+r8kVSJOV1iyw7h6QkDAdnbZrscjPxtcP9mjhMuRybJd 1UPbBkiYFqGMVqAEnhwzGTdc/mt+upQBEXYlSjX9mQUd3+iFAxxr7tI08y3syFtKyEYv U4RA==
X-Received: by 10.14.32.196 with SMTP id o44mr7709231eea.43.1384608125526; Sat, 16 Nov 2013 05:22:05 -0800 (PST)
Received: from [192.168.2.109] (port-92-201-104-246.dynamic.qsc.de. [92.201.104.246]) by mx.google.com with ESMTPSA id x4sm16780790eef.1.2013.11.16.05.22.03 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Nov 2013 05:22:04 -0800 (PST)
Message-ID: <52877178.6040002@googlemail.com>
Date: Sat, 16 Nov 2013 14:22:00 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>			<528559E4.3020903@nostrum.com> <5286272B.5000005@bbs.darktech.org>		 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sat, 16 Nov 2013 13:22:08 -0000

I filed the ffmpeg bug regarding H.261. In a nutshell: ffmpeg currently 
crashes when enabling a certain encoder feature which turns out to be 
very useful for other codecs ("trellis quantization" - which basically 
means that coefficients to be coded are selected with the encoding costs 
in mind) for the H.261 encoder. This is a rather new encoder feature 
which pays of very nicely for other formats and should be applicable for 
H.261 as well.

A major reason IMO why H.261 performs so badly (apart from the old 
format design) is that nobody seems to have cared to transfer new 
technology for determining smart encoding choices to that old format (it 
just makes little commercial sense to strap rockets onto a pig if a 
newer format such as H.263 or H.264 is available). It appears that 
encoders for H.261 are mostly "1990ies" regarding encoding technology. 
 From today's point of view such encoders are blazingly fast, but better 
quality could be achieved with encoders that spend some computation on 
making smarter encoding choices.

The ffmpeg encoder, while working, appears to be a rather 
straightforward module for ffmpeg's internal MPEG-style encoding 
framework (I quickly skimmed through the encoder source code). I'm 
surprised that the H.261 format appears, e.g., to allow for per-GOP and 
per-Macroblock quantizer settings, which may be useful for encoding 
"important" regions with higher detail than, e.g, the background. The 
ffmpeg encoder, however, does not appear to make use of this potential 
at all - it appears to exist so that ffmpeg can cover the complete 
family of H.26x formats, not primarily to produce the best quality possible.

If somebody knows a H.261 encoder aiming at high visual encoding quality 
(and preferably still maintained and available) this may yield a better 
data point for assessing the quality that can be achieved with H.261.


Maik


Am 16.11.2013 03:18, schrieb Justin Uberti:
> Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
> pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
> understand where things go from bad to good.
>
>
> On Fri, Nov 15, 2013 at 3:42 PM, Hervé W.  > wrote:
>
>     http://ge.tt/2bp1Zrz
>
>     options used:
>     mencoder.exe -ovc lavc -lavcopts vcodec=h261:vbitrate=256 -o
>     irene-256k.h261.avi sign_irene_cif.y4m
>
>     mencoder.exe -ovc lavc -lavcopts
>     vcodec=h261:vbitrate=256:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
>     -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
>
>     mencoder.exe -ovc lavc -lavcopts
>     vcodec=h261:vbitrate=15999:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
>     -o irene-highbitrate.h261.avi sign_irene_cif.y4m
>
>     You can probably derive ffmpeg/avconv options from those.
>
>     Notes
>
>       * There's a ticket open about h261
>         https://trac.ffmpeg.org/ticket/3143
>       * 15999 kbps was not the bitrate irene-highbitrate ended up using;
>         that was more like 1933 kbps
>       * My untrained eye did not see any difference between
>         irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
>         maybe most of those options are (rightly) ignored for h261.
>
>
>     - Hervé
>
>     ------------------------------------------------------------------------
>     From: juberti@google.com 
>     Date: Fri, 15 Nov 2013 14:00:50 -0800
>     To: cowwoc@bbs.darktech.org 
>     CC: rtcweb@ietf.org 
>     Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
>     patents evaporated)
>
>
>      From what I understand, the clip from this thread was encoded using
>     MPEG-1, not H.261. Aside from
>     http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have
>     seen any samples of actual H.261 output that give a good indication
>     of its suitability.
>
>
>     On Fri, Nov 15, 2013 at 5:52 AM, cowwoc      > wrote:
>
>
>         Excellent work Adam. I can't speak for others, but at 254 kbps
>         (corrected figure from your follow-up post) H.261 is definitely
>         "good enough" and better than an audio-only connection.
>
>         Gili
>
>
>         On 14/11/2013 6:16 PM, Adam Roach wrote:
>
>             I sent a reply to this earlier, but just now realized that
>             it went only to Justin, not to the list.
>
>
>             On 11/14/13 13:59, Justin Uberti wrote:
>
>                 Thanks, this is interesting. Is the ffmpeg 261 encoder
>                 limited to CIF/QCIF, or can you specify arbitrary sizes?
>
>
>             It looks like the ffmpeg mpeg-1 coder works for arbitrary
>             sizes. I'm not sure what the difference between mpeg-1 and
>             H.261 are, though, so we could be talking apples and oranges
>             (or at least apples and pears) here. I'll note that mpeg-1
>             came out in 1991, which is a good 22 years in the past. I'm
>             not drawing IPR conclusions for you, but invite you to
>             ponder the implications yourself.
>
>             Following Maik's lead with the mpeg-1 js decoder, I put this
>             together:
>
>             https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>
>             ...with this commandline:
>
>                ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
>             -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
>             -vb 256k maven.mpg
>
>             I don't really understand most of those options (I just
>             cribbed them from Maik's example) or whether any of them
>             would introduce more latency than is reasonable for a
>             real-time conversation, but I will observe:
>
>              1. The encoder claims that it was performing on the order
>                 of 90 - 100 fps on my (admittedly modern) system;
>              2. The resolution is 640x360 (somewhat larger than DCIF);
>              3. The video is not, to my eye, unusable (draw your own
>                 conclusions, as it's clearly not as nice as modern codecs);
>              4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
>                 encoding works out to 508 kbits/second total.
>
>
>
>             Source video here, and NASA is acknowledged as the source of
>             the material contained therein:
>             http://www.youtube.com/watch?v=ijAO0FFExx0
>
>             /a
>
>
>
>             _______________________________________________
>             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
>


From maikmerten@googlemail.com  Sat Nov 16 05:28:16 2013
Return-Path: 
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 3C32C11E8173 for ; Sat, 16 Nov 2013 05:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 0ahn+Fj+Ltd7 for ; Sat, 16 Nov 2013 05:28:15 -0800 (PST)
Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7809C11E8151 for ; Sat, 16 Nov 2013 05:27:08 -0800 (PST)
Received: by mail-ea0-f175.google.com with SMTP id z16so1513100ead.34 for ; Sat, 16 Nov 2013 05:27:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=iqZ67gZ4D8/LLCJw/GJTQuiITa+zwMFCSoWQG9LczeI=; b=e2IHdJ7Ecjyl6qpOQVDcJDBTkFbIpiwMkIxkvDdVkdOy4Lfa66qqR9xalnAds1WrrP 612lj1DrmV3tZjXJBMNM9FBtVznn70vfa4IuiXEFPUdQ97WvwE08HkJdv/avyku+zNVR xDCuGEnL5qvZJIxrGkYsC8yT40LEvNfjbX3hdIYmejUWsCXNNZfBo9p6+OW0eQcz82Jx 7dGr/O+cMwwyMf2MWghVmeCh5dcyTL4hRqVJhnQAdR3iexw0+ffAoPlxifAZYO46aQ+0 Dg9h43IUo3Jr2jlnwh3h3dpPpCOZLBkr/lDL4m4ILOlqsLd2JArQ8veFgXd2MmhrA5xX h0sQ==
X-Received: by 10.15.42.193 with SMTP id u41mr7851638eev.16.1384608427317; Sat, 16 Nov 2013 05:27:07 -0800 (PST)
Received: from [192.168.2.109] (port-92-201-104-246.dynamic.qsc.de. [92.201.104.246]) by mx.google.com with ESMTPSA id w6sm16780416eeo.12.2013.11.16.05.27.05 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Nov 2013 05:27:06 -0800 (PST)
Message-ID: <528772A7.4080900@googlemail.com>
Date: Sat, 16 Nov 2013 14:27:03 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>			<528559E4.3020903@nostrum.com> <5286272B.5000005@bbs.darktech.org>		  <52877178.6040002@googlemail.com>
In-Reply-To: <52877178.6040002@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sat, 16 Nov 2013 13:28:16 -0000

Typo-correction: H.261 allows for a per-GOB (Group of Blocks) quantizer. 
A per-GOP (Group of Pictures) quantizer setting makes little sense ;)

Am 16.11.2013 14:22, schrieb Maik Merten:
> I filed the ffmpeg bug regarding H.261. In a nutshell: ffmpeg currently
> crashes when enabling a certain encoder feature which turns out to be
> very useful for other codecs ("trellis quantization" - which basically
> means that coefficients to be coded are selected with the encoding costs
> in mind) for the H.261 encoder. This is a rather new encoder feature
> which pays of very nicely for other formats and should be applicable for
> H.261 as well.
>
> A major reason IMO why H.261 performs so badly (apart from the old
> format design) is that nobody seems to have cared to transfer new
> technology for determining smart encoding choices to that old format (it
> just makes little commercial sense to strap rockets onto a pig if a
> newer format such as H.263 or H.264 is available). It appears that
> encoders for H.261 are mostly "1990ies" regarding encoding technology.
>  From today's point of view such encoders are blazingly fast, but better
> quality could be achieved with encoders that spend some computation on
> making smarter encoding choices.
>
> The ffmpeg encoder, while working, appears to be a rather
> straightforward module for ffmpeg's internal MPEG-style encoding
> framework (I quickly skimmed through the encoder source code). I'm
> surprised that the H.261 format appears, e.g., to allow for per-GOP and
> per-Macroblock quantizer settings, which may be useful for encoding
> "important" regions with higher detail than, e.g, the background. The
> ffmpeg encoder, however, does not appear to make use of this potential
> at all - it appears to exist so that ffmpeg can cover the complete
> family of H.26x formats, not primarily to produce the best quality
> possible.
>
> If somebody knows a H.261 encoder aiming at high visual encoding quality
> (and preferably still maintained and available) this may yield a better
> data point for assessing the quality that can be achieved with H.261.
>
>
> Maik
>
>
> Am 16.11.2013 03:18, schrieb Justin Uberti:
>> Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
>> pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
>> understand where things go from bad to good.
>>
>>
>> On Fri, Nov 15, 2013 at 3:42 PM, Hervé W. > > wrote:
>>
>>
>> http://ge.tt/2bp1Zrz
>>
>>
>>     options used:
>>     mencoder.exe -ovc lavc -lavcopts vcodec=h261:vbitrate=256 -o
>>     irene-256k.h261.avi sign_irene_cif.y4m
>>
>>     mencoder.exe -ovc lavc -lavcopts
>>
>> vcodec=h261:vbitrate=256:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
>>
>>     -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
>>
>>     mencoder.exe -ovc lavc -lavcopts
>>
>> vcodec=h261:vbitrate=15999:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
>>
>>     -o irene-highbitrate.h261.avi sign_irene_cif.y4m
>>
>>     You can probably derive ffmpeg/avconv options from those.
>>
>>     Notes
>>
>>       * There's a ticket open about h261
>>
>> https://trac.ffmpeg.org/ticket/3143
>>       * 15999 kbps was not the bitrate irene-highbitrate ended up using;
>>         that was more like 1933 kbps
>>       * My untrained eye did not see any difference between
>>         irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
>>         maybe most of those options are (rightly) ignored for h261.
>>
>>
>>     - Hervé
>>
>>
>> ------------------------------------------------------------------------
>>     From: juberti@google.com 
>>     Date: Fri, 15 Nov 2013 14:00:50 -0800
>>     To: cowwoc@bbs.darktech.org 
>>     CC: rtcweb@ietf.org 
>>     Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
>>     patents evaporated)
>>
>>
>>      From what I understand, the clip from this thread was encoded using
>>     MPEG-1, not H.261. Aside from
>>     http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have
>>     seen any samples of actual H.261 output that give a good indication
>>     of its suitability.
>>
>>
>>     On Fri, Nov 15, 2013 at 5:52 AM, cowwoc >     > wrote:
>>
>>
>>         Excellent work Adam. I can't speak for others, but at 254 kbps
>>         (corrected figure from your follow-up post) H.261 is definitely
>>         "good enough" and better than an audio-only connection.
>>
>>         Gili
>>
>>
>>         On 14/11/2013 6:16 PM, Adam Roach wrote:
>>
>>             I sent a reply to this earlier, but just now realized that
>>             it went only to Justin, not to the list.
>>
>>
>>             On 11/14/13 13:59, Justin Uberti wrote:
>>
>>                 Thanks, this is interesting. Is the ffmpeg 261 encoder
>>                 limited to CIF/QCIF, or can you specify arbitrary sizes?
>>
>>
>>             It looks like the ffmpeg mpeg-1 coder works for arbitrary
>>             sizes. I'm not sure what the difference between mpeg-1 and
>>             H.261 are, though, so we could be talking apples and oranges
>>             (or at least apples and pears) here. I'll note that mpeg-1
>>             came out in 1991, which is a good 22 years in the past. I'm
>>             not drawing IPR conclusions for you, but invite you to
>>             ponder the implications yourself.
>>
>>             Following Maik's lead with the mpeg-1 js decoder, I put this
>>             together:
>>
>>             https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>>
>>             ...with this commandline:
>>
>>                ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
>>             -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
>>             -vb 256k maven.mpg
>>
>>             I don't really understand most of those options (I just
>>             cribbed them from Maik's example) or whether any of them
>>             would introduce more latency than is reasonable for a
>>             real-time conversation, but I will observe:
>>
>>              1. The encoder claims that it was performing on the order
>>                 of 90 - 100 fps on my (admittedly modern) system;
>>              2. The resolution is 640x360 (somewhat larger than DCIF);
>>              3. The video is not, to my eye, unusable (draw your own
>>                 conclusions, as it's clearly not as nice as modern
>> codecs);
>>              4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
>>                 encoding works out to 508 kbits/second total.
>>
>>
>>
>>             Source video here, and NASA is acknowledged as the source of
>>             the material contained therein:
>>             http://www.youtube.com/watch?v=ijAO0FFExx0
>>
>>             /a
>>
>>
>>
>>             _______________________________________________
>>             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
>>
>


From maikmerten@googlemail.com  Sat Nov 16 09:16:07 2013
Return-Path: 
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 6529411E8150 for ; Sat, 16 Nov 2013 09:16:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 Ws22crbES-P8 for ; Sat, 16 Nov 2013 09:16:05 -0800 (PST)
Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5445411E8106 for ; Sat, 16 Nov 2013 09:16:02 -0800 (PST)
Received: by mail-ea0-f169.google.com with SMTP id l9so1612012eaj.0 for ; Sat, 16 Nov 2013 09:16:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XP+LZPRCF9C3ZND9bNOH5RWDmhLzq/DAkKbyKYssNxE=; b=dFPxks+LXIAsLG6dP3KRiOQtSPlrYQrxI7o0BzMqg7xIo2rWowMhOvj/VymwWzDyZU PjjLrV1PfXL7twz6HAIe/s3tXQhtDlzXz9zhan7aGTpZliSzNSIqPF0Y88Y1eeXNifaG mtrBhpsXXGbDX0xnSpNLPZIgOTH43VbiiXFD6JnNwPMxy4eHoYIRDlAp1T3HcS4U1bgf IekkBl/in+l6JiXpudTNPo0FZW2zokHKEHrCLIgiS0Z2JVcsxo7etTHarU/CBIR7FZlH aF2jOnppP0P8kSL+eW2FqqGz3CRQzaPbk9dEc93KYFX2SnSAZev5ohJajBMrzu7islmc WZHw==
X-Received: by 10.14.199.1 with SMTP id w1mr703728een.13.1384622161449; Sat, 16 Nov 2013 09:16:01 -0800 (PST)
Received: from [192.168.2.109] (port-92-201-104-246.dynamic.qsc.de. [92.201.104.246]) by mx.google.com with ESMTPSA id 1sm18562391eeg.4.2013.11.16.09.15.59 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Nov 2013 09:16:00 -0800 (PST)
Message-ID: <5287A84B.1020404@googlemail.com>
Date: Sat, 16 Nov 2013 18:15:55 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>			<528559E4.3020903@nostrum.com> <5286272B.5000005@bbs.darktech.org>		 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sat, 16 Nov 2013 17:16:07 -0000

I uploaded a set of H.261 encodes of the sign_irene sample, ranging from 
128 kbps to 1024 kbps. This is again done with ffmpeg, so please take my 
comments regarding its H.261 encoder into consideration.

https://drive.google.com/file/d/0B11N4VzriA21WWRoVGd6TWRwb3M/edit?usp=sharing

(btw, transmission of sign language is a nice example where "audio only" 
is not quite useful in case of video codec negotiation failure)


Maik


Am 16.11.2013 03:18, schrieb Justin Uberti:
> Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
> pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
> understand where things go from bad to good.
>
>
> On Fri, Nov 15, 2013 at 3:42 PM, Hervé W.  > wrote:
>
>     http://ge.tt/2bp1Zrz
>
>     options used:
>     mencoder.exe -ovc lavc -lavcopts vcodec=h261:vbitrate=256 -o
>     irene-256k.h261.avi sign_irene_cif.y4m
>
>     mencoder.exe -ovc lavc -lavcopts
>     vcodec=h261:vbitrate=256:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
>     -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
>
>     mencoder.exe -ovc lavc -lavcopts
>     vcodec=h261:vbitrate=15999:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
>     -o irene-highbitrate.h261.avi sign_irene_cif.y4m
>
>     You can probably derive ffmpeg/avconv options from those.
>
>     Notes
>
>       * There's a ticket open about h261
>         https://trac.ffmpeg.org/ticket/3143
>       * 15999 kbps was not the bitrate irene-highbitrate ended up using;
>         that was more like 1933 kbps
>       * My untrained eye did not see any difference between
>         irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
>         maybe most of those options are (rightly) ignored for h261.
>
>
>     - Hervé
>
>     ------------------------------------------------------------------------
>     From: juberti@google.com 
>     Date: Fri, 15 Nov 2013 14:00:50 -0800
>     To: cowwoc@bbs.darktech.org 
>     CC: rtcweb@ietf.org 
>     Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
>     patents evaporated)
>
>
>      From what I understand, the clip from this thread was encoded using
>     MPEG-1, not H.261. Aside from
>     http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have
>     seen any samples of actual H.261 output that give a good indication
>     of its suitability.
>
>
>     On Fri, Nov 15, 2013 at 5:52 AM, cowwoc      > wrote:
>
>
>         Excellent work Adam. I can't speak for others, but at 254 kbps
>         (corrected figure from your follow-up post) H.261 is definitely
>         "good enough" and better than an audio-only connection.
>
>         Gili
>
>
>         On 14/11/2013 6:16 PM, Adam Roach wrote:
>
>             I sent a reply to this earlier, but just now realized that
>             it went only to Justin, not to the list.
>
>
>             On 11/14/13 13:59, Justin Uberti wrote:
>
>                 Thanks, this is interesting. Is the ffmpeg 261 encoder
>                 limited to CIF/QCIF, or can you specify arbitrary sizes?
>
>
>             It looks like the ffmpeg mpeg-1 coder works for arbitrary
>             sizes. I'm not sure what the difference between mpeg-1 and
>             H.261 are, though, so we could be talking apples and oranges
>             (or at least apples and pears) here. I'll note that mpeg-1
>             came out in 1991, which is a good 22 years in the past. I'm
>             not drawing IPR conclusions for you, but invite you to
>             ponder the implications yourself.
>
>             Following Maik's lead with the mpeg-1 js decoder, I put this
>             together:
>
>             https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>
>             ...with this commandline:
>
>                ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
>             -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
>             -vb 256k maven.mpg
>
>             I don't really understand most of those options (I just
>             cribbed them from Maik's example) or whether any of them
>             would introduce more latency than is reasonable for a
>             real-time conversation, but I will observe:
>
>              1. The encoder claims that it was performing on the order
>                 of 90 - 100 fps on my (admittedly modern) system;
>              2. The resolution is 640x360 (somewhat larger than DCIF);
>              3. The video is not, to my eye, unusable (draw your own
>                 conclusions, as it's clearly not as nice as modern codecs);
>              4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
>                 encoding works out to 508 kbits/second total.
>
>
>
>             Source video here, and NASA is acknowledged as the source of
>             the material contained therein:
>             http://www.youtube.com/watch?v=ijAO0FFExx0
>
>             /a
>
>
>
>             _______________________________________________
>             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
>


From stewe@stewe.org  Sat Nov 16 10:17:50 2013
Return-Path: 
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 34E4311E81B2 for ; Sat, 16 Nov 2013 10:17:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1]
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 ljzV5-yr0+Gl for ; Sat, 16 Nov 2013 10:17:46 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id A455A11E81A8 for ; Sat, 16 Nov 2013 10:17:44 -0800 (PST)
Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB361.namprd07.prod.outlook.com (10.141.75.19) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sat, 16 Nov 2013 18:17:27 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) with mapi id 15.00.0820.005; Sat, 16 Nov 2013 18:17:27 +0000
From: Stephan Wenger 
To: Maik Merten , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] H261/MPEG-1 video quality
Thread-Index: AQHO4u+TetNMevLdvEG+R6V6YRXbOponpC0A
Date: Sat, 16 Nov 2013 18:17:24 +0000
Message-ID: 
In-Reply-To: <5287A84B.1020404@googlemail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [24.5.171.95]
x-forefront-prvs: 003245E729
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(164054003)(51704005)(479174003)(377454003)(24454002)(85306002)(74502001)(87936001)(74366001)(87266001)(74662001)(65816001)(31966008)(80022001)(2656002)(76482001)(54356001)(59766001)(63696002)(53806001)(15202345003)(74706001)(66066001)(77982001)(4396001)(79102001)(83072001)(81542001)(81342001)(47736001)(49866001)(47976001)(50986001)(46102001)(80976001)(81686001)(56776001)(54316002)(83322001)(19580395003)(19580405001)(74876001)(51856001)(15975445006)(56816003)(36756003)(81816001)(69226001)(47446002)(15395725003)(76176001)(76796001)(76786001)(15198665003)(77096001)(42262001)(18954195003)(473944003)(460985004)(10090945008); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB361; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:24.5.171.95; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en; 
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sat, 16 Nov 2013 18:17:50 -0000

Hi,
Back in the mid 1990s, we (at Teles AG, Germany) developed an H.261 based
desktop video conferencing system.  It ran real-time over 128 kbit/s ISDN,
at 12.5 fps, CIF, on a Pentium 133 (and well enough on a Pentium 90, with
occasional slight drops in frame rate at high motion), including the
cycles needed for G.728 audio.  We got a better quality with those
resources than what Maik has uploaded.  So Maik is quite right, the ffmpeg
encoder implementation has a lot of room for improvement.
One thing that is quite obvious in the 128 kbit/s sequence is the presence
of both blocking and mosquito artifacts.  This combination points to an
incorrect tuning of the deblocking filter.  In H.261, one can enable and
disable the deblocking filter on a per macroblock basis.  If you don=B9t ge=
t
that right, you have a lousy encoder.  The heuristics were secret sauce of
a video conferencing vendor at the time, matched in importance perhaps
only by a useful echo cancellation.  The deblocking filter obviously
reduces noise at the expense of picture fidelity.  The trick is to keep it
on most of the time in areas of high energy, but occasionally (5 picture
interval?  Something like this) switch it off to capture detail, and at
the same time fine-tune the pre filter to smoothen the input signal just a
bit so to avoid creation of excessive mosquito noise, and crank up the QP.
No, I don=B9t have the time to develop and contribute a patch for ffmpeg.
Stephan
=20
=20

On 11.16.2013, 09:15 , "Maik Merten"  wrote:

>I uploaded a set of H.261 encodes of the sign_irene sample, ranging from
>128 kbps to 1024 kbps. This is again done with ffmpeg, so please take my
>comments regarding its H.261 encoder into consideration.
>
>https://drive.google.com/file/d/0B11N4VzriA21WWRoVGd6TWRwb3M/edit?usp=3Dsh=
ar
>ing
>
>(btw, transmission of sign language is a nice example where "audio only"
>is not quite useful in case of video codec negotiation failure)
>
>
>Maik
>
>
>Am 16.11.2013 03:18, schrieb Justin Uberti:
>> Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
>> pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
>> understand where things go from bad to good.
>>
>>
>> On Fri, Nov 15, 2013 at 3:42 PM, Herv=E9 W. > > wrote:
>>
>>    =20
>>http://
>>ge.tt/2bp1Zrz
>>
>>     options used:
>>     mencoder.exe -ovc lavc -lavcopts vcodec=3Dh261:vbitrate=3D256 -o
>>     irene-256k.h261.avi sign_irene_cif.y4m
>>
>>     mencoder.exe -ovc lavc -lavcopts
>>    =20
>>vcodec=3Dh261:vbitrate=3D256:last_pred=3D3:predia=3D2:dia=3D2:precmp=3D2:=
cmp=3D2:subcmp
>>=3D2:preme=3D2:mbd=3D0
>>     -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
>>
>>     mencoder.exe -ovc lavc -lavcopts
>>    =20
>>vcodec=3Dh261:vbitrate=3D15999:last_pred=3D3:predia=3D2:dia=3D2:precmp=3D=
2:cmp=3D2:subc
>>mp=3D2:preme=3D2:mbd=3D0
>>     -o irene-highbitrate.h261.avi sign_irene_cif.y4m
>>
>>     You can probably derive ffmpeg/avconv options from those.
>>
>>     Notes
>>
>>       * There's a ticket open about h261
>>        =20
>>https://trac.ffmpeg.org/ticket/3143
>>       * 15999 kbps was not the bitrate irene-highbitrate ended up using;
>>         that was more like 1933 kbps
>>       * My untrained eye did not see any difference between
>>         irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
>>         maybe most of those options are (rightly) ignored for h261.
>>
>>
>>     - Herv=E9
>>
>>    =20
>>------------------------------------------------------------------------
>>     From: juberti@google.com 
>>     Date: Fri, 15 Nov 2013 14:00:50 -0800
>>     To: cowwoc@bbs.darktech.org 
>>     CC: rtcweb@ietf.org 
>>     Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
>>     patents evaporated)
>>
>>
>>      From what I understand, the clip from this thread was encoded using
>>     MPEG-1, not H.261. Aside from
>>     http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have
>>     seen any samples of actual H.261 output that give a good indication
>>     of its suitability.
>>
>>
>>     On Fri, Nov 15, 2013 at 5:52 AM, cowwoc >     > wrote:
>>
>>
>>         Excellent work Adam. I can't speak for others, but at 254 kbps
>>         (corrected figure from your follow-up post) H.261 is definitely
>>         "good enough" and better than an audio-only connection.
>>
>>         Gili
>>
>>
>>         On 14/11/2013 6:16 PM, Adam Roach wrote:
>>
>>             I sent a reply to this earlier, but just now realized that
>>             it went only to Justin, not to the list.
>>
>>
>>             On 11/14/13 13:59, Justin Uberti wrote:
>>
>>                 Thanks, this is interesting. Is the ffmpeg 261 encoder
>>                 limited to CIF/QCIF, or can you specify arbitrary sizes?
>>
>>
>>             It looks like the ffmpeg mpeg-1 coder works for arbitrary
>>             sizes. I'm not sure what the difference between mpeg-1 and
>>             H.261 are, though, so we could be talking apples and oranges
>>             (or at least apples and pears) here. I'll note that mpeg-1
>>             came out in 1991, which is a good 22 years in the past. I'm
>>             not drawing IPR conclusions for you, but invite you to
>>             ponder the implications yourself.
>>
>>             Following Maik's lead with the mpeg-1 js decoder, I put this
>>             together:
>>
>>             https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>>
>>             ...with this commandline:
>>
>>                ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
>>             -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
>>             -vb 256k maven.mpg
>>
>>             I don't really understand most of those options (I just
>>             cribbed them from Maik's example) or whether any of them
>>             would introduce more latency than is reasonable for a
>>             real-time conversation, but I will observe:
>>
>>              1. The encoder claims that it was performing on the order
>>                 of 90 - 100 fps on my (admittedly modern) system;
>>              2. The resolution is 640x360 (somewhat larger than DCIF);
>>              3. The video is not, to my eye, unusable (draw your own
>>                 conclusions, as it's clearly not as nice as modern
>>codecs);
>>              4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
>>                 encoding works out to 508 kbits/second total.
>>
>>
>>
>>             Source video here, and NASA is acknowledged as the source of
>>             the material contained therein:
>>             http://www.youtube.com/watch?v=3DijAO0FFExx0
>>
>>             /a
>>
>>
>>
>>             _______________________________________________
>>             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
>>
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb


From gunnar.hellstrom@omnitor.se  Sat Nov 16 11:23:23 2013
Return-Path: 
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 C679211E8188 for ; Sat, 16 Nov 2013 11:23:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6]
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 nfFY1aW0hBkG for ; Sat, 16 Nov 2013 11:23:19 -0800 (PST)
Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0D71C11E8100 for ; Sat, 16 Nov 2013 11:23:18 -0800 (PST)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTPS for ; Sat, 16 Nov 2013 20:23:09 +0100 (CET)
Received: from [192.168.50.32] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 099733A123 for ; Sat, 16 Nov 2013 20:23:09 +0100 (CET)
Message-ID: <5287C61D.8010009@omnitor.se>
Date: Sat, 16 Nov 2013 20:23:09 +0100
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070001030607070900010408"
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sat, 16 Nov 2013 19:23:23 -0000

This is a multi-part message in MIME format.
--------------070001030607070900010408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

It is unexpected and good to see the Irene test sequence being reused 
for this purpose.

The sequence was originally provided for explaining the needs for sign 
language transmission, and providing a possibility to evaluate codecs 
and products used for that purpose.
If anyone want to do more experimenting on that base, the original is 
available in a couple of formats at:
http://www.itu.int/net/itu-t/sigdb/genvideo/Hsupp_1.htm

And the document explaining the needs from sign language application is 
available at:
http://www.itu.int/rec/T-REC-H.Sup1/

/Gunnar
------------------------------------------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se

On 2013-11-16 19:17, Stephan Wenger wrote:
> Hi,
> Back in the mid 1990s, we (at Teles AG, Germany) developed an H.261 based
> desktop video conferencing system.  It ran real-time over 128 kbit/s ISDN,
> at 12.5 fps, CIF, on a Pentium 133 (and well enough on a Pentium 90, with
> occasional slight drops in frame rate at high motion), including the
> cycles needed for G.728 audio.  We got a better quality with those
> resources than what Maik has uploaded.  So Maik is quite right, the ffmpeg
> encoder implementation has a lot of room for improvement.
> One thing that is quite obvious in the 128 kbit/s sequence is the presence
> of both blocking and mosquito artifacts.  This combination points to an
> incorrect tuning of the deblocking filter.  In H.261, one can enable and
> disable the deblocking filter on a per macroblock basis.  If you don¹t get
> that right, you have a lousy encoder.  The heuristics were secret sauce of
> a video conferencing vendor at the time, matched in importance perhaps
> only by a useful echo cancellation.  The deblocking filter obviously
> reduces noise at the expense of picture fidelity.  The trick is to keep it
> on most of the time in areas of high energy, but occasionally (5 picture
> interval?  Something like this) switch it off to capture detail, and at
> the same time fine-tune the pre filter to smoothen the input signal just a
> bit so to avoid creation of excessive mosquito noise, and crank up the QP.
> No, I don¹t have the time to develop and contribute a patch for ffmpeg.
> Stephan
>   
>   
>
> On 11.16.2013, 09:15 , "Maik Merten"  wrote:
>
>> I uploaded a set of H.261 encodes of the sign_irene sample, ranging from
>> 128 kbps to 1024 kbps. This is again done with ffmpeg, so please take my
>> comments regarding its H.261 encoder into consideration.
>>
>> https://drive.google.com/file/d/0B11N4VzriA21WWRoVGd6TWRwb3M/edit?usp=shar
>> ing
>>
>> (btw, transmission of sign language is a nice example where "audio only"
>> is not quite useful in case of video codec negotiation failure)
>>
>>
>> Maik
>>
>>
>> Am 16.11.2013 03:18, schrieb Justin Uberti:
>>> Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
>>> pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
>>> understand where things go from bad to good.
>>>
>>>
>>> On Fri, Nov 15, 2013 at 3:42 PM, Hervé W. >> > wrote:
>>>
>>>      
>>> http://
>>> ge.tt/2bp1Zrz
>>>
>>>      options used:
>>>      mencoder.exe -ovc lavc -lavcopts vcodec=h261:vbitrate=256 -o
>>>      irene-256k.h261.avi sign_irene_cif.y4m
>>>
>>>      mencoder.exe -ovc lavc -lavcopts
>>>      
>>> vcodec=h261:vbitrate=256:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp
>>> =2:preme=2:mbd=0
>>>      -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
>>>
>>>      mencoder.exe -ovc lavc -lavcopts
>>>      
>>> vcodec=h261:vbitrate=15999:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subc
>>> mp=2:preme=2:mbd=0
>>>      -o irene-highbitrate.h261.avi sign_irene_cif.y4m
>>>
>>>      You can probably derive ffmpeg/avconv options from those.
>>>
>>>      Notes
>>>
>>>        * There's a ticket open about h261
>>>          
>>> https://trac.ffmpeg.org/ticket/3143
>>>        * 15999 kbps was not the bitrate irene-highbitrate ended up using;
>>>          that was more like 1933 kbps
>>>        * My untrained eye did not see any difference between
>>>          irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
>>>          maybe most of those options are (rightly) ignored for h261.
>>>
>>>
>>>      - Hervé
>>>
>>>      
>>> ------------------------------------------------------------------------
>>>      From: juberti@google.com 
>>>      Date: Fri, 15 Nov 2013 14:00:50 -0800
>>>      To: cowwoc@bbs.darktech.org 
>>>      CC: rtcweb@ietf.org 
>>>      Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
>>>      patents evaporated)
>>>
>>>
>>>       From what I understand, the clip from this thread was encoded using
>>>      MPEG-1, not H.261. Aside from
>>>      http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have
>>>      seen any samples of actual H.261 output that give a good indication
>>>      of its suitability.
>>>
>>>
>>>      On Fri, Nov 15, 2013 at 5:52 AM, cowwoc >>      > wrote:
>>>
>>>
>>>          Excellent work Adam. I can't speak for others, but at 254 kbps
>>>          (corrected figure from your follow-up post) H.261 is definitely
>>>          "good enough" and better than an audio-only connection.
>>>
>>>          Gili
>>>
>>>
>>>          On 14/11/2013 6:16 PM, Adam Roach wrote:
>>>
>>>              I sent a reply to this earlier, but just now realized that
>>>              it went only to Justin, not to the list.
>>>
>>>
>>>              On 11/14/13 13:59, Justin Uberti wrote:
>>>
>>>                  Thanks, this is interesting. Is the ffmpeg 261 encoder
>>>                  limited to CIF/QCIF, or can you specify arbitrary sizes?
>>>
>>>
>>>              It looks like the ffmpeg mpeg-1 coder works for arbitrary
>>>              sizes. I'm not sure what the difference between mpeg-1 and
>>>              H.261 are, though, so we could be talking apples and oranges
>>>              (or at least apples and pears) here. I'll note that mpeg-1
>>>              came out in 1991, which is a good 22 years in the past. I'm
>>>              not drawing IPR conclusions for you, but invite you to
>>>              ponder the implications yourself.
>>>
>>>              Following Maik's lead with the mpeg-1 js decoder, I put this
>>>              together:
>>>
>>>              https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>>>
>>>              ...with this commandline:
>>>
>>>                 ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
>>>              -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
>>>              -vb 256k maven.mpg
>>>
>>>              I don't really understand most of those options (I just
>>>              cribbed them from Maik's example) or whether any of them
>>>              would introduce more latency than is reasonable for a
>>>              real-time conversation, but I will observe:
>>>
>>>               1. The encoder claims that it was performing on the order
>>>                  of 90 - 100 fps on my (admittedly modern) system;
>>>               2. The resolution is 640x360 (somewhat larger than DCIF);
>>>               3. The video is not, to my eye, unusable (draw your own
>>>                  conclusions, as it's clearly not as nice as modern
>>> codecs);
>>>               4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
>>>                  encoding works out to 508 kbits/second total.
>>>
>>>
>>>
>>>              Source video here, and NASA is acknowledged as the source of
>>>              the material contained therein:
>>>              http://www.youtube.com/watch?v=ijAO0FFExx0
>>>
>>>              /a
>>>
>>>
>>>
>>>              _______________________________________________
>>>              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
>>>
>> _______________________________________________
>> 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


--------------070001030607070900010408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
    It is unexpected and good to see the
      Irene test sequence being reused for this purpose.
    
      
    
      The sequence was originally provided for explaining the needs for
      sign language transmission, and providing a possibility to
      evaluate codecs and products used for that purpose.
    
      If anyone want to do more experimenting on that base, the original
      is available in a couple of formats at:
    
      http://www.itu.int/net/itu-t/sigdb/genvideo/Hsupp_1.htm
    
      
    
      And the document explaining the needs from sign language
      application is available at:
    
      http://www.itu.int/rec/T-REC-H.Sup1/
    
      
    
      /Gunnar
    
      
    
        
    
        Gunnar Hellström
    
        Omnitor
    
        gunnar.hellstrom@omnitor.se
    
        
    
      
    
      On 2013-11-16 19:17, Stephan Wenger wrote:
    
    
    
    
    
      
    Hi,
Back in the mid 1990s, we (at Teles AG, Germany) developed an H.261 based
desktop video conferencing system.  It ran real-time over 128 kbit/s ISDN,
at 12.5 fps, CIF, on a Pentium 133 (and well enough on a Pentium 90, with
occasional slight drops in frame rate at high motion), including the
cycles needed for G.728 audio.  We got a better quality with those
resources than what Maik has uploaded.  So Maik is quite right, the ffmpeg
encoder implementation has a lot of room for improvement.
One thing that is quite obvious in the 128 kbit/s sequence is the presence
of both blocking and mosquito artifacts.  This combination points to an
incorrect tuning of the deblocking filter.  In H.261, one can enable and
disable the deblocking filter on a per macroblock basis.  If you don¹t get
that right, you have a lousy encoder.  The heuristics were secret sauce of
a video conferencing vendor at the time, matched in importance perhaps
only by a useful echo cancellation.  The deblocking filter obviously
reduces noise at the expense of picture fidelity.  The trick is to keep it
on most of the time in areas of high energy, but occasionally (5 picture
interval?  Something like this) switch it off to capture detail, and at
the same time fine-tune the pre filter to smoothen the input signal just a
bit so to avoid creation of excessive mosquito noise, and crank up the QP.
No, I don¹t have the time to develop and contribute a patch for ffmpeg.
Stephan
 
 

On 11.16.2013, 09:15 , "Maik Merten" <maikmerten@googlemail.com> wrote:


    
      
    
        
    I uploaded a set of H.261 encodes of the sign_irene sample, ranging from
128 kbps to 1024 kbps. This is again done with ffmpeg, so please take my
comments regarding its H.261 encoder into consideration.

https://drive.google.com/file/d/0B11N4VzriA21WWRoVGd6TWRwb3M/edit?usp=shar
ing

(btw, transmission of sign language is a nice example where "audio only"
is not quite useful in case of video codec negotiation failure)


Maik


Am 16.11.2013 03:18, schrieb Justin Uberti:

    
        
    
          
    Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
understand where things go from bad to good.


On Fri, Nov 15, 2013 at 3:42 PM, Hervé W. <h_o_w_@hotmail.com
<mailto:h_o_w_@hotmail.com>> wrote:

    
<http://ge.tt/2bp1Zrz><http://ge.tt/2bp1Zrz><http://ge.tt/2bp1Zrz>http://
ge.tt/2bp1Zrz

    options used:
    mencoder.exe -ovc lavc -lavcopts vcodec=h261:vbitrate=256 -o
    irene-256k.h261.avi sign_irene_cif.y4m

    mencoder.exe -ovc lavc -lavcopts
    
vcodec=h261:vbitrate=256:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp
=2:preme=2:mbd=0
    -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m

    mencoder.exe -ovc lavc -lavcopts
    
vcodec=h261:vbitrate=15999:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subc
mp=2:preme=2:mbd=0
    -o irene-highbitrate.h261.avi sign_irene_cif.y4m

    You can probably derive ffmpeg/avconv options from those.

    Notes

      * There's a ticket open about h261
        
<https://trac.ffmpeg.org/ticket/3143>https://trac.ffmpeg.org/ticket/3143
      * 15999 kbps was not the bitrate irene-highbitrate ended up using;
        that was more like 1933 kbps
      * My untrained eye did not see any difference between
        irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
        maybe most of those options are (rightly) ignored for h261.


    - Hervé

    
------------------------------------------------------------------------
    From: juberti@google.com <mailto:juberti@google.com>
    Date: Fri, 15 Nov 2013 14:00:50 -0800
    To: cowwoc@bbs.darktech.org <mailto:cowwoc@bbs.darktech.org>
    CC: rtcweb@ietf.org <mailto:rtcweb@ietf.org>
    Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
    patents evaporated)


     From what I understand, the clip from this thread was encoded using
    MPEG-1, not H.261. Aside from
    http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have
    seen any samples of actual H.261 output that give a good indication
    of its suitability.


    On Fri, Nov 15, 2013 at 5:52 AM, cowwoc <cowwoc@bbs.darktech.org
    <mailto:cowwoc@bbs.darktech.org>> wrote:


        Excellent work Adam. I can't speak for others, but at 254 kbps
        (corrected figure from your follow-up post) H.261 is definitely
        "good enough" and better than an audio-only connection.

        Gili


        On 14/11/2013 6:16 PM, Adam Roach wrote:

            I sent a reply to this earlier, but just now realized that
            it went only to Justin, not to the list.


            On 11/14/13 13:59, Justin Uberti wrote:

                Thanks, this is interesting. Is the ffmpeg 261 encoder
                limited to CIF/QCIF, or can you specify arbitrary sizes?


            It looks like the ffmpeg mpeg-1 coder works for arbitrary
            sizes. I'm not sure what the difference between mpeg-1 and
            H.261 are, though, so we could be talking apples and oranges
            (or at least apples and pears) here. I'll note that mpeg-1
            came out in 1991, which is a good 22 years in the past. I'm
            not drawing IPR conclusions for you, but invite you to
            ponder the implications yourself.

            Following Maik's lead with the mpeg-1 js decoder, I put this
            together:

            https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html

            ...with this commandline:

               ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
            -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
            -vb 256k maven.mpg

            I don't really understand most of those options (I just
            cribbed them from Maik's example) or whether any of them
            would introduce more latency than is reasonable for a
            real-time conversation, but I will observe:

             1. The encoder claims that it was performing on the order
                of 90 - 100 fps on my (admittedly modern) system;
             2. The resolution is 640x360 (somewhat larger than DCIF);
             3. The video is not, to my eye, unusable (draw your own
                conclusions, as it's clearly not as nice as modern
codecs);
             4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
                encoding works out to 508 kbits/second total.



            Source video here, and NASA is acknowledged as the source of
            the material contained therein:
            http://www.youtube.com/watch?v=ijAO0FFExx0

            /a



            _______________________________________________
            rtcweb mailing list
            rtcweb@ietf.org  <mailto:rtcweb@ietf.org>
            https://www.ietf.org/mailman/listinfo/rtcweb



        _______________________________________________
        rtcweb mailing list
        rtcweb@ietf.org <mailto:rtcweb@ietf.org>
        https://www.ietf.org/mailman/listinfo/rtcweb



    _______________________________________________ rtcweb mailing list
    rtcweb@ietf.org <mailto: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

    
    
    
    
    
  


--------------070001030607070900010408--

From randell-ietf@jesup.org  Sat Nov 16 14:12:40 2013
Return-Path: 
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 9023711E83AE for ; Sat, 16 Nov 2013 14:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 sBDm2W7o66aJ for ; Sat, 16 Nov 2013 14:12:34 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id BA77411E838A for ; Sat, 16 Nov 2013 14:12:34 -0800 (PST)
Received: from pool-173-49-144-199.phlapa.fios.verizon.net ([173.49.144.199]:3929 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Vho6T-000GSg-Qf for rtcweb@ietf.org; Sat, 16 Nov 2013 16:12:33 -0600
Message-ID: <5287ED8A.9060305@jesup.org>
Date: Sat, 16 Nov 2013 17:11:22 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52855B35.3080605@nostrum.com>				<5285CCCE.6040906@ericsson.com>	<528625E0.1030203@bbs.darktech.org>	<52862E10.8000506@alvestrand.no>	<52863F9D.9090103@bbs.darktech.org> <52869EEA.8000408@nostrum.com>
In-Reply-To: <52869EEA.8000408@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sat, 16 Nov 2013 22:12:40 -0000

On 11/15/2013 5:23 PM, Adam Roach wrote:
>
> Honestly, there aren't really a lot of contenders here. There's really 
> not much that predates H.261 (H.120 did, but it is *actually* 
> unusable, as opposed to merely whine-worthy). Here's a realistic list 
> of codecs to think about, with H.120 added just as an historical 
> backstop to indicate "digital video didn't realistically exist before 
> this point in time":
>
> Codec           | Date | Quality (comparable to)
> ----------------+------+---------------------------
> VP8             | 2008 | Broadcast HDTV
> H.264           | 2003 | Broadcast HDTV

Broadcast HDTV is MPEG2, starting circa 1999/2000,and still is so far as 
I know.  I think you mean that Cable/Satellite HDTV started using H.264 
in circa 2003.

> Theora/VP3/VP4 | 2000 | DivX-encoded movies
> H.263           | 1995 | RealVideo circa 2000
> H.262/MPEG2     | 1995 | DVDs
> MPEG1           | 1993 | CD Videodisc
> H.261           | 1988 | Early "videophones"
> H.120           | 1984 | Belt-sanding your eyeballs
> ----------------+------+---------------------------

-- 
Randell Jesup -- rjesup a t mozilla d o t com


From adam@nostrum.com  Sat Nov 16 16:23:04 2013
Return-Path: 
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 4B52311E80EA for ; Sat, 16 Nov 2013 16:23:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 PVeEL4nad0qb for ; Sat, 16 Nov 2013 16:23:03 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABAE11E80E2 for ; Sat, 16 Nov 2013 16:23:03 -0800 (PST)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAH0N0Fb071671 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 16 Nov 2013 18:23:02 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <52880C60.9040209@nostrum.com>
Date: Sat, 16 Nov 2013 18:22:56 -0600
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Randell Jesup , rtcweb@ietf.org
References: <52855B35.3080605@nostrum.com>				<5285CCCE.6040906@ericsson.com>	<528625E0.1030203@bbs.darktech.org>	<52862E10.8000506@alvestrand.no>	<52863F9D.9090103@bbs.darktech.org>	<52869EEA.8000408@nostrum.com> <5287ED8A.9060305@jesup.org>
In-Reply-To: <5287ED8A.9060305@jesup.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 00:23:04 -0000

On 11/16/13 16:11, Randell Jesup wrote:
> Broadcast HDTV is MPEG2, starting circa 1999/2000,and still is so far 
> as I know.  I think you mean that Cable/Satellite HDTV started using 
> H.264 in circa 2003. 

I'm don't know about the rest of the world, but at least North America 
includes H.264 as one of the supported codecs now:

http://en.wikipedia.org/wiki/Advanced_Television_Systems_Committee_standards#H.264.2FMPEG-4_AVC

Of course, given that this happened after significant hardware was out 
in the field, it's questionable whether there's been much actual *use* 
of H.264 in ATSC.

/a

From maikmerten@googlemail.com  Sun Nov 17 06:06:10 2013
Return-Path: 
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 40E9911E8191 for ; Sun, 17 Nov 2013 06:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 KHWxmYqTVqLD for ; Sun, 17 Nov 2013 06:06:09 -0800 (PST)
Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA4411E8115 for ; Sun, 17 Nov 2013 06:06:05 -0800 (PST)
Received: by mail-ea0-f177.google.com with SMTP id n15so475297ead.22 for ; Sun, 17 Nov 2013 06:05:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Nod9V2/YFh9NVZ8zw5aO98VECMqHvTcEMXenfXOcMxY=; b=0DYCq9lVnQsIctDRbgGDopL6mrDNFizM08ZUDDnZEAnDaxP9sxHusfdK9GWmX27Qjr zVdhFnWxKIEtDZsIV15WTIL7rp/aTOVS+dKj9c5xF4Xiq7lk9+1xKgGJhBq7qzZhp2zt WzGHfjMQxq1vnih+QdEE6S9WfHAw0qCCheQw4RA94zhBo5nUcKrGxwGqYNzwwbhevQV1 BPnYw7H3r0v5WBDYJBiFfnuJRCYNGQA0kTrChx7HQNnCXSKb2zqGd3i0GGahyEOfNPsa 9iNz7b4OTCMSM8V/QkIC6bn5ZPqQeh/FazYCZKVmI2nMiyrN85+wCQ991+XzwhZqiLos YnlQ==
X-Received: by 10.14.210.200 with SMTP id u48mr191600eeo.63.1384697158727; Sun, 17 Nov 2013 06:05:58 -0800 (PST)
Received: from [192.168.2.109] (port-92-201-15-141.dynamic.qsc.de. [92.201.15.141]) by mx.google.com with ESMTPSA id i1sm27599065eeg.0.2013.11.17.06.05.55 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 06:05:56 -0800 (PST)
Message-ID: <5288CD41.30508@googlemail.com>
Date: Sun, 17 Nov 2013 15:05:53 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 14:06:10 -0000

Dear Stephan,

thanks for sharing your experience regarding high-performance H.261 
implementations and confirming my suspicion regarding ffmpeg's encoder. 
Do you happen to remember if there was any postprocessing involved at 
the receiving end? I find that playback of the low-bitrate encodes 
becomes somewhat more enjoyable with some postprocessing (deblocking, 
deringing) (mplayer -vf pp) and I wonder if one should assume the 
presence of such filters when assessing the quality achievable (given 
that any modern devices have no trouble with the additional computation).


Maik

Am 16.11.2013 19:17, schrieb Stephan Wenger:
> Hi,
> Back in the mid 1990s, we (at Teles AG, Germany) developed an H.261 based
> desktop video conferencing system.  It ran real-time over 128 kbit/s ISDN,
> at 12.5 fps, CIF, on a Pentium 133 (and well enough on a Pentium 90, with
> occasional slight drops in frame rate at high motion), including the
> cycles needed for G.728 audio.  We got a better quality with those
> resources than what Maik has uploaded.  So Maik is quite right, the ffmpeg
> encoder implementation has a lot of room for improvement.
> One thing that is quite obvious in the 128 kbit/s sequence is the presence
> of both blocking and mosquito artifacts.  This combination points to an
> incorrect tuning of the deblocking filter.  In H.261, one can enable and
> disable the deblocking filter on a per macroblock basis.  If you don¹t get
> that right, you have a lousy encoder.  The heuristics were secret sauce of
> a video conferencing vendor at the time, matched in importance perhaps
> only by a useful echo cancellation.  The deblocking filter obviously
> reduces noise at the expense of picture fidelity.  The trick is to keep it
> on most of the time in areas of high energy, but occasionally (5 picture
> interval?  Something like this) switch it off to capture detail, and at
> the same time fine-tune the pre filter to smoothen the input signal just a
> bit so to avoid creation of excessive mosquito noise, and crank up the QP.
> No, I don¹t have the time to develop and contribute a patch for ffmpeg.
> Stephan
>
>
>
> On 11.16.2013, 09:15 , "Maik Merten"  wrote:
>
>> I uploaded a set of H.261 encodes of the sign_irene sample, ranging from
>> 128 kbps to 1024 kbps. This is again done with ffmpeg, so please take my
>> comments regarding its H.261 encoder into consideration.
>>
>> https://drive.google.com/file/d/0B11N4VzriA21WWRoVGd6TWRwb3M/edit?usp=shar
>> ing
>>
>> (btw, transmission of sign language is a nice example where "audio only"
>> is not quite useful in case of video codec negotiation failure)
>>
>>
>> Maik
>>
>>
>> Am 16.11.2013 03:18, schrieb Justin Uberti:
>>> Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
>>> pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
>>> understand where things go from bad to good.
>>>
>>>
>>> On Fri, Nov 15, 2013 at 3:42 PM, Hervé W. >> > wrote:
>>>
>>>
>>> http://
>>> ge.tt/2bp1Zrz
>>>
>>>      options used:
>>>      mencoder.exe -ovc lavc -lavcopts vcodec=h261:vbitrate=256 -o
>>>      irene-256k.h261.avi sign_irene_cif.y4m
>>>
>>>      mencoder.exe -ovc lavc -lavcopts
>>>
>>> vcodec=h261:vbitrate=256:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp
>>> =2:preme=2:mbd=0
>>>      -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
>>>
>>>      mencoder.exe -ovc lavc -lavcopts
>>>
>>> vcodec=h261:vbitrate=15999:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subc
>>> mp=2:preme=2:mbd=0
>>>      -o irene-highbitrate.h261.avi sign_irene_cif.y4m
>>>
>>>      You can probably derive ffmpeg/avconv options from those.
>>>
>>>      Notes
>>>
>>>        * There's a ticket open about h261
>>>
>>> https://trac.ffmpeg.org/ticket/3143
>>>        * 15999 kbps was not the bitrate irene-highbitrate ended up using;
>>>          that was more like 1933 kbps
>>>        * My untrained eye did not see any difference between
>>>          irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
>>>          maybe most of those options are (rightly) ignored for h261.
>>>
>>>
>>>      - Hervé
>>>
>>>
>>> ------------------------------------------------------------------------
>>>      From: juberti@google.com 
>>>      Date: Fri, 15 Nov 2013 14:00:50 -0800
>>>      To: cowwoc@bbs.darktech.org 
>>>      CC: rtcweb@ietf.org 
>>>      Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
>>>      patents evaporated)
>>>
>>>
>>>       From what I understand, the clip from this thread was encoded using
>>>      MPEG-1, not H.261. Aside from
>>>      http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have
>>>      seen any samples of actual H.261 output that give a good indication
>>>      of its suitability.
>>>
>>>
>>>      On Fri, Nov 15, 2013 at 5:52 AM, cowwoc >>      > wrote:
>>>
>>>
>>>          Excellent work Adam. I can't speak for others, but at 254 kbps
>>>          (corrected figure from your follow-up post) H.261 is definitely
>>>          "good enough" and better than an audio-only connection.
>>>
>>>          Gili
>>>
>>>
>>>          On 14/11/2013 6:16 PM, Adam Roach wrote:
>>>
>>>              I sent a reply to this earlier, but just now realized that
>>>              it went only to Justin, not to the list.
>>>
>>>
>>>              On 11/14/13 13:59, Justin Uberti wrote:
>>>
>>>                  Thanks, this is interesting. Is the ffmpeg 261 encoder
>>>                  limited to CIF/QCIF, or can you specify arbitrary sizes?
>>>
>>>
>>>              It looks like the ffmpeg mpeg-1 coder works for arbitrary
>>>              sizes. I'm not sure what the difference between mpeg-1 and
>>>              H.261 are, though, so we could be talking apples and oranges
>>>              (or at least apples and pears) here. I'll note that mpeg-1
>>>              came out in 1991, which is a good 22 years in the past. I'm
>>>              not drawing IPR conclusions for you, but invite you to
>>>              ponder the implications yourself.
>>>
>>>              Following Maik's lead with the mpeg-1 js decoder, I put this
>>>              together:
>>>
>>>              https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>>>
>>>              ...with this commandline:
>>>
>>>                 ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
>>>              -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
>>>              -vb 256k maven.mpg
>>>
>>>              I don't really understand most of those options (I just
>>>              cribbed them from Maik's example) or whether any of them
>>>              would introduce more latency than is reasonable for a
>>>              real-time conversation, but I will observe:
>>>
>>>               1. The encoder claims that it was performing on the order
>>>                  of 90 - 100 fps on my (admittedly modern) system;
>>>               2. The resolution is 640x360 (somewhat larger than DCIF);
>>>               3. The video is not, to my eye, unusable (draw your own
>>>                  conclusions, as it's clearly not as nice as modern
>>> codecs);
>>>               4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
>>>                  encoding works out to 508 kbits/second total.
>>>
>>>
>>>
>>>              Source video here, and NASA is acknowledged as the source of
>>>              the material contained therein:
>>>              http://www.youtube.com/watch?v=ijAO0FFExx0
>>>
>>>              /a
>>>
>>>
>>>
>>>              _______________________________________________
>>>              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
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>


From maikmerten@googlemail.com  Sun Nov 17 06:30:11 2013
Return-Path: 
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 106EC11E8183 for ; Sun, 17 Nov 2013 06:30:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 vuLSfipGPLN3 for ; Sun, 17 Nov 2013 06:30:09 -0800 (PST)
Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8A98A11E8D60 for ; Sun, 17 Nov 2013 06:30:04 -0800 (PST)
Received: by mail-ea0-f180.google.com with SMTP id f15so121430eak.39 for ; Sun, 17 Nov 2013 06:29:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qdW8VgReqZEAKVQqIBGHgRpwvWLzvMSQL2AYrwrNfH0=; b=f/lSumuLBS9sg38Xy7WeAwMsJKbp+QC1fhFjW+IYxkixsLID7pjkeG5PgIm+K3wNbj 4u2JWS3ize3+C5X5rXCQ6mpjRdWEfgL9EX3gh1+x486mjaPlScjoKSa0g0m3sjprE4p6 Gc/ZpLdSmcj19Z+xzaVJBRh39vHolWGXGa9r1zZbx+TMZmF6Do/o0BvopIYX17dtG/p5 FZ0yLl7X4uQSpNpZNe+n3zEqyxyKytmYnbBWjnX57XvuEccXAM/RZkq6UVpRlaUcQgtx +dqpKrEbzS8M9ttaqrTyrkvVkMiPHJFaWTR/nANtWwRBHRaNzC051XFsYs0aD2otQ3a/ G6ig==
X-Received: by 10.14.212.72 with SMTP id x48mr4777587eeo.0.1384698595987; Sun, 17 Nov 2013 06:29:55 -0800 (PST)
Received: from [192.168.2.109] (port-92-201-15-141.dynamic.qsc.de. [92.201.15.141]) by mx.google.com with ESMTPSA id a51sm27758279eeh.8.2013.11.17.06.29.53 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 06:29:55 -0800 (PST)
Message-ID: <5288D2E0.3010503@googlemail.com>
Date: Sun, 17 Nov 2013 15:29:52 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <5287C61D.8010009@omnitor.se>
In-Reply-To: <5287C61D.8010009@omnitor.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 14:30:11 -0000

Dear Gunnar,

Irene is one of my favorite test sequences: It's pleasant to look at, 
has interesting texturing detail, complex movement, diverse facial 
expressions and demonstrates an important use case for video 
communication. In fact, I think this use case nicely demonstrates why 
negotiation failure regarding video codecs should be avoided (even if 
this means making an outdated codec MTI, as long as it can transport 
sign language).

Thanks for providing a link to the ITU documentation regarding this 
application profile and test sequence - it's an interesting read!


Best regards,

Maik

Am 16.11.2013 20:23, schrieb Gunnar Hellstrom:
> It is unexpected and good to see the Irene test sequence being reused
> for this purpose.
>
> The sequence was originally provided for explaining the needs for sign
> language transmission, and providing a possibility to evaluate codecs
> and products used for that purpose.
> If anyone want to do more experimenting on that base, the original is
> available in a couple of formats at:
> http://www.itu.int/net/itu-t/sigdb/genvideo/Hsupp_1.htm
>
> And the document explaining the needs from sign language application is
> available at:
> http://www.itu.int/rec/T-REC-H.Sup1/
>
> /Gunnar
> ------------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
>
> On 2013-11-16 19:17, Stephan Wenger wrote:
>> Hi,
>> Back in the mid 1990s, we (at Teles AG, Germany) developed an H.261 based
>> desktop video conferencing system.  It ran real-time over 128 kbit/s ISDN,
>> at 12.5 fps, CIF, on a Pentium 133 (and well enough on a Pentium 90, with
>> occasional slight drops in frame rate at high motion), including the
>> cycles needed for G.728 audio.  We got a better quality with those
>> resources than what Maik has uploaded.  So Maik is quite right, the ffmpeg
>> encoder implementation has a lot of room for improvement.
>> One thing that is quite obvious in the 128 kbit/s sequence is the presence
>> of both blocking and mosquito artifacts.  This combination points to an
>> incorrect tuning of the deblocking filter.  In H.261, one can enable and
>> disable the deblocking filter on a per macroblock basis.  If you don¹t get
>> that right, you have a lousy encoder.  The heuristics were secret sauce of
>> a video conferencing vendor at the time, matched in importance perhaps
>> only by a useful echo cancellation.  The deblocking filter obviously
>> reduces noise at the expense of picture fidelity.  The trick is to keep it
>> on most of the time in areas of high energy, but occasionally (5 picture
>> interval?  Something like this) switch it off to capture detail, and at
>> the same time fine-tune the pre filter to smoothen the input signal just a
>> bit so to avoid creation of excessive mosquito noise, and crank up the QP.
>> No, I don¹t have the time to develop and contribute a patch for ffmpeg.
>> Stephan
>>
>>
>>
>> On 11.16.2013, 09:15 , "Maik Merten"  wrote:
>>
>>> I uploaded a set of H.261 encodes of the sign_irene sample, ranging from
>>> 128 kbps to 1024 kbps. This is again done with ffmpeg, so please take my
>>> comments regarding its H.261 encoder into consideration.
>>>
>>> https://drive.google.com/file/d/0B11N4VzriA21WWRoVGd6TWRwb3M/edit?usp=shar
>>> ing
>>>
>>> (btw, transmission of sign language is a nice example where "audio only"
>>> is not quite useful in case of video codec negotiation failure)
>>>
>>>
>>> Maik
>>>
>>>
>>> Am 16.11.2013 03:18, schrieb Justin Uberti:
>>>> Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
>>>> pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
>>>> understand where things go from bad to good.
>>>>
>>>>
>>>> On Fri, Nov 15, 2013 at 3:42 PM, Hervé W. >>> > wrote:
>>>>
>>>>
>>>> http://
>>>> ge.tt/2bp1Zrz
>>>>
>>>>      options used:
>>>>      mencoder.exe -ovc lavc -lavcopts vcodec=h261:vbitrate=256 -o
>>>>      irene-256k.h261.avi sign_irene_cif.y4m
>>>>
>>>>      mencoder.exe -ovc lavc -lavcopts
>>>>
>>>> vcodec=h261:vbitrate=256:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp
>>>> =2:preme=2:mbd=0
>>>>      -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
>>>>
>>>>      mencoder.exe -ovc lavc -lavcopts
>>>>
>>>> vcodec=h261:vbitrate=15999:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subc
>>>> mp=2:preme=2:mbd=0
>>>>      -o irene-highbitrate.h261.avi sign_irene_cif.y4m
>>>>
>>>>      You can probably derive ffmpeg/avconv options from those.
>>>>
>>>>      Notes
>>>>
>>>>        * There's a ticket open about h261
>>>>
>>>> https://trac.ffmpeg.org/ticket/3143
>>>>        * 15999 kbps was not the bitrate irene-highbitrate ended up using;
>>>>          that was more like 1933 kbps
>>>>        * My untrained eye did not see any difference between
>>>>          irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
>>>>          maybe most of those options are (rightly) ignored for h261.
>>>>
>>>>
>>>>      - Hervé
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>      From:juberti@google.com  
>>>>      Date: Fri, 15 Nov 2013 14:00:50 -0800
>>>>      To:cowwoc@bbs.darktech.org  
>>>>      CC:rtcweb@ietf.org  
>>>>      Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
>>>>      patents evaporated)
>>>>
>>>>
>>>>       From what I understand, the clip from this thread was encoded using
>>>>      MPEG-1, not H.261. Aside from
>>>>      http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have
>>>>      seen any samples of actual H.261 output that give a good indication
>>>>      of its suitability.
>>>>
>>>>
>>>>      On Fri, Nov 15, 2013 at 5:52 AM, cowwoc >>>      > wrote:
>>>>
>>>>
>>>>          Excellent work Adam. I can't speak for others, but at 254 kbps
>>>>          (corrected figure from your follow-up post) H.261 is definitely
>>>>          "good enough" and better than an audio-only connection.
>>>>
>>>>          Gili
>>>>
>>>>
>>>>          On 14/11/2013 6:16 PM, Adam Roach wrote:
>>>>
>>>>              I sent a reply to this earlier, but just now realized that
>>>>              it went only to Justin, not to the list.
>>>>
>>>>
>>>>              On 11/14/13 13:59, Justin Uberti wrote:
>>>>
>>>>                  Thanks, this is interesting. Is the ffmpeg 261 encoder
>>>>                  limited to CIF/QCIF, or can you specify arbitrary sizes?
>>>>
>>>>
>>>>              It looks like the ffmpeg mpeg-1 coder works for arbitrary
>>>>              sizes. I'm not sure what the difference between mpeg-1 and
>>>>              H.261 are, though, so we could be talking apples and oranges
>>>>              (or at least apples and pears) here. I'll note that mpeg-1
>>>>              came out in 1991, which is a good 22 years in the past. I'm
>>>>              not drawing IPR conclusions for you, but invite you to
>>>>              ponder the implications yourself.
>>>>
>>>>              Following Maik's lead with the mpeg-1 js decoder, I put this
>>>>              together:
>>>>
>>>>              https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>>>>
>>>>              ...with this commandline:
>>>>
>>>>                 ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
>>>>              -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
>>>>              -vb 256k maven.mpg
>>>>
>>>>              I don't really understand most of those options (I just
>>>>              cribbed them from Maik's example) or whether any of them
>>>>              would introduce more latency than is reasonable for a
>>>>              real-time conversation, but I will observe:
>>>>
>>>>               1. The encoder claims that it was performing on the order
>>>>                  of 90 - 100 fps on my (admittedly modern) system;
>>>>               2. The resolution is 640x360 (somewhat larger than DCIF);
>>>>               3. The video is not, to my eye, unusable (draw your own
>>>>                  conclusions, as it's clearly not as nice as modern
>>>> codecs);
>>>>               4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
>>>>                  encoding works out to 508 kbits/second total.
>>>>
>>>>
>>>>
>>>>              Source video here, and NASA is acknowledged as the source of
>>>>              the material contained therein:
>>>>              http://www.youtube.com/watch?v=ijAO0FFExx0
>>>>
>>>>              /a
>>>>
>>>>
>>>>
>>>>              _______________________________________________
>>>>              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
>>>>
>>> _______________________________________________
>>> 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
>


From stewe@stewe.org  Sun Nov 17 09:23:54 2013
Return-Path: 
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 0FD6011E8E71 for ; Sun, 17 Nov 2013 09:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1]
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 ifG4B0pC5pbB for ; Sun, 17 Nov 2013 09:23:50 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id D951D11E8E78 for ; Sun, 17 Nov 2013 09:23:45 -0800 (PST)
Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB361.namprd07.prod.outlook.com (10.141.75.19) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sun, 17 Nov 2013 17:23:41 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.99]) with mapi id 15.00.0820.005; Sun, 17 Nov 2013 17:23:40 +0000
From: Stephan Wenger 
To: Maik Merten , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] H261/MPEG-1 video quality
Thread-Index: AQHO4u+TetNMevLdvEG+R6V6YRXbOponpC0AgAHSNID//7EfAA==
Date: Sun, 17 Nov 2013 17:23:39 +0000
Message-ID: 
In-Reply-To: <5288CD41.30508@googlemail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [24.5.171.95]
x-forefront-prvs: 0033AAD26D
x-forefront-antispam-report: SFV:NSPM; SFS:(54094003)(189002)(199002)(164054003)(51704005)(52604005)(479174003)(377454003)(24454002)(85306002)(74502001)(87936001)(74366001)(87266001)(74662001)(65816001)(31966008)(80022001)(2656002)(76482001)(54356001)(59766001)(63696002)(53806001)(15202345003)(74706001)(66066001)(77982001)(4396001)(79102001)(83072001)(81542001)(81342001)(47736001)(49866001)(47976001)(50986001)(46102001)(80976001)(81686001)(56776001)(54316002)(83322001)(19580395003)(19580405001)(74876001)(51856001)(15975445006)(56816003)(36756003)(81816001)(69226001)(47446002)(15395725003)(76176001)(76796001)(76786001)(15198665003)(77096001)(42262001)(18954195003)(473944003)(460985004)(10090945008); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB361; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:24.5.171.95; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en; 
Content-Type: text/plain; charset="windows-1254"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 17:23:54 -0000

Yes, post filters are helpful at low bitrates, and especially for codecs
with fixed block sizes such as H.261.  I believe we had a very simple
fixed coefficient 5 tap post filter on the vertical block edges.  Nothing
more due to cycle constrains.  I know that they did something slightly
more sophisticated later (perhaps only adding the horizontal block edges),
but at that time I had left the company.
Stephan




On 11.17.2013, 06:05 , "Maik Merten"  wrote:

>Dear Stephan,
>
>thanks for sharing your experience regarding high-performance H.261
>implementations and confirming my suspicion regarding ffmpeg's encoder.
>Do you happen to remember if there was any postprocessing involved at
>the receiving end? I find that playback of the low-bitrate encodes
>becomes somewhat more enjoyable with some postprocessing (deblocking,
>deringing) (mplayer -vf pp) and I wonder if one should assume the
>presence of such filters when assessing the quality achievable (given
>that any modern devices have no trouble with the additional computation).
>
>
>Maik
>
>Am 16.11.2013 19:17, schrieb Stephan Wenger:
>> Hi,
>> Back in the mid 1990s, we (at Teles AG, Germany) developed an H.261
>>based
>> desktop video conferencing system.  It ran real-time over 128 kbit/s
>>ISDN,
>> at 12.5 fps, CIF, on a Pentium 133 (and well enough on a Pentium 90,
>>with
>> occasional slight drops in frame rate at high motion), including the
>> cycles needed for G.728 audio.  We got a better quality with those
>> resources than what Maik has uploaded.  So Maik is quite right, the
>>ffmpeg
>> encoder implementation has a lot of room for improvement.
>> One thing that is quite obvious in the 128 kbit/s sequence is the
>>presence
>> of both blocking and mosquito artifacts.  This combination points to an
>> incorrect tuning of the deblocking filter.  In H.261, one can enable and
>> disable the deblocking filter on a per macroblock basis.  If you don=B9t
>>get
>> that right, you have a lousy encoder.  The heuristics were secret sauce
>>of
>> a video conferencing vendor at the time, matched in importance perhaps
>> only by a useful echo cancellation.  The deblocking filter obviously
>> reduces noise at the expense of picture fidelity.  The trick is to keep
>>it
>> on most of the time in areas of high energy, but occasionally (5 picture
>> interval?  Something like this) switch it off to capture detail, and at
>> the same time fine-tune the pre filter to smoothen the input signal
>>just a
>> bit so to avoid creation of excessive mosquito noise, and crank up the
>>QP.
>> No, I don=B9t have the time to develop and contribute a patch for ffmpeg=
.
>> Stephan
>>
>>
>>
>> On 11.16.2013, 09:15 , "Maik Merten"  wrote:
>>
>>> I uploaded a set of H.261 encodes of the sign_irene sample, ranging
>>>from
>>> 128 kbps to 1024 kbps. This is again done with ffmpeg, so please take
>>>my
>>> comments regarding its H.261 encoder into consideration.
>>>
>>>=20
>>>https://drive.google.com/file/d/0B11N4VzriA21WWRoVGd6TWRwb3M/edit?usp=3D=
sh
>>>ar
>>> ing
>>>
>>> (btw, transmission of sign language is a nice example where "audio
>>>only"
>>> is not quite useful in case of video codec negotiation failure)
>>>
>>>
>>> Maik
>>>
>>>
>>> Am 16.11.2013 03:18, schrieb Justin Uberti:
>>>> Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
>>>> pretty decent. Would be great to see a 512 kbps and 1024 kbps version
>>>>to
>>>> understand where things go from bad to good.
>>>>
>>>>
>>>> On Fri, Nov 15, 2013 at 3:42 PM, Herv=E9 W. >>> > wrote:
>>>>
>>>>
>>>>=20
>>>>http:
>>>>//
>>>> ge.tt/2bp1Zrz
>>>>
>>>>      options used:
>>>>      mencoder.exe -ovc lavc -lavcopts vcodec=3Dh261:vbitrate=3D256 -o
>>>>      irene-256k.h261.avi sign_irene_cif.y4m
>>>>
>>>>      mencoder.exe -ovc lavc -lavcopts
>>>>
>>>>=20
>>>>vcodec=3Dh261:vbitrate=3D256:last_pred=3D3:predia=3D2:dia=3D2:precmp=3D=
2:cmp=3D2:subc
>>>>mp
>>>> =3D2:preme=3D2:mbd=3D0
>>>>      -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
>>>>
>>>>      mencoder.exe -ovc lavc -lavcopts
>>>>
>>>>=20
>>>>vcodec=3Dh261:vbitrate=3D15999:last_pred=3D3:predia=3D2:dia=3D2:precmp=
=3D2:cmp=3D2:su
>>>>bc
>>>> mp=3D2:preme=3D2:mbd=3D0
>>>>      -o irene-highbitrate.h261.avi sign_irene_cif.y4m
>>>>
>>>>      You can probably derive ffmpeg/avconv options from those.
>>>>
>>>>      Notes
>>>>
>>>>        * There's a ticket open about h261
>>>>
>>>>=20
>>>>https://trac.ffmpeg.org/ticket/314
>>>>3
>>>>        * 15999 kbps was not the bitrate irene-highbitrate ended up
>>>>using;
>>>>          that was more like 1933 kbps
>>>>        * My untrained eye did not see any difference between
>>>>          irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
>>>>          maybe most of those options are (rightly) ignored for h261.
>>>>
>>>>
>>>>      - Herv=E9
>>>>
>>>>
>>>>=20
>>>>-----------------------------------------------------------------------
>>>>-
>>>>      From: juberti@google.com 
>>>>      Date: Fri, 15 Nov 2013 14:00:50 -0800
>>>>      To: cowwoc@bbs.darktech.org 
>>>>      CC: rtcweb@ietf.org 
>>>>      Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love
>>>>it if
>>>>      patents evaporated)
>>>>
>>>>
>>>>       From what I understand, the clip from this thread was encoded
>>>>using
>>>>      MPEG-1, not H.261. Aside from
>>>>      http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we
>>>>have
>>>>      seen any samples of actual H.261 output that give a good
>>>>indication
>>>>      of its suitability.
>>>>
>>>>
>>>>      On Fri, Nov 15, 2013 at 5:52 AM, cowwoc >>>      > wrote:
>>>>
>>>>
>>>>          Excellent work Adam. I can't speak for others, but at 254
>>>>kbps
>>>>          (corrected figure from your follow-up post) H.261 is
>>>>definitely
>>>>          "good enough" and better than an audio-only connection.
>>>>
>>>>          Gili
>>>>
>>>>
>>>>          On 14/11/2013 6:16 PM, Adam Roach wrote:
>>>>
>>>>              I sent a reply to this earlier, but just now realized
>>>>that
>>>>              it went only to Justin, not to the list.
>>>>
>>>>
>>>>              On 11/14/13 13:59, Justin Uberti wrote:
>>>>
>>>>                  Thanks, this is interesting. Is the ffmpeg 261
>>>>encoder
>>>>                  limited to CIF/QCIF, or can you specify arbitrary
>>>>sizes?
>>>>
>>>>
>>>>              It looks like the ffmpeg mpeg-1 coder works for arbitrary
>>>>              sizes. I'm not sure what the difference between mpeg-1
>>>>and
>>>>              H.261 are, though, so we could be talking apples and
>>>>oranges
>>>>              (or at least apples and pears) here. I'll note that
>>>>mpeg-1
>>>>              came out in 1991, which is a good 22 years in the past.
>>>>I'm
>>>>              not drawing IPR conclusions for you, but invite you to
>>>>              ponder the implications yourself.
>>>>
>>>>              Following Maik's lead with the mpeg-1 js decoder, I put
>>>>this
>>>>              together:
>>>>
>>>>             =20
>>>>https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>>>>
>>>>              ...with this commandline:
>>>>
>>>>                 ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
>>>>              -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
>>>>              -vb 256k maven.mpg
>>>>
>>>>              I don't really understand most of those options (I just
>>>>              cribbed them from Maik's example) or whether any of them
>>>>              would introduce more latency than is reasonable for a
>>>>              real-time conversation, but I will observe:
>>>>
>>>>               1. The encoder claims that it was performing on the
>>>>order
>>>>                  of 90 - 100 fps on my (admittedly modern) system;
>>>>               2. The resolution is 640x360 (somewhat larger than
>>>>DCIF);
>>>>               3. The video is not, to my eye, unusable (draw your own
>>>>                  conclusions, as it's clearly not as nice as modern
>>>> codecs);
>>>>               4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
>>>>                  encoding works out to 508 kbits/second total.
>>>>
>>>>
>>>>
>>>>              Source video here, and NASA is acknowledged as the
>>>>source of
>>>>              the material contained therein:
>>>>              http://www.youtube.com/watch?v=3DijAO0FFExx0
>>>>
>>>>              /a
>>>>
>>>>
>>>>
>>>>              _______________________________________________
>>>>              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
>>>>
>>>
>>> _______________________________________________
>>> 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


From eckert@cisco.com  Sun Nov 17 09:31:02 2013
Return-Path: 
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 99A1B11E8EAF for ; Sun, 17 Nov 2013 09:31:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 rWZGrh299QBQ for ; Sun, 17 Nov 2013 09:30:53 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3615E11E8EAD for ; Sun, 17 Nov 2013 09:30:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1800; q=dns/txt; s=iport; t=1384709453; x=1385919053; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=sHltrbgzw67gaiFd3/icBHXfyUvG0m9UNwxbY6P8ir8=; b=NYLSRzK0KUOkNHJkcj1ntOKPF7CWcmpJhf5TQdltUxvulylwr8QFSnPE SUpeQCcdmIKTvY2pumAhfemX3XS13IizZDHb3RpsLoKt+2US9xPwnbeNi +M03AXNMFW+ByYUjxM9ig3yV4gfmlbT2hgEiyRiqRqeSYz4oTLMLba0z8 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAFAKn8iFKrRDoG/2dsb2JhbABZgwc4vzNLgRAWdIIlAQEBBAEBATcvAQQLEAsSBgklDwUTIhQTiAAOwGoXj2kHgyCBEQOJQo5NAZINg0k
X-IronPort-AV: E=Sophos;i="4.93,719,1378857600"; d="scan'208";a="94650444"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 17 Nov 2013 17:30:52 +0000
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAHHUoIg017164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Nov 2013 17:30:51 GMT
Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id rAHHUmWT028737; Sun, 17 Nov 2013 09:30:50 -0800 (PST)
Received: (from eckert@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id rAHHUmV1028736; Sun, 17 Nov 2013 09:30:48 -0800 (PST)
Date: Sun, 17 Nov 2013 09:30:48 -0800
From: Toerless Eckert 
To: Adam Roach 
Message-ID: <20131117173048.GA11012@cisco.com>
References:    <5285CCCE.6040906@ericsson.com> <528625E0.1030203@bbs.darktech.org> <52862E10.8000506@alvestrand.no> <52863F9D.9090103@bbs.darktech.org> <52869EEA.8000408@nostrum.com> <5287ED8A.9060305@jesup.org> <52880C60.9040209@nostrum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52880C60.9040209@nostrum.com>
User-Agent: Mutt/1.4i
Cc: Randell Jesup , rtcweb@ietf.org
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 17:31:03 -0000

H.264 is also mandated in DVB, the european standard, and i'd be surprised
if there was any region on this planet where H264 is not part of any digital
TVs MTI. 

Some transmission systems like terrestrial in europe DVB-T started after
H.264 was feasible, so they have no MPEG2. All the systems with legacy MPEG2
content/receiver-equipment have some strategy to move to H264. On
the largest satellite provider in europe for example, HD is only H264
because there was no or very little HD capable MPEG2 in before. If
a provider had a lot of HD even before H264, transition is most difficult.
Thats for example the case fo MSOs in the US. 

I think the experience of evolving codecs in RTCweg will be a lot more
painfull than in TV-land if we don't pick a good MTI though because
of the different dynamics.

On Sat, Nov 16, 2013 at 06:22:56PM -0600, Adam Roach wrote:
> On 11/16/13 16:11, Randell Jesup wrote:
> >Broadcast HDTV is MPEG2, starting circa 1999/2000,and still is so far 
> >as I know.  I think you mean that Cable/Satellite HDTV started using 
> >H.264 in circa 2003. 
> 
> I'm don't know about the rest of the world, but at least North America 
> includes H.264 as one of the supported codecs now:
> 
> http://en.wikipedia.org/wiki/Advanced_Television_Systems_Committee_standards#H.264.2FMPEG-4_AVC
> 
> Of course, given that this happened after significant hardware was out 
> in the field, it's questionable whether there's been much actual *use* 
> of H.264 in ATSC.
> 
> /a
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
---
Toerless Eckert, eckert@cisco.com
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!


From eckert@cisco.com  Sun Nov 17 09:58:25 2013
Return-Path: 
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 16B0711E83E9 for ; Sun, 17 Nov 2013 09:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8]
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 7fsxpopoTkcX for ; Sun, 17 Nov 2013 09:58:20 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 08F1211E8EDB for ; Sun, 17 Nov 2013 09:56:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7597; q=dns/txt; s=iport; t=1384711011; x=1385920611; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=1x+rrOWQHHOwCXQNPXz5II03WdEthrviRUmvC7rpWAE=; b=eDctRQWHmjot8eqPRdMYt+u5VdkYUJ6HWu/K/LayG5wYXhvPjRwIB9co WyDKiIjrERWAvfT4fc3SBceXig8r5/6UZe07h6Yn48y/TcCcOdqwOEQ8c YCqs4uD83hxh2fQ3k4W9G9xYKy9XFaC+DH4G7GWPfQBhZCmseXg8XZ8/I g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjYFAIcCiVKrRDoJ/2dsb2JhbABZgwc4TaxakgxLgRAWdIIlAQEBAwEBAQEvATsLBQsLEQECAQIBCR4HDwUTHwMGDgoJh28DCQUJBbQRjGgXjHOBKQsTgS8HgyCBEQOJQoE0iTiBeIFpAYQRiEQDhTWDSYFH
X-IronPort-AV: E=Sophos;i="4.93,719,1378857600"; d="scan'208";a="94651737"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 17 Nov 2013 17:56:51 +0000
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAHHuoG0010392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Nov 2013 17:56:50 GMT
Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id rAHHum7j013632; Sun, 17 Nov 2013 09:56:49 -0800 (PST)
Received: (from eckert@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id rAHHum1u013628; Sun, 17 Nov 2013 09:56:48 -0800 (PST)
Date: Sun, 17 Nov 2013 09:56:48 -0800
From: Toerless Eckert 
To: Maik Merten 
Message-ID: <20131117175648.GB11012@cisco.com>
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>   <528559E4.3020903@nostrum.com> <5286272B.5000005@bbs.darktech.org>    <52877178.6040002@googlemail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <52877178.6040002@googlemail.com>
User-Agent: Mutt/1.4i
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 17:58:25 -0000

On Sat, Nov 16, 2013 at 02:22:00PM +0100, Maik Merten wrote:
> A major reason IMO why H.261 performs so badly (apart from the old 
> format design) is that nobody seems to have cared to transfer new 
> technology for determining smart encoding choices to that old format (it 
> just makes little commercial sense to strap rockets onto a pig if a 
> newer format such as H.263 or H.264 is available). It appears that 
> encoders for H.261 are mostly "1990ies" regarding encoding technology. 
> From today's point of view such encoders are blazingly fast, but better 
> quality could be achieved with encoders that spend some computation on 
> making smarter encoding choices.

Right. I think the logics of the market space would make a choice
of h261 as MTI just a big desaster and fruitless exercise
in retro-engineering.

- You start with legacy software, then it breaks under a lot
  more/different use than what it was written for in the 90th and you
  have to invest cycles fixing it.
- You wonder whether you should still optimize it, but ohh, wait,
  lets check IPR on any possible optimization, oh wait, if i need
  to start checking IPR, why the heck did i use this legacy codec.
- You try to figure how to make chips work whose native h261
  support if at all still existing still works. YOu wonder if/how
  the next generation of chips could do better on h261.

Toerless

> Maik
> 
> 
> Am 16.11.2013 03:18, schrieb Justin Uberti:
> >Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
> >pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
> >understand where things go from bad to good.
> >
> >
> >On Fri, Nov 15, 2013 at 3:42 PM, Hervé W.  >> wrote:
> >
> >    http://ge.tt/2bp1Zrz
> >
> >    options used:
> >    mencoder.exe -ovc lavc -lavcopts vcodec=h261:vbitrate=256 -o
> >    irene-256k.h261.avi sign_irene_cif.y4m
> >
> >    mencoder.exe -ovc lavc -lavcopts
> >    vcodec=h261:vbitrate=256:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
> >    -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
> >
> >    mencoder.exe -ovc lavc -lavcopts
> >    vcodec=h261:vbitrate=15999:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
> >    -o irene-highbitrate.h261.avi sign_irene_cif.y4m
> >
> >    You can probably derive ffmpeg/avconv options from those.
> >
> >    Notes
> >
> >      * There's a ticket open about h261
> >        https://trac.ffmpeg.org/ticket/3143
> >      * 15999 kbps was not the bitrate irene-highbitrate ended up using;
> >        that was more like 1933 kbps
> >      * My untrained eye did not see any difference between
> >        irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
> >        maybe most of those options are (rightly) ignored for h261.
> >
> >
> >    - Hervé
> >
> >    ------------------------------------------------------------------------
> >    From: juberti@google.com 
> >    Date: Fri, 15 Nov 2013 14:00:50 -0800
> >    To: cowwoc@bbs.darktech.org 
> >    CC: rtcweb@ietf.org 
> >    Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
> >    patents evaporated)
> >
> >
> >     From what I understand, the clip from this thread was encoded using
> >    MPEG-1, not H.261. Aside from
> >    http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have
> >    seen any samples of actual H.261 output that give a good indication
> >    of its suitability.
> >
> >
> >    On Fri, Nov 15, 2013 at 5:52 AM, cowwoc  >    > wrote:
> >
> >
> >        Excellent work Adam. I can't speak for others, but at 254 kbps
> >        (corrected figure from your follow-up post) H.261 is definitely
> >        "good enough" and better than an audio-only connection.
> >
> >        Gili
> >
> >
> >        On 14/11/2013 6:16 PM, Adam Roach wrote:
> >
> >            I sent a reply to this earlier, but just now realized that
> >            it went only to Justin, not to the list.
> >
> >
> >            On 11/14/13 13:59, Justin Uberti wrote:
> >
> >                Thanks, this is interesting. Is the ffmpeg 261 encoder
> >                limited to CIF/QCIF, or can you specify arbitrary sizes?
> >
> >
> >            It looks like the ffmpeg mpeg-1 coder works for arbitrary
> >            sizes. I'm not sure what the difference between mpeg-1 and
> >            H.261 are, though, so we could be talking apples and oranges
> >            (or at least apples and pears) here. I'll note that mpeg-1
> >            came out in 1991, which is a good 22 years in the past. I'm
> >            not drawing IPR conclusions for you, but invite you to
> >            ponder the implications yourself.
> >
> >            Following Maik's lead with the mpeg-1 js decoder, I put this
> >            together:
> >
> >            https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
> >
> >            ...with this commandline:
> >
> >               ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
> >            -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
> >            -vb 256k maven.mpg
> >
> >            I don't really understand most of those options (I just
> >            cribbed them from Maik's example) or whether any of them
> >            would introduce more latency than is reasonable for a
> >            real-time conversation, but I will observe:
> >
> >             1. The encoder claims that it was performing on the order
> >                of 90 - 100 fps on my (admittedly modern) system;
> >             2. The resolution is 640x360 (somewhat larger than DCIF);
> >             3. The video is not, to my eye, unusable (draw your own
> >                conclusions, as it's clearly not as nice as modern codecs);
> >             4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
> >                encoding works out to 508 kbits/second total.
> >
> >
> >
> >            Source video here, and NASA is acknowledged as the source of
> >            the material contained therein:
> >            http://www.youtube.com/watch?v=ijAO0FFExx0
> >
> >            /a
> >
> >
> >
> >            _______________________________________________
> >            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
> >
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
---
Toerless Eckert, eckert@cisco.com
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!


From partha@parthasarathi.co.in  Sun Nov 17 09:58:33 2013
Return-Path: 
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 D7B2911E8F3C for ; Sun, 17 Nov 2013 09:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.636
X-Spam-Level: 
X-Spam-Status: No, score=0.636 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3]
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 CrxRLWi7JXET for ; Sun, 17 Nov 2013 09:58:30 -0800 (PST)
Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.230]) by ietfa.amsl.com (Postfix) with ESMTP id D518811E8150 for ; Sun, 17 Nov 2013 09:57:42 -0800 (PST)
Received: from userPC (unknown [122.166.137.104]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 4A36019085E5; Sun, 17 Nov 2013 17:57:35 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1384711060; bh=pOWn6328/W/ul1jsADza4Kt9RumaDd2TXx24BJ8n+r8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=EhKpDa0kRPH1yAWm201d7F9l1v12S4DWrkFxWx7wHmFDD6n34/z/z8x6k4Q7qPTVT ADOHpe7WlbgEltmwADELuKY2jfsuyY4KlFZP4Sp1uLwfCw1l9UKgYBi8q8oeapVgls heipCFh+ZHQYBsBPscm217gP0xO3EQBrfvM+GkMs=
From: "Parthasarathi R" 
To: "'Erik Lagerway'" , =?iso-8859-1?Q?'G=F6ran_Eriksson_AP'?= 
References: 	<0FA5D66F-2680-4C58-A16E-DCE5531837E3@ericsson.com> 
In-Reply-To: 
Date: Sun, 17 Nov 2013 23:27:32 +0530
Message-ID: <001901cee3be$80a45db0$81ed1910$@co.in>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01CEE3EC.9A5C99B0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7g05mZPFatxlqeQHyvkJquQHgPuQC6qpuA
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020201.52890394.003F, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.100
X-CTCH-Rules: SUBJECT_NEEDS_ENCODING,
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 17:58:34 -0000

This is a multipart message in MIME format.

------=_NextPart_000_001A_01CEE3EC.9A5C99B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1

=20

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf =
Of
Erik Lagerway
Sent: Thursday, November 14, 2013 6:21 AM
To: G=F6ran Eriksson AP
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, =
RFC
3929)

=20

+1 =20




  Erik Lagerway |
 Hookflash | 1 (855) Hookflash ext. 2 |
 Twitter |   WebRTC.is =
Blog


=20

On Wed, Nov 13, 2013 at 4:42 PM, G=F6ran Eriksson AP
 wrote:

+1


14 nov 2013 kl. 00:06 skrev "Bernard Aboba" :

Keith Drage said:=20
=20
"Agree

=20

I am at the point where I would prefer to spend the meeting cycles =
getting
things we can agree on, rather than where we seem to be at the moment =
with
an issue where there are two clear camps and no real sign of a =
compromise.

=20

Ultimately the market will decide (and some parts of it probably have
already decided - which is probably the reason for no progress).

=20

Keith"

=20

[BA] Well said. With most of the RTCWEB WG drafts either having =
completed
WGLC or being candidates for WGLC by the end of the year,  with some =
elbow
grease it seems very possible to move the bulk of the documents to IETF =
last
call within a few months at most.   Polishing the RTCWEB document set =
would
yield multiple benefits.  Not only would it get us closer to the goal of
standardizing the WebRTC protocol stack, but also might well turn up an
issue or two we haven't thought enough about. Also, once we move the
protocol stack further along, we'll have more cycles to spend on =
operational
issues (like monitoring concerns discussed in XRBLOCK), which currently
limit the ability to deploy WebRTC at very large scale.   Unfortunately,
we've been spending so much time on the MTI video codec debate that less
glamorous (but ultimately much more important) engineering work is being
neglected.=20

=20

This is all by way of seconding your point that there is a real =
opportunity
cost to the never-ending, energy sapping MTI codec discussion.  =
Personally,
I'd much rather redirect the work of the Internet Engineering Task Force
RTCWEB WG away from amateur lawyering toward engineering where we =
actually
have expertise and could potentially make a difference.

_______________________________________________
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

=20


------=_NextPart_000_001A_01CEE3EC.9A5C99B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable













    


    +1
    


     
    


    


    


    


    From:=

rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of =
Erik
Lagerway
    
Sent: Thursday, November 14, 2013 6:21 AM
    
To: G=F6ran Eriksson AP
    
Cc: rtcweb@ietf.org
    
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, =
charter,
RFC 3929)
    


    


    


     
    


    


    +1  
    


    


    



    

    


    


    


    Erik Lagerway | Hookflash |
1 (855) Hookflash ext. 2 | Twitter | WebRTC.is
Blog 
    


    


    


     
    


    


    On Wed, Nov 13, 2013 at 4:42 PM, G=F6ran Eriksson =
AP <goran.ap.eriksson@ericsson.com>
wrote:
    


    


    


    +1
    


    


    



    
14 nov 2013 kl. 00:06 skrev "Bernard Aboba" <bernard_aboba@hotmail.com>:
    


    


    


    


    


    


    


    Keith Drage said: 
    
 
    
"Agree
    


     
    


    I
am at the point where I would prefer to spend the meeting cycles getting =
things
we can agree on, rather than where we seem to be at the moment with an =
issue
where there are two clear camps and no real sign of a =
compromise.
    


     
    


    Ultimately
the market will decide (and some parts of it probably have already =
decided -
which is probably the reason for no progress).
    


     
    


    Keith"<=
o:p>
    


     
    


    [BA] Well said. With most of the RTCWEB WG =
drafts
either having completed WGLC or being candidates for WGLC by the end of =
the
year,  with some elbow grease it seems very possible to move the =
bulk of
the documents to IETF last call within a few months at most.  
Polishing the RTCWEB document set would yield multiple benefits.  =
Not only
would it get us closer to the goal of standardizing the WebRTC =
protocol
stack, but also might well turn up an issue or two we haven't thought =
enough
about. Also, once we move the protocol stack further along, we'll have =
more
cycles to spend on operational issues (like monitoring concerns =
discussed in
XRBLOCK), which currently limit the ability to deploy WebRTC at very =
large
scale.   Unfortunately, we've been spending so much time =
on the
MTI video codec debate that less glamorous (but ultimately much more =
important)
engineering work is being neglected. 
    


     
    


    This is all by way of seconding your point that =
there is a
real opportunity cost to the never-ending, energy sapping MTI codec
discussion.  Personally, I'd much rather redirect the work of the =
Internet
Engineering Task Force RTCWEB WG away from amateur lawyering toward =
engineering
where we actually have expertise and could potentially make a =
difference.
    


    


    


    


    


    


    


    


    _______________________________________________
    
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
    


    


     
    


    


    


    





------=_NextPart_000_001A_01CEE3EC.9A5C99B0--


From maikmerten@googlemail.com  Sun Nov 17 11:43:05 2013
Return-Path: 
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 0C0D711E91CD for ; Sun, 17 Nov 2013 11:43:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level: 
X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292]
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 0r8-UhnL6yce for ; Sun, 17 Nov 2013 11:43:04 -0800 (PST)
Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E080B11E91B9 for ; Sun, 17 Nov 2013 11:40:33 -0800 (PST)
Received: by mail-bk0-f45.google.com with SMTP id mx13so90675bkb.18 for ; Sun, 17 Nov 2013 11:40:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1vzXyXK4LqsJpzsYkg12pXVSly966mpna/tprsrOyeY=; b=b9gvp6zsmuPPsB5/JfU2ZhI3CBV1Tx1W1X0Hg5DCOEiKvFsonp+K3RAA4b2sZg2IyU TDW8I/pm7kn9mK3TIjidS62V4lVo9gOm5vEkehaV2fgorerg7MpMpUELPywoMFbijPuF JcXAc3uYjcTWUEfIvaMc0cF7jqCMotbs5Rn5I6/Uwm5Qt2sH0fedvju1SlVUhAwrl4Tl MU+gH2swWiKBmVPeDDD3M+sHQqh4MWFK+AXX9ubQ58ySCNo2YxJ9UavTOjWMg4T1sRfv nAKkVrI8iL7dksCVrGgMYXkEr5Eaz0hpOxWoAjUL2s+FwpZ/eHjJfy//5LI1sxT5rvO8 I4FA==
X-Received: by 10.205.22.71 with SMTP id qv7mr9705236bkb.20.1384717232980; Sun, 17 Nov 2013 11:40:32 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id qe6sm14133354bkb.5.2013.11.17.11.40.31 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 11:40:31 -0800 (PST)
Message-ID: <52891BAD.50408@googlemail.com>
Date: Sun, 17 Nov 2013 20:40:29 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
CC: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com>   <528559E4.3020903@nostrum.com> <5286272B.5000005@bbs.darktech.org>    <52877178.6040002@googlemail.com> <20131117175648.GB11012@cisco.com>
In-Reply-To: <20131117175648.GB11012@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 19:43:05 -0000

Am 17.11.2013 18:56, schrieb Toerless Eckert:
> Right. I think the logics of the market space would make a choice
> of h261 as MTI just a big desaster and fruitless exercise
> in retro-engineering.
>
> - You start with legacy software, then it breaks under a lot
>    more/different use than what it was written for in the 90th and you
>    have to invest cycles fixing it.

Looking around I still see H.261 implementations that are available and 
maintained. Their coding technology may still be "meh", and unless you 
want to resurrect a specific implementation designed for Windows 3.11 
video phones I doubt it's an insurmountable challenge to get something 
up and running. Granted, supporting (n+1) codecs is always more work 
than supporting (n) codecs, and you'd always want to support either 
H.264 or VP8.


> - You wonder whether you should still optimize it, but ohh, wait,
>    lets check IPR on any possible optimization, oh wait, if i need
>    to start checking IPR, why the heck did i use this legacy codec.

Well, the one thing that makes H.261 somewhat interesting is that most 
people seem to agree that one *can* implement it without running into 
IPR - you don't *have* to strap rockets onto that pig. During the whole 
IPR discussion I think everybody focused on what IPR may or may not 
apply to the respective formats as defined by their normative *de*coder 
specifications - I guess because it's up to the implementor to decide 
upon advanced technologies employed by the *en*coder.

> - You try to figure how to make chips work whose native h261
>    support if at all still existing still works. YOu wonder if/how
>    the next generation of chips could do better on h261.

Would hardware support for H.261, if still existing, be actually 
relevant in a world where Skype is doing software encoding of H.264 on 
mobile devices?


Best regards,

Maik

From maikmerten@googlemail.com  Sun Nov 17 11:54:40 2013
Return-Path: 
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 7CCA711E91AF for ; Sun, 17 Nov 2013 11:54:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.953
X-Spam-Level: 
X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.646,  BAYES_00=-2.599]
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 khL5SJ1zV72L for ; Sun, 17 Nov 2013 11:54:39 -0800 (PST)
Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5750311E84FA for ; Sun, 17 Nov 2013 11:54:07 -0800 (PST)
Received: by mail-bk0-f48.google.com with SMTP id v10so1752283bkz.21 for ; Sun, 17 Nov 2013 11:54:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XqiY0LZaVKbBxXREqC/Xd8dtL88+nqp2RiThOUtlopU=; b=nxoXquxU5PNnQ2vaG5BiY/f5o8xoIkaDoBXPP1ofPX1U8hS/dJWJvPM74Ehfb8dkMZ +Akd6W6nLBAUIeaeLDQviRMBfpaYAcFODEV5cp8dsD/qtPaIgeUk+c08fpfHIgTYwCjc N8avRNkkThZcupYcvDYe0dRGW/qK+9VrMYrk6YAKdmPZKH2eamWxoUAX+945soeM695l xSH0UNAvEr+NpxhvzAAr8MCydH53JrWkxBvg2i8z7RxFKEDkreX7Ns3cdnNM/vofIjTp AP9vIf6vcxyxmGhkuyqYDs1QXNgkyfWWAVLMdUa4yHo+NYM2trSp5LGS6cw153fDWxKI QmaQ==
X-Received: by 10.204.173.6 with SMTP id n6mr9528207bkz.5.1384718046429; Sun, 17 Nov 2013 11:54:06 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id on10sm14212222bkb.13.2013.11.17.11.54.04 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 11:54:05 -0800 (PST)
Message-ID: <52891EDB.2050607@googlemail.com>
Date: Sun, 17 Nov 2013 20:54:03 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 19:54:40 -0000

Hello,

just wondering if something like

"9. All entities SHOULD support both H.264 and VP8. All entities MUST at 
least implement one of those. Entities that do not support both H.264 
and VP8 MUST implement H.261."

has already popped up. My reasoning is that implementations supporting 
both high performance codecs will always negotiate to use on of those - 
H.261 should never be relevant there.

It appears that all implementors are willing to implement either H.264 
or VP8 (but not necessarily both). This obviously means that negotiation 
failure regarding a high-performance codec is a possiblity. In this case 
H.261 is actually useful so that basic video calls can still be 
established (for instance, I guess deaf people may always appreciate a 
video connection, as long as sign language can be transmitted).


Maik


Am 14.11.2013 12:37, schrieb Jeremy Fuller:
> Hi,
> Gaining IETF consensus on making it mandatory to support only H.264 or
> only VP8 has clearly failed. I would welcome anyone to share their
> thoughts on why they believe this situation will change anytime in the
> next few years.  Therefore, can I suggest that we remove items 1 and 2
> from the list. Hopefully this will speed up the process by focusing
> efforts towards gaining agreement on one of the remaining options.
> The following alternatives has been proposed:
>
>  1. All entities MUST support H.264
>  2. All entities MUST support VP8
>  3. All entities MUST support both H.264 and VP8
>  4. Browsers MUST support both H.264 and VP8, other entities MUST
>     support at least one of H.264 and VP8
>  5. All entities MUST support at least one of H.264 and VP8
>  6. All entities MUST support H.261
>  7. There is no MTI video codec
>  8. All entities MUST support H.261 and all entities MUST support at
>     least one of H.264 and VP8
>
> Regards,
> Jeremy Fuller
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From treising75@gmail.com  Sun Nov 17 12:13:45 2013
Return-Path: 
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 5040211E81B2 for ; Sun, 17 Nov 2013 12:13:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 uhOOo+9a8yiG for ; Sun, 17 Nov 2013 12:13:44 -0800 (PST)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DACD311E80F7 for ; Sun, 17 Nov 2013 12:13:14 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id n12so5290279wgh.34 for ; Sun, 17 Nov 2013 12:13:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=5jr7SfeRO9WecyhA+qt4kslVtHFbJwLpPrXs+m46rTk=; b=Y3duoNTncBTliXCGcVqwpTzyJdi4QdVjBFHM4C1XSb40SZFGPgqMAJyu3PNzDPLrwT TfNzu+1iJliDiLM51lXUHo+S+stCezGc+Y0Yt1mtAKWs5URzSlh6avaaUT52Co5CL6HT oSvoSGKXF+RK0BKHMHhJMeGnzdqhHpKuc2n4AIXwPYtzXpkDCxZap4yGiQteqELpqQqR aDyaXB1dr+2tlSCqGC6A6RDsmJRuBSdwPcvcDLz+h9Fxdkutobmm2kijseulDYLs4pGx iMGAMngNnX2NbEw3SoZub5Ix31sA2dgHqyV12oI9opC1skp4b1SJUIeceJCwO33Cay4i CoCg==
X-Received: by 10.194.206.5 with SMTP id lk5mr20335wjc.46.1384719194088; Sun, 17 Nov 2013 12:13:14 -0800 (PST)
Received: from [192.168.1.201] (77.119.226.28.static.drei.at. [77.119.226.28]) by mx.google.com with ESMTPSA id nb16sm17215603wic.0.2013.11.17.12.13.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 12:13:13 -0800 (PST)
References:  <52891EDB.2050607@googlemail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <52891EDB.2050607@googlemail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A06EACB-69E2-4CE0-BDF2-1FDFD71159D3@gmail.com>
X-Mailer: iPad Mail (11B554a)
From: Thomas Reisinger 
Date: Sun, 17 Nov 2013 21:13:07 +0100
To: Maik Merten 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 20:13:45 -0000

Hi,

Instead of h.261, I would recommend h.263 as a common base.

Cheers,

Thomas=20
Sent from mobile device

> On 17 Nov 2013, at 20:54, Maik Merten  wrote:
>=20
> Hello,
>=20
> just wondering if something like
>=20
> "9. All entities SHOULD support both H.264 and VP8. All entities MUST at l=
east implement one of those. Entities that do not support both H.264 and VP8=
 MUST implement H.261."
>=20
> has already popped up. My reasoning is that implementations supporting bot=
h high performance codecs will always negotiate to use on of those - H.261 s=
hould never be relevant there.
>=20
> It appears that all implementors are willing to implement either H.264 or V=
P8 (but not necessarily both). This obviously means that negotiation failure=
 regarding a high-performance codec is a possiblity. In this case H.261 is a=
ctually useful so that basic video calls can still be established (for insta=
nce, I guess deaf people may always appreciate a video connection, as long a=
s sign language can be transmitted).
>=20
>=20
> Maik
>=20
>=20
> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>> Hi,
>> Gaining IETF consensus on making it mandatory to support only H.264 or
>> only VP8 has clearly failed. I would welcome anyone to share their
>> thoughts on why they believe this situation will change anytime in the
>> next few years.  Therefore, can I suggest that we remove items 1 and 2
>> from the list. Hopefully this will speed up the process by focusing
>> efforts towards gaining agreement on one of the remaining options.
>> The following alternatives has been proposed:
>>=20
>> 1. All entities MUST support H.264
>> 2. All entities MUST support VP8
>> 3. All entities MUST support both H.264 and VP8
>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>>    support at least one of H.264 and VP8
>> 5. All entities MUST support at least one of H.264 and VP8
>> 6. All entities MUST support H.261
>> 7. There is no MTI video codec
>> 8. All entities MUST support H.261 and all entities MUST support at
>>    least one of H.264 and VP8
>>=20
>> Regards,
>> Jeremy Fuller
>>=20
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>=20
>=20

From basilgohar@librevideo.org  Sun Nov 17 12:58:27 2013
Return-Path: 
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 9B07C11E81A3 for ; Sun, 17 Nov 2013 12:58:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9-y4A3dQWc1k for ; Sun, 17 Nov 2013 12:58:23 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id D8A1011E8DE9 for ; Sun, 17 Nov 2013 12:58:22 -0800 (PST)
Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 644FF65A543 for ; Sun, 17 Nov 2013 15:58:21 -0500 (EST)
Message-ID: <52892DD8.9050105@librevideo.org>
Date: Sun, 17 Nov 2013 15:58:00 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 	<52891EDB.2050607@googlemail.com> <6A06EACB-69E2-4CE0-BDF2-1FDFD71159D3@gmail.com>
In-Reply-To: <6A06EACB-69E2-4CE0-BDF2-1FDFD71159D3@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 20:58:27 -0000

Thomas,

The reason H.261 is even being considered is because it is an old-enough
specification that any patents on it should have now expired.  Patents,
and their liability on existing video formats, are amongst the biggest
factors affecting which formats can be adopted into the rtcweb standard.

H.263 most likely (I haven't checked) still has patents associated with
it that are active and, therefore, present an issue unless the
respective owners of said patents have publicly declared them royalty-free.

On 11/17/2013 03:13 PM, Thomas Reisinger wrote:
> Hi,
> 
> Instead of h.261, I would recommend h.263 as a common base.
> 
> Cheers,
> 
> Thomas 
> Sent from mobile device
> 
>> On 17 Nov 2013, at 20:54, Maik Merten  wrote:
>>
>> Hello,
>>
>> just wondering if something like
>>
>> "9. All entities SHOULD support both H.264 and VP8. All entities MUST at least implement one of those. Entities that do not support both H.264 and VP8 MUST implement H.261."
>>
>> has already popped up. My reasoning is that implementations supporting both high performance codecs will always negotiate to use on of those - H.261 should never be relevant there.
>>
>> It appears that all implementors are willing to implement either H.264 or VP8 (but not necessarily both). This obviously means that negotiation failure regarding a high-performance codec is a possiblity. In this case H.261 is actually useful so that basic video calls can still be established (for instance, I guess deaf people may always appreciate a video connection, as long as sign language can be transmitted).
>>
>>
>> Maik
>>
>>
>> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>>> Hi,
>>> Gaining IETF consensus on making it mandatory to support only H.264 or
>>> only VP8 has clearly failed. I would welcome anyone to share their
>>> thoughts on why they believe this situation will change anytime in the
>>> next few years.  Therefore, can I suggest that we remove items 1 and 2
>>> from the list. Hopefully this will speed up the process by focusing
>>> efforts towards gaining agreement on one of the remaining options.
>>> The following alternatives has been proposed:
>>>
>>> 1. All entities MUST support H.264
>>> 2. All entities MUST support VP8
>>> 3. All entities MUST support both H.264 and VP8
>>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>>>    support at least one of H.264 and VP8
>>> 5. All entities MUST support at least one of H.264 and VP8
>>> 6. All entities MUST support H.261
>>> 7. There is no MTI video codec
>>> 8. All entities MUST support H.261 and all entities MUST support at
>>>    least one of H.264 and VP8
>>>
>>> Regards,
>>> Jeremy Fuller
>>>
>>>
>>> _______________________________________________
>>> 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
> 


-- 
Libre Video
http://librevideo.org

From vsingh.ietf@gmail.com  Sun Nov 17 13:44:02 2013
Return-Path: 
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 D35E411E8E42 for ; Sun, 17 Nov 2013 13:44:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YIXoy4LE762P for ; Sun, 17 Nov 2013 13:44:02 -0800 (PST)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id A0ABD11E919D for ; Sun, 17 Nov 2013 13:43:48 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id e14so878082iej.14 for ; Sun, 17 Nov 2013 13:43:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=/GxMOFwjggADhglwpCzxbLD0dsm7cxIHqlN6P6jnlNY=; b=ROdCOfoTXjmIeiGJeBjGSeGhelzaFUb17RmuqcW3EjtU4Pk7qRW1imu5f8C0DxaKqH UW48YRvxFm9qX8ZyE5/JWtGmqF9UZYFbReR9QEwIdMeskat/qrNlviocCDPYgZztj57/ SnhI0BWkMpUl4PaYkDju2JDn0i89fau9iM21iDysCw631Eou17rdeKsrFGFs/828NMeY Ito/T9xKt2ExJXcP+mpPZ6Mh5Jnan+SESnbxuBAd+kyUrxmoSM40uk/klwrL58oHfK8/ WpUWExY7Q8oZUh4Wh2c1qAvCwFEPEMdhNNLfa97AEWitWve+w6SVmwICoXL/e1o66kSu y0vQ==
X-Received: by 10.50.39.51 with SMTP id m19mr11069373igk.51.1384724628184; Sun, 17 Nov 2013 13:43:48 -0800 (PST)
References: 
From: Varun Singh 
In-Reply-To: 
Mime-Version: 1.0 (1.0)
Date: Sun, 17 Nov 2013 23:43:45 +0200
Message-ID: <5645151759529247262@unknownmsgid>
To: Bernard Aboba 
Content-Type: multipart/alternative; boundary=047d7bdc131293239604eb665349
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Sun, 17 Nov 2013 21:44:02 -0000

--047d7bdc131293239604eb665349
Content-Type: text/plain; charset=ISO-8859-1

+1, to focus on engineering and operational issues.

On Nov 14, 2013, at 1:06, Bernard Aboba  wrote:

 Keith Drage said:

"Agree

I am at the point where I would prefer to spend the meeting cycles getting
things we can agree on, rather than where we seem to be at the moment with
an issue where there are two clear camps and no real sign of a compromise.

Ultimately the market will decide (and some parts of it probably have
already decided - which is probably the reason for no progress).

Keith"

[BA] Well said. With most of the RTCWEB WG drafts either having completed
WGLC or being candidates for WGLC by the end of the year,  with some elbow
grease it seems very possible to move the bulk of the documents to IETF
last call within a few months at most.   Polishing the RTCWEB document set
would yield multiple benefits.  Not only would it get us closer to the goal
of standardizing the WebRTC protocol stack, but also might well turn up an
issue or two we haven't thought enough about. Also, once we move the
protocol stack further along, we'll have more cycles to spend on
operational issues (like monitoring concerns discussed in XRBLOCK), which
currently limit the ability to deploy WebRTC at very large scale.
Unfortunately, we've been spending so much time on the MTI video codec
debate that less glamorous (but ultimately much more important) engineering
work is being neglected.

This is all by way of seconding your point that there is a real opportunity
cost to the never-ending, energy sapping MTI codec discussion.  Personally,
I'd much rather redirect the work of the Internet Engineering Task Force
RTCWEB WG away from amateur lawyering toward engineering where we actually
have expertise and could potentially make a difference.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bdc131293239604eb665349
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    +1, to focus on engineeri=
ng and operational issues.=A0

    On Nov 14, 2013, at 1:06, Berna=
rd Aboba <bernard_aboba@hot=
mail.com> wrote:
    

    



    Keith Drage said: 
    =A0
    "Agree
    <=
div align=3D"left" dir=3D"ltr">=A0
    

    I am at the point where I would prefer to sp=
end the meeting cycles getting things we can agree on, rather than where we=
 seem to be at the moment with an issue where there are two clear camps and=
 no real sign of a compromise.
    

    =A0
    Ultimately the market will decide (and some parts of it probably=
 have already decided - which is probably the reason for no progress).
    

    =A0
    Keith"
    

    =A0
    [B=
A] Well said.=A0With most of the RTCWEB WG drafts either having completed W=
GLC or being candidates for WGLC by the end of the year,=A0 with some elbow=
 grease it seems very possible to move the bulk of the documents to IETF la=
st call within a few months at most.=A0=A0 Polishing the RTCWEB document se=
t would yield multiple benefits.=A0 Not only would it get us closer to=A0th=
e goal of standardizing the WebRTC protocol stack, but also might well turn=
 up an issue or two we haven't thought enough about. Also, once we move=
 the protocol stack further along, we'll have more cycles to spend on o=
perational issues (like monitoring concerns discussed in XRBLOCK), which cu=
rrently limit the ability to deploy WebRTC at very large scale.=A0=A0 Unfor=
tunately, we've been spending so=A0much time on the MTI video codec deb=
ate that less glamorous (but ultimately much more important) engineering wo=
rk is being neglected. 
    

    =A0
    Th=
is is all by way of seconding your point that there is a real opportunity c=
ost to the never-ending, energy sapping MTI codec discussion.=A0 Personally=
, I'd much rather redirect the work of the Internet Engineering Task Fo=
rce RTCWEB WG away from amateur lawyering toward engineering where we actua=
lly have expertise and could potentially make a difference.
    
 		 	   		  
    

    ___________________=
____________________________
    rtcweb mailing list
    =
rtcweb@ietf.org
    https://www.ietf=
.org/mailman/listinfo/rtcweb
    

    

--047d7bdc131293239604eb665349--

From cowwoc@bbs.darktech.org  Sun Nov 17 19:06:53 2013
Return-Path: 
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 B24FD11E80E2 for ; Sun, 17 Nov 2013 19:06:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.561
X-Spam-Level: 
X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 bBvyPGozDUA0 for ; Sun, 17 Nov 2013 19:06:49 -0800 (PST)
Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 85A3C11E8122 for ; Sun, 17 Nov 2013 19:06:45 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id as1so1714160iec.13 for ; Sun, 17 Nov 2013 19:06:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=r+EFNfb+gfoKYWQvxmW8fosPdhpIFotILRDgJExlEoo=; b=QLZrKUfMZ6q+dye6m8XCkG7z+GZkI0SBfHgnC1nGDf6vE1Wueqwo/INlmZu48EngjV HeCevT9iByVOUWPVPM56dk+vnI2mpLZ6lF6xg1TVLwKIFquxkjoGwZB8sr5WrM4eC7GX m3DcqRyAKJeYvLc42lMxjIMDhbIsQbRLak2rc2Wy3SXK5osji05MsoIyLSdrXq+UBcKM z7YYqOIaH2/3c4PinDcszKl9vqaopz/XaTGTdDhwBqj7jBsrEmgRvp1xTPFo5OQIDs+1 eOuxVo3g37/0R+wfkzQ6pjioqEHBhwZPdnEYV6SwajJMUeXTq9OGrGz4AZqbqzK0aTOt uiYA==
X-Gm-Message-State: ALoCoQlAwTi2d8TdHAbuUQzo51dXQ3gOYiVbH+p1MLNX0Z+LC+aRxbQavoRzi3EhqcVjecnzJ50E
X-Received: by 10.50.129.39 with SMTP id nt7mr12178119igb.13.1384744004647; Sun, 17 Nov 2013 19:06:44 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id k6sm11461866igx.8.2013.11.17.19.06.43 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 19:06:43 -0800 (PST)
Message-ID: <5289842C.5030406@bbs.darktech.org>
Date: Sun, 17 Nov 2013 22:06:20 -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: rtcweb@ietf.org
References:  <52891EDB.2050607@googlemail.com>
In-Reply-To: <52891EDB.2050607@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 03:06:53 -0000

Maik,

Interesting :)

+1 for adding this as a new option. It gives the H.264 and VP8 crowds 
incentive to implement each other's codecs, or suffer with an older 
codec (H.261). It's a win-win either way.

My only worry is that this option will lead to the neglect of H.261 
support. So long as the working group commits to providing a "good 
enough" H.261 implementation (with a commercially-friendly license) as 
part of the reference WebRTC implementation I think we will be okay.

Gili

On 17/11/2013 2:54 PM, Maik Merten wrote:
> Hello,
>
> just wondering if something like
>
> "9. All entities SHOULD support both H.264 and VP8. All entities MUST 
> at least implement one of those. Entities that do not support both 
> H.264 and VP8 MUST implement H.261."
>
> has already popped up. My reasoning is that implementations supporting 
> both high performance codecs will always negotiate to use on of those 
> - H.261 should never be relevant there.
>
> It appears that all implementors are willing to implement either H.264 
> or VP8 (but not necessarily both). This obviously means that 
> negotiation failure regarding a high-performance codec is a 
> possiblity. In this case H.261 is actually useful so that basic video 
> calls can still be established (for instance, I guess deaf people may 
> always appreciate a video connection, as long as sign language can be 
> transmitted).
>
>
> Maik
>
>
> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>> Hi,
>> Gaining IETF consensus on making it mandatory to support only H.264 or
>> only VP8 has clearly failed. I would welcome anyone to share their
>> thoughts on why they believe this situation will change anytime in the
>> next few years.  Therefore, can I suggest that we remove items 1 and 2
>> from the list. Hopefully this will speed up the process by focusing
>> efforts towards gaining agreement on one of the remaining options.
>> The following alternatives has been proposed:
>>
>>  1. All entities MUST support H.264
>>  2. All entities MUST support VP8
>>  3. All entities MUST support both H.264 and VP8
>>  4. Browsers MUST support both H.264 and VP8, other entities MUST
>>     support at least one of H.264 and VP8
>>  5. All entities MUST support at least one of H.264 and VP8
>>  6. All entities MUST support H.261
>>  7. There is no MTI video codec
>>  8. All entities MUST support H.261 and all entities MUST support at
>>     least one of H.264 and VP8
>>
>> Regards,
>> Jeremy Fuller
>>
>>
>> _______________________________________________
>> 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


From harald@alvestrand.no  Sun Nov 17 20:47:20 2013
Return-Path: 
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 EB0D111E84CA for ; Sun, 17 Nov 2013 20:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 0k6t1V97he9p for ; Sun, 17 Nov 2013 20:47:15 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0678B11E8283 for ; Sun, 17 Nov 2013 20:47:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 07EE939E05D for ; Mon, 18 Nov 2013 05:46:59 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzzQyUQiFqX8 for ; Mon, 18 Nov 2013 05:46:57 +0100 (CET)
Received: from [172.30.42.117] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BD5A939E029 for ; Mon, 18 Nov 2013 05:46:57 +0100 (CET)
Message-ID: <52899BC0.2030909@alvestrand.no>
Date: Mon, 18 Nov 2013 05:46:56 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <5645151759529247262@unknownmsgid>
In-Reply-To: <5645151759529247262@unknownmsgid>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------000401000207070702040406"
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 04:47:21 -0000

This is a multi-part message in MIME format.
--------------000401000207070702040406
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 11/17/2013 10:43 PM, Varun Singh wrote:
> +1, to focus on engineering and operational issues.

Since firewall traversal was deemed to be a subject so specialized we
couldn't debate it on the main list, perhaps we could have an MTI-only
sublist?

I'll personally commit to reading every message on it, but I suspect
there are people on this mailing list who would like not to.

>
> On Nov 14, 2013, at 1:06, Bernard Aboba  > wrote:
>
>> Keith Drage said:
>>  
>> "Agree
>>  
>> I am at the point where I would prefer to spend the meeting cycles
>> getting things we can agree on, rather than where we seem to be at
>> the moment with an issue where there are two clear camps and no real
>> sign of a compromise.
>>  
>> Ultimately the market will decide (and some parts of it probably have
>> already decided - which is probably the reason for no progress).
>>  
>> Keith"
>>  
>> [BA] Well said. With most of the RTCWEB WG drafts either having
>> completed WGLC or being candidates for WGLC by the end of the year, 
>> with some elbow grease it seems very possible to move the bulk of the
>> documents to IETF last call within a few months at most.   Polishing
>> the RTCWEB document set would yield multiple benefits.  Not only
>> would it get us closer to the goal of standardizing the WebRTC
>> protocol stack, but also might well turn up an issue or two we
>> haven't thought enough about. Also, once we move the protocol stack
>> further along, we'll have more cycles to spend on operational issues
>> (like monitoring concerns discussed in XRBLOCK), which currently
>> limit the ability to deploy WebRTC at very large scale.  
>> Unfortunately, we've been spending so much time on the MTI video
>> codec debate that less glamorous (but ultimately much more important)
>> engineering work is being neglected.
>>  
>> This is all by way of seconding your point that there is a real
>> opportunity cost to the never-ending, energy sapping MTI codec
>> discussion.  Personally, I'd much rather redirect the work of the
>> Internet Engineering Task Force RTCWEB WG away from amateur lawyering
>> toward engineering where we actually have expertise and could
>> potentially make a difference.
>> _______________________________________________
>> 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


-- 
Surveillance is pervasive. Go Dark.


--------------000401000207070702040406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
    On 11/17/2013 10:43 PM, Varun Singh
      wrote:
    
    
    
    
    
      
    +1, to focus on engineering and operational issues. 
    
      
    
    
    
    
    
    Since firewall traversal was deemed to be a subject so specialized
    we couldn't debate it on the main list, perhaps we could have an
    MTI-only sublist?
    
    
    
    I'll personally commit to reading every message on it, but I suspect
    there are people on this mailing list who would like not to.
    
    
    
    
    
      

    
        On Nov 14, 2013, at 1:06, Bernard Aboba <bernard_aboba@hotmail.com>
        wrote:
    
        
    
      
    
      
    
        
    
          
          
    Keith Drage said: 
    
             
    
            "Agree
    
            
     
    
            
    I am at the point where I
                  would prefer to spend the meeting cycles getting
                  things we can agree on, rather than where we seem to
                  be at the moment with an issue where there are two
                  clear camps and no real sign of a compromise.
    
            
     
    
            
    Ultimately the market
                  will decide (and some parts of it probably have
                  already decided - which is probably the reason for no
                  progress).
    
            
     
    
            
    Keith"
    
            
     
    
            
    [BA] Well said. With most of the
              RTCWEB WG drafts either having completed WGLC or being
              candidates for WGLC by the end of the year,  with some
              elbow grease it seems very possible to move the bulk of
              the documents to IETF last call within a few months at
              most.   Polishing the RTCWEB document set would yield
              multiple benefits.  Not only would it get us closer to the
              goal of standardizing the WebRTC protocol stack, but also
              might well turn up an issue or two we haven't thought
              enough about. Also, once we move the protocol stack
              further along, we'll have more cycles to spend on
              operational issues (like monitoring concerns discussed in
              XRBLOCK), which currently limit the ability to deploy
              WebRTC at very large scale.   Unfortunately, we've been
              spending so much time on the MTI video codec debate that
              less glamorous (but ultimately much more important)
              engineering work is being neglected. 
    
            
     
    
            
    This is all by way of seconding
              your point that there is a real opportunity cost to the
              never-ending, energy sapping MTI codec discussion. 
              Personally, I'd much rather redirect the work of the
              Internet Engineering Task Force RTCWEB WG away from
              amateur lawyering toward engineering where we actually
              have expertise and could potentially make a difference.
    
          
    
        
    
      
    
      
    
        
    _______________________________________________
    
          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

    
    
    
    
    
    
    
    
    -- 
Surveillance is pervasive. Go Dark.

    
  


--------------000401000207070702040406--

From hangzhou.chenxin@huawei.com  Sun Nov 17 22:33:12 2013
Return-Path: 
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 2B63911E8174 for ; Sun, 17 Nov 2013 22:33:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jnwLDngV7BmA for ; Sun, 17 Nov 2013 22:33:06 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D1FEB11E8123 for ; Sun, 17 Nov 2013 22:33:05 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAK08625; Mon, 18 Nov 2013 06:33:03 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Nov 2013 06:32:58 +0000
Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Nov 2013 06:33:01 +0000
Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.191]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Mon, 18 Nov 2013 14:32:57 +0800
From: "Chenxin (Xin)" 
To: Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3929)
Thread-Index: AQHO5BlKWizBeFtfRUmj9AbINJTWmpoqgv/g
Date: Mon, 18 Nov 2013 06:32:57 +0000
Message-ID: <9E34D50A21D1D1489134B4D770CE03976809D9D8@SZXEMA504-MBX.china.huawei.com>
References:  <5645151759529247262@unknownmsgid> <52899BC0.2030909@alvestrand.no>
In-Reply-To: <52899BC0.2030909@alvestrand.no>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.166.41.125]
Content-Type: multipart/alternative; boundary="_000_9E34D50A21D1D1489134B4D770CE03976809D9D8SZXEMA504MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 06:33:12 -0000

--_000_9E34D50A21D1D1489134B4D770CE03976809D9D8SZXEMA504MBXchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1, to focus on engineering and operational issues too.


I suggest to keep it on the main list now. The technical debate on the MTI =
video is enough. We need focus on how to handle this dilemma. I think that =
move the discussion to the sub-list will not be helpful, which should not n=
eed a long time technical discussion in this stage.

But I am fine if you think the sub-mailing list is used for the strategy. I=
 am just afraid that  moving the discussion will delay the decision on MTI =
because losing focus and so on.


Best Regards,
     Xin

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Harald Alvestrand
Sent: Monday, November 18, 2013 12:47 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3=
929)

On 11/17/2013 10:43 PM, Varun Singh wrote:
+1, to focus on engineering and operational issues.

Since firewall traversal was deemed to be a subject so specialized we could=
n't debate it on the main list, perhaps we could have an MTI-only sublist?

I'll personally commit to reading every message on it, but I suspect there =
are people on this mailing list who would like not to.



On Nov 14, 2013, at 1:06, Bernard Aboba > wrote:
Keith Drage said:

"Agree

I am at the point where I would prefer to spend the meeting cycles getting =
things we can agree on, rather than where we seem to be at the moment with =
an issue where there are two clear camps and no real sign of a compromise.

Ultimately the market will decide (and some parts of it probably have alrea=
dy decided - which is probably the reason for no progress).

Keith"

[BA] Well said. With most of the RTCWEB WG drafts either having completed W=
GLC or being candidates for WGLC by the end of the year,  with some elbow g=
rease it seems very possible to move the bulk of the documents to IETF last=
 call within a few months at most.   Polishing the RTCWEB document set woul=
d yield multiple benefits.  Not only would it get us closer to the goal of =
standardizing the WebRTC protocol stack, but also might well turn up an iss=
ue or two we haven't thought enough about. Also, once we move the protocol =
stack further along, we'll have more cycles to spend on operational issues =
(like monitoring concerns discussed in XRBLOCK), which currently limit the =
ability to deploy WebRTC at very large scale.   Unfortunately, we've been s=
pending so much time on the MTI video codec debate that less glamorous (but=
 ultimately much more important) engineering work is being neglected.

This is all by way of seconding your point that there is a real opportunity=
 cost to the never-ending, energy sapping MTI codec discussion.  Personally=
, I'd much rather redirect the work of the Internet Engineering Task Force =
RTCWEB WG away from amateur lawyering toward engineering where we actually =
have expertise and could potentially make a difference.
_______________________________________________
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




--

Surveillance is pervasive. Go Dark.

--_000_9E34D50A21D1D1489134B4D770CE03976809D9D8SZXEMA504MBXchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









    

    &#=
43;1, to focus on engineering and operational issues too.

    

     
    

     
    

    I suggest to keep it on the main list now. The technica=
l debate on the MTI video is enough. We need focus on how to
 handle this dilemma. I think that move the discussion to the sub-list will=
 not be helpful, which should not need a long time technical discussion in =
this stage.  
    

     
    

    But I am fine if you think the sub-mailing list is used=
 for the strategy. I am just afraid that  moving the discussion
 will delay the decision on MTI because losing focus and so on. =

    

     
    

     
    

    

    Best Regards,
    

         Xi=
n

    

    

     =
;
    

    

    

    

    From:=
 rtcweb-bounces@ietf=
.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Harald Alvestrand
    
Sent: Monday, November 18, 2013 12:47 PM
    
To: rtcweb@ietf.org
    
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter=
, RFC 3929)
    

    

    

     
    

    

    On 11/17/2013 10:43 PM, Varun S=
ingh wrote:
    

    

    

    

    +1, to focus on engineering=
 and operational issues.

    

    

    


    
Since firewall traversal was deemed to be a subject so specialized we could=
n't debate it on the main list, perhaps we could have an MTI-only sublist?<=
br>

    
I'll personally commit to reading every message on it, but I suspect there =
are people on this mailing list who would like not to.
    

    

    

    

    

    =

    
On Nov 14, 2013, at 1:06, Bernard Aboba <bernard_aboba@hotmail.com> wrote:    

    

    

    

    

    Keith Drage said: 
    
 
    
"    Agree
    

     
    

    I am at the point where I would =
prefer to spend the meeting cycles getting things we can agree on, rather t=
han where we seem to be at the moment with an issue where
 there are two clear camps and no real sign of a compromise.
    

     
    

    Ultimately the market will decid=
e (and some parts of it probably have already decided - which is probably t=
he reason for no progress).

     
    

    Keith"
    

     
    

    [BA] Well said. With most =
of the RTCWEB WG drafts either having completed WGLC or being candidates fo=
r WGLC by the end of the year,  with some elbow grease it seems very p=
ossible to move the bulk of the documents to IETF
 last call within a few months at most.   Polishing the RTCWEB do=
cument set would yield multiple benefits.  Not only would it get us cl=
oser to the goal of standardizing the WebRTC protocol stack, but also =
might well turn up an issue or two we haven't thought
 enough about. Also, once we move the protocol stack further along, we'll h=
ave more cycles to spend on operational issues (like monitoring concerns di=
scussed in XRBLOCK), which currently limit the ability to deploy WebRTC at =
very large scale.   Unfortunately,
 we've been spending so much time on the MTI video codec debate that l=
ess glamorous (but ultimately much more important) engineering work is bein=
g neglected.

    

     
    

    This is all by way of seconding=
 your point that there is a real opportunity cost to the never-ending, ener=
gy sapping MTI codec discussion.  Personally, I'd much rather redirect=
 the work of the Internet Engineering Task
 Force RTCWEB WG away from amateur lawyering toward engineering where we ac=
tually have expertise and could potentially make a difference.
    

    

    

    

    

    

    _______________________________=
________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
https://www.ietf.o=
rg/mailman/listinfo/rtcweb
    

    

    


    

    

    

    

    _______________________________________________
    

    rtcweb mailing list
    

    rtcweb@ietf.or=
g
    

    https://www.ietf.org/mailman/listinfo/rtcweb<=
/pre>


    

    

    

    

    -- 
    

    Surveillance is pervasive. Go Dark.
    

    

    



--_000_9E34D50A21D1D1489134B4D770CE03976809D9D8SZXEMA504MBXchi_--

From treising75@gmail.com  Sun Nov 17 22:52:02 2013
Return-Path: 
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 1886B11E857E for ; Sun, 17 Nov 2013 22:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 7LgjBAYHZI64 for ; Sun, 17 Nov 2013 22:52:01 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id EDF4111E855A for ; Sun, 17 Nov 2013 22:52:00 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id ey16so3360580wid.1 for ; Sun, 17 Nov 2013 22:52:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=/Y4iAW3eq3Feb//2GKfK/W2NKu+xOzIIbQIOx8KaJdI=; b=qIZ3r3q+/upToHK+9dwO6TAA3WEgHJFe4x5IX/kBn8mTPY2XXpcA4MmiF+GgDMhVXQ vute1tO98PJORRcpnOaovselAC7qvmYm0dqCP7Mouv1C9tDhX+r+362WfhgwTdEumpVq nF4ao++A6+MLZoIXrdSV5rNhMvdP63ubkXqsix4HfLx4qJqt2Yih9qzjJchwLJcB/MoC d/COWL/3U9URaNCeI2ARKYGSKLZWUNknoiShbQfgZJWBZMWpIsLRr0UcnmWY2k6F5Cm7 ALPH8mn3dZXlmeZ1CPTantoB+ZL8kd2nV9JvTmiKFPisORU0Gbrtq+UBiPQZgTPuTSOR +Oow==
X-Received: by 10.180.79.230 with SMTP id m6mr15736448wix.19.1384757519753; Sun, 17 Nov 2013 22:51:59 -0800 (PST)
Received: from [192.168.1.202] (77.119.226.28.static.drei.at. [77.119.226.28]) by mx.google.com with ESMTPSA id gm2sm21059263wib.4.2013.11.17.22.51.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 22:51:59 -0800 (PST)
References:  <52891EDB.2050607@googlemail.com> <6A06EACB-69E2-4CE0-BDF2-1FDFD71159D3@gmail.com> <52892DD8.9050105@librevideo.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <52892DD8.9050105@librevideo.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DB56E1B-C97D-4D39-AA07-C4857CE3470D@gmail.com>
X-Mailer: iPhone Mail (11B554a)
From: Thomas Reisinger 
Date: Mon, 18 Nov 2013 07:51:53 +0100
To: Basil Mohamed Gohar 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 06:52:02 -0000

Team,

I had the same concerns about the royalty fee, but after some research I thi=
nk there aren't any more. For h.264 this still applies. H.261 is not accepta=
ble anymore in a HD world as it is today. Maybe somebody else cloud put some=
 light on the royalty fees for h.263. I will continue my research.

Cheers,

Thomas Reisinger

> On 17.11.2013, at 21:58, Basil Mohamed Gohar  w=
rote:
>=20
> Thomas,
>=20
> The reason H.261 is even being considered is because it is an old-enough
> specification that any patents on it should have now expired.  Patents,
> and their liability on existing video formats, are amongst the biggest
> factors affecting which formats can be adopted into the rtcweb standard.
>=20
> H.263 most likely (I haven't checked) still has patents associated with
> it that are active and, therefore, present an issue unless the
> respective owners of said patents have publicly declared them royalty-free=
.
>=20
>> On 11/17/2013 03:13 PM, Thomas Reisinger wrote:
>> Hi,
>>=20
>> Instead of h.261, I would recommend h.263 as a common base.
>>=20
>> Cheers,
>>=20
>> Thomas=20
>> Sent from mobile device
>>=20
>>> On 17 Nov 2013, at 20:54, Maik Merten  wrote:=

>>>=20
>>> Hello,
>>>=20
>>> just wondering if something like
>>>=20
>>> "9. All entities SHOULD support both H.264 and VP8. All entities MUST at=
 least implement one of those. Entities that do not support both H.264 and V=
P8 MUST implement H.261."
>>>=20
>>> has already popped up. My reasoning is that implementations supporting b=
oth high performance codecs will always negotiate to use on of those - H.261=
 should never be relevant there.
>>>=20
>>> It appears that all implementors are willing to implement either H.264 o=
r VP8 (but not necessarily both). This obviously means that negotiation fail=
ure regarding a high-performance codec is a possiblity. In this case H.261 i=
s actually useful so that basic video calls can still be established (for in=
stance, I guess deaf people may always appreciate a video connection, as lon=
g as sign language can be transmitted).
>>>=20
>>>=20
>>> Maik
>>>=20
>>>=20
>>> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>>>> Hi,
>>>> Gaining IETF consensus on making it mandatory to support only H.264 or
>>>> only VP8 has clearly failed. I would welcome anyone to share their
>>>> thoughts on why they believe this situation will change anytime in the
>>>> next few years.  Therefore, can I suggest that we remove items 1 and 2
>>>> from the list. Hopefully this will speed up the process by focusing
>>>> efforts towards gaining agreement on one of the remaining options.
>>>> The following alternatives has been proposed:
>>>>=20
>>>> 1. All entities MUST support H.264
>>>> 2. All entities MUST support VP8
>>>> 3. All entities MUST support both H.264 and VP8
>>>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>>>>   support at least one of H.264 and VP8
>>>> 5. All entities MUST support at least one of H.264 and VP8
>>>> 6. All entities MUST support H.261
>>>> 7. There is no MTI video codec
>>>> 8. All entities MUST support H.261 and all entities MUST support at
>>>>   least one of H.264 and VP8
>>>>=20
>>>> Regards,
>>>> Jeremy Fuller
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>=20
>>>=20
>>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>=20
>=20
> --=20
> Libre Video
> http://librevideo.org
>=20

From finlayson@live555.com  Sun Nov 17 22:59:03 2013
Return-Path: 
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 11A6911E85AF for ; Sun, 17 Nov 2013 22:59:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 d7g2t30XFLfU for ; Sun, 17 Nov 2013 22:58:58 -0800 (PST)
Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3791111E85AB for ; Sun, 17 Nov 2013 22:58:16 -0800 (PST)
Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id rAI6wExF054607 for ; Sun, 17 Nov 2013 22:58:15 -0800 (PST) (envelope-from finlayson@live555.com)
From: Ross Finlayson 
Content-Type: multipart/alternative; boundary="Apple-Mail=_13DCF512-89ED-4FE8-A0B0-84C2D6DD37A2"
Message-Id: <565DE5B9-89A1-4BAF-BBC7-F179B381D837@live555.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Date: Sun, 17 Nov 2013 22:58:14 -0800
References:  <52891EDB.2050607@googlemail.com>
To: rtcweb@ietf.org
In-Reply-To: <52891EDB.2050607@googlemail.com>
X-Mailer: Apple Mail (2.1822)
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 06:59:03 -0000

--Apple-Mail=_13DCF512-89ED-4FE8-A0B0-84C2D6DD37A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> just wondering if something like
>=20
> "9. All entities SHOULD support both H.264 and VP8. All entities MUST =
at least implement one of those. Entities that do not support both H.264 =
and VP8 MUST implement H.261."
>=20
> has already popped up. My reasoning is that implementations supporting =
both high performance codecs will always negotiate to use on of those - =
H.261 should never be relevant there.

This looks promising.  To summarize: You're proposing that each =
implementation MUST implement (at least) one of the following sets of =
codecs:
	{VP8, H.264}
	{VP8, H.261}
	{H.264, H.261}

This guarantees that there'll never be negotiation failure (between a =
pair of implementations), because the intersection of any two of these =
sets is non-empty.

It also allows the H.264 camp to avoid any alleged additional IPR risk =
from implementing VP8, because they won't need to implement VP8 (they'll =
need to implement H.261 instead).

Similarly, it also allows the VP8 camp to avoid any H.264 licensing =
requirements, because they won't need to implement H.264 (they'll need =
to implement H.261 instead).

And people who are willing to implement both VP8 and H.264 will know =
that they'll always be able to negotiate high-quality video.

Who knows - this may well be something that we could reach consensus on =
(provided that everyone agrees that there's little IPR risk from =
H.261)...


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


--Apple-Mail=_13DCF512-89ED-4FE8-A0B0-84C2D6DD37A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


    just wondering if =
something like

    "9. All entities SHOULD support both H.264 and =
VP8. All entities MUST at least implement one of those. Entities that do =
not support both H.264 and VP8 MUST implement H.261."

    has already =
popped up. My reasoning is that implementations supporting both high =
performance codecs will always negotiate to use on of those - H.261 =
should never be relevant =
there.

    This looks promising. =
 To summarize: You're proposing that each implementation MUST =
implement (at least) one of the following sets of codecs:
    	{VP8, =
H.264}
    	=
{VP8, H.261}
    	{H.264, =
H.261}

    This guarantees that there'll =
never be negotiation failure (between a pair of implementations), =
because the intersection of any two of these sets is =
non-empty.

    It also allows the H.264 camp to =
avoid any alleged additional IPR risk from implementing VP8, because =
they won't need to implement VP8 (they'll need to implement H.261 =
instead).

    Similarly, it also allows the VP8 =
camp to avoid any H.264 licensing requirements, because they won't need =
to implement H.264 (they'll need to implement H.261 =
instead).

    And people who are willing to =
implement both VP8 and H.264 will know that they'll always be able to =
negotiate high-quality video.

    Who knows - this =
may well be something that we could reach consensus on (provided that =
everyone agrees that there's little IPR risk from =
H.261)...


    
Ross Finlayson
    Live =
Networks, Inc.
    http://www.live555.com/    =


    

    =

--Apple-Mail=_13DCF512-89ED-4FE8-A0B0-84C2D6DD37A2--

From lgeyser@gmail.com  Sun Nov 17 23:13:33 2013
Return-Path: 
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 EEF7411E8256 for ; Sun, 17 Nov 2013 23:13:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mSDn-0au5m8d for ; Sun, 17 Nov 2013 23:13:32 -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 B0E4611E853E for ; Sun, 17 Nov 2013 23:13:26 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id c11so236371lbj.33 for ; Sun, 17 Nov 2013 23:13:25 -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=AxjNKDwQ21Z2GiFs0a8YssWP0/iyuL2Dt3Ubw/McIMw=; b=zJhxtPPZzRsZvXxdKeLGTVgyK5u7oxfduBbOn0+uT67/s1j9FSpFRFM9Acg50bFaVy Isk8eYIt7ytGlv1b4dHx54YvxfJL6oJjuxXt3KNFqViRvnMVYF/mSfl0wzWknPGUpKBb UklgkTtxM1Qe+m8cCDIJ6KH9C/5jDX4fYolcdoDUkbRMW0Cu2tCF2sdZ7risF4GWwdjk Dqg4kgqt7N9MOubdclZa6JQ3cLimpdEsbe76CXN+GNE7ftNYR9TvPLP4ivlW0y0oD0fK YzchQwL+nZxVSSz7A0XsYMM0vd8gMIuNSXtIp2lTxNy06p4+PoS00ksRJMa6GcWXV9ot Yp0Q==
MIME-Version: 1.0
X-Received: by 10.112.53.134 with SMTP id b6mr12604166lbp.5.1384758805588; Sun, 17 Nov 2013 23:13:25 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Sun, 17 Nov 2013 23:13:25 -0800 (PST)
In-Reply-To: <7DB56E1B-C97D-4D39-AA07-C4857CE3470D@gmail.com>
References:  <52891EDB.2050607@googlemail.com> <6A06EACB-69E2-4CE0-BDF2-1FDFD71159D3@gmail.com> <52892DD8.9050105@librevideo.org> <7DB56E1B-C97D-4D39-AA07-C4857CE3470D@gmail.com>
Date: Mon, 18 Nov 2013 09:13:25 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c3e624b4f0fe04eb6e484e
Cc: Thomas Reisinger 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 07:13:34 -0000

--001a11c3e624b4f0fe04eb6e484e
Content-Type: text/plain; charset=ISO-8859-1

Hi Thomas,

On this list there seem to be patents listed from 1997 to 2011 for H.263:
http://www.itu.int/net4/ipr/search.aspx?sector=ITU&class=PS&country=-1&org=-1&rec=H.263&prod=H.263&ps_country=-1&opt=-1&field=anokwcvd


On 18 November 2013 08:51, Thomas Reisinger  wrote:

> Team,
>
> I had the same concerns about the royalty fee, but after some research I
> think there aren't any more. For h.264 this still applies. H.261 is not
> acceptable anymore in a HD world as it is today. Maybe somebody else cloud
> put some light on the royalty fees for h.263. I will continue my research.
>
> Cheers,
>
> Thomas Reisinger
>
> > On 17.11.2013, at 21:58, Basil Mohamed Gohar 
> wrote:
> >
> > Thomas,
> >
> > The reason H.261 is even being considered is because it is an old-enough
> > specification that any patents on it should have now expired.  Patents,
> > and their liability on existing video formats, are amongst the biggest
> > factors affecting which formats can be adopted into the rtcweb standard.
> >
> > H.263 most likely (I haven't checked) still has patents associated with
> > it that are active and, therefore, present an issue unless the
> > respective owners of said patents have publicly declared them
> royalty-free.
> >
> >> On 11/17/2013 03:13 PM, Thomas Reisinger wrote:
> >> Hi,
> >>
> >> Instead of h.261, I would recommend h.263 as a common base.
> >>
> >> Cheers,
> >>
> >> Thomas
> >> Sent from mobile device
> >>
> >>> On 17 Nov 2013, at 20:54, Maik Merten 
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> just wondering if something like
> >>>
> >>> "9. All entities SHOULD support both H.264 and VP8. All entities MUST
> at least implement one of those. Entities that do not support both H.264
> and VP8 MUST implement H.261."
> >>>
> >>> has already popped up. My reasoning is that implementations supporting
> both high performance codecs will always negotiate to use on of those -
> H.261 should never be relevant there.
> >>>
> >>> It appears that all implementors are willing to implement either H.264
> or VP8 (but not necessarily both). This obviously means that negotiation
> failure regarding a high-performance codec is a possiblity. In this case
> H.261 is actually useful so that basic video calls can still be established
> (for instance, I guess deaf people may always appreciate a video
> connection, as long as sign language can be transmitted).
> >>>
> >>>
> >>> Maik
> >>>
> >>>
> >>> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
> >>>> Hi,
> >>>> Gaining IETF consensus on making it mandatory to support only H.264 or
> >>>> only VP8 has clearly failed. I would welcome anyone to share their
> >>>> thoughts on why they believe this situation will change anytime in the
> >>>> next few years.  Therefore, can I suggest that we remove items 1 and 2
> >>>> from the list. Hopefully this will speed up the process by focusing
> >>>> efforts towards gaining agreement on one of the remaining options.
> >>>> The following alternatives has been proposed:
> >>>>
> >>>> 1. All entities MUST support H.264
> >>>> 2. All entities MUST support VP8
> >>>> 3. All entities MUST support both H.264 and VP8
> >>>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
> >>>>   support at least one of H.264 and VP8
> >>>> 5. All entities MUST support at least one of H.264 and VP8
> >>>> 6. All entities MUST support H.261
> >>>> 7. There is no MTI video codec
> >>>> 8. All entities MUST support H.261 and all entities MUST support at
> >>>>   least one of H.264 and VP8
> >>>>
> >>>> Regards,
> >>>> Jeremy Fuller
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>
> >
> >
> > --
> > Libre Video
> > http://librevideo.org
> >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--001a11c3e624b4f0fe04eb6e484e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




    O=
n 18 November 2013 08:51, Thomas Reisinger <treising75@gmail.com>=
; wrote:
    

    Team,
    

    
I had the same concerns about the royalty fee, but after some research I th=
ink there aren't any more. For h.264 this still applies. H.261 is not a=
cceptable anymore in a HD world as it is today. Maybe somebody else cloud p=
ut some light on the royalty fees for h.263. I will continue my research.


    
Cheers,
    

    
Thomas Reisinger
    


    
> On 17.11.2013, at 21:58, Basil Mohamed Gohar <basilgohar@librevideo.org> wrote:
    
>
    
> Thomas,
    
>
    
> The reason H.261 is even being considered is because it is an old-enou=
gh
    
> specification that any patents on it should have now expired. =A0Paten=
ts,
    
> and their liability on existing video formats, are amongst the biggest=

    
> factors affecting which formats can be adopted into the rtcweb standar=
d.
    
>
    
> H.263 most likely (I haven't checked) still has patents associated=
 with
    
> it that are active and, therefore, present an issue unless the
    
> respective owners of said patents have publicly declared them royalty-=
free.
    
>
    
>> On 11/17/2013 03:13 PM, Thomas Reisinger wrote:
    
>> Hi,
    
>>
    
>> Instead of h.261, I would recommend h.263 as a common base.
    
>>
    
>> Cheers,
    
>>
    
>> Thomas
    
>> Sent from mobile device
    
>>
    
>>> On 17 Nov 2013, at 20:54, Maik Merten <maikmerten@googlemail.com> wrote:
    
>>>
    
>>> Hello,
    
>>>
    
>>> just wondering if something like
    
>>>
    
>>> "9. All entities SHOULD support both H.264 and VP8. All e=
ntities MUST at least implement one of those. Entities that do not support =
both H.264 and VP8 MUST implement H.261."
    
>>>
    
>>> has already popped up. My reasoning is that implementations su=
pporting both high performance codecs will always negotiate to use on of th=
ose - H.261 should never be relevant there.
    
>>>
    
>>> It appears that all implementors are willing to implement eith=
er H.264 or VP8 (but not necessarily both). This obviously means that negot=
iation failure regarding a high-performance codec is a possiblity. In this =
case H.261 is actually useful so that basic video calls can still be establ=
ished (for instance, I guess deaf people may always appreciate a video conn=
ection, as long as sign language can be transmitted).
    

>>>
    
>>>
    
>>> Maik
    
>>>
    
>>>
    
>>> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
    
>>>> Hi,
    
>>>> Gaining IETF consensus on making it mandatory to support o=
nly H.264 or
    
>>>> only VP8 has clearly failed. I would welcome anyone to sha=
re their
    
>>>> thoughts on why they believe this situation will change an=
ytime in the
    
>>>> next few years. =A0Therefore, can I suggest that we remove=
 items 1 and 2
    
>>>> from the list. Hopefully this will speed up the process by=
 focusing
    
>>>> efforts towards gaining agreement on one of the remaining =
options.
    
>>>> The following alternatives has been proposed:
    
>>>>
    
>>>> 1. All entities MUST support H.264
    
>>>> 2. All entities MUST support VP8
    
>>>> 3. All entities MUST support both H.264 and VP8
    
>>>> 4. Browsers MUST support both H.264 and VP8, other entitie=
s MUST
    
>>>> =A0 support at least one of H.264 and VP8
    
>>>> 5. All entities MUST support at least one of H.264 and VP8=

    
>>>> 6. All entities MUST support H.261
    
>>>> 7. There is no MTI video codec
    
>>>> 8. All entities MUST support H.261 and all entities MUST s=
upport at
    
>>>> =A0 least one of H.264 and VP8
    
>>>>
    
>>>> Regards,
    
>>>> Jeremy Fuller
    
>>>>
    
>>>>
    
>>>> _______________________________________________
    
>>>> 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
    
>>
    
>
    
>
    
> --
    
> Libre Video
    
> http://librevideo.=
org
    
>
    
_______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--001a11c3e624b4f0fe04eb6e484e--

From maikmerten@googlemail.com  Sun Nov 17 23:56:42 2013
Return-Path: 
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 75DE011E8149 for ; Sun, 17 Nov 2013 23:56:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 5zoXCSNurM3h for ; Sun, 17 Nov 2013 23:56:40 -0800 (PST)
Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id E065411E80F2 for ; Sun, 17 Nov 2013 23:56:39 -0800 (PST)
Received: by mail-bk0-f49.google.com with SMTP id my13so441718bkb.36 for ; Sun, 17 Nov 2013 23:56:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=nlyL3s8mEum2H5RkffxfAQ5RQoNRSmya7yMjpvkqS5M=; b=yQ9UFJH2PqK3T4cmcvjhi0qVVu8l4bZHn5jiZ3p6vHC0cPo+qtqCrNUkSo8i5FiAHq umouZWwQqDP9vE1ezb2s+i7fAWZxFP0E7+CobKKxXpOezpJnui26AYNi6oljzRbUfRrW g8WcnJ01FynVuC31D7D8gHu7Vebu37xqSY4AMaZ8puIPpCrVsLvC8rIbPdRxmZUFSR5T dL2xE4AsVJalUmM1ks17x2Idn4UBAFwm8eOqdpnBqGRkae4aBHtbAGOPIeRghgqi47WC PnTU1QFr7pHgv5oAe3zPbKEDHgkLJehrLn+APwv0+b/nwDJJFJ87Ag8Jc5Zu1as5D/n7 qaoA==
X-Received: by 10.205.14.69 with SMTP id pp5mr11572691bkb.14.1384761397892; Sun, 17 Nov 2013 23:56:37 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id qg7sm15639929bkb.6.2013.11.17.23.56.36 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 23:56:36 -0800 (PST)
Message-ID: <5289C87D.1050009@googlemail.com>
Date: Mon, 18 Nov 2013 08:57:49 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 	<52891EDB.2050607@googlemail.com> <565DE5B9-89A1-4BAF-BBC7-F179B381D837@live555.com>
In-Reply-To: <565DE5B9-89A1-4BAF-BBC7-F179B381D837@live555.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 07:56:42 -0000

Dear Ross,

thanks for providing your thoughts on this proposal. Your analysis quite 
perfectly reflects my reasoning.

I think there is consensus that both H.264 Constrained Baseline and VP8 
are capable of delivering high quality video. However...

  - the camp opposing VP8 fears that Google is not in complete control 
of the surrounding IPR situation
  - the camp opposing H.264 presented diverse examples where H.264's 
licensing is not compatible with their very operating principles

I currently do not see how this can be resolved in such a way that each 
camp is happy.

There apparently is consensus, however, that negotiation failure should 
be avoided and that high video quality is desirable, meaning that 
entities are very welcome to implement both high performance codecs. 
This does not appear to be possible for all participants, so to avoid 
negotiation failure while working around IPR issues something like H.261 
looks quite promising IMO. While some participants rightfully question 
the place such an antique codec may have in our HD world, I'm still 
fully convinced that transmitting CIF video can still be very much 
desirable over forcefully transmitting no video at all: that resolution 
still transports emotions, facial features and sign language (which is 
relevant to those concerned with accessibility).

It can also be demonstrated that objective quality measures such as PSNR 
and SSIM favor transmission of low resolution video over a static black 
picture ;)

Again in a nutshell:

  - nobody is forced to implement a codec they object to on IPR grounds
  - we never have negotiation failure and can always transmit video 
(albeit not always beautiful video)
  - implementations that are always able to transmit high quality video 
do not need to be concerned with implementing a low quality video codec


Best regards,

Maik


Am 18.11.2013 07:58, schrieb Ross Finlayson:
>> just wondering if something like
>>
>> "9. All entities SHOULD support both H.264 and VP8. All entities MUST
>> at least implement one of those. Entities that do not support both
>> H.264 and VP8 MUST implement H.261."
>>
>> has already popped up. My reasoning is that implementations supporting
>> both high performance codecs will always negotiate to use on of those
>> - H.261 should never be relevant there.
>
> This looks promising.  To summarize: You're proposing that each
> implementation MUST implement (at least) one of the following sets of
> codecs:
> {VP8, H.264}
> {VP8, H.261}
> {H.264, H.261}
>
> This guarantees that there'll never be negotiation failure (between a
> pair of implementations), because the intersection of any two of these
> sets is non-empty.
>
> It also allows the H.264 camp to avoid any alleged additional IPR risk
> from implementing VP8, because they won't need to implement VP8 (they'll
> need to implement H.261 instead).
>
> Similarly, it also allows the VP8 camp to avoid any H.264 licensing
> requirements, because they won't need to implement H.264 (they'll need
> to implement H.261 instead).
>
> And people who are willing to implement both VP8 and H.264 will know
> that they'll always be able to negotiate high-quality video.
>
> Who knows - this may well be something that we could reach consensus on
> (provided that everyone agrees that there's little IPR risk from H.261)...
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From treising75@gmail.com  Mon Nov 18 00:11:16 2013
Return-Path: 
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 00EF811E8162 for ; Mon, 18 Nov 2013 00:11:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.697,  BAYES_00=-2.599, HTML_MESSAGE=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 HxNyvHt2FYy7 for ; Mon, 18 Nov 2013 00:11:11 -0800 (PST)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1C59A11E8126 for ; Mon, 18 Nov 2013 00:11:10 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id z12so5845718wgg.19 for ; Mon, 18 Nov 2013 00:11:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=d0i9JuygY6Qp62SQbWmH4inQsVDgYY16f6Zwr2dZ7Gk=; b=CbWwk6xvKWSu7RdJ5dOunQGmgpQUKMdxbdIden5UEtmTysn9hcUCYljveZGDTZKkQU ntEpntr/B9gvlpplLith+ebvtlgtCIXsFOEMEH5vKpm7XNJNNJl3kLobtXP7DSfaT65A Gr16SA8bCE0Cmqtg0DTlNoFcPDvKp3nQkhCa3PAX8FxQDVG0y9C/ijZlzETSUfDcMGOG i+7YGXdyZZDuuS4e9hI/25ak5O7DZkJalI8zqapKXUknK4mVstCEHTWMx/wYZEcIYblv Rf2/Ly/Rdc4p0JXQgQ34mjO2qqemNeWLJ0EN7Zf+iB/1y1LZ9baI8edlfbGtP6rsxmVU Ouyg==
X-Received: by 10.180.211.212 with SMTP id ne20mr16040776wic.31.1384762270240;  Mon, 18 Nov 2013 00:11:10 -0800 (PST)
Received: from papageizichta (77.119.226.28.static.drei.at. [77.119.226.28]) by mx.google.com with ESMTPSA id ey4sm21613702wic.11.2013.11.18.00.11.08 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Nov 2013 00:11:09 -0800 (PST)
From: "Thomas Reisinger" 
To: "'Leon Geyser'" , 
References: 	<52891EDB.2050607@googlemail.com>	<6A06EACB-69E2-4CE0-BDF2-1FDFD71159D3@gmail.com>	<52892DD8.9050105@librevideo.org>	<7DB56E1B-C97D-4D39-AA07-C4857CE3470D@gmail.com> 
In-Reply-To: 
Date: Mon, 18 Nov 2013 09:11:09 +0100
Message-ID: <003e01cee435$be1f3940$3a5dabc0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01CEE43E.1FE83520"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFCmr0eP3xRJBLBEMD8MQ+xPSdPQQKh3Qx5AkkcETYDF2FQ6QJClJ9hAVVzwo2a5mHhIA==
Content-Language: de-at
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 08:11:16 -0000

This is a multipart message in MIME format.

------=_NextPart_000_003F_01CEE43E.1FE83520
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thank you Leon. Why should we go with h.261 (except the lower cpu
requirements for en/decoding), when we have a very popular royalty free
h.263 as a common base for most video participants?

 

 

Cheers,

 

Thomas Reisinger 

From: Leon Geyser [mailto:lgeyser@gmail.com] 
Sent: Montag, 18. November 2013 08:13
To: rtcweb@ietf.org
Cc: Basil Mohamed Gohar; Thomas Reisinger
Subject: Re: [rtcweb] Video codec selection - way forward

 

Hi Thomas,

On this list there seem to be patents listed from 1997 to 2011 for H.263:

http://www.itu.int/net4/ipr/search.aspx?sector=ITU

&class=PS&country=-1&org=-1&rec=H.263&prod=H.263&ps_country=-1&opt=-1&field=
anokwcvd

 

On 18 November 2013 08:51, Thomas Reisinger  > wrote:

Team,

I had the same concerns about the royalty fee, but after some research I
think there aren't any more. For h.264 this still applies. H.261 is not
acceptable anymore in a HD world as it is today. Maybe somebody else cloud
put some light on the royalty fees for h.263. I will continue my research.

Cheers,

Thomas Reisinger


> On 17.11.2013, at 21:58, Basil Mohamed Gohar  > wrote:
>
> Thomas,
>
> The reason H.261 is even being considered is because it is an old-enough
> specification that any patents on it should have now expired.  Patents,
> and their liability on existing video formats, are amongst the biggest
> factors affecting which formats can be adopted into the rtcweb standard.
>
> H.263 most likely (I haven't checked) still has patents associated with
> it that are active and, therefore, present an issue unless the
> respective owners of said patents have publicly declared them
royalty-free.
>
>> On 11/17/2013 03:13 PM, Thomas Reisinger wrote:
>> Hi,
>>
>> Instead of h.261, I would recommend h.263 as a common base.
>>
>> Cheers,
>>
>> Thomas
>> Sent from mobile device
>>
>>> On 17 Nov 2013, at 20:54, Maik Merten  > wrote:
>>>
>>> Hello,
>>>
>>> just wondering if something like
>>>
>>> "9. All entities SHOULD support both H.264 and VP8. All entities MUST at
least implement one of those. Entities that do not support both H.264 and
VP8 MUST implement H.261."
>>>
>>> has already popped up. My reasoning is that implementations supporting
both high performance codecs will always negotiate to use on of those -
H.261 should never be relevant there.
>>>
>>> It appears that all implementors are willing to implement either H.264
or VP8 (but not necessarily both). This obviously means that negotiation
failure regarding a high-performance codec is a possiblity. In this case
H.261 is actually useful so that basic video calls can still be established
(for instance, I guess deaf people may always appreciate a video connection,
as long as sign language can be transmitted).
>>>
>>>
>>> Maik
>>>
>>>
>>> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>>>> Hi,
>>>> Gaining IETF consensus on making it mandatory to support only H.264 or
>>>> only VP8 has clearly failed. I would welcome anyone to share their
>>>> thoughts on why they believe this situation will change anytime in the
>>>> next few years.  Therefore, can I suggest that we remove items 1 and 2
>>>> from the list. Hopefully this will speed up the process by focusing
>>>> efforts towards gaining agreement on one of the remaining options.
>>>> The following alternatives has been proposed:
>>>>
>>>> 1. All entities MUST support H.264
>>>> 2. All entities MUST support VP8
>>>> 3. All entities MUST support both H.264 and VP8
>>>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>>>>   support at least one of H.264 and VP8
>>>> 5. All entities MUST support at least one of H.264 and VP8
>>>> 6. All entities MUST support H.261
>>>> 7. There is no MTI video codec
>>>> 8. All entities MUST support H.261 and all entities MUST support at
>>>>   least one of H.264 and VP8
>>>>
>>>> Regards,
>>>> Jeremy Fuller
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
> --
> Libre Video
> http://librevideo.org
>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org  
https://www.ietf.org/mailman/listinfo/rtcweb

 


------=_NextPart_000_003F_01CEE43E.1FE83520
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


    Thank you Leon. Why should we go with =
h.261 (except the lower cpu requirements for en/decoding), when we have =
a very popular royalty free h.263 as a common base for most video =
participants?
     
     
    Cheers,
     
    Thomas Reisinger 
    From: Leon =
Geyser [mailto:lgeyser@gmail.com] 
    Sent: Montag, 18. November =
2013 08:13
    To: rtcweb@ietf.org
    Cc: Basil Mohamed =
Gohar; Thomas Reisinger
    Subject: Re: [rtcweb] Video codec =
selection - way forward
     
     
    On 18 November 2013 08:51, Thomas Reisinger <treising75@gmail.com> =
wrote:
    Team,

    I had the same concerns about the royalty =
fee, but after some research I think there aren't any more. For h.264 =
this still applies. H.261 is not acceptable anymore in a HD world as it =
is today. Maybe somebody else cloud put some light on the royalty fees =
for h.263. I will continue my research.

    Cheers,

    Thomas =
Reisinger

    > On =
17.11.2013, at 21:58, Basil Mohamed Gohar <basilgohar@librevideo.org&g=
t; wrote:
    >
    > Thomas,
    >
    > The reason H.261 is =
even being considered is because it is an old-enough
    > =
specification that any patents on it should have now expired. =
 Patents,
    > and their liability on existing video formats, =
are amongst the biggest
    > factors affecting which formats can be =
adopted into the rtcweb standard.
    >
    > H.263 most likely (I =
haven't checked) still has patents associated with
    > it that are =
active and, therefore, present an issue unless the
    > respective =
owners of said patents have publicly declared them =
royalty-free.
    >
    >> On 11/17/2013 03:13 PM, Thomas =
Reisinger wrote:
    >> Hi,
    >>
    >> Instead of =
h.261, I would recommend h.263 as a common base.
    >>
    >> =
Cheers,
    >>
    >> Thomas
    >> Sent from mobile =
device
    >>
    >>> On 17 Nov 2013, at 20:54, Maik Merten =
<maikmerten@googlemail.com&g=
t; wrote:
    >>>
    >>> =
Hello,
    >>>
    >>> just wondering if something =
like
    >>>
    >>> "9. All entities SHOULD =
support both H.264 and VP8. All entities MUST at least implement one of =
those. Entities that do not support both H.264 and VP8 MUST implement =
H.261."
    >>>
    >>> has already popped up. My =
reasoning is that implementations supporting both high performance =
codecs will always negotiate to use on of those - H.261 should never be =
relevant there.
    >>>
    >>> It appears that all =
implementors are willing to implement either H.264 or VP8 (but not =
necessarily both). This obviously means that negotiation failure =
regarding a high-performance codec is a possiblity. In this case H.261 =
is actually useful so that basic video calls can still be established =
(for instance, I guess deaf people may always appreciate a video =
connection, as long as sign language can be =
transmitted).
    >>>
    >>>
    >>> =
Maik
    >>>
    >>>
    >>> Am 14.11.2013 =
12:37, schrieb Jeremy Fuller:
    >>>> =
Hi,
    >>>> Gaining IETF consensus on making it mandatory to =
support only H.264 or
    >>>> only VP8 has clearly failed. I =
would welcome anyone to share their
    >>>> thoughts on why =
they believe this situation will change anytime in =
the
    >>>> next few years.  Therefore, can I suggest =
that we remove items 1 and 2
    >>>> from the list. =
Hopefully this will speed up the process by focusing
    >>>> =
efforts towards gaining agreement on one of the remaining =
options.
    >>>> The following alternatives has been =
proposed:
    >>>>
    >>>> 1. All entities MUST =
support H.264
    >>>> 2. All entities MUST support =
VP8
    >>>> 3. All entities MUST support both H.264 and =
VP8
    >>>> 4. Browsers MUST support both H.264 and VP8, =
other entities MUST
    >>>>   support at least one of =
H.264 and VP8
    >>>> 5. All entities MUST support at least =
one of H.264 and VP8
    >>>> 6. All entities MUST support =
H.261
    >>>> 7. There is no MTI video =
codec
    >>>> 8. All entities MUST support H.261 and all =
entities MUST support at
    >>>>   least one of H.264 =
and VP8
    >>>>
    >>>> =
Regards,
    >>>> Jeremy =
Fuller
    >>>>
    >>>>
    >>>> =
_______________________________________________
    >>>> =
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
    >=
;>
    >
    >
    > --
    > Libre Video
    > http://librevideo.org
    >
    __________________=
_____________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
     
    
------=_NextPart_000_003F_01CEE43E.1FE83520--


From maikmerten@googlemail.com  Mon Nov 18 00:21:38 2013
Return-Path: 
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 CF88711E8162 for ; Mon, 18 Nov 2013 00:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 MowOidoe2HRq for ; Mon, 18 Nov 2013 00:21:37 -0800 (PST)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 810C111E8149 for ; Mon, 18 Nov 2013 00:21:36 -0800 (PST)
Received: by mail-bk0-f50.google.com with SMTP id e11so1051358bkh.23 for ; Mon, 18 Nov 2013 00:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=r82b0XROJZst/7kEgkVpPqzWr0kueNvRrLYjN2UAiRQ=; b=LlBSmDs7BV0sDbFzqTVRujy31olJHMVzvapVxnTxBu5hdy4EAkwX9XZRoRYoP0hwk/ yN6Lg1c+or569VpuosbwGI2ZCG5fd69FWUvOSoGCyV6cbnWEP6kLXjH7YUP/Juxeg+pZ X27lYsm0APlnMaiO0UebfVCYZiFGMW3j6gNXLbyfrjKGppWZSVkhg9zkVKzjl+I34N1h iKZAn8zKnNy6qYQSXwlrbmHJVffqHHhdNYpH5NRX2HdGEnZ0IbReObkWTy2yvjB+rXp0 0om68d4ojBC+Voq0nZLBCw43vVDFqcemqFZy7G5CZfrDrG97e7wnyMFZtu6ydx1suSVc zh/g==
X-Received: by 10.204.103.199 with SMTP id l7mr11612578bko.11.1384762895577; Mon, 18 Nov 2013 00:21:35 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id w9sm15742899bkn.12.2013.11.18.00.21.33 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 00:21:34 -0800 (PST)
Message-ID: <5289CE55.6090004@googlemail.com>
Date: Mon, 18 Nov 2013 09:22:45 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 	<52891EDB.2050607@googlemail.com>	<6A06EACB-69E2-4CE0-BDF2-1FDFD71159D3@gmail.com>	<52892DD8.9050105@librevideo.org>	<7DB56E1B-C97D-4D39-AA07-C4857CE3470D@gmail.com>	 <003e01cee435$be1f3940$3a5dabc0$@gmail.com>
In-Reply-To: <003e01cee435$be1f3940$3a5dabc0$@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 08:21:38 -0000

H.263 seems to be covered by the MPEG-4 Visual patent pool and appears 
to require licensing:

http://www.mpegla.com/main/programs/M4V/Documents/M4VCrossRef.pdf


Maik


Am 18.11.2013 09:11, schrieb Thomas Reisinger:
> Thank you Leon. Why should we go with h.261 (except the lower cpu
> requirements for en/decoding), when we have a very popular royalty free
> h.263 as a common base for most video participants?
>
> Cheers,
>
> Thomas Reisinger
>
> *From:*Leon Geyser [mailto:lgeyser@gmail.com]
> *Sent:* Montag, 18. November 2013 08:13
> *To:* rtcweb@ietf.org
> *Cc:* Basil Mohamed Gohar; Thomas Reisinger
> *Subject:* Re: [rtcweb] Video codec selection - way forward
>
> Hi Thomas,
>
> On this list there seem to be patents listed from 1997 to 2011 for H.263:
>
> http://www.itu.int/net4/ipr/search.aspx?sector=ITU&class=PS&country=-1&org=-1&rec=H.263&prod=H.263&ps_country=-1&opt=-1&field=anokwcvd
>
> On 18 November 2013 08:51, Thomas Reisinger  > wrote:
>
>     Team,
>
>     I had the same concerns about the royalty fee, but after some
>     research I think there aren't any more. For h.264 this still
>     applies. H.261 is not acceptable anymore in a HD world as it is
>     today. Maybe somebody else cloud put some light on the royalty fees
>     for h.263. I will continue my research.
>
>     Cheers,
>
>     Thomas Reisinger
>
>
>      > On 17.11.2013, at 21:58, Basil Mohamed Gohar
>     > wrote:
>      >
>      > Thomas,
>      >
>      > The reason H.261 is even being considered is because it is an
>     old-enough
>      > specification that any patents on it should have now expired.
>       Patents,
>      > and their liability on existing video formats, are amongst the
>     biggest
>      > factors affecting which formats can be adopted into the rtcweb
>     standard.
>      >
>      > H.263 most likely (I haven't checked) still has patents
>     associated with
>      > it that are active and, therefore, present an issue unless the
>      > respective owners of said patents have publicly declared them
>     royalty-free.
>      >
>      >> On 11/17/2013 03:13 PM, Thomas Reisinger wrote:
>      >> Hi,
>      >>
>      >> Instead of h.261, I would recommend h.263 as a common base.
>      >>
>      >> Cheers,
>      >>
>      >> Thomas
>      >> Sent from mobile device
>      >>
>      >>> On 17 Nov 2013, at 20:54, Maik Merten
>     > wrote:
>      >>>
>      >>> Hello,
>      >>>
>      >>> just wondering if something like
>      >>>
>      >>> "9. All entities SHOULD support both H.264 and VP8. All
>     entities MUST at least implement one of those. Entities that do not
>     support both H.264 and VP8 MUST implement H.261."
>      >>>
>      >>> has already popped up. My reasoning is that implementations
>     supporting both high performance codecs will always negotiate to use
>     on of those - H.261 should never be relevant there.
>      >>>
>      >>> It appears that all implementors are willing to implement
>     either H.264 or VP8 (but not necessarily both). This obviously means
>     that negotiation failure regarding a high-performance codec is a
>     possiblity. In this case H.261 is actually useful so that basic
>     video calls can still be established (for instance, I guess deaf
>     people may always appreciate a video connection, as long as sign
>     language can be transmitted).
>      >>>
>      >>>
>      >>> Maik
>      >>>
>      >>>
>      >>> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>      >>>> Hi,
>      >>>> Gaining IETF consensus on making it mandatory to support only
>     H.264 or
>      >>>> only VP8 has clearly failed. I would welcome anyone to share their
>      >>>> thoughts on why they believe this situation will change
>     anytime in the
>      >>>> next few years.  Therefore, can I suggest that we remove items
>     1 and 2
>      >>>> from the list. Hopefully this will speed up the process by
>     focusing
>      >>>> efforts towards gaining agreement on one of the remaining options.
>      >>>> The following alternatives has been proposed:
>      >>>>
>      >>>> 1. All entities MUST support H.264
>      >>>> 2. All entities MUST support VP8
>      >>>> 3. All entities MUST support both H.264 and VP8
>      >>>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>      >>>>   support at least one of H.264 and VP8
>      >>>> 5. All entities MUST support at least one of H.264 and VP8
>      >>>> 6. All entities MUST support H.261
>      >>>> 7. There is no MTI video codec
>      >>>> 8. All entities MUST support H.261 and all entities MUST
>     support at
>      >>>>   least one of H.264 and VP8
>      >>>>
>      >>>> Regards,
>      >>>> Jeremy Fuller
>      >>>>
>      >>>>
>      >>>> _______________________________________________
>      >>>> 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
>      >>
>      >
>      >
>      > --
>      > Libre Video
>      > http://librevideo.org
>      >
>     _______________________________________________
>     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
>


From magnus.westerlund@ericsson.com  Mon Nov 18 02:55:24 2013
Return-Path: 
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 577E811E814C for ; Mon, 18 Nov 2013 02:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.344
X-Spam-Level: 
X-Spam-Status: No, score=-105.344 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_MONEYTERMS=0.681, USER_IN_WHITELIST=-100]
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 qwbLzqPnGvZX for ; Mon, 18 Nov 2013 02:55:14 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8E411E8108 for ; Mon, 18 Nov 2013 02:55:06 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-ba-5289f2095b7d
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0C.87.03802.902F9825; Mon, 18 Nov 2013 11:55:06 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Mon, 18 Nov 2013 11:55:05 +0100
Message-ID: <5289F209.9030008@ericsson.com>
Date: Mon, 18 Nov 2013 11:55:05 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Basil Mohamed Gohar , 
References: <5283DFDC.4010906@ericsson.com> <528492E8.8020202@ericsson.com> <52869891.7010100@librevideo.org>
In-Reply-To: <52869891.7010100@librevideo.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3VpfrU2eQwffdPBYPPm5mtVj7r53d gcljyZKfTB7Nr68zBTBFcdmkpOZklqUW6dslcGVcn9bKVDCBt+LsxXNsDYwfuboYOTkkBEwk /hxfwwZhi0lcuLceyObiEBI4xCgx98FXRghnOaPEi9Un2EGqeAW0Jdb+amIBsVkEVCVubjnK BGKzCVhI3PzRCDZJVCBY4vyrxVD1ghInZz4BqufgEBFwk1j73gjEFBawlLhw3ASkQkggV+JG 60WwKZwCehJzT5xiBSmREBCX6GkMAgkzA4WnXG1hhLDlJZq3zmaGaNWWaGjqYJ3AKDgLya5Z SFpmIWlZwMi8ipE9NzEzJ73caBMjMBwPbvmtuoPxzjmRQ4zSHCxK4rwf3joHCQmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamBM7/708vvW6AdTmrf73fn5kjHCUEVcd/q+A//TfwY1LuHVnbeF 83uBw8RtZQsX/P58ffaha0YRc59PZOhavG3+Sw3lzT4diUtXNyWF2xt/eCHFJxvic0Fuju6h bIcHBb1LymNaU9hW/PTv+1qqkVU56Xmu5dYVl7XNz/xYqFbRn+brdGbVNM07SizFGYmGWsxF xYkAlpFzuRUCAAA=
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 10:55:25 -0000

Hi,

As requested I have added this to the list of proposals.

/Magnus

On 2013-11-15 22:56, Basil Mohamed Gohar wrote:
> I am forwarding the following on behalf of Hervé.  You can consider this
> also a +1 from me for the proposal, for what it's worth:
> 
>> Proposal for MTI video codec: All entities MUST support Theora.
>>
>> Theora was derived from VP3 (a codec from 2000).
>> Theora bitstream format freeze in June 2004.
>>
>> Theora documentation (including link to spec pdf) : http://theora.org/doc/
>>
>> If you want to try out the codec, rather than write your own from scratch, please consider using the reference implementation's latest sources (rather than version 1.1) : http://git.xiph.org/?p=mirrors/theora.git
>>
>> There have been several commercial products that apparently weren't sued into bankruptcy: http://wiki.xiph.org/Games_that_use_Theora
>>
>> No license fees are owed to Xiph for implementation.
>>
>> See also:
>> http://wiki.xiph.org/TheoraSoftwarePlayers
>> http://wiki.xiph.org/Theora_Hardware
>> http://wiki.xiph.org/TheoraSoftwareEncoders
>> http://wiki.xiph.org/TheoraDecoders
>> http://wiki.xiph.org/TheoraEncoders
>>
>>
>> - Hervé
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Mon Nov 18 04:43:00 2013
Return-Path: 
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 EE17511E84B4 for ; Mon, 18 Nov 2013 04:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.713
X-Spam-Level: 
X-Spam-Status: No, score=-105.713 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 qyFlh4C35ZQM for ; Mon, 18 Nov 2013 04:42:55 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8E911E849B for ; Mon, 18 Nov 2013 04:42:44 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-c0-528a0b437c9b
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0A.48.03802.34B0A825; Mon, 18 Nov 2013 13:42:43 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.328.9; Mon, 18 Nov 2013 13:42:42 +0100
Message-ID: <528A0B41.2050107@ericsson.com>
Date: Mon, 18 Nov 2013 13:42:41 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Maik Merten , 
References:  <52891EDB.2050607@googlemail.com>
In-Reply-To: <52891EDB.2050607@googlemail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgluLIzCtJLcpLzFFi42KZGfG3VteZuyvI4MFrCYvHzV9YLNb+a2d3 YPJ4OmEyu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKmrpzBVrBNrKLnSG0D4x/BLkZODgkBE4m7 W1YzQ9hiEhfurWfrYuTiEBI4xCgx6cA5VghnOaPE559bgao4OHgFtCW6r5aCNLAIqEoc7rnP AmKzCVhI3PzRyAZiiwoES5x/tZgdxOYVEJQ4OfMJWI2IgJ3Eqg8v2UDGCAtYSlw4bgISFhIo lLjc/BdsOqeAnsTKRWUgpoSAuERPYxBIBTNQdMrVFkYIW16ieetsZohObYmGpg7WCYyCs5Ds moWkZRaSlgWMzKsY2XMTM3PSy402MQJD8eCW36o7GO+cEznEKM3BoiTO++Gtc5CQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGxnXvzB1Y9YxviZ2b2nLAX00/K73inS0rX+r/xM+l4kpnzpYl v39c8dTuKWs0a4PcodMzT+SudBZRVlhomly/wLLIsvWQqgev+ITYhcmSisvCYy6+2LVl6Snb 9cnt2YY5zikh22ZlxE65toLp1+e7F/8r799yS+rBnTVSOoHe/K8q193sstzuqMRSnJFoqMVc VJwIACSv2RcTAgAA
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 12:43:01 -0000

Hi,

I have added this to the list of alternatives proposed.

/Magnus

On 2013-11-17 20:54, Maik Merten wrote:
> Hello,
> 
> just wondering if something like
> 
> "9. All entities SHOULD support both H.264 and VP8. All entities MUST at
> least implement one of those. Entities that do not support both H.264
> and VP8 MUST implement H.261."
> 
> has already popped up. My reasoning is that implementations supporting
> both high performance codecs will always negotiate to use on of those -
> H.261 should never be relevant there.
> 
> It appears that all implementors are willing to implement either H.264
> or VP8 (but not necessarily both). This obviously means that negotiation
> failure regarding a high-performance codec is a possiblity. In this case
> H.261 is actually useful so that basic video calls can still be
> established (for instance, I guess deaf people may always appreciate a
> video connection, as long as sign language can be transmitted).
> 
> 
> Maik
> 
> 
> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>> Hi,
>> Gaining IETF consensus on making it mandatory to support only H.264 or
>> only VP8 has clearly failed. I would welcome anyone to share their
>> thoughts on why they believe this situation will change anytime in the
>> next few years.  Therefore, can I suggest that we remove items 1 and 2
>> from the list. Hopefully this will speed up the process by focusing
>> efforts towards gaining agreement on one of the remaining options.
>> The following alternatives has been proposed:
>>
>>  1. All entities MUST support H.264
>>  2. All entities MUST support VP8
>>  3. All entities MUST support both H.264 and VP8
>>  4. Browsers MUST support both H.264 and VP8, other entities MUST
>>     support at least one of H.264 and VP8
>>  5. All entities MUST support at least one of H.264 and VP8
>>  6. All entities MUST support H.261
>>  7. There is no MTI video codec
>>  8. All entities MUST support H.261 and all entities MUST support at
>>     least one of H.264 and VP8
>>
>> Regards,
>> Jeremy Fuller
>>
>>
>> _______________________________________________
>> 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
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Mon Nov 18 04:45:36 2013
Return-Path: 
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 AC94511E84DA for ; Mon, 18 Nov 2013 04:45:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.772
X-Spam-Level: 
X-Spam-Status: No, score=-105.772 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 n+-7gLGcTlsb for ; Mon, 18 Nov 2013 04:45:31 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD5511E849B for ; Mon, 18 Nov 2013 04:45:16 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-6b-528a0bdb23ad
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 91.73.23787.BDB0A825; Mon, 18 Nov 2013 13:45:15 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.2.328.9; Mon, 18 Nov 2013 13:45:12 +0100
Message-ID: <528A0BD8.1070409@ericsson.com>
Date: Mon, 18 Nov 2013 13:45:12 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: 
References: <5283DFDC.4010906@ericsson.com>
In-Reply-To: <5283DFDC.4010906@ericsson.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvre5t7q4ggyNT1C3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuIfD9kK/opUPHz6krGBcbNAFyMnh4SAicTattUsELaYxIV7 69m6GLk4hAQOMUq8PnSKGcJZzihx5e5NRpAqXgFtidmHP7CB2CwCqhLzO34wg9hsAhYSN380 gsVFBYIlzr9azA5RLyhxcuYTsA0iAqISrx9PY+1i5OAQFrCUuHDcBCQsBDSyfecEsFZOAR2J La8Xs4GUSAiIS/Q0BoGEmQX0JKZcbWGEsOUlmrfOZoZpbWjqYJ3AKDgLybJZSFpmIWlZwMi8 ipE9NzEzJ73ccBMjMPgObvmtu4Px1DmRQ4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQW H2Jk4uCUamAU98up+/g8+iBT6z1HJZHrpxw+fWE4dEN49vs7GU/uf1EI5zJqtH5RJFEyxV/n Vk//bdMaMcY/2Y81+wLC9hn8mNy+ue/On4ezLkxlMbqsPvsQU6pa7wMtUdbyYyVzpbPqnhjb PLt3+fmVrMsXbK3mvGiJuFZ39GGUUMyuu6+PftWavt3zyc9eJZbijERDLeai4kQAYjnDpgwC AAA=
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 12:45:36 -0000

WG,

The current list of proposed alternative are the following one:

 The following alternatives has been proposed:

  1. All entities MUST support H.264
  2. All entities MUST support VP8
  3. All entities MUST support both H.264 and VP8
  4. Browsers MUST support both H.264 and VP8, other entities MUST
     support at least one of H.264 and VP8
  5. All entities MUST support at least one of H.264 and VP8
  6. All entities MUST support H.261
  7. There is no MTI video codec
  8. 5+6, i.e. All entities MUST support H.261 and all entities MUST
     support at least one of H.264 and VP8
  9. All entities MUST support Theora.
 10. All entities SHOULD support both H.264 and VP8. All entities MUST
     at least implement one of those. Entities that do not support both
     H.264 and VP8 MUST implement H.261.

The deadline to propose additional alternatives are: 27th of November 2013

Cheers

Magnus

On 2013-11-13 21:23, Gonzalo Camarillo wrote:
> Folks,
> 
> I hope everybody had a safe trip back home after Vancouver.
> 
> As you all know, we need to make progress regarding the selection of the
> MTI video codec. The following are some of the alternatives we have on
> the table:
> 
>  1. All entities MUST support H.264
>  2. All entities MUST support VP8
>  3. All entities MUST support both H.264 and VP8
>  4. Browsers MUST support both H.264 and VP8
>  5. All entities MUST support either H.264 or VP8
>  6. All entities MUST support H.261
>  7. There is no MTI video codec
> 
> If you want the group to consider additional alternatives to the ones
> above, please let the group know within the following *two weeks*. At
> that point, the chairs will be listing all the received alternatives and
> proposing a process to select one among them.
> 
> Please, send your proposals in an email to the list. You do not need to
> write a draft; just send the text you would like to see in the final
> document regarding video codecs.
> 
> Thanks,
> 
> Gonzalo
> Responsible AD for this WG
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From creslin@digium.com  Mon Nov 18 08:27:45 2013
Return-Path: 
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 5936E11E8145 for ; Mon, 18 Nov 2013 08:27:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 ECrmOtn37huH for ; Mon, 18 Nov 2013 08:27:39 -0800 (PST)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5758311E80F9 for ; Mon, 18 Nov 2013 08:25:55 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id ec20so5108565lab.15 for ; Mon, 18 Nov 2013 08:25:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MbNjVFe8RYRtdsY/2ReNYtgc8f6XhxkMTLK//jfP7HU=; b=jh3kemNf26wtSVO/4++ZpGY4cWH6LT+xKBbXw7dbOueXRGCX4knomviGdQYrJGUenA +HfTIAELU6nraaXAjmsrTfxHWDLxjco2hD3EdBk9Tfb9MyJXksYuwiKTgnOaEzPUIOai ysdrFZK+DWzKU4ap8L5zT94k+2y22gFG9t5XjBR2wpjjejiqZdA3cb+HDlwspYnAwTct 0uvZxFVQXNBFnKlFppEMwr41DP2l4OZNhUpO6yF2c1bvMm1XF2ERZo2vbUmCaAtsRHha rIGVQ7Ou8U0kxBlATZZsOwOdTgaEVGV0fb1AvkXHN5+4q3s3e09hZuYKpt8Nb6bAK6zx jORg==
X-Gm-Message-State: ALoCoQlYHJBS35k6ef8nrPhK36iXvK5vzRFN3eV83AlcTFJGfW6L/cG6+PqjyWqlWmhFFYfOE25J
MIME-Version: 1.0
X-Received: by 10.152.3.42 with SMTP id 10mr15260973laz.22.1384791946684; Mon, 18 Nov 2013 08:25:46 -0800 (PST)
Received: by 10.112.132.102 with HTTP; Mon, 18 Nov 2013 08:25:46 -0800 (PST)
In-Reply-To: <9E34D50A21D1D1489134B4D770CE03976809D9D8@SZXEMA504-MBX.china.huawei.com>
References:  <5645151759529247262@unknownmsgid> <52899BC0.2030909@alvestrand.no> <9E34D50A21D1D1489134B4D770CE03976809D9D8@SZXEMA504-MBX.china.huawei.com>
Date: Mon, 18 Nov 2013 10:25:46 -0600
Message-ID: 
From: Matt Fredrickson 
To: "Chenxin (Xin)" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 16:27:45 -0000

+1

Matthew Fredrickson

On Mon, Nov 18, 2013 at 12:32 AM, Chenxin (Xin)
 wrote:
> +1, to focus on engineering and operational issues too.
>
>
>
>
>
> I suggest to keep it on the main list now. The technical debate on the MTI
> video is enough. We need focus on how to handle this dilemma. I think that
> move the discussion to the sub-list will not be helpful, which should not
> need a long time technical discussion in this stage.
>
>
>
> But I am fine if you think the sub-mailing list is used for the strategy. I
> am just afraid that  moving the discussion will delay the decision on MTI
> because losing focus and so on.
>
>
>
>
>
> Best Regards,
>
>      Xin
>
>
>
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> Harald Alvestrand
> Sent: Monday, November 18, 2013 12:47 PM
> To: rtcweb@ietf.org
>
>
> Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC
> 3929)
>
>
>
> On 11/17/2013 10:43 PM, Varun Singh wrote:
>
> +1, to focus on engineering and operational issues.
>
>
> Since firewall traversal was deemed to be a subject so specialized we
> couldn't debate it on the main list, perhaps we could have an MTI-only
> sublist?
>
> I'll personally commit to reading every message on it, but I suspect there
> are people on this mailing list who would like not to.
>
>
>
> On Nov 14, 2013, at 1:06, Bernard Aboba  wrote:
>
> Keith Drage said:
>
> "Agree
>
>
>
> I am at the point where I would prefer to spend the meeting cycles getting
> things we can agree on, rather than where we seem to be at the moment with
> an issue where there are two clear camps and no real sign of a compromise.
>
>
>
> Ultimately the market will decide (and some parts of it probably have
> already decided - which is probably the reason for no progress).
>
>
>
> Keith"
>
>
>
> [BA] Well said. With most of the RTCWEB WG drafts either having completed
> WGLC or being candidates for WGLC by the end of the year,  with some elbow
> grease it seems very possible to move the bulk of the documents to IETF last
> call within a few months at most.   Polishing the RTCWEB document set would
> yield multiple benefits.  Not only would it get us closer to the goal of
> standardizing the WebRTC protocol stack, but also might well turn up an
> issue or two we haven't thought enough about. Also, once we move the
> protocol stack further along, we'll have more cycles to spend on operational
> issues (like monitoring concerns discussed in XRBLOCK), which currently
> limit the ability to deploy WebRTC at very large scale.   Unfortunately,
> we've been spending so much time on the MTI video codec debate that less
> glamorous (but ultimately much more important) engineering work is being
> neglected.
>
>
>
> This is all by way of seconding your point that there is a real opportunity
> cost to the never-ending, energy sapping MTI codec discussion.  Personally,
> I'd much rather redirect the work of the Internet Engineering Task Force
> RTCWEB WG away from amateur lawyering toward engineering where we actually
> have expertise and could potentially make a difference.
>
> _______________________________________________
> 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
>
>
>
>
> --
>
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

From stewe@stewe.org  Mon Nov 18 08:36:40 2013
Return-Path: 
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 0064211E8100 for ; Mon, 18 Nov 2013 08:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 VHbOX+UyxntI for ; Mon, 18 Nov 2013 08:36:12 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 96DFD11E80E9 for ; Mon, 18 Nov 2013 08:36:07 -0800 (PST)
Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB361.namprd07.prod.outlook.com (10.141.75.19) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 18 Nov 2013 16:35:49 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.99]) with mapi id 15.00.0820.005; Mon, 18 Nov 2013 16:35:49 +0000
From: Stephan Wenger 
To: "rtcweb@ietf.org" 
Thread-Topic: H.263 licensing situation
Thread-Index: AQHO5Hw82CrX2zLKtkCl7+jrUHCjXg==
Date: Mon, 18 Nov 2013 16:35:47 +0000
Message-ID: 
In-Reply-To: <5289CE55.6090004@googlemail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [24.5.171.95]
x-forefront-prvs: 00342DD5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(46102001)(50986001)(47976001)(81686001)(56776001)(80976001)(47736001)(49866001)(56816003)(54316002)(51856001)(74876001)(83322001)(4396001)(83072001)(81542001)(79102001)(77982001)(81342001)(77096001)(69226001)(47446002)(81816001)(36756003)(76796001)(76176001)(76786001)(74366001)(87936001)(74502001)(80022001)(65816001)(31966008)(2656002)(87266001)(74662001)(85306002)(53806001)(76482001)(63696002)(59766001)(54356001)(66066001)(74706001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB361; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:24.5.171.95; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en; 
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <993004F30483EE49B48A471DACE17FC0@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: [rtcweb] H.263 licensing situation
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 16:36:40 -0000

Hi,

Here is what I know or suspect regarding H.263 licensing:

Know:=20

Leon is correct, there are type 2 patent declarations in the ITU against
H.263.

Maik is also correct, H.263 baseline is a subset of MPEG-4 part 2.  MPEG-4
part 2 is generally considered royalty bearing and the license has been
enforced.  However, very few (no one?) is using strict H.263 baseline, and
even for an only slightly more advanced use of H.263 (no need to go to
H.263+, for example), the MPEG-4 portfolio license would not apply.

H.263 has been the predominant codec in the video conferencing industry
for close to a decade (ca. 1996 through ca. 2005).  In all this time, I
have heard of one single instance of patent assertion by a non-troll
against several of the large video conferencing vendors.  However, since
those vendors all used a chip produced by the non-troll, they had enough
commercial leverage to fend off those assertions without the dispute ever
going to trial and, so I hear, without paying any premium for the use of
the patent.   The patent in question has now expired.

H.263 baseline is insufficient for rtcweb=B9s purposes, as it does not allo=
w
arbitrary picture sizes.  You want to have at least the PLUSPTYPE picture
header extension which allows arbitrary picture sizes.  You also probably
want a few of the optional modes, especially the bug-fixes (improved VLC)
and the deblocking filter.  Patents related to this technologies are not
covered under the MPEG-LA MPEG-4 part 2 license.

Suspect:

Since we would most likely not use strict H.263 baseline, the war-chest of
the MPEG-LA pool cannot be used to enforce a patent against our
hypothetical H.263 implementation because it is not MPEG-4 part 2
compliant.  Which, in turn, means that the MPEG-4 part 2 rightholders
would be on their own in asserting their patents.  Which, in turn, means
that there is no difference between H.263 and other non-pooled video
codecs from an MPEG-LA related risk assessment.
 =20

There have been patent assertions by trolls allegedly related to video
compression in general and H.263 in particular, but those happen all the
time and there is not much one can do about them.  Once you are a juicy
enough target (based on the troll=B9s perception of relationship between
your legal competence versus your size) the troll will find you.
Technicalities such as whether the patent is actually infringed or related
to standards are secondary at best in the eye of a troll.  Their business,
at least when going against smaller companies, is to settle for a few
hundreds of thousands--an amount the alleged infringer can pay without
excessive hurt--thereby filling their war chest and then go to the next
=B3customer=B2.  When they meet determined opposition (based on a combinati=
on
of legal and technical competence), they often move on to greener pastures.

As H.263 is fairly widely deployed, and I have not heard about patent
assertions except the cases mentioned above, the risk of a successful
patent assertion is probably manageable for almost everyone with
sufficient legal resources.  At least in countries that allow equitable
defenses (implied license, laches, estoppel).

So is it worth evaluating H.263 further?  IMO, probably not.  It=B9s
doubtless technically better than H.261, but the risk is inproportionally
higher.  And the whole idea of this substandard baseline codec has been to
be essentially without risk.

Stephan


>


From cowwoc@bbs.darktech.org  Mon Nov 18 08:48:39 2013
Return-Path: 
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 9863111E811A for ; Mon, 18 Nov 2013 08:48:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.565
X-Spam-Level: 
X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.034,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 5AHRgKvb3RRL for ; Mon, 18 Nov 2013 08:48:34 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3379711E81CB for ; Mon, 18 Nov 2013 08:45:22 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id to1so9468282ieb.3 for ; Mon, 18 Nov 2013 08:45:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oXQfgVs/7fKxYtSLUs+xvjMAkIYz7MeJffkKyh1jtZs=; b=O/alWggFyeEbrBa7EZ/svYrXyi4HcE9e2dLptdKMCZVgjUwohyrnOJIsmtafz0l2BK cwkzTghFJDLwVTHATG7qoBe6SxZ1jwQhVLhuowht6oB4IaYCPdK80zrrFViMO1t2/WZE DPdNw0GsgoZfc+hItyg1lDkQq03npPe4fVvJ4tEkozeSycqhbQI2yiEHnavYF7ZtMLWK jRH16TLhBJslad2j6pvOGrJLS19Dby3exsteqbhdif2MfWa3ANJNrrUGWNp7YSTnYwKJ 8pLoP8NE0zdPMLaa+L4zhaEFTRYznwGO50/rY2Oxi5VsbFAOCsX/XBc6TgTuZDuFX1YN TqHw==
X-Gm-Message-State: ALoCoQklDxko3oYJv2MS0epFeQAqw4hVxnCCWZI5ov1la7lY42XlbNnnOirDiomEJAtK3KJW24Je
X-Received: by 10.50.124.133 with SMTP id mi5mr9414016igb.57.1384793121473; Mon, 18 Nov 2013 08:45:21 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ri5sm9543675igc.1.2013.11.18.08.45.19 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 08:45:20 -0800 (PST)
Message-ID: <528A4408.50105@bbs.darktech.org>
Date: Mon, 18 Nov 2013 11:44:56 -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: rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com> <528A0BD8.1070409@ericsson.com>
In-Reply-To: <528A0BD8.1070409@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 16:48:39 -0000

Looks good! I'd like to get a clarification which affects multiple 
options, but #10 most of all.

Does the WG commit to providing reference implementations that supports 
VP8, H.264, H.261 with a commercially-friendly license? I am talking 
strictly about the software license, not the codec IPR. Meaning, libx264 
requires a GPL license and ffmpeg requires either a LGPL or GPL license. 
I would argue that libx264 is a non-starter for commercial use on any 
platform (due to GPL) and ffmpeg is not usable under iOS (since LGPL + 
static linking is equivalent to GPL). It is my understanding that the 
current WebRTC reference implementation is published under the BSD 
license. I am asking for the final reference implementation (supporting 
these codecs) to be published under the same license.

I'm not saying that anyone has to ship a reference implementation 
supporting all 3 codecs, but rather that the WG should publish a 
reference implementation demonstrating how it can be done and proving 
interoperability actually works as expected.

Thanks,
Gili

On 18/11/2013 7:45 AM, Magnus Westerlund wrote:
> WG,
>
> The current list of proposed alternative are the following one:
>
>   The following alternatives has been proposed:
>
>    1. All entities MUST support H.264
>    2. All entities MUST support VP8
>    3. All entities MUST support both H.264 and VP8
>    4. Browsers MUST support both H.264 and VP8, other entities MUST
>       support at least one of H.264 and VP8
>    5. All entities MUST support at least one of H.264 and VP8
>    6. All entities MUST support H.261
>    7. There is no MTI video codec
>    8. 5+6, i.e. All entities MUST support H.261 and all entities MUST
>       support at least one of H.264 and VP8
>    9. All entities MUST support Theora.
>   10. All entities SHOULD support both H.264 and VP8. All entities MUST
>       at least implement one of those. Entities that do not support both
>       H.264 and VP8 MUST implement H.261.
>
> The deadline to propose additional alternatives are: 27th of November 2013
>
> Cheers
>
> Magnus
>
> On 2013-11-13 21:23, Gonzalo Camarillo wrote:
>> Folks,
>>
>> I hope everybody had a safe trip back home after Vancouver.
>>
>> As you all know, we need to make progress regarding the selection of the
>> MTI video codec. The following are some of the alternatives we have on
>> the table:
>>
>>   1. All entities MUST support H.264
>>   2. All entities MUST support VP8
>>   3. All entities MUST support both H.264 and VP8
>>   4. Browsers MUST support both H.264 and VP8
>>   5. All entities MUST support either H.264 or VP8
>>   6. All entities MUST support H.261
>>   7. There is no MTI video codec
>>
>> If you want the group to consider additional alternatives to the ones
>> above, please let the group know within the following *two weeks*. At
>> that point, the chairs will be listing all the received alternatives and
>> proposing a process to select one among them.
>>
>> Please, send your proposals in an email to the list. You do not need to
>> write a draft; just send the text you would like to see in the final
>> document regarding video codecs.
>>
>> Thanks,
>>
>> Gonzalo
>> Responsible AD for this WG
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>


From dromasca@avaya.com  Mon Nov 18 08:48:49 2013
Return-Path: 
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 5A3F011E81C6; Mon, 18 Nov 2013 08:48:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 5HkRvYzBmzTD; Mon, 18 Nov 2013 08:48:39 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5026C11E817E; Mon, 18 Nov 2013 08:45:30 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmAGACdDilLGmAcV/2dsb2JhbABZgmYhgQu/NoEcFm0HgicBAQMSKD8SARUVFEImAQQODRqHXwGlZpx9jzgxgyeBEQOedosngyiCKg
X-IronPort-AV: E=Sophos;i="4.93,724,1378872000"; d="scan'208";a="37280283"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Nov 2013 11:45:29 -0500
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Nov 2013 11:39:13 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Mon, 18 Nov 2013 17:45:28 +0100
From: "Romascanu, Dan (Dan)" 
To: "pm-dir@ietf.org" 
Thread-Topic: PM-DIR review of draft-ietf-rtcweb-rtp-usage-10
Thread-Index: Ac7kfZXgBPXNkVKoRnSjO64aLIqIrw==
Date: Mon, 18 Nov 2013 16:45:28 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1293FC7D@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.46]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: [rtcweb] PM-DIR review of draft-ietf-rtcweb-rtp-usage-10
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 16:48:49 -0000

This is the PM-DIR review of draft-ietf-rtcweb-rtp-usage-10. I am the assig=
ned PM-DIR reviewer for this I-D.=20

This Internet-Draft defines the media transport aspects and provides the de=
tails of the RTP usage in WebRTC - specifically the requirements for which =
RTP features, profiles and extensions need to be supported in WebRTC.=20

The I-D does not define performance metrics, so a 6390 review does not appl=
y.=20

The I-D includes a short section (section 8) dedicated to 'WebRTC Use of RT=
P: Performance Monitoring'. I am fine with the content of this section with=
 two comments:=20

1.=20
>  It is not yet clear
   what extended metrics are appropriate for use in the WebRTC context,
   so implementations are not expected to generate any RTCP XR packets.

I believe that it would be more appropriate to replace ' implementations ar=
e not expected ' by ' implementations are not required '

2.=20
>  A large number of additional performance metrics are supported by the
   RTCP Extended Reports (XR) framework [RFC3611]. =20

I think that mentioning 3611 only is limiting nowadays and that RFC 6792 sh=
ould be mentioned as well.

Regards,

Dan


From maikmerten@googlemail.com  Mon Nov 18 09:16:11 2013
Return-Path: 
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 2287111E81BA for ; Mon, 18 Nov 2013 09:16:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.276
X-Spam-Level: 
X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323,  BAYES_00=-2.599]
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 y2GNdr5qufqL for ; Mon, 18 Nov 2013 09:16:10 -0800 (PST)
Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5EC11E81C7 for ; Mon, 18 Nov 2013 09:14:51 -0800 (PST)
Received: by mail-bk0-f47.google.com with SMTP id mx12so1009522bkb.34 for ; Mon, 18 Nov 2013 09:14:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fxZuSC5Ftg5QB2r1nMVzhUdBS5L9L2qfAX2jaDZZIik=; b=dHzs+HViJNAZSIYDNl6NFDncUSQnjDqZMKY3/OcmYXIbFpRV0AS2Edtm7bjhbyL2Ft ofLADVxZaqu2zqZZviWfHLCC6FTuDCVH+dUHL/QaRjz0EDs5pkZdCsfZm+ZuFtpU9B/v fnLDvoQSbJ0wxN1UODHdXYN9dqshUWoFnKM/3nSj+GJja0ITiqkgNmCci+1B9FTSj3n+ 3zu0Ng2lXhakKUj81jOVKqYhMGuQZjS8GKCgo7dshCUVFbMBaXb+BnOaPH1gkIAsu3b9 7kFYCZELfRIPAHpbLrwexU2VDIp+jp5DU1pfwpaKOK3sRgwFHwa7p2jjM36Yoy3PiKxi ma+Q==
X-Received: by 10.204.69.12 with SMTP id x12mr12873659bki.12.1384794891001; Mon, 18 Nov 2013 09:14:51 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id zl3sm17353710bkb.4.2013.11.18.09.14.48 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 09:14:49 -0800 (PST)
Message-ID: <528A4B07.7010104@googlemail.com>
Date: Mon, 18 Nov 2013 18:14:47 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com> <528A0BD8.1070409@ericsson.com> <528A4408.50105@bbs.darktech.org>
In-Reply-To: <528A4408.50105@bbs.darktech.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 17:16:11 -0000

Regarding H.261, apart from ffmpeg there's also a maintained 
implementation over at

http://sourceforge.net/p/opalvoip/code/29319/tree/opal/trunk/plugins/video/H.261-vic/h261vic.cxx

which is covered by the Mozilla Public License 1.0 
(http://www.mozilla.org/MPL/1.0/).

"3.7. Larger Works.
You may create a Larger Work by combining Covered Code with other code 
not governed by the terms of this License and distribute the Larger Work 
as a single product. In such a case, You must make sure the requirements 
of this License are fulfilled for the Covered Code."

The H.261 *en*coder of that project looks rather primitive (only 
generating I-frames), but the *de*coder should be feature-complete. 
Perhaps that's something to build upon.

I would also suspect that complete and battle-tested implementations 
gather dust at some vendors of telco stuff, but nobody seems to have 
open sourced one.



Maik


Am 18.11.2013 17:44, schrieb cowwoc:
>
> Looks good! I'd like to get a clarification which affects multiple
> options, but #10 most of all.
>
> Does the WG commit to providing reference implementations that supports
> VP8, H.264, H.261 with a commercially-friendly license? I am talking
> strictly about the software license, not the codec IPR. Meaning, libx264
> requires a GPL license and ffmpeg requires either a LGPL or GPL license.
> I would argue that libx264 is a non-starter for commercial use on any
> platform (due to GPL) and ffmpeg is not usable under iOS (since LGPL +
> static linking is equivalent to GPL). It is my understanding that the
> current WebRTC reference implementation is published under the BSD
> license. I am asking for the final reference implementation (supporting
> these codecs) to be published under the same license.
>
> I'm not saying that anyone has to ship a reference implementation
> supporting all 3 codecs, but rather that the WG should publish a
> reference implementation demonstrating how it can be done and proving
> interoperability actually works as expected.
>
> Thanks,
> Gili
>
> On 18/11/2013 7:45 AM, Magnus Westerlund wrote:
>> WG,
>>
>> The current list of proposed alternative are the following one:
>>
>>   The following alternatives has been proposed:
>>
>>    1. All entities MUST support H.264
>>    2. All entities MUST support VP8
>>    3. All entities MUST support both H.264 and VP8
>>    4. Browsers MUST support both H.264 and VP8, other entities MUST
>>       support at least one of H.264 and VP8
>>    5. All entities MUST support at least one of H.264 and VP8
>>    6. All entities MUST support H.261
>>    7. There is no MTI video codec
>>    8. 5+6, i.e. All entities MUST support H.261 and all entities MUST
>>       support at least one of H.264 and VP8
>>    9. All entities MUST support Theora.
>>   10. All entities SHOULD support both H.264 and VP8. All entities MUST
>>       at least implement one of those. Entities that do not support both
>>       H.264 and VP8 MUST implement H.261.
>>
>> The deadline to propose additional alternatives are: 27th of November
>> 2013
>>
>> Cheers
>>
>> Magnus
>>
>> On 2013-11-13 21:23, Gonzalo Camarillo wrote:
>>> Folks,
>>>
>>> I hope everybody had a safe trip back home after Vancouver.
>>>
>>> As you all know, we need to make progress regarding the selection of the
>>> MTI video codec. The following are some of the alternatives we have on
>>> the table:
>>>
>>>   1. All entities MUST support H.264
>>>   2. All entities MUST support VP8
>>>   3. All entities MUST support both H.264 and VP8
>>>   4. Browsers MUST support both H.264 and VP8
>>>   5. All entities MUST support either H.264 or VP8
>>>   6. All entities MUST support H.261
>>>   7. There is no MTI video codec
>>>
>>> If you want the group to consider additional alternatives to the ones
>>> above, please let the group know within the following *two weeks*. At
>>> that point, the chairs will be listing all the received alternatives and
>>> proposing a process to select one among them.
>>>
>>> Please, send your proposals in an email to the list. You do not need to
>>> write a draft; just send the text you would like to see in the final
>>> document regarding video codecs.
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>> Responsible AD for this WG
>>>
>>> _______________________________________________
>>> 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


From cowwoc@bbs.darktech.org  Mon Nov 18 09:45:40 2013
Return-Path: 
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 E325C11E819A for ; Mon, 18 Nov 2013 09:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.569
X-Spam-Level: 
X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 6dFNScFNa+-u for ; Mon, 18 Nov 2013 09:45:35 -0800 (PST)
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id BED0E11E81DE for ; Mon, 18 Nov 2013 09:38:40 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id ar20so2899711iec.2 for ; Mon, 18 Nov 2013 09:38:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RlLtf764SxcpebLLtGVYt8HITkxaW+V86EWb1R//9dU=; b=Vc3rn3IIa/7D4gkJErQHolvS2dswpgHblLDz4EMaxW97RUAAPrFSYNwfh75MGmvnQb blBTEY5/bH8ESYCj0ezoNYri2gPMsV9iasgoucCfFOTWGqOYaFJNKD2a2i3ilGqLN9LX LRmmFQGRGslZn28sPAV8slPeCs99g/WX7XOh8v7rvcYt+wWOMjxnAFQbImaRASL/d1nV iVmp6qNmPDREyBbuea9D12VANC4n2u/SKHCUjn0PEdSueuP2s8asNuAMMm6Vs8CR4rZd Oinrfggum8lcn5dFb6yntsvGmhQt2G/BmAQhaxSP1t0WxL8aNJQ5nXzfeuG8OkkE9N9Q 9UUw==
X-Gm-Message-State: ALoCoQnGOaNhpeBcKTGBA6LzOEibKwmP50vYygTc6nzY5m+M5lbTec5vuGGLYCSpIGbMY3YyEdA4
X-Received: by 10.50.26.36 with SMTP id i4mr15442765igg.33.1384796320102; Mon, 18 Nov 2013 09:38:40 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ri5sm9787564igc.1.2013.11.18.09.38.38 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 09:38:39 -0800 (PST)
Message-ID: <528A5087.1020304@bbs.darktech.org>
Date: Mon, 18 Nov 2013 12:38:15 -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: rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com> <528A0BD8.1070409@ericsson.com>	<528A4408.50105@bbs.darktech.org> <528A4B07.7010104@googlemail.com>
In-Reply-To: <528A4B07.7010104@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Reference implementation of software codecs (was: Video codec selection - way forward)
X-BeenThere: rtcweb@ietf.org
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: Mon, 18 Nov 2013 17:45:40 -0000
X-List-Received-Date: Mon, 18 Nov 2013 17:45:40 -0000

Okay, so I believe this is an open issue. I've changed the topic to 
avoid hijacking the old thread.

Gili

On 18/11/2013 12:14 PM, Maik Merten wrote:
> Regarding H.261, apart from ffmpeg there's also a maintained 
> implementation over at
>
> http://sourceforge.net/p/opalvoip/code/29319/tree/opal/trunk/plugins/video/H.261-vic/h261vic.cxx 
>
>
> which is covered by the Mozilla Public License 1.0 
> (http://www.mozilla.org/MPL/1.0/).
>
> "3.7. Larger Works.
> You may create a Larger Work by combining Covered Code with other code 
> not governed by the terms of this License and distribute the Larger 
> Work as a single product. In such a case, You must make sure the 
> requirements of this License are fulfilled for the Covered Code."
>
> The H.261 *en*coder of that project looks rather primitive (only 
> generating I-frames), but the *de*coder should be feature-complete. 
> Perhaps that's something to build upon.
>
> I would also suspect that complete and battle-tested implementations 
> gather dust at some vendors of telco stuff, but nobody seems to have 
> open sourced one.
>
>
>
> Maik
>
>
> Am 18.11.2013 17:44, schrieb cowwoc:
>>
>> Looks good! I'd like to get a clarification which affects multiple
>> options, but #10 most of all.
>>
>> Does the WG commit to providing reference implementations that supports
>> VP8, H.264, H.261 with a commercially-friendly license? I am talking
>> strictly about the software license, not the codec IPR. Meaning, libx264
>> requires a GPL license and ffmpeg requires either a LGPL or GPL license.
>> I would argue that libx264 is a non-starter for commercial use on any
>> platform (due to GPL) and ffmpeg is not usable under iOS (since LGPL +
>> static linking is equivalent to GPL). It is my understanding that the
>> current WebRTC reference implementation is published under the BSD
>> license. I am asking for the final reference implementation (supporting
>> these codecs) to be published under the same license.
>>
>> I'm not saying that anyone has to ship a reference implementation
>> supporting all 3 codecs, but rather that the WG should publish a
>> reference implementation demonstrating how it can be done and proving
>> interoperability actually works as expected.
>>
>> Thanks,
>> Gili
>>
>> On 18/11/2013 7:45 AM, Magnus Westerlund wrote:
>>> WG,
>>>
>>> The current list of proposed alternative are the following one:
>>>
>>>   The following alternatives has been proposed:
>>>
>>>    1. All entities MUST support H.264
>>>    2. All entities MUST support VP8
>>>    3. All entities MUST support both H.264 and VP8
>>>    4. Browsers MUST support both H.264 and VP8, other entities MUST
>>>       support at least one of H.264 and VP8
>>>    5. All entities MUST support at least one of H.264 and VP8
>>>    6. All entities MUST support H.261
>>>    7. There is no MTI video codec
>>>    8. 5+6, i.e. All entities MUST support H.261 and all entities MUST
>>>       support at least one of H.264 and VP8
>>>    9. All entities MUST support Theora.
>>>   10. All entities SHOULD support both H.264 and VP8. All entities MUST
>>>       at least implement one of those. Entities that do not support 
>>> both
>>>       H.264 and VP8 MUST implement H.261.
>>>
>>> The deadline to propose additional alternatives are: 27th of November
>>> 2013
>>>
>>> Cheers
>>>
>>> Magnus
>>>
>>> On 2013-11-13 21:23, Gonzalo Camarillo wrote:
>>>> Folks,
>>>>
>>>> I hope everybody had a safe trip back home after Vancouver.
>>>>
>>>> As you all know, we need to make progress regarding the selection 
>>>> of the
>>>> MTI video codec. The following are some of the alternatives we have on
>>>> the table:
>>>>
>>>>   1. All entities MUST support H.264
>>>>   2. All entities MUST support VP8
>>>>   3. All entities MUST support both H.264 and VP8
>>>>   4. Browsers MUST support both H.264 and VP8
>>>>   5. All entities MUST support either H.264 or VP8
>>>>   6. All entities MUST support H.261
>>>>   7. There is no MTI video codec
>>>>
>>>> If you want the group to consider additional alternatives to the ones
>>>> above, please let the group know within the following *two weeks*. At
>>>> that point, the chairs will be listing all the received 
>>>> alternatives and
>>>> proposing a process to select one among them.
>>>>
>>>> Please, send your proposals in an email to the list. You do not 
>>>> need to
>>>> write a draft; just send the text you would like to see in the final
>>>> document regarding video codecs.
>>>>
>>>> Thanks,
>>>>
>>>> Gonzalo
>>>> Responsible AD for this WG
>>>>
>>>> _______________________________________________
>>>> 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


From cowwoc@bbs.darktech.org  Mon Nov 18 10:39:21 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1451A1F4F for ; Mon, 18 Nov 2013 10:39:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZz0C4DE56Fz for ; Mon, 18 Nov 2013 10:39:18 -0800 (PST)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8371A1F48 for ; Mon, 18 Nov 2013 10:39:15 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id u16so9008832iet.6 for ; Mon, 18 Nov 2013 10:39:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=x3j0Esor0TZLFVAcVMCeMOmx4O3/rGZ3U+xtOwlcxfA=; b=fDMFNzi/egxNa+bknlMfpWYjrBGy+WEpKYoMcv3BBtbFJYcV4tpaeV44eJ5rznf+JD TyFe1LJ0tgsF6SMZa+sb6MtwdomOFCrQxzfyOnpwX+UEeAb0Vlu0N/mi/DFDLxVQP47x SDWZsZWs8OrFpJcRaq2rNruODOjmtUPEoA4I25EAaFmS9ZsXqXTOWF6F2ICG5rvWsBPy p+2ZJrwqmGqhYmj9ov5gytBH8tUQW16Ugi97oYrah2kHiwD3bjAoBWuDPV4bD/v7zRU2 hVvR8i5gaVfQo6pBMeVhUhDZxBzPqqNHVGioPLooURospw0WYVCu0FcLCv2xpsgYkrDD +Uhg==
X-Gm-Message-State: ALoCoQnk9zibVnOuDyscaEqAYoVcWg2uMg5ZeHMfw3yA5R2p1S/TUcuPpiHNKfRRuD2biCsYXnfK
X-Received: by 10.50.55.106 with SMTP id r10mr15588199igp.45.1384799949545; Mon, 18 Nov 2013 10:39:09 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id jk5sm14935453igb.0.2013.11.18.10.39.07 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 10:39:08 -0800 (PST)
Message-ID: <528A5EB4.2010308@bbs.darktech.org>
Date: Mon, 18 Nov 2013 13:38:44 -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: "rtcweb@ietf.org" 
References: <5283DFDC.4010906@ericsson.com> <528A0BD8.1070409@ericsson.com> <528A4408.50105@bbs.darktech.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000208060003000802020005"
Subject: Re: [rtcweb] Reference implementation of software codecs (was: Video codec selection - way forward)
X-BeenThere: rtcweb@ietf.org
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, 18 Nov 2013 18:39:21 -0000

This is a multi-part message in MIME format.
--------------000208060003000802020005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Could the chairs comment on this? Is this the WG's position? (Do you 
need more time to think this over?)

I ask because this would affect which option we'd vote for.

Thanks,
Gili

On 18/11/2013 12:58 PM, Eric Rescorla wrote:
> On Mon, Nov 18, 2013 at 8:44 AM, cowwoc  > wrote:
>
>
>     Looks good! I'd like to get a clarification which affects multiple
>     options, but #10 most of all.
>
>     Does the WG commit to providing reference implementations that
>     supports VP8, H.264, H.261 with a commercially-friendly license? I
>     am talking strictly about the software license, not the codec IPR.
>     Meaning, libx264 requires a GPL license and ffmpeg requires either
>     a LGPL or GPL license. I would argue that libx264 is a non-starter
>     for commercial use on any platform (due to GPL) and ffmpeg is not
>     usable under iOS (since LGPL + static linking is equivalent to
>     GPL). It is my understanding that the current WebRTC reference
>     implementation is published under the BSD license. I am asking for
>     the final reference implementation (supporting these codecs) to be
>     published under the same license.
>
>     I'm not saying that anyone has to ship a reference implementation
>     supporting all 3 codecs, but rather that the WG should publish a
>     reference implementation demonstrating how it can be done and
>     proving interoperability actually works as expected.
>
>
> Huh?
>
> IETF WGs almost never provide reference implementations. Given the 
> scale of the effort and the
> state of the existing implementations, I can't imagine why would do
> so in this case.
>
> -Ekr
>
>
>     Thanks,
>     Gili
>
>
>     On 18/11/2013 7:45 AM, Magnus Westerlund wrote:
>
>         WG,
>
>         The current list of proposed alternative are the following one:
>
>           The following alternatives has been proposed:
>
>            1. All entities MUST support H.264
>            2. All entities MUST support VP8
>            3. All entities MUST support both H.264 and VP8
>            4. Browsers MUST support both H.264 and VP8, other entities
>         MUST
>               support at least one of H.264 and VP8
>            5. All entities MUST support at least one of H.264 and VP8
>            6. All entities MUST support H.261
>            7. There is no MTI video codec
>            8. 5+6, i.e. All entities MUST support H.261 and all
>         entities MUST
>               support at least one of H.264 and VP8
>            9. All entities MUST support Theora.
>           10. All entities SHOULD support both H.264 and VP8. All
>         entities MUST
>               at least implement one of those. Entities that do not
>         support both
>               H.264 and VP8 MUST implement H.261.
>
>         The deadline to propose additional alternatives are: 27th of
>         November 2013
>
>         Cheers
>
>         Magnus
>
>         On 2013-11-13 21:23, Gonzalo Camarillo wrote:
>
>             Folks,
>
>             I hope everybody had a safe trip back home after Vancouver.
>
>             As you all know, we need to make progress regarding the
>             selection of the
>             MTI video codec. The following are some of the
>             alternatives we have on
>             the table:
>
>               1. All entities MUST support H.264
>               2. All entities MUST support VP8
>               3. All entities MUST support both H.264 and VP8
>               4. Browsers MUST support both H.264 and VP8
>               5. All entities MUST support either H.264 or VP8
>               6. All entities MUST support H.261
>               7. There is no MTI video codec
>
>             If you want the group to consider additional alternatives
>             to the ones
>             above, please let the group know within the following *two
>             weeks*. At
>             that point, the chairs will be listing all the received
>             alternatives and
>             proposing a process to select one among them.
>
>             Please, send your proposals in an email to the list. You
>             do not need to
>             write a draft; just send the text you would like to see in
>             the final
>             document regarding video codecs.
>
>             Thanks,
>
>             Gonzalo
>             Responsible AD for this WG
>
>             _______________________________________________
>             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
>
>


--------------000208060003000802020005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
      Could the chairs comment on this? Is this the WG's position? (Do
      you need more time to think this over?)
    
      
    
      I ask because this would affect which option we'd vote for.
    
      
    
      Thanks,
    
      Gili
    
      
    
      On 18/11/2013 12:58 PM, Eric Rescorla wrote:
    
    
    
    
    
      
    On Mon, Nov 18, 2013 at 8:44 AM, cowwoc <cowwoc@bbs.darktech.org>
        wrote:
    
        
    
          
    
            

    
              Looks good! I'd like to get a clarification which affects
              multiple options, but #10 most of all.
    
              
    
              Does the WG commit to providing reference implementations
              that supports VP8, H.264, H.261 with a
              commercially-friendly license? I am talking strictly about
              the software license, not the codec IPR. Meaning, libx264
              requires a GPL license and ffmpeg requires either a LGPL
              or GPL license. I would argue that libx264 is a
              non-starter for commercial use on any platform (due to
              GPL) and ffmpeg is not usable under iOS (since LGPL +
              static linking is equivalent to GPL). It is my
              understanding that the current WebRTC reference
              implementation is published under the BSD license. I am
              asking for the final reference implementation (supporting
              these codecs) to be published under the same license.
    
              
    
              I'm not saying that anyone has to ship a reference
              implementation supporting all 3 codecs, but rather that
              the WG should publish a reference implementation
              demonstrating how it can be done and proving
              interoperability actually works as expected.
    
            
    
            

    
            
    
            
    Huh?
    
            

    
            
    
            
    IETF WGs almost never provide reference
              implementations. Given the scale of the effort and the
    
            
    state of the existing implementations, I can't imagine
              why would do
    
            
    so in this case.
    
            

    
            
    
            
    -Ekr
    
            

    
            
    
            

    
            
    
            
    
              Thanks,
    
              Gili
              
    
                

    
                  
    
                  On 18/11/2013 7:45 AM, Magnus Westerlund wrote:
    
                  
    
                    WG,
    
                    
    
                    The current list of proposed alternative are the
                    following one:
    
                    
    
                      The following alternatives has been proposed:
    
                    
    
                       1. All entities MUST support H.264
    
                       2. All entities MUST support VP8
    
                       3. All entities MUST support both H.264 and VP8
    
                       4. Browsers MUST support both H.264 and VP8,
                    other entities MUST
    
                          support at least one of H.264 and VP8
    
                       5. All entities MUST support at least one of
                    H.264 and VP8
    
                       6. All entities MUST support H.261
    
                       7. There is no MTI video codec
    
                       8. 5+6, i.e. All entities MUST support H.261 and
                    all entities MUST
    
                          support at least one of H.264 and VP8
    
                       9. All entities MUST support Theora.
    
                      10. All entities SHOULD support both H.264 and
                    VP8. All entities MUST
    
                          at least implement one of those. Entities that
                    do not support both
    
                          H.264 and VP8 MUST implement H.261.
    
                    
    
                    The deadline to propose additional alternatives are:
                    27th of November 2013
    
                    
    
                    Cheers
    
                    
    
                    Magnus
    
                    
    
                    On 2013-11-13 21:23, Gonzalo Camarillo wrote:
    
                    
    
                      Folks,
    
                      
    
                      I hope everybody had a safe trip back home after
                      Vancouver.
    
                      
    
                      As you all know, we need to make progress
                      regarding the selection of the
    
                      MTI video codec. The following are some of the
                      alternatives we have on
    
                      the table:
    
                      
    
                        1. All entities MUST support H.264
    
                        2. All entities MUST support VP8
    
                        3. All entities MUST support both H.264 and VP8
    
                        4. Browsers MUST support both H.264 and VP8
    
                        5. All entities MUST support either H.264 or VP8
    
                        6. All entities MUST support H.261
    
                        7. There is no MTI video codec
    
                      
    
                      If you want the group to consider additional
                      alternatives to the ones
    
                      above, please let the group know within the
                      following *two weeks*. At
    
                      that point, the chairs will be listing all the
                      received alternatives and
    
                      proposing a process to select one among them.
    
                      
    
                      Please, send your proposals in an email to the
                      list. You do not need to
    
                      write a draft; just send the text you would like
                      to see in the final
    
                      document regarding video codecs.
    
                      
    
                      Thanks,
    
                      
    
                      Gonzalo
    
                      Responsible AD for this WG
    
                      
    
                      _______________________________________________
    
                      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
    
                
    
              
    
            
    
          
    
          
    
        
    
      
    
    
    
    
    
  


--------------000208060003000802020005--

From maikmerten@googlemail.com  Mon Nov 18 11:12:34 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847871ADF6B for ; Mon, 18 Nov 2013 11:12:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJd-xnoDwX1e for ; Mon, 18 Nov 2013 11:12:32 -0800 (PST)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1B45B1AC4A3 for ; Mon, 18 Nov 2013 11:12:31 -0800 (PST)
Received: by mail-bk0-f50.google.com with SMTP id e11so1318748bkh.23 for ; Mon, 18 Nov 2013 11:12:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=P4gyLRV3cSh3UPT3ByOrpMar7QNEotRfblRn6NB3Kz8=; b=y7TU5hMB/d+MN83WsXkI6EcPB+pRH2mKYFQQivgrh9pLPbNUuCCCOaGsEGWTC5gNB8 gyW3WgFnebQV2OHDAwXuqEKmOD1XtDXl2pCbzeb+0MDWG6DIuoZ5hBv3dpv4GmVuryIC kXayKUwlvXnzCJl6e8IQQwTVQ8prmQvd9WUM1ld7t1I1J4lYxkc5PABdtvUC5e+G86qq VkLmzQ5Rz1yhDHHw4En//cqiP3wew3snfr4vrxGN+sKSpqAT7V1NrS4DnTAl1hU+4eS0 KCHY+R1e4mKeRiLDoIfA06KVPEPMugB+mNPsdkLsYl1FqBxU+OVaeRF7giOOa54uTGXq Akmw==
X-Received: by 10.205.22.71 with SMTP id qv7mr13455593bkb.20.1384801945819; Mon, 18 Nov 2013 11:12:25 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id pk7sm17709321bkb.2.2013.11.18.11.12.23 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 11:12:24 -0800 (PST)
Message-ID: <528A6696.8060404@googlemail.com>
Date: Mon, 18 Nov 2013 20:12:22 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com>	<528A0BD8.1070409@ericsson.com>	<528A4408.50105@bbs.darktech.org>	<528A4B07.7010104@googlemail.com> <528A5087.1020304@bbs.darktech.org>
In-Reply-To: <528A5087.1020304@bbs.darktech.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Reference implementation of software codecs
X-BeenThere: rtcweb@ietf.org
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, 18 Nov 2013 19:12:34 -0000

FWIW, I think I found a BSD-stlye H.261 implementation, which appears to 
include contributions from Cisco:

http://mpeg4ip.cvs.sourceforge.net/viewvc/mpeg4ip/mpeg4ip/server/mp4live/h261/encoder-h261.cpp?revision=1.12&view=markup

A BSD-style implementation thus wouldn't have to start from scratch, 
albeit some extensive massaging may be needed to plug it into a WebRTC 
context.


Maik


Am 18.11.2013 18:38, schrieb cowwoc:
>
> Okay, so I believe this is an open issue. I've changed the topic to
> avoid hijacking the old thread.
>
> Gili
>
> On 18/11/2013 12:14 PM, Maik Merten wrote:
>> Regarding H.261, apart from ffmpeg there's also a maintained
>> implementation over at
>>
>> http://sourceforge.net/p/opalvoip/code/29319/tree/opal/trunk/plugins/video/H.261-vic/h261vic.cxx
>>
>>
>> which is covered by the Mozilla Public License 1.0
>> (http://www.mozilla.org/MPL/1.0/).
>>
>> "3.7. Larger Works.
>> You may create a Larger Work by combining Covered Code with other code
>> not governed by the terms of this License and distribute the Larger
>> Work as a single product. In such a case, You must make sure the
>> requirements of this License are fulfilled for the Covered Code."
>>
>> The H.261 *en*coder of that project looks rather primitive (only
>> generating I-frames), but the *de*coder should be feature-complete.
>> Perhaps that's something to build upon.
>>
>> I would also suspect that complete and battle-tested implementations
>> gather dust at some vendors of telco stuff, but nobody seems to have
>> open sourced one.
>>
>>
>>
>> Maik
>>
>>
>> Am 18.11.2013 17:44, schrieb cowwoc:
>>>
>>> Looks good! I'd like to get a clarification which affects multiple
>>> options, but #10 most of all.
>>>
>>> Does the WG commit to providing reference implementations that supports
>>> VP8, H.264, H.261 with a commercially-friendly license? I am talking
>>> strictly about the software license, not the codec IPR. Meaning, libx264
>>> requires a GPL license and ffmpeg requires either a LGPL or GPL license.
>>> I would argue that libx264 is a non-starter for commercial use on any
>>> platform (due to GPL) and ffmpeg is not usable under iOS (since LGPL +
>>> static linking is equivalent to GPL). It is my understanding that the
>>> current WebRTC reference implementation is published under the BSD
>>> license. I am asking for the final reference implementation (supporting
>>> these codecs) to be published under the same license.
>>>
>>> I'm not saying that anyone has to ship a reference implementation
>>> supporting all 3 codecs, but rather that the WG should publish a
>>> reference implementation demonstrating how it can be done and proving
>>> interoperability actually works as expected.
>>>
>>> Thanks,
>>> Gili
>>>
>>> On 18/11/2013 7:45 AM, Magnus Westerlund wrote:
>>>> WG,
>>>>
>>>> The current list of proposed alternative are the following one:
>>>>
>>>>   The following alternatives has been proposed:
>>>>
>>>>    1. All entities MUST support H.264
>>>>    2. All entities MUST support VP8
>>>>    3. All entities MUST support both H.264 and VP8
>>>>    4. Browsers MUST support both H.264 and VP8, other entities MUST
>>>>       support at least one of H.264 and VP8
>>>>    5. All entities MUST support at least one of H.264 and VP8
>>>>    6. All entities MUST support H.261
>>>>    7. There is no MTI video codec
>>>>    8. 5+6, i.e. All entities MUST support H.261 and all entities MUST
>>>>       support at least one of H.264 and VP8
>>>>    9. All entities MUST support Theora.
>>>>   10. All entities SHOULD support both H.264 and VP8. All entities MUST
>>>>       at least implement one of those. Entities that do not support
>>>> both
>>>>       H.264 and VP8 MUST implement H.261.
>>>>
>>>> The deadline to propose additional alternatives are: 27th of November
>>>> 2013
>>>>
>>>> Cheers
>>>>
>>>> Magnus
>>>>
>>>> On 2013-11-13 21:23, Gonzalo Camarillo wrote:
>>>>> Folks,
>>>>>
>>>>> I hope everybody had a safe trip back home after Vancouver.
>>>>>
>>>>> As you all know, we need to make progress regarding the selection
>>>>> of the
>>>>> MTI video codec. The following are some of the alternatives we have on
>>>>> the table:
>>>>>
>>>>>   1. All entities MUST support H.264
>>>>>   2. All entities MUST support VP8
>>>>>   3. All entities MUST support both H.264 and VP8
>>>>>   4. Browsers MUST support both H.264 and VP8
>>>>>   5. All entities MUST support either H.264 or VP8
>>>>>   6. All entities MUST support H.261
>>>>>   7. There is no MTI video codec
>>>>>
>>>>> If you want the group to consider additional alternatives to the ones
>>>>> above, please let the group know within the following *two weeks*. At
>>>>> that point, the chairs will be listing all the received
>>>>> alternatives and
>>>>> proposing a process to select one among them.
>>>>>
>>>>> Please, send your proposals in an email to the list. You do not
>>>>> need to
>>>>> write a draft; just send the text you would like to see in the final
>>>>> document regarding video codecs.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gonzalo
>>>>> Responsible AD for this WG
>>>>>
>>>>> _______________________________________________
>>>>> 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


From keith.drage@alcatel-lucent.com  Mon Nov 18 11:44:21 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC78D1AE1B7 for ; Mon, 18 Nov 2013 11:44:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIc6tnUsXBN9 for ; Mon, 18 Nov 2013 11:44:20 -0800 (PST)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 44F281AE1B0 for ; Mon, 18 Nov 2013 11:44:16 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rAIJi61x003936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Nov 2013 13:44:08 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rAIJi5In011104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 20:44:05 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 18 Nov 2013 20:44:05 +0100
From: "DRAGE, Keith (Keith)" 
To: cowwoc , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Video codec selection - way forward
Thread-Index: AQHO4K5RagQcMG904k2Egdlu3UC4t5oq5eoAgABC+wCAADaGkA==
Date: Mon, 18 Nov 2013 19:44:04 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0E6F65@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <5283DFDC.4010906@ericsson.com> <528A0BD8.1070409@ericsson.com> <528A4408.50105@bbs.darktech.org>
In-Reply-To: <528A4408.50105@bbs.darktech.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 18 Nov 2013 19:44:22 -0000

Maybe you can explain how the WG is able to commit any of this.

Neither IETF or the WG are legal entities!

Individuals may express opinions on various options, but you will get nothi=
ng beyond this in my understanding.

Regards

Keith=20

> -----Original Message-----
> From: rtcweb-bounces@ietf.org=20
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
> Sent: 18 November 2013 16:45
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Video codec selection - way forward
>=20
>=20
> Looks good! I'd like to get a clarification which affects=20
> multiple options, but #10 most of all.
>=20
> Does the WG commit to providing reference implementations=20
> that supports VP8, H.264, H.261 with a commercially-friendly=20
> license? I am talking strictly about the software license,=20
> not the codec IPR. Meaning, libx264 requires a GPL license=20
> and ffmpeg requires either a LGPL or GPL license.=20
> I would argue that libx264 is a non-starter for commercial=20
> use on any platform (due to GPL) and ffmpeg is not usable=20
> under iOS (since LGPL + static linking is equivalent to GPL).=20
> It is my understanding that the current WebRTC reference=20
> implementation is published under the BSD license. I am=20
> asking for the final reference implementation (supporting=20
> these codecs) to be published under the same license.
>=20
> I'm not saying that anyone has to ship a reference=20
> implementation supporting all 3 codecs, but rather that the=20
> WG should publish a reference implementation demonstrating=20
> how it can be done and proving interoperability actually=20
> works as expected.
>=20
> Thanks,
> Gili
>=20
> On 18/11/2013 7:45 AM, Magnus Westerlund wrote:
> > WG,
> >
> > The current list of proposed alternative are the following one:
> >
> >   The following alternatives has been proposed:
> >
> >    1. All entities MUST support H.264
> >    2. All entities MUST support VP8
> >    3. All entities MUST support both H.264 and VP8
> >    4. Browsers MUST support both H.264 and VP8, other entities MUST
> >       support at least one of H.264 and VP8
> >    5. All entities MUST support at least one of H.264 and VP8
> >    6. All entities MUST support H.261
> >    7. There is no MTI video codec
> >    8. 5+6, i.e. All entities MUST support H.261 and all=20
> entities MUST
> >       support at least one of H.264 and VP8
> >    9. All entities MUST support Theora.
> >   10. All entities SHOULD support both H.264 and VP8. All=20
> entities MUST
> >       at least implement one of those. Entities that do not=20
> support both
> >       H.264 and VP8 MUST implement H.261.
> >
> > The deadline to propose additional alternatives are: 27th=20
> of November=20
> > 2013
> >
> > Cheers
> >
> > Magnus
> >
> > On 2013-11-13 21:23, Gonzalo Camarillo wrote:
> >> Folks,
> >>
> >> I hope everybody had a safe trip back home after Vancouver.
> >>
> >> As you all know, we need to make progress regarding the=20
> selection of=20
> >> the MTI video codec. The following are some of the alternatives we=20
> >> have on the table:
> >>
> >>   1. All entities MUST support H.264
> >>   2. All entities MUST support VP8
> >>   3. All entities MUST support both H.264 and VP8
> >>   4. Browsers MUST support both H.264 and VP8
> >>   5. All entities MUST support either H.264 or VP8
> >>   6. All entities MUST support H.261
> >>   7. There is no MTI video codec
> >>
> >> If you want the group to consider additional alternatives=20
> to the ones=20
> >> above, please let the group know within the following *two=20
> weeks*. At=20
> >> that point, the chairs will be listing all the received=20
> alternatives=20
> >> and proposing a process to select one among them.
> >>
> >> Please, send your proposals in an email to the list. You=20
> do not need=20
> >> to write a draft; just send the text you would like to see in the=20
> >> final document regarding video codecs.
> >>
> >> Thanks,
> >>
> >> Gonzalo
> >> Responsible AD for this WG
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >>
> >
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> =

From keith.drage@alcatel-lucent.com  Mon Nov 18 11:44:22 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A561AE1B0 for ; Mon, 18 Nov 2013 11:44:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jxs8qEmscP7 for ; Mon, 18 Nov 2013 11:44:20 -0800 (PST)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 44EFB1AE1AC for ; Mon, 18 Nov 2013 11:44:15 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rAIJi5Ih003934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Nov 2013 13:44:07 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rAIJi4bh011093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 20:44:04 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 18 Nov 2013 20:44:04 +0100
From: "DRAGE, Keith (Keith)" 
To: Magnus Westerlund , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Video codec selection - way forward
Thread-Index: AQHO4K5RagQcMG904k2Egdlu3UC4t5oq5eoAgABWmVA=
Date: Mon, 18 Nov 2013 19:44:04 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0E6F62@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <5283DFDC.4010906@ericsson.com> <528A0BD8.1070409@ericsson.com>
In-Reply-To: <528A0BD8.1070409@ericsson.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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, 18 Nov 2013 19:44:22 -0000

While I do not think it is an alternative in itself, and therefore orthogon=
al to this discussion, I would like to see any draft resulting from this al=
so containing a set of requirements leading to work that makes any hardware=
 based codec available to the application via the browser.

I agree any APIs that already exist in this area do need more work and that=
 work is not the work of rtcweb (and it is also not my area of expertise), =
but we seem to be drifting round in circles trying to deal with rights issu=
es on downloaded codecs, and ignoring the use of codecs that may already be=
 installed on the device for which the rights have already been paid.

Regards

Keith

> -----Original Message-----
> From: rtcweb-bounces@ietf.org=20
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund
> Sent: 18 November 2013 12:45
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Video codec selection - way forward
>=20
> WG,
>=20
> The current list of proposed alternative are the following one:
>=20
>  The following alternatives has been proposed:
>=20
>   1. All entities MUST support H.264
>   2. All entities MUST support VP8
>   3. All entities MUST support both H.264 and VP8
>   4. Browsers MUST support both H.264 and VP8, other entities MUST
>      support at least one of H.264 and VP8
>   5. All entities MUST support at least one of H.264 and VP8
>   6. All entities MUST support H.261
>   7. There is no MTI video codec
>   8. 5+6, i.e. All entities MUST support H.261 and all entities MUST
>      support at least one of H.264 and VP8
>   9. All entities MUST support Theora.
>  10. All entities SHOULD support both H.264 and VP8. All entities MUST
>      at least implement one of those. Entities that do not=20
> support both
>      H.264 and VP8 MUST implement H.261.
>=20
> The deadline to propose additional alternatives are: 27th of=20
> November 2013
>=20
> Cheers
>=20
> Magnus
>=20
> On 2013-11-13 21:23, Gonzalo Camarillo wrote:
> > Folks,
> >=20
> > I hope everybody had a safe trip back home after Vancouver.
> >=20
> > As you all know, we need to make progress regarding the=20
> selection of=20
> > the MTI video codec. The following are some of the alternatives we=20
> > have on the table:
> >=20
> >  1. All entities MUST support H.264
> >  2. All entities MUST support VP8
> >  3. All entities MUST support both H.264 and VP8  4. Browsers MUST=20
> > support both H.264 and VP8  5. All entities MUST support=20
> either H.264=20
> > or VP8  6. All entities MUST support H.261  7. There is no=20
> MTI video=20
> > codec
> >=20
> > If you want the group to consider additional alternatives=20
> to the ones=20
> > above, please let the group know within the following *two=20
> weeks*. At=20
> > that point, the chairs will be listing all the received=20
> alternatives=20
> > and proposing a process to select one among them.
> >=20
> > Please, send your proposals in an email to the list. You do=20
> not need=20
> > to write a draft; just send the text you would like to see in the=20
> > final document regarding video codecs.
> >=20
> > Thanks,
> >=20
> > Gonzalo
> > Responsible AD for this WG
> >=20
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >=20
> >=20
>=20
>=20
> --=20
>=20
> Magnus Westerlund
>=20
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> F=E4r=F6gatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> =

From singer@apple.com  Mon Nov 18 16:07:12 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C2F1AE5F4 for ; Mon, 18 Nov 2013 16:07:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Level: 
X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwMi8iA_RfAC for ; Mon, 18 Nov 2013 16:07:10 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id BA8CF1AE5F0 for ; Mon, 18 Nov 2013 16:07:10 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWH000VRHNJ8U41@mail-out.apple.com> for rtcweb@ietf.org; Mon, 18 Nov 2013 16:07:05 -0800 (PST)
X-AuditID: 1180715a-b7f3c6d00000020e-18-528aaba882d1
Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay6.apple.com (Apple SCV relay) with SMTP id 14.2D.00526.8ABAA825; Mon, 18 Nov 2013 16:07:04 -0800 (PST)
Received: from [17.153.17.55] (unknown [17.153.17.55]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWH00LO2HNSR410@aniseed.apple.com> for rtcweb@ietf.org; Mon, 18 Nov 2013 16:07:04 -0800 (PST)
From: David Singer 
In-reply-to: <52891EDB.2050607@googlemail.com>
Date: Mon, 18 Nov 2013 16:07:04 -0800
Message-id: 
References:  <52891EDB.2050607@googlemail.com>
To: Maik Merten 
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FAsrrtidVeQQet/c4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMfdleMES0YrbM7+zNTBOEexi5OSQEDCR+D79PyOELSZx4d56 ti5GLg4hgX4miZ+r9oElhATmMklMPSoDYjMLaEms33mcCcTmFdCT2Ll3G2sXIweHsIClxIXj JiBhNgFViQdzjoG1cgKVtP9+CVbOAhSfteA4C8QYYYnvj+9B2doST95dYIUYaSOxd8dUqLXF Eqf/PQCLiwDVtJ46xg5xp6zE6XPPWSYwCsxCctEsJBfNQjJ2ASPzKkaBotScxEozvcSCgpxU veT83E2M4KArjNrB2LDc6hCjAAejEg/vBPeuICHWxLLiytxDjBIczEoivFKzgEK8KYmVValF +fFFpTmpxYcYpTlYlMR5n/gApQTSE0tSs1NTC1KLYLJMHJxSDYyiXe/j1k7M0SqJ6it8wP4q jOnXZe0kHqfvnSZOS/tdJjCHKAl/KPu57MoBnpkhVd27XZVeRIrcuzQz+BLboZIEmePHFzz5 zfh0dax398d+m71Kcjc32zZfmaQVKX4/+PCRLVvuZktGsp2dXJA5se1hMoOxhcSHID5Ju+7j sS8eVexdufLdNz8lluKMREMt5qLiRADnEtchNgIAAA==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Tue, 19 Nov 2013 00:07:12 -0000

It's an interesting idea, but the quality of H.261, the availability of decent implementations, and its (functional) restrictions may mean that people are very loath to spend (waste) engineering time on it.  Is this a MUST that would, in fact, get respected?


On Nov 17, 2013, at 11:54 , Maik Merten  wrote:

> Hello,
> 
> just wondering if something like
> 
> "9. All entities SHOULD support both H.264 and VP8. All entities MUST at least implement one of those. Entities that do not support both H.264 and VP8 MUST implement H.261."
> 
> has already popped up. My reasoning is that implementations supporting both high performance codecs will always negotiate to use on of those - H.261 should never be relevant there.
> 
> It appears that all implementors are willing to implement either H.264 or VP8 (but not necessarily both). This obviously means that negotiation failure regarding a high-performance codec is a possiblity. In this case H.261 is actually useful so that basic video calls can still be established (for instance, I guess deaf people may always appreciate a video connection, as long as sign language can be transmitted).
> 
> 
> Maik
> 
> 
> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>> Hi,
>> Gaining IETF consensus on making it mandatory to support only H.264 or
>> only VP8 has clearly failed. I would welcome anyone to share their
>> thoughts on why they believe this situation will change anytime in the
>> next few years.  Therefore, can I suggest that we remove items 1 and 2
>> from the list. Hopefully this will speed up the process by focusing
>> efforts towards gaining agreement on one of the remaining options.
>> The following alternatives has been proposed:
>> 
>> 1. All entities MUST support H.264
>> 2. All entities MUST support VP8
>> 3. All entities MUST support both H.264 and VP8
>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>>    support at least one of H.264 and VP8
>> 5. All entities MUST support at least one of H.264 and VP8
>> 6. All entities MUST support H.261
>> 7. There is no MTI video codec
>> 8. All entities MUST support H.261 and all entities MUST support at
>>    least one of H.264 and VP8
>> 
>> Regards,
>> Jeremy Fuller
>> 
>> 
>> _______________________________________________
>> 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

David Singer
Multimedia and Software Standards, Apple Inc.


From bernard_aboba@hotmail.com  Mon Nov 18 17:00:15 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46111AE837 for ; Mon, 18 Nov 2013 17:00:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level: 
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGndh9YfnEEC for ; Mon, 18 Nov 2013 17:00:13 -0800 (PST)
Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by ietfa.amsl.com (Postfix) with ESMTP id C799B1AE833 for ; Mon, 18 Nov 2013 17:00:13 -0800 (PST)
Received: from BLU403-EAS242 ([65.55.111.72]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 18 Nov 2013 17:00:08 -0800
X-TMN: [r1nn4+9APvUThAaOIxP9fwchJblwBU8g]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References:  <52891EDB.2050607@googlemail.com> 
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
In-Reply-To: 
Date: Mon, 18 Nov 2013 17:00:02 -0800
To: David Singer 
X-OriginalArrivalTime: 19 Nov 2013 01:00:08.0095 (UTC) FILETIME=[B0C71AF0:01CEE4C2]
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Tue, 19 Nov 2013 01:00:15 -0000

David Singer said:

> Is this a MUST that would, in fact, get respected?

[BA] Given the level of support this option got previously (close to nil) I'=
d say probably not.=

From rjsparks@nostrum.com  Mon Nov 18 17:18:48 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980771AE8D0 for ; Mon, 18 Nov 2013 17:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.035
X-Spam-Level: 
X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDZvLbz-Rj_l for ; Mon, 18 Nov 2013 17:18:47 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCB61AE8CD for ; Mon, 18 Nov 2013 17:18:47 -0800 (PST)
Received: from 132-177-252-46.ip.sipit.net ([132.177.252.46]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAJ1Idgd095759 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 18 Nov 2013 19:18:41 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <528ABC71.9090005@nostrum.com>
Date: Mon, 18 Nov 2013 17:18:41 -0800
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" , SIP Forum Discussion 
Content-Type: multipart/alternative; boundary="------------070404020508020608020304"
Received-SPF: pass (shaman.nostrum.com: 132.177.252.46 is authenticated by a trusted mechanism)
Subject: [rtcweb] RTCWeb-it2 results
X-BeenThere: rtcweb@ietf.org
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: Tue, 19 Nov 2013 01:18:48 -0000

This is a multi-part message in MIME format.
--------------070404020508020608020304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The second SIP Forum RTCWeb Interoperability Test was hosted by TMC in 
Santa Clara, California, Monday November 18, 2013.

We had a very successful test session. Most of the scenarios we 
exercised "just worked" the first time. We had two browser 
implementations, and one application suite at the table. The scenarios 
we tested included a rich combination of nat and firewall restricted 
network paths, ensuring that the expected media and datachannel path was 
taken in each scenario. (This included forcing the browsers to 
communicate only through a Turn server.)

One observation from the tests is that implementations cannot rely on 
streams being available until onAddStream is called. This may or may not 
happen before the setRemoteDescription success callback.

We found a few deployed applications that are currently changing their 
behavior based on the User-Agent string, and have cost themselves 
starting to automatically work cross-browser as the browsers are being 
updated. New application developers should isolate such decisions. (It 
would have been nice to disable these checks to see if cross-browser 
DataChannels worked with the browser code at the table.)

Having a rich application suite available helped drive effective tests, 
and provided very useful feedback for the application developer. All 
application developers should consider attending the next event to get 
the quick feedback this kind of testing environment provides.

--------------070404020508020608020304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    
    
    The second SIP Forum
        RTCWeb Interoperability Test was hosted by TMC in Santa Clara,
        California, Monday November 18, 2013.
    
    

    
    
    
    
    We had a very successful
        test session. Most of the scenarios we exercised "just worked"
        the first time. We had two browser implementations, and one
        application suite at the table. The scenarios we tested included
        a rich combination of nat and firewall restricted network paths,
        ensuring that the expected media and datachannel path was taken
        in each scenario. (This included forcing the browsers to
        communicate only through a Turn server.)
    
    

    
    
    
    
    One observation from the
        tests is that implementations cannot rely on streams being
        available until onAddStream is called. This may or may not
        happen before the setRemoteDescription success callback.
    
    

    
    
    
    
    We found a few deployed
        applications that are currently changing their behavior based on
        the User-Agent string, and have cost themselves starting to
        automatically work cross-browser as the browsers are being
        updated. New application developers should isolate such
        decisions. (It would have been nice to disable these checks to
        see if cross-browser DataChannels worked with the browser code
        at the table.)
    
    

    
    
    
    
    Having a rich application
        suite available helped drive effective tests, and provided very
        useful feedback for the application developer. All application
        developers should consider attending the next event to get the
        quick feedback this kind of testing environment provides.
    
  


--------------070404020508020608020304--

From vsingh.ietf@gmail.com  Mon Nov 18 18:27:57 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9419A1AE291 for ; Mon, 18 Nov 2013 18:27:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUFS6z1RfV2g for ; Mon, 18 Nov 2013 18:27:55 -0800 (PST)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 78C361AE1C2 for ; Mon, 18 Nov 2013 18:27:55 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id qd12so905288ieb.29 for ; Mon, 18 Nov 2013 18:27:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=POY5kxD5GDRPnqCMArzJZaVJfB1nHXfozMVHUtp6ZfE=; b=DunharTIAha1YxJYbNaUJ++r1PbPiX8yOy5Kr4OhEJNnjMup50c0U7cqoZk3+SI8Aq SDopo2VCQMauT2BJEwQUr1tq68/vJfX+L2hfMYUKSWj1TEc2uo/LVA+l4X7BU7KJQyKq ESwZNT7D+t9x8BNM3lOUAsd2CEkNq8UuYoEYVJ9GAIoiOYqzfMBnOmtBV5/NEBCdCzdo oDfiEz5EWmloZuMcXUN6tL0PfVeJdWR6AGWx2+8Hr4HOYCsecF2fC37GEIA9r9EdMebZ ZpDuyev6e12nU/U5LHMhIzBlg+zHhFXPbTJTCtjvw/43FGAKUZPRDuUSjn3aPUEZtvKv mpnQ==
X-Received: by 10.50.39.51 with SMTP id m19mr17201336igk.51.1384828069477; Mon, 18 Nov 2013 18:27:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.102.8 with HTTP; Mon, 18 Nov 2013 18:27:28 -0800 (PST)
In-Reply-To: <52899BC0.2030909@alvestrand.no>
References:  <5645151759529247262@unknownmsgid> <52899BC0.2030909@alvestrand.no>
From: Varun Singh 
Date: Mon, 18 Nov 2013 18:27:28 -0800
Message-ID: 
To: Harald Alvestrand 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] opportunity cost (was MTI video codec, charter, RFC 3929)
X-BeenThere: rtcweb@ietf.org
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: Tue, 19 Nov 2013 02:27:57 -0000

On Sun, Nov 17, 2013 at 8:46 PM, Harald Alvestrand  wrote:
> On 11/17/2013 10:43 PM, Varun Singh wrote:
>
> +1, to focus on engineering and operational issues.
>
>
> Since firewall traversal was deemed to be a subject so specialized we
> couldn't debate it on the main list, perhaps we could have an MTI-only
> sublist?
>
> I'll personally commit to reading every message on it, but I suspect there
> are people on this mailing list who would like not to.
>

if other codecs are being discussed (H.261/3, Theora), it may affect the
traffic model discussion in RMCAT , i.e., how much variability in
sending rates can be expected for a target rate and how quickly can the
codec respond to a new rate request.

If the expected behavior is very different from the discussions on
traffic models (in Vancouver), having those discussions helps us
understand the congestion control requirements better.


>
>
> On Nov 14, 2013, at 1:06, Bernard Aboba  wrote:
>
> Keith Drage said:
>
> "Agree
>
> I am at the point where I would prefer to spend the meeting cycles getting
> things we can agree on, rather than where we seem to be at the moment with
> an issue where there are two clear camps and no real sign of a compromise.
>
> Ultimately the market will decide (and some parts of it probably have
> already decided - which is probably the reason for no progress).
>
> Keith"
>
> [BA] Well said. With most of the RTCWEB WG drafts either having completed
> WGLC or being candidates for WGLC by the end of the year,  with some elbow
> grease it seems very possible to move the bulk of the documents to IETF last
> call within a few months at most.   Polishing the RTCWEB document set would
> yield multiple benefits.  Not only would it get us closer to the goal of
> standardizing the WebRTC protocol stack, but also might well turn up an
> issue or two we haven't thought enough about. Also, once we move the
> protocol stack further along, we'll have more cycles to spend on operational
> issues (like monitoring concerns discussed in XRBLOCK), which currently
> limit the ability to deploy WebRTC at very large scale.   Unfortunately,
> we've been spending so much time on the MTI video codec debate that less
> glamorous (but ultimately much more important) engineering work is being
> neglected.
>
> This is all by way of seconding your point that there is a real opportunity
> cost to the never-ending, energy sapping MTI codec discussion.  Personally,
> I'd much rather redirect the work of the Internet Engineering Task Force
> RTCWEB WG away from amateur lawyering toward engineering where we actually
> have expertise and could potentially make a difference.
>
> _______________________________________________
> 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
>
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



-- 
http://www.netlab.tkk.fi/~varun/

From harald@alvestrand.no  Tue Nov 19 00:00:42 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5A61AC8F5 for ; Tue, 19 Nov 2013 00:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.425
X-Spam-Level: 
X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZO7UHLi96PK for ; Tue, 19 Nov 2013 00:00:39 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8F00C1AC862 for ; Tue, 19 Nov 2013 00:00:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D9CF39E2CB for ; Tue, 19 Nov 2013 09:00:33 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yqLggbtsBcf for ; Tue, 19 Nov 2013 09:00:32 +0100 (CET)
Received: from [172.30.42.84] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D9D8F39E09E for ; Tue, 19 Nov 2013 09:00:32 +0100 (CET)
Message-ID: <528B1A9F.8050601@alvestrand.no>
Date: Tue, 19 Nov 2013 09:00:31 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com>	<5285209D.7020407@googlemail.com>			<528559E4.3020903@nostrum.com>	<5286272B.5000005@bbs.darktech.org>			 <52877178.6040002@googlemail.com>
In-Reply-To: <52877178.6040002@googlemail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Trellis IPR status? (Re:  H261/MPEG-1 video quality)
X-BeenThere: rtcweb@ietf.org
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: Tue, 19 Nov 2013 08:00:42 -0000

On 11/16/2013 02:22 PM, Maik Merten wrote:
> I filed the ffmpeg bug regarding H.261. In a nutshell: ffmpeg
> currently crashes when enabling a certain encoder feature which turns
> out to be very useful for other codecs ("trellis quantization" - which
> basically means that coefficients to be coded are selected with the
> encoding costs in mind) for the H.261 encoder. This is a rather new
> encoder feature which pays of very nicely for other formats and should
> be applicable for H.261 as well.

Just checking: Do you know the patent status of trellis quantization?

One issue this particular WG has with codecs is that in order to have a
non-IPR-encumbered spec, we need a non-IPR-encumbered encoder too -
unlike the situation for playback-only contexts, where a
non-IPR-encumbered decoder may be enough.

Thus, people who describe a particular quality level achievable with a
non-IPR-encumbered codec would seem to have to describe a
non-IPR-encumbered encoder that can achieve that quality level, too.


From maikmerten@googlemail.com  Tue Nov 19 01:08:21 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE2A1AD6C1 for ; Tue, 19 Nov 2013 01:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.979
X-Spam-Level: 
X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSvDN8sjPMHr for ; Tue, 19 Nov 2013 01:08:19 -0800 (PST)
Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9047B1ACC91 for ; Tue, 19 Nov 2013 01:08:19 -0800 (PST)
Received: by mail-bk0-f49.google.com with SMTP id my13so937122bkb.22 for ; Tue, 19 Nov 2013 01:08:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=42RQVj2fZXvIryvZuoAsl3iQoKf+u/sCmIa4dwcKSvI=; b=bQD6ba5alFtqNiKWpiz8yzv1SZCFSS8m+YOn02FQp3Ti9GKyNAJaWpkobRiSfklpUj TNjjGVUeLjksXeNtNIukARHmeUh+WFOoAk3ZwM98kr5WSNWwwvB+MRxdi0r0Jsb2ZaV9 O2x47whKUjiKLSXxES+EM7sq+ltFC1DwdD6R2bxdBlqhwz/DFHM+a8wklans+z9jPRLs jheV1plaNW3VYQtwX1+0XK5xEIlYJbw0PTbl3Pn1kvmlq9T3O1xSnWocL7c3Qgado03L 9ds/HBg3aApaBAtwmfdENUqxGe8g6rUc6Xx5T+sjwRqrVkvy8HRD5RjZg9WjqhbJBtlF hkow==
X-Received: by 10.205.9.68 with SMTP id ov4mr15530774bkb.21.1384852091731; Tue, 19 Nov 2013 01:08:11 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id zl3sm19613157bkb.4.2013.11.19.01.08.09 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 01:08:10 -0800 (PST)
Message-ID: <528B2ABE.4040701@googlemail.com>
Date: Tue, 19 Nov 2013 10:09:18 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
CC: rtcweb@ietf.org
References:  <52891EDB.2050607@googlemail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Tue, 19 Nov 2013 09:08:21 -0000

I'm sure the prospect of implementing H.261 is not a desirable one but I 
wonder if

  - implementing the codec of "the other codec camp" is more desirable
  - the end-users will appreciate spuriously failing video calls


Basically this boils down on what the question is. "Who enjoys 
implementing H.261?" clearly will be answered as "nobody". However, "who 
can live with the inconvenience of implementing H.261 for the sake of 
interoperability and accessibility" may be answered differently.

It would, of course, be preferable if H.261 can be substituted with a 
higher performing alternative, although I guess the set of codecs with a 
universally accepted status as "no worries regarding IPR or licensing" 
is limited.


Maik


Am 19.11.2013 01:07, schrieb David Singer:
> It's an interesting idea, but the quality of H.261, the availability of decent implementations, and its (functional) restrictions may mean that people are very loath to spend (waste) engineering time on it.  Is this a MUST that would, in fact, get respected?
>
>
> On Nov 17, 2013, at 11:54 , Maik Merten  wrote:
>
>> Hello,
>>
>> just wondering if something like
>>
>> "9. All entities SHOULD support both H.264 and VP8. All entities MUST at least implement one of those. Entities that do not support both H.264 and VP8 MUST implement H.261."
>>
>> has already popped up. My reasoning is that implementations supporting both high performance codecs will always negotiate to use on of those - H.261 should never be relevant there.
>>
>> It appears that all implementors are willing to implement either H.264 or VP8 (but not necessarily both). This obviously means that negotiation failure regarding a high-performance codec is a possiblity. In this case H.261 is actually useful so that basic video calls can still be established (for instance, I guess deaf people may always appreciate a video connection, as long as sign language can be transmitted).
>>
>>
>> Maik
>>
>>
>> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>>> Hi,
>>> Gaining IETF consensus on making it mandatory to support only H.264 or
>>> only VP8 has clearly failed. I would welcome anyone to share their
>>> thoughts on why they believe this situation will change anytime in the
>>> next few years.  Therefore, can I suggest that we remove items 1 and 2
>>> from the list. Hopefully this will speed up the process by focusing
>>> efforts towards gaining agreement on one of the remaining options.
>>> The following alternatives has been proposed:
>>>
>>> 1. All entities MUST support H.264
>>> 2. All entities MUST support VP8
>>> 3. All entities MUST support both H.264 and VP8
>>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>>>     support at least one of H.264 and VP8
>>> 5. All entities MUST support at least one of H.264 and VP8
>>> 6. All entities MUST support H.261
>>> 7. There is no MTI video codec
>>> 8. All entities MUST support H.261 and all entities MUST support at
>>>     least one of H.264 and VP8
>>>
>>> Regards,
>>> Jeremy Fuller
>>>
>>>
>>> _______________________________________________
>>> 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
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>


From magnus.westerlund@ericsson.com  Tue Nov 19 02:55:04 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AC01ADBF7; Tue, 19 Nov 2013 02:55:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEaOOLycnJY5; Tue, 19 Nov 2013 02:55:02 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 08DCF1AD7BF; Tue, 19 Nov 2013 02:55:01 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-c9-528b437f9585
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 63.DE.27941.F734B825; Tue, 19 Nov 2013 11:54:55 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Tue, 19 Nov 2013 11:54:54 +0100
Message-ID: <528B437E.5090903@ericsson.com>
Date: Tue, 19 Nov 2013 11:54:54 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" , "pm-dir@ietf.org" 
References: <9904FB1B0159DA42B0B887B7FA8119CA1293FC7D@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1293FC7D@AZ-FFEXMB04.global.avaya.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUyM+JvrW69c3eQwZRbyhZff/5gtTj6wdJi 7b92dgdmj4Mr57B7LFnykymAKYrLJiU1J7MstUjfLoEr48zsicwFT/gruk/OYGxgPMvTxcjJ ISFgInFw1xcmCFtM4sK99WwgtpDAEUaJezMkuhi5gOzljBLtp6+xgyR4BbQlWvZ/YAWxWQRU JRae+c8IYrMJWEjc/NEI1iwqECxx/tViqHpBiZMzn7CA2CICYRIT5x4F62UWUJe4s/gcWI2w gKvEv+n97BCLgyU+7zsJdhCnQIjEnEVngGwOoOPEJXoagyBa9SSmXG1hhLDlJZq3zmaGaNWW aGjqYJ3AKDQLyeZZSFpmIWlZwMi8ipGjOLU4KTfdyGATIzBkD275bbGD8fJfm0OM0hwsSuK8 H986BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg7HHte30waf++KzsmCHKmp9yO/P0+fFpq 45elvAVhV/bM37t3169wN+cXbmf4OAoXJJUKzdZ/XRm0ZsU5udObVp/99vfkzlvHd8Wz7XhU FXN0g5/b84mefmtuXD1eO0tFqPfwv3XSj0+Vb/kjp/XHx/ZrotTB2QZt8xO75Ep9Nu5Pn1pu 8FgouEGJpTgj0VCLuag4EQCZKIqpJwIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] PM-DIR review of draft-ietf-rtcweb-rtp-usage-10
X-BeenThere: rtcweb@ietf.org
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: Tue, 19 Nov 2013 10:55:04 -0000

Hi Dan,

Thanks for your review. I see no issue with changing the document as you
have requested.

Cheers

Magnus

On 2013-11-18 17:45, Romascanu, Dan (Dan) wrote:
> 
> This is the PM-DIR review of draft-ietf-rtcweb-rtp-usage-10. I am the
> assigned PM-DIR reviewer for this I-D.
> 
> This Internet-Draft defines the media transport aspects and provides
> the details of the RTP usage in WebRTC - specifically the
> requirements for which RTP features, profiles and extensions need to
> be supported in WebRTC.
> 
> The I-D does not define performance metrics, so a 6390 review does
> not apply.
> 
> The I-D includes a short section (section 8) dedicated to 'WebRTC Use
> of RTP: Performance Monitoring'. I am fine with the content of this
> section with two comments:
> 
> 1.
>> It is not yet clear
> what extended metrics are appropriate for use in the WebRTC context, 
> so implementations are not expected to generate any RTCP XR packets.
> 
> I believe that it would be more appropriate to replace '
> implementations are not expected ' by ' implementations are not
> required '
> 
> 2.
>> A large number of additional performance metrics are supported by
>> the
> RTCP Extended Reports (XR) framework [RFC3611].
> 
> I think that mentioning 3611 only is limiting nowadays and that RFC
> 6792 should be mentioned as well.
> 
> Regards,
> 
> Dan
> 
> _______________________________________________ rtcweb mailing list 
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From maikmerten@googlemail.com  Tue Nov 19 03:59:43 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09EA1ADF28 for ; Tue, 19 Nov 2013 03:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFsBA1Y82H0h for ; Tue, 19 Nov 2013 03:59:42 -0800 (PST)
Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id E2A161AD8EA for ; Tue, 19 Nov 2013 03:59:41 -0800 (PST)
Received: by mail-bk0-f51.google.com with SMTP id 6so1098285bkj.10 for ; Tue, 19 Nov 2013 03:59:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=abtxsoVzpcIzxvXMNJVswRBM1BP4tZHslhWv9qDxDko=; b=nqPBhwb0+x25TphKnJPCIIX0uAf2Hk4YQbeZL6w6k7p6gCsv/6+15eTraayjucM1cv zBDa2903j9J3ZyYNdT/eNeEO3OLQGk3UT4VElSvYey3c4wIczaa0sSHvMQF3Ljlucmpd EI/Do0SV1a7zdR/9RkmWhtD6hDntsBsF/wW3hKJI4tP2tUw3QSoMkPdjAsdtGHNc9RWt Kb7fg8zJBhGzixzQPcNtK3VHv7kP9RwkP6if4VP94ECFvhYOMnBEf5olbrhdD9XWdY2E Lzo6y7A/pNMj7erjBaqfEzmK1DEDG7vNNCb1WC7Xaz5EQA+LVGwaWffMkQeqeRvk3ADK wW4g==
X-Received: by 10.204.232.78 with SMTP id jt14mr16103346bkb.3.1384862375167; Tue, 19 Nov 2013 03:59:35 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id j6sm9557297bki.17.2013.11.19.03.59.33 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 03:59:34 -0800 (PST)
Message-ID: <528B52EA.9010201@googlemail.com>
Date: Tue, 19 Nov 2013 13:00:42 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com>	<5285209D.7020407@googlemail.com>			<528559E4.3020903@nostrum.com>	<5286272B.5000005@bbs.darktech.org>			 <52877178.6040002@googlemail.com> <528B1A9F.8050601@alvestrand.no>
In-Reply-To: <528B1A9F.8050601@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Trellis IPR status? (Re:  H261/MPEG-1 video quality)
X-BeenThere: rtcweb@ietf.org
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: Tue, 19 Nov 2013 11:59:43 -0000

Am 19.11.2013 09:00, schrieb Harald Alvestrand:
> Just checking: Do you know the patent status of trellis quantization?
>
> One issue this particular WG has with codecs is that in order to have a
> non-IPR-encumbered spec, we need a non-IPR-encumbered encoder too -
> unlike the situation for playback-only contexts, where a
> non-IPR-encumbered decoder may be enough.
>
> Thus, people who describe a particular quality level achievable with a
> non-IPR-encumbered codec would seem to have to describe a
> non-IPR-encumbered encoder that can achieve that quality level, too.

I don't think discussing the IPR-situation of encoder optimizations was 
a topic yet, as implementers can choose what optimization features they 
enable in their encoder deployments. In the case of H.261, I think it is 
undisputed that an "IPR-free", spec-compliant encoder can be created. 
The samples I provided were encoded without modern encoder techniques 
(simply because ffmpeg used to crash when doing the advanced stuff, 
which now has been fixed), but clearly I'm not in a position to report 
on the general IPR situation of ffmpeg's H.261 encoder. Due to H.261's 
special IPR status it may indeed make sense to have both "IPR-safe" 
samples and "rockets attached" samples, once and if such performance 
boosters become available for H.261.

When assessing the performance that is achievable with a given format it 
is natural to try to create the best encodes possible, as has been done, 
e.g., with the VP8 vs. H.264 quality debate here on the list. For 
instance, H.264 was represented by x264 (most likely because of it is 
usually the best performing encoder) and not, e.g., by Cisco's encoder, 
albeit the latter is likely to become more relevant in the form of 
OpenH264. As far as I recall nobody called for a comparative IPR 
analysis regarding, e.g., those two encoder implementations. I assume 
this is because everyone assumes that each implementer will make its own 
risk-assessment regarding deployed encoding techniques. If this is so 
this should apply to H.261 as well.


Maik



From harald@alvestrand.no  Tue Nov 19 05:26:31 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7079C1ADFB0 for ; Tue, 19 Nov 2013 05:26:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.425
X-Spam-Level: 
X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N81lD03jAaen for ; Tue, 19 Nov 2013 05:26:28 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 70CD41ADFA6 for ; Tue, 19 Nov 2013 05:26:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6AD2139E49F for ; Tue, 19 Nov 2013 14:26:22 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQs5BSCJrjbk for ; Tue, 19 Nov 2013 14:26:21 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DA39439E482 for ; Tue, 19 Nov 2013 14:26:20 +0100 (CET)
Message-ID: <528B66FB.1060005@alvestrand.no>
Date: Tue, 19 Nov 2013 14:26:19 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com>	<5285209D.7020407@googlemail.com>			<528559E4.3020903@nostrum.com>	<5286272B.5000005@bbs.darktech.org>			 <52877178.6040002@googlemail.com> <528B1A9F.8050601@alvestrand.no> <528B52EA.9010201@googlemail.com>
In-Reply-To: <528B52EA.9010201@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Trellis IPR status? (Re:  H261/MPEG-1 video quality)
X-BeenThere: rtcweb@ietf.org
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: Tue, 19 Nov 2013 13:26:31 -0000

On 11/19/2013 01:00 PM, Maik Merten wrote:
> Am 19.11.2013 09:00, schrieb Harald Alvestrand:
>> Just checking: Do you know the patent status of trellis quantization?
>>
>> One issue this particular WG has with codecs is that in order to have a
>> non-IPR-encumbered spec, we need a non-IPR-encumbered encoder too -
>> unlike the situation for playback-only contexts, where a
>> non-IPR-encumbered decoder may be enough.
>>
>> Thus, people who describe a particular quality level achievable with a
>> non-IPR-encumbered codec would seem to have to describe a
>> non-IPR-encumbered encoder that can achieve that quality level, too.
>
> I don't think discussing the IPR-situation of encoder optimizations 
> was a topic yet, as implementers can choose what optimization features 
> they enable in their encoder deployments. In the case of H.261, I 
> think it is undisputed that an "IPR-free", spec-compliant encoder can 
> be created. The samples I provided were encoded without modern encoder 
> techniques (simply because ffmpeg used to crash when doing the 
> advanced stuff, which now has been fixed), but clearly I'm not in a 
> position to report on the general IPR situation of ffmpeg's H.261 
> encoder. Due to H.261's special IPR status it may indeed make sense to 
> have both "IPR-safe" samples and "rockets attached" samples, once and 
> if such performance boosters become available for H.261.
>
> When assessing the performance that is achievable with a given format 
> it is natural to try to create the best encodes possible, as has been 
> done, e.g., with the VP8 vs. H.264 quality debate here on the list. 
> For instance, H.264 was represented by x264 (most likely because of it 
> is usually the best performing encoder) and not, e.g., by Cisco's 
> encoder, albeit the latter is likely to become more relevant in the 
> form of OpenH264. As far as I recall nobody called for a comparative 
> IPR analysis regarding, e.g., those two encoder implementations. I 
> assume this is because everyone assumes that each implementer will 
> make its own risk-assessment regarding deployed encoding techniques. 
> If this is so this should apply to H.261 as well.

In the case of VP8, the patent and copyright grants apply both to the 
decoder and the published reference encoder (which is also the one used 
for the tests).

Choosing x264 for the tests was easy; it's got a reputation for quality, 
and its reference source is available on the Internet, so everyone can 
agree what we're talking about when we say "x264, GIT tag xxxxx".


From maikmerten@googlemail.com  Tue Nov 19 06:47:41 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB63C1ADFF8 for ; Tue, 19 Nov 2013 06:47:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga0plGT9UG9U for ; Tue, 19 Nov 2013 06:47:40 -0800 (PST)
Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 31BFE1ADFF6 for ; Tue, 19 Nov 2013 06:47:38 -0800 (PST)
Received: by mail-bk0-f49.google.com with SMTP id my13so1062477bkb.8 for ; Tue, 19 Nov 2013 06:47:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MgPQWCsFB14i0i5D2NS/aItW9IrY2yDVUDxmpBAuGR0=; b=h7tPnRmB14ATc7Te5qkxw8KfGz20mkF787w9mapGWJKrHNwiX4CIAylZWWOMyC3auw khUk3NS+nQegH+CC49EKqHBqduL6n+JK4mv6GKX5hxwwLqOpigUS/BR10yFQiQ9E+blP GKZ7+22rpRRo8uWmOPhe4C7I439Pt/8jdPsm4nhj+SKL401C2uIgOOXYgYTRDJoKe6/1 ztaxaCCJsl+EcCgR9w+h4peuEcGljtxNxRYh8oWHeaPZ7+RFbZ0LIeeN4iLZl2RJkQC6 Fnyxn61RdUvf6t9+YKl9dVfojTJmEuyB+Sa9bbREpFI7+uG0pLZtFYskpEXnhWqbWL0K zn6A==
X-Received: by 10.205.15.72 with SMTP id pt8mr16318712bkb.17.1384872452603; Tue, 19 Nov 2013 06:47:32 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id l5sm20731602bko.7.2013.11.19.06.47.30 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 06:47:31 -0800 (PST)
Message-ID: <528B7A47.4010709@googlemail.com>
Date: Tue, 19 Nov 2013 15:48:39 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com>	<5285209D.7020407@googlemail.com>			<528559E4.3020903@nostrum.com>	<5286272B.5000005@bbs.darktech.org>			 <52877178.6040002@googlemail.com> <528B1A9F.8050601@alvestrand.no> <528B52EA.9010201@googlemail.com> <528B66FB.1060005@alvestrand.no>
In-Reply-To: <528B66FB.1060005@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Trellis IPR status? (Re:  H261/MPEG-1 video quality)
X-BeenThere: rtcweb@ietf.org
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: Tue, 19 Nov 2013 14:47:42 -0000

Am 19.11.2013 14:26, schrieb Harald Alvestrand:
> In the case of VP8, the patent and copyright grants apply both to the
> decoder and the published reference encoder (which is also the one used
> for the tests).
>
> Choosing x264 for the tests was easy; it's got a reputation for quality,
> and its reference source is available on the Internet, so everyone can
> agree what we're talking about when we say "x264, GIT tag xxxxx".

Yeah, just pointing out that IPR discussion wasn't centered on encoder 
implementations, as every specific implementation can open its own can 
of worms which may not strictly be related to the output format itself.


Maik


From cowwoc@bbs.darktech.org  Tue Nov 19 12:25:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A528E1AE1A3 for ; Tue, 19 Nov 2013 12:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnyceoCi9vXN for ; Tue, 19 Nov 2013 12:24:58 -0800 (PST)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8885D1AE194 for ; Tue, 19 Nov 2013 12:24:58 -0800 (PST)
Received: by mail-ob0-f174.google.com with SMTP id wn1so2869352obc.33 for ; Tue, 19 Nov 2013 12:24:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wYBQUgDB7pjWo+PE5IqI+TE5I7wH5ZvUZTos7U6WfS0=; b=ADPt8KNS6wrKG56lxXN2xIudbqu4lkyYKAftoSRabccA+Jsr60e/y9rQfFptZxuguy vE6VYIZsopLzDq/XhR/lnJU5szF7puTBqZFWbRhmnOzZIDlixEtM2EOBPaI4DEZmpVcZ cRIKAiAy3QG3FiCdRtamveZKV/moHkWVKr91I/Yg+sBTVhsiWUqeDwAUWY128RSJ85hE qah6Vn92ozqphq5UvUJlZKh5J77wWYu2b9a3C58xAWn0lGyYXhjzjnXC8pD7OnheMO7S 4er0CCCBfVT+mFWwu+Ad1PSA7n9EvVRhwQxAWeLTz2Zq7bIcs/a+BtpBSMzULaRTOp7+ A2gw==
X-Gm-Message-State: ALoCoQlHvWfdTwEJXNjoukTpF1/Nplpsm3jW2rS6akGqjgVc8UYRPZqmV5W6JQxHbSzM7zLJEIQe
X-Received: by 10.182.28.35 with SMTP id y3mr2854739obg.55.1384892692071; Tue, 19 Nov 2013 12:24:52 -0800 (PST)
Received: from [10.35.1.167] (sccc-66-78-236-243.smartcity.com. [66.78.236.243]) by mx.google.com with ESMTPSA id ii8sm31613553obb.11.2013.11.19.12.24.50 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 12:24:51 -0800 (PST)
Message-ID: <528BC901.3090206@bbs.darktech.org>
Date: Tue, 19 Nov 2013 12:24:33 -0800
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>
In-Reply-To: <528B2ABE.4040701@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Tue, 19 Nov 2013 20:25:00 -0000

+1

On 19/11/2013 1:09 AM, Maik Merten wrote:
> I'm sure the prospect of implementing H.261 is not a desirable one but 
> I wonder if
>
>  - implementing the codec of "the other codec camp" is more desirable
>  - the end-users will appreciate spuriously failing video calls
>
>
> Basically this boils down on what the question is. "Who enjoys 
> implementing H.261?" clearly will be answered as "nobody". However, 
> "who can live with the inconvenience of implementing H.261 for the 
> sake of interoperability and accessibility" may be answered differently.
>
> It would, of course, be preferable if H.261 can be substituted with a 
> higher performing alternative, although I guess the set of codecs with 
> a universally accepted status as "no worries regarding IPR or 
> licensing" is limited.
>
>
> Maik
>
>
> Am 19.11.2013 01:07, schrieb David Singer:
>> It's an interesting idea, but the quality of H.261, the availability 
>> of decent implementations, and its (functional) restrictions may mean 
>> that people are very loath to spend (waste) engineering time on it.  
>> Is this a MUST that would, in fact, get respected?
>>
>>
>> On Nov 17, 2013, at 11:54 , Maik Merten  
>> wrote:
>>
>>> Hello,
>>>
>>> just wondering if something like
>>>
>>> "9. All entities SHOULD support both H.264 and VP8. All entities 
>>> MUST at least implement one of those. Entities that do not support 
>>> both H.264 and VP8 MUST implement H.261."
>>>
>>> has already popped up. My reasoning is that implementations 
>>> supporting both high performance codecs will always negotiate to use 
>>> on of those - H.261 should never be relevant there.
>>>
>>> It appears that all implementors are willing to implement either 
>>> H.264 or VP8 (but not necessarily both). This obviously means that 
>>> negotiation failure regarding a high-performance codec is a 
>>> possiblity. In this case H.261 is actually useful so that basic 
>>> video calls can still be established (for instance, I guess deaf 
>>> people may always appreciate a video connection, as long as sign 
>>> language can be transmitted).
>>>
>>>
>>> Maik
>>>
>>>
>>> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>>>> Hi,
>>>> Gaining IETF consensus on making it mandatory to support only H.264 or
>>>> only VP8 has clearly failed. I would welcome anyone to share their
>>>> thoughts on why they believe this situation will change anytime in the
>>>> next few years.  Therefore, can I suggest that we remove items 1 and 2
>>>> from the list. Hopefully this will speed up the process by focusing
>>>> efforts towards gaining agreement on one of the remaining options.
>>>> The following alternatives has been proposed:
>>>>
>>>> 1. All entities MUST support H.264
>>>> 2. All entities MUST support VP8
>>>> 3. All entities MUST support both H.264 and VP8
>>>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>>>>     support at least one of H.264 and VP8
>>>> 5. All entities MUST support at least one of H.264 and VP8
>>>> 6. All entities MUST support H.261
>>>> 7. There is no MTI video codec
>>>> 8. All entities MUST support H.261 and all entities MUST support at
>>>>     least one of H.264 and VP8
>>>>
>>>> Regards,
>>>> Jeremy Fuller
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From bernard_aboba@hotmail.com  Tue Nov 19 19:27:16 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538A21AE069 for ; Tue, 19 Nov 2013 19:27:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AsD08LnLZuk for ; Tue, 19 Nov 2013 19:27:15 -0800 (PST)
Received: from blu0-omc2-s36.blu0.hotmail.com (blu0-omc2-s36.blu0.hotmail.com [65.55.111.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACEA1AE043 for ; Tue, 19 Nov 2013 19:27:14 -0800 (PST)
Received: from BLU169-W24 ([65.55.111.71]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 19 Nov 2013 19:27:09 -0800
X-TMN: [QUNvzYULLYM8YLEGMIVbnL/xGqTTtWXv]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_191ad7f2-45f7-4255-a3c1-56c5daf50558_"
From: Bernard Aboba 
To: Maik Merten 
Date: Tue, 19 Nov 2013 19:27:08 -0800
Importance: Normal
In-Reply-To: <528B2ABE.4040701@googlemail.com>
References: , <52891EDB.2050607@googlemail.com>, , <528B2ABE.4040701@googlemail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Nov 2013 03:27:09.0075 (UTC) FILETIME=[64E79630:01CEE5A0]
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 03:27:16 -0000

--_191ad7f2-45f7-4255-a3c1-56c5daf50558_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Maik said:=20

>   - implementing the codec of "the other codec camp" is more desirable
>   - the end-users will appreciate spuriously failing video calls

[BA] The above are not the only choices=2C because it is not necessary to "=
implement the codec of the other codec camp" in order to provide support fo=
r it.  The Cisco offer of an H.264 encoder/decoder is only one example. =20
=20
So really=2C the choice is more between "support codec extensibility and al=
low 'the other codec camp' to take risks they are comfortable with" and "im=
plement an inferior codec no one wants". =20
=20
=20
 		 	   		  =

--_191ad7f2-45f7-4255-a3c1-56c5daf50558_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





    Maik said: 

    >=3B   - im=
plementing the codec of "the other codec camp" is more desirable
    >=3B =
  - the end-users will appreciate spuriously failing video calls

    [BA=
] The above are not the only choices=2C because it is not necessary to "imp=
lement the codec of the other codec camp" in order to provide support for i=
t. =3B The Cisco offer of an H.264 encoder/decoder is only one example.=
 =3B 
     =3B
    So really=2C the choice is more between "support c=
odec extensibility and allow 'the other codec camp' to take risks they are =
comfortable with" and "implement an inferior codec no one wants". =3B <=
BR> =3B
     =3B
     		 	   		  
    
=

--_191ad7f2-45f7-4255-a3c1-56c5daf50558_--

From cowwoc@bbs.darktech.org  Tue Nov 19 22:52:33 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914751AE36A for ; Tue, 19 Nov 2013 22:52:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPhWSFjtYihl for ; Tue, 19 Nov 2013 22:52:32 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBEF81AE363 for ; Tue, 19 Nov 2013 22:52:31 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id rq2so3059242pbb.31 for ; Tue, 19 Nov 2013 22:52:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=rdaw4N77r9mHbyFWKWDuT93QW3++JUpWdDezst6vARU=; b=d9brpKGjrtJ0mJK2uZ+pbSemg5cfe3Msz+SjZERnuTxh8qo/k4Ndg70KJMAUIow2sZ 7jZCvr7NzCyExd3K62FDlFxlHUWPbzgL+85/PlUCTQPaVUP7z2ESszyF1wdHMKZfAEML 53GQebe4O6pxBfn/WS4w524xeklaGZyEp6WgdO4sEvemqEIvYh8S65CBpWnVesNBKTIp NjZ8zbqDR3PgEvuPCU0+DxwnlQ7gLlrsFL2+Z4QI0EGcQnoC3tQRNcCfMN6J5hGUKIq6 omxUnH+Y/Y7o2RbWWiQOOetWge5Y1CLXLLZXwr1q9BxIGWP9tCNb2MGm6aKGy9A+rmnR QGSw==
X-Gm-Message-State: ALoCoQkEfHUVffRuUAxiRmWK/Iwq/AI/F4D6TwITTC3mA1SygOykKqgEH4i+dHw+oA+zUJl2K4vb
X-Received: by 10.68.189.101 with SMTP id gh5mr29692027pbc.39.1384930345580; Tue, 19 Nov 2013 22:52:25 -0800 (PST)
Received: from [172.16.0.59] ([12.208.14.10]) by mx.google.com with ESMTPSA id bl8sm30114608pad.17.2013.11.19.22.52.22 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 22:52:24 -0800 (PST)
Message-ID: <528C5C22.5090505@bbs.darktech.org>
Date: Tue, 19 Nov 2013 22:52:18 -0800
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: , <52891EDB.2050607@googlemail.com>, , <528B2ABE.4040701@googlemail.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030004000103020406060801"
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 06:52:33 -0000

This is a multi-part message in MIME format.
--------------030004000103020406060801
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bernard,

Numerous stakeholders have already stated that they cannot use Cisco's 
offering (including some noteworthy open-source operating systems) so 
this is a non-starter.

No one is arguing that implementing H.261 is great. We're just saying 
that it's better than the alternative (no video).

Gili

On 19/11/2013 7:27 PM, Bernard Aboba wrote:
> Maik said:
>
> > - implementing the codec of "the other codec camp" is more desirable
> > - the end-users will appreciate spuriously failing video calls
>
> [BA] The above are not the only choices, because it is not necessary 
> to "implement the codec of the other codec camp" in order to provide 
> support for it.  The Cisco offer of an H.264 encoder/decoder is only 
> one example.
>
> So really, the choice is more between "support codec extensibility and 
> allow 'the other codec camp' to take risks they are comfortable with" 
> and "implement an inferior codec no one wants".
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------030004000103020406060801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Bernard,
    
    
    
    Numerous stakeholders have already stated that they cannot use
    Cisco's offering (including some noteworthy open-source operating
    systems) so this is a non-starter.
    
    
    
    No one is arguing that implementing H.261 is great. We're just
    saying that it's better than the alternative (no video).
    
    
    
    Gili
    
    
    
    
    On 19/11/2013 7:27 PM, Bernard Aboba
      wrote:
    
    
    
    
    
      
      
    Maik said: 
    
        
    
        > - implementing the codec of "the other codec camp" is more
        desirable
    
        > - the end-users will appreciate spuriously failing video
        calls
    
        
    
        [BA] The above are not the only choices, because it is not
        necessary to "implement the codec of the other codec camp" in
        order to provide support for it.  The Cisco offer of an H.264
        encoder/decoder is only one example.  
    
         
    
        So really, the choice is more between "support codec
        extensibility and allow 'the other codec camp' to take risks
        they are comfortable with" and "implement an inferior codec no
        one wants".  
    
         
    
         
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

    
    
    
    
    
  


--------------030004000103020406060801--

From maikmerten@googlemail.com  Wed Nov 20 00:57:27 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20211AC7EE for ; Wed, 20 Nov 2013 00:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.979
X-Spam-Level: 
X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgHJmW10i8QX for ; Wed, 20 Nov 2013 00:57:25 -0800 (PST)
Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 761341AC4AB for ; Wed, 20 Nov 2013 00:57:25 -0800 (PST)
Received: by mail-ea0-f169.google.com with SMTP id l9so3766045eaj.28 for ; Wed, 20 Nov 2013 00:57:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=q9b70LNVhfQFD9XiESzrlr6A6CUl1reVrtVZ9fRoCGY=; b=0l+UdI5ZL4PvMLXkJmob+FE9v9EwxPau0fCF/CxUWA5kVWTEpzhWowOeMQhiZy5iSa M34JxIe000i0Pg0kuanAju/VQhjU74RYTK3RjKKMBTr0fMj7YRecxJ+ShsUr+aHhONZU 6ZatQyo36ykUodSqksBeDOfkCTf6fqtn7gZHrI2rBnP69/gvzWVksVhMKeHZVcG205w+ xobg83O9z+pDaCu5+9H17Fk241FBte/u/5e/rDZfcxPsnOglkXoXEtvEPk9VGuF6zIKJ axQHbpx2xejXuPxpCv41U4jTIwzBib6rzDgCTpj9KG+K0aJUia8xfFN52EKn9IjtnqDL AmKg==
X-Received: by 10.14.6.134 with SMTP id 6mr725097een.66.1384937838728; Wed, 20 Nov 2013 00:57:18 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id v45sm7155878eef.11.2013.11.20.00.57.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 00:57:17 -0800 (PST)
Message-ID: <528C79AD.10608@googlemail.com>
Date: Wed, 20 Nov 2013 09:58:21 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
CC: "rtcweb@ietf.org" 
References: , <52891EDB.2050607@googlemail.com>, , <528B2ABE.4040701@googlemail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 08:57:27 -0000

Am 20.11.2013 04:27, schrieb Bernard Aboba:
> Maik said:
>
>  > - implementing the codec of "the other codec camp" is more desirable
>  > - the end-users will appreciate spuriously failing video calls
>
> [BA] The above are not the only choices, because it is not necessary to
> "implement the codec of the other codec camp" in order to provide
> support for it.  The Cisco offer of an H.264 encoder/decoder is only one
> example.

I meant "implementing" as in "implementing and deploying support for".

Cisco's offer, while certainly useful in some (or even many) application 
contexts, cannot cover all relevant deployment scenarios. This not only 
concerns WebRTC implementation providers, but also users (for instance, 
what licensing status do machines have that are recovered from disk 
images that happen to include the binary blob implementing H.264?).


> So really, the choice is more between "support codec extensibility and
> allow 'the other codec camp' to take risks they are comfortable with"
> and "implement an inferior codec no one wants".

Without a fallback codec there will be negotiation failure in ways that 
are out of control of the affected users. I think this is undesirable 
for all involved parties. Implementing support for an "IPR-safe", 
unsophisticated, well-understood, albeit sadly low-performing codec to 
me sounds like a manageable requirement for implementers to guarantee a 
minimal level of video interoperability. It's for sure an inconvenience, 
but so is firewall traversal.


Maik

From lijing80@huawei.com  Wed Nov 20 03:22:40 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A73A1ADBD4 for ; Wed, 20 Nov 2013 03:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.725
X-Spam-Level: 
X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roxc9zuSdn0Q for ; Wed, 20 Nov 2013 03:22:37 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 271FB1AD8DC for ; Wed, 20 Nov 2013 03:22:37 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYD12464; Wed, 20 Nov 2013 11:22:30 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 11:22:20 +0000
Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 11:22:28 +0000
Received: from szxeml558-mbs.china.huawei.com ([169.254.8.146]) by szxeml456-hub.china.huawei.com ([10.82.67.199]) with mapi id 14.03.0158.001; Wed, 20 Nov 2013 19:22:24 +0800
From: "Lijing (Jessie)" 
To: "justin@uberti.name" 
Thread-Topic: "pranswer" be applied as an update to a previously sent "answer"?
Thread-Index: Ac7l4scu/mHtTyeMTCWCotMxqofkyw==
Date: Wed, 20 Nov 2013 11:22:23 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.171.171]
Content-Type: multipart/alternative; boundary="_000_A3045C90BB645147BC99159AA47ABAC748C3DACBszxeml558mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "rtcweb@ietf.org" 
Subject: [rtcweb] "pranswer" be applied as an update to a previously sent "answer"?
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 11:22:40 -0000

--_000_A3045C90BB645147BC99159AA47ABAC748C3DACBszxeml558mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

draft-ietf-rtcweb-jsep-05 -----Section 4.1.3 says:

"pranswer" indicates that a description should be parsed as an
   answer, but not a final answer, and so should not result in the
   freeing of allocated resources.  It may result in the start of media
   transmission, if the answer does not specify an inactive media
   direction.  A description used as a "pranswer" may be applied as a
   response to an "offer", or an update to a previously sent "answer".

How can a pranswer be applied as an update to a previously sent answer?  I =
am not sure what's the corresponding scenario.
>From the state machine perspective, when answer is received, it enters the =
stable state. At this point, the state machine can not directly jump to loc=
al pranswer or remote pranswer state.

My two cents: May be it needs more description or correction here.


________________________________
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com
Email: lijing80@huawei.com
________________________________


--_000_A3045C90BB645147BC99159AA47ABAC748C3DACBszxeml558mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









    

    draft-ietf-rtcweb-jsep-05 -----=
Section 4.1.3 says:
    

     
    

    "pranswer" indicates that a descrip=
tion should be parsed as an
    

       answer, but not a final answer, =
and so should not result in the
    

       freeing of allocated resources.&=
nbsp; It may result in the start of media
    

       transmission, if the answer does=
 not specify an inactive media
    

       direction.  A description u=
sed as a "pranswer" may be applied as a
    

       response to an &qu=
ot;offer", or
an update to a previously sent "answer"=
.
    

     
    

    How can a pranswer be applied a=
s an update to a previously sent answer?  I am not sure what’s t=
he corresponding scenario.

    

    From the state machine perspect=
ive, when answer is received, it enters the stable state. At this point, th=
e state machine can not directly jump to local pranswer or remote pranswer =
state.
    

     
    

    My two cents: May be it needs m=
ore description or correction here.
    

     
    

     
    

    

    

    

    Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
    
http://www.huawei.com
    

    Email: lijing80@huawei.com

    

    

    

    

     
    

    



--_000_A3045C90BB645147BC99159AA47ABAC748C3DACBszxeml558mbschi_--

From bernard_aboba@hotmail.com  Wed Nov 20 09:44:16 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C99A1AE082 for ; Wed, 20 Nov 2013 09:44:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWkrXp5c7UAy for ; Wed, 20 Nov 2013 09:44:14 -0800 (PST)
Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by ietfa.amsl.com (Postfix) with ESMTP id 52DE61ADFF9 for ; Wed, 20 Nov 2013 09:44:14 -0800 (PST)
Received: from BLU169-W19 ([65.55.111.71]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 20 Nov 2013 09:44:08 -0800
X-TMN: [C33yy3ePv7w6k5HhBFppmeoY3jO6LQGPMzv8L3CAOMk=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_e48e23b2-122c-4dec-a2bb-4f7d9f9a73cf_"
From: Bernard Aboba 
To: Maik Merten 
Date: Wed, 20 Nov 2013 09:44:07 -0800
Importance: Normal
In-Reply-To: <528C79AD.10608@googlemail.com>
References: , , <52891EDB.2050607@googlemail.com>, , , , <528B2ABE.4040701@googlemail.com>, , <528C79AD.10608@googlemail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Nov 2013 17:44:08.0259 (UTC) FILETIME=[1D206930:01CEE618]
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 17:44:16 -0000

--_e48e23b2-122c-4dec-a2bb-4f7d9f9a73cf_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Maik said:=20

> Cisco's offer=2C while certainly useful in some (or even many) applicatio=
n=20
> contexts=2C cannot cover all relevant deployment scenarios.=20
[BA] I'd note that the current IETF discussion of MTI video codecs is somew=
hat similar to a previous discussion in W3C relating to the MTI codec for s=
treaming video.   In that previous discussion=2C advocates of the potential=
 MTI codecs offered to implement their preferred codec for other browsers. =
 So if past is prologue=2C other offers may emerge over time.=20

> Without a fallback codec there will be negotiation failure in ways that a=
re out of control of the affected users.=20

[BA] In practice=2C negotiation failure is annoying enough that customers a=
nd users are going to demand that it be addressed in some fashion.  This co=
uld be via native implementation of multiple codecs=2C via codec plugins as=
 Cisco has proposed=2C or via on-premise or cloud-based transcoding solutio=
ns as Justin has described.   Given the penalties that the marketplace will=
 impose on services that don't address interoperability in some fashion=2C =
it seems to me that the issue is very likely to be addressed in practice=2C=
 at least for commercial services. =20
On the other hand=2C  attempting to impose a solution that has no real cons=
ensus could do real damage=2C by diverting resources away from implementing=
 leading edge codecs (e.g. VP9 and HEVC) or polishing the WebRTC protocol s=
pecifications so as to fully enable multi-codec support=2C which is going t=
o necessary whichever camp you're in.  		 	   		  =

--_e48e23b2-122c-4dec-a2bb-4f7d9f9a73cf_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





    Maik said: =3B

    &=
gt=3B Cisco's offer=2C while certainly useful in some (or even many) applic=
ation 
    >=3B contexts=2C cannot cover all relevant deployment scenarios=
. =3B

    [BA] I'd note that the current IETF disc=
ussion of MTI video codecs is somewhat similar to a previous discussion in =
W3C relating to the MTI codec for streaming video.  =3B In that previou=
s discussion=2C advocates of the potential MTI codecs offered to implement =
their preferred codec for other browsers.  =3BSo if past is prologue=2C=
 other offers may emerge over time. =3B

    &g=
t=3B Without a fallback codec there will be negotiation failure in ways tha=
t =3Bare out of control of the affected users. =3B
    [BA] In practice=2C negotiation failure is annoying enough tha=
t customers and users are going to demand that it be addressed in some fash=
ion.  =3BThis could be via native implementation of multiple codecs=2C =
via codec plugins as Cisco has proposed=2C or via on-premise or cloud-based=
 transcoding solutions as Justin has described.  =3B Given the penaltie=
s that the marketplace will impose on services that don't address interoper=
ability in some fashion=2C it seems to me that the issue is very likely to =
be addressed in practice=2C at least for commercial services.  =3B

    On the other hand=2C  =3Battempting to impose a=
 solution that has no real consensus could do real damage=2C by diverting r=
esources away from implementing leading edge codecs (e.g. VP9 and HEVC) or =
polishing the WebRTC protocol specifications so as to fully enable multi-co=
dec support=2C which is going to necessary whichever camp you're in. =
=3B
     		 	   		  
    
=

--_e48e23b2-122c-4dec-a2bb-4f7d9f9a73cf_--

From bernard_aboba@hotmail.com  Wed Nov 20 09:52:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB3A1AE0CE for ; Wed, 20 Nov 2013 09:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-B-pkrEESnt for ; Wed, 20 Nov 2013 09:52:11 -0800 (PST)
Received: from blu0-omc3-s32.blu0.hotmail.com (blu0-omc3-s32.blu0.hotmail.com [65.55.116.107]) by ietfa.amsl.com (Postfix) with ESMTP id A78001AE0A2 for ; Wed, 20 Nov 2013 09:52:11 -0800 (PST)
Received: from BLU169-W140 ([65.55.116.73]) by blu0-omc3-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 20 Nov 2013 09:52:05 -0800
X-TMN: [nEuJGZBOoIdXTSOvRvvsIdYyECN2qkWjbyCmOMu8EQI=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_c9137f37-9169-40c3-816c-50ea5617d178_"
From: Bernard Aboba 
To: "rtcweb@ietf.org" 
Date: Wed, 20 Nov 2013 09:52:04 -0800
Importance: Normal
In-Reply-To: <526C6C21.90602@it.aoyama.ac.jp>
References: , <526C6C21.90602@it.aoyama.ac.jp>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Nov 2013 17:52:05.0226 (UTC) FILETIME=[396BCCA0:01CEE619]
Subject: Re: [rtcweb] Performance of H.264...
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 17:52:13 -0000

--_c9137f37-9169-40c3-816c-50ea5617d178_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sorry to interrupt the ongoing codec rant-o-rama=2C but some may find the f=
ollowing pre-print paper of interest: http://iphome.hhi.de/marpe/download/P=
erformance_HEVC_VP9_X264_PCS_2013_preprint.pdf 		 	   		  =

--_c9137f37-9169-40c3-816c-50ea5617d178_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





    Sorry to interrupt the ongoing c=
odec rant-o-rama=2C but some may find the following pre-print paper of inte=
rest: =3B=
 		 	   		  
    
=

--_c9137f37-9169-40c3-816c-50ea5617d178_--

From bernard_aboba@hotmail.com  Wed Nov 20 10:07:56 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90371AE203 for ; Wed, 20 Nov 2013 10:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1ym3NnSESPE for ; Wed, 20 Nov 2013 10:07:55 -0800 (PST)
Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC801AE107 for ; Wed, 20 Nov 2013 10:07:55 -0800 (PST)
Received: from BLU169-W108 ([65.55.116.72]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 20 Nov 2013 10:07:49 -0800
X-TMN: [a78youuQw9gXoSIOM83/V2MqWGMoX2oQdf1+5FWix40=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_bc3de97a-5f58-49d6-8d7b-f130d728df1e_"
From: Bernard Aboba 
To: Magnus Westerlund , "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" , Eric Rescorla 
Date: Wed, 20 Nov 2013 10:07:48 -0800
Importance: Normal
In-Reply-To: <5285E318.3090006@ericsson.com>
References: , <5285E318.3090006@ericsson.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Nov 2013 18:07:49.0181 (UTC) FILETIME=[6C0FE6D0:01CEE61B]
Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 18:07:57 -0000

--_bc3de97a-5f58-49d6-8d7b-f130d728df1e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I have a meta-question about consent freshness=2C which is whether it is st=
ill necessary if  DTLS/SRTP is both mandatory both to implement as well as =
to use (e.g. we could use DTLS heartbeat extension RFC 6520 instead).  		 	=
   		  =

--_bc3de97a-5f58-49d6-8d7b-f130d728df1e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





    I have a meta-question about con=
sent freshness=2C which is whether it is still necessary if  =3BDTLS/SR=
TP is both mandatory both to implement as well as to use (e.g. we could use=
 DTLS heartbeat extension RFC 6520 instead). =3B 		 	   		  
    
=

--_bc3de97a-5f58-49d6-8d7b-f130d728df1e_--

From martin.thomson@gmail.com  Wed Nov 20 10:27:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD54F1AE471 for ; Wed, 20 Nov 2013 10:27:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcFUt8TGhams for ; Wed, 20 Nov 2013 10:27:12 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC141AE434 for ; Wed, 20 Nov 2013 10:27:12 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id l18so1199652wgh.18 for ; Wed, 20 Nov 2013 10:27:05 -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=I73OqZ4SoC49XeP+MTFAGPDoouN5Jkwq2kj1LXCcW6A=; b=giFYvocg5owuBMWC5nubN/26F5+w1dKSeGeJM9DWD4R6U8p91KNH3PcnClT4J/nZxX 1ygXT44dHG4/KXk2up87f+COQnnohx9hpdDO/PmebktlRo1c9PE5pYLG1TZU6mdQKlTb lw7IiXomAm1ZjgjsC89JBBvR32GYftG/C3EoWb/sWzSjhGExiNTc/GQAd4zLvXm33DNA oanG1yt8LPwxngWkWn9DduZayUDrUkqulZ++G2pEyBJelGNnDlDcBD0eFvCga4NsGYow HBbnwclWzMKj8CyuArIsveK0PcAEXuj31Y3mDGcBN6ndZLBZ5z0EcnvswnDjNJtqx6LR J0Kw==
MIME-Version: 1.0
X-Received: by 10.194.61.84 with SMTP id n20mr1840023wjr.61.1384972025375; Wed, 20 Nov 2013 10:27:05 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Wed, 20 Nov 2013 10:27:05 -0800 (PST)
In-Reply-To: 
References:  <5285E318.3090006@ericsson.com> 
Date: Wed, 20 Nov 2013 10:27:05 -0800
Message-ID: 
From: Martin Thomson 
To: Bernard Aboba 
Content-Type: text/plain; charset=UTF-8
Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 18:27:14 -0000

On 20 November 2013 10:07, Bernard Aboba  wrote:
> I have a meta-question about consent freshness, which is whether it is still
> necessary if  DTLS/SRTP is both mandatory both to implement as well as to
> use (e.g. we could use DTLS heartbeat extension RFC 6520 instead).

Funny you should mention that.  You are by no means the first person
to ask this question.

In fact, I went so far as to write up a draft during the WebRTC
meeting last week.  Dan and I have been going back and forth on a
number of aspects, but I think that it's at least in good enough shape
to put up for wider discussion.

  http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00

Overall, I think that this is cleaner.  The main advantage is that any
authenticated data counts toward refreshing consent.  That means zero
overhead in many common cases.

From bernard_aboba@hotmail.com  Wed Nov 20 10:31:45 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CF11ADFEF for ; Wed, 20 Nov 2013 10:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6d9Tj9L2Waw for ; Wed, 20 Nov 2013 10:31:44 -0800 (PST)
Received: from blu0-omc4-s35.blu0.hotmail.com (blu0-omc4-s35.blu0.hotmail.com [65.55.111.174]) by ietfa.amsl.com (Postfix) with ESMTP id 243941AE042 for ; Wed, 20 Nov 2013 10:31:44 -0800 (PST)
Received: from BLU169-W114 ([65.55.111.135]) by blu0-omc4-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 20 Nov 2013 10:31:37 -0800
X-TMN: [qCBCU4g6b20WjyebQofFaq47iqoXxaRuSCXy+VT7i9A=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_e9a2da2e-d196-489f-ab77-703f07e32921_"
From: Bernard Aboba 
To: Martin Thomson 
Date: Wed, 20 Nov 2013 10:31:37 -0800
Importance: Normal
In-Reply-To: 
References: , <5285E318.3090006@ericsson.com>, , 
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Nov 2013 18:31:37.0393 (UTC) FILETIME=[BF57C210:01CEE61E]
Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 18:31:45 -0000

--_e9a2da2e-d196-489f-ab77-703f07e32921_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> I think that it's at least in good enough shape to put up for wider discu=
ssion.
> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00
>=20
> Overall=2C I think that this is cleaner.  The main advantage is that any
> authenticated data counts toward refreshing consent.  That means zero
> overhead in many common cases.

[BA] I have to agree that it is worth discussing=2C particularly given the =
potential for zero additional overhead.  		 	   		  =

--_e9a2da2e-d196-489f-ab77-703f07e32921_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





    >=3B I think that it's at=
 least in good enough shape =3Bto put up for wider discussion.
    >=
=3B http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00
    >=3B >=3B Overall=2C I think that this is cleaner.  The main advantage is th=
at any
    >=3B authenticated data counts toward refreshing consent.  That=
 means zero
    >=3B overhead in many common cases.

    [BA] I have to agree that it is worth discussing=2C particularly giv=
en the potential for zero additional overhead. =3B
     		 	   		  
=

--_e9a2da2e-d196-489f-ab77-703f07e32921_--

From maikmerten@googlemail.com  Wed Nov 20 10:45:53 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2BA1AE063 for ; Wed, 20 Nov 2013 10:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3lFcK4MR46F for ; Wed, 20 Nov 2013 10:45:51 -0800 (PST)
Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD751AE04D for ; Wed, 20 Nov 2013 10:45:51 -0800 (PST)
Received: by mail-ee0-f48.google.com with SMTP id e49so4203873eek.21 for ; Wed, 20 Nov 2013 10:45:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JMdUY4btTHDguqC/spuK6V6Y7oEelV/1H4HDNggyqpQ=; b=MIjF2QEBtpsL9NPsXmmdyqc/gxBc7OB3e/WfTGIVNEQIzuTMz55QLqKlgQ1tByrJka z5gyZXy7q4+8fjtu4yUHZnPg01deZ1x0Z3vaGNXMqoS5aG3IZrEK7D2ROp0Qr1Pha3Sg yg4U5wNN4uNMN7hR8x/PZuZOcO5z4lNcvX78E6RqMykBfQ1mYgLFqkZRsgnS69f6L2Gr e7Oju7tN8FuJDiWHg6dwsZhW982RFl1W+GH57KOhmX3aVfuD4yiG/8ThAMPTpSTPsIHv lpmbJF/a06tk1+5ZjOQcjlTog1GRnTYrnd4GTW2AJplkjRQmhreuVkNLtOzo4UR8e4G/ btUw==
X-Received: by 10.14.205.8 with SMTP id i8mr2764024eeo.19.1384973144401; Wed, 20 Nov 2013 10:45:44 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id h48sm6530538eev.3.2013.11.20.10.45.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 10:45:43 -0800 (PST)
Message-ID: <528D0355.3090603@googlemail.com>
Date: Wed, 20 Nov 2013 19:45:41 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: , , <52891EDB.2050607@googlemail.com>, , , , <528B2ABE.4040701@googlemail.com>, , <528C79AD.10608@googlemail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 18:45:53 -0000

Dear Bernhard,

I'm completely with you regarding that a reliable mechanism for 
multi-codec handling is needed, no matter the outcome of the codec 
discussion. After all, everybody will want to deploy new codec 
technology in the future.

I also think that pressure from customers will eventually lead to 
transcoding services being offered to serve as a bandaid in case no 
consensus can be achieved. I'm saying "bandaid" here, because I suspect 
that in practice such transcoding services will introduce costs (which 
may not be acceptable to new players), increase latency (always not so 
nice), and possibly introduce single points of failure (nasty for 
everyone). Reliance on such services would be a admittance of failure 
regarding P2P interoperability.

(Personally, I would consider it a grave specification bug if users 
cannot reliably establish even a basic, direct video call, with every 
involved entity adhering to the spec and network conditions permitting.)

You're of course right that mandating something without consensus cannot 
possibly be solution. I'm just hoping there's consensus that P2P 
interoperability does matter. From my point of view H.261 is an option 
that can enable (very) basic video interoperability (engineering 
perspective) and also is trouble-free regarding IPR (legal perspective, 
which appears to be what's making consensus on codecs difficult). Having 
a solution that engineers can implement and lawyers can agree to seems 
to be a rare constellation. It's up to implementers to decide if they 
are willing to make use of it to achieve basic interoperability.


Best regards,

Maik



Am 20.11.2013 18:44, schrieb Bernard Aboba:
> Maik said:
>
>  > Cisco's offer, while certainly useful in some (or even many) application
>  > contexts, cannot cover all relevant deployment scenarios.
>
> [BA] I'd note that the current IETF discussion of MTI video codecs is
> somewhat similar to a previous discussion in W3C relating to the MTI
> codec for streaming video.   In that previous discussion, advocates of
> the potential MTI codecs offered to implement their preferred codec for
> other browsers.  So if past is prologue, other offers may emerge over time.
>
>  > Without a fallback codec there will be negotiation failure in ways
> that are out of control of the affected users.
>
> [BA] In practice, negotiation failure is annoying enough that customers
> and users are going to demand that it be addressed in some fashion.
>   This could be via native implementation of multiple codecs, via codec
> plugins as Cisco has proposed, or via on-premise or cloud-based
> transcoding solutions as Justin has described.   Given the penalties
> that the marketplace will impose on services that don't address
> interoperability in some fashion, it seems to me that the issue is very
> likely to be addressed in practice, at least for commercial services.
>
> On the other hand,  attempting to impose a solution that has no real
> consensus could do real damage, by diverting resources away from
> implementing leading edge codecs (e.g. VP9 and HEVC) or polishing the
> WebRTC protocol specifications so as to fully enable multi-codec
> support, which is going to necessary whichever camp you're in.


From maikmerten@googlemail.com  Wed Nov 20 11:08:23 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FC41AE0F1 for ; Wed, 20 Nov 2013 11:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 221Zh3fu7RNK for ; Wed, 20 Nov 2013 11:08:22 -0800 (PST)
Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 29E911AE0DE for ; Wed, 20 Nov 2013 11:08:22 -0800 (PST)
Received: by mail-ea0-f176.google.com with SMTP id h14so1866483eaj.7 for ; Wed, 20 Nov 2013 11:08:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JY/xh3mgP2MPXce/dXO8xLr6qT5xwXs9Q3xJdnwEsYs=; b=gmwtK+1nW0k1NlN6CGAnEAYFZ4UWxFMYelHfRUwiq2bzADNkS4IgL0Z9ZX+6fOKho+ kJr9golvAbXa5uQroxfQUre28fTVvgj1/EvOmOffzmm0g1lEpttCHGjpWtlhtx97ef8d 9jhL6jOmjSOzuPQQFZ04/zG9IUdGaHSKqpP9j0bv2K1G21Hc4wu+hknScNXRujYliLX5 17klDV7hWtMn5NeHbuh1FLqOp9OCuLSIgiMnTaQ1rEEvSRNv9KcZViqfnl84VKSLc9RS Npqbk9HZ0Jlvr1hHMu+ijuRVbSBzJ9MN9Igrd9WdwFrKNat3+Aa7seWsEgme0bG0OhTg bx0w==
X-Received: by 10.14.241.76 with SMTP id f52mr40737eer.53.1384974495088; Wed, 20 Nov 2013 11:08:15 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id o1sm5519005eea.10.2013.11.20.11.08.13 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 11:08:14 -0800 (PST)
Message-ID: <528D089C.9060700@googlemail.com>
Date: Wed, 20 Nov 2013 20:08:12 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: , <526C6C21.90602@it.aoyama.ac.jp> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Performance of H.264...
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 19:08:24 -0000

Am 20.11.2013 18:52, schrieb Bernard Aboba:
> Sorry to interrupt the ongoing codec rant-o-rama, but some may find the
> following pre-print paper of interest:
> http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_preprint.pdf

There's much to be said about PSNR as means for comparing image quality. 
There's also much to be said about PSNR as means for conducting 
cross-codec quality assessments.

And little of it is pretty.

I always chuckle when I see x264 being given the "--tune psnr" 
parameter. Even core developers of x264 have strong opinions on this: 
http://x264dev.multimedia.cx/archives/458



Maik


From bernard_aboba@hotmail.com  Wed Nov 20 11:23:41 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD121AE0C3 for ; Wed, 20 Nov 2013 11:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WswJdafZjJIy for ; Wed, 20 Nov 2013 11:23:40 -0800 (PST)
Received: from blu0-omc2-s11.blu0.hotmail.com (blu0-omc2-s11.blu0.hotmail.com [65.55.111.86]) by ietfa.amsl.com (Postfix) with ESMTP id C4A281AE071 for ; Wed, 20 Nov 2013 11:23:40 -0800 (PST)
Received: from BLU169-W137 ([65.55.111.71]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 20 Nov 2013 11:23:34 -0800
X-TMN: [UtZORJJP4OZzlrn4TjgNZLda/yJPfHhRRz1rEu9Vy88=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_80363990-e719-48b0-abff-f9ffab09b95e_"
From: Bernard Aboba 
To: Maik Merten , "rtcweb@ietf.org" 
Date: Wed, 20 Nov 2013 11:23:33 -0800
Importance: Normal
In-Reply-To: <528D089C.9060700@googlemail.com>
References: , , <526C6C21.90602@it.aoyama.ac.jp>, , <528D089C.9060700@googlemail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Nov 2013 19:23:34.0318 (UTC) FILETIME=[012CC4E0:01CEE626]
Subject: Re: [rtcweb] Performance of H.264...
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 19:23:42 -0000

--_80363990-e719-48b0-abff-f9ffab09b95e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> There's much to be said about PSNR as means for comparing image quality.=
=20
[BA] Section III A states that the comparison really doesn't relate to inte=
ractive/low delay uses (e.g. use of B frames=2C etc.) which is what we'd ca=
re about on this mailing list.   But it's the first study of its kind so it=
 seemed worth posting a link to (in hopes that someone else might have a li=
nk to something more relevant).  		 	   		  =

--_80363990-e719-48b0-abff-f9ffab09b95e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





    >=3B There's much to be s=
aid about PSNR as means for comparing image quality. =3B

    =

    [BA] Section III A states that the comparison really doesn't rel=
ate to interactive/low delay uses (e.g. use of B frames=2C etc.) which is w=
hat we'd care about on this mailing list.  =3B But it's the first study=
 of its kind so it seemed worth posting a link to (in hopes that someone el=
se might have a link to something more relevant). =3B
     		 	   		  =

    
=

--_80363990-e719-48b0-abff-f9ffab09b95e_--

From john@jlc.net  Wed Nov 20 11:26:01 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357801AE027 for ; Wed, 20 Nov 2013 11:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.725
X-Spam-Level: 
X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vks3A-RlHgGu for ; Wed, 20 Nov 2013 11:25:59 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5D31ADF7F for ; Wed, 20 Nov 2013 11:25:59 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id AD68CC94A8; Wed, 20 Nov 2013 14:25:50 -0500 (EST)
Date: Wed, 20 Nov 2013 14:25:50 -0500
From: John Leslie 
To: Maik Merten 
Message-ID: <20131120192550.GA34900@verdi>
References: <526C6C21.90602@it.aoyama.ac.jp>  <528D089C.9060700@googlemail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <528D089C.9060700@googlemail.com>
User-Agent: Mutt/1.4.1i
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Performance of H.264...
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 19:26:01 -0000

Maik Merten  wrote:
> Am 20.11.2013 18:52, schrieb Bernard Aboba:
> 
>> http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_preprint.pdf
> 
> There's much to be said about PSNR as means for comparing image quality. 
> There's also much to be said about PSNR as means for conducting 
> cross-codec quality assessments.
> 
> And little of it is pretty.

   I don't think we need to pick on the authors here -- they were quite
clear about what they were doing.

   IMHO, the point to take away from the paper is that _neither_ H.264
nor VP8 are considered "current" first choices.

   The paper basically showed _by_how_much_ H.264 falls short of current
state-of-the-art.

> I always chuckle when I see x264 being given the "--tune psnr" 
> parameter. Even core developers of x264 have strong opinions on this: 
> http://x264dev.multimedia.cx/archives/458

   Fun reading...

   But we _don't_ need any more lengthy criticisms of comparisons right
now. We _aren't_ going to drop everything and switch to H.265 as MTI --
or any other state-of-the-art codec.

   I fully agree that both H.264 and VP8 deserve SHOULD status; and
I agree H.261, being good enough for sign-language reading, looks like
the right fallback.

   H.261 is certainly easy enough to "implement" and deploy; and I'll
bet 80%  of us are ready for the question...

--
John Leslie 

From stewe@stewe.org  Wed Nov 20 11:40:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3B61AE055 for ; Wed, 20 Nov 2013 11:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QsPcy8VQpVw for ; Wed, 20 Nov 2013 11:40:25 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7EA1AE162 for ; Wed, 20 Nov 2013 11:40:24 -0800 (PST)
Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB362.namprd07.prod.outlook.com (10.141.75.21) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 20 Nov 2013 19:40:16 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.99]) with mapi id 15.00.0820.005; Wed, 20 Nov 2013 19:40:15 +0000
From: Stephan Wenger 
To: Bernard Aboba , Maik Merten , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Performance of H.264...
Thread-Index: AQHO5hk+oT4X9Wzm8UyORPNQmBT585oue4QAgAAESoD//36IAA==
Date: Wed, 20 Nov 2013 19:40:14 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.220.22]
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(2656002)(80022001)(81342001)(66066001)(47976001)(51856001)(87266001)(87936001)(4396001)(50986001)(49866001)(16236675002)(47736001)(65816001)(53806001)(54356001)(46102001)(77096001)(56816003)(83072001)(63696002)(85306002)(15975445006)(19580395003)(74876001)(74706001)(76786001)(54316002)(83322001)(36756003)(80976001)(19580405001)(77982001)(59766001)(74662001)(47446002)(81542001)(74366001)(81686001)(56776001)(76482001)(76796001)(69226001)(79102001)(76176001)(31966008)(81816001)(74502001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB362; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:160.79.220.22; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_CEB277B3AA931stewesteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] Performance of H.264...
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 19:40:28 -0000

--_000_CEB277B3AA931stewesteweorg_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


From: Bernard Aboba >
Date: Wednesday, 20 November, 2013 at 14:23
To: Maik Merten >, "rtcweb@ietf.org" >
Subject: Re: [rtcweb] Performance of H.264...

>> There's much to be said about PSNR as means for comparing image quality.

>[BA] Section III A states that the comparison really doesn't relate to int=
eractive/low delay uses (e.g. use of B frames, etc.) which is what we'd car=
e about on this mailing list.   But it's the first study of its kind so it =
seemed worth posting a link to (in hopes that someone else might have a lin=
k to something more relevant).

Ask, and it shall be given you; seek, and ye shall find...

See here: https://skydrive.live.com/view.aspx?resid=3DA6F8E452A49F023D!769&=
app=3DWordPdf&authkey=3D!AP15CciU4zPcTHc

This paper also compares codec operation points relevant for entertainment,=
 and does not focus on video conferencing (without I pictures).  However, s=
ince it contains data for both random access GOP structures and pure intra,=
 one could extrapolate pure predicted picture performance and arrive some c=
onclusion (which is left as an exercise for the reader :-)
Note that the use of B pictures is uncorrelated with the use in low delay e=
nvironments, and has been since at least 2003.  (In H.264 and later standar=
ds, both predictors of B pictures can point to the past.)  The use of B pic=
tures nowadays is almost exclusively a complexity question.

Stephan


--_000_CEB277B3AA931stewesteweorg_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <39CE719551AF624AB6DB21309B7D39AE@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable








    

    


    
From: Bernard Aboba <bernard_aboba@hotmail.com>
    
Date: Wednesday, 20 November, 2013 =
at 14:23

    
To: Maik Merten <maikmerten@googlemail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
    
Subject: Re: [rtcweb] Performance o=
f H.264...
    

    


    

    

    

    

    

    >> There's much to be said about PSNR as means for comparing ima=
ge quality. 
    


    

    

    >[BA] Section III A states that the comparison really doesn't relat=
e to interactive/low delay uses (e.g. use of B frames, etc.) which is what =
we'd care about on this mailing list.   But it's the first study of it=
s kind so it seemed worth posting a link
 to (in hopes that someone else might have a link to something more relevan=
t). 
    

    

    

    
    


    

    

    

    Ask, and it shall be given you; seek, and ye shall find…
    


    

    

    See here: https://skydrive.live.com/view.aspx?resid=3DA6F8E452A49F023D=
!769&app=3DWordPdf&authkey=3D!AP15CciU4zPcTHc
    


    

    

    This paper also compares codec operation points relevant for entertain=
ment, and does not focus on video conferencing (without I pictures).  =
However, since it contains data for both random access GOP structures and p=
ure intra, one could extrapolate pure
 predicted picture performance and arrive some conclusion (which is left as=
 an exercise for the reader :-)
    

    Note that the use of B pictures is uncorrelated with the use in low de=
lay environments, and has been since at least 2003.  (In H.264 and lat=
er standards, both predictors of B pictures can point to the past.)  T=
he use of B pictures nowadays is almost exclusively
 a complexity question.
    


    

    

    Stephan
    

    


    

    



--_000_CEB277B3AA931stewesteweorg_--

From xiphmont@gmail.com  Wed Nov 20 11:42:32 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728C91AE29E for ; Wed, 20 Nov 2013 11:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNgg9LPHvKKv for ; Wed, 20 Nov 2013 11:42:31 -0800 (PST)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id C0CB81AE1A6 for ; Wed, 20 Nov 2013 11:42:30 -0800 (PST)
Received: by mail-lb0-f181.google.com with SMTP id q8so6427429lbi.40 for ; Wed, 20 Nov 2013 11:42:23 -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=7xc98ZrTChyC8BHNyGpqMTkpzDWhGQ7c32pNmYaRaBY=; b=B89n7EH/N9ox6zhGid/yheW0rtD7EE7PftBEXuQMJRDYF0LBHY9u4T4Hh0ZSbXJ22/ ZlZL+GZ/+2Y0ycTx9ZjPNMRziToAhq79IDC4I6CC4MDeB6noJFVbp+NHFLlOZevtrQmO fCcpIUt0zN/2pRQOExHkyUEumRbQYtTNpd2BLZ0C2Hwg/H9bAJaqBDVR+igOlhuKMV4+ FUt0KdKclmGut7g+NIWqOWiRNI00KC7gLK2H93x9FSMdP1LBbJsr+A+a9y480FSWOQul pgoAk1iRNqxf84ytGduKeTxvZgWoYMb/BRvsm1EI17UqqVQayn+U2uBZBQTRSIxwdEOA 7rEQ==
MIME-Version: 1.0
X-Received: by 10.152.22.228 with SMTP id h4mr26978laf.71.1384976543534; Wed, 20 Nov 2013 11:42:23 -0800 (PST)
Received: by 10.112.128.202 with HTTP; Wed, 20 Nov 2013 11:42:23 -0800 (PST)
In-Reply-To: <20131120192550.GA34900@verdi>
References: <526C6C21.90602@it.aoyama.ac.jp>  <528D089C.9060700@googlemail.com> <20131120192550.GA34900@verdi>
Date: Wed, 20 Nov 2013 14:42:23 -0500
Message-ID: 
From: Monty Montgomery 
To: John Leslie 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Performance of H.264...
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 19:42:32 -0000

>  I don't think we need to pick on the authors here --

Yeah, actually we do.

> they were quite
> clear about what they were doing.

They were clear about what, 'why they think that's meaningful' is
considerably less clear.

>    IMHO, the point to take away from the paper is that _neither_ H.264
> nor VP8 are considered "current" first choices.
>
>    The paper basically showed _by_how_much_ H.264 falls short of current
> state-of-the-art.

No, PSNR is by itself a completely worthless metric for comparing two
different codecs.  Not 'lacking' but 'worthless'.

Monty

From singer@apple.com  Wed Nov 20 11:42:59 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CC41AE482 for ; Wed, 20 Nov 2013 11:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Level: 
X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdxKVMwxI3Uk for ; Wed, 20 Nov 2013 11:42:57 -0800 (PST)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7308D1AE47D for ; Wed, 20 Nov 2013 11:42:57 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWK00D3KUR82PO0@mail-out.apple.com> for rtcweb@ietf.org; Wed, 20 Nov 2013 11:42:51 -0800 (PST)
X-AuditID: 1180715a-b7f3c6d00000020e-c8-528d10ba8f42
Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay6.apple.com (Apple SCV relay) with SMTP id D6.15.00526.AB01D825; Wed, 20 Nov 2013 11:42:50 -0800 (PST)
Received: from [17.114.4.173] (unknown [17.114.4.173]) by cardamom.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWK004OXUREPG10@cardamom.apple.com> for rtcweb@ietf.org; Wed, 20 Nov 2013 11:42:50 -0800 (PST)
From: David Singer 
In-reply-to: <528D0355.3090603@googlemail.com>
Date: Wed, 20 Nov 2013 11:42:50 -0800
Content-transfer-encoding: quoted-printable
Message-id: <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com>
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1816)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FAcp7tLoDfIYMN0G4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XzGG5aCU9wVk/bOZ2xg7OfsYuTkkBAwkei6MZEdwhaTuHBv PVsXIxeHkMBEJolVu08zQjjzmSS2vpgMlOHgYBbQk7h/UQukgRfIPHrmNRNIWFjAUuLCcROQ MJuAqsSDOccYQWxOoJLb65+ygdgsQPGj62Yyg9jMAtoST95dYIUYYyOxqWs2O8SqN0wSTx50 gxWJCAhLbH3VywRxnKzExL8nGCcw8s9CuGIWkitmIRm7gJF5FaNAUWpOYqWZXmJBQU6qXnJ+ 7iZGcHgVRu1gbFhudYhRgINRiYe343FPkBBrYllxZe4hRgkOZiUR3vMcvUFCvCmJlVWpRfnx RaU5qcWHGKU5WJTEeVVndAcJCaQnlqRmp6YWpBbBZJk4OKUaGP2nPTSV3vP8ZHjRNYOTpw9e evpl7c1H1XznHBxfnJU97pRUKNXUt+txHd++NoaZreKiNU++H+L3k5r9c1/SA5YLjDo67k9i dkspXA1L0XbY4Nycv+hyVlTk+R1TnAXaXD7xnpi7t7k3svUhd+m61Y9m3NZSzxHh1sixbO+a cWnC14+bv7Gw8imxFGckGmoxFxUnAgC8j6rdKwIAAA==
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 19:42:59 -0000

I think we should think hard about H.263 instead of H.261 as the third =
fallback.  Why?

http://www.itu.int/rec/T-REC-H.263/



H.263 was first published in March 1996, so it's 17 years old.  The =
restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more =
recent amendments deal with this (and a plethora of other issues), so =
we=92d need to settle on which of those are mandatory (the usual =
profiling discussion).

There are 34 records in the patent database against H.261, mostly from =
1989 but one as recent as 2005 (though that is a re-file).  That's 2.2 =
(reciprocity), as was one other I checked.

Rather surprisingly, there are only 31 against H.263!  The most recent =
is 2011, and is also option 2.  Most are 1997-2001.


On this quick glance, H.263 appears no worse than H.261. IANAL (as I am =
sure you have all noticed).


H.263 is much more widely supported and mandated.  It has been mandated =
in the 3GPP specs for years (for lots of services, including videoconf), =
and is effectively the fallback codec today in the industry, as I =
understand.  It was ubiquitous in video telephony for years, and I =
suspect many of those systems still ship it.

So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 work?

(I am asking the question, not even answering on behalf of my company, =
yet.  Let=92s get the issues on the table.)


David Singer
Multimedia and Software Standards, Apple Inc.


From treising75@gmail.com  Wed Nov 20 13:53:32 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3FC1AE506 for ; Wed, 20 Nov 2013 13:53:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIM8CvsRI9Yl for ; Wed, 20 Nov 2013 13:53:30 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 81C401AE1F3 for ; Wed, 20 Nov 2013 13:53:30 -0800 (PST)
Received: by mail-lb0-f182.google.com with SMTP id u14so4377903lbd.13 for ; Wed, 20 Nov 2013 13:53:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=alOxzKq3/pTB5a0aSgbSXGlDLmPOlwua8zMErkXO6Hw=; b=GPJf2ovbI971LXmH2M3u5/eOJs2mNmPoFM4r2nmBaXHIjGU2mLF1Phpk3unSv2xYam 4XhPh0gPeJTyTKYi0IFKkOoeTzFrJY7Xe4eqbis702IcqFIqwcyI2H4kFKmt0O9NxOch rZwqAsrWaGZv41mv6FcaCI+A7t0O555MWAvVr9VmHuiC9pJhHxnl7q0JSRN4MxmBZELq 4NezM9krIU2t1HtRMzbZwZXxR8BAry20SyN1KC80iB1uhhxhqgFw1AQSMzpAGu9AV87J 6dU7u37jeyprxYs4GjHqrq2hD5Uh6qmTxEUJZ2tJQ6YgzLhzIJ/Vqy8x/iHMQgWtb8Ce xaMg==
X-Received: by 10.152.19.2 with SMTP id a2mr2109884lae.2.1384984403156; Wed, 20 Nov 2013 13:53:23 -0800 (PST)
Received: from [10.10.170.174] ([89.105.252.154]) by mx.google.com with ESMTPSA id sd11sm19134202lab.2.2013.11.20.13.53.21 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 13:53:21 -0800 (PST)
References: <526C6C21.90602@it.aoyama.ac.jp>  <528D089C.9060700@googlemail.com> <20131120192550.GA34900@verdi>
Mime-Version: 1.0 (1.0)
In-Reply-To: <20131120192550.GA34900@verdi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (11B554a)
From: Thomas Reisinger 
Date: Wed, 20 Nov 2013 23:53:21 +0200
To: John Leslie 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Performance of H.264...
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 21:53:32 -0000

=46rom my opinion we should stick with h.263 even the minimal risk or licenc=
es for the implementer. H261 is a no go for me.

Thomas Reisinger

> On 20.11.2013, at 21:25, John Leslie  wrote:
>=20
> Maik Merten  wrote:
>> Am 20.11.2013 18:52, schrieb Bernard Aboba:
>>=20
>>> http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_p=
reprint.pdf
>>=20
>> There's much to be said about PSNR as means for comparing image quality.=20=

>> There's also much to be said about PSNR as means for conducting=20
>> cross-codec quality assessments.
>>=20
>> And little of it is pretty.
>=20
>   I don't think we need to pick on the authors here -- they were quite
> clear about what they were doing.
>=20
>   IMHO, the point to take away from the paper is that _neither_ H.264
> nor VP8 are considered "current" first choices.
>=20
>   The paper basically showed _by_how_much_ H.264 falls short of current
> state-of-the-art.
>=20
>> I always chuckle when I see x264 being given the "--tune psnr"=20
>> parameter. Even core developers of x264 have strong opinions on this:=20
>> http://x264dev.multimedia.cx/archives/458
>=20
>   Fun reading...
>=20
>   But we _don't_ need any more lengthy criticisms of comparisons right
> now. We _aren't_ going to drop everything and switch to H.265 as MTI --
> or any other state-of-the-art codec.
>=20
>   I fully agree that both H.264 and VP8 deserve SHOULD status; and
> I agree H.261, being good enough for sign-language reading, looks like
> the right fallback.
>=20
>   H.261 is certainly easy enough to "implement" and deploy; and I'll
> bet 80%  of us are ready for the question...
>=20
> --
> John Leslie 
>=20

From basilgohar@librevideo.org  Wed Nov 20 13:57:30 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9C71AE580 for ; Wed, 20 Nov 2013 13:57:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level: 
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtfFSdyWbSDV for ; Wed, 20 Nov 2013 13:57:28 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFBB1AE576 for ; Wed, 20 Nov 2013 13:57:28 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id AF2E76531C0 for ; Wed, 20 Nov 2013 16:57:21 -0500 (EST)
Message-ID: <528D303F.6010302@librevideo.org>
Date: Wed, 20 Nov 2013 16:57:19 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <526C6C21.90602@it.aoyama.ac.jp>  <528D089C.9060700@googlemail.com> <20131120192550.GA34900@verdi> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Performance of H.264...
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 21:57:30 -0000

On 11/20/2013 04:53 PM, Thomas Reisinger wrote:
> From my opinion we should stick with h.263 even the minimal risk or licences for the implementer. H261 is a no go for me.
> 
> Thomas Reisinger

Thomas,

The point of choosing something aside from VP8 and H.264, which are both
superior to H.263, is to *completely* avoid all raised and known
licensing concerns in the mandatory part of the spec.

This is where H.261 has any value at all in this discussion, even more
so than any alleged quality tweaks and performance.  It is because any
rtcweb implementation can include a standards-compliant H.261 en/decoder
without worrying at all about patent risks.

If we're willing to accept even a small degree of patent risk, then that
opens up the door to formats far superior to H.261 and even H.263,
several of which have already been presented.

-- 
Libre Video
http://librevideo.org

From stewe@stewe.org  Wed Nov 20 14:14:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DF31AE084 for ; Wed, 20 Nov 2013 14:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3W9G-q-vGK4g for ; Wed, 20 Nov 2013 14:14:22 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id B65131AE01C for ; Wed, 20 Nov 2013 14:14:21 -0800 (PST)
Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB361.namprd07.prod.outlook.com (10.141.75.19) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 20 Nov 2013 22:14:09 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.99]) with mapi id 15.00.0820.005; Wed, 20 Nov 2013 22:14:08 +0000
From: Stephan Wenger 
To: Basil Mohamed Gohar , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Performance of H.264...
Thread-Index: AQHO5hk+oT4X9Wzm8UyORPNQmBT585oue4QAgAAE7QCAACk3gIAAARyA//9+kYA=
Date: Wed, 20 Nov 2013 22:14:07 +0000
Message-ID: 
In-Reply-To: <528D303F.6010302@librevideo.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.220.22]
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(479174003)(24454002)(189002)(199002)(51704005)(83322001)(36756003)(19580395003)(19580405001)(49866001)(56776001)(54316002)(81686001)(69226001)(56816003)(76176001)(51856001)(47736001)(74876001)(81342001)(83072001)(47976001)(80976001)(46102001)(50986001)(79102001)(77096001)(81816001)(47446002)(76796001)(4396001)(16601075003)(87936001)(76786001)(77982001)(74366001)(80022001)(31966008)(2656002)(74502001)(65816001)(53806001)(87266001)(74662001)(85306002)(63696002)(66066001)(76482001)(74706001)(59766001)(81542001)(54356001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB361; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:160.79.220.22; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0B059A5D084FBF469FDE492D0B01E40C@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] Performance of H.264...
X-BeenThere: rtcweb@ietf.org
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: Wed, 20 Nov 2013 22:14:24 -0000

Hi,
I believe you can indeed include an H.261 *de*coder without running
unmanageable risk, for pretty much every value of unmanageable.  The
*en*coder is much trickier, as you would have to ensure that your
non-standardized mechanisms are also not covered by enforceable patents.
H.261 *En*coders have never been standardized.
You could in theory implement, without deviation, RM8 (the final H.261
test model), published around the same time as H.261.
Stephan

On 11.20.2013, 16:57 , "Basil Mohamed Gohar" 
wrote:

>On 11/20/2013 04:53 PM, Thomas Reisinger wrote:
>> From my opinion we should stick with h.263 even the minimal risk or
>>licences for the implementer. H261 is a no go for me.
>>=20
>> Thomas Reisinger
>
>Thomas,
>
>The point of choosing something aside from VP8 and H.264, which are both
>superior to H.263, is to *completely* avoid all raised and known
>licensing concerns in the mandatory part of the spec.
>
>This is where H.261 has any value at all in this discussion, even more
>so than any alleged quality tweaks and performance.  It is because any
>rtcweb implementation can include a standards-compliant H.261 en/decoder
>without worrying at all about patent risks.
>
>If we're willing to accept even a small degree of patent risk, then that
>opens up the door to formats far superior to H.261 and even H.263,
>several of which have already been presented.
>
>--=20
>Libre Video
>http://librevideo.org
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb


From cowwoc@bbs.darktech.org  Wed Nov 20 17:49:09 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFA81ADEC1 for ; Wed, 20 Nov 2013 17:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zw2fXEP5gQsb for ; Wed, 20 Nov 2013 17:49:08 -0800 (PST)
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA081A802B for ; Wed, 20 Nov 2013 17:49:08 -0800 (PST)
Received: by mail-pa0-f48.google.com with SMTP id rd3so3584746pab.35 for ; Wed, 20 Nov 2013 17:49:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=YI/vdrAtlAmYP0moqPjThB+VzaYPT3BU1tzT3dASNB4=; b=imTC4i26YkZA4ZJ0Z94H9dM7t9calL7BbndyZaFtPmq4BcEUrV4EAwa51ccOQr9B6u uwhhlpMn6vey6IgwjGF/uOrD2C4qDzX3M3Ksr81s8xvlAOyW9DN929r6WLxmOFVkLn+5 A3PLFIh0rEHn2HiXU3AoyPFqX0sojrB5PZHDjZVCS9uafNg4CRMaZzZJyt859J9Byzdz BFc2I3U1cJ49L/J7sNqvnpN7EV8FSTICs28OGmkbwcPdr75XUzFSUVsgVkLXaPWz8l0j QLcgxqKdyH3vbbNazHiR7nYZbCQIVbnOHi2ojIAzytlUZyTP1s/QMdCWs+kDXnfwsNSI 43mQ==
X-Gm-Message-State: ALoCoQmzEe8vKoBU/nIIaeIJYaAyBRq/+ijGSM4Op7bGuoxJmhVpuhOBcIHFCA64xWXliB5MR542
X-Received: by 10.68.6.66 with SMTP id y2mr3746683pby.60.1384998541871; Wed, 20 Nov 2013 17:49:01 -0800 (PST)
Received: from [10.35.1.62] (sccc-66-78-236-243.smartcity.com. [66.78.236.243]) by mx.google.com with ESMTPSA id p1sm41297412pbo.12.2013.11.20.17.49.00 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 17:49:01 -0800 (PST)
Message-ID: <528D6688.8080507@bbs.darktech.org>
Date: Wed, 20 Nov 2013 17:48:56 -0800
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Any update on OpenH264?
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 01:49:10 -0000

Hi,

Does Cisco have an update on http://www.openh264.org/? When will 
https://github.com/cisco/openh264 be populated with a functional project?

Thank you,
Gili

From basilgohar@librevideo.org  Wed Nov 20 17:55:14 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5FB1ADBCC for ; Wed, 20 Nov 2013 17:55:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level: 
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y56QJJHxpi-D for ; Wed, 20 Nov 2013 17:55:13 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9C31AD94A for ; Wed, 20 Nov 2013 17:55:13 -0800 (PST)
Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id CDF0A6586EC for ; Wed, 20 Nov 2013 20:55:06 -0500 (EST)
Message-ID: <528D67F3.5070408@librevideo.org>
Date: Wed, 20 Nov 2013 20:54:59 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528D6688.8080507@bbs.darktech.org>
In-Reply-To: <528D6688.8080507@bbs.darktech.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Any update on OpenH264?
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 01:55:15 -0000

On 11/20/2013 08:48 PM, Gili wrote:
> Hi,
> 
> Does Cisco have an update on http://www.openh264.org/? When will
> https://github.com/cisco/openh264 be populated with a functional project?
> 
> Thank you,
> Gili

During the last IETF meeting, one of the presenters mentioned something
on the order of Christmas.

-- 
Libre Video
http://librevideo.org

From cowwoc@bbs.darktech.org  Wed Nov 20 18:14:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D961ADBCC for ; Wed, 20 Nov 2013 18:14:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egyKIfveWUlf for ; Wed, 20 Nov 2013 18:14:09 -0800 (PST)
Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by ietfa.amsl.com (Postfix) with ESMTP id 10BF11ACC88 for ; Wed, 20 Nov 2013 18:14:09 -0800 (PST)
Received: by mail-pd0-f177.google.com with SMTP id q10so5266478pdj.36 for ; Wed, 20 Nov 2013 18:14:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=lC9LmxIWjgseeYfh7OBpJaBuOGSJ6xy+Ai9PMD+5oWs=; b=U/nPMjCRox22WvqxymaVMBTNzS38viCaBYjHle08Sd10eYnXoJn5shD4783ecC18KE D9fKawzc+rQkx/Cna5+BiJfHrvSE1hYnboSf2Tio9VDDy9pg5102euqCRhvwxyiX9Bl3 RhlpoU9lLfl4j+zP3INYblg3Im7OQ9Y75WoriXF/OFo3qda6x1F2kVyv+lAcA5bDEHym 66slp70Myzzx0J4cuEH8gy39OXt4nPVxsSUjLcWKi470ACheZll2PfCa4FT7j5wFeGK3 XuPgmUic63LVV47ZB2sfQlURxCAFpnfbaLFhTwa+qgXHApfFNCl7suqAj67xssd9q8+y 44sw==
X-Gm-Message-State: ALoCoQkTciEGWK7k9yHK2CEJEzVurBjO0i0B0Mfp8MqBNOTe+YX7h1TKp5kk0rup9iTHBuxxGdrX
X-Received: by 10.66.148.97 with SMTP id tr1mr3668507pab.163.1385000041371; Wed, 20 Nov 2013 18:14:01 -0800 (PST)
Received: from [10.35.1.62] (sccc-66-78-236-243.smartcity.com. [66.78.236.243]) by mx.google.com with ESMTPSA id tu6sm41387506pbc.41.2013.11.20.18.13.59 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 18:14:00 -0800 (PST)
Message-ID: <528D6C63.7050607@bbs.darktech.org>
Date: Wed, 20 Nov 2013 18:13:55 -0800
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="------------090608080602030802010303"
Subject: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 02:14:10 -0000

This is a multi-part message in MIME format.
--------------090608080602030802010303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I'm at the WebRTC World conference. If I understood correctly, Zingaya 
just demoed what they claim is a VP8 to H.264 bridge that converts the 
video without transcoding. My interpretation is that they convert the 
surrounding packet format without re-encoding the actual video. Someone 
who understands codec internals (I don't) might want to validate this 
claim, because it could have a significant impact on the MTI debate.

It sounds far fetched, but imagine the possibilities:

 1. If the video is not being re-encoded, do H.264 royalties apply?
 2. If the conversion is really cheap, is it feasible to connect a H.264
    peer to a VP8 peer and have one of them convert in-line (no MCU)?

Gili


--------------090608080602030802010303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Hi,
    
    
    
    I'm at the WebRTC World conference. If I understood correctly,
    Zingaya just demoed what they claim is a VP8 to H.264 bridge that
    converts the video without transcoding. My interpretation is that
    they convert the surrounding packet format without re-encoding the
    actual video. Someone who understands codec internals (I don't)
    might want to validate this claim, because it could have a
    significant impact on the MTI debate.
    
    
    
    It sounds far fetched, but imagine the possibilities:
    
    
      
      
    1. If the video is not being re-encoded, do H.264 royalties
        apply?
      2. 
      
    2. If the conversion is really cheap, is it feasible to connect a
        H.264 peer to a VP8 peer and have one of them convert in-line
        (no MCU)?
      
      
      3. 
    
    
    
    Gili
    
    
    
  


--------------090608080602030802010303--

From fluffy@cisco.com  Wed Nov 20 20:21:11 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A171AE0B7 for ; Wed, 20 Nov 2013 20:21:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.026
X-Spam-Level: 
X-Spam-Status: No, score=-110.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8cYJPiY1-9x for ; Wed, 20 Nov 2013 20:21:10 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 42A391AE0AC for ; Wed, 20 Nov 2013 20:21:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14; q=dns/txt; s=iport; t=1385007664; x=1386217264; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=C3KnYIPoTMp4fzT2pXiVyoGvL0ntEZJaPMP+iFOYdFQ=; b=K7/Q5UR5pmOxKBe5avCCGhKDWKH7r7bBDH1OXvb+WGIjKqmxtfVq4E4T hMJ2qD33Q0mpVR68kT3I9KcoNOGmCTnbGslju0b0VUFg0NgRu8wnCoM3B 6C7ENxl3ulFtFMXpS0ioL9clyv1Yr7pTiKYKjNIw/vtxowiT190E4UOFU 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvgFAEWJjVKtJXG+/2dsb2JhbABZgwfAFBZtB4IsGSFRAT0BQiYBBIgUoE6gExeTEoESA5gSkg2DKA
X-IronPort-AV: E=Sophos;i="4.93,741,1378857600";  d="scan'208";a="1109296"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 21 Nov 2013 04:21:01 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAL4L12b027053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 21 Nov 2013 04:21:01 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 22:21:01 -0600
From: "Cullen Jennings (fluffy)" 
To: "rtcweb@ietf.org" 
Thread-Topic: The answer for gilli
Thread-Index: Ac7mcRVZT+q9wHdmT5u7J0Cog8XzBA==
Date: Thu, 21 Nov 2013 04:21:00 +0000
Message-ID: <53FD0F4B-6B6C-432D-A3A5-84161CC16F2A@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7E0EB7B629837547BB938D8E82C6C1F3@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [rtcweb] The answer for gilli
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 04:21:11 -0000

Christmas=20

From bossiel@yahoo.fr  Wed Nov 20 23:51:23 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9901AE08B for ; Wed, 20 Nov 2013 23:51:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0VBNkc_bmZh for ; Wed, 20 Nov 2013 23:51:22 -0800 (PST)
Received: from nm9-vm0.bullet.mail.ird.yahoo.com (nm9-vm0.bullet.mail.ird.yahoo.com [77.238.189.197]) by ietfa.amsl.com (Postfix) with ESMTP id E0DC81A1F78 for ; Wed, 20 Nov 2013 23:51:21 -0800 (PST)
Received: from [77.238.189.49] by nm9.bullet.mail.ird.yahoo.com with NNFMP; 21 Nov 2013 07:51:14 -0000
Received: from [46.228.39.97] by tm2.bullet.mail.ird.yahoo.com with NNFMP; 21 Nov 2013 07:51:14 -0000
Received: from [127.0.0.1] by smtp134.mail.ir2.yahoo.com with NNFMP; 21 Nov 2013 07:51:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1385020274; bh=p4W/1LZrbCYGfrgwEQMRX5BzfWQBg6T6JXKgt0TQov0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=5G04aFpQdLgCPRwTETqILx/V3+eA2Sg2dXp42Es+a1H4xdctvmuOAX7ivxyHAcN4iLJToQZc5Zx/x4IfVPfIfB9MWasRUfv6ERm99+4j4gDBErYepN+jHjTq16+EHZZ8cr9OT+fLf1woEXe/m8Nb/gRc3JaWdJf9EeRVMc+sb08=
X-Yahoo-Newman-Id: 471109.81794.bm@smtp134.mail.ir2.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: YCMJHVcVM1ltKvgZJvhSd9t28X6e.MRkw8Ms5sGttAcs4w1 CiuRITRNcVgLEvkbVUVbNn4kZCqTK4OYidfPRJl47A8L.7qaosYAwzAZDx64 SNNznxBChyAtSJMaMrJluE9BKRb65xFig3KYs6yugWns9W.Ot8ofZSaiCLrl NtcAy8yiYhXzi6eBZ.qY8iqtAL_1vmTD42k4.HKB5spLtP25r2gXMphIrZcg PtxH95rDgzKZJjLdl6DKes24zX7162zTj3HoqEkQvmztTiPinj8lqF7GrrjF _1XLXS5nkzMA8PNY.BAy0FCcl4JPaSDUkkokbrUu356AWtgT1JhBKJytswqC fpoNYP2sBUME8s1TK1l7ACSAUP48lcEdEUGS0QefuQrV.nnyVZPL8iX_N_.E 1NohIrhXprkUPma52VNu.uw15nCHV9DHzhtDKbCkDfOppaP0uC7vcTgPpSUW Ip31b85ilkKUxwGapo8HCWHJAffWYMk2ZDHwL84Ppab8waQLxI7RZCV1Op2C 8bcWpDS1EGobW5D2sLrH95gKRcrU-
X-Yahoo-SMTP: Dix.ZgGswBADJg.if3NVG_xX0Xc-
X-Rocket-Received: from [192.168.0.26] (bossiel@88.179.39.5 with ) by smtp134.mail.ir2.yahoo.com with SMTP; 21 Nov 2013 07:51:14 +0000 UTC
References: <528D6C63.7050607@bbs.darktech.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <528D6C63.7050607@bbs.darktech.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-B7014F6D-7FC3-447D-B39D-CF5A24F00FD2
Content-Transfer-Encoding: 7bit
Message-Id: <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr>
X-Mailer: iPhone Mail (10B350)
From: Bossiel 
Date: Thu, 21 Nov 2013 08:51:15 +0100
To: Gili 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 07:51:24 -0000

--Apple-Mail-B7014F6D-7FC3-447D-B39D-CF5A24F00FD2
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

This could be true if they can also walk on water and change it into wine.
To be serious, no it's not possible.
Mamadou

Sent from my iPhone

On Nov 21, 2013, at 3:13, Gili  wrote:

> Hi,
>=20
> I'm at the WebRTC World conference. If I understood correctly, Zingaya jus=
t demoed what they claim is a VP8 to H.264 bridge that converts the video wi=
thout transcoding. My interpretation is that they convert the surrounding pa=
cket format without re-encoding the     actual video. Someone who understand=
s codec internals (I don't) might want to validate this claim, because it co=
uld have a significant impact on the MTI debate.
>=20
> It sounds far fetched, but imagine the possibilities:
> If the video is not being re-encoded, do H.264 royalties apply?
> If the conversion is really cheap, is it feasible to connect a H.264 peer t=
o a VP8 peer and have one of them convert in-line (no MCU)?
> Gili
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

--Apple-Mail-B7014F6D-7FC3-447D-B39D-CF5A24F00FD2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


    This could be true if they can also walk on water and change it into wine.
    To be serious, no it's not possible.
    Mamadou

    Sent from my iPhone

    On Nov 21, 2013, at 3:13, Gili <cowwoc@bbs.darktech.org> wrote:

    
  

    
  
  
    Hi,
    
    
    
    I'm at the WebRTC World conference. If I understood correctly,
    Zingaya just demoed what they claim is a VP8 to H.264 bridge that
    converts the video without transcoding. My interpretation is that
    they convert the surrounding packet format without re-encoding the
    actual video. Someone who understands codec internals (I don't)
    might want to validate this claim, because it could have a
    significant impact on the MTI debate.
    
    
    
    It sounds far fetched, but imagine the possibilities:
    
    
      
      
    1. If the video is not being re-encoded, do H.264 royalties
        apply?
      2. 
      
    2. If the conversion is really cheap, is it feasible to connect a
        H.264 peer to a VP8 peer and have one of them convert in-line
        (no MCU)?
      
      
      3. 
    
    
    
    Gili
    
    
    
  


    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb
    
--Apple-Mail-B7014F6D-7FC3-447D-B39D-CF5A24F00FD2--

From cowwoc@bbs.darktech.org  Thu Nov 21 00:16:56 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460CD1AE10D for ; Thu, 21 Nov 2013 00:16:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvldlCPb5QpU for ; Thu, 21 Nov 2013 00:16:55 -0800 (PST)
Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id EBE0C1AC499 for ; Thu, 21 Nov 2013 00:16:54 -0800 (PST)
Received: by mail-pd0-f182.google.com with SMTP id v10so5276406pde.13 for ; Thu, 21 Nov 2013 00:16:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=56ErxUgDFHutsx9JNYcFi4NZpanyd/o1bmAZ4+NALg0=; b=Uzsh6dsOnnaykwzTSohAO/K6VEHzn+a59jh8G9XaXUGhrtYSvp8k8Z8kq8wsdo+C/7 iC013Vh1OHDFX+gnE7wxuHhSqQv1iFcvyPQ2LkvMV7yoJoj3zmdaldDPlLvh82W/9Ume 3StD8kKwslAp2GjcMxcrOjFTgEzEI2vf66WKCMXEjtVOXX67wOqLx8Z580w5D//zz8K5 bbXt2U8nBpUiE3UYQbO8l+fsd/h39YvFelgwjr6S3NewOrrEUkvOVzsmlKd79ZnzPhpN +t/qhp+/ZN5d5UfAA6eVv3CEa64OAMPBZm46sxtZutbp9zosjyAEImh/irPbdKEXYQKb Cnyg==
X-Gm-Message-State: ALoCoQlEYqkJC9s8sgx2pb02Vorj9XJnPgW8IZC8lXRbkF0w7lzPdRZ5pLlZPd6Z9j8OCJh/nrK+
X-Received: by 10.66.243.196 with SMTP id xa4mr522763pac.174.1385021808237; Thu, 21 Nov 2013 00:16:48 -0800 (PST)
Received: from [172.16.0.59] ([12.208.14.10]) by mx.google.com with ESMTPSA id er3sm43703505pbb.40.2013.11.21.00.16.46 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 00:16:47 -0800 (PST)
Message-ID: <528DC169.5050008@bbs.darktech.org>
Date: Thu, 21 Nov 2013 00:16:41 -0800
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528D6688.8080507@bbs.darktech.org> <528D67F3.5070408@librevideo.org>
In-Reply-To: <528D67F3.5070408@librevideo.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Any update on OpenH264?
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 08:16:56 -0000

Cullen and Basil,

That's excellent news! Thank you for the update :)

Gili

On 20/11/2013 5:54 PM, Basil Mohamed Gohar wrote:
> On 11/20/2013 08:48 PM, Gili wrote:
>> Hi,
>>
>> Does Cisco have an update on http://www.openh264.org/? When will
>> https://github.com/cisco/openh264 be populated with a functional project?
>>
>> Thank you,
>> Gili
> During the last IETF meeting, one of the presenters mentioned something
> on the order of Christmas.

On 20/11/2013 8:21 PM, Cullen Jennings wrote:
> Christmas


From magnus.westerlund@ericsson.com  Thu Nov 21 00:56:07 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85B51AC82A for ; Thu, 21 Nov 2013 00:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFFrYVLyayFL for ; Thu, 21 Nov 2013 00:56:05 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 02AB91A1F7E for ; Thu, 21 Nov 2013 00:56:04 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-c6-528dca9de32a
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 74.9E.03802.D9ACD825; Thu, 21 Nov 2013 09:55:57 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.2.328.9; Thu, 21 Nov 2013 09:55:52 +0100
Message-ID: <528DCA98.3040102@ericsson.com>
Date: Thu, 21 Nov 2013 09:55:52 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: David Singer , 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com>
In-Reply-To: <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3Vnfuqd4gg0vbTC3W/mtnt5jf/5HF gclj68kfbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4vPcfa8EToYo/u5QbGJv5uxg5OSQETCSm nr3MDmGLSVy4t56ti5GLQ0jgEKPE/uYtYAkhgeWMEsv2M4PYvALaEqveNrOB2CwCqhJ9/VvB atgELCRu/mgEi4sKBEtc7V0HVS8ocXLmExYQW0TATGL9+/+sXYwcHMIClhIXjptA7JrMLLF/ xncmkBpOAVuJHdMvsoHUSAiIS/Q0BoGEmQUMJI4smsMKYctLNG+dzQxxmrZEQ1MH6wRGwVlI ts1C0jILScsCRuZVjOy5iZk56eVGmxiB4Xhwy2/VHYx3zokcYpTmYFES5/3w1jlISCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA+PWKTp9E5yl/Jfa67gyeFe1cpX8Lqx+qsx74Ja8/8alav/y hY3vn1+63unO+jfhbF9XyDx7HTRpqnCllI+D1dVjy540Z3C/Vbdycphx93/QsmPGk4zsin6o dSwxm1PVsHN2kqHjEvadR97GfnBZefVSc9HSI292fX32vYhH7x5T+4qlh6+0fd2txFKckWio xVxUnAgANmJzvxUCAAA=
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 08:56:08 -0000

Dave,

Just to be clear. I will not add any new option to the list as I
understand this is currently a discussion piece. You and any other have
until the end of 27th of November to request an addition to the list of
alternatives.

Cheers

Magnus

On 2013-11-20 20:42, David Singer wrote:
> I think we should think hard about H.263 instead of H.261 as the third fallback.  Why?
> 
> http://www.itu.int/rec/T-REC-H.263/
> 
> 
> 
> H.263 was first published in March 1996, so it's 17 years old.  The restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more recent amendments deal with this (and a plethora of other issues), so we’d need to settle on which of those are mandatory (the usual profiling discussion).
> 
> There are 34 records in the patent database against H.261, mostly from 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2 (reciprocity), as was one other I checked.
> 
> Rather surprisingly, there are only 31 against H.263!  The most recent is 2011, and is also option 2.  Most are 1997-2001.
> 
> 
> On this quick glance, H.263 appears no worse than H.261. IANAL (as I am sure you have all noticed).
> 
> 
> H.263 is much more widely supported and mandated.  It has been mandated in the 3GPP specs for years (for lots of services, including videoconf), and is effectively the fallback codec today in the industry, as I understand.  It was ubiquitous in video telephony for years, and I suspect many of those systems still ship it.
> 
> So, would “MUST implement at least two of (H.264, VP8, H.263)” work?
> 
> (I am asking the question, not even answering on behalf of my company, yet.  Let’s get the issues on the table.)
> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From harald@alvestrand.no  Thu Nov 21 02:19:59 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426901AE08C for ; Thu, 21 Nov 2013 02:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.424
X-Spam-Level: 
X-Spam-Status: No, score=-7.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4zCHv5i1Osz for ; Thu, 21 Nov 2013 02:19:56 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4F11AD8E3 for ; Thu, 21 Nov 2013 02:19:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AE75A39E96F for ; Thu, 21 Nov 2013 11:19:49 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYfGN5jXhEVP for ; Thu, 21 Nov 2013 11:19:49 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E46FE39E10F for ; Thu, 21 Nov 2013 11:19:48 +0100 (CET)
Message-ID: <528DDE43.4080505@alvestrand.no>
Date: Thu, 21 Nov 2013 11:19:47 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: , <526C6C21.90602@it.aoyama.ac.jp> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030706070808080207090507"
Subject: Re: [rtcweb] Performance of H.264...
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 10:19:59 -0000

This is a multi-part message in MIME format.
--------------030706070808080207090507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 11/20/2013 06:52 PM, Bernard Aboba wrote:
> Sorry to interrupt the ongoing codec rant-o-rama, but some may find 
> the following pre-print paper of interest:
> http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_preprint.pdf

Yes, locking the QP on VP9 (and VP8) harms performance.



--------------030706070808080207090507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
    On 11/20/2013 06:52 PM, Bernard Aboba
      wrote:
    
    
    
    
    
      
      
    Sorry to interrupt the ongoing codec rant-o-rama,
        but some may find the following pre-print paper of interest: 
        
      
    
    
    
    
    
    Yes, locking the QP on VP9 (and VP8) harms performance.
    
    
    
    
    
  


--------------030706070808080207090507--

From harald@alvestrand.no  Thu Nov 21 04:20:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E369B1AE112 for ; Thu, 21 Nov 2013 04:20:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.424
X-Spam-Level: 
X-Spam-Status: No, score=-7.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voTD6LzHLxGv for ; Thu, 21 Nov 2013 04:19:58 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9334B1AE10F for ; Thu, 21 Nov 2013 04:19:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2749339EA1A for ; Thu, 21 Nov 2013 13:19:50 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k21abj5JQUO for ; Thu, 21 Nov 2013 13:19:49 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2614D39E38C for ; Thu, 21 Nov 2013 13:19:49 +0100 (CET)
Message-ID: <528DFA63.6030404@alvestrand.no>
Date: Thu, 21 Nov 2013 13:19:47 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090006080005000506030306"
Subject: Re: [rtcweb] "pranswer" be applied as an update to a previously sent "answer"?
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 12:20:01 -0000

This is a multi-part message in MIME format.
--------------090006080005000506030306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 11/20/2013 12:22 PM, Lijing (Jessie) wrote:
>
> draft-ietf-rtcweb-jsep-05 -----Section 4.1.3 says:
>
> "pranswer" indicates that a description should be parsed as an
>
>    answer, but not a final answer, and so should not result in the
>
>    freeing of allocated resources.  It may result in the start of media
>
>    transmission, if the answer does not specify an inactive media
>
>    direction.  A description used as a "pranswer" may be applied as a
>
>    response to an "offer", or an update to a previously sent "answer".
>
> How can a pranswer be applied as an update to a previously sent 
> answer?  I am not sure what's the corresponding scenario.
>
> From the state machine perspective, when answer is received, it enters 
> the stable state. At this point, the state machine can not directly 
> jump to local pranswer or remote pranswer state.
>
> My two cents: May be it needs more description or correction here.
>

This makes sense, and is consistent with the state diagrams, if the last 
"answer" is changed to "pranswer".

Justin, is this an error in the draft?


--------------090006080005000506030306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
    On 11/20/2013 12:22 PM, Lijing (Jessie)
      wrote:
    
    
    
    
    
      
      
      
      
      
    
        
    draft-ietf-rtcweb-jsep-05
            -----Section 4.1.3 says:
    
        
     
    
        
    "pranswer" indicates
            that a description should be parsed as an
    
        
       answer, but not a
            final answer, and so should not result in the
    
        
       freeing of allocated
            resources.  It may result in the start of media
    
        
       transmission, if the
            answer does not specify an inactive media
    
        
       direction.  A
            description used as a "pranswer" may be applied as a
    
        
       response to an
            "offer", or
          an update to a previously
            sent "answer".
    
        
     
    
        
    How can a pranswer be
            applied as an update to a previously sent answer?  I am not
            sure what’s the corresponding scenario.
            
    
        
    From the state machine
            perspective, when answer is received, it enters the stable
            state. At this point, the state machine can not directly
            jump to local pranswer or remote pranswer state.
    
        
     
    
        
    My two cents: May be it
            needs more description or correction here.
    
      
    
    
    
    
    
    This makes sense, and is consistent with the state diagrams, if the
    last "answer" is changed to "pranswer".
    
    
    
    Justin, is this an error in the draft?
    
    
    
  


--------------090006080005000506030306--

From christer.holmberg@ericsson.com  Thu Nov 21 05:05:53 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD301ADEBA for ; Thu, 21 Nov 2013 05:05:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZS8NBMVgOhT for ; Thu, 21 Nov 2013 05:05:50 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DD9C91AD8EB for ; Thu, 21 Nov 2013 05:05:49 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-fb-528e05266828
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 01.7C.15980.6250E825; Thu, 21 Nov 2013 14:05:42 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Thu, 21 Nov 2013 14:05:41 +0100
From: Christer Holmberg 
To: Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] "pranswer" be applied as an update to a previously sent "answer"?
Thread-Index: AQHO5rP/K+uj4wpB1ES8hu6P+BLdH5ovpwyQ
Date: Thu, 21 Nov 2013 13:05:41 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C54AE8D@ESESSMB209.ericsson.se>
References:  <528DFA63.6030404@alvestrand.no>
In-Reply-To: <528DFA63.6030404@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C54AE8DESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra4aa1+QwYJdahbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIm37/NVnDLteLU6VOMDYwXbbsYOTkkBEwk psw8wAphi0lcuLeerYuRi0NI4BCjxJ6bzUwQzmJGiR+HvgI5HBxsAhYS3f+0QRpEBIIlep+/ ZwSxhQUiJa4ue8QIUiIiECWx6gcfRImRxLZvS1lBwiwCqhLX3suAhHkFfCUetf4CqxYSqJDo eJcBEuYU0JXYuOkEO4jNCHTN91NrmEBsZgFxiVtP5jNBXCkgsWTPeWYIW1Ti5eN/UNcrSnx8 tY8Roj5fYtqc24wQqwQlTs58wjKBUWQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHH TMjiCxjZVzGy5yZm5qSXm29iBEbNwS2/DXYwbrovdohRmoNFSZz3w1vnICGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2MdfK/Lu+zcZha/5bjxDXBfx/M1ly4F2kvafLAbIeC/xmBSen1RrWm S9knLay/79Ac2yGYvrPz3P+llw6kNDQH3kx8lGElf1DO5drNI6biiruPlM0/05VvUiTkHL1z h72RH9fN9RMd3nY9nBgive7pysc+crkqL3dKejt8O7axVjn7Tthci0fdSizFGYmGWsxFxYkA PXIjrmgCAAA=
Subject: Re: [rtcweb] "pranswer" be applied as an update to a previously sent "answer"?
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 13:05:53 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C54AE8DESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I would assume that the text should say "update to a previously applied "pr=
answer".

Regards,

Christer

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran=
d
Sent: 21. marraskuuta 2013 14:20
To: rtcweb@ietf.org
Subject: Re: [rtcweb] "pranswer" be applied as an update to a previously se=
nt "answer"?

On 11/20/2013 12:22 PM, Lijing (Jessie) wrote:
draft-ietf-rtcweb-jsep-05 -----Section 4.1.3 says:

"pranswer" indicates that a description should be parsed as an
   answer, but not a final answer, and so should not result in the
   freeing of allocated resources.  It may result in the start of media
   transmission, if the answer does not specify an inactive media
   direction.  A description used as a "pranswer" may be applied as a
   response to an "offer", or an update to a previously sent "answer".

How can a pranswer be applied as an update to a previously sent answer?  I =
am not sure what's the corresponding scenario.
>From the state machine perspective, when answer is received, it enters the =
stable state. At this point, the state machine can not directly jump to loc=
al pranswer or remote pranswer state.

My two cents: May be it needs more description or correction here.

This makes sense, and is consistent with the state diagrams, if the last "a=
nswer" is changed to "pranswer".

Justin, is this an error in the draft?

--_000_7594FB04B1934943A5C02806D1A2204B1C54AE8DESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









    

    Hi,
    

    =
 
    

    I wou=
ld assume that the text should say “update to a previously
applied “pra=
nswer”.
    

    =
 
    

    Regar=
ds,
    

    =
 
    

    Chris=
ter
    

    =
 
    

    

    

    From: rtcweb [=
mailto:rtcweb-bounces@ietf.org]
On Behalf Of Harald Alvestrand
    
Sent: 21. marraskuuta 2013 14:20
    
To: rtcweb@ietf.org
    
Subject: Re: [rtcweb] "pranswer" be applied as an update t=
o a previously sent "answer"?
    

    

    

     =

    

    

    On 11/20/2013 12:22 PM, Lijing (Jessie) wrote:<=
/o:p>
    

    

    

    draft-ietf-rtcweb-jsep-05 -----Section 4.1.3 says:
    

     
    

    "pranswer" indicates that a des=
cription should be parsed as an
    

       answer, but not a final answ=
er, and so should not result in the
    

       freeing of allocated resourc=
es.  It may result in the start of media
    

       transmission, if the answer =
does not specify an inactive media
    

       direction.  A descripti=
on used as a "pranswer" may be applied as a
    

       response to an=
 "offer", or
an update to a previously sent "answer&q=
uot;.
    

     
    

    How can a pranswer be applied as an update to a prev=
iously sent answer?  I am not sure what’s the corresponding scen=
ario.

    

    From the state machine perspective, when answer is r=
eceived, it enters the stable state. At this point, the state machine can n=
ot directly jump to local pranswer or remote pranswer state.
    

     
    

    My two cents: May be it needs more description or co=
rrection here.
    

    


    
This makes sense, and is consistent with the state diagrams, if the last &q=
uot;answer" is changed to "pranswer".
    

    
Justin, is this an error in the draft?
    

    



--_000_7594FB04B1934943A5C02806D1A2204B1C54AE8DESESSMB209erics_--

From mzanaty@cisco.com  Thu Nov 21 06:27:38 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB091AE18B for ; Thu, 21 Nov 2013 06:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.025
X-Spam-Level: 
X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEDXs3mZDxEV for ; Thu, 21 Nov 2013 06:27:36 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BEAA11AE184 for ; Thu, 21 Nov 2013 06:27:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5218; q=dns/txt; s=iport; t=1385044049; x=1386253649; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Dq7YOgu/qFfLpDmXiqbyfGjxIJ/nrP+E7Qu0Ua9U850=; b=lDJjpA+xjXfHjGI7MTQnUaYpjDI92xNgNTZPBbPEUFCZNaAWNZrzMT2k pHkC5BvHFq/+nA2eo+uQYXDSvbEHBp7/+sczkIy/aqXa3KrIj+7YAilx3 3iPF1D2rvI1CgrvupEqhixaY176Y70WVYFzz26fgL4nywn+SIuW23gAgt o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFABMXjlKtJV2b/2dsb2JhbABZgwc4vQROgSMWdIImAQEEAQEBZQYLEAIBCAQ7BycLFBECBA4Fh28DDw3BDxMEjHKCdQQHgyCBEgOWLYFljFiFOIMogWok
X-IronPort-AV: E=Sophos;i="4.93,744,1378857600";  d="scan'208,217";a="286590944"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 21 Nov 2013 14:27:29 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rALERS2b009854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Nov 2013 14:27:28 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 08:27:28 -0600
From: "Mo Zanaty (mzanaty)" 
To: Bossiel 
Thread-Topic: [rtcweb] VP8 / H.264 conversion without transcoding
Thread-Index: AQHO5o56hPWXG33d2ki07HUjEvwix5ovvn5j
Date: Thu, 21 Nov 2013 14:27:27 +0000
Message-ID: <5A2BC34D-FE4D-4420-B52F-729087815F37@cisco.com>
References: <528D6C63.7050607@bbs.darktech.org>, <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr>
In-Reply-To: <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_5A2BC34DFE4D4420B52F729087815F37ciscocom_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 14:27:38 -0000

--_000_5A2BC34DFE4D4420B52F729087815F37ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This probably refers to an intelligent transcoder versus a brute force tran=
scoder. An intelligent transcoder harvests more data during decoding than j=
ust the raw output pixels, and uses this extra data to ease encoding. Data =
like block partitions, motion vectors, intra modes, quantization parameters=
, etc.

This is common for common conversions, like MPEG2 to H.264. VP8 and H.264 a=
re much closer formats, so this can significantly improve transcoder perfor=
mance.

However, this is strictly a performance optimization, with no impact on IPR=
 or licensing issues.

Mo


On Nov 21, 2013, at 2:51 AM, "Bossiel" > wrote:

This could be true if they can also walk on water and change it into wine.
To be serious, no it's not possible.
Mamadou

Sent from my iPhone

On Nov 21, 2013, at 3:13, Gili > wrote:

Hi,

I'm at the WebRTC World conference. If I understood correctly, Zingaya just=
 demoed what they claim is a VP8 to H.264 bridge that converts the video wi=
thout transcoding. My interpretation is that they convert the surrounding p=
acket format without re-encoding the actual video. Someone who understands =
codec internals (I don't) might want to validate this claim, because it cou=
ld have a significant impact on the MTI debate.

It sounds far fetched, but imagine the possibilities:

  1.  If the video is not being re-encoded, do H.264 royalties apply?
  2.  If the conversion is really cheap, is it feasible to connect a H.264 =
peer to a VP8 peer and have one of them convert in-line (no MCU)?

Gili

_______________________________________________
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

--_000_5A2BC34DFE4D4420B52F729087815F37ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







    This probably refers to an intelligent transcoder versus a brute force=
 transcoder. An intelligent transcoder harvests more data during decoding t=
han just the raw output pixels, and uses this extra data to ease encoding. =
Data like block partitions, motion
 vectors, intra modes, quantization parameters, etc.
    


    

    

    This is common for common conversions, like MPEG2 to H.264. VP8 and H.=
264 are much closer formats, so this can significantly improve transcoder p=
erformance.
    


    

    

    However, this is strictly a performance optimization, with no impact o=
n IPR or licensing issues.
    


    

    

    Mo
    


    

    
On Nov 21, 2013, at 2:51 AM, "Bossiel" <bossiel@yahoo.fr> wrote:
    

    

    

    

    

    This could be true if they can also walk on water and change it into w=
ine.
    

    To be serious, no it's not possible.
    

    Mamadou
    

    
Sent from my iPhone
    


    
On Nov 21, 2013, at 3:13, Gili <cowwoc@bbs.darktech.org> wrote:
    

    

    

    

    Hi,
    

    
I'm at the WebRTC World conference. If I understood correctly, Zingaya just=
 demoed what they claim is a VP8 to H.264 bridge that converts the video wi=
thout transcoding. My interpretation is that they convert the surrounding p=
acket format without re-encoding
 the actual video. Someone who understands codec internals (I don't) might =
want to validate this claim, because it could have a significant impact on =
the MTI debate.
    

    
It sounds far fetched, but imagine the possibilities:
    

      

    1. If the video is not being re-encoded, do H.264 royalties apply? 
      2. If the conversion is really cheap, is it feasible to connect a H.264 peer=
 to a VP8 peer and have one of them convert in-line (no MCU)?
      

    

    Gili
    

    

    

    

    

    _______________________________________________
    
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
    

    



--_000_5A2BC34DFE4D4420B52F729087815F37ciscocom_--

From magnus.westerlund@ericsson.com  Thu Nov 21 08:51:12 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555E21AE207 for ; Thu, 21 Nov 2013 08:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7baQfyl-dsBj for ; Thu, 21 Nov 2013 08:51:09 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DF2AF1AE1FE for ; Thu, 21 Nov 2013 08:51:08 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-1f-528e39f5a9e8
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B1.F4.03802.5F93E825; Thu, 21 Nov 2013 17:51:01 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Thu, 21 Nov 2013 17:51:00 +0100
Message-ID: <528E39F4.4010706@ericsson.com>
Date: Thu, 21 Nov 2013 17:51:00 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIJMWRmVeSWpSXmKPExsUyM+Jvre5Xy74gg84F0hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/uUi0wFD2QrdtzfxdbA+F68i5GTQ0LARGLDj6dsELaYxIV7 68FsIYFDjBK7P1t3MXIB2csZJX5cfcgMkuAV0JZY9GstO4jNIqAqcaFlGVicTcBC4uaPRrBm UYFgiau966DqBSVOznzCAmKLCKhLXH54AaxXWEBT4k73M9YuRg6gxeISPY1BIGFmAT2JKVdb GCFseYntb+cwQ9yjLdHQ1ME6gZF/FpKps5C0zELSsoCReRUje25iZk56udEmRmAwHdzyW3UH 451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAKFrK/NLn3Mz+M+um 6Z6Pya4JFJG5UDvlsEnxu3m2eXWXVjxLn7FJd6FoR80LhvK7U1o3b1hZ/vbggYdlM7W3S248 pvtP7f+22OoiM569yqevRXyVd9i4YufWx6d/7doXysDcOe/wzCkVVcHtxypCVNj9AtJuL2Kx XN/5T1Zj+rV8w9IfsaXVxkosxRmJhlrMRcWJAKwOyaH0AQAA
Subject: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 16:51:12 -0000

WG,

The WebRTC ecosystem needs to avoid interoperability failure to grow
optimally.  The RTCWEB working group took on the task of establish Audio
and Video MTI codecs as part of meeting that need. We have not succeeded
in finishing that task for video using normal IETF process, but it is
still important.

We (WG chairs) are proposing that the working group consent to a method
that will establish an MTI, even if the MTI chosen does not have rough
consensus.  We would far prefer the normal IETF process, but it is not
proving workable for this selection.

We initially proposed a method from RFC 3929 (external review team), but
now believe that the working group would not consent to that method.
Instead we are proposing a method that leaves the decision in the hands
of the WG.

The method we propose is based on Instant-runoff voting,
http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
understanding that the choice will be the winner according to the
Instant-runoff voting process.

The steps in the proposed process are these (1-5):

1) Establish a final list of alternatives, based on the WG's input to
Gonzalo's email on the 13th of November that requires any additions to
provided by end of the 27th of November.

2) Establish those eligible to vote.  Any participant in the
working group process either electronically or in-person as of yesterday
(20th of November). Who has participated in the Working group process
will be anyone that can be identified from:
 - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
   an interim meeting since the WG's creation.
 - posting of at least one email to the RTCWEB mailing list

The voter must at time of voting prove their eligibility, by pointing to
the mail archive or a particular blue sheet/meeting. Please verify your
own eligibility.

3) Start the the voting period. Those eligible and willing to vote send
their ballot to a vote collector (Matt Lepinski, former Nomcom chair)
within two weeks using email. The vote collector will check when
receiving a ballot the that the voter is eligible and send a
confirmation email on receiving the ballot. During the balloting period
the vote collector will keep all ballots secret.

Balloting:
 - The voter MUST rank ALL alternatives in their ballot from the most
   preferred, marked with rank 1, the second most with 2, all the way
   to the least preferred marked with rank N.


4) When the voting period is over the ballot collector will publish the
results as well as all ballots, including the voters name to the RTCWEB
WG mailing list. This enables all voting individuals to verify that
their ballot is unmodified. And allows anyone to verify the result of
the vote.

5) The selection is recorded in the drafts.


--- End of Process Proposal ---

This message initiates the first step in the working group consensus
call process. Namely a one week comment and discussion period for the
above process.

After that week the WG chairs will update, if necessary, the proposal.
Then using the normal IETF process in which anyone is eligible to
participate, the chairs will ask for (rough) consensus to adopt this
extraordinary process to achieve the working group's stated goals.  The
end date for this consensus call is 2-weeks after the announcement of
the consensus call.

If the working group does not consent to using this extraordinary
process, we will hold a consensus call if the WG can accept
"WebRTC entities MUST support at least one of H.264 or VP8.".

If there is failure to establish consensus even for this statement, the
chairs conclude that the WG can't establish what to say about a MTI
video codec.

The WG Chairs

Magnus Westerlund
Cullen Jennings
Ted Hardie



From maikmerten@googlemail.com  Thu Nov 21 09:22:15 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997F61AE1FB for ; Thu, 21 Nov 2013 09:22:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2znfsgs2tQCw for ; Thu, 21 Nov 2013 09:22:13 -0800 (PST)
Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2711AE08D for ; Thu, 21 Nov 2013 09:22:13 -0800 (PST)
Received: by mail-ee0-f53.google.com with SMTP id b57so17734eek.40 for ; Thu, 21 Nov 2013 09:22:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gAPihc6b1j/5fxufiHCx41eeGgcTinlqN/x0xLNid0w=; b=YiJDw+JaGxHf1ZmtGqKnBshufzYX87DmcYxPZzlCCAO27pUEtogLfmME3yPKBUw97n Si3YlLgrJsH67w/kDJCeVrlhHJ/gu1jOjkdjXZuyz2f+DPRnoYA9JlimSqJSLcGxcuJH zwP7WXZGi5jkUzRkONK412ewgRAD4qaIqwVI9nlwCyo+vFgIHa+dZ/Y4S6GhOUYn1zjQ hjHPlKpgn68EaWJSpFqMr/XmEL6AU6aTua44aOF5trx6Q2V6vuLHfh/avX+AcCy9Kjjs z5uLK5h0zAFG95AZvmn+AGEepzwGOIqV3k1XRhMX+Wpr9wIcUKrbW/aO8N6pL/CdoX7S G0Mw==
X-Received: by 10.14.94.199 with SMTP id n47mr58377eef.81.1385054526145; Thu, 21 Nov 2013 09:22:06 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id i1sm72040942eeg.0.2013.11.21.09.22.02 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 09:22:03 -0800 (PST)
Message-ID: <528E4139.3050808@googlemail.com>
Date: Thu, 21 Nov 2013 18:22:01 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com>
In-Reply-To: <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 17:22:15 -0000

Cleary H.263 is preferable from an engineering standpoint (as is, e.g., 
MPEG-1 Part 2): better performance, more deployments. The central 
question is, however, if those can actually be implemented without some 
sort of licensing.

If they can: Aweseome! However, this may not be determinable without a 
review by people who are knowledgeable in the field of IPR, i.e., 
"actual lawyers". I understand that H.263 is not yet old enough to 
automatically be considered "safe" (and neither is MPEG-1 Part 2, 
although it is closer).

Best regards,

Maik

Am 20.11.2013 20:42, schrieb David Singer:
> I think we should think hard about H.263 instead of H.261 as the third fallback.  Why?
>
> http://www.itu.int/rec/T-REC-H.263/
>
>
>
> H.263 was first published in March 1996, so it's 17 years old.  The restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more recent amendments deal with this (and a plethora of other issues), so we’d need to settle on which of those are mandatory (the usual profiling discussion).
>
> There are 34 records in the patent database against H.261, mostly from 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2 (reciprocity), as was one other I checked.
>
> Rather surprisingly, there are only 31 against H.263!  The most recent is 2011, and is also option 2.  Most are 1997-2001.
>
>
> On this quick glance, H.263 appears no worse than H.261. IANAL (as I am sure you have all noticed).
>
>
> H.263 is much more widely supported and mandated.  It has been mandated in the 3GPP specs for years (for lots of services, including videoconf), and is effectively the fallback codec today in the industry, as I understand.  It was ubiquitous in video telephony for years, and I suspect many of those systems still ship it.
>
> So, would “MUST implement at least two of (H.264, VP8, H.263)” work?
>
> (I am asking the question, not even answering on behalf of my company, yet.  Let’s get the issues on the table.)
>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From adam@nostrum.com  Thu Nov 21 09:30:21 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6499F1AE05F for ; Thu, 21 Nov 2013 09:30:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOC8LwSBL3ur for ; Thu, 21 Nov 2013 09:30:20 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB1D1AE202 for ; Thu, 21 Nov 2013 09:30:19 -0800 (PST)
Received: from Orochi.local (sccc-66-78-236-243.smartcity.com [66.78.236.243]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rALHU9OA070153 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 21 Nov 2013 11:30:10 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <528E431D.6030703@nostrum.com>
Date: Thu, 21 Nov 2013 09:30:05 -0800
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: David Singer , rtcweb@ietf.org
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com>
In-Reply-To: <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass (shaman.nostrum.com: 66.78.236.243 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 17:30:21 -0000

On 11/20/13 11:42, David Singer wrote:
> So, would “MUST implement at least two of (H.264, VP8, H.263)†work?

I have to give you a lot of credit for coming up with a "pick two of 
three" formulation. That's a clever way to guarantee overlapping codecs 
between any two pairwise implementations. I'm still not sure it's the 
right direction for *this* decision, but it sure is an interesting 
thought exercise.

/a

From singer@apple.com  Thu Nov 21 09:33:23 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FE01AE02A for ; Thu, 21 Nov 2013 09:33:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Level: 
X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7COCQP9pE68u for ; Thu, 21 Nov 2013 09:33:22 -0800 (PST)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5291A1ADFFF for ; Thu, 21 Nov 2013 09:33:22 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWM002LTJFA44R1@mail-out.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 09:33:15 -0800 (PST)
X-AuditID: 11807158-b7efa6d000002d28-8b-528e43db4fb6
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay5.apple.com (Apple SCV relay) with SMTP id BB.AF.11560.BD34E825; Thu, 21 Nov 2013 09:33:15 -0800 (PST)
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWM00D2YJFEKX10@spicerack.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 09:33:15 -0800 (PST)
From: David Singer 
In-reply-to: <528E431D.6030703@nostrum.com>
Date: Thu, 21 Nov 2013 09:33:14 -0800
Content-transfer-encoding: quoted-printable
Message-id: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E431D.6030703@nostrum.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.1822)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FCsoXvbuS/IoPUbp8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+LVhBnPBcdaKe9vbGRsYN7J0MXJySAiYSMy8tZQZwhaTuHBv PVsXIxeHkMBkJol971qhnNVMElN//mTqYuTgYBbQk7h/UQukgRfIvNV8nxkkLCxgKXHhuAlI mE1AVeLBnGOMIDangLbE1ZOPweazAMXbrpwB28ssICzx/fE9KFtb4sm7C6wgY3gFbCSW3cmG 2HqAWWLygunsIDUiAooSbYdvQt0pK7H7+XfmCYwCsxAOmoXkoFlIpi5gZF7FKFCUmpNYaaqX WFCQk6qXnJ+7iREcdIUROxj/L7M6xCjAwajEw7vTsi9IiDWxrLgy9xCjBAezkgjvV3WgEG9K YmVValF+fFFpTmrxIUZpDhYlcV7VGd1BQgLpiSWp2ampBalFMFkmDk6pBsaSZjab6uap5V0W xssUbxtE1i0+KLxuznxTgdf73ebtWXHqc4e05cf1CyvkPix4IOq51fI5fxfLnznzv0/M0Zmm 7xB/Lvlwm/BZg7wtHm1h6m++b7UyFejZ+7x7ar7Gw0R1Dhf/f1UPTRovZ58qs7Ff7fh7i/kT x44l/AbaxR/WMF6Jtz/Fm6bEUpyRaKjFXFScCACdqYkSNgIAAA==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 17:33:23 -0000

On Nov 21, 2013, at 9:30 , Adam Roach  wrote:

> On 11/20/13 11:42, David Singer wrote:
>> So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 =
work?
>=20
> I have to give you a lot of credit for coming up with a "pick two of =
three" formulation. That's a clever way to guarantee overlapping codecs =
between any two pairwise implementations. I'm still not sure it's the =
right direction for *this* decision, but it sure is an interesting =
thought exercise.
>=20
> /a

Thanks, but not my idea;  that was the H.261 =93pick two of three=94.  I =
am just suggesting H.263 may be a better choice.

David Singer
Multimedia and Software Standards, Apple Inc.


From derhoermi@gmx.net  Thu Nov 21 09:59:16 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31901AE204 for ; Thu, 21 Nov 2013 09:59:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level: 
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWUzQRtlNIHd for ; Thu, 21 Nov 2013 09:59:15 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id D68D31AE1FE for ; Thu, 21 Nov 2013 09:59:14 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.32.80]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MOCSm-1VmsSC1dxs-005aH5 for ; Thu, 21 Nov 2013 18:59:04 +0100
From: Bjoern Hoehrmann 
To: Magnus Westerlund 
Date: Thu, 21 Nov 2013 18:59:05 +0100
Message-ID: 
References: <528E39F4.4010706@ericsson.com>
In-Reply-To: <528E39F4.4010706@ericsson.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:2REjMrmnl2obEjPJF/urQfSwYYdOH5ZYNTt/07oNlex53iZuiAl zZ55Pl5oJDEdujuJl/uNuQ05N28sIo+apg9P9OASeJEdyOYSVVhiBRcZPrZjyzOx3fElGTS /DJR6Sm4Ip6zRIX8yBPRop4QismyXBHPWhiSj6LQz3RPF5M+abmcqmnKGLj9IZmsHoPBGw7 VMokvGTRZfqdwAhLocFOw==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 17:59:16 -0000

* Magnus Westerlund wrote:
>Balloting:
> - The voter MUST rank ALL alternatives in their ballot from the most
>   preferred, marked with rank 1, the second most with 2, all the way
>   to the least preferred marked with rank N.
>
>4) When the voting period is over the ballot collector will publish the
>results as well as all ballots, including the voters name to the RTCWEB
>WG mailing list. This enables all voting individuals to verify that
>their ballot is unmodified. And allows anyone to verify the result of
>the vote.
>
>5) The selection is recorded in the drafts.
>
>--- End of Process Proposal ---

I think this needs to say how invalid ballots are handled. It seems easy
to assign the same rank twice, for instance.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From fluffy@iii.ca  Thu Nov 21 10:05:07 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FACF1AE204 for ; Thu, 21 Nov 2013 10:05:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOsmgT4K1Eua for ; Thu, 21 Nov 2013 10:05:05 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id BB98C1AE135 for ; Thu, 21 Nov 2013 10:05:05 -0800 (PST)
Received: from sjc-vpn3-1087.cisco.com (unknown [128.107.239.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 503EF50A87; Thu, 21 Nov 2013 13:04:58 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: <528A4408.50105@bbs.darktech.org>
Date: Thu, 21 Nov 2013 10:05:33 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <46A95E42-F733-490E-B72D-5D37F389ADDE@iii.ca>
References: <5283DFDC.4010906@ericsson.com> <528A0BD8.1070409@ericsson.com> <528A4408.50105@bbs.darktech.org>
To: cowwoc 
X-Mailer: Apple Mail (2.1510)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:05:07 -0000

On Nov 18, 2013, at 8:44 AM, cowwoc  wrote:

> Does the WG commit to providing reference implementations=20

IETF process does not require the WG to provide any implementations at =
all - I do not think the WG is committing to provide implementations of =
anything. Of course individuals or companies might but not the IETF.=20

Cullen (as one of the chairs) =85



From peter.dunkley@crocodilertc.net  Thu Nov 21 10:09:17 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBF91AE0E4 for ; Thu, 21 Nov 2013 10:09:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wxj1mQuEEcEY for ; Thu, 21 Nov 2013 10:09:16 -0800 (PST)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 48D941ADFFF for ; Thu, 21 Nov 2013 10:09:16 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id lx4so180690iec.37 for ; Thu, 21 Nov 2013 10:09:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TdYlZmSY0RUEPldkwWuIYt1GnTPCfM++DcJd9HPJx2g=; b=bC8sCSNcyjKlQpOMsQWcGTdOH5tg10JtBUvL9JZubqiqob/9MdGOBC0wFQ5iKDCKRD d7ccJXqcBgkNQ3TW70hm478uXQtCMJjE9mW57Vs83fvZxy1WZepV+O2bFWoiSIhjk2IC btwiT416xKRAq/cp4+1rmkN8Q9ibM5bnlEUG0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TdYlZmSY0RUEPldkwWuIYt1GnTPCfM++DcJd9HPJx2g=; b=craSMeuuuPu3KAZuUgHpJwf5SX1JdWm9crDhMZrs1dlf+tQHXlCLMpNqHgHgrIwVQD NvqUZYDFswIqvgw6/H/XhFESQWQwjoJJ5SpLdsdB2BBAe9TDwZtTa3qHpdb4AV2A9hnR h0yttfQ90lUh6z2xg0jRusNVZFMvWRYqX/e/Pe45vTL10aXaB3iI34wQr4q8K8Sv6Qmk zo1YtdC2OwlOHtlRwIHUSlRaCPXSvyHrg0lHf7AU9ILH4+kKwHgrB3TuUcdVmKXZ7qJk d0qst9/W0xILyhkkIA8pzs+ABLaar5kN64/QmuVPpiP5GKgNp3rp+BZqntZPwks9R+JU xAzw==
X-Gm-Message-State: ALoCoQljI9r6rOjRHdx4Q49INN52+yeBbaioMed7C8k/FX/WLujxioHKhOqZqJd8OixJqd7bfWDd
MIME-Version: 1.0
X-Received: by 10.42.110.147 with SMTP id q19mr4934778icp.6.1385057349425; Thu, 21 Nov 2013 10:09:09 -0800 (PST)
Received: by 10.64.229.13 with HTTP; Thu, 21 Nov 2013 10:09:09 -0800 (PST)
In-Reply-To: <528E39F4.4010706@ericsson.com>
References: <528E39F4.4010706@ericsson.com>
Date: Thu, 21 Nov 2013 10:09:09 -0800
Message-ID: 
From: Peter Dunkley 
To: Magnus Westerlund 
Content-Type: multipart/alternative; boundary=20cf303bf4a04e718504ebb3cb0b
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:09:17 -0000

--20cf303bf4a04e718504ebb3cb0b
Content-Type: text/plain; charset=ISO-8859-1

On 21 November 2013 08:51, Magnus Westerlund  wrote:

2) Establish those eligible to vote.  Any participant in the
> working group process either electronically or in-person as of yesterday
> (20th of November). Who has participated in the Working group process
> will be anyone that can be identified from:
>  - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
>    an interim meeting since the WG's creation.
>  - posting of at least one email to the RTCWEB mailing list
>
> The voter must at time of voting prove their eligibility, by pointing to
> the mail archive or a particular blue sheet/meeting. Please verify your
> own eligibility.
>
>
>
What about those who are not on the blue sheets because we participated
(and at the last meeting voted/hummed on this issue) through Jabber?

Regards,

Peter

--20cf303bf4a04e718504ebb3cb0b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



    =
On 21 November 2013 08:51, Magnus Westerlund <magnus.westerl=
und@ericsson.com> wrote:
    

    
2) Establish those eligible to vote. =A0Any participant in the
    
working group process either electronically or in-person as of yesterday
(20th of November). Who has participated in the Working group process
    
will be anyone that can be identified from:
    
=A0- The Blue Sheets for any RTCWEB WG session during an IETF meeting or
=A0 =A0an interim meeting since the WG's creation.
    
=A0- posting of at least one email to the RTCWEB mailing list
    

    
The voter must at time of voting prove their eligibility, by pointing to
the mail archive or a particular blue sheet/meeting. Please verify your
    
own eligibility.
    



    What about those who are not on th=
e blue sheets because we participated (and at the last meeting voted/hummed=
 on this issue) through Jabber?

    Regards,
    


    Peter
    

    

--20cf303bf4a04e718504ebb3cb0b--

From fluffy@iii.ca  Thu Nov 21 10:11:14 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15F81AE22D for ; Thu, 21 Nov 2013 10:11:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv7S5NdPFFGO for ; Thu, 21 Nov 2013 10:11:12 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 611A81AE1F9 for ; Thu, 21 Nov 2013 10:11:12 -0800 (PST)
Received: from sjc-vpn3-1087.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0614822E1F4; Thu, 21 Nov 2013 13:10:58 -0500 (EST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: 
Date: Thu, 21 Nov 2013 10:11:34 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <528E39F4.4010706@ericsson.com> 
To: Bjoern Hoehrmann 
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:11:14 -0000

On Nov 21, 2013, at 9:59 AM, Bjoern Hoehrmann  wrote:

> * Magnus Westerlund wrote:
>> Balloting:
>> - The voter MUST rank ALL alternatives in their ballot from the most
>>  preferred, marked with rank 1, the second most with 2, all the way
>>  to the least preferred marked with rank N.
>>=20
>> 4) When the voting period is over the ballot collector will publish =
the
>> results as well as all ballots, including the voters name to the =
RTCWEB
>> WG mailing list. This enables all voting individuals to verify that
>> their ballot is unmodified. And allows anyone to verify the result of
>> the vote.
>>=20
>> 5) The selection is recorded in the drafts.
>>=20
>> --- End of Process Proposal ---
>=20
> I think this needs to say how invalid ballots are handled. It seems =
easy
> to assign the same rank twice, for instance.
> --=20

Good point - would you be OK if the  vote collector notices a problem, =
they can email the voter and see if they want to correct it, but any =
invalid ballots that are not correct by the end of voting period will be =
discarded ?




From fluffy@iii.ca  Thu Nov 21 10:14:26 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73761AE0C6 for ; Thu, 21 Nov 2013 10:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgN9kyNFDdxg for ; Thu, 21 Nov 2013 10:14:24 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3832D1ADF50 for ; Thu, 21 Nov 2013 10:14:24 -0800 (PST)
Received: from sjc-vpn3-1087.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 19CC122E1FA; Thu, 21 Nov 2013 13:14:16 -0500 (EST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: 
Date: Thu, 21 Nov 2013 10:14:52 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <827DC810-21FD-494D-9E44-6C7406887464@iii.ca>
References: <528E39F4.4010706@ericsson.com> 
To: Peter Dunkley 
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:14:27 -0000

If there are any people in that category that wish to vote, could they =
email the chairs with full name and affiliation. That would make it =
easier to figure out how to deal with this issue. I think it will be =
hard to take votes from someone that will not provide the information =
required to be on a blue sheet due to questions about double counting.=20=



On Nov 21, 2013, at 10:09 AM, Peter Dunkley =
 wrote:

>=20
> On 21 November 2013 08:51, Magnus Westerlund =
 wrote:
>=20
> 2) Establish those eligible to vote.  Any participant in the
> working group process either electronically or in-person as of =
yesterday
> (20th of November). Who has participated in the Working group process
> will be anyone that can be identified from:
>  - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
>    an interim meeting since the WG's creation.
>  - posting of at least one email to the RTCWEB mailing list
>=20
> The voter must at time of voting prove their eligibility, by pointing =
to
> the mail archive or a particular blue sheet/meeting. Please verify =
your
> own eligibility.
>=20
>=20
>=20
> What about those who are not on the blue sheets because we =
participated (and at the last meeting voted/hummed on this issue) =
through Jabber?
>=20
> Regards,
>=20
> Peter
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From jlaurens@cisco.com  Thu Nov 21 10:17:14 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610A31AE21D for ; Thu, 21 Nov 2013 10:17:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.025
X-Spam-Level: 
X-Spam-Status: No, score=-10.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lizmTWURKv4Q for ; Thu, 21 Nov 2013 10:17:12 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3801AE0E4 for ; Thu, 21 Nov 2013 10:17:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10372; q=dns/txt; s=iport; t=1385057825; x=1386267425; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gmBjrHplQ+HWfotuAto9JVKPqw8N6MvPFj21e/RecgM=; b=aXRBWP7B3J7nucBeVYjNuT50SmumKIq/B4A12/C6u9KEsCtuAZfO74qK Jtwzf9TAM0gUvY7iN2+pjaIFKw8s0JL+iCZLRooLZ6gueXIFpj1h2+k0y jJr67p0cLpdnkRdxKmKJGwhLJDRr6Jl7BBDVDDPDcJaOpdy4orzvth6Qc k=;
X-Files: smime.p7s : 4459
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsFACJNjlKtJV2b/2dsb2JhbABZgwc4U7wJToEkFnSCJQEBAQMBAQEBawsQAgEIBBQuAiULJQIEDgUOh20GDcEfEwSOHxACAYE5B4MggRIDkDCBMYJPg2KSEIMogio
X-IronPort-AV: E=Sophos;i="4.93,746,1378857600";  d="p7s'?scan'208,217";a="1284479"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 21 Nov 2013 18:17:05 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rALIH5KH015043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Nov 2013 18:17:05 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.33]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 12:17:04 -0600
From: "Jeremy Laurenson (jlaurens)" 
To: Peter Dunkley 
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: AQHO5uXhwwBMrYLzkkCKzkaBuKV9+w==
Date: Thu, 21 Nov 2013 18:17:04 +0000
Message-ID: <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>
References: <528E39F4.4010706@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.238.14]
Content-Type: multipart/signed; boundary="Apple-Mail=_E2F2BA27-029B-4D23-81A5-76579AAD7CD9"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:17:14 -0000

--Apple-Mail=_E2F2BA27-029B-4D23-81A5-76579AAD7CD9
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_054E23A9-E280-48B0-BAE9-45D87BF2DD75"


--Apple-Mail=_054E23A9-E280-48B0-BAE9-45D87BF2DD75
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

If they participated in the mailing list they would be included. I can't =
imagine that simply logging into a chat room in order to vote qualifies =
you.


On Nov 21, 2013, at 1:09 PM, Peter Dunkley =
 wrote:

>=20
> On 21 November 2013 08:51, Magnus Westerlund =
 wrote:
>=20
> 2) Establish those eligible to vote.  Any participant in the
> working group process either electronically or in-person as of =
yesterday
> (20th of November). Who has participated in the Working group process
> will be anyone that can be identified from:
>  - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
>    an interim meeting since the WG's creation.
>  - posting of at least one email to the RTCWEB mailing list
>=20
> The voter must at time of voting prove their eligibility, by pointing =
to
> the mail archive or a particular blue sheet/meeting. Please verify =
your
> own eligibility.
>=20
>=20
>=20
> What about those who are not on the blue sheets because we =
participated (and at the last meeting voted/hummed on this issue) =
through Jabber?
>=20
> Regards,
>=20
> Peter
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--Apple-Mail=_054E23A9-E280-48B0-BAE9-45D87BF2DD75
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

If they participated in the mailing list they would be included. I can't imagine that simply logging into a chat room in order to vote qualifies you.

    


    On Nov 21, 2013, at 1:09 PM, Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:


    On 21 November 2013 08:51, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
    

    
2) Establish those eligible to vote.  Any participant in the
    
working group process either electronically or in-person as of yesterday
    
(20th of November). Who has participated in the Working group process
    
will be anyone that can be identified from:
    
 - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
    
   an interim meeting since the WG's creation.
    
 - posting of at least one email to the RTCWEB mailing list
    

    
The voter must at time of voting prove their eligibility, by pointing to
    
the mail archive or a particular blue sheet/meeting. Please verify your
    
own eligibility.
    



    What about those who are not on the blue sheets because we participated (and at the last meeting voted/hummed on this issue) through Jabber?

    Regards,
    


    Peter
    

    
_______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb

    
--Apple-Mail=_054E23A9-E280-48B0-BAE9-45D87BF2DD75--

--Apple-Mail=_E2F2BA27-029B-4D23-81A5-76579AAD7CD9
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw
ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug
b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ
BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50
ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD
Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi
VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey
xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/
xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28
ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB
o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy
aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS
MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo
dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl
cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY
BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB
8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl
cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu
IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb
dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4
e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po
mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9
5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4
OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi
dE0HbYQwggb/MIIF56ADAgECAhBMB51Pnvlk8cSmNt8H9SnjMA0GCSqGSIb3DQEBBQUAMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu
dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE
AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEw
MTEwMDAwMDBaFw0xNDEwMTIyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0
ZWQgLSAxMzgxNDg5MjU3Mzg2MSEwHwYJKoZIhvcNAQkBFhJqbGF1cmVuc0BjaXNjby5jb20xDzAN
BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT
eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK/+Nq7kMnqR6fQzT7AdPZqAFXEHu2WpnwBLsyXj
TZLjXzU4sk37efasq1jwJ6bhYarwFOnnM32PAtmEjWsWYrVC/yerrjDiQetD+ja7mEidL/SrOKNt
9oVnOO8SNdOYeFwydzx/mIFlQXLWA3DOj+xxHkonk9Zvz6kU4aOMC9eodawruobR5rBwn7dybplc
e9m3BbDpIIKDIhkNjXQw8nesBtpwj40wIMsdPKh+YauCZW1mhh3LCAbU8JnJ9ruDKO6w+9EEFeFA
6F3DFqaHAnNdQj/bPVulnYpDqhNjOZqrp4677+fnCmWpHMqla0KuB6ujLY6rwc2T1ocpeT+zfb8C
AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU6AbcYQIy/DM74yCnYa/NhoUDAbowHQYDVR0R
BBYwFIESamxhdXJlbnNAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB
MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku
dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs
JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90
JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy
QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB
Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1
dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww
bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1
dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg
hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw
KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA
A4IBAQCaq/WPMAj7VTYbcIaIj4ejrezJkEdvtM7qG49B8Q/FG1nDEkyeQ6me9VcYMauVoP92PzB9
f9jaHRUPFPJ5O/HIZ3OrK4B9Ejc6zMO20Nlbf0hAX+9vJfOfz8iVYyfY0/7pO1bw2W/2u0S+KLL+
nocRFuDLiKaaKNeXaXb9spxSUer97n3oT862+cSWfbMHv4x1GeHAyRyWZfkHi2USNbetMaJ87uxy
drfB/tkaik47F+0O6bSk5bGO/qklOHtdAiZvWyqzODKRTmtSeY7WjvhWkQaUKNjMuVZP7KIGJXUn
UJoycIMIHCOBX+WMKDPjSib+FchE77R5wPJE3lUTnScgMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV
BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg
VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T
eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSm
Nt8H9SnjMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMTEyMTE4MTcwM1owIwYJKoZIhvcNAQkEMRYEFEGddiNVU4zrtsgWYu3YrVD3hMXz
MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD
b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSmNt8H9SnjMIHOBgsqhkiG9w0BCRACCzGBvqCB
uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL
ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC
EEwHnU+e+WTxxKY23wf1KeMwDQYJKoZIhvcNAQEBBQAEggEAcnK8XRSxq16Fg07a2j5FuRWoOKsX
LjoiPgeDJdUxzF+sSmrDAmNfM6NIjK9QxkvUavCU9XlcAEHK+9Qxyq+IdFv+J6WvUxAPtHjNxoh/
qo/9WlBVz05ufvZxV8QEceqv99XSVuqjcaCrNrjrznM3P7OdTd69V2JL3GhG5M8CJ8Sfcb46Tc5Y
W61bo6aGipSUt48EAABG4WR1QH/nc1PZ45a+T+Ti/EwGDhYRWS8aobnn0tomg2RhmKJ9p+SUnLek
WsTleo0W9rHXPjrc5IORpkPnWyJ9JvtaASfkGXKfDX0RF5aQ847T4nWrwu9X99RL/YfSrIcoB3EH
LO8p6UW2OQAAAAAAAA==

--Apple-Mail=_E2F2BA27-029B-4D23-81A5-76579AAD7CD9--

From fluffy@iii.ca  Thu Nov 21 10:17:26 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F329B1AE237 for ; Thu, 21 Nov 2013 10:17:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOjhHfrTkKIc for ; Thu, 21 Nov 2013 10:17:24 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 204331AE238 for ; Thu, 21 Nov 2013 10:17:24 -0800 (PST)
Received: from sjc-vpn3-1087.cisco.com (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8D139509B6; Thu, 21 Nov 2013 13:17:16 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C54AE8D@ESESSMB209.ericsson.se>
Date: Thu, 21 Nov 2013 10:17:52 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <528DFA63.6030404@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C54AE8D@ESESSMB209.ericsson.se>
To: Christer Holmberg 
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] "pranswer" be applied as an update to a previously sent "answer"?
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:17:26 -0000

On Nov 21, 2013, at 5:05 AM, Christer Holmberg =
 wrote:

> Hi,
> =20
> I would assume that the text should say =93update to a previously =
applied =93pranswer=94.
> =20
> Regards,

+1=20

> =20
> Christer
> =20
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald =
Alvestrand
> Sent: 21. marraskuuta 2013 14:20
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] "pranswer" be applied as an update to a =
previously sent "answer"?
> =20
> On 11/20/2013 12:22 PM, Lijing (Jessie) wrote:
> draft-ietf-rtcweb-jsep-05 -----Section 4.1.3 says:
> =20
> "pranswer" indicates that a description should be parsed as an
>    answer, but not a final answer, and so should not result in the
>    freeing of allocated resources.  It may result in the start of =
media
>    transmission, if the answer does not specify an inactive media
>    direction.  A description used as a "pranswer" may be applied as a
>    response to an "offer", or an update to a previously sent "answer".
> =20
> How can a pranswer be applied as an update to a previously sent =
answer?  I am not sure what=92s the corresponding scenario.
> =46rom the state machine perspective, when answer is received, it =
enters the stable state. At this point, the state machine can not =
directly jump to local pranswer or remote pranswer state.
> =20
> My two cents: May be it needs more description or correction here.
>=20
> This makes sense, and is consistent with the state diagrams, if the =
last "answer" is changed to "pranswer".
>=20
> Justin, is this an error in the draft?
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From derhoermi@gmx.net  Thu Nov 21 10:21:23 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996FE1AE23B for ; Thu, 21 Nov 2013 10:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level: 
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2d_DT7PNqdW for ; Thu, 21 Nov 2013 10:21:22 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id D788D1AE244 for ; Thu, 21 Nov 2013 10:21:14 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.32.80]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MSY2q-1W8p0B0WBw-00RYiX for ; Thu, 21 Nov 2013 19:21:07 +0100
From: Bjoern Hoehrmann 
To: Cullen Jennings 
Date: Thu, 21 Nov 2013 19:21:08 +0100
Message-ID: <5ijs89h7ukib0rnvs7oqq522m7spa92g93@hive.bjoern.hoehrmann.de>
References: <528E39F4.4010706@ericsson.com>  
In-Reply-To: 
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:1nRK0lmdGQZ92tidPDEXH0SVaGcv3Pq5WKelqsr8nWMXqTCT7SX WrGCTC2Vao/1hxZT5ex9RsIcJvxJxs90LHEKQmMEArhy/DHM3qtYwrT1RO0N5UgBGLTA6HA vi2ZuG/l2Z9uDaVPZNya7Q4DEZA6zub/GS4wK/MzcBdXTbBhWBTjKIFi75t+2fS4yYNYArn CV3ZmJVmB/LBoAVAELiTg==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:21:23 -0000

* Cullen Jennings wrote:
>On Nov 21, 2013, at 9:59 AM, Bjoern Hoehrmann  wrote:
>> I think this needs to say how invalid ballots are handled. It seems easy
>> to assign the same rank twice, for instance.
>
>Good point - would you be OK if the  vote collector notices a problem, 
>they can email the voter and see if they want to correct it, but any 
>invalid ballots that are not correct by the end of voting period will be 
>discarded ?

That would be acceptable.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From peter.dunkley@crocodilertc.net  Thu Nov 21 10:24:29 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9B31AE03D for ; Thu, 21 Nov 2013 10:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcrPaY4EIR64 for ; Thu, 21 Nov 2013 10:24:27 -0800 (PST)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 333D61AE1DB for ; Thu, 21 Nov 2013 10:24:27 -0800 (PST)
Received: by mail-ie0-f180.google.com with SMTP id tp5so215887ieb.25 for ; Thu, 21 Nov 2013 10:24:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VqX8dak/iWTNXxDqHKqsWpgvn0669HGr298xEuzFz6c=; b=b9zkkTWKocPqwq4DkAczZZIXI7AiyFfhjWiTBj9QZ6tGaHvnyfeWLm8B3Jau+33q5I qFCmtZ8QD9ka13jzpvo5AFzzCMTTig9k38+BzACWtoOP2UBjBJ/wptxZC81vjWMOneVZ CDPc/5VsgCMAZBurDnMPedamwHz5ocCPe1Aww=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VqX8dak/iWTNXxDqHKqsWpgvn0669HGr298xEuzFz6c=; b=Q3IuMn/pYpDzMkxmDveng/N8CACeJjjZGGolqrS+8X5EC3DiiEQVrFrIOtZZqlHk71 qaGhYRqpCtNBWhTPsDANGvV7tdanP1s5V1UlygdymYBXtVPN0pLAeQwmDlCeVt1DlEXl 5F7dNU3Um7pXeD7jLzkpoQyqdp1Lx+ptBZ/XhdqYfGsxy2IG6MBGHo32u+PqLAy2SRQ4 bO0gDBGnvfMTxHmbkoCygM0T4X6c32rRL7jQErcDlOg4OKMZTGknkGEUeWdiVi5LJbr/ UfIyPo9noIjzNFlO33iirwWVC8rKCsmsj1911aqp9JSDT90lCJCFBi9sJ96aFhiI61qJ oUyQ==
X-Gm-Message-State: ALoCoQl/r0Te+K51r3XjIf07FmyRnovhS88L+1OQuDyFnejKL/u9AjNQW1DBrzMBZn+a7LzXQUdv
MIME-Version: 1.0
X-Received: by 10.50.1.78 with SMTP id 14mr28573495igk.37.1385058260389; Thu, 21 Nov 2013 10:24:20 -0800 (PST)
Received: by 10.64.229.13 with HTTP; Thu, 21 Nov 2013 10:24:20 -0800 (PST)
In-Reply-To: <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>
Date: Thu, 21 Nov 2013 10:24:20 -0800
Message-ID: 
From: Peter Dunkley 
To: "Jeremy Laurenson (jlaurens)" 
Content-Type: multipart/alternative; boundary=047d7bdc119a9aa6a804ebb40116
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:24:29 -0000

--047d7bdc119a9aa6a804ebb40116
Content-Type: text/plain; charset=ISO-8859-1

This is a topic that is important to me (and the company I work for) that I
have been following closely, but each time I see an issue on the list I
would like to comment on it someone has already said what I would say.

There will have been many people in the room at the meetings (and
presumably on the blue sheets) who have never posted on this list and these
people get a vote.  The only difference between them and me will be that
they work for a company that has the budget (both in terms of money and
time) to send them there.

If you allow those who have been in the room and not posted to vote, but
those of us who were only able to participate online cannot vote, you are
in effect giving preference to organisations and individuals with bigger
budgets.  That would hardly seem fair.

Regards,

Peter


On 21 November 2013 10:17, Jeremy Laurenson (jlaurens)
wrote:

> If they participated in the mailing list they would be included. I can't
> imagine that simply logging into a chat room in order to vote qualifies you.
>
>
> On Nov 21, 2013, at 1:09 PM, Peter Dunkley 
> wrote:
>
>
> On 21 November 2013 08:51, Magnus Westerlund <
> magnus.westerlund@ericsson.com> wrote:
>
> 2) Establish those eligible to vote.  Any participant in the
>> working group process either electronically or in-person as of yesterday
>> (20th of November). Who has participated in the Working group process
>> will be anyone that can be identified from:
>>  - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
>>    an interim meeting since the WG's creation.
>>  - posting of at least one email to the RTCWEB mailing list
>>
>> The voter must at time of voting prove their eligibility, by pointing to
>> the mail archive or a particular blue sheet/meeting. Please verify your
>> own eligibility.
>>
>>
>>
> What about those who are not on the blue sheets because we participated
> (and at the last meeting voted/hummed on this issue) through Jabber?
>
> Regards,
>
> Peter
>  _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--047d7bdc119a9aa6a804ebb40116
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    This is a topic that is important to me (and the company I=
 work for) that I have been following closely, but each time I see an issue=
 on the list I would like to comment on it someone has already said what I =
would say.
    

    There will have been many people in the room at the meetings=
 (and presumably on the blue sheets) who have never posted on this list and=
 these people get a vote. =A0The only difference between them and me will b=
e that they work for a company that has the budget (both in terms of money =
and time) to send them there.
    


    If you allow those who have been in the room and not po=
sted to vote, but those of us who were only able to participate online cann=
ot vote, you are in effect giving preference to organisations and individua=
ls with bigger budgets. =A0That would hardly seem fair.
    


    Regards,

    Peter


    On 21 November 20=
13 10:17, Jeremy Laurenson (jlaurens) <jlaurens@cisco.com> =
wrote:
    

    If they =
participated in the mailing list they would be included. I can't imagin=
e that simply logging into a chat room in order to vote qualifies you.
    

    


    On Nov 21, 2013, at 1:09 PM, Peter Dun=
kley <peter.dunkley@crocodilertc.net> wrote:

    


    On 21 November 2013 08:51, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
    


    
2) Establish those eligible to vote. =A0Any participant in the
    
working group process either electronically or in-person as of yesterday
(20th of November). Who has participated in the Working group process
    
will be anyone that can be identified from:
    
=A0- The Blue Sheets for any RTCWEB WG session during an IETF meeting or
=A0 =A0an interim meeting since the WG's creation.
    
=A0- posting of at least one email to the RTCWEB mailing list
    

    
The voter must at time of voting prove their eligibility, by pointing to
the mail archive or a particular blue sheet/meeting. Please verify your
    
own eligibility.
    



    What about those who are not on th=
e blue sheets because we participated (and at the last meeting voted/hummed=
 on this issue) through Jabber?

    Regards,
    



    Peter
    

    
_______________________________________________
    rtcweb mailing list
    <=
a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
    =
=
https://www.ietf.org/mailman/listinfo/rtcweb
    





    -- 
    Peter Dunkley
    Technical Director
    

    Crocodile RCS Ltd
    

    

--047d7bdc119a9aa6a804ebb40116--

From stpeter@stpeter.im  Thu Nov 21 10:26:42 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ACB1AE247 for ; Thu, 21 Nov 2013 10:26:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.427
X-Spam-Level: 
X-Spam-Status: No, score=-4.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XDWBI1pomrF for ; Thu, 21 Nov 2013 10:26:40 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8DA1AE23C for ; Thu, 21 Nov 2013 10:26:40 -0800 (PST)
Received: from sjc-vpn5-558.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DA84D4010C; Thu, 21 Nov 2013 11:26:32 -0700 (MST)
Message-ID: <528E5057.30408@stpeter.im>
Date: Thu, 21 Nov 2013 11:26:31 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Magnus Westerlund ,  "rtcweb@ietf.org" 
References: <528E39F4.4010706@ericsson.com>
In-Reply-To: <528E39F4.4010706@ericsson.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:26:42 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/21/13 9:51 AM, Magnus Westerlund wrote:

> The method we propose is based on Instant-runoff voting, 
> http://en.wikipedia.org/wiki/Instant-runoff_voting, with the 
> understanding that the choice will be the winner according to the 
> Instant-runoff voting process.

I have the greatest respect for the chairs, but this is an engraved
invitation for people to appeal whatever decision might be reached.

More fundamentally: Voting? At the IETF?? Really?!?

I sincerely hope we can figure out a better process...

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSjlBXAAoJEOoGpJErxa2pxmoP/2cCm8UEteJlhNkpV+kTrgYc
epj1s0LHlQYS/XBWvTpa6d/DeBS0N/mWUAHg+QDj1J5kXiCol3PVpZB7yp2YP4p+
OcsF/y4KTJCZz+Qs/SBj6o68eX4Cuk68FZ5nrSK6/jSuRFLH6LYTbXW7jvF/Y4pX
ER5kUg14c+s+NFo575ru3PjYJy2NoSUHVJfB/pLtmlFSH+WKZXw7RFR+Sivlyw3p
RSJ2fsGldRRa/5aLFajDXxVmViwOtDbuoIFpKKfSSw76a3Q4IbPPX+gezQi7p0ky
cJCED5/U6IR4wtyWxsfQTV7XDvebYtWTXk2smzKPmQCdRnUiHmT5fmtR6bxDVbSu
h7xrLCTJeW8qx4IN9zvXCg6QUKUzPdtJuhRF/HouCiZQs9v+d0jmSaR/ZUiZ0Ho9
1uXHkiUezkksDKjxB9hsJDmMj24BMzu8TmkndZd3Q4lSg0PI+R1ALd6MgXupBCif
L8lwYm+JG4cT548O1AfFrBmYcqKnNuTilAA7ZwwJtk6eLcpzpwbLFvRq0LVhsmJC
dDiNKGSFmgj8wTgT7Z3SQ+km++gecDILGvnJU5hXo6RmnErcjzkis7YMootreSUi
qCA1fJm7s1TZMn18X79XzHRF6run0C9UaYZORSPwlpmTzAdjRKN5WimstXO2yIQJ
IZFFqvSNutklVl36Limg
=G59C
-----END PGP SIGNATURE-----

From stpeter@stpeter.im  Thu Nov 21 10:43:29 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3541AE088 for ; Thu, 21 Nov 2013 10:43:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.427
X-Spam-Level: 
X-Spam-Status: No, score=-4.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EKiZ1SFt8_j for ; Thu, 21 Nov 2013 10:43:27 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 05BBE1AE0A0 for ; Thu, 21 Nov 2013 10:43:27 -0800 (PST)
Received: from sjc-vpn5-558.cisco.com (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A29F54010C; Thu, 21 Nov 2013 11:43:19 -0700 (MST)
Message-ID: <528E5446.3030406@stpeter.im>
Date: Thu, 21 Nov 2013 11:43:18 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Magnus Westerlund ,  "rtcweb@ietf.org" 
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>
In-Reply-To: <528E5057.30408@stpeter.im>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:43:29 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/21/13 11:26 AM, Peter Saint-Andre wrote:
> On 11/21/13 9:51 AM, Magnus Westerlund wrote:
> 
>> The method we propose is based on Instant-runoff voting, 
>> http://en.wikipedia.org/wiki/Instant-runoff_voting, with the 
>> understanding that the choice will be the winner according to
>> the Instant-runoff voting process.
> 
> I have the greatest respect for the chairs, but this is an
> engraved invitation for people to appeal whatever decision might be
> reached.
> 
> More fundamentally: Voting? At the IETF?? Really?!?
> 
> I sincerely hope we can figure out a better process...

In an effort to post something more productive, I suggest that we at
least explore the idea of two MTI codecs, as we already have done for
audio. This was not an option in Vancouver because no one wrote an
Internet-Draft about it before the deadline, but I got the sense in
the room that at least some people would have preferred this approach,
if only to put an end to our long working group nightmare.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSjlRFAAoJEOoGpJErxa2pR6wP/iyP+SUhog4LHqP0DZJJ/NbC
XBVcvYy8G1h+LuDWYMl5MsuuWnUlIixjz6jSvuKazS1nfkU6BEVvg2OOB+JTk5zp
QWrLKRaTnqdkS5GlfDlzt+8aa9i1vAYEFx4GdwASvYfEGtmlBjb3O2WRDbm/202r
Laf1/rG700aVKqbnnlc3tpB0Ucs2zo6k+d8ms8ayh7UoBf2g9DuO12IAJ3rW4J45
Jn64rP1xXxQoXkQnbrE/t+RqY/5ltUKjRqfz6uM3R/9CLISnXmVZS8X0lEh+ZMNv
YhBl5eCEQ+JFirBu4deA9emmojUKgsGb4kthxHw5bSbY1WpPQ+hMN1H28xVesvn/
7HcIigiLrJ4+UUO/m95u6uOf0/+RJsnwCtCkEpP+BkiS5l8oNPuyW7fOGFf4mnvn
73jMLx/OPCZxxGyskKJYcdQzQVCIwHZYqlQcB6jXF04bXU1bBkQdusJF0OpCb8aq
ImUm1hnJ3ZYXTk9kSgtkSxVkv79IjBHs/L35HozoG+UaFmZrqpBfmshO4llMeCdh
DrV434YnbtZAA1yxClw68ZhhnUnnxQRKqKCPwz/fpIes7zKkWsdPmguEU0x6wntr
8IU15GLOii2pDYZeumSrbop4DwTRQjcG7aS/73JQg3n8oX14+eVdYikijAilXGTx
cWjyfQBKAmxgkq3IEHem
=pcJq
-----END PGP SIGNATURE-----

From fluffy@iii.ca  Thu Nov 21 10:45:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECE61AE1CE for ; Thu, 21 Nov 2013 10:45:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In0zBgryVmWs for ; Thu, 21 Nov 2013 10:45:34 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9291AE0A0 for ; Thu, 21 Nov 2013 10:45:34 -0800 (PST)
Received: from sjc-vpn3-1087.cisco.com (unknown [128.107.239.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A7947509B5; Thu, 21 Nov 2013 13:45:26 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: <5A2BC34D-FE4D-4420-B52F-729087815F37@cisco.com>
Date: Thu, 21 Nov 2013 10:46:02 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <528D6C63.7050607@bbs.darktech.org>, <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr> <5A2BC34D-FE4D-4420-B52F-729087815F37@cisco.com>
To: Bossiel 
X-Mailer: Apple Mail (2.1510)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:45:36 -0000

It's a cool demo and I talked to the team that did it. This is only =
possible because VP8 and H.264 are very similar codecs. The idea is to =
not redo the motion vector computations or the DCT but just reuse the =
values from one format in the other since they are the same. They hope =
that this can provide reduce the CPU by 1/3 from a full decode then =
re-encode. It also help reduce loss of quality for video. Other people =
have talked about this idea over the years and many people think it can =
give a 2 to 3 speed up so that seems consistent with their goals.=20

It still requires the same bandwidth, and has similar other impacts. I =
can not see any way that it would not require MPEG-LA IPR for 264.=20


On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty)  =
wrote:

> This probably refers to an intelligent transcoder versus a brute force =
transcoder. An intelligent transcoder harvests more data during decoding =
than just the raw output pixels, and uses this extra data to ease =
encoding. Data like block partitions, motion vectors, intra modes, =
quantization parameters, etc.
>=20
> This is common for common conversions, like MPEG2 to H.264. VP8 and =
H.264 are much closer formats, so this can significantly improve =
transcoder performance.
>=20
> However, this is strictly a performance optimization, with no impact =
on IPR or licensing issues.
>=20
> Mo
>=20
>=20
> On Nov 21, 2013, at 2:51 AM, "Bossiel"  wrote:
>=20
> This could be true if they can also walk on water and change it into =
wine.
> To be serious, no it's not possible.
> Mamadou
>=20
> Sent from my iPhone
>=20
> On Nov 21, 2013, at 3:13, Gili  wrote:
>=20
>> Hi,
>>=20
>> I'm at the WebRTC World conference. If I understood correctly, =
Zingaya just demoed what they claim is a VP8 to H.264 bridge that =
converts the video without transcoding. My interpretation is that they =
convert the surrounding packet format without re-encoding the actual =
video. Someone who understands codec internals (I don't) might want to =
validate this claim, because it could have a significant impact on the =
MTI debate.
>>=20
>> It sounds far fetched, but imagine the possibilities:
>> 	=95 If the video is not being re-encoded, do H.264 royalties =
apply?
>> 	=95 If the conversion is really cheap, is it feasible to connect =
a H.264 peer to a VP8 peer and have one of them convert in-line (no =
MCU)?
>> Gili
>> _______________________________________________
>> 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


From juberti@google.com  Thu Nov 21 10:56:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876081AE23F for ; Thu, 21 Nov 2013 10:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mmDjNOcYt2c for ; Thu, 21 Nov 2013 10:56:52 -0800 (PST)
Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7A44C1AE247 for ; Thu, 21 Nov 2013 10:56:52 -0800 (PST)
Received: by mail-ve0-f175.google.com with SMTP id jx11so125881veb.34 for ; Thu, 21 Nov 2013 10:56:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LJj/lynV2tnHjhXyZ8S54pRXAy88xjhNV47tv/DryrI=; b=JCtBA2l3mKAUI4FslGRPAXONMrMjqx2PkFAzQg+SbBGiVLoYYbsXAdOsF/Ca7dVKox VQV+HLl1ClKUv3Oqn2pB6leQVM41koUSQvf3qUTW9G8tsGxG2yCav8FH+ypY6EFyX8Kr e5/J8SzqtpsgSgNNrtkScFRnpGQKBRLhCTsalxn2witpIuN/OT62RrQhLgExexWiMUWS 9IUAbEorUDkwOsgQkcYtoiiUnhw1Z4ypNf9wOp8HSk9nRhFzTtHBT/uGV4u1HIEbgmPF my19X2t7GxpyhH5O8slDnKB/zmfY7q2XUND7otU/7JEiAxtNg8W/N/KcI9spNl+b8TUc v0bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LJj/lynV2tnHjhXyZ8S54pRXAy88xjhNV47tv/DryrI=; b=DXTfbe1x6nVWL1v5/YoeD1UXK7GvMkNENEtJ2sIhVAAaTTe7FdPNlMldiTC+KyucGu tv2u6olP/r5fAIBRsxtt6jlFmK6alnNV5OjjWecNW85UnqZ2CakVvuvtar2MfbVCrATA sp73U4hqlOUnagvNrBfv5vtI+1iaMfF+gSy8Z5bwKRBHSOYASiURGpr4SYhQI00vxGUk E/UxxZthX23F9vm1XqRyOSHJ+ctIVAiJFPR70ZNUVnmP+PBjqnetSMwKLKlKquZPib2t rLPSa5VX69S6WrGJrKKf7n+NF7DeugRAnReB9Wc/wpBCpJfmH03c90/3O2zq060qQy4x Z3QA==
X-Gm-Message-State: ALoCoQlttjMvwoq9GxcDODtZHTKkaz9/TVxaxzHVfVI10XEV9bbwpJl5K8jd3r/IOizW8WmBjAlxRkc3Zr12Wht+QOp4cPWiCQPWRpjuiy4M4XOAN5ZSHiOc8AUILEBGJt8Qu44BNGzCy6fR0aFAeDpytEnudfAQYRp+8s2BAz/kXnEjXr+T3wf7I6p/GJaKX5lv9ESZlX9Y
X-Received: by 10.52.98.99 with SMTP id eh3mr3386080vdb.29.1385060205351; Thu, 21 Nov 2013 10:56:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Thu, 21 Nov 2013 10:56:25 -0800 (PST)
In-Reply-To: <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>
From: Justin Uberti 
Date: Thu, 21 Nov 2013 10:56:25 -0800
Message-ID: 
To: "Jeremy Laurenson (jlaurens)" 
Content-Type: multipart/alternative; boundary=20cf307f38888869cf04ebb475fb
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:56:54 -0000

--20cf307f38888869cf04ebb475fb
Content-Type: text/plain; charset=UTF-8

Following an IETF meeting on Jabber doesn't count as participating?

The "big guy vs little guy" narrative continues...


On Thu, Nov 21, 2013 at 10:17 AM, Jeremy Laurenson (jlaurens) <
jlaurens@cisco.com> wrote:

> If they participated in the mailing list they would be included. I can't
> imagine that simply logging into a chat room in order to vote qualifies you.
>
>
> On Nov 21, 2013, at 1:09 PM, Peter Dunkley 
> wrote:
>
>
> On 21 November 2013 08:51, Magnus Westerlund <
> magnus.westerlund@ericsson.com> wrote:
>
> 2) Establish those eligible to vote.  Any participant in the
>> working group process either electronically or in-person as of yesterday
>> (20th of November). Who has participated in the Working group process
>> will be anyone that can be identified from:
>>  - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
>>    an interim meeting since the WG's creation.
>>  - posting of at least one email to the RTCWEB mailing list
>>
>> The voter must at time of voting prove their eligibility, by pointing to
>> the mail archive or a particular blue sheet/meeting. Please verify your
>> own eligibility.
>>
>>
>>
> What about those who are not on the blue sheets because we participated
> (and at the last meeting voted/hummed on this issue) through Jabber?
>
> Regards,
>
> Peter
>  _______________________________________________
> 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
>
>

--20cf307f38888869cf04ebb475fb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Following an IETF meeting on Jabber doesn't count as p=
articipating?

    The "big guy vs little guy" narr=
ative continues...


    

On Thu, Nov 21, 2013 at 10:17 AM, Jeremy Laurenson (jlaurens) <jlaurens@c=
isco.com> wrote:
    


    If they participated in the mailing lis=
t they would be included. I can't imagine that simply logging into a ch=
at room in order to vote qualifies you.

    


    On Nov 21, 2013, at 1:09 PM, Peter Dun=
kley <peter.dunkley@crocodilertc.net> wrote:

    



    On 21 November 2013 08:51, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
    



    
2) Establish those eligible to vote. =C2=A0Any participant in the
    
working group process either electronically or in-person as of yesterday
(20th of November). Who has participated in the Working group process
    
will be anyone that can be identified from:
    
=C2=A0- The Blue Sheets for any RTCWEB WG session during an IETF meeting or=

    
=C2=A0 =C2=A0an interim meeting since the WG's creation.
    
=C2=A0- posting of at least one email to the RTCWEB mailing list
    

    
The voter must at time of voting prove their eligibility, by pointing to
the mail archive or a particular blue sheet/meeting. Please verify your
    
own eligibility.
    



    What about those who are not on th=
e blue sheets because we participated (and at the last meeting voted/hummed=
 on this issue) through Jabber?

    Regards,
    




    Peter
    

    
_______________________________________________
    rtcweb mailing list
    <=
a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
    =
=
https://www.ietf.org/mailman/listinfo/rtcweb
    




    ______________________________=
_________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--20cf307f38888869cf04ebb475fb--

From adam@nostrum.com  Thu Nov 21 10:59:09 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735B11AE0A0 for ; Thu, 21 Nov 2013 10:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1osvW1-SI96 for ; Thu, 21 Nov 2013 10:59:08 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 677651AE001 for ; Thu, 21 Nov 2013 10:59:08 -0800 (PST)
Received: from Orochi.local (sccc-66-78-236-243.smartcity.com [66.78.236.243]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rALIwuE8073692 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 21 Nov 2013 12:58:58 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <528E57EC.6020000@nostrum.com>
Date: Thu, 21 Nov 2013 10:58:52 -0800
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Magnus Westerlund , "rtcweb@ietf.org" 
References: <528E39F4.4010706@ericsson.com>
In-Reply-To: <528E39F4.4010706@ericsson.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 66.78.236.243 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 18:59:09 -0000

On 11/21/13 08:51, Magnus Westerlund wrote:
> We (WG chairs) are proposing that the working group consent to a method
> that will establish an MTI, even if the MTI chosen does not have rough
> consensus.

Although this is phrased very carefully, I think this email 
inadvertently glosses over the fact that this is a formal call for 
consensus around the proposed approach. I also think you need to be 
crystal clear -- and I'm going to borrow RFC 3929's language here -- 
"that the working group's consensus to use [this specific] method stands 
in for the working group's consensus on the technical issue."

I wanted to point this out because it would be very easy to accidentally 
read the email as an announcement for the way the codec will be 
selected, rather than a call for consensus around a proposed approach.

/a

From mohammedsraad@raadtech.com  Thu Nov 21 11:01:07 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37811AE265 for ; Thu, 21 Nov 2013 11:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdG8Af_oKHBu for ; Thu, 21 Nov 2013 11:01:05 -0800 (PST)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by ietfa.amsl.com (Postfix) with ESMTP id E3C631AE264 for ; Thu, 21 Nov 2013 11:01:04 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id q58so171535wes.33 for ; Thu, 21 Nov 2013 11:00:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AjAUKkqbjSaUPJUju9qmSnOY7Kqa7DoGHjQ/KjXZNT8=; b=FTZlIKWFd6S2n2KQ9QaHE3Iq3r/55pp10BAeeyLYPRwsoLidWegm1ifJCJoVL7aaFn /+aZXgaACvwCUjDFRWVu8cDMVFW+d7uoXbaXdpTCyeA2Y2dgcOPQ80aQxFVTBcjhibMZ rNWETs8BmJSooqrOwcz2PB017cvLORzupnBB8to9yNX+mKvJhRTaKDyf0aPoAY0rs+Xh pkGf0xWi0nGMtmDBeHJS6QkT75Fu7INGUmSM+e96LymsrnW26L9E6O51WO0JTfVnq5cz A69m90VhikdGsXtJedeZ2ff8CPO0mRwM48ibGGOF6Rgt0roqwBxkFbQOcZSybiSL1IPk uLeg==
X-Gm-Message-State: ALoCoQm0JAEjekydycTA/DxIe4y7C7w2f7AkbVRnAn8tLSJ9SP9VcfeqOlyXMxvs2t0i4bXrLKSe
MIME-Version: 1.0
X-Received: by 10.194.2.108 with SMTP id 12mr2343913wjt.64.1385060457458; Thu, 21 Nov 2013 11:00:57 -0800 (PST)
Received: by 10.194.179.166 with HTTP; Thu, 21 Nov 2013 11:00:57 -0800 (PST)
Received: by 10.194.179.166 with HTTP; Thu, 21 Nov 2013 11:00:57 -0800 (PST)
In-Reply-To: 
References: <528D6C63.7050607@bbs.darktech.org> <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr> <5A2BC34D-FE4D-4420-B52F-729087815F37@cisco.com> 
Date: Fri, 22 Nov 2013 06:00:57 +1100
Message-ID: 
From: Mohammed Raad 
To: Cullen Jennings 
Content-Type: multipart/alternative; boundary=047d7b3440da8f45cb04ebb4842f
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:01:08 -0000

--047d7b3440da8f45cb04ebb4842f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

Typically "smart" transcoding operates at 50 percent complexity or less. We
did a fair bit of this at Dilithium Networks when I was there. There are
also significant memory and delay savings when one operates on the MB level
instead of the picture level. With regards to IPR, there is a significant
number of current patents in this area that are not in any multi
organization patent pool as far as I know. Transcoding in this way also
provides quality advantages over tandem transcoding.

Obviously the more similar the codecs the more one gains. In the case of
VP8 and AVC CBP, there are significant enough differences in essential
elements such as the way quantization is done to make this kind of
transcoding challenging, but it is possible and the numbers mentioned in
the previous post sound about right.

Mohammed
On 21 Nov 2013 20:45, "Cullen Jennings"  wrote:

>
> It's a cool demo and I talked to the team that did it. This is only
> possible because VP8 and H.264 are very similar codecs. The idea is to no=
t
> redo the motion vector computations or the DCT but just reuse the values
> from one format in the other since they are the same. They hope that this
> can provide reduce the CPU by 1/3 from a full decode then re-encode. It
> also help reduce loss of quality for video. Other people have talked abou=
t
> this idea over the years and many people think it can give a 2 to 3 speed
> up so that seems consistent with their goals.
>
> It still requires the same bandwidth, and has similar other impacts. I ca=
n
> not see any way that it would not require MPEG-LA IPR for 264.
>
>
> On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty) 
> wrote:
>
> > This probably refers to an intelligent transcoder versus a brute force
> transcoder. An intelligent transcoder harvests more data during decoding
> than just the raw output pixels, and uses this extra data to ease encodin=
g.
> Data like block partitions, motion vectors, intra modes, quantization
> parameters, etc.
> >
> > This is common for common conversions, like MPEG2 to H.264. VP8 and
> H.264 are much closer formats, so this can significantly improve transcod=
er
> performance.
> >
> > However, this is strictly a performance optimization, with no impact on
> IPR or licensing issues.
> >
> > Mo
> >
> >
> > On Nov 21, 2013, at 2:51 AM, "Bossiel"  wrote:
> >
> > This could be true if they can also walk on water and change it into
> wine.
> > To be serious, no it's not possible.
> > Mamadou
> >
> > Sent from my iPhone
> >
> > On Nov 21, 2013, at 3:13, Gili  wrote:
> >
> >> Hi,
> >>
> >> I'm at the WebRTC World conference. If I understood correctly, Zingaya
> just demoed what they claim is a VP8 to H.264 bridge that converts the
> video without transcoding. My interpretation is that they convert the
> surrounding packet format without re-encoding the actual video. Someone w=
ho
> understands codec internals (I don't) might want to validate this claim,
> because it could have a significant impact on the MTI debate.
> >>
> >> It sounds far fetched, but imagine the possibilities:
> >>      =95 If the video is not being re-encoded, do H.264 royalties appl=
y?
> >>      =95 If the conversion is really cheap, is it feasible to connect =
a
> H.264 peer to a VP8 peer and have one of them convert in-line (no MCU)?
> >> Gili
> >> _______________________________________________
> >> 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
>

--047d7b3440da8f45cb04ebb4842f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


    Hi,
    

    Typically "smart" transcoding operates at 50 percent complexit=
y or less. We did a fair bit of this at Dilithium Networks when I was there=
. There are also significant memory and delay savings when one operates on =
the MB level instead of the picture level. With regards to IPR, there is a =
significant number of current patents in this area that are not in any mult=
i organization patent pool as far as I know. Transcoding in this way also p=
rovides quality advantages over tandem transcoding. 
    


    Obviously the more similar the codecs the more one gains. In the case of=
 VP8 and AVC CBP, there are significant enough differences in essential ele=
ments such as the way quantization is done to make this kind of transcoding=
 challenging, but it is possible and the numbers mentioned in the previous =
post sound about right.
    

    

    Mohammed
    

    On 21 Nov 2013 20:45, "Cullen Jennings"=
; <fluffy@iii.ca> wrote:
    

    
It's a cool demo and I talked to the team that did it. This is only pos=
sible because VP8 and H.264 are very similar codecs. The idea is to not red=
o the motion vector computations or the DCT but just reuse the values from =
one format in the other since they are the same. They hope that this can pr=
ovide reduce the CPU by 1/3 from a full decode then re-encode. It also help=
 reduce loss of quality for video. Other people have talked about this idea=
 over the years and many people think it can give a 2 to 3 speed up so that=
 seems consistent with their goals.
    


    
It still requires the same bandwidth, and has similar other impacts. I can =
not see any way that it would not require MPEG-LA IPR for 264.
    

    

    
On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:
    

    
> This probably refers to an intelligent transcoder versus a brute force=
 transcoder. An intelligent transcoder harvests more data during decoding t=
han just the raw output pixels, and uses this extra data to ease encoding. =
Data like block partitions, motion vectors, intra modes, quantization param=
eters, etc.
    

>
    
> This is common for common conversions, like MPEG2 to H.264. VP8 and H.=
264 are much closer formats, so this can significantly improve transcoder p=
erformance.
    
>
    
> However, this is strictly a performance optimization, with no impact o=
n IPR or licensing issues.
    
>
    
> Mo
    
>
    
>
    
> On Nov 21, 2013, at 2:51 AM, "Bossiel" <bossiel@yahoo.fr> wrote:
    
>
    
> This could be true if they can also walk on water and change it into w=
ine.
    
> To be serious, no it's not possible.
    
> Mamadou
    
>
    
> Sent from my iPhone
    
>
    
> On Nov 21, 2013, at 3:13, Gili <cowwoc@bbs.darktech.org> wrote:
    
>
    
>> Hi,
    
>>
    
>> I'm at the WebRTC World conference. If I understood correctly,=
 Zingaya just demoed what they claim is a VP8 to H.264 bridge that converts=
 the video without transcoding. My interpretation is that they convert the =
surrounding packet format without re-encoding the actual video. Someone who=
 understands codec internals (I don't) might want to validate this clai=
m, because it could have a significant impact on the MTI debate.
    

>>
    
>> It sounds far fetched, but imagine the possibilities:
    
>> =A0 =A0 =A0=95 If the video is not being re-encoded, do H.264 roya=
lties apply?
    
>> =A0 =A0 =A0=95 If the conversion is really cheap, is it feasible t=
o connect a H.264 peer to a VP8 peer and have one of them convert in-line (=
no MCU)?
    
>> Gili
    
>> _______________________________________________
    
>> 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
    

    

--047d7b3440da8f45cb04ebb4842f--

From harald@alvestrand.no  Thu Nov 21 11:12:40 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C791AE262 for ; Thu, 21 Nov 2013 11:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.425
X-Spam-Level: 
X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP7wbDn29s5k for ; Thu, 21 Nov 2013 11:12:37 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 928E71AE072 for ; Thu, 21 Nov 2013 11:12:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 30E0A39EAAF for ; Thu, 21 Nov 2013 20:12:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IIUt2lnYtX1 for ; Thu, 21 Nov 2013 20:11:53 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4F6C339E197 for ; Thu, 21 Nov 2013 20:11:53 +0100 (CET)
Message-ID: <528E5AF7.5080403@alvestrand.no>
Date: Thu, 21 Nov 2013 20:11:51 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com>
In-Reply-To: <528E39F4.4010706@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Voting method choice (Re: Proposed Video Selection Process)
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:12:40 -0000

Forking this thread, and leaving aside all consideration of whether the 
IETF should do voting, whether the electorate is the right electorate 
for the decision and so on:

I wonder if Instant Runoff is the right choice for this situation.
Instant Runoff means that when you don't get a majority for anything, 
you drop the lowest-ranked candidate and distribute the ballots that had 
this as their #1 across the other candidates.

This has the property that in a polarized situation, compromises may get 
dropped out of the running before the alternatives that they might serve 
as a compromise between.

In this case, I'd favour a Condorcet-compatible method, such as Schulze; 
it provides the guarantee that if a choice is preferred by a majority of 
the participants over every other choice, it will always be chosen.

http://en.wikipedia.org/wiki/Condorcet_method#Schulze_method


On 11/21/2013 05:51 PM, Magnus Westerlund wrote:
> WG,
>
> The WebRTC ecosystem needs to avoid interoperability failure to grow
> optimally.  The RTCWEB working group took on the task of establish Audio
> and Video MTI codecs as part of meeting that need. We have not succeeded
> in finishing that task for video using normal IETF process, but it is
> still important.
>
> We (WG chairs) are proposing that the working group consent to a method
> that will establish an MTI, even if the MTI chosen does not have rough
> consensus.  We would far prefer the normal IETF process, but it is not
> proving workable for this selection.
>
> We initially proposed a method from RFC 3929 (external review team), but
> now believe that the working group would not consent to that method.
> Instead we are proposing a method that leaves the decision in the hands
> of the WG.
> google.com
> The method we propose is based on Instant-runoff voting,
> http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
> understanding that the choice will be the winner according to the
> Instant-runoff voting process.
>
> The steps in the proposed process are these (1-5):
>
> 1) Establish a final list of alternatives, based on the WG's input to
> Gonzalo's email on the 13th of November that requires any additions to
> provided by end of the 27th of November.
>
> 2) Establish those eligible to vote.  Any participant in the
> working group process either electronically or in-person as of yesterday
> (20th of November). Who has participated in the Working group process
> will be anyone that can be identified from:
>   - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
>     an interim meeting since the WG's creation.
>   - posting of at least one email to the RTCWEB mailing list
>
> The voter must at time of voting prove their eligibility, by pointing to
> the mail archive or a particular blue sheet/meeting. Please verify your
> own eligibility.
>
> 3) Start the the voting period. Those eligible and willing to vote send
> their ballot to a vote collector (Matt Lepinski, former Nomcom chair)
> within two weeks using email. The vote collector will check when
> receiving a ballot the that the voter is eligible and send a
> confirmation email on receiving the ballot. During the balloting period
> the vote collector will keep all ballots secret.
>
> Balloting:
>   - The voter MUST rank ALL alternatives in their ballot from the most
>     preferred, marked with rank 1, the second most with 2, all the way
>     to the least preferred marked with rank N.
>
>
> 4) When the voting period is over the ballot collector will publish the
> results as well as all ballots, including the voters name to the RTCWEB
> WG mailing list. This enables all voting individuals to verify that
> their ballot is unmodified. And allows anyone to verify the result of
> the vote.
>
> 5) The selection is recorded in the drafts.
>
>
> --- End of Process Proposal ---
>
> This message initiates the first step in the working group consensus
> call process. Namely a one week comment and discussion period for the
> above process.
>
> After that week the WG chairs will update, if necessary, the proposal.
> Then using the normal IETF process in which anyone is eligible to
> participate, the chairs will ask for (rough) consensus to adopt this
> extraordinary process to achieve the working group's stated goals.  The
> end date for this consensus call is 2-weeks after the announcement of
> the consensus call.
>
> If the working group does not consent to using this extraordinary
> process, we will hold a consensus call if the WG can accept
> "WebRTC entities MUST support at least one of H.264 or VP8.".
>
> If there is failure to establish consensus even for this statement, the
> chairs conclude that the WG can't establish what to say about a MTI
> video codec.
>
> The WG Chairs
>
> Magnus Westerlund
> Cullen Jennings
> Ted Hardie
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From adam@nostrum.com  Thu Nov 21 11:13:27 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997BF1AE050 for ; Thu, 21 Nov 2013 11:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXRJ3KAkIH_V for ; Thu, 21 Nov 2013 11:13:26 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B4BDD1AE001 for ; Thu, 21 Nov 2013 11:13:26 -0800 (PST)
Received: from Orochi.local (sccc-66-78-236-243.smartcity.com [66.78.236.243]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rALJDFGa074276 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 21 Nov 2013 13:13:16 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <528E5B47.70702@nostrum.com>
Date: Thu, 21 Nov 2013 11:13:11 -0800
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Justin Uberti , "Jeremy Laurenson (jlaurens)" 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 66.78.236.243 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:13:27 -0000

On 11/21/13 10:56, Justin Uberti wrote:
> Following an IETF meeting on Jabber doesn't count as participating?
>
> The "big guy vs little guy" narrative continues...

I think that's a bit specious. If someone is following the issue at such 
a distance that they haven't expressed an opinion on the mailing list, I 
can't see how taking a vote from them counts as anything other than 
simple, old-fashioned ballot stuffing.

I'll take it one step further. I find the prospect that we're allowing 
blue sheets to stand in for participation to be highly questionable: 
letting the tourists vote is weighting the opinion of demonstrably 
uninvolved (or less-involved) parties at the same level as those who 
have actually been working on the topic. I do not think that a 
blue-sheet sign in without any on-list participation should be 
sufficient to participate in the kind of process the chairs are proposing.

Or perhaps I'm missing something. Is there something about the 
capabilities of "the little guy" that makes sending an email an 
unrealistically high barrier to entry?

/a

From fippo@goodadvice.pages.de  Thu Nov 21 11:19:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061861AE05C for ; Thu, 21 Nov 2013 11:19:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfzLvLa7OwQD for ; Thu, 21 Nov 2013 11:19:10 -0800 (PST)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id E52D91AE207 for ; Thu, 21 Nov 2013 11:19:09 -0800 (PST)
Received: from [192.168.2.101] (p54973753.dip0.t-ipconnect.de [84.151.55.83]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id rALJJ0VM020467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Nov 2013 20:19:02 +0100
Message-ID: <528E5CA0.8080007@goodadvice.pages.de>
Date: Thu, 21 Nov 2013 20:18:56 +0100
From: Philipp Hancke 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com>  <827DC810-21FD-494D-9E44-6C7406887464@iii.ca>
In-Reply-To: <827DC810-21FD-494D-9E44-6C7406887464@iii.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:19:13 -0000

> If there are any people in that category that wish to vote, could they email the chairs with full name and affiliation. That would make it easier to figure out how to deal with this issue. I think it will be hard to take votes from someone that will not provide the information required to be on a blue sheet due to questions about double counting.

There is an issue with the jabber logs: they only record room nicknames, 
not the full JID. So there is no way to tell who that "stpeter" or "EKR" 
guy really is.

That is certainly something that needs to be improved in the future.

From ekr@rtfm.com  Thu Nov 21 11:20:03 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683A11AE247 for ; Thu, 21 Nov 2013 11:20:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v6_En-UFU1G for ; Thu, 21 Nov 2013 11:19:59 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 703671AE05C for ; Thu, 21 Nov 2013 11:19:59 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id k14so195155wgh.11 for ; Thu, 21 Nov 2013 11:19:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VaYkkfz47rsmoZno9HVOsCuIKtRb+wsBjmxAuch8GpQ=; b=UO0A67otL1mkXjdNHf8HF/2ev0JQi87CMw/7UI2o1Y5xPHUmcYL2cXyuqo9ikknutE f11iXrjz64AHStxbK5WN3n7a9VnN0ddNKUQn4SNmeU9IQb9ZQrJjEVRGQK1mX+ds4AmH Ly4KwDiy4o3MhAvYQ323CZ4dk2DsVK+o12YbxdXLwQZQXRnrebMfmZ5WQp2ERt0Bkad6 74WOALS2oU/epaHDGdh5pSD+b5g+dKjw7h7j04Vmn7IZuQX8Oyyjlvr3XWtB5zcAN4PB oum4o7J9REx0rQpX41+Vz6JWZvv0YLvDw13J/HnkGWTroUU/DptHCVtNuO3tuRWvhGnp NtbQ==
X-Gm-Message-State: ALoCoQkPHsEeBL3p4CaRwAyPg4jt8tHFtgxIr0DdEqJwVHRM2zX4nVrDO7g9QLAE/2Hk2tqPGaCn
X-Received: by 10.180.221.38 with SMTP id qb6mr7156472wic.8.1385061592185; Thu, 21 Nov 2013 11:19:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 21 Nov 2013 11:19:12 -0800 (PST)
X-Originating-IP: [63.245.220.224]
In-Reply-To: <528E5AF7.5080403@alvestrand.no>
References: <528E39F4.4010706@ericsson.com> <528E5AF7.5080403@alvestrand.no>
From: Eric Rescorla 
Date: Thu, 21 Nov 2013 11:19:12 -0800
Message-ID: 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=001a1134d2da320f2c04ebb4c8d4
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video Selection Process)
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:20:03 -0000

--001a1134d2da320f2c04ebb4c8d4
Content-Type: text/plain; charset=ISO-8859-1

In order to forestall the inevitable voting nerd thread, allow me to
point to:

http://en.wikipedia.org/wiki/Arrow%27s_theorem

-Ekr



On Thu, Nov 21, 2013 at 11:11 AM, Harald Alvestrand wrote:

> Forking this thread, and leaving aside all consideration of whether the
> IETF should do voting, whether the electorate is the right electorate for
> the decision and so on:
>
> I wonder if Instant Runoff is the right choice for this situation.
> Instant Runoff means that when you don't get a majority for anything, you
> drop the lowest-ranked candidate and distribute the ballots that had this
> as their #1 across the other candidates.
>
> This has the property that in a polarized situation, compromises may get
> dropped out of the running before the alternatives that they might serve as
> a compromise between.
>
> In this case, I'd favour a Condorcet-compatible method, such as Schulze;
> it provides the guarantee that if a choice is preferred by a majority of
> the participants over every other choice, it will always be chosen.
>
> http://en.wikipedia.org/wiki/Condorcet_method#Schulze_method
>
>
> On 11/21/2013 05:51 PM, Magnus Westerlund wrote:
>
>> WG,
>>
>> The WebRTC ecosystem needs to avoid interoperability failure to grow
>> optimally.  The RTCWEB working group took on the task of establish Audio
>> and Video MTI codecs as part of meeting that need. We have not succeeded
>> in finishing that task for video using normal IETF process, but it is
>> still important.
>>
>> We (WG chairs) are proposing that the working group consent to a method
>> that will establish an MTI, even if the MTI chosen does not have rough
>> consensus.  We would far prefer the normal IETF process, but it is not
>> proving workable for this selection.
>>
>> We initially proposed a method from RFC 3929 (external review team), but
>> now believe that the working group would not consent to that method.
>> Instead we are proposing a method that leaves the decision in the hands
>> of the WG.
>> google.com
>> The method we propose is based on Instant-runoff voting,
>> http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
>> understanding that the choice will be the winner according to the
>> Instant-runoff voting process.
>>
>> The steps in the proposed process are these (1-5):
>>
>> 1) Establish a final list of alternatives, based on the WG's input to
>> Gonzalo's email on the 13th of November that requires any additions to
>> provided by end of the 27th of November.
>>
>> 2) Establish those eligible to vote.  Any participant in the
>> working group process either electronically or in-person as of yesterday
>> (20th of November). Who has participated in the Working group process
>> will be anyone that can be identified from:
>>   - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
>>     an interim meeting since the WG's creation.
>>   - posting of at least one email to the RTCWEB mailing list
>>
>> The voter must at time of voting prove their eligibility, by pointing to
>> the mail archive or a particular blue sheet/meeting. Please verify your
>> own eligibility.
>>
>> 3) Start the the voting period. Those eligible and willing to vote send
>> their ballot to a vote collector (Matt Lepinski, former Nomcom chair)
>> within two weeks using email. The vote collector will check when
>> receiving a ballot the that the voter is eligible and send a
>> confirmation email on receiving the ballot. During the balloting period
>> the vote collector will keep all ballots secret.
>>
>> Balloting:
>>   - The voter MUST rank ALL alternatives in their ballot from the most
>>     preferred, marked with rank 1, the second most with 2, all the way
>>     to the least preferred marked with rank N.
>>
>>
>> 4) When the voting period is over the ballot collector will publish the
>> results as well as all ballots, including the voters name to the RTCWEB
>> WG mailing list. This enables all voting individuals to verify that
>> their ballot is unmodified. And allows anyone to verify the result of
>> the vote.
>>
>> 5) The selection is recorded in the drafts.
>>
>>
>> --- End of Process Proposal ---
>>
>> This message initiates the first step in the working group consensus
>> call process. Namely a one week comment and discussion period for the
>> above process.
>>
>> After that week the WG chairs will update, if necessary, the proposal.
>> Then using the normal IETF process in which anyone is eligible to
>> participate, the chairs will ask for (rough) consensus to adopt this
>> extraordinary process to achieve the working group's stated goals.  The
>> end date for this consensus call is 2-weeks after the announcement of
>> the consensus call.
>>
>> If the working group does not consent to using this extraordinary
>> process, we will hold a consensus call if the WG can accept
>> "WebRTC entities MUST support at least one of H.264 or VP8.".
>>
>> If there is failure to establish consensus even for this statement, the
>> chairs conclude that the WG can't establish what to say about a MTI
>> video codec.
>>
>> The WG Chairs
>>
>> Magnus Westerlund
>> Cullen Jennings
>> Ted Hardie
>>
>>
>> _______________________________________________
>> 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
>

--001a1134d2da320f2c04ebb4c8d4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    In order to forestall the inevitable voting nerd thread, a=
llow me to
    point to:


    -Ekr



    On Thu, Nov 21, 2013 at 11:11 A=
M, Harald Alvestrand <harald@alvestrand.no> wrote:
    


    Forking this thread, and leaving aside all c=
onsideration of whether the IETF should do voting, whether the electorate i=
s the right electorate for the decision and so on:
    



    
I wonder if Instant Runoff is the right choice for this situation.
    
Instant Runoff means that when you don't get a majority for anything, y=
ou drop the lowest-ranked candidate and distribute the ballots that had thi=
s as their #1 across the other candidates.
    

    
This has the property that in a polarized situation, compromises may get dr=
opped out of the running before the alternatives that they might serve as a=
 compromise between.
    

    
In this case, I'd favour a Condorcet-compatible method, such as Schulze=
; it provides the guarantee that if a choice is preferred by a majority of =
the participants over every other choice, it will always be chosen.
    



    
http://en.wikipedia.org/wiki/Condorcet_method#Schulz=
e_method
    

    

    
On 11/21/2013 05:51 PM, Magnus Westerlund wrote:
    

    
WG,
    

    
The WebRTC ecosystem needs to avoid interoperability failure to grow
    
optimally. =A0The RTCWEB working group took on the task of establish Audio<=
br>
and Video MTI codecs as part of meeting that need. We have not succeeded
in finishing that task for video using normal IETF process, but it is
    
still important.
    

    
We (WG chairs) are proposing that the working group consent to a method
    
that will establish an MTI, even if the MTI chosen does not have rough
    
consensus. =A0We would far prefer the normal IETF process, but it is not
proving workable for this selection.
    

    
We initially proposed a method from RFC 3929 (external review team), but
now believe that the working group would not consent to that method.
    
Instead we are proposing a method that leaves the decision in the hands
    
of the WG.
    
google.com
    
The method we propose is based on Instant-runoff voting,
    
http://en.wikipedia.org/wiki/Instant-runoff_voting, with t=
he
    
understanding that the choice will be the winner according to the
    
Instant-runoff voting process.
    

    
The steps in the proposed process are these (1-5):
    

    
1) Establish a final list of alternatives, based on the WG's input to
Gonzalo's email on the 13th of November that requires any additions to<=
br>
provided by end of the 27th of November.
    

    
2) Establish those eligible to vote. =A0Any participant in the
    
working group process either electronically or in-person as of yesterday
(20th of November). Who has participated in the Working group process
    
will be anyone that can be identified from:
    
=A0 - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
=A0 =A0 an interim meeting since the WG's creation.
    
=A0 - posting of at least one email to the RTCWEB mailing list
    

    
The voter must at time of voting prove their eligibility, by pointing to
the mail archive or a particular blue sheet/meeting. Please verify your
    
own eligibility.
    

    
3) Start the the voting period. Those eligible and willing to vote send
    
their ballot to a vote collector (Matt Lepinski, former Nomcom chair)
    
within two weeks using email. The vote collector will check when
    
receiving a ballot the that the voter is eligible and send a
    
confirmation email on receiving the ballot. During the balloting period
    
the vote collector will keep all ballots secret.
    

    
Balloting:
    
=A0 - The voter MUST rank ALL alternatives in their ballot from the most
=A0 =A0 preferred, marked with rank 1, the second most with 2, all the way<=
br>
=A0 =A0 to the least preferred marked with rank N.
    

    

    
4) When the voting period is over the ballot collector will publish the
    
results as well as all ballots, including the voters name to the RTCWEB
    
WG mailing list. This enables all voting individuals to verify that
    
their ballot is unmodified. And allows anyone to verify the result of
    
the vote.
    

    
5) The selection is recorded in the drafts.
    

    

    
--- End of Process Proposal ---
    

    
This message initiates the first step in the working group consensus
    
call process. Namely a one week comment and discussion period for the
    
above process.
    

    
After that week the WG chairs will update, if necessary, the proposal.
    
Then using the normal IETF process in which anyone is eligible to
    
participate, the chairs will ask for (rough) consensus to adopt this
    
extraordinary process to achieve the working group's stated goals. =A0T=
he
    
end date for this consensus call is 2-weeks after the announcement of
    
the consensus call.
    

    
If the working group does not consent to using this extraordinary
    
process, we will hold a consensus call if the WG can accept
    
"WebRTC entities MUST support at least one of H.264 or VP8.".
    

    
If there is failure to establish consensus even for this statement, the
    
chairs conclude that the WG can't establish what to say about a MTI
    
video codec.
    

    
The WG Chairs
    

    
Magnus Westerlund
    
Cullen Jennings
    
Ted Hardie
    

    

    
_______________________________________________
    
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
    


    

--001a1134d2da320f2c04ebb4c8d4--

From fluffy@iii.ca  Thu Nov 21 11:21:21 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A811AE26C for ; Thu, 21 Nov 2013 11:21:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pz_j0q93fmr for ; Thu, 21 Nov 2013 11:21:18 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 877751AE263 for ; Thu, 21 Nov 2013 11:21:18 -0800 (PST)
Received: from sjc-vpn3-1087.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 762F222E1F3; Thu, 21 Nov 2013 14:21:05 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: <528E57EC.6020000@nostrum.com>
Date: Thu, 21 Nov 2013 11:21:40 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <528E39F4.4010706@ericsson.com> <528E57EC.6020000@nostrum.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:21:21 -0000

The intention was to discus this for a week update it as needed,  then =
make the formal consensus call to use the proposed process process. So I =
agree we need a very clear consensus call on it.=20

On Nov 21, 2013, at 10:58 AM, Adam Roach  wrote:

> On 11/21/13 08:51, Magnus Westerlund wrote:
>> We (WG chairs) are proposing that the working group consent to a =
method
>> that will establish an MTI, even if the MTI chosen does not have =
rough
>> consensus.
>=20
> Although this is phrased very carefully, I think this email =
inadvertently glosses over the fact that this is a formal call for =
consensus around the proposed approach. I also think you need to be =
crystal clear -- and I'm going to borrow RFC 3929's language here -- =
"that the working group's consensus to use [this specific] method stands =
in for the working group's consensus on the technical issue."
>=20
> I wanted to point this out because it would be very easy to =
accidentally read the email as an announcement for the way the codec =
will be selected, rather than a call for consensus around a proposed =
approach.
>=20
> /a
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From singer@apple.com  Thu Nov 21 11:21:45 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E089B1AE275 for ; Thu, 21 Nov 2013 11:21:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Level: 
X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg3z0nObl_vt for ; Thu, 21 Nov 2013 11:21:42 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 035711AE247 for ; Thu, 21 Nov 2013 11:21:42 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWM00E5WODS30B0@mail-out.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 11:20:27 -0800 (PST)
X-AuditID: 11807143-b7fbb6d00000049d-df-528e5cfaa884
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay2.apple.com (Apple SCV relay) with SMTP id 98.4E.01181.AFC5E825; Thu, 21 Nov 2013 11:20:27 -0800 (PST)
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWM00DJ0OE2KX40@spicerack.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 11:20:26 -0800 (PST)
From: David Singer 
In-reply-to: <528E4139.3050808@googlemail.com>
Date: Thu, 21 Nov 2013 11:20:26 -0800
Content-transfer-encoding: quoted-printable
Message-id: <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1822)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUi2FCsofs7pi/I4N5zJou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8WmOXMEq8YpTszczNTDeFepi5OCQEDCReLTXvouRE8gUk7hw bz0biC0kMJlJYtlrbgh7NZNE5042kHJmAT2J+xe1QMK8QOat5vvMIGFhAUuJC8dNQMJsAqoS D+YcYwSxOYFKlvz6wA5iswDF537eCRZnFtCWePLuAivEGBuJRbteM3UxcgFtOsossfv7GhaQ hIiAsMTWV71MEKfJSux+/p15AiP/LIQrZiG5YhaSsQsYmVcxChSl5iRWGuklFhTkpOol5+du YgSHVaHzDsZjy6wOMQpwMCrx8O6w7AsSYk0sK67MPcQowcGsJML7VR0oxJuSWFmVWpQfX1Sa k1p8iFGag0VJnHeHL1BKID2xJDU7NbUgtQgmy8TBKdXA6G/RZSU5f+d3zoyWXw4SvRs5CnfL f7x5qcJ//emKrms1ad8jZjIYZXNHbfmy4XHsF5P9/A6un68w631x9LLOrRf6MfnO9k18dza9 ZY/cP0t1e8v+xpNxtsG94TxFJ9ZMY77DWFvnc1umYL4fp/bN0p1qb66kte8ukWw8v2qzdHtw RNiss1umK7EUZyQaajEXFScCADmzwn0nAgAA
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:21:46 -0000

Chairs

can we add this as an option to the formal list, so we get formal =
feedback on its acceptability, please?

=93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94


I think this may be the best (maybe only) way to tease out how much risk =
people perceive.

Many thanks

On Nov 21, 2013, at 9:22 , Maik Merten  =
wrote:

> Cleary H.263 is preferable from an engineering standpoint (as is, =
e.g., MPEG-1 Part 2): better performance, more deployments. The central =
question is, however, if those can actually be implemented without some =
sort of licensing.
>=20
> If they can: Aweseome! However, this may not be determinable without a =
review by people who are knowledgeable in the field of IPR, i.e., =
"actual lawyers". I understand that H.263 is not yet old enough to =
automatically be considered "safe" (and neither is MPEG-1 Part 2, =
although it is closer).
>=20
> Best regards,
>=20
> Maik
>=20
> Am 20.11.2013 20:42, schrieb David Singer:
>> I think we should think hard about H.263 instead of H.261 as the =
third fallback.  Why?
>>=20
>> http://www.itu.int/rec/T-REC-H.263/
>>=20
>>=20
>>=20
>> H.263 was first published in March 1996, so it's 17 years old.  The =
restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more =
recent amendments deal with this (and a plethora of other issues), so =
we=92d need to settle on which of those are mandatory (the usual =
profiling discussion).
>>=20
>> There are 34 records in the patent database against H.261, mostly =
from 1989 but one as recent as 2005 (though that is a re-file).  That's =
2.2 (reciprocity), as was one other I checked.
>>=20
>> Rather surprisingly, there are only 31 against H.263!  The most =
recent is 2011, and is also option 2.  Most are 1997-2001.
>>=20
>>=20
>> On this quick glance, H.263 appears no worse than H.261. IANAL (as I =
am sure you have all noticed).
>>=20
>>=20
>> H.263 is much more widely supported and mandated.  It has been =
mandated in the 3GPP specs for years (for lots of services, including =
videoconf), and is effectively the fallback codec today in the industry, =
as I understand.  It was ubiquitous in video telephony for years, and I =
suspect many of those systems still ship it.
>>=20
>> So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 =
work?
>>=20
>> (I am asking the question, not even answering on behalf of my =
company, yet.  Let=92s get the issues on the table.)
>>=20
>>=20
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

David Singer
Multimedia and Software Standards, Apple Inc.


From peter.dunkley@crocodilertc.net  Thu Nov 21 11:21:47 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE051AE247 for ; Thu, 21 Nov 2013 11:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSQshh6yImew for ; Thu, 21 Nov 2013 11:21:43 -0800 (PST)
Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 957571AE273 for ; Thu, 21 Nov 2013 11:21:43 -0800 (PST)
Received: by mail-pb0-f49.google.com with SMTP id jt11so186816pbb.22 for ; Thu, 21 Nov 2013 11:21:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=XXdMD+OPrHPjbT1ZM/GoqxQ/nA7qeKArEYncfKxihoE=; b=KHVzGYzUMx3qeE7yIrH4EqM/XDLh4p5vfwCj6Je+CzNdreA2M2w8LwMsnwakAiUd2i hVNFTGMa8aj+cAwGrrYcuBy4e837EiGNCzg3WH3Nrx3GwsyFZh+cpZd1c5KFhiuJtQ0C KOjo1uGm0afskEPg/IV/VWfQc3QYyLTgepgTI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=XXdMD+OPrHPjbT1ZM/GoqxQ/nA7qeKArEYncfKxihoE=; b=j/bYsipkILqK4G2uvd/4b6u3SnpIskcHnpAF1YFsLgSSptSAEBaDK537+zs5OzUEQ7 Gni7vj+0xUkl8TWE788P15X+mnjFXA/Gr4gm/ZEbPmSC6pmAFbd8pUrQjz9rVf9mllsP a44RKhX4hT9GTVQEQMPWwQ6hQuPA7VJhuDa+NeFBkn+878CehpRK+LpzjN2lLE/am48j Pt6qOsT08lfmxU28mdqXej085A/mc7ckNMZIbrNU8r08VRuu6vb7UXEpWDKVxNb2TvHH 3+ZFdtmDdOnVITFWHzCNv0z1FuiR/2+B/3dW3Xp5YWfbD+Pws6DDVbM+ibfCUZdt46Ur 2nDA==
X-Gm-Message-State: ALoCoQmj0ksFcV9XG/K3vjiJ+P1WPQCjkKieDoyXJF/lInhsEXRfLRA7DDv5c8ltC+Z2yRtKn1pY
X-Received: by 10.69.31.170 with SMTP id kn10mr7882381pbd.106.1385061696913; Thu, 21 Nov 2013 11:21:36 -0800 (PST)
Received: from [10.35.1.201] (sccc-66-78-236-243.smartcity.com. [66.78.236.243]) by mx.google.com with ESMTPSA id kd1sm53992339pab.20.2013.11.21.11.21.36 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 11:21:36 -0800 (PST)
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <528E5B47.70702@nostrum.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (11B554a)
From: Peter Dunkley 
Date: Thu, 21 Nov 2013 11:21:24 -0800
To: Adam Roach 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:21:47 -0000

Barring blue sheets signers who have not sent an email on the list as well w=
ould seem fair to me.

What I considered unfair was those that had been able to attend in person (b=
ut not really contributed) could vote when those online could not.

Regards,

Peter

--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

> On 21 Nov 2013, at 11:13, Adam Roach  wrote:
>=20
>> On 11/21/13 10:56, Justin Uberti wrote:
>> Following an IETF meeting on Jabber doesn't count as participating?
>>=20
>> The "big guy vs little guy" narrative continues...
>=20
> I think that's a bit specious. If someone is following the issue at such a=
 distance that they haven't expressed an opinion on the mailing list, I can'=
t see how taking a vote from them counts as anything other than simple, old-=
fashioned ballot stuffing.
>=20
> I'll take it one step further. I find the prospect that we're allowing blu=
e sheets to stand in for participation to be highly questionable: letting th=
e tourists vote is weighting the opinion of demonstrably uninvolved (or less=
-involved) parties at the same level as those who have actually been working=
 on the topic. I do not think that a blue-sheet sign in without any on-list p=
articipation should be sufficient to participate in the kind of process the c=
hairs are proposing.
>=20
> Or perhaps I'm missing something. Is there something about the capabilitie=
s of "the little guy" that makes sending an email an unrealistically high ba=
rrier to entry?
>=20
> /a
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From singer@apple.com  Thu Nov 21 11:25:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00601AE079 for ; Thu, 21 Nov 2013 11:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.427
X-Spam-Level: 
X-Spam-Status: No, score=-9.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN9AZhQ-t6fZ for ; Thu, 21 Nov 2013 11:24:58 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id E384D1AE05D for ; Thu, 21 Nov 2013 11:24:58 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWM002O2OKZ44Z1@mail-out.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 11:24:52 -0800 (PST)
X-AuditID: 1180715a-b7f3c6d00000020e-19-528e5e03df0b
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay6.apple.com (Apple SCV relay) with SMTP id 7B.06.00526.30E5E825; Thu, 21 Nov 2013 11:24:51 -0800 (PST)
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWM00DO0OLFKX40@spicerack.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 11:24:51 -0800 (PST)
From: David Singer 
In-reply-to: <528E5057.30408@stpeter.im>
Date: Thu, 21 Nov 2013 11:24:51 -0800
Content-transfer-encoding: quoted-printable
Message-id: 
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1822)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FCsocsc1xdkcOibucXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeDPrA0vBXY6KnTOOsDcwtrB3MXJySAiYSCyf3MQEYYtJXLi3 nq2LkYtDSGAyk8T5Ey+gnNVMEp8W32fsYuTgYBbQk7h/UQukgRfIvNV8nxnEFhYwk/hwvwNs KJuAqsSDOccYQWxOAQ2Jpe9ms4DYLEDxp193soLYzAKxEntfrWSGsLUlnry7wAox00ai7/g/ NhBbSMBdYtfX5WAzRQS0JC5d64M6WlZi9/PvzBMYBWYhXDQLyUWzkExdwMi8ilGgKDUnsdJM L7GgICdVLzk/dxMjOOwKo3YwNiy3OsQowMGoxAO0vC9IiDWxrLgy9xCjBAezkgjvV3WgEG9K YmVValF+fFFpTmrxIUZpDhYlcd5dvkApgfTEktTs1NSC1CKYLBMHp1QDo/T/Ro0VDUahXg1q 38IaWWv9v78tc9zKOCn9+s1Niy/7rmXo3urzmn1XcPW3ic0XDlifnVa8qMh6S7jZ2295JpGq pYd3vSkye8xToultbRfuVqX2/+gGld37dvwsTNVYqbn0/4917OqfpG5zTtjIMPF55Kycf5/a uwUj85ZkRYkULLiz2eCUkRJLcUaioRZzUXEiAHh1V+U3AgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:25:00 -0000

On Nov 21, 2013, at 10:26 , Peter Saint-Andre  =
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On 11/21/13 9:51 AM, Magnus Westerlund wrote:
>=20
>> The method we propose is based on Instant-runoff voting,=20
>> http://en.wikipedia.org/wiki/Instant-runoff_voting, with the=20
>> understanding that the choice will be the winner according to the=20
>> Instant-runoff voting process.
>=20
> I have the greatest respect for the chairs, but this is an engraved
> invitation for people to appeal whatever decision might be reached.
>=20
> More fundamentally: Voting? At the IETF?? Really?!?
>=20
> I sincerely hope we can figure out a better process=85
>=20

Me too.

For example, the W3C uses a Call for Objections process, where the =
option with the weakest technical objection is selected.  I fear that =
voting will result in a decision that won=92t be honored by a =
significant part of the population.  We don=92t need just a mandate, we =
want the effect of an effective mandate.


David Singer
Multimedia and Software Standards, Apple Inc.


From cowwoc@bbs.darktech.org  Thu Nov 21 11:26:04 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314521AE1C4 for ; Thu, 21 Nov 2013 11:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fljTvGnwfEng for ; Thu, 21 Nov 2013 11:26:02 -0800 (PST)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29A561AE05D for ; Thu, 21 Nov 2013 11:26:02 -0800 (PST)
Received: by mail-pa0-f44.google.com with SMTP id fa1so191143pad.31 for ; Thu, 21 Nov 2013 11:25:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6OslFPMdY7oYpVQH99ZKJlZ0tytzgeGpUb0LUWlCnfU=; b=eUOjrnxEI5nqJOUinC0ifW+0ZuwSu4uW+/UuLIfXa3WTTZsM1/NxsquHwfZPKyDCFN B8IKOjtFtKlEszBczhLOJ+YtYQDa/NCN8ztP2QG4/iKGq0BPqsyMU/vH6qXDepCjZP4W ltDMI4hyGr/H0u/ER2vYJhxVy8HtnzctkG3xLEfR1Y4XG144YYoWYK/G1MSrToNn2LcY GZCp+3XXXm/7ZykOD3v7odrl8yiGAaV+DXbESk8ZyIOKnLX2jdlNv1U4bWPfpzvGoV82 /LtEYwI35JmPQ3k3jbGhDVdhgHeGGIOQzZb6zTPcFHMQyZVFmae1f3VxIbKvB6orJfe0 e/yQ==
X-Gm-Message-State: ALoCoQkABBPIZHPUto/hjBZ7VcrVbrLR56GLL47ZPt8ebPeNLT5yCDF0OrydN7/hynW/83daL1yK
X-Received: by 10.68.35.39 with SMTP id e7mr7958895pbj.140.1385061955456; Thu, 21 Nov 2013 11:25:55 -0800 (PST)
Received: from [10.35.1.155] (sccc-66-78-236-243.smartcity.com. [66.78.236.243]) by mx.google.com with ESMTPSA id qf7sm54010616pac.14.2013.11.21.11.25.53 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 11:25:54 -0800 (PST)
Message-ID: <528E5E3C.70008@bbs.darktech.org>
Date: Thu, 21 Nov 2013 11:25:48 -0800
From: Gili 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528D6C63.7050607@bbs.darktech.org>, <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr> <5A2BC34D-FE4D-4420-B52F-729087815F37@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:26:04 -0000

Cullen,

Thanks for the background information. I also remember them saying that 
we are only at the beginning of this process and that they expect more 
performance improvements in the upcoming months.

It would be nice to gauge how far we are from being able to do this kind 
of conversion in real-time on a mobile device (I suspect very far, but 
it's worth asking). This has implications for P2P interoperability 
between VP8 and H.264 peers without a middleman.

Gili

On 21/11/2013 10:46 AM, Cullen Jennings wrote:
> It's a cool demo and I talked to the team that did it. This is only possible because VP8 and H.264 are very similar codecs. The idea is to not redo the motion vector computations or the DCT but just reuse the values from one format in the other since they are the same. They hope that this can provide reduce the CPU by 1/3 from a full decode then re-encode. It also help reduce loss of quality for video. Other people have talked about this idea over the years and many people think it can give a 2 to 3 speed up so that seems consistent with their goals.
>
> It still requires the same bandwidth, and has similar other impacts. I can not see any way that it would not require MPEG-LA IPR for 264.
>
>
> On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty)  wrote:
>
>> This probably refers to an intelligent transcoder versus a brute force transcoder. An intelligent transcoder harvests more data during decoding than just the raw output pixels, and uses this extra data to ease encoding. Data like block partitions, motion vectors, intra modes, quantization parameters, etc.
>>
>> This is common for common conversions, like MPEG2 to H.264. VP8 and H.264 are much closer formats, so this can significantly improve transcoder performance.
>>
>> However, this is strictly a performance optimization, with no impact on IPR or licensing issues.
>>
>> Mo
>>
>>
>> On Nov 21, 2013, at 2:51 AM, "Bossiel"  wrote:
>>
>> This could be true if they can also walk on water and change it into wine.
>> To be serious, no it's not possible.
>> Mamadou
>>
>> Sent from my iPhone
>>
>> On Nov 21, 2013, at 3:13, Gili  wrote:
>>
>>> Hi,
>>>
>>> I'm at the WebRTC World conference. If I understood correctly, Zingaya just demoed what they claim is a VP8 to H.264 bridge that converts the video without transcoding. My interpretation is that they convert the surrounding packet format without re-encoding the actual video. Someone who understands codec internals (I don't) might want to validate this claim, because it could have a significant impact on the MTI debate.
>>>
>>> It sounds far fetched, but imagine the possibilities:
>>> 	• If the video is not being re-encoded, do H.264 royalties apply?
>>> 	• If the conversion is really cheap, is it feasible to connect a H.264 peer to a VP8 peer and have one of them convert in-line (no MCU)?
>>> Gili
>>> _______________________________________________
>>> 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


From fluffy@iii.ca  Thu Nov 21 11:27:16 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC9B1AE241 for ; Thu, 21 Nov 2013 11:27:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdhpwRh1GCAz for ; Thu, 21 Nov 2013 11:27:14 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3501AE1C4 for ; Thu, 21 Nov 2013 11:27:14 -0800 (PST)
Received: from sjc-vpn3-1087.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6F82622E1FA; Thu, 21 Nov 2013 14:27:01 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>
Date: Thu, 21 Nov 2013 11:27:37 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>
To: David Singer 
X-Mailer: Apple Mail (2.1510)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:27:16 -0000

Added a=20

#11 	=95 MUST implement at least two of {VP8, H.264 CBP, H.263}


On Nov 21, 2013, at 11:20 AM, David Singer  wrote:

> Chairs
>=20
> can we add this as an option to the formal list, so we get formal =
feedback on its acceptability, please?
>=20
> =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
>=20
>=20
> I think this may be the best (maybe only) way to tease out how much =
risk people perceive.
>=20
> Many thanks
>=20
> On Nov 21, 2013, at 9:22 , Maik Merten  =
wrote:
>=20
>> Cleary H.263 is preferable from an engineering standpoint (as is, =
e.g., MPEG-1 Part 2): better performance, more deployments. The central =
question is, however, if those can actually be implemented without some =
sort of licensing.
>>=20
>> If they can: Aweseome! However, this may not be determinable without =
a review by people who are knowledgeable in the field of IPR, i.e., =
"actual lawyers". I understand that H.263 is not yet old enough to =
automatically be considered "safe" (and neither is MPEG-1 Part 2, =
although it is closer).
>>=20
>> Best regards,
>>=20
>> Maik
>>=20
>> Am 20.11.2013 20:42, schrieb David Singer:
>>> I think we should think hard about H.263 instead of H.261 as the =
third fallback.  Why?
>>>=20
>>> http://www.itu.int/rec/T-REC-H.263/
>>>=20
>>>=20
>>>=20
>>> H.263 was first published in March 1996, so it's 17 years old.  The =
restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more =
recent amendments deal with this (and a plethora of other issues), so =
we=92d need to settle on which of those are mandatory (the usual =
profiling discussion).
>>>=20
>>> There are 34 records in the patent database against H.261, mostly =
from 1989 but one as recent as 2005 (though that is a re-file).  That's =
2.2 (reciprocity), as was one other I checked.
>>>=20
>>> Rather surprisingly, there are only 31 against H.263!  The most =
recent is 2011, and is also option 2.  Most are 1997-2001.
>>>=20
>>>=20
>>> On this quick glance, H.263 appears no worse than H.261. IANAL (as I =
am sure you have all noticed).
>>>=20
>>>=20
>>> H.263 is much more widely supported and mandated.  It has been =
mandated in the 3GPP specs for years (for lots of services, including =
videoconf), and is effectively the fallback codec today in the industry, =
as I understand.  It was ubiquitous in video telephony for years, and I =
suspect many of those systems still ship it.
>>>=20
>>> So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 =
work?
>>>=20
>>> (I am asking the question, not even answering on behalf of my =
company, yet.  Let=92s get the issues on the table.)
>>>=20
>>>=20
>>> David Singer
>>> Multimedia and Software Standards, Apple Inc.
>>>=20
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>=20
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> David Singer
> Multimedia and Software Standards, Apple Inc.
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From maikmerten@googlemail.com  Thu Nov 21 11:27:17 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61261AE1C4 for ; Thu, 21 Nov 2013 11:27:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp5_I_RiBjqE for ; Thu, 21 Nov 2013 11:27:15 -0800 (PST)
Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7147C1AE207 for ; Thu, 21 Nov 2013 11:27:15 -0800 (PST)
Received: by mail-ea0-f177.google.com with SMTP id n15so77717ead.22 for ; Thu, 21 Nov 2013 11:27:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=CEBXLjNqWHr2DkbSrI54+i4KHFmYReVkmidbhsZgUcQ=; b=ZkUqK6mGbXP2iHH1epaew/GCwB4ciFXmEdMe8DrE1QZW5CsDyHgRYvbn5g+26rOZFv 5d7zVcDPNuhCmW9Z5/mHkz4ZrWsu7uxEMjwZGRlNzH+MUPLRzZuaiwZFWl3ejpRRQnB/ N7iS49MPORbEsFFNNAj9XkfcAIp3RLjO8GieJbp7RQFwWuOf6tF6lCIK9C7WuiViBjvY 66bg0dU4CH0mX0N0E8M6YDbKh07ylgbcRXxWqOQnc0uf4zLzK0aqMU7UGPJvZE5rvQ3o 0kLq7jucZynj9NTyYaogvtiTqJSFwAcWEnyiL0ZNBgxfNW2sc9IQFPI7GKBc62E0DqEI bMhQ==
X-Received: by 10.14.109.1 with SMTP id r1mr10816704eeg.32.1385062028206; Thu, 21 Nov 2013 11:27:08 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id o47sm73213399eem.21.2013.11.21.11.27.06 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 11:27:07 -0800 (PST)
Message-ID: <528E5E89.8040706@googlemail.com>
Date: Thu, 21 Nov 2013 20:27:05 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>
In-Reply-To: <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:27:18 -0000

Btw, should any occurrence of "H.264" in the current list of options be 
substituted with "H.264 CBP"? Perhaps it is best to be very clear on the 
profile which should be implemented.

Thanks,

Maik

Am 21.11.2013 20:20, schrieb David Singer:
> Chairs
>
> can we add this as an option to the formal list, so we get formal feedback on its acceptability, please?
>
> “Like option ??, pick at least two of {VP8, H.264 CBP, H.263}”
>
>
> I think this may be the best (maybe only) way to tease out how much risk people perceive.
>
> Many thanks
>
> On Nov 21, 2013, at 9:22 , Maik Merten  wrote:
>
>> Cleary H.263 is preferable from an engineering standpoint (as is, e.g., MPEG-1 Part 2): better performance, more deployments. The central question is, however, if those can actually be implemented without some sort of licensing.
>>
>> If they can: Aweseome! However, this may not be determinable without a review by people who are knowledgeable in the field of IPR, i.e., "actual lawyers". I understand that H.263 is not yet old enough to automatically be considered "safe" (and neither is MPEG-1 Part 2, although it is closer).
>>
>> Best regards,
>>
>> Maik
>>
>> Am 20.11.2013 20:42, schrieb David Singer:
>>> I think we should think hard about H.263 instead of H.261 as the third fallback.  Why?
>>>
>>> http://www.itu.int/rec/T-REC-H.263/
>>>
>>>
>>>
>>> H.263 was first published in March 1996, so it's 17 years old.  The restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more recent amendments deal with this (and a plethora of other issues), so we’d need to settle on which of those are mandatory (the usual profiling discussion).
>>>
>>> There are 34 records in the patent database against H.261, mostly from 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2 (reciprocity), as was one other I checked.
>>>
>>> Rather surprisingly, there are only 31 against H.263!  The most recent is 2011, and is also option 2.  Most are 1997-2001.
>>>
>>>
>>> On this quick glance, H.263 appears no worse than H.261. IANAL (as I am sure you have all noticed).
>>>
>>>
>>> H.263 is much more widely supported and mandated.  It has been mandated in the 3GPP specs for years (for lots of services, including videoconf), and is effectively the fallback codec today in the industry, as I understand.  It was ubiquitous in video telephony for years, and I suspect many of those systems still ship it.
>>>
>>> So, would “MUST implement at least two of (H.264, VP8, H.263)” work?
>>>
>>> (I am asking the question, not even answering on behalf of my company, yet.  Let’s get the issues on the table.)
>>>
>>>
>>> David Singer
>>> Multimedia and Software Standards, Apple Inc.
>>>
>>> _______________________________________________
>>> 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
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From fluffy@iii.ca  Thu Nov 21 11:29:50 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E32D1AE0E5 for ; Thu, 21 Nov 2013 11:29:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZel79tb8DWn for ; Thu, 21 Nov 2013 11:29:47 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id C18991AE0B3 for ; Thu, 21 Nov 2013 11:29:47 -0800 (PST)
Received: from sjc-vpn3-1087.cisco.com (unknown [128.107.239.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9668250A86; Thu, 21 Nov 2013 14:29:40 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: <528E5E3C.70008@bbs.darktech.org>
Date: Thu, 21 Nov 2013 11:30:15 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <528D6C63.7050607@bbs.darktech.org>, <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr> <5A2BC34D-FE4D-4420-B52F-729087815F37@cisco.com>  <528E5E3C.70008@bbs.darktech.org>
To: Gili 
X-Mailer: Apple Mail (2.1510)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:29:50 -0000

On Nov 21, 2013, at 11:25 AM, Gili  wrote:

> I also remember them saying that we are only at the beginning of this =
process and that they expect more performance improvements in the =
upcoming months.

Yes, they were very clear it just a early snap shot of what might be =
possible (right now it is only one direction for example). Their end =
goal (not where they are now) is the 1/3 CPU usage.=20


From maikmerten@googlemail.com  Thu Nov 21 11:32:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638EA1AE204 for ; Thu, 21 Nov 2013 11:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wELm40tdeLSN for ; Thu, 21 Nov 2013 11:32:37 -0800 (PST)
Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 980EC1AE269 for ; Thu, 21 Nov 2013 11:32:33 -0800 (PST)
Received: by mail-ea0-f169.google.com with SMTP id l9so85315eaj.28 for ; Thu, 21 Nov 2013 11:32:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GYIL+ZUQlwY5rfSKiA3+bexMzhR8vwpjGbX0pv0heew=; b=Uw7yHYr6Cu5WMdtJS4yAPd9+nq+kyIcdgqc3uAVIuSi/BzBKINIxPIHTnDbFaxTUqo q+FTEzLwZPOj6qsAOs7OmSFajuxqi0aPR6UUKCHVyGtbP1CdsZmayp+zRmEeMZSvj+6S vqIHW3JZLSfzkItPW3cvVImE0H9LfN5SwlOd14ulWUuzOBlySwqmPELUfA3wc+aNnstK eYoCxbXi9xYkaxUjOPDfZGkQgP27YXFE9PT5yAIO21XXYmXGoweLFAu8ftcbkNPRGudX IGczBuD0VNEdLSNQSdGQbBLxjhehaD2G0w05iK0fzgI0QZHLxxjGQJN1kadF88jhVuQc 9H5A==
X-Received: by 10.14.105.200 with SMTP id k48mr10694051eeg.1.1385062346415; Thu, 21 Nov 2013 11:32:26 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id j46sm73156372eew.18.2013.11.21.11.32.24 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 11:32:25 -0800 (PST)
Message-ID: <528E5FC6.6030208@googlemail.com>
Date: Thu, 21 Nov 2013 20:32:22 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:32:39 -0000

I wonder if it #10 should be rephrased into a nice and clear

MUST implement at least two of {VP8, H.264 CBP, H.261}

to highlight the structural similarity.


Maik


Am 21.11.2013 20:27, schrieb Cullen Jennings:
>
> Added a
>
> #11 	• MUST implement at least two of {VP8, H.264 CBP, H.263}
>
>
> On Nov 21, 2013, at 11:20 AM, David Singer  wrote:
>
>> Chairs
>>
>> can we add this as an option to the formal list, so we get formal feedback on its acceptability, please?
>>
>> “Like option ??, pick at least two of {VP8, H.264 CBP, H.263}”
>>
>>
>> I think this may be the best (maybe only) way to tease out how much risk people perceive.
>>
>> Many thanks
>>
>> On Nov 21, 2013, at 9:22 , Maik Merten  wrote:
>>
>>> Cleary H.263 is preferable from an engineering standpoint (as is, e.g., MPEG-1 Part 2): better performance, more deployments. The central question is, however, if those can actually be implemented without some sort of licensing.
>>>
>>> If they can: Aweseome! However, this may not be determinable without a review by people who are knowledgeable in the field of IPR, i.e., "actual lawyers". I understand that H.263 is not yet old enough to automatically be considered "safe" (and neither is MPEG-1 Part 2, although it is closer).
>>>
>>> Best regards,
>>>
>>> Maik
>>>
>>> Am 20.11.2013 20:42, schrieb David Singer:
>>>> I think we should think hard about H.263 instead of H.261 as the third fallback.  Why?
>>>>
>>>> http://www.itu.int/rec/T-REC-H.263/
>>>>
>>>>
>>>>
>>>> H.263 was first published in March 1996, so it's 17 years old.  The restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more recent amendments deal with this (and a plethora of other issues), so we’d need to settle on which of those are mandatory (the usual profiling discussion).
>>>>
>>>> There are 34 records in the patent database against H.261, mostly from 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2 (reciprocity), as was one other I checked.
>>>>
>>>> Rather surprisingly, there are only 31 against H.263!  The most recent is 2011, and is also option 2.  Most are 1997-2001.
>>>>
>>>>
>>>> On this quick glance, H.263 appears no worse than H.261. IANAL (as I am sure you have all noticed).
>>>>
>>>>
>>>> H.263 is much more widely supported and mandated.  It has been mandated in the 3GPP specs for years (for lots of services, including videoconf), and is effectively the fallback codec today in the industry, as I understand.  It was ubiquitous in video telephony for years, and I suspect many of those systems still ship it.
>>>>
>>>> So, would “MUST implement at least two of (H.264, VP8, H.263)” work?
>>>>
>>>> (I am asking the question, not even answering on behalf of my company, yet.  Let’s get the issues on the table.)
>>>>
>>>>
>>>> David Singer
>>>> Multimedia and Software Standards, Apple Inc.
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>
>> _______________________________________________
>> 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
>


From lgeyser@gmail.com  Thu Nov 21 11:33:07 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3CC1AE074 for ; Thu, 21 Nov 2013 11:33:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFthkveTsoMt for ; Thu, 21 Nov 2013 11:33:04 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9691AE19E for ; Thu, 21 Nov 2013 11:32:54 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id eh20so174660lab.4 for ; Thu, 21 Nov 2013 11:32:47 -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=JMtnvKR5kxjV/7ELQjKXo4r48JBZ0zfz4lnv5g6uFxI=; b=UTNqQfKy1641xM3lUsip/TAlxX/rOHgBSMrsKSH6eNt9tumvSg8v2Heid6eh54sUQZ wY0wdmGfdRJNN68vw1hB8yOyva+FmoS5cZG+wnDEK0WPJHLb4ofh1E9c0GErrvopPSQx yBsA0Ek9Z7CfrbrtCvptVH/HDn8XDKZ9abFXB6mgErv3U7yFSLq0iQicPQlgef5wo+fa 4+rDEdxjojC6u1I9JKDC4nn6pwHbZTPGlR1/ir9xblr4dukMKeRP4m3rk4CnynZxc8cH cISyyG+KRLJPcgrvOGmL54lE4SLNExHOE9VLPrdQRMd5yW+T3mHd7l6IDh3U+AvjMOI3 MsxQ==
MIME-Version: 1.0
X-Received: by 10.152.4.230 with SMTP id n6mr6085092lan.1.1385062367628; Thu, 21 Nov 2013 11:32:47 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 21 Nov 2013 11:32:47 -0800 (PST)
In-Reply-To: <528E5E89.8040706@googlemail.com>
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com> <528E5E89.8040706@googlemail.com>
Date: Thu, 21 Nov 2013 21:32:47 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e013d1e8e6a124304ebb4f66e
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:33:07 -0000

--089e013d1e8e6a124304ebb4f66e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

+1


On 21 November 2013 21:27, Maik Merten  wrote:

> Btw, should any occurrence of "H.264" in the current list of options be
> substituted with "H.264 CBP"? Perhaps it is best to be very clear on the
> profile which should be implemented.
>
> Thanks,
>
> Maik
>
> Am 21.11.2013 20:20, schrieb David Singer:
>
>  Chairs
>>
>> can we add this as an option to the formal list, so we get formal
>> feedback on its acceptability, please?
>>
>> =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
>>
>>
>> I think this may be the best (maybe only) way to tease out how much risk
>> people perceive.
>>
>> Many thanks
>>
>> On Nov 21, 2013, at 9:22 , Maik Merten  wrote=
:
>>
>>  Cleary H.263 is preferable from an engineering standpoint (as is, e.g.,
>>> MPEG-1 Part 2): better performance, more deployments. The central quest=
ion
>>> is, however, if those can actually be implemented without some sort of
>>> licensing.
>>>
>>> If they can: Aweseome! However, this may not be determinable without a
>>> review by people who are knowledgeable in the field of IPR, i.e., "actu=
al
>>> lawyers". I understand that H.263 is not yet old enough to automaticall=
y be
>>> considered "safe" (and neither is MPEG-1 Part 2, although it is closer)=
.
>>>
>>> Best regards,
>>>
>>> Maik
>>>
>>> Am 20.11.2013 20:42, schrieb David Singer:
>>>
>>>> I think we should think hard about H.263 instead of H.261 as the third
>>>> fallback.  Why?
>>>>
>>>> http://www.itu.int/rec/T-REC-H.263/
>>>>
>>>>
>>>>
>>>> H.263 was first published in March 1996, so it's 17 years old.  The
>>>> restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, mor=
e
>>>> recent amendments deal with this (and a plethora of other issues), so =
we=92d
>>>> need to settle on which of those are mandatory (the usual profiling
>>>> discussion).
>>>>
>>>> There are 34 records in the patent database against H.261, mostly from
>>>> 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2
>>>> (reciprocity), as was one other I checked.
>>>>
>>>> Rather surprisingly, there are only 31 against H.263!  The most recent
>>>> is 2011, and is also option 2.  Most are 1997-2001.
>>>>
>>>>
>>>> On this quick glance, H.263 appears no worse than H.261. IANAL (as I a=
m
>>>> sure you have all noticed).
>>>>
>>>>
>>>> H.263 is much more widely supported and mandated.  It has been mandate=
d
>>>> in the 3GPP specs for years (for lots of services, including videoconf=
),
>>>> and is effectively the fallback codec today in the industry, as I
>>>> understand.  It was ubiquitous in video telephony for years, and I sus=
pect
>>>> many of those systems still ship it.
>>>>
>>>> So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 wor=
k?
>>>>
>>>> (I am asking the question, not even answering on behalf of my company,
>>>> yet.  Let=92s get the issues on the table.)
>>>>
>>>>
>>>> David Singer
>>>> Multimedia and Software Standards, Apple Inc.
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>
>> _______________________________________________
>> 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
>

--089e013d1e8e6a124304ebb4f66e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


    +1


    On 21 November 2013 21:27, Maik Merten <maikmerten@googl=
email.com> wrote:
    

    Btw, should any occurrence of "H.264&qu=
ot; in the current list of options be substituted with "H.264 CBP"=
;? Perhaps it is best to be very clear on the profile which should be imple=
mented.
    


    
Thanks,
    

    
Maik
    

    
Am 21.11.2013 20:20, schrieb David Singer:

    

    
Chairs
    

    
can we add this as an option to the formal list, so we get formal feedback =
on its acceptability, please?
    

    
=93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
    

    

    
I think this may be the best (maybe only) way to tease out how much risk pe=
ople perceive.
    

    
Many thanks
    

    
On Nov 21, 2013, at 9:22 , Maik Merten <maikmerten@googlemail.com> wrote:
    

    

    
Cleary H.263 is preferable from an engineering standpoint (as is, e.g., MPE=
G-1 Part 2): better performance, more deployments. The central question is,=
 however, if those can actually be implemented without some sort of licensi=
ng.
    


    
If they can: Aweseome! However, this may not be determinable without a revi=
ew by people who are knowledgeable in the field of IPR, i.e., "actual =
lawyers". I understand that H.263 is not yet old enough to automatical=
ly be considered "safe" (and neither is MPEG-1 Part 2, although i=
t is closer).
    


    
Best regards,
    

    
Maik
    

    
Am 20.11.2013 20:42, schrieb David Singer:
    

    
I think we should think hard about H.263 instead of H.261 as the third fall=
back. =A0Why?
    

    
http://ww=
w.itu.int/rec/T-REC-H.263/
    

    

    

    
H.263 was first published in March 1996, so it's 17 years old. =A0The r=
estrictions (e.g. on picture size) are no WORSE than H.261. =A0Yes, more re=
cent amendments deal with this (and a plethora of other issues), so we=92d =
need to settle on which of those are mandatory (the usual profiling discuss=
ion).
    


    
There are 34 records in the patent database against H.261, mostly from 1989=
 but one as recent as 2005 (though that is a re-file). =A0That's 2.2 (r=
eciprocity), as was one other I checked.
    

    
Rather surprisingly, there are only 31 against H.263! =A0The most recent is=
 2011, and is also option 2. =A0Most are 1997-2001.
    

    

    
On this quick glance, H.263 appears no worse than H.261. IANAL (as I am sur=
e you have all noticed).
    

    

    
H.263 is much more widely supported and mandated. =A0It has been mandated i=
n the 3GPP specs for years (for lots of services, including videoconf), and=
 is effectively the fallback codec today in the industry, as I understand. =
=A0It was ubiquitous in video telephony for years, and I suspect many of th=
ose systems still ship it.
    


    
So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 work?

    
(I am asking the question, not even answering on behalf of my company, yet.=
 =A0Let=92s get the issues on the table.)
    

    

    
David Singer
    
Multimedia and Software Standards, Apple Inc.
    

    
_______________________________________________
    
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
    

    

    
David Singer
    
Multimedia and Software Standards, Apple Inc.
    

    
_______________________________________________
    
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
    


    

--089e013d1e8e6a124304ebb4f66e--

From juberti@google.com  Thu Nov 21 11:33:51 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA541AE0F1 for ; Thu, 21 Nov 2013 11:33:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI1Ykj1q7iNi for ; Thu, 21 Nov 2013 11:33:49 -0800 (PST)
Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A76E71AE121 for ; Thu, 21 Nov 2013 11:33:49 -0800 (PST)
Received: by mail-vb0-f47.google.com with SMTP id x11so155499vbb.20 for ; Thu, 21 Nov 2013 11:33:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v/nNscrCTtIlDnLVKk6hfNp8FWE2NB6pgZHDL7QKB4I=; b=Aj7h0AlbD7tOk3l5zMfbGWFp/XXp6uSiB/zCb1l3okY/36uc3QMdpZ8FWQpZn+c++h zKcdFDKAB5Nf49WF1GFy7B0i3lU6+qQaCOPJZ1REeh/E8FtwQTWB/lnfeKaTgObZliLq gZ/8r3+Xnk3DxnXcVhaiASWHr9vjkR9sjnmPppXr2igSL/OR4n2lEZcDanM7nwkczPR/ EPGDCax32ABU58hwvrSjjRu8n/RZUQ6DnMnP7WiQHQhLFllY96Il9BHxsaRj8lUCtWfi NxoXepPmoyfMgXOzQrt1JC4q9nRdh4i0yuIMK/PuGQUXq5FF2zc302KtqU+uvGw2maA1 ewig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=v/nNscrCTtIlDnLVKk6hfNp8FWE2NB6pgZHDL7QKB4I=; b=MOsgy0d3gV5imjBy2FFYhr0hYT6X6rqYdi4RczGx823F4AEAcAcMSZtd9nl0uZKBB9 h1D6hxEfkBPs/X4mC/crt0PHcT+7MV89z85o5/ajzABooNYXUiorWAL99agsLYW8dTA/ SymwfvVnZyfuIJ1qkAg2IRY4n5seRfVWlbb+wqTLMYtexjGt3uhLJij+e2Wi2lfb3ucY kLfzDWAY3sARi/xSzkfSWeC5TclXNnomZed7U5lH9onQJ2UWeKKPPfhAmeb9lXsD19FB HMtUiD9ZMu5QHv3OTdfh7dLzXAJI3DbD+eMrO343yJNaCQCJIJ9kFZg6Y/2W/t1gBykH VZHw==
X-Gm-Message-State: ALoCoQkDTbrbYapdMF0yfFePb/UVZUC/D5ITKcqJAbqn/KWprkANoqNxMvfSWjQna4QcABiepyMw9u5Qc6UlpDzmEyppWp/89rUG7L6Kv78i6VgouDWWsHDnwMBY3exoboE9I2eJAq+LK+jzhAaB4GtWONDcwuS6fGaGxYkHgFk3RP8LobcyKbt6DYBMPNUDNKDjszY0E9cD
X-Received: by 10.52.37.69 with SMTP id w5mr2406731vdj.32.1385062422718; Thu, 21 Nov 2013 11:33:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Thu, 21 Nov 2013 11:33:22 -0800 (PST)
In-Reply-To: <528E5B47.70702@nostrum.com>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com>
From: Justin Uberti 
Date: Thu, 21 Nov 2013 11:33:22 -0800
Message-ID: 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=20cf30780db0b2bbc304ebb4f992
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:33:51 -0000

--20cf30780db0b2bbc304ebb4f992
Content-Type: text/plain; charset=UTF-8

My primary objection was to the tourist phenomenon you point out; if we are
going to allow lurkers to vote, we should do so regardless of whether their
presence is physical or virtual.

On Thu, Nov 21, 2013 at 11:13 AM, Adam Roach  wrote:

> On 11/21/13 10:56, Justin Uberti wrote:
>
>> Following an IETF meeting on Jabber doesn't count as participating?
>>
>> The "big guy vs little guy" narrative continues...
>>
>
> I think that's a bit specious. If someone is following the issue at such a
> distance that they haven't expressed an opinion on the mailing list, I
> can't see how taking a vote from them counts as anything other than simple,
> old-fashioned ballot stuffing.
>
> I'll take it one step further. I find the prospect that we're allowing
> blue sheets to stand in for participation to be highly questionable:
> letting the tourists vote is weighting the opinion of demonstrably
> uninvolved (or less-involved) parties at the same level as those who have
> actually been working on the topic. I do not think that a blue-sheet sign
> in without any on-list participation should be sufficient to participate in
> the kind of process the chairs are proposing.
>
> Or perhaps I'm missing something. Is there something about the
> capabilities of "the little guy" that makes sending an email an
> unrealistically high barrier to entry?
>
> /a
>

--20cf30780db0b2bbc304ebb4f992
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    My primary objection was to the tourist phenomenon you poi=
nt out; if we are going to allow lurkers to vote, we should do so regardles=
s of whether their presence is physical or virtual.=C2=A0
    


    
On Thu, Nov 21, 2013 at 11:13 AM, Adam Roach <adam@nostrum.com> wrote:
    



    On 11/21/13 10:56, Justin Uberti wrote:
    

    
Following an IETF meeting on Jabber doesn't count as participating?
    

    
The "big guy vs little guy" narrative continues...
    

    

    
I think that's a bit specious. If someone is following the issue at suc=
h a distance that they haven't expressed an opinion on the mailing list=
, I can't see how taking a vote from them counts as anything other than=
 simple, old-fashioned ballot stuffing.
    




    
I'll take it one step further. I find the prospect that we're allow=
ing blue sheets to stand in for participation to be highly questionable: le=
tting the tourists vote is weighting the opinion of demonstrably uninvolved=
 (or less-involved) parties at the same level as those who have actually be=
en working on the topic. I do not think that a blue-sheet sign in without a=
ny on-list participation should be sufficient to participate in the kind of=
 process the chairs are proposing.
    




    
Or perhaps I'm missing something. Is there something about the capabili=
ties of "the little guy" that makes sending an email an unrealist=
ically high barrier to entry?
    


    
/a
    


    

--20cf30780db0b2bbc304ebb4f992--

From basilgohar@librevideo.org  Thu Nov 21 11:38:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AA01AE21A for ; Thu, 21 Nov 2013 11:38:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level: 
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lgBEXplTnDz for ; Thu, 21 Nov 2013 11:37:59 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1C87D1AE092 for ; Thu, 21 Nov 2013 11:37:59 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 27E706595F4 for ; Thu, 21 Nov 2013 14:37:52 -0500 (EST)
Message-ID: <528E610D.70800@librevideo.org>
Date: Thu, 21 Nov 2013 14:37:49 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com> <528E5AF7.5080403@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video Selection Process)
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:38:00 -0000

On 11/21/2013 02:19 PM, Eric Rescorla wrote:
> In order to forestall the inevitable voting nerd thread, allow me to
> point to:
> 
> http://en.wikipedia.org/wiki/Arrow%27s_theorem
> 
> -Ekr

It's only the second time it's been brought up regarding MTI codecs! :)

-- 
Libre Video
http://librevideo.org

From silviapfeiffer1@gmail.com  Thu Nov 21 11:38:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD931AE283 for ; Thu, 21 Nov 2013 11:38:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aWIhR856W7U for ; Thu, 21 Nov 2013 11:38:22 -0800 (PST)
Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id DE9221AE131 for ; Thu, 21 Nov 2013 11:38:21 -0800 (PST)
Received: by mail-ob0-f176.google.com with SMTP id va2so243685obc.7 for ; Thu, 21 Nov 2013 11:38:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WAKeTMaRpYAMDmjCtkUIT4g4JHf3QEdXJVJRAH4KC58=; b=biVJPkNeXCw3oyNNdfJmYjTCF41zIPTOuJCpmV096rCr8VV/+kSyWclURDS/i4IvUO o/4CYbc7RP1ERpY/GjDDwp5Feng1rVdBlA0oPkNaI82/z1G4gQvdFn5H3ZSlr7J2L6Ga yuytiuBgMmewJypYsu3JsLeaQygr+D142k9qJoubYFbXBBMehiD2NOKjn6nwcvgbFLkq B6SZk1Nrul5B6MxmE5oyRmreuNn5w4sQSekhkbGPU5wJFSaJX02lp+PDB3bPaGToiRbo KRSwEn/gzI3UqDxBR76lkoSpVv2royVJZZvDqIrPsk3P+tXBpT24bjQ4yaXBiRQZZ2Fd w/Zg==
X-Received: by 10.182.246.39 with SMTP id xt7mr7006172obc.16.1385062695067; Thu, 21 Nov 2013 11:38:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.68.164 with HTTP; Thu, 21 Nov 2013 11:37:55 -0800 (PST)
In-Reply-To: <528E5B47.70702@nostrum.com>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com>
From: Silvia Pfeiffer 
Date: Thu, 21 Nov 2013 11:37:55 -0800
Message-ID: 
To: Adam Roach 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:38:24 -0000

On Thu, Nov 21, 2013 at 11:13 AM, Adam Roach  wrote:
> On 11/21/13 10:56, Justin Uberti wrote:
>>
>> Following an IETF meeting on Jabber doesn't count as participating?
>>
>> The "big guy vs little guy" narrative continues...
>
>
> I think that's a bit specious. If someone is following the issue at such a
> distance that they haven't expressed an opinion on the mailing list, I can't
> see how taking a vote from them counts as anything other than simple,
> old-fashioned ballot stuffing.

They might have just been active on the W3C webrtc list and watched
here to see what is happening with codecs, but haven't expressed their
position.


> I'll take it one step further. I find the prospect that we're allowing blue
> sheets to stand in for participation to be highly questionable: letting the
> tourists vote is weighting the opinion of demonstrably uninvolved (or
> less-involved) parties at the same level as those who have actually been
> working on the topic. I do not think that a blue-sheet sign in without any
> on-list participation should be sufficient to participate in the kind of
> process the chairs are proposing.

We could add that participation on the W3C webrtc list also qualifies.


> Or perhaps I'm missing something. Is there something about the capabilities
> of "the little guy" that makes sending an email an unrealistically high
> barrier to entry?

To address the little guys even more, we could also add that
participation on the discuss-webrtc list also qualifies.

Just my 2c worth.

Cheers,
Silvia.

From sslivinski@lifesize.com  Thu Nov 21 11:34:48 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223BB1AE0EC for ; Thu, 21 Nov 2013 11:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFhm9IxRFl8V for ; Thu, 21 Nov 2013 11:34:46 -0800 (PST)
Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with SMTP id E97721AE0F1 for ; Thu, 21 Nov 2013 11:34:45 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUo5gTkgEJcqxfRM1/SyemvjDcXIgA/Jm@postini.com; Thu, 21 Nov 2013 11:34:39 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 13:31:07 -0600
From: Stefan Slivinski 
To: "'rtcweb@ietf.org'" 
Date: Thu, 21 Nov 2013 13:31:05 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7m68Cf7/thuJ34R3Orj6krJlGcVgABHgHr
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7DA@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <528E57EC.6020000@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:41:38 -0000

I'm a new comer, so just a brief intro: I have a background developing real=
 time video codecs for embedded devices so I'm in a position to comment at =
a technical level within this group

For clarity purposes the proposed alternatives in Magnus' email on nov 18th=
; are we strictly speaking about decoders?  Historically mandatory requirem=
ents are they relate to video compatibility define just the decoders.  Obvi=
ously if there is only a single mandatory video decoder this implies a mand=
atory encoder, however in the case where there are 2 mandatory decoders onl=
y a single encoder is technically required.

Clarifying this is fairly important because in the case of both h264 and vp=
8 (and in the future vp9 and h265) the decoder complexity is fairly low and=
 hardware acceleration is not critical but in the case of the encoders wher=
e the complexity can be 3x or worse, hardware acceleration becomes increasi=
ngly important

Stefan


----- Original Message -----
From: Adam Roach [mailto:adam@nostrum.com]
Sent: Thursday, November 21, 2013 12:58 PM=0A=
To: Magnus Westerlund ; rtcweb@ietf.org 
Subject: Re: [rtcweb] Proposed Video Selection Process

On 11/21/13 08:51, Magnus Westerlund wrote:
> We (WG chairs) are proposing that the working group consent to a method
> that will establish an MTI, even if the MTI chosen does not have rough
> consensus.

Although this is phrased very carefully, I think this email=20
inadvertently glosses over the fact that this is a formal call for=20
consensus around the proposed approach. I also think you need to be=20
crystal clear -- and I'm going to borrow RFC 3929's language here --=20
"that the working group's consensus to use [this specific] method stands=20
in for the working group's consensus on the technical issue."

I wanted to point this out because it would be very easy to accidentally=20
read the email as an announcement for the way the codec will be=20
selected, rather than a call for consensus around a proposed approach.

/a
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

From peter.dunkley@crocodilertc.net  Thu Nov 21 11:46:55 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A211AE162 for ; Thu, 21 Nov 2013 11:46:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjcAO6UCn_2H for ; Thu, 21 Nov 2013 11:46:53 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 40F711AE04D for ; Thu, 21 Nov 2013 11:46:53 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id at1so405783iec.33 for ; Thu, 21 Nov 2013 11:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HaQErZBZWbv/sRLVsuaOahb8Sthpv0lHtOO9FxNZCt8=; b=AWA1OMjl1Ul4tqIxGF8ZjLSX2JcGQC5eWOVd7qSaj+v4/nLF1xyaJGrtUYzDTtInu3 spIoclyhSAo803JhzF8ilG9S8sNDN6NFhxFNAyDEYA5KqQIVFKAAlHrSKFEDD6dfpbbv UlmRt/6dkmUKCCqtHfaJhzAXJkrY0SkVDTV+4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HaQErZBZWbv/sRLVsuaOahb8Sthpv0lHtOO9FxNZCt8=; b=ibYyTYdL6wKk3slzbCIhkfeY3+/5hpa+gpezIdlrsGq+I3XvQ1Z26vIj95o6F/vgIx oEMbDbs63CrcpBjQt8BJ2fy544umtxSjL/wzar6pZ/hTZwzaVwhYQmwYuHHF1Xzv+SQN O0nh2el+VAmja3t3cmvHWqWizdbW+Mad1ZUh0Zar4lwVJlCJv7sP6O8/CqtcVRqFbVya CHbSqsITOJfTxXfHZb34uRC4pVfLCgRQLq6ZUed16sUwJrmGHab9nzGHBO9zMid7t8+a 5OrY6UVuuNYZiP3379LH5/W7npOgRImFKZPcS643uMFcOMjVmOznhI0/PpdWwaiTbMUA lVWg==
X-Gm-Message-State: ALoCoQmx0YEUAwfG/pS5cZ0YVT1VKECiZ1ifoTB11i64pMS6br3b8lI61tLM+2Knjvvinv2GhhD9
MIME-Version: 1.0
X-Received: by 10.50.114.168 with SMTP id jh8mr6820268igb.6.1385063206407; Thu, 21 Nov 2013 11:46:46 -0800 (PST)
Received: by 10.64.229.13 with HTTP; Thu, 21 Nov 2013 11:46:46 -0800 (PST)
In-Reply-To: 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> 
Date: Thu, 21 Nov 2013 11:46:46 -0800
Message-ID: 
From: Peter Dunkley 
To: Silvia Pfeiffer 
Content-Type: multipart/alternative; boundary=089e01229f8668e9d104ebb5281c
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:46:55 -0000

--089e01229f8668e9d104ebb5281c
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I am sure there are many people on the blue sheets who have never
participated on any of the mailing lists.  My point is that to be fair (and
as this is controversial it must be fair) if they get a vote because they
showed up in person those of us who showed up online should get a vote too.

I am based in the UK, so the late in the day meetings at Vancouver were at
incredibly anti-social times for me.  Still, it was important and I made
the effort to stay up and participate in the only way I could.

There is also a consistency issue here.  Those of us on Jabber were able to
(and encouraged to) participate in the consensus process, but it has been
proposed that we be excluded from the vote.  Really, you should either be
able to participate through Jabber or not in a consistent way.

Regards,

Peter



On 21 November 2013 11:37, Silvia Pfeiffer wrote:

> On Thu, Nov 21, 2013 at 11:13 AM, Adam Roach  wrote:
> > On 11/21/13 10:56, Justin Uberti wrote:
> >>
> >> Following an IETF meeting on Jabber doesn't count as participating?
> >>
> >> The "big guy vs little guy" narrative continues...
> >
> >
> > I think that's a bit specious. If someone is following the issue at such
> a
> > distance that they haven't expressed an opinion on the mailing list, I
> can't
> > see how taking a vote from them counts as anything other than simple,
> > old-fashioned ballot stuffing.
>
> They might have just been active on the W3C webrtc list and watched
> here to see what is happening with codecs, but haven't expressed their
> position.
>
>
> > I'll take it one step further. I find the prospect that we're allowing
> blue
> > sheets to stand in for participation to be highly questionable: letting
> the
> > tourists vote is weighting the opinion of demonstrably uninvolved (or
> > less-involved) parties at the same level as those who have actually been
> > working on the topic. I do not think that a blue-sheet sign in without
> any
> > on-list participation should be sufficient to participate in the kind of
> > process the chairs are proposing.
>
> We could add that participation on the W3C webrtc list also qualifies.
>
>
> > Or perhaps I'm missing something. Is there something about the
> capabilities
> > of "the little guy" that makes sending an email an unrealistically high
> > barrier to entry?
>
> To address the little guys even more, we could also add that
> participation on the discuss-webrtc list also qualifies.
>
> Just my 2c worth.
>
> Cheers,
> Silvia.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--089e01229f8668e9d104ebb5281c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    Hello,

    I am sure there are many people =
on the blue sheets who have never participated on any of the mailing lists.=
 =A0My point is that to be fair (and as this is controversial it must be fa=
ir) if they get a vote because they showed up in person those of us who sho=
wed up online should get a vote too.
    


    I am based in the UK, so the late in the day meetings a=
t Vancouver were at incredibly anti-social times for me. =A0Still, it was i=
mportant and I made the effort to stay up and participate in the only way I=
 could.
    


    There is also a consistency issue here. =A0Those of us =
on Jabber were able to (and encouraged to) participate in the consensus pro=
cess, but it has been proposed that we be excluded from the vote. =A0Really=
, you should either be able to participate through Jabber or not in a consi=
stent way.
    


    Regards,

    Peter

    <=
/div>


    On=
 21 November 2013 11:37, Silvia Pfeiffer <silviapfeiffer1@gmail.co=
m> wrote:
    

    On Thu, Nov 21, 2013 at 11=
:13 AM, Adam Roach <adam@nostrum.com=
> wrote:
    


    > On 11/21/13 10:56, Justin Uberti wrote:
    
>>
    
>> Following an IETF meeting on Jabber doesn't count as participa=
ting?
    
>>
    
>> The "big guy vs little guy" narrative continues...
    
>
    
>
    
> I think that's a bit specious. If someone is following the issue a=
t such a
    
> distance that they haven't expressed an opinion on the mailing lis=
t, I can't
    
> see how taking a vote from them counts as anything other than simple,<=
br>
> old-fashioned ballot stuffing.
    

    

    They might have just been active on the W3C webrtc list and watched
here to see what is happening with codecs, but haven't expressed their<=
br>
position.
    


    

    
> I'll take it one step further. I find the prospect that we're =
allowing blue
    
> sheets to stand in for participation to be highly questionable: lettin=
g the
    
> tourists vote is weighting the opinion of demonstrably uninvolved (or<=
br>
> less-involved) parties at the same level as those who have actually be=
en
    
> working on the topic. I do not think that a blue-sheet sign in without=
 any
    
> on-list participation should be sufficient to participate in the kind =
of
    
> process the chairs are proposing.
    

    

    We could add that participation on the W3C webrtc list also qualifies=
.
    


    

    
> Or perhaps I'm missing something. Is there something about the cap=
abilities
    
> of "the little guy" that makes sending an email an unrealist=
ically high
    
> barrier to entry?
    

    

    To address the little guys even more, we could also add that
    
participation on the discuss-webrtc list also qualifies.
    

    
Just my 2c worth.
    

    
Cheers,
    
Silvia.
    

    ___________________________________=
____________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    




    -- 
    =

    Peter Dunkley
    Technical Director
    

    Crocodile RCS Ltd
    

    

--089e01229f8668e9d104ebb5281c--

From bossiel@yahoo.fr  Thu Nov 21 11:49:59 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB4D1AE1BC for ; Thu, 21 Nov 2013 11:49:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjyDM1eSSbe0 for ; Thu, 21 Nov 2013 11:49:56 -0800 (PST)
Received: from nm3-vm6.bullet.mail.ir2.yahoo.com (nm3-vm6.bullet.mail.ir2.yahoo.com [212.82.96.95]) by ietfa.amsl.com (Postfix) with ESMTP id 8239C1AE162 for ; Thu, 21 Nov 2013 11:49:55 -0800 (PST)
Received: from [212.82.98.59] by nm3.bullet.mail.ir2.yahoo.com with NNFMP; 21 Nov 2013 19:49:48 -0000
Received: from [46.228.39.66] by tm12.bullet.mail.ir2.yahoo.com with NNFMP; 21 Nov 2013 19:49:47 -0000
Received: from [127.0.0.1] by smtp103.mail.ir2.yahoo.com with NNFMP; 21 Nov 2013 19:49:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1385063387; bh=Sybe3FT82cNFnZ2M0jNQt9HYt9xxwpE/37y/ofIUCNk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=Uej8Vp3Tz2IZ7uJtIzZMrKLYYhQS1zJirUHBlvYtBHr+HHEmAB2TvVhiHnbdM2MXwEM9AfIA3yWPbDKziwB5aVpcmP7skiEmkICyEtzbtx2ExtiW+N2XyqHG9PcsHcz1b9jZiQNHzi7FG9Z9jlcoeDTogDPTnLSPwD9QwAt+/fw=
X-Yahoo-Newman-Id: 951814.21109.bm@smtp103.mail.ir2.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 4XajX7kVM1mLJDtqWSVA05Bu3Jdx0IWKfl.Ua1eqpoA_OuJ Em0LA16Z4wpA.5Xq6WVE3KWWtDgFn9B_VX3SQojM6UiypBO25M.mIyH.Mh7S rKmpB2kvmKpsDfRI4AfuzMO2SBVltVsbkpqdbLhPCJWrlwiJmww0cd2h_kS_ bTpN2VrQnt4XIPXwKWVdmssBndKmSGFJ4QOPoa73X2vzWvCGxpQ4wJrtbbsS NBh714CW_cd9MJYdf5fp_Xbn2MK2loEiFR6LMBY3DHkjaqzO.1kd4SGLGstZ 9r9hkCPs3A7D7xI2dRzHXijpTAFEv5PATEbwTAM2sKLQN0jydMaqSOOdxSjY zlgXXNx2PIDob.WHb9OYQ3JzA583CBacg4R8zhbp6E.dVsr51kzm40ZTjwru FMWHFMu2iwp.c0sO8OjqMmayPebL.msg8iiEFCZjYznZtQ8hFJLNQF1tnkM3 h74zen1GbYtXJ1nv2ZaAeA_HhtHcKK83sNLEbWFckpucr2hMcTioH70vMCmb Om7U2uvUDwjY9G63dTz.PTtPw89A-
X-Yahoo-SMTP: Dix.ZgGswBADJg.if3NVG_xX0Xc-
X-Rocket-Received: from [192.168.0.26] (bossiel@88.179.39.5 with ) by smtp103.mail.ir2.yahoo.com with SMTP; 21 Nov 2013 19:49:47 +0000 UTC
References: <528D6C63.7050607@bbs.darktech.org> <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr> <5A2BC34D-FE4D-4420-B52F-729087815F37@cisco.com>  
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-0AD8B605-68FF-49CA-A3D2-B15FF665E414
Content-Transfer-Encoding: 7bit
Message-Id: <5ED0603D-B26D-4EDA-AAE5-7F45F9EDC3C3@yahoo.fr>
X-Mailer: iPhone Mail (10B350)
From: Bossiel 
Date: Thu, 21 Nov 2013 20:49:42 +0100
To: Mohammed Raad 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:49:59 -0000

--Apple-Mail-0AD8B605-68FF-49CA-A3D2-B15FF665E414
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Entropy decoding (CABAC/CAVLC) must be done to get the macroblock structure(=
partirions, motion vectors...) and residual (AC/DC coeffs). The only part yo=
u're skiping is the inverse transform, scaling and motion compensation. Also=
, the DPB mgt for reference pictures cannot be skiped.
This said, I don't see how this could save 1/3 CPU.

Sent from my iPhone

On Nov 21, 2013, at 20:00, Mohammed Raad  wrote:=


> Hi,
>=20
> Typically "smart" transcoding operates at 50 percent complexity or less. W=
e did a fair bit of this at Dilithium Networks when I was there. There are a=
lso significant memory and delay savings when one operates on the MB level i=
nstead of the picture level. With regards to IPR, there is a significant num=
ber of current patents in this area that are not in any multi organization p=
atent pool as far as I know. Transcoding in this way also provides quality a=
dvantages over tandem transcoding.
>=20
> Obviously the more similar the codecs the more one gains. In the case of V=
P8 and AVC CBP, there are significant enough differences in essential elemen=
ts such as the way quantization is done to make this kind of transcoding cha=
llenging, but it is possible and the numbers mentioned in the previous post s=
ound about right.
> Mohammed
>=20
> On 21 Nov 2013 20:45, "Cullen Jennings"  wrote:
>>=20
>> It's a cool demo and I talked to the team that did it. This is only possi=
ble because VP8 and H.264 are very similar codecs. The idea is to not redo t=
he motion vector computations or the DCT but just reuse the values from one f=
ormat in the other since they are the same. They hope that this can provide r=
educe the CPU by 1/3 from a full decode then re-encode. It also help reduce l=
oss of quality for video. Other people have talked about this idea over the y=
ears and many people think it can give a 2 to 3 speed up so that seems consi=
stent with their goals.
>>=20
>> It still requires the same bandwidth, and has similar other impacts. I ca=
n not see any way that it would not require MPEG-LA IPR for 264.
>>=20
>>=20
>> On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty)  wrot=
e:
>>=20
>> > This probably refers to an intelligent transcoder versus a brute force t=
ranscoder. An intelligent transcoder harvests more data during decoding than=
 just the raw output pixels, and uses this extra data to ease encoding. Data=
 like block partitions, motion vectors, intra modes, quantization parameters=
, etc.
>> >
>> > This is common for common conversions, like MPEG2 to H.264. VP8 and H.2=
64 are much closer formats, so this can significantly improve transcoder per=
formance.
>> >
>> > However, this is strictly a performance optimization, with no impact on=
 IPR or licensing issues.
>> >
>> > Mo
>> >
>> >
>> > On Nov 21, 2013, at 2:51 AM, "Bossiel"  wrote:
>> >
>> > This could be true if they can also walk on water and change it into wi=
ne.
>> > To be serious, no it's not possible.
>> > Mamadou
>> >
>> > Sent from my iPhone
>> >
>> > On Nov 21, 2013, at 3:13, Gili  wrote:
>> >
>> >> Hi,
>> >>
>> >> I'm at the WebRTC World conference. If I understood correctly, Zingaya=
 just demoed what they claim is a VP8 to H.264 bridge that converts the vide=
o without transcoding. My interpretation is that they convert the surroundin=
g packet format without re-encoding the actual video. Someone who understand=
s codec internals (I don't) might want to validate this claim, because it co=
uld have a significant impact on the MTI debate.
>> >>
>> >> It sounds far fetched, but imagine the possibilities:
>> >>      =E2=80=A2 If the video is not being re-encoded, do H.264 royaltie=
s apply?
>> >>      =E2=80=A2 If the conversion is really cheap, is it feasible to co=
nnect a H.264 peer to a VP8 peer and have one of them convert in-line (no MC=
U)?
>> >> Gili
>> >> _______________________________________________
>> >> 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
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb

--Apple-Mail-0AD8B605-68FF-49CA-A3D2-B15FF665E414
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Entropy decoding (CABAC/CAVLC) must be=
 done to get the macroblock structure(partirions, motion vectors...) and res=
idual (AC/DC coeffs). The only part you're skiping is the inverse transform,=
 scaling and motion compensation. Also, the DPB mgt for reference pictures c=
annot be skiped.
    This said, I don't see how this could save 1/3 CP=
U.

    Sent from my iPhone

    On Nov 21, 2013, at 20:00=
, Mohammed Raad <mohammedsr=
aad@raadtech.com> wrote:

    =

    Hi,
    

    Typically "smart" transcoding operates at 50 percent complexity or less. W=
e did a fair bit of this at Dilithium Networks when I was there. There are a=
lso significant memory and delay savings when one operates on the MB level i=
nstead of the picture level. With regards to IPR, there is a significant num=
ber of current patents in this area that are not in any multi organization p=
atent pool as far as I know. Transcoding in this way also provides quality a=
dvantages over tandem transcoding. 
    


    Obviously the more similar the codecs the more one gains. In the case of V=
P8 and AVC CBP, there are significant enough differences in essential elemen=
ts such as the way quantization is done to make this kind of transcoding cha=
llenging, but it is possible and the numbers mentioned in the previous post s=
ound about right.
    

    

    Mohammed
    

    On 21 Nov 2013 20:45, "Cullen Jennings" <fluffy@iii.ca> wrote:
    

    
It's a cool demo and I talked to the team that did it. This is only possible=
 because VP8 and H.264 are very similar codecs. The idea is to not redo the m=
otion vector computations or the DCT but just reuse the values from one form=
at in the other since they are the same. They hope that this can provide red=
uce the CPU by 1/3 from a full decode then re-encode. It also help reduce lo=
ss of quality for video. Other people have talked about this idea over the y=
ears and many people think it can give a 2 to 3 speed up so that seems consi=
stent with their goals.
    


    
It still requires the same bandwidth, and has similar other impacts. I can n=
ot see any way that it would not require MPEG-LA IPR for 264.
    

    

    
On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:
    

    
> This probably refers to an intelligent transcoder versus a brute force t=
ranscoder. An intelligent transcoder harvests more data during decoding than=
 just the raw output pixels, and uses this extra data to ease encoding. Data=
 like block partitions, motion vectors, intra modes, quantization parameters=
, etc.
    

>
    
> This is common for common conversions, like MPEG2 to H.264. VP8 and H.2=
64 are much closer formats, so this can significantly improve transcoder per=
formance.
    
>
    
> However, this is strictly a performance optimization, with no impact on=
 IPR or licensing issues.
    
>
    
> Mo
    
>
    
>
    
> On Nov 21, 2013, at 2:51 AM, "Bossiel" <bossiel@yahoo.fr> wrote:
    
>
    
> This could be true if they can also walk on water and change it into wi=
ne.
    
> To be serious, no it's not possible.
    
> Mamadou
    
>
    
> Sent from my iPhone
    
>
    
> On Nov 21, 2013, at 3:13, Gili <cowwoc@bbs.darktech.org> wrote:
    
>
    
>> Hi,
    
>>
    
>> I'm at the WebRTC World conference. If I understood correctly, Zing=
aya just demoed what they claim is a VP8 to H.264 bridge that converts the v=
ideo without transcoding. My interpretation is that they convert the surroun=
ding packet format without re-encoding the actual video. Someone who underst=
ands codec internals (I don't) might want to validate this claim, because it=
 could have a significant impact on the MTI debate.
    

>>
    
>> It sounds far fetched, but imagine the possibilities:
    
>>      =E2=80=A2 If the video is not being re-encoded,=
 do H.264 royalties apply?
    
>>      =E2=80=A2 If the conversion is really cheap, is=
 it feasible to connect a H.264 peer to a VP8 peer and have one of them conv=
ert in-line (no MCU)?
    
>> Gili
    
>> _______________________________________________
    
>> 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
    
h=
ttps://www.ietf.org/mailman/listinfo/rtcweb
    

    

    =

--Apple-Mail-0AD8B605-68FF-49CA-A3D2-B15FF665E414--

From basilgohar@librevideo.org  Thu Nov 21 11:56:42 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123511AE1BC for ; Thu, 21 Nov 2013 11:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level: 
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AQ0PyrZnSbq for ; Thu, 21 Nov 2013 11:56:41 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id E49BF1AE17E for ; Thu, 21 Nov 2013 11:56:40 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id E963B659765 for ; Thu, 21 Nov 2013 14:56:33 -0500 (EST)
Message-ID: <528E656F.2070404@librevideo.org>
Date: Thu, 21 Nov 2013 14:56:31 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DA@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA8AD7DA@ausmsex00.austin.kmvtechnologies.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 19:56:42 -0000

On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
> I'm a new comer, so just a brief intro: I have a background developing real time video codecs for embedded devices so I'm in a position to comment at a technical level within this group
> 
> For clarity purposes the proposed alternatives in Magnus' email on nov 18th; are we strictly speaking about decoders?  Historically mandatory requirements are they relate to video compatibility define just the decoders.  Obviously if there is only a single mandatory video decoder this implies a mandatory encoder, however in the case where there are 2 mandatory decoders only a single encoder is technically required.
> 
> Clarifying this is fairly important because in the case of both h264 and vp8 (and in the future vp9 and h265) the decoder complexity is fairly low and hardware acceleration is not critical but in the case of the encoders where the complexity can be 3x or worse, hardware acceleration becomes increasingly important
> 
> Stefan

What is being specified as MTI is a format, and not a specific
implementation.  So, MTI will not take the form of "OpenH264" or
"libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8".

The same was done for the MTI audio codec, which is Opus, not *libopus*,
which is one specific implementation of the codec.

There was a suggestion that the WG also offer a reference implementation
of the MTI codec choice, but that seems like it won't happen, nor is it
really the purpose of the WG to do so.  We are picking from
already-existing and implemented formats in the first place.

-- 
Libre Video
http://librevideo.org

From xiphmont@gmail.com  Thu Nov 21 12:01:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6DB1AE14B for ; Thu, 21 Nov 2013 12:01:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV1IId4NHrvh for ; Thu, 21 Nov 2013 12:00:59 -0800 (PST)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 180051AE2A3 for ; Thu, 21 Nov 2013 12:00:49 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id y6so200139lbh.14 for ; Thu, 21 Nov 2013 12:00:42 -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=59iDzZuOK+juhD9Hyz2AOVAhCEQJG1WuvuN9ccxfMUc=; b=b3A69hEPCcVi1WEvRMgszMZxMKyZ0zSjBPHRPm2Ppk5fsScSqSNEQw6CaZRzgkWiek WBLGuDjt0JTcPgh1qKlzX7cRFsmrDttHTykln6R6/iGOo0FWqpHuF0uXmBVfUzd1FjnK ZiLy3lPa2ndQftp0N9kDEomITUNMh0Dgq9AuQuORsu9VEomWIpD8GkHIM1BWxjQ4gId4 MgQXp24pL0ho6WIkOAsemAuzTMXKPC3VqWuXdW8WEZD4m+MgWBGxlANLRe807LwnQ5pf MN3U1SCA0or0kYFXaL2Aoefy3wZ3qvxx9CcQ/21jPJRY6GjWzo4hUBSBkTO3+rxeHFJI gsqw==
MIME-Version: 1.0
X-Received: by 10.152.116.7 with SMTP id js7mr6205666lab.11.1385064042628; Thu, 21 Nov 2013 12:00:42 -0800 (PST)
Received: by 10.112.128.202 with HTTP; Thu, 21 Nov 2013 12:00:42 -0800 (PST)
In-Reply-To: <5ED0603D-B26D-4EDA-AAE5-7F45F9EDC3C3@yahoo.fr>
References: <528D6C63.7050607@bbs.darktech.org> <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr> <5A2BC34D-FE4D-4420-B52F-729087815F37@cisco.com>   <5ED0603D-B26D-4EDA-AAE5-7F45F9EDC3C3@yahoo.fr>
Date: Thu, 21 Nov 2013 15:00:42 -0500
Message-ID: 
From: Monty Montgomery 
To: Bossiel 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:01:01 -0000

On Thu, Nov 21, 2013 at 2:49 PM, Bossiel  wrote:
> Entropy decoding (CABAC/CAVLC) must be done to get the macroblock
> structure(partirions, motion vectors...) and residual (AC/DC coeffs). The
> only part you're skiping is the inverse transform, scaling and motion
> compensation.

You wouldn't even be skipping the inverse transform.  VP8 and h.264
don't use the same DCT, so you'd have to do an inverse to track
transform error propagation, which won't be the same in the two
codecs.  Unless, of course, something else rather clever is going
on...

Monty

From lorenzo@meetecho.com  Thu Nov 21 12:02:17 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C699D1AE2AB for ; Thu, 21 Nov 2013 12:02:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.02
X-Spam-Level: 
X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB9vIw9i3U2A for ; Thu, 21 Nov 2013 12:02:15 -0800 (PST)
Received: from smtpdg11.aruba.it (smtpdg6.aruba.it [62.149.158.236]) by ietfa.amsl.com (Postfix) with ESMTP id C529D1AE2AD for ; Thu, 21 Nov 2013 12:02:14 -0800 (PST)
Received: from rainpc ([87.6.118.125]) by smtpcmd04.ad.aruba.it with bizsmtp id sL251m00r2iQqnr01L25E2; Thu, 21 Nov 2013 21:02:06 +0100
Date: Thu, 21 Nov 2013 21:02:05 +0100
From: Lorenzo Miniero 
To: Peter Dunkley 
Message-ID: <20131121210205.61c44ef2@rainpc>
In-Reply-To: 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com>  
Organization: Meetecho
X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:02:18 -0000

On Thu, 21 Nov 2013 11:46:46 -0800
Peter Dunkley  wrote:

> Hello,
> 
> I am sure there are many people on the blue sheets who have never
> participated on any of the mailing lists.  My point is that to be fair (and
> as this is controversial it must be fair) if they get a vote because they
> showed up in person those of us who showed up online should get a vote too.
> 


Considering that a considerable part of the attendance at the last RTCWEB meeting session was made of people who didn't even know what RTCWEB was, I can't but agree with you.

Lorenzo


> I am based in the UK, so the late in the day meetings at Vancouver were at
> incredibly anti-social times for me.  Still, it was important and I made
> the effort to stay up and participate in the only way I could.
> 
> There is also a consistency issue here.  Those of us on Jabber were able to
> (and encouraged to) participate in the consensus process, but it has been
> proposed that we be excluded from the vote.  Really, you should either be
> able to participate through Jabber or not in a consistent way.
> 
> Regards,
> 
> Peter
> 
> 
> 
> On 21 November 2013 11:37, Silvia Pfeiffer wrote:
> 
> > On Thu, Nov 21, 2013 at 11:13 AM, Adam Roach  wrote:
> > > On 11/21/13 10:56, Justin Uberti wrote:
> > >>
> > >> Following an IETF meeting on Jabber doesn't count as participating?
> > >>
> > >> The "big guy vs little guy" narrative continues...
> > >
> > >
> > > I think that's a bit specious. If someone is following the issue at such
> > a
> > > distance that they haven't expressed an opinion on the mailing list, I
> > can't
> > > see how taking a vote from them counts as anything other than simple,
> > > old-fashioned ballot stuffing.
> >
> > They might have just been active on the W3C webrtc list and watched
> > here to see what is happening with codecs, but haven't expressed their
> > position.
> >
> >
> > > I'll take it one step further. I find the prospect that we're allowing
> > blue
> > > sheets to stand in for participation to be highly questionable: letting
> > the
> > > tourists vote is weighting the opinion of demonstrably uninvolved (or
> > > less-involved) parties at the same level as those who have actually been
> > > working on the topic. I do not think that a blue-sheet sign in without
> > any
> > > on-list participation should be sufficient to participate in the kind of
> > > process the chairs are proposing.
> >
> > We could add that participation on the W3C webrtc list also qualifies.
> >
> >
> > > Or perhaps I'm missing something. Is there something about the
> > capabilities
> > > of "the little guy" that makes sending an email an unrealistically high
> > > barrier to entry?
> >
> > To address the little guys even more, we could also add that
> > participation on the discuss-webrtc list also qualifies.
> >
> > Just my 2c worth.
> >
> > Cheers,
> > Silvia.
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> 
> 
> 
> -- 
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From ekr@rtfm.com  Thu Nov 21 12:02:46 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6287E1AE04D for ; Thu, 21 Nov 2013 12:02:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ndSFRrqVv3a for ; Thu, 21 Nov 2013 12:02:40 -0800 (PST)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 63D511AE2AD for ; Thu, 21 Nov 2013 12:02:40 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id a1so249996wgh.0 for ; Thu, 21 Nov 2013 12:02:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IRpp8JbsJbk49Udo9mXbdo3yahabgoVtB7hYGTWvxlE=; b=LlCJj9DV7UIj4yBP4AdvAtZbswWzFSRFHAKGNY7ufxSH7YRBLnsA9IefSwsDVeJZM1 du4ME8Mp8RlDLnzC5ViKXqRmXVu3Yxht/lpmQFtK5n3ZTivBBUFVGJYhxFfFo4uHOisQ WKgwhQdxNbEob3j35TrDnUG4XI6Rn8Ap5xFO9oVhtQbsM38LzXb3nFMuxhpeV4c4uQcV bXRTqxeEnWM+O7r+V0HSRuPBzytaslLOdj36fJ2c9YnPQoHKV8c3BIsXFfbFecIfdCTM w1EspoxuHrJwszWYBCZDrzdsguCiNMRLBilQ9dUROKo0j97PTepe8+1fmT6yRywSucc8 YBJQ==
X-Gm-Message-State: ALoCoQlazaHVVF2yxjoMsTkZQ+RdxhI5yulWVy3RSBf9naq85zhvw9LQehCR5j3c5PwwqZRSaOZm
X-Received: by 10.180.221.38 with SMTP id qb6mr7302194wic.8.1385064153131; Thu, 21 Nov 2013 12:02:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 21 Nov 2013 12:01:53 -0800 (PST)
X-Originating-IP: [63.245.220.224]
In-Reply-To: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com> 
From: Eric Rescorla 
Date: Thu, 21 Nov 2013 12:01:53 -0800
Message-ID: 
To: Cullen Jennings 
Content-Type: multipart/alternative; boundary=001a1134d2dad6c01e04ebb560e0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:02:46 -0000

--001a1134d2dad6c01e04ebb560e0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I would like to propose some additional alternatives.

SHOULD: Theora
MUST: Theora
SHOULD: H.261
SHOULD: H.261 Theora
MUST: Theora; SHOULD: H.261
MUST: H.261
MUST: H.261; SHOULD: Theora
MUST: H.261 Theora
SHOULD: H.263
SHOULD: H.263 Theora
MUST: Theora; SHOULD: H.263
SHOULD: H.263 H.261
SHOULD: H.263 H.261 Theora
MUST: Theora; SHOULD: H.263 H.261
MUST: H.261; SHOULD: H.263
MUST: H.261; SHOULD: H.263 Theora
MUST: H.261 Theora; SHOULD: H.263
MUST: H.263
MUST: H.263; SHOULD: Theora
MUST: H.263 Theora
MUST: H.263; SHOULD: H.261
MUST: H.263; SHOULD: H.261 Theora
MUST: H.263 Theora; SHOULD: H.261
MUST: H.263 H.261
MUST: H.263 H.261; SHOULD: Theora
MUST: H.263 H.261 Theora
SHOULD: VP8
SHOULD: VP8 Theora
MUST: Theora; SHOULD: VP8
SHOULD: VP8 H.261
SHOULD: VP8 H.261 Theora
MUST: Theora; SHOULD: VP8 H.261
MUST: H.261; SHOULD: VP8
MUST: H.261; SHOULD: VP8 Theora
MUST: H.261 Theora; SHOULD: VP8
SHOULD: VP8 H.263
SHOULD: VP8 H.263 Theora
MUST: Theora; SHOULD: VP8 H.263
SHOULD: VP8 H.263 H.261
SHOULD: VP8 H.263 H.261 Theora
MUST: Theora; SHOULD: VP8 H.263 H.261
MUST: H.261; SHOULD: VP8 H.263
MUST: H.261; SHOULD: VP8 H.263 Theora
MUST: H.261 Theora; SHOULD: VP8 H.263
MUST: H.263; SHOULD: VP8
MUST: H.263; SHOULD: VP8 Theora
MUST: H.263 Theora; SHOULD: VP8
MUST: H.263; SHOULD: VP8 H.261
MUST: H.263; SHOULD: VP8 H.261 Theora
MUST: H.263 Theora; SHOULD: VP8 H.261
MUST: H.263 H.261; SHOULD: VP8
MUST: H.263 H.261; SHOULD: VP8 Theora
MUST: H.263 H.261 Theora; SHOULD: VP8
MUST: VP8
MUST: VP8; SHOULD: Theora
MUST: VP8 Theora
 MUST: VP8; SHOULD: H.261
MUST: VP8; SHOULD: H.261 Theora
MUST: VP8 Theora; SHOULD: H.261
MUST: VP8 H.261
MUST: VP8 H.261; SHOULD: Theora
MUST: VP8 H.261 Theora
MUST: VP8; SHOULD: H.263
MUST: VP8; SHOULD: H.263 Theora
MUST: VP8 Theora; SHOULD: H.263
MUST: VP8; SHOULD: H.263 H.261
MUST: VP8; SHOULD: H.263 H.261 Theora
MUST: VP8 Theora; SHOULD: H.263 H.261
MUST: VP8 H.261; SHOULD: H.263
MUST: VP8 H.261; SHOULD: H.263 Theora
MUST: VP8 H.261 Theora; SHOULD: H.263
MUST: VP8 H.263
MUST: VP8 H.263; SHOULD: Theora
MUST: VP8 H.263 Theora
MUST: VP8 H.263; SHOULD: H.261
MUST: VP8 H.263; SHOULD: H.261 Theora
MUST: VP8 H.263 Theora; SHOULD: H.261
MUST: VP8 H.263 H.261
MUST: VP8 H.263 H.261; SHOULD: Theora
MUST: VP8 H.263 H.261 Theora
SHOULD: H.264
SHOULD: H.264 Theora
MUST: Theora; SHOULD: H.264
SHOULD: H.264 H.261
SHOULD: H.264 H.261 Theora
MUST: Theora; SHOULD: H.264 H.261
MUST: H.261; SHOULD: H.264
MUST: H.261; SHOULD: H.264 Theora
MUST: H.261 Theora; SHOULD: H.264
SHOULD: H.264 H.263
SHOULD: H.264 H.263 Theora
MUST: Theora; SHOULD: H.264 H.263
SHOULD: H.264 H.263 H.261
SHOULD: H.264 H.263 H.261 Theora
MUST: Theora; SHOULD: H.264 H.263 H.261
MUST: H.261; SHOULD: H.264 H.263
MUST: H.261; SHOULD: H.264 H.263 Theora
MUST: H.261 Theora; SHOULD: H.264 H.263
MUST: H.263; SHOULD: H.264
MUST: H.263; SHOULD: H.264 Theora
MUST: H.263 Theora; SHOULD: H.264
MUST: H.263; SHOULD: H.264 H.261
MUST: H.263; SHOULD: H.264 H.261 Theora
MUST: H.263 Theora; SHOULD: H.264 H.261
MUST: H.263 H.261; SHOULD: H.264
MUST: H.263 H.261; SHOULD: H.264 Theora
MUST: H.263 H.261 Theora; SHOULD: H.264
SHOULD: H.264 VP8
SHOULD: H.264 VP8 Theora
MUST: Theora; SHOULD: H.264 VP8
SHOULD: H.264 VP8 H.261
SHOULD: H.264 VP8 H.261 Theora
MUST: Theora; SHOULD: H.264 VP8 H.261
MUST: H.261; SHOULD: H.264 VP8
MUST: H.261; SHOULD: H.264 VP8 Theora
MUST: H.261 Theora; SHOULD: H.264 VP8
SHOULD: H.264 VP8 H.263
SHOULD: H.264 VP8 H.263 Theora
MUST: Theora; SHOULD: H.264 VP8 H.263
SHOULD: H.264 VP8 H.263 H.261
SHOULD: H.264 VP8 H.263 H.261 Theora
MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
MUST: H.261; SHOULD: H.264 VP8 H.263
MUST: H.261; SHOULD: H.264 VP8 H.263 Theora
MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
MUST: H.263; SHOULD: H.264 VP8
MUST: H.263; SHOULD: H.264 VP8 Theora
MUST: H.263 Theora; SHOULD: H.264 VP8
MUST: H.263; SHOULD: H.264 VP8 H.261
MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
MUST: H.263 Theora; SHOULD: H.264 VP8 H.261
MUST: H.263 H.261; SHOULD: H.264 VP8
MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
MUST: H.263 H.261 Theora; SHOULD: H.264 VP8
MUST: VP8; SHOULD: H.264
MUST: VP8; SHOULD: H.264 Theora
MUST: VP8 Theora; SHOULD: H.264
MUST: VP8; SHOULD: H.264 H.261
MUST: VP8; SHOULD: H.264 H.261 Theora
MUST: VP8 Theora; SHOULD: H.264 H.261
MUST: VP8 H.261; SHOULD: H.264
MUST: VP8 H.261; SHOULD: H.264 Theora
MUST: VP8 H.261 Theora; SHOULD: H.264
MUST: VP8; SHOULD: H.264 H.263
MUST: VP8; SHOULD: H.264 H.263 Theora
MUST: VP8 Theora; SHOULD: H.264 H.263
MUST: VP8; SHOULD: H.264 H.263 H.261
MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
MUST: VP8 H.261; SHOULD: H.264 H.263
MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
MUST: VP8 H.261 Theora; SHOULD: H.264 H.263
MUST: VP8 H.263; SHOULD: H.264
MUST: VP8 H.263; SHOULD: H.264 Theora
MUST: VP8 H.263 Theora; SHOULD: H.264
MUST: VP8 H.263; SHOULD: H.264 H.261
MUST: VP8 H.263; SHOULD: H.264 H.261 Theora
MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
MUST: VP8 H.263 H.261; SHOULD: H.264
MUST: VP8 H.263 H.261; SHOULD: H.264 Theora
MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
MUST: H.264
MUST: H.264; SHOULD: Theora
MUST: H.264 Theora
MUST: H.264; SHOULD: H.261
MUST: H.264; SHOULD: H.261 Theora
MUST: H.264 Theora; SHOULD: H.261
MUST: H.264 H.261
MUST: H.264 H.261; SHOULD: Theora
MUST: H.264 H.261 Theora
MUST: H.264; SHOULD: H.263
MUST: H.264; SHOULD: H.263 Theora
MUST: H.264 Theora; SHOULD: H.263
MUST: H.264; SHOULD: H.263 H.261
MUST: H.264; SHOULD: H.263 H.261 Theora
MUST: H.264 Theora; SHOULD: H.263 H.261
MUST: H.264 H.261; SHOULD: H.263
MUST: H.264 H.261; SHOULD: H.263 Theora
MUST: H.264 H.261 Theora; SHOULD: H.263
MUST: H.264 H.263
MUST: H.264 H.263; SHOULD: Theora
MUST: H.264 H.263 Theora
MUST: H.264 H.263; SHOULD: H.261
MUST: H.264 H.263; SHOULD: H.261 Theora
MUST: H.264 H.263 Theora; SHOULD: H.261
MUST: H.264 H.263 H.261
MUST: H.264 H.263 H.261; SHOULD: Theora
MUST: H.264 H.263 H.261 Theora
MUST: H.264; SHOULD: VP8
MUST: H.264; SHOULD: VP8 Theora
MUST: H.264 Theora; SHOULD: VP8
MUST: H.264; SHOULD: VP8 H.261
MUST: H.264; SHOULD: VP8 H.261 Theora
MUST: H.264 Theora; SHOULD: VP8 H.261
MUST: H.264 H.261; SHOULD: VP8
MUST: H.264 H.261; SHOULD: VP8 Theora
MUST: H.264 H.261 Theora; SHOULD: VP8
MUST: H.264; SHOULD: VP8 H.263
MUST: H.264; SHOULD: VP8 H.263 Theora
MUST: H.264 Theora; SHOULD: VP8 H.263
MUST: H.264; SHOULD: VP8 H.263 H.261
MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
MUST: H.264 H.261; SHOULD: VP8 H.263
MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
MUST: H.264 H.261 Theora; SHOULD: VP8 H.263
MUST: H.264 H.263; SHOULD: VP8
MUST: H.264 H.263; SHOULD: VP8 Theora
MUST: H.264 H.263 Theora; SHOULD: VP8
MUST: H.264 H.263; SHOULD: VP8 H.261
MUST: H.264 H.263; SHOULD: VP8 H.261 Theora
MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
MUST: H.264 H.263 H.261; SHOULD: VP8
MUST: H.264 H.263 H.261; SHOULD: VP8 Theora
MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
MUST: H.264 VP8
MUST: H.264 VP8; SHOULD: Theora
MUST: H.264 VP8 Theora
MUST: H.264 VP8; SHOULD: H.261
MUST: H.264 VP8; SHOULD: H.261 Theora
MUST: H.264 VP8 Theora; SHOULD: H.261
MUST: H.264 VP8 H.261
MUST: H.264 VP8 H.261; SHOULD: Theora
MUST: H.264 VP8 H.261 Theora
MUST: H.264 VP8; SHOULD: H.263
MUST: H.264 VP8; SHOULD: H.263 Theora
MUST: H.264 VP8 Theora; SHOULD: H.263
MUST: H.264 VP8; SHOULD: H.263 H.261
MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
MUST: H.264 VP8 H.261; SHOULD: H.263
MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
MUST: H.264 VP8 H.261 Theora; SHOULD: H.263
MUST: H.264 VP8 H.263
MUST: H.264 VP8 H.263; SHOULD: Theora
MUST: H.264 VP8 H.263 Theora
MUST: H.264 VP8 H.263; SHOULD: H.261
MUST: H.264 VP8 H.263; SHOULD: H.261 Theora
MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
MUST: H.264 VP8 H.263 H.261
MUST: H.264 VP8 H.263 H.261; SHOULD: Theora
MUST: H.264 VP8 H.263 H.261 Theora
SHOULD do 1 of {H.261, Theora}
SHOULD do 1 of {H.263, Theora}
SHOULD do 1 of {H.263, H.261}
SHOULD do 1 of {H.263, H.261, Theora}
SHOULD do 2 of {H.263, H.261, Theora}
SHOULD do 1 of {VP8, Theora}
SHOULD do 1 of {VP8, H.261}
SHOULD do 1 of {VP8, H.261, Theora}
SHOULD do 2 of {VP8, H.261, Theora}
SHOULD do 1 of {VP8, H.263}
SHOULD do 1 of {VP8, H.263, Theora}
SHOULD do 2 of {VP8, H.263, Theora}
SHOULD do 1 of {VP8, H.263, H.261}
SHOULD do 2 of {VP8, H.263, H.261}
SHOULD do 1 of {VP8, H.263, H.261, Theora}
SHOULD do 2 of {VP8, H.263, H.261, Theora}
SHOULD do 3 of {VP8, H.263, H.261, Theora}
SHOULD do 1 of {H.264, Theora}
SHOULD do 1 of {H.264, H.261}
SHOULD do 1 of {H.264, H.261, Theora}
SHOULD do 2 of {H.264, H.261, Theora}
SHOULD do 1 of {H.264, H.263}
SHOULD do 1 of {H.264, H.263, Theora}
SHOULD do 2 of {H.264, H.263, Theora}
SHOULD do 1 of {H.264, H.263, H.261}
SHOULD do 2 of {H.264, H.263, H.261}
SHOULD do 1 of {H.264, H.263, H.261, Theora}
SHOULD do 2 of {H.264, H.263, H.261, Theora}
SHOULD do 3 of {H.264, H.263, H.261, Theora}
SHOULD do 1 of {H.264, VP8}
SHOULD do 1 of {H.264, VP8, Theora}
SHOULD do 2 of {H.264, VP8, Theora}
SHOULD do 1 of {H.264, VP8, H.261}
SHOULD do 2 of {H.264, VP8, H.261}
SHOULD do 1 of {H.264, VP8, H.261, Theora}
SHOULD do 2 of {H.264, VP8, H.261, Theora}
SHOULD do 3 of {H.264, VP8, H.261, Theora}
SHOULD do 1 of {H.264, VP8, H.263}
SHOULD do 2 of {H.264, VP8, H.263}
SHOULD do 1 of {H.264, VP8, H.263, Theora}
SHOULD do 2 of {H.264, VP8, H.263, Theora}
SHOULD do 3 of {H.264, VP8, H.263, Theora}
SHOULD do 1 of {H.264, VP8, H.263, H.261}
SHOULD do 2 of {H.264, VP8, H.263, H.261}
SHOULD do 3 of {H.264, VP8, H.263, H.261}
SHOULD do 1 of {H.264, VP8, H.263, H.261, Theora}
SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
SHOULD do 3 of {H.264, VP8, H.263, H.261, Theora}
SHOULD do 4 of {H.264, VP8, H.263, H.261, Theora}
MUST do 1 of {H.261, Theora}
MUST do 1 of {H.263, Theora}
MUST do 1 of {H.263, H.261}
MUST do 1 of {H.263, H.261, Theora}
MUST do 2 of {H.263, H.261, Theora}
MUST do 1 of {VP8, Theora}
MUST do 1 of {VP8, H.261}
MUST do 1 of {VP8, H.261, Theora}
MUST do 2 of {VP8, H.261, Theora}
MUST do 1 of {VP8, H.263}
MUST do 1 of {VP8, H.263, Theora}
MUST do 2 of {VP8, H.263, Theora}
MUST do 1 of {VP8, H.263, H.261}
MUST do 2 of {VP8, H.263, H.261}
MUST do 1 of {VP8, H.263, H.261, Theora}
MUST do 2 of {VP8, H.263, H.261, Theora}
MUST do 3 of {VP8, H.263, H.261, Theora}
MUST do 1 of {H.264, Theora}
MUST do 1 of {H.264, H.261}
MUST do 1 of {H.264, H.261, Theora}
MUST do 2 of {H.264, H.261, Theora}
MUST do 1 of {H.264, H.263}
MUST do 1 of {H.264, H.263, Theora}
MUST do 2 of {H.264, H.263, Theora}
MUST do 1 of {H.264, H.263, H.261}
MUST do 2 of {H.264, H.263, H.261}
MUST do 1 of {H.264, H.263, H.261, Theora}
MUST do 2 of {H.264, H.263, H.261, Theora}
MUST do 3 of {H.264, H.263, H.261, Theora}
MUST do 1 of {H.264, VP8}
MUST do 1 of {H.264, VP8, Theora}
MUST do 2 of {H.264, VP8, Theora}
MUST do 1 of {H.264, VP8, H.261}
MUST do 2 of {H.264, VP8, H.261}
MUST do 1 of {H.264, VP8, H.261, Theora}
MUST do 2 of {H.264, VP8, H.261, Theora}
MUST do 3 of {H.264, VP8, H.261, Theora}
MUST do 1 of {H.264, VP8, H.263}
MUST do 2 of {H.264, VP8, H.263}
MUST do 1 of {H.264, VP8, H.263, Theora}
MUST do 2 of {H.264, VP8, H.263, Theora}
MUST do 3 of {H.264, VP8, H.263, Theora}
MUST do 1 of {H.264, VP8, H.263, H.261}
MUST do 2 of {H.264, VP8, H.263, H.261}
MUST do 3 of {H.264, VP8, H.263, H.261}
MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
MUST do 2 of {H.264, VP8, H.263, H.261, Theora}
MUST do 3 of {H.264, VP8, H.263, H.261, Theora}
MUST do 4 of {H.264, VP8, H.263, H.261, Theora}







On Thu, Nov 21, 2013 at 11:27 AM, Cullen Jennings  wrote:

>
> Added a
>
> #11     =95 MUST implement at least two of {VP8, H.264 CBP, H.263}
>
>
> On Nov 21, 2013, at 11:20 AM, David Singer  wrote:
>
> > Chairs
> >
> > can we add this as an option to the formal list, so we get formal
> feedback on its acceptability, please?
> >
> > =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
> >
> >
> > I think this may be the best (maybe only) way to tease out how much ris=
k
> people perceive.
> >
> > Many thanks
> >
> > On Nov 21, 2013, at 9:22 , Maik Merten 
> wrote:
> >
> >> Cleary H.263 is preferable from an engineering standpoint (as is, e.g.=
,
> MPEG-1 Part 2): better performance, more deployments. The central questio=
n
> is, however, if those can actually be implemented without some sort of
> licensing.
> >>
> >> If they can: Aweseome! However, this may not be determinable without a
> review by people who are knowledgeable in the field of IPR, i.e., "actual
> lawyers". I understand that H.263 is not yet old enough to automatically =
be
> considered "safe" (and neither is MPEG-1 Part 2, although it is closer).
> >>
> >> Best regards,
> >>
> >> Maik
> >>
> >> Am 20.11.2013 20:42, schrieb David Singer:
> >>> I think we should think hard about H.263 instead of H.261 as the thir=
d
> fallback.  Why?
> >>>
> >>> http://www.itu.int/rec/T-REC-H.263/
> >>>
> >>>
> >>>
> >>> H.263 was first published in March 1996, so it's 17 years old.  The
> restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more
> recent amendments deal with this (and a plethora of other issues), so we=
=92d
> need to settle on which of those are mandatory (the usual profiling
> discussion).
> >>>
> >>> There are 34 records in the patent database against H.261, mostly fro=
m
> 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2
> (reciprocity), as was one other I checked.
> >>>
> >>> Rather surprisingly, there are only 31 against H.263!  The most recen=
t
> is 2011, and is also option 2.  Most are 1997-2001.
> >>>
> >>>
> >>> On this quick glance, H.263 appears no worse than H.261. IANAL (as I
> am sure you have all noticed).
> >>>
> >>>
> >>> H.263 is much more widely supported and mandated.  It has been
> mandated in the 3GPP specs for years (for lots of services, including
> videoconf), and is effectively the fallback codec today in the industry, =
as
> I understand.  It was ubiquitous in video telephony for years, and I
> suspect many of those systems still ship it.
> >>>
> >>> So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 wo=
rk?
> >>>
> >>> (I am asking the question, not even answering on behalf of my company=
,
> yet.  Let=92s get the issues on the table.)
> >>>
> >>>
> >>> David Singer
> >>> Multimedia and Software Standards, Apple Inc.
> >>>
> >>> _______________________________________________
> >>> 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
> >
> > David Singer
> > Multimedia and Software Standards, Apple Inc.
> >
> > _______________________________________________
> > 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
>

--001a1134d2dad6c01e04ebb560e0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


    I would like to propose some additional alternatives.
    =

    SHOULD: Theora
    MUST: Theora
    SHOULD:=
 H.261
    SHOULD: H.261 Theora
    MUST: Theora; SHOULD: H.261=

    



    MUST: H.261
    MUST: H.261; SHOULD: Theora
    MUST: H.26=
1 Theora
    SHOULD: H.263
    SHOULD: H.263 Theora
    M=
UST: Theora; SHOULD: H.263
    SHOULD: H.263 H.261
    SHOULD: =
H.263 H.261 Theora
    



    MUST: Theora; SHOULD: H.263 H.261
    MUST: H.261; SHOULD: H.263=

    MUST: H.261; SHOULD: H.263 Theora
    MUST: H.261 Theora; =
SHOULD: H.263
    MUST: H.263
    MUST: H.263; SHOULD: Theora



    MUST: H.263 Theora
    MUST: H.263; SHOULD: H.261
    MUST=
: H.263; SHOULD: H.261 Theora
    MUST: H.263 Theora; SHOULD: H.261
    MUST: H.263 H.261
    MUST: H.263 H.261; SHOULD: Theora



    MUST: H.263 H.261 Theora
    SHOULD: VP8
    SHOULD: VP8 T=
heora
    MUST: Theora; SHOULD: VP8
    SHOULD: VP8 H.261
    =

    SHOULD: VP8 H.261 Theora
    MUST: Theora; SHOULD: VP8 H.261



    MUST: H.261; SHOULD: VP8
    MUST: H.261; SHOULD: VP8 Theora
    MUST: H.261 Theora; SHOULD: VP8
    SHOULD: VP8 H.263
    SHOULD: VP8 H.263 Theora
    MUST: Theora; SHOULD: VP8 H.263
    



    SHOULD: VP8 H.263 H.261
    SHOULD: VP8 H.263 H.261 Theora
    =

    MUST: Theora; SHOULD: VP8 H.263 H.261
    MUST: H.261; SHOULD: V=
P8 H.263
    MUST: H.261; SHOULD: VP8 H.263 Theora
    MUST: H.=
261 Theora; SHOULD: VP8 H.263
    



    MUST: H.263; SHOULD: VP8
    MUST: H.263; SHOULD: VP8 Theora
    MUST: H.263 Theora; SHOULD: VP8
    MUST: H.263; SHOULD: VP8 H=
.261
    MUST: H.263; SHOULD: VP8 H.261 Theora
    MUST: H.263 =
Theora; SHOULD: VP8 H.261
    



    MUST: H.263 H.261; SHOULD: VP8
    MUST: H.263 H.261; SHOULD: VP=
8 Theora
    MUST: H.263 H.261 Theora; SHOULD: VP8
    MUST: VP=
8
    MUST: VP8; SHOULD: Theora
    MUST: VP8 Theora
    


    
MUST: VP8; SHOULD: H.261
    MUST: VP8; SHOULD: H.261 Theora
    MUST: VP8 Theora; SHOULD: H.261
    MUST: VP8 H.261
    MUST:=
 VP8 H.261; SHOULD: Theora
    MUST: VP8 H.261 Theora
    

MUST: VP8; SHOULD: H.263
    

    MUST: VP8; SHOULD: H.263 Theora
    MUST: VP8 Theora; SHOULD: H.=
263
    MUST: VP8; SHOULD: H.263 H.261
    MUST: VP8; SHOULD: H=
.263 H.261 Theora
    MUST: VP8 Theora; SHOULD: H.263 H.261
    



    MUST: VP8 H.261; SHOULD: H.263
    MUST: VP8 H.261; SHOULD: H.26=
3 Theora
    MUST: VP8 H.261 Theora; SHOULD: H.263
    MUST: VP=
8 H.263
    MUST: VP8 H.263; SHOULD: Theora
    MUST: VP8 H.263=
 Theora
    



    MUST: VP8 H.263; SHOULD: H.261
    MUST: VP8 H.263; SHOULD: H.26=
1 Theora
    MUST: VP8 H.263 Theora; SHOULD: H.261
    MUST: VP=
8 H.263 H.261
    MUST: VP8 H.263 H.261; SHOULD: Theora
    


MUST: VP8 H.263 H.261 Theora
    SHOULD: H.264
    SHOULD: H.26=
4 Theora
    MUST: Theora; SHOULD: H.264
    SHOULD: H.264 H.26=
1
    SHOULD: H.264 H.261 Theora
    MUST: Theora; SHOULD: H.26=
4 H.261
    



    MUST: H.261; SHOULD: H.264
    MUST: H.261; SHOULD: H.264 Theora=

    MUST: H.261 Theora; SHOULD: H.264
    SHOULD: H.264 H.263<=
/div>
    SHOULD: H.264 H.263 Theora
    MUST: Theora; SHOULD: H.264 =
H.263
    



    SHOULD: H.264 H.263 H.261
    SHOULD: H.264 H.263 H.261 Theora
    MUST: Theora; SHOULD: H.264 H.263 H.261
    MUST: H.261; SHO=
ULD: H.264 H.263
    MUST: H.261; SHOULD: H.264 H.263 Theora
    



    MUST: H.261 Theora; SHOULD: H.264 H.263
    MUST: H.263; SHOULD:=
 H.264
    MUST: H.263; SHOULD: H.264 Theora
    MUST: H.263 Th=
eora; SHOULD: H.264
    MUST: H.263; SHOULD: H.264 H.261
    


MUST: H.263; SHOULD: H.264 H.261 Theora
    MUST: H.263 Theora; SHOUL=
D: H.264 H.261
    MUST: H.263 H.261; SHOULD: H.264
    MUST: H=
.263 H.261; SHOULD: H.264 Theora
    MUST: H.263 H.261 Theora; SHOULD=
: H.264
    



    SHOULD: H.264 VP8
    SHOULD: H.264 VP8 Theora
    MUST: T=
heora; SHOULD: H.264 VP8
    SHOULD: H.264 VP8 H.261
    SHOULD=
: H.264 VP8 H.261 Theora
    MUST: Theora; SHOULD: H.264 VP8 H.261



    MUST: H.261; SHOULD: H.264 VP8
    MUST: H.261; SHOULD: H.264 VP=
8 Theora
    MUST: H.261 Theora; SHOULD: H.264 VP8
    SHOULD: =
H.264 VP8 H.263
    SHOULD: H.264 VP8 H.263 Theora
    MUST: Th=
eora; SHOULD: H.264 VP8 H.263
    



    SHOULD: H.264 VP8 H.263 H.261
    SHOULD: H.264 VP8 H.263 H.261 =
Theora
    MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
    MUST=
: H.261; SHOULD: H.264 VP8 H.263
    MUST: H.261; SHOULD: H.264 VP8 H=
.263 Theora
    



    MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
    MUST: H.263; SHO=
ULD: H.264 VP8
    MUST: H.263; SHOULD: H.264 VP8 Theora
    MU=
ST: H.263 Theora; SHOULD: H.264 VP8
    MUST: H.263; SHOULD: H.264 VP=
8 H.261
    



    MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
    MUST: H.263 Theo=
ra; SHOULD: H.264 VP8 H.261
    MUST: H.263 H.261; SHOULD: H.264 VP8<=
/div>
    MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
    MUST: H.263=
 H.261 Theora; SHOULD: H.264 VP8
    



    MUST: VP8; SHOULD: H.264
    MUST: VP8; SHOULD: H.264 Theora
    MUST: VP8 Theora; SHOULD: H.264
    MUST: VP8; SHOULD: H.264 H=
.261
    MUST: VP8; SHOULD: H.264 H.261 Theora
    MUST: VP8 Th=
eora; SHOULD: H.264 H.261
    



    MUST: VP8 H.261; SHOULD: H.264
    MUST: VP8 H.261; SHOULD: H.26=
4 Theora
    MUST: VP8 H.261 Theora; SHOULD: H.264
    MUST: VP=
8; SHOULD: H.264 H.263
    MUST: VP8; SHOULD: H.264 H.263 Theora



    MUST: VP8 Theora; SHOULD: H.264 H.263
    MUST: VP8; SHOULD: H.2=
64 H.263 H.261
    MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
    <=
div>MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
    MUST: VP8 H.261; =
SHOULD: H.264 H.263
    



    MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
    MUST: VP8 H.261 =
Theora; SHOULD: H.264 H.263
    MUST: VP8 H.263; SHOULD: H.264
    <=
div>MUST: VP8 H.263; SHOULD: H.264 Theora
    MUST: VP8 H.263 Theora;=
 SHOULD: H.264
    



    MUST: VP8 H.263; SHOULD: H.264 H.261
    MUST: VP8 H.263; SHOULD=
: H.264 H.261 Theora
    MUST: VP8 H.263 Theora; SHOULD: H.264 H.261<=
/div>
    MUST: VP8 H.263 H.261; SHOULD: H.264
    MUST: VP8 H.263 H.=
261; SHOULD: H.264 Theora
    



    MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
    MUST: H.264
    MUST: H.264; SHOULD: Theora
    MUST: H.264 Theora
    MU=
ST: H.264; SHOULD: H.261
    MUST: H.264; SHOULD: H.261 Theora
    



    MUST: H.264 Theora; SHOULD: H.261
    MUST: H.264 H.261
    MUST: H.264 H.261; SHOULD: Theora
    MUST: H.264 H.261 Theora
    MUST: H.264; SHOULD: H.263
    MUST: H.264; SHOULD: H.263 Theor=
a
    



    MUST: H.264 Theora; SHOULD: H.263
    MUST: H.264; SHOULD: H.263=
 H.261
    MUST: H.264; SHOULD: H.263 H.261 Theora
    MUST: H.=
264 Theora; SHOULD: H.263 H.261
    MUST: H.264 H.261; SHOULD: H.263<=
/div>



    MUST: H.264 H.261; SHOULD: H.263 Theora
    MUST: H.264 H.261 Th=
eora; SHOULD: H.263
    MUST: H.264 H.263
    MUST: H.264 H.263=
; SHOULD: Theora
    MUST: H.264 H.263 Theora
    MUST: H.264 H=
.263; SHOULD: H.261
    



    MUST: H.264 H.263; SHOULD: H.261 Theora
    MUST: H.264 H.263 Th=
eora; SHOULD: H.261
    MUST: H.264 H.263 H.261
    MUST: H.264=
 H.263 H.261; SHOULD: Theora
    MUST: H.264 H.263 H.261 Theora
    



    MUST: H.264; SHOULD: VP8
    MUST: H.264; SHOULD: VP8 Theora
    MUST: H.264 Theora; SHOULD: VP8
    MUST: H.264; SHOULD: VP8 H=
.261
    MUST: H.264; SHOULD: VP8 H.261 Theora
    MUST: H.264 =
Theora; SHOULD: VP8 H.261
    



    MUST: H.264 H.261; SHOULD: VP8
    MUST: H.264 H.261; SHOULD: VP=
8 Theora
    MUST: H.264 H.261 Theora; SHOULD: VP8
    MUST: H.=
264; SHOULD: VP8 H.263
    MUST: H.264; SHOULD: VP8 H.263 Theora



    MUST: H.264 Theora; SHOULD: VP8 H.263
    MUST: H.264; SHOULD: V=
P8 H.263 H.261
    MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
    <=
div>MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
    MUST: H.264 H.261=
; SHOULD: VP8 H.263
    



    MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
    MUST: H.264 H.26=
1 Theora; SHOULD: VP8 H.263
    MUST: H.264 H.263; SHOULD: VP8
    <=
div>MUST: H.264 H.263; SHOULD: VP8 Theora
    MUST: H.264 H.263 Theor=
a; SHOULD: VP8
    



    MUST: H.264 H.263; SHOULD: VP8 H.261
    MUST: H.264 H.263; SHOU=
LD: VP8 H.261 Theora
    MUST: H.264 H.263 Theora; SHOULD: VP8 H.261<=
/div>
    MUST: H.264 H.263 H.261; SHOULD: VP8
    MUST: H.264 H.263 =
H.261; SHOULD: VP8 Theora
    



    MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
    MUST: H.264 VP8<=
/div>
    MUST: H.264 VP8; SHOULD: Theora
    MUST: H.264 VP8 Theora<=
/div>
    MUST: H.264 VP8; SHOULD: H.261
    MUST: H.264 VP8; SHOULD:=
 H.261 Theora
    



    MUST: H.264 VP8 Theora; SHOULD: H.261
    MUST: H.264 VP8 H.261<=
/div>
    MUST: H.264 VP8 H.261; SHOULD: Theora
    MUST: H.264 VP8 H=
.261 Theora
    MUST: H.264 VP8; SHOULD: H.263
    MUST: H.264 =
VP8; SHOULD: H.263 Theora
    



    MUST: H.264 VP8 Theora; SHOULD: H.263
    MUST: H.264 VP8; SHOUL=
D: H.263 H.261
    MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
    <=
div>MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
    MUST: H.264 VP8 H=
.261; SHOULD: H.263
    



    MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
    MUST: H.264 VP8 =
H.261 Theora; SHOULD: H.263
    MUST: H.264 VP8 H.263
    MUST:=
 H.264 VP8 H.263; SHOULD: Theora
    MUST: H.264 VP8 H.263 Theora



    MUST: H.264 VP8 H.263; SHOULD: H.261
    MUST: H.264 VP8 H.263; =
SHOULD: H.261 Theora
    MUST: H.264 VP8 H.263 Theora; SHOULD: H.261<=
/div>
    MUST: H.264 VP8 H.263 H.261
    MUST: H.264 VP8 H.263 H.261=
; SHOULD: Theora
    



    MUST: H.264 VP8 H.263 H.261 Theora
    SHOULD do 1 of {H.261, Th=
eora}
    SHOULD do 1 of {H.263, Theora}
    SHOULD do 1 of {H.=
263, H.261}
    SHOULD do 1 of {H.263, H.261, Theora}
    

SHOULD do 2 of {H.263, H.261, Theora}
    

    SHOULD do 1 of {VP8, Theora}
    SHOULD do 1 of {VP8, H.261}
    SHOULD do 1 of {VP8, H.261, Theora}
    SHOULD do 2 of {VP8, H=
.261, Theora}
    SHOULD do 1 of {VP8, H.263}
    SHOULD do 1 o=
f {VP8, H.263, Theora}
    



    SHOULD do 2 of {VP8, H.263, Theora}
    SHOULD do 1 of {VP8, H.2=
63, H.261}
    SHOULD do 2 of {VP8, H.263, H.261}
    SHOULD do=
 1 of {VP8, H.263, H.261, Theora}
    SHOULD do 2 of {VP8, H.263, H.2=
61, Theora}
    



    SHOULD do 3 of {VP8, H.263, H.261, Theora}
    SHOULD do 1 of {H=
.264, Theora}
    SHOULD do 1 of {H.264, H.261}
    SHOULD do 1=
 of {H.264, H.261, Theora}
    SHOULD do 2 of {H.264, H.261, Theora}<=
/div>



    SHOULD do 1 of {H.264, H.263}
    SHOULD do 1 of {H.264, H.263, =
Theora}
    SHOULD do 2 of {H.264, H.263, Theora}
    SHOULD do=
 1 of {H.264, H.263, H.261}
    SHOULD do 2 of {H.264, H.263, H.261}<=
/div>



    SHOULD do 1 of {H.264, H.263, H.261, Theora}
    SHOULD do 2 of =
{H.264, H.263, H.261, Theora}
    SHOULD do 3 of {H.264, H.263, H.261=
, Theora}
    SHOULD do 1 of {H.264, VP8}
    SHOULD do 1 of {H=
.264, VP8, Theora}
    



    SHOULD do 2 of {H.264, VP8, Theora}
    SHOULD do 1 of {H.264, V=
P8, H.261}
    SHOULD do 2 of {H.264, VP8, H.261}
    SHOULD do=
 1 of {H.264, VP8, H.261, Theora}
    SHOULD do 2 of {H.264, VP8, H.2=
61, Theora}
    



    SHOULD do 3 of {H.264, VP8, H.261, Theora}
    SHOULD do 1 of {H=
.264, VP8, H.263}
    SHOULD do 2 of {H.264, VP8, H.263}
    SH=
OULD do 1 of {H.264, VP8, H.263, Theora}
    SHOULD do 2 of {H.264, V=
P8, H.263, Theora}
    



    SHOULD do 3 of {H.264, VP8, H.263, Theora}
    SHOULD do 1 of {H=
.264, VP8, H.263, H.261}
    SHOULD do 2 of {H.264, VP8, H.263, H.261=
}
    SHOULD do 3 of {H.264, VP8, H.263, H.261}
    SHOULD do 1=
 of {H.264, VP8, H.263, H.261, Theora}
    



    SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
    SHOULD do =
3 of {H.264, VP8, H.263, H.261, Theora}
    SHOULD do 4 of {H.264, VP=
8, H.263, H.261, Theora}
    MUST do 1 of {H.261, Theora}
    


MUST do 1 of {H.263, Theora}
    MUST do 1 of {H.263, H.261}
    MUST do 1 of {H.263, H.261, Theora}
    MUST do 2 of {H.263, H.261,=
 Theora}
    MUST do 1 of {VP8, Theora}
    MUST do 1 of {VP8, =
H.261}
    



    MUST do 1 of {VP8, H.261, Theora}
    MUST do 2 of {VP8, H.261, =
Theora}
    MUST do 1 of {VP8, H.263}
    MUST do 1 of {VP8, H.=
263, Theora}
    MUST do 2 of {VP8, H.263, Theora}
    MUST do =
1 of {VP8, H.263, H.261}
    



    MUST do 2 of {VP8, H.263, H.261}
    MUST do 1 of {VP8, H.263, H=
.261, Theora}
    MUST do 2 of {VP8, H.263, H.261, Theora}
    =
MUST do 3 of {VP8, H.263, H.261, Theora}
    MUST do 1 of {H.264, The=
ora}
    



    MUST do 1 of {H.264, H.261}
    MUST do 1 of {H.264, H.261, Theo=
ra}
    MUST do 2 of {H.264, H.261, Theora}
    MUST do 1 of {H=
.264, H.263}
    MUST do 1 of {H.264, H.263, Theora}
    MUST d=
o 2 of {H.264, H.263, Theora}
    



    MUST do 1 of {H.264, H.263, H.261}
    MUST do 2 of {H.264, H.26=
3, H.261}
    MUST do 1 of {H.264, H.263, H.261, Theora}
    MU=
ST do 2 of {H.264, H.263, H.261, Theora}
    MUST do 3 of {H.264, H.2=
63, H.261, Theora}
    



    MUST do 1 of {H.264, VP8}
    MUST do 1 of {H.264, VP8, Theora}<=
/div>
    MUST do 2 of {H.264, VP8, Theora}
    MUST do 1 of {H.264, =
VP8, H.261}
    MUST do 2 of {H.264, VP8, H.261}
    MUST do 1 =
of {H.264, VP8, H.261, Theora}
    



    MUST do 2 of {H.264, VP8, H.261, Theora}
    MUST do 3 of {H.264=
, VP8, H.261, Theora}
    MUST do 1 of {H.264, VP8, H.263}
    =
MUST do 2 of {H.264, VP8, H.263}
    MUST do 1 of {H.264, VP8, H.263,=
 Theora}
    



    MUST do 2 of {H.264, VP8, H.263, Theora}
    MUST do 3 of {H.264=
, VP8, H.263, Theora}
    MUST do 1 of {H.264, VP8, H.263, H.261}
    MUST do 2 of {H.264, VP8, H.263, H.261}
    MUST do 3 of {H.26=
4, VP8, H.263, H.261}
    



    MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
    MUST do 2 of=
 {H.264, VP8, H.263, H.261, Theora}
    MUST do 3 of {H.264, VP8, H.2=
63, H.261, Theora}
    MUST do 4 of {H.264, VP8, H.263, H.261, Theora=
}
    








    =



    On Thu,=
 Nov 21, 2013 at 11:27 AM, Cullen Jennings <fluffy@iii.ca> wrote=
:
    




    
Added a
    

    
#11 =A0 =A0 =95 MUST implement at least two of {VP8, H.264 CBP, H.263}
    


    

    
On Nov 21, 2013, at 11:20 AM, David Singer <singer@apple.com> wrote:
    

    
> Chairs
    
>
    
> can we add this as an option to the formal list, so we get formal feed=
back on its acceptability, please?
    
>
    
> =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
    
>
    
>
    
> I think this may be the best (maybe only) way to tease out how much ri=
sk people perceive.
    
>
    
> Many thanks
    
>
    
> On Nov 21, 2013, at 9:22 , Maik Merten <maikmerten@googlemail.com> wrote=
:
    
>
    
>> Cleary H.263 is preferable from an engineering standpoint (as is, =
e.g., MPEG-1 Part 2): better performance, more deployments. The central que=
stion is, however, if those can actually be implemented without some sort o=
f licensing.
    



>>
    
>> If they can: Aweseome! However, this may not be determinable witho=
ut a review by people who are knowledgeable in the field of IPR, i.e., &quo=
t;actual lawyers". I understand that H.263 is not yet old enough to au=
tomatically be considered "safe" (and neither is MPEG-1 Part 2, a=
lthough it is closer).
    



>>
    
>> Best regards,
    
>>
    
>> Maik
    
>>
    
>> Am 20.11.2013 20:42, schrieb David Singer:
    
>>> I think we should think hard about H.263 instead of H.261 as t=
he third fallback. =A0Why?
    
>>>
    
>>> http://www.itu.int/rec/T-REC-H.263/
    
>>>
    
>>>
    
>>>
    
>>> H.263 was first published in March 1996, so it's 17 years =
old. =A0The restrictions (e.g. on picture size) are no WORSE than H.261. =
=A0Yes, more recent amendments deal with this (and a plethora of other issu=
es), so we=92d need to settle on which of those are mandatory (the usual pr=
ofiling discussion).
    



>>>
    
>>> There are 34 records in the patent database against H.261, mos=
tly from 1989 but one as recent as 2005 (though that is a re-file). =A0That=
's 2.2 (reciprocity), as was one other I checked.
    
>>>
    
>>> Rather surprisingly, there are only 31 against H.263! =A0The m=
ost recent is 2011, and is also option 2. =A0Most are 1997-2001.
    
>>>
    
>>>
    
>>> On this quick glance, H.263 appears no worse than H.261. IANAL=
 (as I am sure you have all noticed).
    
>>>
    
>>>
    
>>> H.263 is much more widely supported and mandated. =A0It has be=
en mandated in the 3GPP specs for years (for lots of services, including vi=
deoconf), and is effectively the fallback codec today in the industry, as I=
 understand. =A0It was ubiquitous in video telephony for years, and I suspe=
ct many of those systems still ship it.
    



>>>
    
>>> So, would =93MUST implement at least two of (H.264, VP8, H.263=
)=94 work?
    
>>>
    
>>> (I am asking the question, not even answering on behalf of my =
company, yet. =A0Let=92s get the issues on the table.)
    
>>>
    
>>>
    
>>> David Singer
    
>>> Multimedia and Software Standards, Apple Inc.
    
>>>
    
>>> _______________________________________________
    
>>> rtcweb mailing list
    
>>> rtcweb@ie=
tf.org
    
>>> https://www.ietf.org/mailman/listinfo/rtcweb
    
>>>
    
>>
    
>> _______________________________________________
    
>> rtcweb mailing list
    
>> rtcweb@ietf.o=
rg
    
>> https://www.ietf.org/mailman/listinfo/rtcweb
    
>
    
> David Singer
    
> Multimedia and Software Standards, Apple Inc.
    
>
    
> _______________________________________________
    
> 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
    


    

--001a1134d2dad6c01e04ebb560e0--


From martin.thomson@gmail.com  Thu Nov 21 12:06:23 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00BD1AE289 for ; Thu, 21 Nov 2013 12:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2pouPXL_hKP for ; Thu, 21 Nov 2013 12:06:22 -0800 (PST)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6DF1AE092 for ; Thu, 21 Nov 2013 12:06:22 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id q59so260393wes.27 for ; Thu, 21 Nov 2013 12:06:15 -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=QPRdhiIMDOgTRz6uFtPX+lFXTG3wOIo0+VdLlI35ssY=; b=Dol5CdJ1+p715P+rufPalUdT4hcKWpMnRFw5dCnsj7d9AV7GzcbI1WojHabfU+wVmG LOdLA+uxT0XdXOCydOH67CfN1bXYQGCvplcv3yCztUGnCQs7wLhrMaunEonENuqeSTp8 H6AN1lb5FiwJWKRVHG+P6+A53+wHiRB1YYtNOjpXpNyhLECTgcijpFhGqNuhC2yvI8vs owsrgXUoLYanir1cegOwKwt25VxuqGHCrJQc77gnDQPOE9idDnDv9PevZm9TPdHsEdlm BGyqRx7Py1vogf3dohIfFijk1jYPb8lE6P46U0gqzV4LxkvCFW21EV9wyerP3XpdOEPH Xuig==
MIME-Version: 1.0
X-Received: by 10.180.208.49 with SMTP id mb17mr31606226wic.64.1385064375027;  Thu, 21 Nov 2013 12:06:15 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Thu, 21 Nov 2013 12:06:14 -0800 (PST)
In-Reply-To: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>  
Date: Thu, 21 Nov 2013 12:06:14 -0800
Message-ID: 
From: Martin Thomson 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:06:23 -0000

On 21 November 2013 12:01, Eric Rescorla  wrote:
> I would like to propose some additional alternatives.

I notice that RFC 4235 and RFC 4715 are absent from that list.  Both
have been raised on the list before.  Why not include those as well?

From sslivinski@lifesize.com  Thu Nov 21 12:06:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82011AE2AB for ; Thu, 21 Nov 2013 12:06:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mt45wKkL9W1 for ; Thu, 21 Nov 2013 12:06:37 -0800 (PST)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id A77621AE289 for ; Thu, 21 Nov 2013 12:06:37 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUo5nxw6kT2AXCrJ5a2x6QtVB+ktsvGjT@postini.com; Thu, 21 Nov 2013 12:06:31 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 14:02:38 -0600
From: Stefan Slivinski 
To: "'rtcweb@ietf.org'" 
Date: Thu, 21 Nov 2013 14:02:37 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7m88vU75kinTTXTl+N5uM4vUQpkQAANQn3
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <528E656F.2070404@librevideo.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:06:39 -0000

I in no way intended to suggest  a specific implementation of a video codec=
.  My question was around whether we are voting on requiring decoders (my a=
ssumption) or both encoders and decoders


----- Original Message -----
From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
Sent: Thursday, November 21, 2013 01:56 PM=0A=
To: rtcweb@ietf.org 
Subject: Re: [rtcweb] Proposed Video Selection Process

On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
> I'm a new comer, so just a brief intro: I have a background developing re=
al time video codecs for embedded devices so I'm in a position to comment a=
t a technical level within this group
>=20
> For clarity purposes the proposed alternatives in Magnus' email on nov 18=
th; are we strictly speaking about decoders?  Historically mandatory requir=
ements are they relate to video compatibility define just the decoders.  Ob=
viously if there is only a single mandatory video decoder this implies a ma=
ndatory encoder, however in the case where there are 2 mandatory decoders o=
nly a single encoder is technically required.
>=20
> Clarifying this is fairly important because in the case of both h264 and =
vp8 (and in the future vp9 and h265) the decoder complexity is fairly low a=
nd hardware acceleration is not critical but in the case of the encoders wh=
ere the complexity can be 3x or worse, hardware acceleration becomes increa=
singly important
>=20
> Stefan

What is being specified as MTI is a format, and not a specific
implementation.  So, MTI will not take the form of "OpenH264" or
"libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8".

The same was done for the MTI audio codec, which is Opus, not *libopus*,
which is one specific implementation of the codec.

There was a suggestion that the WG also offer a reference implementation
of the MTI codec choice, but that seems like it won't happen, nor is it
really the purpose of the WG to do so.  We are picking from
already-existing and implemented formats in the first place.

--=20
Libre Video
http://librevideo.org
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

From sslivinski@lifesize.com  Thu Nov 21 12:09:57 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8A01AE24C for ; Thu, 21 Nov 2013 12:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBvEfnSRpqOa for ; Thu, 21 Nov 2013 12:09:55 -0800 (PST)
Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with SMTP id DE7A31AE1CE for ; Thu, 21 Nov 2013 12:09:54 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKUo5ojBinheOr2+VQbDKbqPsZxZDWkfiA@postini.com; Thu, 21 Nov 2013 12:09:48 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 14:05:04 -0600
From: Stefan Slivinski 
To: "'rtcweb@ietf.org'" 
Date: Thu, 21 Nov 2013 14:05:03 -0600
Thread-Topic: [rtcweb] VP8 / H.264 conversion without transcoding
Thread-Index: Ac7m9HWkPD64F/ekQAiU7Jpu17L52gAAIFU5
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7DE@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:09:57 -0000

The primary advantage you get from this technique is the ability to skip or=
 dramatically reduce motion estimation on the encoder.  The algorithms are =
similar at a high level but different enough at a low level to make a light=
 weight transcoder impossible


----- Original Message -----
From: Monty Montgomery [mailto:xiphmont@gmail.com]
Sent: Thursday, November 21, 2013 02:00 PM=0A=
To: Bossiel 
Cc: rtcweb@ietf.org 
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding

On Thu, Nov 21, 2013 at 2:49 PM, Bossiel  wrote:
> Entropy decoding (CABAC/CAVLC) must be done to get the macroblock
> structure(partirions, motion vectors...) and residual (AC/DC coeffs). The
> only part you're skiping is the inverse transform, scaling and motion
> compensation.

You wouldn't even be skipping the inverse transform.  VP8 and h.264
don't use the same DCT, so you'd have to do an inverse to track
transform error propagation, which won't be the same in the two
codecs.  Unless, of course, something else rather clever is going
on...

Monty
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

From john@jlc.net  Thu Nov 21 12:11:37 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72221AE1CE for ; Thu, 21 Nov 2013 12:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.725
X-Spam-Level: 
X-Spam-Status: No, score=-6.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scneDjK6C62Q for ; Thu, 21 Nov 2013 12:11:29 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 05DD51AE19C for ; Thu, 21 Nov 2013 12:11:29 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id E63E5C94BF; Thu, 21 Nov 2013 15:11:19 -0500 (EST)
Date: Thu, 21 Nov 2013 15:11:19 -0500
From: John Leslie 
To: Peter Saint-Andre 
Message-ID: <20131121201119.GA59496@verdi>
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <528E5057.30408@stpeter.im>
User-Agent: Mutt/1.4.1i
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:11:38 -0000

Peter Saint-Andre  wrote:
> 
> I have the greatest respect for the chairs, but this is an engraved
> invitation for people to appeal whatever decision might be reached.
> 
> More fundamentally: Voting? At the IETF?? Really?!?
> 
> I sincerely hope we can figure out a better process...

   +1

====

   Additionally, if we are to follow a voting process, we must publish
a list of voters and invent some process to challenge who is included
and who is omitted. This is NOT trivial.

--
John Leslie 

From stevek@stevek.com  Thu Nov 21 12:14:30 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D70D1AE275 for ; Thu, 21 Nov 2013 12:14:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXXuIo_NEVj3 for ; Thu, 21 Nov 2013 12:14:25 -0800 (PST)
Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 050BF1AE18E for ; Thu, 21 Nov 2013 12:14:24 -0800 (PST)
Received: by mail-pa0-f52.google.com with SMTP id ld10so244222pab.39 for ; Thu, 21 Nov 2013 12:14:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=KAqzIlRj67eW3dRMBZ6nx58ei9+y2Z59wlcZ/6Rmonc=; b=Q2KZYh77oi0+jU1JUyTyNbxq+W9dClBBKiDNP4JY5M7fwuQwnkrdr7DvyGydhBXRUH ZBGfjVPx1iAPqKOofQ5+XUkOP+hip9idQuDzg2U7GXhRBt60jFvFzm9LVSQQVu3XQdQj cs5xqGvvcJ0bPIn5bo9NcLt32bLt8iyBxJzxKf/FCc3LpzyAs9j6ImNwDgTWmgEaPRd4 ephv0w6v060LG3Urg8MIDGIGJh+/V+Wi5zrVB0poAn+Wo7VioIk0sK0+QGaTpHBv5Ape kgvGP0gmzUa/UjKmNlrwuRvjF/y/m4XzIAwW3/1q2VLJWkZPd/6ssYMOaO2Nx+pSS8SJ yGww==
X-Gm-Message-State: ALoCoQlnWTJ932a6pdoDQK9FK4pjt8H6Gikt4aRPacVLhpOlpcvUdcvuAC7yRa+1Wt9fk2D/xwTi
X-Received: by 10.68.143.231 with SMTP id sh7mr8166513pbb.35.1385064858238; Thu, 21 Nov 2013 12:14:18 -0800 (PST)
Received: from [10.149.80.145] (mobile-166-137-186-220.mycingular.net. [166.137.186.220]) by mx.google.com with ESMTPSA id hz10sm47992609pbc.36.2013.11.21.12.14.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 12:14:17 -0800 (PST)
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>  
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-AC553157-4237-482E-AF9B-E05D8547CDFA
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (11B554a)
From: Steve Kann 
Date: Thu, 21 Nov 2013 12:14:15 -0800
To: Eric Rescorla 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:14:30 -0000

--Apple-Mail-AC553157-4237-482E-AF9B-E05D8547CDFA
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Do you plan to open-source your codec option generator?   It would make modi=
fying the list much more efficient.=20






-Sent from an iOS mobile device

> On Nov 21, 2013, at 12:01 PM, Eric Rescorla  wrote:
>=20
> I would like to propose some additional alternatives.
>=20
> SHOULD: Theora
> MUST: Theora
> SHOULD: H.261
> SHOULD: H.261 Theora
> MUST: Theora; SHOULD: H.261
> MUST: H.261
> MUST: H.261; SHOULD: Theora
> MUST: H.261 Theora
> SHOULD: H.263
> SHOULD: H.263 Theora
> MUST: Theora; SHOULD: H.263
> SHOULD: H.263 H.261
> SHOULD: H.263 H.261 Theora
> MUST: Theora; SHOULD: H.263 H.261
> MUST: H.261; SHOULD: H.263
> MUST: H.261; SHOULD: H.263 Theora
> MUST: H.261 Theora; SHOULD: H.263
> MUST: H.263
> MUST: H.263; SHOULD: Theora
> MUST: H.263 Theora
> MUST: H.263; SHOULD: H.261
> MUST: H.263; SHOULD: H.261 Theora
> MUST: H.263 Theora; SHOULD: H.261
> MUST: H.263 H.261
> MUST: H.263 H.261; SHOULD: Theora
> MUST: H.263 H.261 Theora
> SHOULD: VP8
> SHOULD: VP8 Theora
> MUST: Theora; SHOULD: VP8
> SHOULD: VP8 H.261
> SHOULD: VP8 H.261 Theora
> MUST: Theora; SHOULD: VP8 H.261
> MUST: H.261; SHOULD: VP8
> MUST: H.261; SHOULD: VP8 Theora
> MUST: H.261 Theora; SHOULD: VP8
> SHOULD: VP8 H.263
> SHOULD: VP8 H.263 Theora
> MUST: Theora; SHOULD: VP8 H.263
> SHOULD: VP8 H.263 H.261
> SHOULD: VP8 H.263 H.261 Theora
> MUST: Theora; SHOULD: VP8 H.263 H.261
> MUST: H.261; SHOULD: VP8 H.263
> MUST: H.261; SHOULD: VP8 H.263 Theora
> MUST: H.261 Theora; SHOULD: VP8 H.263
> MUST: H.263; SHOULD: VP8
> MUST: H.263; SHOULD: VP8 Theora
> MUST: H.263 Theora; SHOULD: VP8
> MUST: H.263; SHOULD: VP8 H.261
> MUST: H.263; SHOULD: VP8 H.261 Theora
> MUST: H.263 Theora; SHOULD: VP8 H.261
> MUST: H.263 H.261; SHOULD: VP8
> MUST: H.263 H.261; SHOULD: VP8 Theora
> MUST: H.263 H.261 Theora; SHOULD: VP8
> MUST: VP8
> MUST: VP8; SHOULD: Theora
> MUST: VP8 Theora
> MUST: VP8; SHOULD: H.261
> MUST: VP8; SHOULD: H.261 Theora
> MUST: VP8 Theora; SHOULD: H.261
> MUST: VP8 H.261
> MUST: VP8 H.261; SHOULD: Theora
> MUST: VP8 H.261 Theora
> MUST: VP8; SHOULD: H.263
> MUST: VP8; SHOULD: H.263 Theora
> MUST: VP8 Theora; SHOULD: H.263
> MUST: VP8; SHOULD: H.263 H.261
> MUST: VP8; SHOULD: H.263 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.263 H.261
> MUST: VP8 H.261; SHOULD: H.263
> MUST: VP8 H.261; SHOULD: H.263 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.263
> MUST: VP8 H.263
> MUST: VP8 H.263; SHOULD: Theora
> MUST: VP8 H.263 Theora
> MUST: VP8 H.263; SHOULD: H.261
> MUST: VP8 H.263; SHOULD: H.261 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.261
> MUST: VP8 H.263 H.261
> MUST: VP8 H.263 H.261; SHOULD: Theora
> MUST: VP8 H.263 H.261 Theora
> SHOULD: H.264
> SHOULD: H.264 Theora
> MUST: Theora; SHOULD: H.264
> SHOULD: H.264 H.261
> SHOULD: H.264 H.261 Theora
> MUST: Theora; SHOULD: H.264 H.261
> MUST: H.261; SHOULD: H.264
> MUST: H.261; SHOULD: H.264 Theora
> MUST: H.261 Theora; SHOULD: H.264
> SHOULD: H.264 H.263
> SHOULD: H.264 H.263 Theora
> MUST: Theora; SHOULD: H.264 H.263
> SHOULD: H.264 H.263 H.261
> SHOULD: H.264 H.263 H.261 Theora
> MUST: Theora; SHOULD: H.264 H.263 H.261
> MUST: H.261; SHOULD: H.264 H.263
> MUST: H.261; SHOULD: H.264 H.263 Theora
> MUST: H.261 Theora; SHOULD: H.264 H.263
> MUST: H.263; SHOULD: H.264
> MUST: H.263; SHOULD: H.264 Theora
> MUST: H.263 Theora; SHOULD: H.264
> MUST: H.263; SHOULD: H.264 H.261
> MUST: H.263; SHOULD: H.264 H.261 Theora
> MUST: H.263 Theora; SHOULD: H.264 H.261
> MUST: H.263 H.261; SHOULD: H.264
> MUST: H.263 H.261; SHOULD: H.264 Theora
> MUST: H.263 H.261 Theora; SHOULD: H.264
> SHOULD: H.264 VP8
> SHOULD: H.264 VP8 Theora
> MUST: Theora; SHOULD: H.264 VP8
> SHOULD: H.264 VP8 H.261
> SHOULD: H.264 VP8 H.261 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.261
> MUST: H.261; SHOULD: H.264 VP8
> MUST: H.261; SHOULD: H.264 VP8 Theora
> MUST: H.261 Theora; SHOULD: H.264 VP8
> SHOULD: H.264 VP8 H.263
> SHOULD: H.264 VP8 H.263 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.263
> SHOULD: H.264 VP8 H.263 H.261
> SHOULD: H.264 VP8 H.263 H.261 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
> MUST: H.261; SHOULD: H.264 VP8 H.263
> MUST: H.261; SHOULD: H.264 VP8 H.263 Theora
> MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
> MUST: H.263; SHOULD: H.264 VP8
> MUST: H.263; SHOULD: H.264 VP8 Theora
> MUST: H.263 Theora; SHOULD: H.264 VP8
> MUST: H.263; SHOULD: H.264 VP8 H.261
> MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
> MUST: H.263 Theora; SHOULD: H.264 VP8 H.261
> MUST: H.263 H.261; SHOULD: H.264 VP8
> MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
> MUST: H.263 H.261 Theora; SHOULD: H.264 VP8
> MUST: VP8; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 Theora
> MUST: VP8 Theora; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 H.261
> MUST: VP8; SHOULD: H.264 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.261
> MUST: VP8 H.261; SHOULD: H.264
> MUST: VP8 H.261; SHOULD: H.264 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 H.263
> MUST: VP8; SHOULD: H.264 H.263 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.263
> MUST: VP8; SHOULD: H.264 H.263 H.261
> MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
> MUST: VP8 H.261; SHOULD: H.264 H.263
> MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.264 H.263
> MUST: VP8 H.263; SHOULD: H.264
> MUST: VP8 H.263; SHOULD: H.264 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.264
> MUST: VP8 H.263; SHOULD: H.264 H.261
> MUST: VP8 H.263; SHOULD: H.264 H.261 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
> MUST: VP8 H.263 H.261; SHOULD: H.264
> MUST: VP8 H.263 H.261; SHOULD: H.264 Theora
> MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
> MUST: H.264
> MUST: H.264; SHOULD: Theora
> MUST: H.264 Theora
> MUST: H.264; SHOULD: H.261
> MUST: H.264; SHOULD: H.261 Theora
> MUST: H.264 Theora; SHOULD: H.261
> MUST: H.264 H.261
> MUST: H.264 H.261; SHOULD: Theora
> MUST: H.264 H.261 Theora
> MUST: H.264; SHOULD: H.263
> MUST: H.264; SHOULD: H.263 Theora
> MUST: H.264 Theora; SHOULD: H.263
> MUST: H.264; SHOULD: H.263 H.261
> MUST: H.264; SHOULD: H.263 H.261 Theora
> MUST: H.264 Theora; SHOULD: H.263 H.261
> MUST: H.264 H.261; SHOULD: H.263
> MUST: H.264 H.261; SHOULD: H.263 Theora
> MUST: H.264 H.261 Theora; SHOULD: H.263
> MUST: H.264 H.263
> MUST: H.264 H.263; SHOULD: Theora
> MUST: H.264 H.263 Theora
> MUST: H.264 H.263; SHOULD: H.261
> MUST: H.264 H.263; SHOULD: H.261 Theora
> MUST: H.264 H.263 Theora; SHOULD: H.261
> MUST: H.264 H.263 H.261
> MUST: H.264 H.263 H.261; SHOULD: Theora
> MUST: H.264 H.263 H.261 Theora
> MUST: H.264; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 Theora
> MUST: H.264 Theora; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 H.261
> MUST: H.264; SHOULD: VP8 H.261 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.261
> MUST: H.264 H.261; SHOULD: VP8
> MUST: H.264 H.261; SHOULD: VP8 Theora
> MUST: H.264 H.261 Theora; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 H.263
> MUST: H.264; SHOULD: VP8 H.263 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.263
> MUST: H.264; SHOULD: VP8 H.263 H.261
> MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
> MUST: H.264 H.261; SHOULD: VP8 H.263
> MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
> MUST: H.264 H.261 Theora; SHOULD: VP8 H.263
> MUST: H.264 H.263; SHOULD: VP8
> MUST: H.264 H.263; SHOULD: VP8 Theora
> MUST: H.264 H.263 Theora; SHOULD: VP8
> MUST: H.264 H.263; SHOULD: VP8 H.261
> MUST: H.264 H.263; SHOULD: VP8 H.261 Theora
> MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
> MUST: H.264 H.263 H.261; SHOULD: VP8
> MUST: H.264 H.263 H.261; SHOULD: VP8 Theora
> MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
> MUST: H.264 VP8
> MUST: H.264 VP8; SHOULD: Theora
> MUST: H.264 VP8 Theora
> MUST: H.264 VP8; SHOULD: H.261
> MUST: H.264 VP8; SHOULD: H.261 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.261
> MUST: H.264 VP8 H.261
> MUST: H.264 VP8 H.261; SHOULD: Theora
> MUST: H.264 VP8 H.261 Theora
> MUST: H.264 VP8; SHOULD: H.263
> MUST: H.264 VP8; SHOULD: H.263 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.263
> MUST: H.264 VP8; SHOULD: H.263 H.261
> MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
> MUST: H.264 VP8 H.261; SHOULD: H.263
> MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
> MUST: H.264 VP8 H.261 Theora; SHOULD: H.263
> MUST: H.264 VP8 H.263
> MUST: H.264 VP8 H.263; SHOULD: Theora
> MUST: H.264 VP8 H.263 Theora
> MUST: H.264 VP8 H.263; SHOULD: H.261
> MUST: H.264 VP8 H.263; SHOULD: H.261 Theora
> MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
> MUST: H.264 VP8 H.263 H.261
> MUST: H.264 VP8 H.263 H.261; SHOULD: Theora
> MUST: H.264 VP8 H.263 H.261 Theora
> SHOULD do 1 of {H.261, Theora}
> SHOULD do 1 of {H.263, Theora}
> SHOULD do 1 of {H.263, H.261}
> SHOULD do 1 of {H.263, H.261, Theora}
> SHOULD do 2 of {H.263, H.261, Theora}
> SHOULD do 1 of {VP8, Theora}
> SHOULD do 1 of {VP8, H.261}
> SHOULD do 1 of {VP8, H.261, Theora}
> SHOULD do 2 of {VP8, H.261, Theora}
> SHOULD do 1 of {VP8, H.263}
> SHOULD do 1 of {VP8, H.263, Theora}
> SHOULD do 2 of {VP8, H.263, Theora}
> SHOULD do 1 of {VP8, H.263, H.261}
> SHOULD do 2 of {VP8, H.263, H.261}
> SHOULD do 1 of {VP8, H.263, H.261, Theora}
> SHOULD do 2 of {VP8, H.263, H.261, Theora}
> SHOULD do 3 of {VP8, H.263, H.261, Theora}
> SHOULD do 1 of {H.264, Theora}
> SHOULD do 1 of {H.264, H.261}
> SHOULD do 1 of {H.264, H.261, Theora}
> SHOULD do 2 of {H.264, H.261, Theora}
> SHOULD do 1 of {H.264, H.263}
> SHOULD do 1 of {H.264, H.263, Theora}
> SHOULD do 2 of {H.264, H.263, Theora}
> SHOULD do 1 of {H.264, H.263, H.261}
> SHOULD do 2 of {H.264, H.263, H.261}
> SHOULD do 1 of {H.264, H.263, H.261, Theora}
> SHOULD do 2 of {H.264, H.263, H.261, Theora}
> SHOULD do 3 of {H.264, H.263, H.261, Theora}
> SHOULD do 1 of {H.264, VP8}
> SHOULD do 1 of {H.264, VP8, Theora}
> SHOULD do 2 of {H.264, VP8, Theora}
> SHOULD do 1 of {H.264, VP8, H.261}
> SHOULD do 2 of {H.264, VP8, H.261}
> SHOULD do 1 of {H.264, VP8, H.261, Theora}
> SHOULD do 2 of {H.264, VP8, H.261, Theora}
> SHOULD do 3 of {H.264, VP8, H.261, Theora}
> SHOULD do 1 of {H.264, VP8, H.263}
> SHOULD do 2 of {H.264, VP8, H.263}
> SHOULD do 1 of {H.264, VP8, H.263, Theora}
> SHOULD do 2 of {H.264, VP8, H.263, Theora}
> SHOULD do 3 of {H.264, VP8, H.263, Theora}
> SHOULD do 1 of {H.264, VP8, H.263, H.261}
> SHOULD do 2 of {H.264, VP8, H.263, H.261}
> SHOULD do 3 of {H.264, VP8, H.263, H.261}
> SHOULD do 1 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 3 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 4 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 1 of {H.261, Theora}
> MUST do 1 of {H.263, Theora}
> MUST do 1 of {H.263, H.261}
> MUST do 1 of {H.263, H.261, Theora}
> MUST do 2 of {H.263, H.261, Theora}
> MUST do 1 of {VP8, Theora}
> MUST do 1 of {VP8, H.261}
> MUST do 1 of {VP8, H.261, Theora}
> MUST do 2 of {VP8, H.261, Theora}
> MUST do 1 of {VP8, H.263}
> MUST do 1 of {VP8, H.263, Theora}
> MUST do 2 of {VP8, H.263, Theora}
> MUST do 1 of {VP8, H.263, H.261}
> MUST do 2 of {VP8, H.263, H.261}
> MUST do 1 of {VP8, H.263, H.261, Theora}
> MUST do 2 of {VP8, H.263, H.261, Theora}
> MUST do 3 of {VP8, H.263, H.261, Theora}
> MUST do 1 of {H.264, Theora}
> MUST do 1 of {H.264, H.261}
> MUST do 1 of {H.264, H.261, Theora}
> MUST do 2 of {H.264, H.261, Theora}
> MUST do 1 of {H.264, H.263}
> MUST do 1 of {H.264, H.263, Theora}
> MUST do 2 of {H.264, H.263, Theora}
> MUST do 1 of {H.264, H.263, H.261}
> MUST do 2 of {H.264, H.263, H.261}
> MUST do 1 of {H.264, H.263, H.261, Theora}
> MUST do 2 of {H.264, H.263, H.261, Theora}
> MUST do 3 of {H.264, H.263, H.261, Theora}
> MUST do 1 of {H.264, VP8}
> MUST do 1 of {H.264, VP8, Theora}
> MUST do 2 of {H.264, VP8, Theora}
> MUST do 1 of {H.264, VP8, H.261}
> MUST do 2 of {H.264, VP8, H.261}
> MUST do 1 of {H.264, VP8, H.261, Theora}
> MUST do 2 of {H.264, VP8, H.261, Theora}
> MUST do 3 of {H.264, VP8, H.261, Theora}
> MUST do 1 of {H.264, VP8, H.263}
> MUST do 2 of {H.264, VP8, H.263}
> MUST do 1 of {H.264, VP8, H.263, Theora}
> MUST do 2 of {H.264, VP8, H.263, Theora}
> MUST do 3 of {H.264, VP8, H.263, Theora}
> MUST do 1 of {H.264, VP8, H.263, H.261}
> MUST do 2 of {H.264, VP8, H.263, H.261}
> MUST do 3 of {H.264, VP8, H.263, H.261}
> MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 2 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 3 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 4 of {H.264, VP8, H.263, H.261, Theora}
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>> On Thu, Nov 21, 2013 at 11:27 AM, Cullen Jennings  wrote:
>>=20
>> Added a
>>=20
>> #11     =E2=80=A2 MUST implement at least two of {VP8, H.264 CBP, H.263}
>>=20
>>=20
>> On Nov 21, 2013, at 11:20 AM, David Singer  wrote:
>>=20
>> > Chairs
>> >
>> > can we add this as an option to the formal list, so we get formal feedb=
ack on its acceptability, please?
>> >
>> > =E2=80=9CLike option ??, pick at least two of {VP8, H.264 CBP, H.263}=E2=
=80=9D
>> >
>> >
>> > I think this may be the best (maybe only) way to tease out how much ris=
k people perceive.
>> >
>> > Many thanks
>> >
>> > On Nov 21, 2013, at 9:22 , Maik Merten  wrot=
e:
>> >
>> >> Cleary H.263 is preferable from an engineering standpoint (as is, e.g.=
, MPEG-1 Part 2): better performance, more deployments. The central question=
 is, however, if those can actually be implemented without some sort of lice=
nsing.
>> >>
>> >> If they can: Aweseome! However, this may not be determinable without a=
 review by people who are knowledgeable in the field of IPR, i.e., "actual l=
awyers". I understand that H.263 is not yet old enough to automatically be c=
onsidered "safe" (and neither is MPEG-1 Part 2, although it is closer).
>> >>
>> >> Best regards,
>> >>
>> >> Maik
>> >>
>> >> Am 20.11.2013 20:42, schrieb David Singer:
>> >>> I think we should think hard about H.263 instead of H.261 as the thir=
d fallback.  Why?
>> >>>
>> >>> http://www.itu.int/rec/T-REC-H.263/
>> >>>
>> >>>
>> >>>
>> >>> H.263 was first published in March 1996, so it's 17 years old.  The r=
estrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more recen=
t amendments deal with this (and a plethora of other issues), so we=E2=80=99=
d need to settle on which of those are mandatory (the usual profiling discus=
sion).
>> >>>
>> >>> There are 34 records in the patent database against H.261, mostly fro=
m 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2 (re=
ciprocity), as was one other I checked.
>> >>>
>> >>> Rather surprisingly, there are only 31 against H.263!  The most recen=
t is 2011, and is also option 2.  Most are 1997-2001.
>> >>>
>> >>>
>> >>> On this quick glance, H.263 appears no worse than H.261. IANAL (as I a=
m sure you have all noticed).
>> >>>
>> >>>
>> >>> H.263 is much more widely supported and mandated.  It has been mandat=
ed in the 3GPP specs for years (for lots of services, including videoconf), a=
nd is effectively the fallback codec today in the industry, as I understand.=
  It was ubiquitous in video telephony for years, and I suspect many of thos=
e systems still ship it.
>> >>>
>> >>> So, would =E2=80=9CMUST implement at least two of (H.264, VP8, H.263)=
=E2=80=9D work?
>> >>>
>> >>> (I am asking the question, not even answering on behalf of my company=
, yet.  Let=E2=80=99s get the issues on the table.)
>> >>>
>> >>>
>> >>> David Singer
>> >>> Multimedia and Software Standards, Apple Inc.
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> > David Singer
>> > Multimedia and Software Standards, Apple Inc.
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

--Apple-Mail-AC553157-4237-482E-AF9B-E05D8547CDFA
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



    Do you plan to open-sou=
rce your codec option generator?   It would make modifying the list muc=
h more efficient. 






    -Sent from an iOS mobile device

    On Nov 21, 2013, at 12:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:

    I would like to propose some additional alternatives=
.

    SHOULD: Theora
    MUST: Theora
    SH=
OULD: H.261
    SHOULD: H.261 Theora
    MUST: Theora; SHOULD: H=
.261
    



    MUST: H.261
    MUST: H.261; SHOULD: Theora
    MUST: H.261=
 Theora
    SHOULD: H.263
    SHOULD: H.263 Theora
    MUS=
T: Theora; SHOULD: H.263
    SHOULD: H.263 H.261
    SHOULD: H.2=
63 H.261 Theora
    



    MUST: Theora; SHOULD: H.263 H.261
    MUST: H.261; SHOULD: H.263<=
/div>
    MUST: H.261; SHOULD: H.263 Theora
    MUST: H.261 Theora; SH=
OULD: H.263
    MUST: H.263
    MUST: H.263; SHOULD: Theora



    MUST: H.263 Theora
    MUST: H.263; SHOULD: H.261
    MUST:=
 H.263; SHOULD: H.261 Theora
    MUST: H.263 Theora; SHOULD: H.261
    MUST: H.263 H.261
    MUST: H.263 H.261; SHOULD: Theora
    



    MUST: H.263 H.261 Theora
    SHOULD: VP8
    SHOULD: VP8 Th=
eora
    MUST: Theora; SHOULD: VP8
    SHOULD: VP8 H.261
    SHOULD: VP8 H.261 Theora
    MUST: Theora; SHOULD: VP8 H.261
    



    MUST: H.261; SHOULD: VP8
    MUST: H.261; SHOULD: VP8 Theora
    MUST: H.261 Theora; SHOULD: VP8
    SHOULD: VP8 H.263
    =
SHOULD: VP8 H.263 Theora
    MUST: Theora; SHOULD: VP8 H.263
    



    SHOULD: VP8 H.263 H.261
    SHOULD: VP8 H.263 H.261 Theora
    <=
div>MUST: Theora; SHOULD: VP8 H.263 H.261
    MUST: H.261; SHOULD: VP8=
 H.263
    MUST: H.261; SHOULD: VP8 H.263 Theora
    MUST: H.261=
 Theora; SHOULD: VP8 H.263
    



    MUST: H.263; SHOULD: VP8
    MUST: H.263; SHOULD: VP8 Theora
    MUST: H.263 Theora; SHOULD: VP8
    MUST: H.263; SHOULD: VP8 H.2=
61
    MUST: H.263; SHOULD: VP8 H.261 Theora
    MUST: H.263 The=
ora; SHOULD: VP8 H.261
    



    MUST: H.263 H.261; SHOULD: VP8
    MUST: H.263 H.261; SHOULD: VP8=
 Theora
    MUST: H.263 H.261 Theora; SHOULD: VP8
    MUST: VP8<=
/div>
    MUST: VP8; SHOULD: Theora
    MUST: VP8 Theora
    


    
MUST: VP8; SHOULD: H.261
    MUST: VP8; SHOULD: H.261 Theora
    MUST: VP8 Theora; SHOULD: H.261
    MUST: VP8 H.261
    MUST: V=
P8 H.261; SHOULD: Theora
    MUST: VP8 H.261 Theora
    

MUST: VP8; SHOULD: H.263
    

    MUST: VP8; SHOULD: H.263 Theora
    MUST: VP8 Theora; SHOULD: H.2=
63
    MUST: VP8; SHOULD: H.263 H.261
    MUST: VP8; SHOULD: H.2=
63 H.261 Theora
    MUST: VP8 Theora; SHOULD: H.263 H.261
    



    MUST: VP8 H.261; SHOULD: H.263
    MUST: VP8 H.261; SHOULD: H.263=
 Theora
    MUST: VP8 H.261 Theora; SHOULD: H.263
    MUST: VP8 H=
.263
    MUST: VP8 H.263; SHOULD: Theora
    MUST: VP8 H.263 The=
ora
    



    MUST: VP8 H.263; SHOULD: H.261
    MUST: VP8 H.263; SHOULD: H.261=
 Theora
    MUST: VP8 H.263 Theora; SHOULD: H.261
    MUST: VP8 H=
.263 H.261
    MUST: VP8 H.263 H.261; SHOULD: Theora
    


MUST: VP8 H.263 H.261 Theora
    SHOULD: H.264
    SHOULD: H.264=
 Theora
    MUST: Theora; SHOULD: H.264
    SHOULD: H.264 H.261<=
/div>
    SHOULD: H.264 H.261 Theora
    MUST: Theora; SHOULD: H.264 H=
.261
    



    MUST: H.261; SHOULD: H.264
    MUST: H.261; SHOULD: H.264 Theora<=
/div>
    MUST: H.261 Theora; SHOULD: H.264
    SHOULD: H.264 H.263
    SHOULD: H.264 H.263 Theora
    MUST: Theora; SHOULD: H.264 H.2=
63
    



    SHOULD: H.264 H.263 H.261
    SHOULD: H.264 H.263 H.261 Theora
    MUST: Theora; SHOULD: H.264 H.263 H.261
    MUST: H.261; SHOUL=
D: H.264 H.263
    MUST: H.261; SHOULD: H.264 H.263 Theora
    



    MUST: H.261 Theora; SHOULD: H.264 H.263
    MUST: H.263; SHOULD: H=
.264
    MUST: H.263; SHOULD: H.264 Theora
    MUST: H.263 Theor=
a; SHOULD: H.264
    MUST: H.263; SHOULD: H.264 H.261
    


MUST: H.263; SHOULD: H.264 H.261 Theora
    MUST: H.263 Theora; SHOULD=
: H.264 H.261
    MUST: H.263 H.261; SHOULD: H.264
    MUST: H.2=
63 H.261; SHOULD: H.264 Theora
    MUST: H.263 H.261 Theora; SHOULD: H=
.264
    



    SHOULD: H.264 VP8
    SHOULD: H.264 VP8 Theora
    MUST: Th=
eora; SHOULD: H.264 VP8
    SHOULD: H.264 VP8 H.261
    SHOULD: H=
.264 VP8 H.261 Theora
    MUST: Theora; SHOULD: H.264 VP8 H.261
    



    MUST: H.261; SHOULD: H.264 VP8
    MUST: H.261; SHOULD: H.264 VP8=
 Theora
    MUST: H.261 Theora; SHOULD: H.264 VP8
    SHOULD: H.=
264 VP8 H.263
    SHOULD: H.264 VP8 H.263 Theora
    MUST: Theor=
a; SHOULD: H.264 VP8 H.263
    



    SHOULD: H.264 VP8 H.263 H.261
    SHOULD: H.264 VP8 H.263 H.261 T=
heora
    MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
    MUST: H=
.261; SHOULD: H.264 VP8 H.263
    MUST: H.261; SHOULD: H.264 VP8 H.263=
 Theora
    



    MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
    MUST: H.263; SHOU=
LD: H.264 VP8
    MUST: H.263; SHOULD: H.264 VP8 Theora
    MUST=
: H.263 Theora; SHOULD: H.264 VP8
    MUST: H.263; SHOULD: H.264 VP8 H=
.261
    



    MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
    MUST: H.263 Theor=
a; SHOULD: H.264 VP8 H.261
    MUST: H.263 H.261; SHOULD: H.264 VP8
    MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
    MUST: H.263 H.=
261 Theora; SHOULD: H.264 VP8
    



    MUST: VP8; SHOULD: H.264
    MUST: VP8; SHOULD: H.264 Theora
    MUST: VP8 Theora; SHOULD: H.264
    MUST: VP8; SHOULD: H.264 H.2=
61
    MUST: VP8; SHOULD: H.264 H.261 Theora
    MUST: VP8 Theor=
a; SHOULD: H.264 H.261
    



    MUST: VP8 H.261; SHOULD: H.264
    MUST: VP8 H.261; SHOULD: H.264=
 Theora
    MUST: VP8 H.261 Theora; SHOULD: H.264
    MUST: VP8;=
 SHOULD: H.264 H.263
    MUST: VP8; SHOULD: H.264 H.263 Theora
    



    MUST: VP8 Theora; SHOULD: H.264 H.263
    MUST: VP8; SHOULD: H.26=
4 H.263 H.261
    MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
    MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
    MUST: VP8 H.261; SHO=
ULD: H.264 H.263
    



    MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
    MUST: VP8 H.261 T=
heora; SHOULD: H.264 H.263
    MUST: VP8 H.263; SHOULD: H.264
    MUST: VP8 H.263; SHOULD: H.264 Theora
    MUST: VP8 H.263 Theora; SH=
OULD: H.264
    



    MUST: VP8 H.263; SHOULD: H.264 H.261
    MUST: VP8 H.263; SHOULD:=
 H.264 H.261 Theora
    MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
    MUST: VP8 H.263 H.261; SHOULD: H.264
    MUST: VP8 H.263 H.261=
; SHOULD: H.264 Theora
    



    MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
    MUST: H.264
    =

    MUST: H.264; SHOULD: Theora
    MUST: H.264 Theora
    MUST=
: H.264; SHOULD: H.261
    MUST: H.264; SHOULD: H.261 Theora
    



    MUST: H.264 Theora; SHOULD: H.261
    MUST: H.264 H.261
    MUST: H.264 H.261; SHOULD: Theora
    MUST: H.264 H.261 Theora
    <=
div>MUST: H.264; SHOULD: H.263
    MUST: H.264; SHOULD: H.263 Theora



    MUST: H.264 Theora; SHOULD: H.263
    MUST: H.264; SHOULD: H.263 H=
.261
    MUST: H.264; SHOULD: H.263 H.261 Theora
    MUST: H.264=
 Theora; SHOULD: H.263 H.261
    MUST: H.264 H.261; SHOULD: H.263



    MUST: H.264 H.261; SHOULD: H.263 Theora
    MUST: H.264 H.261 The=
ora; SHOULD: H.263
    MUST: H.264 H.263
    MUST: H.264 H.263; S=
HOULD: Theora
    MUST: H.264 H.263 Theora
    MUST: H.264 H.263=
; SHOULD: H.261
    



    MUST: H.264 H.263; SHOULD: H.261 Theora
    MUST: H.264 H.263 The=
ora; SHOULD: H.261
    MUST: H.264 H.263 H.261
    MUST: H.264 H=
.263 H.261; SHOULD: Theora
    MUST: H.264 H.263 H.261 Theora
    



    MUST: H.264; SHOULD: VP8
    MUST: H.264; SHOULD: VP8 Theora
    MUST: H.264 Theora; SHOULD: VP8
    MUST: H.264; SHOULD: VP8 H.2=
61
    MUST: H.264; SHOULD: VP8 H.261 Theora
    MUST: H.264 The=
ora; SHOULD: VP8 H.261
    



    MUST: H.264 H.261; SHOULD: VP8
    MUST: H.264 H.261; SHOULD: VP8=
 Theora
    MUST: H.264 H.261 Theora; SHOULD: VP8
    MUST: H.26=
4; SHOULD: VP8 H.263
    MUST: H.264; SHOULD: VP8 H.263 Theora
    



    MUST: H.264 Theora; SHOULD: VP8 H.263
    MUST: H.264; SHOULD: VP=
8 H.263 H.261
    MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
    MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
    MUST: H.264 H.261; S=
HOULD: VP8 H.263
    



    MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
    MUST: H.264 H.261=
 Theora; SHOULD: VP8 H.263
    MUST: H.264 H.263; SHOULD: VP8
    MUST: H.264 H.263; SHOULD: VP8 Theora
    MUST: H.264 H.263 Theora; S=
HOULD: VP8
    



    MUST: H.264 H.263; SHOULD: VP8 H.261
    MUST: H.264 H.263; SHOUL=
D: VP8 H.261 Theora
    MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
    MUST: H.264 H.263 H.261; SHOULD: VP8
    MUST: H.264 H.263 H.2=
61; SHOULD: VP8 Theora
    



    MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
    MUST: H.264 VP8
    MUST: H.264 VP8; SHOULD: Theora
    MUST: H.264 VP8 Theora
    MUST: H.264 VP8; SHOULD: H.261
    MUST: H.264 VP8; SHOULD: H.=
261 Theora
    



    MUST: H.264 VP8 Theora; SHOULD: H.261
    MUST: H.264 VP8 H.261
    MUST: H.264 VP8 H.261; SHOULD: Theora
    MUST: H.264 VP8 H.2=
61 Theora
    MUST: H.264 VP8; SHOULD: H.263
    MUST: H.264 VP8=
; SHOULD: H.263 Theora
    



    MUST: H.264 VP8 Theora; SHOULD: H.263
    MUST: H.264 VP8; SHOULD=
: H.263 H.261
    MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
    MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
    MUST: H.264 VP8 H.26=
1; SHOULD: H.263
    



    MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
    MUST: H.264 VP8 H=
.261 Theora; SHOULD: H.263
    MUST: H.264 VP8 H.263
    MUST: H=
.264 VP8 H.263; SHOULD: Theora
    MUST: H.264 VP8 H.263 Theora
    



    MUST: H.264 VP8 H.263; SHOULD: H.261
    MUST: H.264 VP8 H.263; S=
HOULD: H.261 Theora
    MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
    MUST: H.264 VP8 H.263 H.261
    MUST: H.264 VP8 H.263 H.261; S=
HOULD: Theora
    



    MUST: H.264 VP8 H.263 H.261 Theora
    SHOULD do 1 of {H.261, The=
ora}
    SHOULD do 1 of {H.263, Theora}
    SHOULD do 1 of {H.26=
3, H.261}
    SHOULD do 1 of {H.263, H.261, Theora}
    

SHOULD do 2 of {H.263, H.261, Theora}
    

    SHOULD do 1 of {VP8, Theora}
    SHOULD do 1 of {VP8, H.261}
    SHOULD do 1 of {VP8, H.261, Theora}
    SHOULD do 2 of {VP8, H.2=
61, Theora}
    SHOULD do 1 of {VP8, H.263}
    SHOULD do 1 of {=
VP8, H.263, Theora}
    



    SHOULD do 2 of {VP8, H.263, Theora}
    SHOULD do 1 of {VP8, H.26=
3, H.261}
    SHOULD do 2 of {VP8, H.263, H.261}
    SHOULD do 1=
 of {VP8, H.263, H.261, Theora}
    SHOULD do 2 of {VP8, H.263, H.261,=
 Theora}
    



    SHOULD do 3 of {VP8, H.263, H.261, Theora}
    SHOULD do 1 of {H.=
264, Theora}
    SHOULD do 1 of {H.264, H.261}
    SHOULD do 1 o=
f {H.264, H.261, Theora}
    SHOULD do 2 of {H.264, H.261, Theora}



    SHOULD do 1 of {H.264, H.263}
    SHOULD do 1 of {H.264, H.263, T=
heora}
    SHOULD do 2 of {H.264, H.263, Theora}
    SHOULD do 1=
 of {H.264, H.263, H.261}
    SHOULD do 2 of {H.264, H.263, H.261}



    SHOULD do 1 of {H.264, H.263, H.261, Theora}
    SHOULD do 2 of {=
H.264, H.263, H.261, Theora}
    SHOULD do 3 of {H.264, H.263, H.261, T=
heora}
    SHOULD do 1 of {H.264, VP8}
    SHOULD do 1 of {H.264=
, VP8, Theora}
    



    SHOULD do 2 of {H.264, VP8, Theora}
    SHOULD do 1 of {H.264, VP=
8, H.261}
    SHOULD do 2 of {H.264, VP8, H.261}
    SHOULD do 1=
 of {H.264, VP8, H.261, Theora}
    SHOULD do 2 of {H.264, VP8, H.261,=
 Theora}
    



    SHOULD do 3 of {H.264, VP8, H.261, Theora}
    SHOULD do 1 of {H.=
264, VP8, H.263}
    SHOULD do 2 of {H.264, VP8, H.263}
    SHOU=
LD do 1 of {H.264, VP8, H.263, Theora}
    SHOULD do 2 of {H.264, VP8,=
 H.263, Theora}
    



    SHOULD do 3 of {H.264, VP8, H.263, Theora}
    SHOULD do 1 of {H.=
264, VP8, H.263, H.261}
    SHOULD do 2 of {H.264, VP8, H.263, H.261}<=
/div>
    SHOULD do 3 of {H.264, VP8, H.263, H.261}
    SHOULD do 1 of=
 {H.264, VP8, H.263, H.261, Theora}
    



    SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
    SHOULD do 3=
 of {H.264, VP8, H.263, H.261, Theora}
    SHOULD do 4 of {H.264, VP8,=
 H.263, H.261, Theora}
    MUST do 1 of {H.261, Theora}
    


MUST do 1 of {H.263, Theora}
    MUST do 1 of {H.263, H.261}
    MUST do 1 of {H.263, H.261, Theora}
    MUST do 2 of {H.263, H.261, T=
heora}
    MUST do 1 of {VP8, Theora}
    MUST do 1 of {VP8, H.2=
61}
    



    MUST do 1 of {VP8, H.261, Theora}
    MUST do 2 of {VP8, H.261, T=
heora}
    MUST do 1 of {VP8, H.263}
    MUST do 1 of {VP8, H.26=
3, Theora}
    MUST do 2 of {VP8, H.263, Theora}
    MUST do 1 o=
f {VP8, H.263, H.261}
    



    MUST do 2 of {VP8, H.263, H.261}
    MUST do 1 of {VP8, H.263, H.=
261, Theora}
    MUST do 2 of {VP8, H.263, H.261, Theora}
    MU=
ST do 3 of {VP8, H.263, H.261, Theora}
    MUST do 1 of {H.264, Theora=
}
    



    MUST do 1 of {H.264, H.261}
    MUST do 1 of {H.264, H.261, Theor=
a}
    MUST do 2 of {H.264, H.261, Theora}
    MUST do 1 of {H.2=
64, H.263}
    MUST do 1 of {H.264, H.263, Theora}
    MUST do 2=
 of {H.264, H.263, Theora}
    



    MUST do 1 of {H.264, H.263, H.261}
    MUST do 2 of {H.264, H.263=
, H.261}
    MUST do 1 of {H.264, H.263, H.261, Theora}
    MUST=
 do 2 of {H.264, H.263, H.261, Theora}
    MUST do 3 of {H.264, H.263,=
 H.261, Theora}
    



    MUST do 1 of {H.264, VP8}
    MUST do 1 of {H.264, VP8, Theora}
    MUST do 2 of {H.264, VP8, Theora}
    MUST do 1 of {H.264, VP=
8, H.261}
    MUST do 2 of {H.264, VP8, H.261}
    MUST do 1 of {=
H.264, VP8, H.261, Theora}
    



    MUST do 2 of {H.264, VP8, H.261, Theora}
    MUST do 3 of {H.264,=
 VP8, H.261, Theora}
    MUST do 1 of {H.264, VP8, H.263}
    MU=
ST do 2 of {H.264, VP8, H.263}
    MUST do 1 of {H.264, VP8, H.263, Th=
eora}
    



    MUST do 2 of {H.264, VP8, H.263, Theora}
    MUST do 3 of {H.264,=
 VP8, H.263, Theora}
    MUST do 1 of {H.264, VP8, H.263, H.261}
    =

    MUST do 2 of {H.264, VP8, H.263, H.261}
    MUST do 3 of {H.264, V=
P8, H.263, H.261}
    



    MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
    MUST do 2 of {=
H.264, VP8, H.263, H.261, Theora}
    MUST do 3 of {H.264, VP8, H.263,=
 H.261, Theora}
    MUST do 4 of {H.264, VP8, H.263, H.261, Theora}








    <=
/div>


    On Thu, N=
ov 21, 2013 at 11:27 AM, Cullen Jennings <fluffy@iii.ca> wrote:




    
Added a
    

    
#11     =E2=80=A2 MUST implement at least two of {VP8, H.264 CBP, H=
.263}
    


    

    
On Nov 21, 2013, at 11:20 AM, David Singer <singer@apple.com> wrote:
    

    
> Chairs
    
>
    
> can we add this as an option to the formal list, so we get formal feedb=
ack on its acceptability, please?
    
>
    
> =E2=80=9CLike option ??, pick at least two of {VP8, H.264 CBP, H.263}=E2=
=80=9D
    
>
    
>
    
> I think this may be the best (maybe only) way to tease out how much ris=
k people perceive.
    
>
    
> Many thanks
    
>
    
> On Nov 21, 2013, at 9:22 , Maik Merten <maikmerten@googlemail.com> wrote:<=
br>
>
    
>> Cleary H.263 is preferable from an engineering standpoint (as is, e=
.g., MPEG-1 Part 2): better performance, more deployments. The central quest=
ion is, however, if those can actually be implemented without some sort of l=
icensing.
    



>>
    
>> If they can: Aweseome! However, this may not be determinable withou=
t a review by people who are knowledgeable in the field of IPR, i.e., "actua=
l lawyers". I understand that H.263 is not yet old enough to automatically b=
e considered "safe" (and neither is MPEG-1 Part 2, although it is closer).



>>
    
>> Best regards,
    
>>
    
>> Maik
    
>>
    
>> Am 20.11.2013 20:42, schrieb David Singer:
    
>>> I think we should think hard about H.263 instead of H.261 as th=
e third fallback.  Why?
    
>>>
    
>>> http://www.itu.int/rec/T-REC-H.263/
    
>>>
    
>>>
    
>>>
    
>>> H.263 was first published in March 1996, so it's 17 years old. &=
nbsp;The restrictions (e.g. on picture size) are no WORSE than H.261.  =
Yes, more recent amendments deal with this (and a plethora of other issues),=
 so we=E2=80=99d need to settle on which of those are mandatory (the usual p=
rofiling discussion).
    



>>>
    
>>> There are 34 records in the patent database against H.261, most=
ly from 1989 but one as recent as 2005 (though that is a re-file).  Tha=
t's 2.2 (reciprocity), as was one other I checked.
    
>>>
    
>>> Rather surprisingly, there are only 31 against H.263!  The=
 most recent is 2011, and is also option 2.  Most are 1997-2001.
    
>>>
    
>>>
    
>>> On this quick glance, H.263 appears no worse than H.261. IANAL (=
as I am sure you have all noticed).
    
>>>
    
>>>
    
>>> H.263 is much more widely supported and mandated.  It has b=
een mandated in the 3GPP specs for years (for lots of services, including vi=
deoconf), and is effectively the fallback codec today in the industry, as I u=
nderstand.  It was ubiquitous in video telephony for years, and I suspe=
ct many of those systems still ship it.
    



>>>
    
>>> So, would =E2=80=9CMUST implement at least two of (H.264, VP8, H=
.263)=E2=80=9D work?
    
>>>
    
>>> (I am asking the question, not even answering on behalf of my c=
ompany, yet.  Let=E2=80=99s get the issues on the table.)
    
>>>
    
>>>
    
>>> David Singer
    
>>> Multimedia and Software Standards, Apple Inc.
    
>>>
    
>>> _______________________________________________
    
>>> rtcweb mailing list
    
>>> rtcweb@iet=
f.org
    
>>> https://www.ietf.org/mailman/listinfo/rtcweb
    
>>>
    
>>
    
>> _______________________________________________
    
>> rtcweb mailing list
    
>> rtcweb@ietf.or=
g
    
>> https://www.ietf.org/mailman/listinfo/rtcweb
    
>
    
> David Singer
    
> Multimedia and Software Standards, Apple Inc.
    
>
    
> _______________________________________________
    
> rtcweb mailing list
    
> rtcweb@ietf.org
    
>     https://www.ietf.org/mailman/listinfo/rtcweb
    

    
_______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    =

h=
ttps://www.ietf.org/mailman/listinfo/rtcweb
    


    

    ____________________=
___________________________
    rtcweb mailing list
    rtcweb@ietf.org
    <=
a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org=
/mailman/listinfo/rtcweb
    =

--Apple-Mail-AC553157-4237-482E-AF9B-E05D8547CDFA--


From basilgohar@librevideo.org  Thu Nov 21 12:15:41 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8E31AE290 for ; Thu, 21 Nov 2013 12:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level: 
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65b_MbXJJc6S for ; Thu, 21 Nov 2013 12:15:40 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 567CB1AE282 for ; Thu, 21 Nov 2013 12:15:40 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 68ADA65971F for ; Thu, 21 Nov 2013 15:15:33 -0500 (EST)
Message-ID: <528E69E2.9020208@librevideo.org>
Date: Thu, 21 Nov 2013 15:15:30 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:15:41 -0000

On 11/21/2013 03:02 PM, Stefan Slivinski wrote:
> I in no way intended to suggest  a specific implementation of a video codec.  My question was around whether we are voting on requiring decoders (my assumption) or both encoders and decoders

The discussions, up to this point, have been about choosing an MTI video
format so that rtcweb endpoints can communicate with one-another.  I am
not sure how this goal can be achieved without having an encoder and a
decoder on both ends, sharing at least one common format, whether it is
H.261, Theora, H.264, VP8, or something else.

-- 
Libre Video
http://librevideo.org

From ekr@rtfm.com  Thu Nov 21 12:18:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6031AE289 for ; Thu, 21 Nov 2013 12:18:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6hfLxPLAV1D for ; Thu, 21 Nov 2013 12:18:33 -0800 (PST)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 2754E1AE07D for ; Thu, 21 Nov 2013 12:18:33 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id b13so252392wgh.34 for ; Thu, 21 Nov 2013 12:18:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=S0eFBPPeKBxODQm3ki6Ptdu1zihw4uezmqV/vNO/bRI=; b=XVkopNFIoeOjF0as4yOa8c9bGeJa7bLsWLzs187DdDYBu+ZK8BDSOFT88qQrCfklHe BLIuQev6LQh5d7m12hf1SmM6DPJMUJzYZPo9YrTJG5VdL5Qa5S28JQaJHgkdyYgLDXNU xY58Mu6uq4Nu33SxKMH5GRAh1wYRxT7Qqd8/YNmtHfRvlTJFNnfHAmyl5r3UvgP/CznQ 9Hnpif6m6H25gvXtgaS6Xd4TOeNTC9CyGKgvIpylTitTjJ9lowsCHypCuxkGBIIfinJ3 qpVqT1ECRZpxuWr1c7IQ2VsaV4p4R7eSXrWoT0RfrKSthQFwFiIoyLl6p5LrPJnDLF79 Ao6Q==
X-Gm-Message-State: ALoCoQkXEoRtQf7HP4RfIys/KksDjMk3Ben9Ku0pqhogxLvG4hxa/Z3SRzXPfjWkc/roCImgQLPe
X-Received: by 10.180.211.71 with SMTP id na7mr31931175wic.5.1385065105727; Thu, 21 Nov 2013 12:18:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 21 Nov 2013 12:17:45 -0800 (PST)
X-Originating-IP: [63.245.220.224]
In-Reply-To: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>   
From: Eric Rescorla 
Date: Thu, 21 Nov 2013 12:17:45 -0800
Message-ID: 
To: Steve Kann 
Content-Type: multipart/alternative; boundary=001a11c347e09e33f304ebb59934
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:18:39 -0000

--001a11c347e09e33f304ebb59934
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 21, 2013 at 12:14 PM, Steve Kann  wrote:

>
> Do you plan to open-source your codec option generator?   It would make
> modifying the list much more efficient.
>


I was thinking of distributing it as a binary module you could link into
your
mail client.

-Ekr


>
>
>
> -Sent from an iOS mobile device
>
> On Nov 21, 2013, at 12:01 PM, Eric Rescorla  wrote:
>
> I would like to propose some additional alternatives.
>
> SHOULD: Theora
> MUST: Theora
> SHOULD: H.261
> SHOULD: H.261 Theora
> MUST: Theora; SHOULD: H.261
> MUST: H.261
> MUST: H.261; SHOULD: Theora
> MUST: H.261 Theora
> SHOULD: H.263
> SHOULD: H.263 Theora
> MUST: Theora; SHOULD: H.263
> SHOULD: H.263 H.261
> SHOULD: H.263 H.261 Theora
> MUST: Theora; SHOULD: H.263 H.261
> MUST: H.261; SHOULD: H.263
> MUST: H.261; SHOULD: H.263 Theora
> MUST: H.261 Theora; SHOULD: H.263
> MUST: H.263
> MUST: H.263; SHOULD: Theora
> MUST: H.263 Theora
> MUST: H.263; SHOULD: H.261
> MUST: H.263; SHOULD: H.261 Theora
> MUST: H.263 Theora; SHOULD: H.261
> MUST: H.263 H.261
> MUST: H.263 H.261; SHOULD: Theora
> MUST: H.263 H.261 Theora
> SHOULD: VP8
> SHOULD: VP8 Theora
> MUST: Theora; SHOULD: VP8
> SHOULD: VP8 H.261
> SHOULD: VP8 H.261 Theora
> MUST: Theora; SHOULD: VP8 H.261
> MUST: H.261; SHOULD: VP8
> MUST: H.261; SHOULD: VP8 Theora
> MUST: H.261 Theora; SHOULD: VP8
> SHOULD: VP8 H.263
> SHOULD: VP8 H.263 Theora
> MUST: Theora; SHOULD: VP8 H.263
> SHOULD: VP8 H.263 H.261
> SHOULD: VP8 H.263 H.261 Theora
> MUST: Theora; SHOULD: VP8 H.263 H.261
> MUST: H.261; SHOULD: VP8 H.263
> MUST: H.261; SHOULD: VP8 H.263 Theora
> MUST: H.261 Theora; SHOULD: VP8 H.263
> MUST: H.263; SHOULD: VP8
> MUST: H.263; SHOULD: VP8 Theora
> MUST: H.263 Theora; SHOULD: VP8
> MUST: H.263; SHOULD: VP8 H.261
> MUST: H.263; SHOULD: VP8 H.261 Theora
> MUST: H.263 Theora; SHOULD: VP8 H.261
> MUST: H.263 H.261; SHOULD: VP8
> MUST: H.263 H.261; SHOULD: VP8 Theora
> MUST: H.263 H.261 Theora; SHOULD: VP8
> MUST: VP8
> MUST: VP8; SHOULD: Theora
> MUST: VP8 Theora
>  MUST: VP8; SHOULD: H.261
> MUST: VP8; SHOULD: H.261 Theora
> MUST: VP8 Theora; SHOULD: H.261
> MUST: VP8 H.261
> MUST: VP8 H.261; SHOULD: Theora
> MUST: VP8 H.261 Theora
> MUST: VP8; SHOULD: H.263
> MUST: VP8; SHOULD: H.263 Theora
> MUST: VP8 Theora; SHOULD: H.263
> MUST: VP8; SHOULD: H.263 H.261
> MUST: VP8; SHOULD: H.263 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.263 H.261
> MUST: VP8 H.261; SHOULD: H.263
> MUST: VP8 H.261; SHOULD: H.263 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.263
> MUST: VP8 H.263
> MUST: VP8 H.263; SHOULD: Theora
> MUST: VP8 H.263 Theora
> MUST: VP8 H.263; SHOULD: H.261
> MUST: VP8 H.263; SHOULD: H.261 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.261
> MUST: VP8 H.263 H.261
> MUST: VP8 H.263 H.261; SHOULD: Theora
> MUST: VP8 H.263 H.261 Theora
> SHOULD: H.264
> SHOULD: H.264 Theora
> MUST: Theora; SHOULD: H.264
> SHOULD: H.264 H.261
> SHOULD: H.264 H.261 Theora
> MUST: Theora; SHOULD: H.264 H.261
> MUST: H.261; SHOULD: H.264
> MUST: H.261; SHOULD: H.264 Theora
> MUST: H.261 Theora; SHOULD: H.264
> SHOULD: H.264 H.263
> SHOULD: H.264 H.263 Theora
> MUST: Theora; SHOULD: H.264 H.263
> SHOULD: H.264 H.263 H.261
> SHOULD: H.264 H.263 H.261 Theora
> MUST: Theora; SHOULD: H.264 H.263 H.261
> MUST: H.261; SHOULD: H.264 H.263
> MUST: H.261; SHOULD: H.264 H.263 Theora
> MUST: H.261 Theora; SHOULD: H.264 H.263
> MUST: H.263; SHOULD: H.264
> MUST: H.263; SHOULD: H.264 Theora
> MUST: H.263 Theora; SHOULD: H.264
> MUST: H.263; SHOULD: H.264 H.261
> MUST: H.263; SHOULD: H.264 H.261 Theora
> MUST: H.263 Theora; SHOULD: H.264 H.261
> MUST: H.263 H.261; SHOULD: H.264
> MUST: H.263 H.261; SHOULD: H.264 Theora
> MUST: H.263 H.261 Theora; SHOULD: H.264
> SHOULD: H.264 VP8
> SHOULD: H.264 VP8 Theora
> MUST: Theora; SHOULD: H.264 VP8
> SHOULD: H.264 VP8 H.261
> SHOULD: H.264 VP8 H.261 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.261
> MUST: H.261; SHOULD: H.264 VP8
> MUST: H.261; SHOULD: H.264 VP8 Theora
> MUST: H.261 Theora; SHOULD: H.264 VP8
> SHOULD: H.264 VP8 H.263
> SHOULD: H.264 VP8 H.263 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.263
> SHOULD: H.264 VP8 H.263 H.261
> SHOULD: H.264 VP8 H.263 H.261 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
> MUST: H.261; SHOULD: H.264 VP8 H.263
> MUST: H.261; SHOULD: H.264 VP8 H.263 Theora
> MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
> MUST: H.263; SHOULD: H.264 VP8
> MUST: H.263; SHOULD: H.264 VP8 Theora
> MUST: H.263 Theora; SHOULD: H.264 VP8
> MUST: H.263; SHOULD: H.264 VP8 H.261
> MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
> MUST: H.263 Theora; SHOULD: H.264 VP8 H.261
> MUST: H.263 H.261; SHOULD: H.264 VP8
> MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
> MUST: H.263 H.261 Theora; SHOULD: H.264 VP8
> MUST: VP8; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 Theora
> MUST: VP8 Theora; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 H.261
> MUST: VP8; SHOULD: H.264 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.261
> MUST: VP8 H.261; SHOULD: H.264
> MUST: VP8 H.261; SHOULD: H.264 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 H.263
> MUST: VP8; SHOULD: H.264 H.263 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.263
> MUST: VP8; SHOULD: H.264 H.263 H.261
> MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
> MUST: VP8 H.261; SHOULD: H.264 H.263
> MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.264 H.263
> MUST: VP8 H.263; SHOULD: H.264
> MUST: VP8 H.263; SHOULD: H.264 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.264
> MUST: VP8 H.263; SHOULD: H.264 H.261
> MUST: VP8 H.263; SHOULD: H.264 H.261 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
> MUST: VP8 H.263 H.261; SHOULD: H.264
> MUST: VP8 H.263 H.261; SHOULD: H.264 Theora
> MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
> MUST: H.264
> MUST: H.264; SHOULD: Theora
> MUST: H.264 Theora
> MUST: H.264; SHOULD: H.261
> MUST: H.264; SHOULD: H.261 Theora
> MUST: H.264 Theora; SHOULD: H.261
> MUST: H.264 H.261
> MUST: H.264 H.261; SHOULD: Theora
> MUST: H.264 H.261 Theora
> MUST: H.264; SHOULD: H.263
> MUST: H.264; SHOULD: H.263 Theora
> MUST: H.264 Theora; SHOULD: H.263
> MUST: H.264; SHOULD: H.263 H.261
> MUST: H.264; SHOULD: H.263 H.261 Theora
> MUST: H.264 Theora; SHOULD: H.263 H.261
> MUST: H.264 H.261; SHOULD: H.263
> MUST: H.264 H.261; SHOULD: H.263 Theora
> MUST: H.264 H.261 Theora; SHOULD: H.263
> MUST: H.264 H.263
> MUST: H.264 H.263; SHOULD: Theora
> MUST: H.264 H.263 Theora
> MUST: H.264 H.263; SHOULD: H.261
> MUST: H.264 H.263; SHOULD: H.261 Theora
> MUST: H.264 H.263 Theora; SHOULD: H.261
> MUST: H.264 H.263 H.261
> MUST: H.264 H.263 H.261; SHOULD: Theora
> MUST: H.264 H.263 H.261 Theora
> MUST: H.264; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 Theora
> MUST: H.264 Theora; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 H.261
> MUST: H.264; SHOULD: VP8 H.261 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.261
> MUST: H.264 H.261; SHOULD: VP8
> MUST: H.264 H.261; SHOULD: VP8 Theora
> MUST: H.264 H.261 Theora; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 H.263
> MUST: H.264; SHOULD: VP8 H.263 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.263
> MUST: H.264; SHOULD: VP8 H.263 H.261
> MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
> MUST: H.264 H.261; SHOULD: VP8 H.263
> MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
> MUST: H.264 H.261 Theora; SHOULD: VP8 H.263
> MUST: H.264 H.263; SHOULD: VP8
> MUST: H.264 H.263; SHOULD: VP8 Theora
> MUST: H.264 H.263 Theora; SHOULD: VP8
> MUST: H.264 H.263; SHOULD: VP8 H.261
> MUST: H.264 H.263; SHOULD: VP8 H.261 Theora
> MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
> MUST: H.264 H.263 H.261; SHOULD: VP8
> MUST: H.264 H.263 H.261; SHOULD: VP8 Theora
> MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
> MUST: H.264 VP8
> MUST: H.264 VP8; SHOULD: Theora
> MUST: H.264 VP8 Theora
> MUST: H.264 VP8; SHOULD: H.261
> MUST: H.264 VP8; SHOULD: H.261 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.261
> MUST: H.264 VP8 H.261
> MUST: H.264 VP8 H.261; SHOULD: Theora
> MUST: H.264 VP8 H.261 Theora
> MUST: H.264 VP8; SHOULD: H.263
> MUST: H.264 VP8; SHOULD: H.263 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.263
> MUST: H.264 VP8; SHOULD: H.263 H.261
> MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
> MUST: H.264 VP8 H.261; SHOULD: H.263
> MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
> MUST: H.264 VP8 H.261 Theora; SHOULD: H.263
> MUST: H.264 VP8 H.263
> MUST: H.264 VP8 H.263; SHOULD: Theora
> MUST: H.264 VP8 H.263 Theora
> MUST: H.264 VP8 H.263; SHOULD: H.261
> MUST: H.264 VP8 H.263; SHOULD: H.261 Theora
> MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
> MUST: H.264 VP8 H.263 H.261
> MUST: H.264 VP8 H.263 H.261; SHOULD: Theora
> MUST: H.264 VP8 H.263 H.261 Theora
> SHOULD do 1 of {H.261, Theora}
> SHOULD do 1 of {H.263, Theora}
> SHOULD do 1 of {H.263, H.261}
> SHOULD do 1 of {H.263, H.261, Theora}
> SHOULD do 2 of {H.263, H.261, Theora}
> SHOULD do 1 of {VP8, Theora}
> SHOULD do 1 of {VP8, H.261}
> SHOULD do 1 of {VP8, H.261, Theora}
> SHOULD do 2 of {VP8, H.261, Theora}
> SHOULD do 1 of {VP8, H.263}
> SHOULD do 1 of {VP8, H.263, Theora}
> SHOULD do 2 of {VP8, H.263, Theora}
> SHOULD do 1 of {VP8, H.263, H.261}
> SHOULD do 2 of {VP8, H.263, H.261}
> SHOULD do 1 of {VP8, H.263, H.261, Theora}
> SHOULD do 2 of {VP8, H.263, H.261, Theora}
> SHOULD do 3 of {VP8, H.263, H.261, Theora}
> SHOULD do 1 of {H.264, Theora}
> SHOULD do 1 of {H.264, H.261}
> SHOULD do 1 of {H.264, H.261, Theora}
> SHOULD do 2 of {H.264, H.261, Theora}
> SHOULD do 1 of {H.264, H.263}
> SHOULD do 1 of {H.264, H.263, Theora}
> SHOULD do 2 of {H.264, H.263, Theora}
> SHOULD do 1 of {H.264, H.263, H.261}
> SHOULD do 2 of {H.264, H.263, H.261}
> SHOULD do 1 of {H.264, H.263, H.261, Theora}
> SHOULD do 2 of {H.264, H.263, H.261, Theora}
> SHOULD do 3 of {H.264, H.263, H.261, Theora}
> SHOULD do 1 of {H.264, VP8}
> SHOULD do 1 of {H.264, VP8, Theora}
> SHOULD do 2 of {H.264, VP8, Theora}
> SHOULD do 1 of {H.264, VP8, H.261}
> SHOULD do 2 of {H.264, VP8, H.261}
> SHOULD do 1 of {H.264, VP8, H.261, Theora}
> SHOULD do 2 of {H.264, VP8, H.261, Theora}
> SHOULD do 3 of {H.264, VP8, H.261, Theora}
> SHOULD do 1 of {H.264, VP8, H.263}
> SHOULD do 2 of {H.264, VP8, H.263}
> SHOULD do 1 of {H.264, VP8, H.263, Theora}
> SHOULD do 2 of {H.264, VP8, H.263, Theora}
> SHOULD do 3 of {H.264, VP8, H.263, Theora}
> SHOULD do 1 of {H.264, VP8, H.263, H.261}
> SHOULD do 2 of {H.264, VP8, H.263, H.261}
> SHOULD do 3 of {H.264, VP8, H.263, H.261}
> SHOULD do 1 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 3 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 4 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 1 of {H.261, Theora}
> MUST do 1 of {H.263, Theora}
> MUST do 1 of {H.263, H.261}
> MUST do 1 of {H.263, H.261, Theora}
> MUST do 2 of {H.263, H.261, Theora}
> MUST do 1 of {VP8, Theora}
> MUST do 1 of {VP8, H.261}
> MUST do 1 of {VP8, H.261, Theora}
> MUST do 2 of {VP8, H.261, Theora}
> MUST do 1 of {VP8, H.263}
> MUST do 1 of {VP8, H.263, Theora}
> MUST do 2 of {VP8, H.263, Theora}
> MUST do 1 of {VP8, H.263, H.261}
> MUST do 2 of {VP8, H.263, H.261}
> MUST do 1 of {VP8, H.263, H.261, Theora}
> MUST do 2 of {VP8, H.263, H.261, Theora}
> MUST do 3 of {VP8, H.263, H.261, Theora}
> MUST do 1 of {H.264, Theora}
> MUST do 1 of {H.264, H.261}
> MUST do 1 of {H.264, H.261, Theora}
> MUST do 2 of {H.264, H.261, Theora}
> MUST do 1 of {H.264, H.263}
> MUST do 1 of {H.264, H.263, Theora}
> MUST do 2 of {H.264, H.263, Theora}
> MUST do 1 of {H.264, H.263, H.261}
> MUST do 2 of {H.264, H.263, H.261}
> MUST do 1 of {H.264, H.263, H.261, Theora}
> MUST do 2 of {H.264, H.263, H.261, Theora}
> MUST do 3 of {H.264, H.263, H.261, Theora}
> MUST do 1 of {H.264, VP8}
> MUST do 1 of {H.264, VP8, Theora}
> MUST do 2 of {H.264, VP8, Theora}
> MUST do 1 of {H.264, VP8, H.261}
> MUST do 2 of {H.264, VP8, H.261}
> MUST do 1 of {H.264, VP8, H.261, Theora}
> MUST do 2 of {H.264, VP8, H.261, Theora}
> MUST do 3 of {H.264, VP8, H.261, Theora}
> MUST do 1 of {H.264, VP8, H.263}
> MUST do 2 of {H.264, VP8, H.263}
> MUST do 1 of {H.264, VP8, H.263, Theora}
> MUST do 2 of {H.264, VP8, H.263, Theora}
> MUST do 3 of {H.264, VP8, H.263, Theora}
> MUST do 1 of {H.264, VP8, H.263, H.261}
> MUST do 2 of {H.264, VP8, H.263, H.261}
> MUST do 3 of {H.264, VP8, H.263, H.261}
> MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 2 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 3 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 4 of {H.264, VP8, H.263, H.261, Theora}
>
>
>
>
>
>
>
> On Thu, Nov 21, 2013 at 11:27 AM, Cullen Jennings  wrote:
>
>>
>> Added a
>>
>> #11     =95 MUST implement at least two of {VP8, H.264 CBP, H.263}
>>
>>
>> On Nov 21, 2013, at 11:20 AM, David Singer  wrote:
>>
>> > Chairs
>> >
>> > can we add this as an option to the formal list, so we get formal
>> feedback on its acceptability, please?
>> >
>> > =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
>> >
>> >
>> > I think this may be the best (maybe only) way to tease out how much
>> risk people perceive.
>> >
>> > Many thanks
>> >
>> > On Nov 21, 2013, at 9:22 , Maik Merten 
>> wrote:
>> >
>> >> Cleary H.263 is preferable from an engineering standpoint (as is,
>> e.g., MPEG-1 Part 2): better performance, more deployments. The central
>> question is, however, if those can actually be implemented without some
>> sort of licensing.
>> >>
>> >> If they can: Aweseome! However, this may not be determinable without =
a
>> review by people who are knowledgeable in the field of IPR, i.e., "actua=
l
>> lawyers". I understand that H.263 is not yet old enough to automatically=
 be
>> considered "safe" (and neither is MPEG-1 Part 2, although it is closer).
>> >>
>> >> Best regards,
>> >>
>> >> Maik
>> >>
>> >> Am 20.11.2013 20:42, schrieb David Singer:
>> >>> I think we should think hard about H.263 instead of H.261 as the
>> third fallback.  Why?
>> >>>
>> >>> http://www.itu.int/rec/T-REC-H.263/
>> >>>
>> >>>
>> >>>
>> >>> H.263 was first published in March 1996, so it's 17 years old.  The
>> restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more
>> recent amendments deal with this (and a plethora of other issues), so we=
=92d
>> need to settle on which of those are mandatory (the usual profiling
>> discussion).
>> >>>
>> >>> There are 34 records in the patent database against H.261, mostly
>> from 1989 but one as recent as 2005 (though that is a re-file).  That's =
2.2
>> (reciprocity), as was one other I checked.
>> >>>
>> >>> Rather surprisingly, there are only 31 against H.263!  The most
>> recent is 2011, and is also option 2.  Most are 1997-2001.
>> >>>
>> >>>
>> >>> On this quick glance, H.263 appears no worse than H.261. IANAL (as I
>> am sure you have all noticed).
>> >>>
>> >>>
>> >>> H.263 is much more widely supported and mandated.  It has been
>> mandated in the 3GPP specs for years (for lots of services, including
>> videoconf), and is effectively the fallback codec today in the industry,=
 as
>> I understand.  It was ubiquitous in video telephony for years, and I
>> suspect many of those systems still ship it.
>> >>>
>> >>> So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 w=
ork?
>> >>>
>> >>> (I am asking the question, not even answering on behalf of my
>> company, yet.  Let=92s get the issues on the table.)
>> >>>
>> >>>
>> >>> David Singer
>> >>> Multimedia and Software Standards, Apple Inc.
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> > David Singer
>> > Multimedia and Software Standards, Apple Inc.
>> >
>> > _______________________________________________
>> > 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
>
>

--001a11c347e09e33f304ebb59934
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable





    On Thu, Nov 21, 2013 at 12:14 PM, Steve Kann <=
stevek@stevek.com> wrote:
    



    Do you=
 plan to open-source your codec option generator? =A0 It would make modifyi=
ng the list much more efficient. 
    



    =A0
    I was thinking of dist=
ributing it as a binary module you could link into your
    mail clie=
nt.

    -Ekr

    






    -Sent from an<=
span>=A0iOS mobile device
    I would like to p=
ropose some additional alternatives.

    SHOULD: Theora=

    MUST: Theora
    SHOULD: H.261
    SHOULD: H.261 The=
ora
    


    MUST: Theora; SHOULD: H.261
    



    MUST: H.261
    MUST: H.261; SHOULD: Theora
    MUST: H.26=
1 Theora
    SHOULD: H.263
    SHOULD: H.263 Theora
    M=
UST: Theora; SHOULD: H.263
    SHOULD: H.263 H.261
    SHOULD: =
H.263 H.261 Theora
    





    MUST: Theora; SHOULD: H.263 H.261
    MUST: H.261; SHOULD: H.263=

    MUST: H.261; SHOULD: H.263 Theora
    MUST: H.261 Theora; =
SHOULD: H.263
    MUST: H.263
    MUST: H.263; SHOULD: Theora





    MUST: H.263 Theora
    MUST: H.263; SHOULD: H.261
    MUST=
: H.263; SHOULD: H.261 Theora
    MUST: H.263 Theora; SHOULD: H.261
    MUST: H.263 H.261
    MUST: H.263 H.261; SHOULD: Theora





    MUST: H.263 H.261 Theora
    SHOULD: VP8
    SHOULD: VP8 T=
heora
    MUST: Theora; SHOULD: VP8
    SHOULD: VP8 H.261
    =

    SHOULD: VP8 H.261 Theora
    MUST: Theora; SHOULD: VP8 H.261





    MUST: H.261; SHOULD: VP8
    MUST: H.261; SHOULD: VP8 Theora
    MUST: H.261 Theora; SHOULD: VP8
    SHOULD: VP8 H.263
    SHOULD: VP8 H.263 Theora
    MUST: Theora; SHOULD: VP8 H.263
    





    SHOULD: VP8 H.263 H.261
    SHOULD: VP8 H.263 H.261 Theora
    =

    MUST: Theora; SHOULD: VP8 H.263 H.261
    MUST: H.261; SHOULD: V=
P8 H.263
    MUST: H.261; SHOULD: VP8 H.263 Theora
    MUST: H.=
261 Theora; SHOULD: VP8 H.263
    





    MUST: H.263; SHOULD: VP8
    MUST: H.263; SHOULD: VP8 Theora
    MUST: H.263 Theora; SHOULD: VP8
    MUST: H.263; SHOULD: VP8 H=
.261
    MUST: H.263; SHOULD: VP8 H.261 Theora
    MUST: H.263 =
Theora; SHOULD: VP8 H.261
    





    MUST: H.263 H.261; SHOULD: VP8
    MUST: H.263 H.261; SHOULD: VP=
8 Theora
    MUST: H.263 H.261 Theora; SHOULD: VP8
    MUST: VP=
8
    MUST: VP8; SHOULD: Theora
    MUST: VP8 Theora
    




    
MUST: VP8; SHOULD: H.261
    MUST: VP8; SHOULD: H.261 Theora
    MUST: VP8 Theora; SHOULD: H.261
    MUST: VP8 H.261
    MUST:=
 VP8 H.261; SHOULD: Theora
    MUST: VP8 H.261 Theora
    



MUST: VP8; SHOULD: H.263
    

    MUST: VP8; SHOULD: H.263 Theora
    MUST: VP8 Theora; SHOULD: H.=
263
    MUST: VP8; SHOULD: H.263 H.261
    MUST: VP8; SHOULD: H=
.263 H.261 Theora
    MUST: VP8 Theora; SHOULD: H.263 H.261
    





    MUST: VP8 H.261; SHOULD: H.263
    MUST: VP8 H.261; SHOULD: H.26=
3 Theora
    MUST: VP8 H.261 Theora; SHOULD: H.263
    MUST: VP=
8 H.263
    MUST: VP8 H.263; SHOULD: Theora
    MUST: VP8 H.263=
 Theora
    





    MUST: VP8 H.263; SHOULD: H.261
    MUST: VP8 H.263; SHOULD: H.26=
1 Theora
    MUST: VP8 H.263 Theora; SHOULD: H.261
    MUST: VP=
8 H.263 H.261
    MUST: VP8 H.263 H.261; SHOULD: Theora
    




MUST: VP8 H.263 H.261 Theora
    SHOULD: H.264
    SHOULD: H.26=
4 Theora
    MUST: Theora; SHOULD: H.264
    SHOULD: H.264 H.26=
1
    SHOULD: H.264 H.261 Theora
    MUST: Theora; SHOULD: H.26=
4 H.261
    





    MUST: H.261; SHOULD: H.264
    MUST: H.261; SHOULD: H.264 Theora=

    MUST: H.261 Theora; SHOULD: H.264
    SHOULD: H.264 H.263<=
/div>
    SHOULD: H.264 H.263 Theora
    MUST: Theora; SHOULD: H.264 =
H.263
    





    SHOULD: H.264 H.263 H.261
    SHOULD: H.264 H.263 H.261 Theora
    MUST: Theora; SHOULD: H.264 H.263 H.261
    MUST: H.261; SHO=
ULD: H.264 H.263
    MUST: H.261; SHOULD: H.264 H.263 Theora
    





    MUST: H.261 Theora; SHOULD: H.264 H.263
    MUST: H.263; SHOULD:=
 H.264
    MUST: H.263; SHOULD: H.264 Theora
    MUST: H.263 Th=
eora; SHOULD: H.264
    MUST: H.263; SHOULD: H.264 H.261
    




MUST: H.263; SHOULD: H.264 H.261 Theora
    MUST: H.263 Theora; SHOUL=
D: H.264 H.261
    MUST: H.263 H.261; SHOULD: H.264
    MUST: H=
.263 H.261; SHOULD: H.264 Theora
    MUST: H.263 H.261 Theora; SHOULD=
: H.264
    





    SHOULD: H.264 VP8
    SHOULD: H.264 VP8 Theora
    MUST: T=
heora; SHOULD: H.264 VP8
    SHOULD: H.264 VP8 H.261
    SHOULD=
: H.264 VP8 H.261 Theora
    MUST: Theora; SHOULD: H.264 VP8 H.261





    MUST: H.261; SHOULD: H.264 VP8
    MUST: H.261; SHOULD: H.264 VP=
8 Theora
    MUST: H.261 Theora; SHOULD: H.264 VP8
    SHOULD: =
H.264 VP8 H.263
    SHOULD: H.264 VP8 H.263 Theora
    MUST: Th=
eora; SHOULD: H.264 VP8 H.263
    





    SHOULD: H.264 VP8 H.263 H.261
    SHOULD: H.264 VP8 H.263 H.261 =
Theora
    MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
    MUST=
: H.261; SHOULD: H.264 VP8 H.263
    MUST: H.261; SHOULD: H.264 VP8 H=
.263 Theora
    





    MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
    MUST: H.263; SHO=
ULD: H.264 VP8
    MUST: H.263; SHOULD: H.264 VP8 Theora
    MU=
ST: H.263 Theora; SHOULD: H.264 VP8
    MUST: H.263; SHOULD: H.264 VP=
8 H.261
    





    MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
    MUST: H.263 Theo=
ra; SHOULD: H.264 VP8 H.261
    MUST: H.263 H.261; SHOULD: H.264 VP8<=
/div>
    MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
    MUST: H.263=
 H.261 Theora; SHOULD: H.264 VP8
    





    MUST: VP8; SHOULD: H.264
    MUST: VP8; SHOULD: H.264 Theora
    MUST: VP8 Theora; SHOULD: H.264
    MUST: VP8; SHOULD: H.264 H=
.261
    MUST: VP8; SHOULD: H.264 H.261 Theora
    MUST: VP8 Th=
eora; SHOULD: H.264 H.261
    





    MUST: VP8 H.261; SHOULD: H.264
    MUST: VP8 H.261; SHOULD: H.26=
4 Theora
    MUST: VP8 H.261 Theora; SHOULD: H.264
    MUST: VP=
8; SHOULD: H.264 H.263
    MUST: VP8; SHOULD: H.264 H.263 Theora





    MUST: VP8 Theora; SHOULD: H.264 H.263
    MUST: VP8; SHOULD: H.2=
64 H.263 H.261
    MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
    <=
div>MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
    MUST: VP8 H.261; =
SHOULD: H.264 H.263
    





    MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
    MUST: VP8 H.261 =
Theora; SHOULD: H.264 H.263
    MUST: VP8 H.263; SHOULD: H.264
    <=
div>MUST: VP8 H.263; SHOULD: H.264 Theora
    MUST: VP8 H.263 Theora;=
 SHOULD: H.264
    





    MUST: VP8 H.263; SHOULD: H.264 H.261
    MUST: VP8 H.263; SHOULD=
: H.264 H.261 Theora
    MUST: VP8 H.263 Theora; SHOULD: H.264 H.261<=
/div>
    MUST: VP8 H.263 H.261; SHOULD: H.264
    MUST: VP8 H.263 H.=
261; SHOULD: H.264 Theora
    





    MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
    MUST: H.264
    MUST: H.264; SHOULD: Theora
    MUST: H.264 Theora
    MU=
ST: H.264; SHOULD: H.261
    MUST: H.264; SHOULD: H.261 Theora
    





    MUST: H.264 Theora; SHOULD: H.261
    MUST: H.264 H.261
    MUST: H.264 H.261; SHOULD: Theora
    MUST: H.264 H.261 Theora
    MUST: H.264; SHOULD: H.263
    MUST: H.264; SHOULD: H.263 Theor=
a
    





    MUST: H.264 Theora; SHOULD: H.263
    MUST: H.264; SHOULD: H.263=
 H.261
    MUST: H.264; SHOULD: H.263 H.261 Theora
    MUST: H.=
264 Theora; SHOULD: H.263 H.261
    MUST: H.264 H.261; SHOULD: H.263<=
/div>





    MUST: H.264 H.261; SHOULD: H.263 Theora
    MUST: H.264 H.261 Th=
eora; SHOULD: H.263
    MUST: H.264 H.263
    MUST: H.264 H.263=
; SHOULD: Theora
    MUST: H.264 H.263 Theora
    MUST: H.264 H=
.263; SHOULD: H.261
    





    MUST: H.264 H.263; SHOULD: H.261 Theora
    MUST: H.264 H.263 Th=
eora; SHOULD: H.261
    MUST: H.264 H.263 H.261
    MUST: H.264=
 H.263 H.261; SHOULD: Theora
    MUST: H.264 H.263 H.261 Theora
    





    MUST: H.264; SHOULD: VP8
    MUST: H.264; SHOULD: VP8 Theora
    MUST: H.264 Theora; SHOULD: VP8
    MUST: H.264; SHOULD: VP8 H=
.261
    MUST: H.264; SHOULD: VP8 H.261 Theora
    MUST: H.264 =
Theora; SHOULD: VP8 H.261
    





    MUST: H.264 H.261; SHOULD: VP8
    MUST: H.264 H.261; SHOULD: VP=
8 Theora
    MUST: H.264 H.261 Theora; SHOULD: VP8
    MUST: H.=
264; SHOULD: VP8 H.263
    MUST: H.264; SHOULD: VP8 H.263 Theora





    MUST: H.264 Theora; SHOULD: VP8 H.263
    MUST: H.264; SHOULD: V=
P8 H.263 H.261
    MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
    <=
div>MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
    MUST: H.264 H.261=
; SHOULD: VP8 H.263
    





    MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
    MUST: H.264 H.26=
1 Theora; SHOULD: VP8 H.263
    MUST: H.264 H.263; SHOULD: VP8
    <=
div>MUST: H.264 H.263; SHOULD: VP8 Theora
    MUST: H.264 H.263 Theor=
a; SHOULD: VP8
    





    MUST: H.264 H.263; SHOULD: VP8 H.261
    MUST: H.264 H.263; SHOU=
LD: VP8 H.261 Theora
    MUST: H.264 H.263 Theora; SHOULD: VP8 H.261<=
/div>
    MUST: H.264 H.263 H.261; SHOULD: VP8
    MUST: H.264 H.263 =
H.261; SHOULD: VP8 Theora
    





    MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
    MUST: H.264 VP8<=
/div>
    MUST: H.264 VP8; SHOULD: Theora
    MUST: H.264 VP8 Theora<=
/div>
    MUST: H.264 VP8; SHOULD: H.261
    MUST: H.264 VP8; SHOULD:=
 H.261 Theora
    





    MUST: H.264 VP8 Theora; SHOULD: H.261
    MUST: H.264 VP8 H.261<=
/div>
    MUST: H.264 VP8 H.261; SHOULD: Theora
    MUST: H.264 VP8 H=
.261 Theora
    MUST: H.264 VP8; SHOULD: H.263
    MUST: H.264 =
VP8; SHOULD: H.263 Theora
    





    MUST: H.264 VP8 Theora; SHOULD: H.263
    MUST: H.264 VP8; SHOUL=
D: H.263 H.261
    MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
    <=
div>MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
    MUST: H.264 VP8 H=
.261; SHOULD: H.263
    





    MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
    MUST: H.264 VP8 =
H.261 Theora; SHOULD: H.263
    MUST: H.264 VP8 H.263
    MUST:=
 H.264 VP8 H.263; SHOULD: Theora
    MUST: H.264 VP8 H.263 Theora





    MUST: H.264 VP8 H.263; SHOULD: H.261
    MUST: H.264 VP8 H.263; =
SHOULD: H.261 Theora
    MUST: H.264 VP8 H.263 Theora; SHOULD: H.261<=
/div>
    MUST: H.264 VP8 H.263 H.261
    MUST: H.264 VP8 H.263 H.261=
; SHOULD: Theora
    





    MUST: H.264 VP8 H.263 H.261 Theora
    SHOULD do 1 of {H.261, Th=
eora}
    SHOULD do 1 of {H.263, Theora}
    SHOULD do 1 of {H.=
263, H.261}
    SHOULD do 1 of {H.263, H.261, Theora}
    



SHOULD do 2 of {H.263, H.261, Theora}
    

    SHOULD do 1 of {VP8, Theora}
    SHOULD do 1 of {VP8, H.261}
    SHOULD do 1 of {VP8, H.261, Theora}
    SHOULD do 2 of {VP8, H=
.261, Theora}
    SHOULD do 1 of {VP8, H.263}
    SHOULD do 1 o=
f {VP8, H.263, Theora}
    





    SHOULD do 2 of {VP8, H.263, Theora}
    SHOULD do 1 of {VP8, H.2=
63, H.261}
    SHOULD do 2 of {VP8, H.263, H.261}
    SHOULD do=
 1 of {VP8, H.263, H.261, Theora}
    SHOULD do 2 of {VP8, H.263, H.2=
61, Theora}
    





    SHOULD do 3 of {VP8, H.263, H.261, Theora}
    SHOULD do 1 of {H=
.264, Theora}
    SHOULD do 1 of {H.264, H.261}
    SHOULD do 1=
 of {H.264, H.261, Theora}
    SHOULD do 2 of {H.264, H.261, Theora}<=
/div>





    SHOULD do 1 of {H.264, H.263}
    SHOULD do 1 of {H.264, H.263, =
Theora}
    SHOULD do 2 of {H.264, H.263, Theora}
    SHOULD do=
 1 of {H.264, H.263, H.261}
    SHOULD do 2 of {H.264, H.263, H.261}<=
/div>





    SHOULD do 1 of {H.264, H.263, H.261, Theora}
    SHOULD do 2 of =
{H.264, H.263, H.261, Theora}
    SHOULD do 3 of {H.264, H.263, H.261=
, Theora}
    SHOULD do 1 of {H.264, VP8}
    SHOULD do 1 of {H=
.264, VP8, Theora}
    





    SHOULD do 2 of {H.264, VP8, Theora}
    SHOULD do 1 of {H.264, V=
P8, H.261}
    SHOULD do 2 of {H.264, VP8, H.261}
    SHOULD do=
 1 of {H.264, VP8, H.261, Theora}
    SHOULD do 2 of {H.264, VP8, H.2=
61, Theora}
    





    SHOULD do 3 of {H.264, VP8, H.261, Theora}
    SHOULD do 1 of {H=
.264, VP8, H.263}
    SHOULD do 2 of {H.264, VP8, H.263}
    SH=
OULD do 1 of {H.264, VP8, H.263, Theora}
    SHOULD do 2 of {H.264, V=
P8, H.263, Theora}
    





    SHOULD do 3 of {H.264, VP8, H.263, Theora}
    SHOULD do 1 of {H=
.264, VP8, H.263, H.261}
    SHOULD do 2 of {H.264, VP8, H.263, H.261=
}
    SHOULD do 3 of {H.264, VP8, H.263, H.261}
    SHOULD do 1=
 of {H.264, VP8, H.263, H.261, Theora}
    





    SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
    SHOULD do =
3 of {H.264, VP8, H.263, H.261, Theora}
    SHOULD do 4 of {H.264, VP=
8, H.263, H.261, Theora}
    MUST do 1 of {H.261, Theora}
    




MUST do 1 of {H.263, Theora}
    MUST do 1 of {H.263, H.261}
    MUST do 1 of {H.263, H.261, Theora}
    MUST do 2 of {H.263, H.261,=
 Theora}
    MUST do 1 of {VP8, Theora}
    MUST do 1 of {VP8, =
H.261}
    





    MUST do 1 of {VP8, H.261, Theora}
    MUST do 2 of {VP8, H.261, =
Theora}
    MUST do 1 of {VP8, H.263}
    MUST do 1 of {VP8, H.=
263, Theora}
    MUST do 2 of {VP8, H.263, Theora}
    MUST do =
1 of {VP8, H.263, H.261}
    





    MUST do 2 of {VP8, H.263, H.261}
    MUST do 1 of {VP8, H.263, H=
.261, Theora}
    MUST do 2 of {VP8, H.263, H.261, Theora}
    =
MUST do 3 of {VP8, H.263, H.261, Theora}
    MUST do 1 of {H.264, The=
ora}
    





    MUST do 1 of {H.264, H.261}
    MUST do 1 of {H.264, H.261, Theo=
ra}
    MUST do 2 of {H.264, H.261, Theora}
    MUST do 1 of {H=
.264, H.263}
    MUST do 1 of {H.264, H.263, Theora}
    MUST d=
o 2 of {H.264, H.263, Theora}
    





    MUST do 1 of {H.264, H.263, H.261}
    MUST do 2 of {H.264, H.26=
3, H.261}
    MUST do 1 of {H.264, H.263, H.261, Theora}
    MU=
ST do 2 of {H.264, H.263, H.261, Theora}
    MUST do 3 of {H.264, H.2=
63, H.261, Theora}
    





    MUST do 1 of {H.264, VP8}
    MUST do 1 of {H.264, VP8, Theora}<=
/div>
    MUST do 2 of {H.264, VP8, Theora}
    MUST do 1 of {H.264, =
VP8, H.261}
    MUST do 2 of {H.264, VP8, H.261}
    MUST do 1 =
of {H.264, VP8, H.261, Theora}
    





    MUST do 2 of {H.264, VP8, H.261, Theora}
    MUST do 3 of {H.264=
, VP8, H.261, Theora}
    MUST do 1 of {H.264, VP8, H.263}
    =
MUST do 2 of {H.264, VP8, H.263}
    MUST do 1 of {H.264, VP8, H.263,=
 Theora}
    





    MUST do 2 of {H.264, VP8, H.263, Theora}
    MUST do 3 of {H.264=
, VP8, H.263, Theora}
    MUST do 1 of {H.264, VP8, H.263, H.261}
    MUST do 2 of {H.264, VP8, H.263, H.261}
    MUST do 3 of {H.26=
4, VP8, H.263, H.261}
    





    MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
    MUST do 2 of=
 {H.264, VP8, H.263, H.261, Theora}
    MUST do 3 of {H.264, VP8, H.2=
63, H.261, Theora}
    MUST do 4 of {H.264, VP8, H.263, H.261, Theora=
}
    










    =



    On Thu,=
 Nov 21, 2013 at 11:27 AM, Cullen Jennings <fluffy@iii.ca> wrote=
:
    






    
Added a
    

    
#11 =A0 =A0 =95 MUST implement at least two of {VP8, H.264 CBP, H.263}
    


    

    
On Nov 21, 2013, at 11:20 AM, David Singer <singer@apple.com> wrote:
    

    
> Chairs
    
>
    
> can we add this as an option to the formal list, so we get formal feed=
back on its acceptability, please?
    
>
    
> =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
    
>
    
>
    
> I think this may be the best (maybe only) way to tease out how much ri=
sk people perceive.
    
>
    
> Many thanks
    
>
    
> On Nov 21, 2013, at 9:22 , Maik Merten <maikmerten@googlemail.com> wrote=
:
    
>
    
>> Cleary H.263 is preferable from an engineering standpoint (as is, =
e.g., MPEG-1 Part 2): better performance, more deployments. The central que=
stion is, however, if those can actually be implemented without some sort o=
f licensing.
    





>>
    
>> If they can: Aweseome! However, this may not be determinable witho=
ut a review by people who are knowledgeable in the field of IPR, i.e., &quo=
t;actual lawyers". I understand that H.263 is not yet old enough to au=
tomatically be considered "safe" (and neither is MPEG-1 Part 2, a=
lthough it is closer).
    





>>
    
>> Best regards,
    
>>
    
>> Maik
    
>>
    
>> Am 20.11.2013 20:42, schrieb David Singer:
    
>>> I think we should think hard about H.263 instead of H.261 as t=
he third fallback. =A0Why?
    
>>>
    
>>> http://www.itu.int/rec/T-REC-H.263/
    
>>>
    
>>>
    
>>>
    
>>> H.263 was first published in March 1996, so it's 17 years =
old. =A0The restrictions (e.g. on picture size) are no WORSE than H.261. =
=A0Yes, more recent amendments deal with this (and a plethora of other issu=
es), so we=92d need to settle on which of those are mandatory (the usual pr=
ofiling discussion).
    





>>>
    
>>> There are 34 records in the patent database against H.261, mos=
tly from 1989 but one as recent as 2005 (though that is a re-file). =A0That=
's 2.2 (reciprocity), as was one other I checked.
    
>>>
    
>>> Rather surprisingly, there are only 31 against H.263! =A0The m=
ost recent is 2011, and is also option 2. =A0Most are 1997-2001.
    
>>>
    
>>>
    
>>> On this quick glance, H.263 appears no worse than H.261. IANAL=
 (as I am sure you have all noticed).
    
>>>
    
>>>
    
>>> H.263 is much more widely supported and mandated. =A0It has be=
en mandated in the 3GPP specs for years (for lots of services, including vi=
deoconf), and is effectively the fallback codec today in the industry, as I=
 understand. =A0It was ubiquitous in video telephony for years, and I suspe=
ct many of those systems still ship it.
    





>>>
    
>>> So, would =93MUST implement at least two of (H.264, VP8, H.263=
)=94 work?
    
>>>
    
>>> (I am asking the question, not even answering on behalf of my =
company, yet. =A0Let=92s get the issues on the table.)
    
>>>
    
>>>
    
>>> David Singer
    
>>> Multimedia and Software Standards, Apple Inc.
    
>>>
    
>>> _______________________________________________
    
>>> rtcweb mailing list
    
>>> rtcweb@ie=
tf.org
    
>>> https://www.ietf.org/mailman/listinfo/rtcweb
    
>>>
    
>>
    
>> _______________________________________________
    
>> rtcweb mailing list
    
>> rtcweb@ietf.o=
rg
    
>> https://www.ietf.org/mailman/listinfo/rtcweb
    
>
    
> David Singer
    
> Multimedia and Software Standards, Apple Inc.
    
>
    
> _______________________________________________
    
> 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<=
/a>
    

    https://www.ietf.org/mailman/listinfo/rtcweb

    

--001a11c347e09e33f304ebb59934--


From creslin@digium.com  Thu Nov 21 12:18:40 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18311AE289 for ; Thu, 21 Nov 2013 12:18:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJDg7YWMOAC8 for ; Thu, 21 Nov 2013 12:18:36 -0800 (PST)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 21F421AE1A6 for ; Thu, 21 Nov 2013 12:18:35 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id ec20so212810lab.15 for ; Thu, 21 Nov 2013 12:18:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NRMf4CZ25WlnoVzJ1/qexf4YK+xcdd+0r1xyh7+X9xQ=; b=ByExHCtT/09DmOGJT3ZDIkFVFJFORfp56f9QniGyOBBOMm1CQg5tSXx6nezN1Gc2n/ +kMZ3zFcngPApmvjZFOJvV7qvYBdDSHbyBFzU7bUu+Bc+nLLgSod7WFsjZBCsJxGNP2a dBsVrBKI12XoTtT/RgYyFGDC/QdnMNlhG/YhQPxptQbdjPNOd/oanCED7ktwtYWOjblq G9eyxTpmC4mh55SPSLeyMywPlh0i290O3bWk6jTxUjoEAocfL7jAI6Y+I8DU6xu94qjn gI+IiI0oBuh6t8VXtUyJlhuTnr3CwdPqMSOi6EKBGBqf6ejLk9Qm9crO3xl1CpCAKjQj 2iHg==
X-Gm-Message-State: ALoCoQl/Alx6wb33sc/q7NL6zjSCscA3T2ZcBtR8FntQcPBRv0lrtF1fPRae/iw9U64mwMUaKm/d
MIME-Version: 1.0
X-Received: by 10.112.162.136 with SMTP id ya8mr2333161lbb.43.1385065108575; Thu, 21 Nov 2013 12:18:28 -0800 (PST)
Received: by 10.112.132.102 with HTTP; Thu, 21 Nov 2013 12:18:28 -0800 (PST)
In-Reply-To: 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com>  
Date: Thu, 21 Nov 2013 14:18:28 -0600
Message-ID: 
From: Matt Fredrickson 
To: Peter Dunkley 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:18:40 -0000

I agree.  I too attempt to participate remotely and would not like to
be excluded from any decision making vote on this process.

Matthew Fredrickson

On Thu, Nov 21, 2013 at 1:46 PM, Peter Dunkley
 wrote:
> Hello,
>
> I am sure there are many people on the blue sheets who have never
> participated on any of the mailing lists.  My point is that to be fair (and
> as this is controversial it must be fair) if they get a vote because they
> showed up in person those of us who showed up online should get a vote too.
>
> I am based in the UK, so the late in the day meetings at Vancouver were at
> incredibly anti-social times for me.  Still, it was important and I made the
> effort to stay up and participate in the only way I could.
>
> There is also a consistency issue here.  Those of us on Jabber were able to
> (and encouraged to) participate in the consensus process, but it has been
> proposed that we be excluded from the vote.  Really, you should either be
> able to participate through Jabber or not in a consistent way.
>
> Regards,
>
> Peter
>
>
>
> On 21 November 2013 11:37, Silvia Pfeiffer 
> wrote:
>>
>> On Thu, Nov 21, 2013 at 11:13 AM, Adam Roach  wrote:
>> > On 11/21/13 10:56, Justin Uberti wrote:
>> >>
>> >> Following an IETF meeting on Jabber doesn't count as participating?
>> >>
>> >> The "big guy vs little guy" narrative continues...
>> >
>> >
>> > I think that's a bit specious. If someone is following the issue at such
>> > a
>> > distance that they haven't expressed an opinion on the mailing list, I
>> > can't
>> > see how taking a vote from them counts as anything other than simple,
>> > old-fashioned ballot stuffing.
>>
>> They might have just been active on the W3C webrtc list and watched
>> here to see what is happening with codecs, but haven't expressed their
>> position.
>>
>>
>> > I'll take it one step further. I find the prospect that we're allowing
>> > blue
>> > sheets to stand in for participation to be highly questionable: letting
>> > the
>> > tourists vote is weighting the opinion of demonstrably uninvolved (or
>> > less-involved) parties at the same level as those who have actually been
>> > working on the topic. I do not think that a blue-sheet sign in without
>> > any
>> > on-list participation should be sufficient to participate in the kind of
>> > process the chairs are proposing.
>>
>> We could add that participation on the W3C webrtc list also qualifies.
>>
>>
>> > Or perhaps I'm missing something. Is there something about the
>> > capabilities
>> > of "the little guy" that makes sending an email an unrealistically high
>> > barrier to entry?
>>
>> To address the little guys even more, we could also add that
>> participation on the discuss-webrtc list also qualifies.
>>
>> Just my 2c worth.
>>
>> Cheers,
>> Silvia.
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

From xiphmont@gmail.com  Thu Nov 21 12:21:07 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20941AE289 for ; Thu, 21 Nov 2013 12:21:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8UIpWGjOzAq for ; Thu, 21 Nov 2013 12:21:06 -0800 (PST)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id C81A01AE1D2 for ; Thu, 21 Nov 2013 12:21:05 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id er20so211367lab.8 for ; Thu, 21 Nov 2013 12:20:58 -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=pCOFcgvK8lCXQ3ZmfvFhk1rS5ACWUtIU5I9R/hbbD7g=; b=QxxYaYoWt1a95Qf0QXXD/+6fgdGQ53j7hc0c4FAzqatUj4viMH2k/J+seauOMUWudr 4pnJtsGXLC7twbzhaPsp0NLFexspttcluHPpSU7f3T7rbY1RPdQ9yaBUBvpAOSBy/mrt IYj+woaJeyViN/w+ma+qxkL98Tl4q9FNJRxjA3o14MqTShqB5NJfGR9dDsqtMoCWxMJd JCu4adcpuauEQ8N2t/LkIcSl3mvq/QZ1HrIcqufS+11kI4yAxjZtttCxll1L99PouSd9 Tp6daIL1U20Z3ocHL+BfUb2X1nVL0gqzn3mGPzImjG6gHdZEXiESbXOPhQ307qOcOofR DwcQ==
MIME-Version: 1.0
X-Received: by 10.112.210.136 with SMTP id mu8mr5972848lbc.25.1385065258357; Thu, 21 Nov 2013 12:20:58 -0800 (PST)
Received: by 10.112.128.202 with HTTP; Thu, 21 Nov 2013 12:20:58 -0800 (PST)
In-Reply-To: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>  
Date: Thu, 21 Nov 2013 15:20:58 -0500
Message-ID: 
From: Monty Montgomery 
To: Eric Rescorla 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:21:08 -0000

On Thu, Nov 21, 2013 at 3:01 PM, Eric Rescorla  wrote:
> I would like to propose some additional alternatives.

Careful.  This sort of 100-way thing is how Toronto elected Rob Ford.

Monty

From creslin@digium.com  Thu Nov 21 12:21:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D8D1AE289 for ; Thu, 21 Nov 2013 12:21:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1P07Ffj2yat for ; Thu, 21 Nov 2013 12:21:35 -0800 (PST)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id CCA181AE2D1 for ; Thu, 21 Nov 2013 12:21:34 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id w6so209850lbh.25 for ; Thu, 21 Nov 2013 12:21:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QfRJvowdtR4MAoO3AHhBJxGJ+dmt/5kwE+ZElllLiwA=; b=YgBo/jjbtVUcpJeWhQMf1VVHAz7vXrsWHaOce8dTGTeKz6AMH4cQCM+XNH4irioPAh hDAfCl9ePIBh533SeIX5AdL1unaXKVr6SYAusI8hzLvHcuA5ECzSYHFb+3BD8d9N7H2m Ksq0esGeVdE6LXhGqVnSbSTBbRftgAFk5Da5xXrwNXjOAzGDUf09iTauixYuY7s/iFU8 PIyRjyOTbglf3QjpFEbWH5iv/BPSXnEih8GPQNpIh6xyApgMH4NjmNO3v0Xuzq/LtBZt d3QR0561smuh2cr+VoolocFyoO1fBtsz9Ny+/mvmLSCuCjkUARUajfkXOD1uTEk4ym0V 3IHQ==
X-Gm-Message-State: ALoCoQmsKp4OtrcqjkCiLLtJdZU9TB108VGEVjhSkiVfVThEDcOQJekfZqkf1MnTf5LNdhCiHRKi
MIME-Version: 1.0
X-Received: by 10.152.120.102 with SMTP id lb6mr2722697lab.37.1385065287215; Thu, 21 Nov 2013 12:21:27 -0800 (PST)
Received: by 10.112.132.102 with HTTP; Thu, 21 Nov 2013 12:21:26 -0800 (PST)
In-Reply-To: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>    
Date: Thu, 21 Nov 2013 14:21:26 -0600
Message-ID: 
From: Matt Fredrickson 
To: Eric Rescorla 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:21:39 -0000

I would like another option.  I cannot use that on my dynamically
deployed EC2 instances due to licensing restrictions. :-)

Matthew Fredrickson

On Thu, Nov 21, 2013 at 2:17 PM, Eric Rescorla  wrote:
>
>
>
> On Thu, Nov 21, 2013 at 12:14 PM, Steve Kann  wrote:
>>
>>
>> Do you plan to open-source your codec option generator?   It would make
>> modifying the list much more efficient.
>
>
>
> I was thinking of distributing it as a binary module you could link into
> your
> mail client.
>
> -Ekr
>
>>
>>
>>
>>
>> -Sent from an iOS mobile device
>>
>> On Nov 21, 2013, at 12:01 PM, Eric Rescorla  wrote:
>>
>> I would like to propose some additional alternatives.
>>
>> SHOULD: Theora
>> MUST: Theora
>> SHOULD: H.261
>> SHOULD: H.261 Theora
>> MUST: Theora; SHOULD: H.261
>> MUST: H.261
>> MUST: H.261; SHOULD: Theora
>> MUST: H.261 Theora
>> SHOULD: H.263
>> SHOULD: H.263 Theora
>> MUST: Theora; SHOULD: H.263
>> SHOULD: H.263 H.261
>> SHOULD: H.263 H.261 Theora
>> MUST: Theora; SHOULD: H.263 H.261
>> MUST: H.261; SHOULD: H.263
>> MUST: H.261; SHOULD: H.263 Theora
>> MUST: H.261 Theora; SHOULD: H.263
>> MUST: H.263
>> MUST: H.263; SHOULD: Theora
>> MUST: H.263 Theora
>> MUST: H.263; SHOULD: H.261
>> MUST: H.263; SHOULD: H.261 Theora
>> MUST: H.263 Theora; SHOULD: H.261
>> MUST: H.263 H.261
>> MUST: H.263 H.261; SHOULD: Theora
>> MUST: H.263 H.261 Theora
>> SHOULD: VP8
>> SHOULD: VP8 Theora
>> MUST: Theora; SHOULD: VP8
>> SHOULD: VP8 H.261
>> SHOULD: VP8 H.261 Theora
>> MUST: Theora; SHOULD: VP8 H.261
>> MUST: H.261; SHOULD: VP8
>> MUST: H.261; SHOULD: VP8 Theora
>> MUST: H.261 Theora; SHOULD: VP8
>> SHOULD: VP8 H.263
>> SHOULD: VP8 H.263 Theora
>> MUST: Theora; SHOULD: VP8 H.263
>> SHOULD: VP8 H.263 H.261
>> SHOULD: VP8 H.263 H.261 Theora
>> MUST: Theora; SHOULD: VP8 H.263 H.261
>> MUST: H.261; SHOULD: VP8 H.263
>> MUST: H.261; SHOULD: VP8 H.263 Theora
>> MUST: H.261 Theora; SHOULD: VP8 H.263
>> MUST: H.263; SHOULD: VP8
>> MUST: H.263; SHOULD: VP8 Theora
>> MUST: H.263 Theora; SHOULD: VP8
>> MUST: H.263; SHOULD: VP8 H.261
>> MUST: H.263; SHOULD: VP8 H.261 Theora
>> MUST: H.263 Theora; SHOULD: VP8 H.261
>> MUST: H.263 H.261; SHOULD: VP8
>> MUST: H.263 H.261; SHOULD: VP8 Theora
>> MUST: H.263 H.261 Theora; SHOULD: VP8
>> MUST: VP8
>> MUST: VP8; SHOULD: Theora
>> MUST: VP8 Theora
>> MUST: VP8; SHOULD: H.261
>> MUST: VP8; SHOULD: H.261 Theora
>> MUST: VP8 Theora; SHOULD: H.261
>> MUST: VP8 H.261
>> MUST: VP8 H.261; SHOULD: Theora
>> MUST: VP8 H.261 Theora
>> MUST: VP8; SHOULD: H.263
>> MUST: VP8; SHOULD: H.263 Theora
>> MUST: VP8 Theora; SHOULD: H.263
>> MUST: VP8; SHOULD: H.263 H.261
>> MUST: VP8; SHOULD: H.263 H.261 Theora
>> MUST: VP8 Theora; SHOULD: H.263 H.261
>> MUST: VP8 H.261; SHOULD: H.263
>> MUST: VP8 H.261; SHOULD: H.263 Theora
>> MUST: VP8 H.261 Theora; SHOULD: H.263
>> MUST: VP8 H.263
>> MUST: VP8 H.263; SHOULD: Theora
>> MUST: VP8 H.263 Theora
>> MUST: VP8 H.263; SHOULD: H.261
>> MUST: VP8 H.263; SHOULD: H.261 Theora
>> MUST: VP8 H.263 Theora; SHOULD: H.261
>> MUST: VP8 H.263 H.261
>> MUST: VP8 H.263 H.261; SHOULD: Theora
>> MUST: VP8 H.263 H.261 Theora
>> SHOULD: H.264
>> SHOULD: H.264 Theora
>> MUST: Theora; SHOULD: H.264
>> SHOULD: H.264 H.261
>> SHOULD: H.264 H.261 Theora
>> MUST: Theora; SHOULD: H.264 H.261
>> MUST: H.261; SHOULD: H.264
>> MUST: H.261; SHOULD: H.264 Theora
>> MUST: H.261 Theora; SHOULD: H.264
>> SHOULD: H.264 H.263
>> SHOULD: H.264 H.263 Theora
>> MUST: Theora; SHOULD: H.264 H.263
>> SHOULD: H.264 H.263 H.261
>> SHOULD: H.264 H.263 H.261 Theora
>> MUST: Theora; SHOULD: H.264 H.263 H.261
>> MUST: H.261; SHOULD: H.264 H.263
>> MUST: H.261; SHOULD: H.264 H.263 Theora
>> MUST: H.261 Theora; SHOULD: H.264 H.263
>> MUST: H.263; SHOULD: H.264
>> MUST: H.263; SHOULD: H.264 Theora
>> MUST: H.263 Theora; SHOULD: H.264
>> MUST: H.263; SHOULD: H.264 H.261
>> MUST: H.263; SHOULD: H.264 H.261 Theora
>> MUST: H.263 Theora; SHOULD: H.264 H.261
>> MUST: H.263 H.261; SHOULD: H.264
>> MUST: H.263 H.261; SHOULD: H.264 Theora
>> MUST: H.263 H.261 Theora; SHOULD: H.264
>> SHOULD: H.264 VP8
>> SHOULD: H.264 VP8 Theora
>> MUST: Theora; SHOULD: H.264 VP8
>> SHOULD: H.264 VP8 H.261
>> SHOULD: H.264 VP8 H.261 Theora
>> MUST: Theora; SHOULD: H.264 VP8 H.261
>> MUST: H.261; SHOULD: H.264 VP8
>> MUST: H.261; SHOULD: H.264 VP8 Theora
>> MUST: H.261 Theora; SHOULD: H.264 VP8
>> SHOULD: H.264 VP8 H.263
>> SHOULD: H.264 VP8 H.263 Theora
>> MUST: Theora; SHOULD: H.264 VP8 H.263
>> SHOULD: H.264 VP8 H.263 H.261
>> SHOULD: H.264 VP8 H.263 H.261 Theora
>> MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
>> MUST: H.261; SHOULD: H.264 VP8 H.263
>> MUST: H.261; SHOULD: H.264 VP8 H.263 Theora
>> MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
>> MUST: H.263; SHOULD: H.264 VP8
>> MUST: H.263; SHOULD: H.264 VP8 Theora
>> MUST: H.263 Theora; SHOULD: H.264 VP8
>> MUST: H.263; SHOULD: H.264 VP8 H.261
>> MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
>> MUST: H.263 Theora; SHOULD: H.264 VP8 H.261
>> MUST: H.263 H.261; SHOULD: H.264 VP8
>> MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
>> MUST: H.263 H.261 Theora; SHOULD: H.264 VP8
>> MUST: VP8; SHOULD: H.264
>> MUST: VP8; SHOULD: H.264 Theora
>> MUST: VP8 Theora; SHOULD: H.264
>> MUST: VP8; SHOULD: H.264 H.261
>> MUST: VP8; SHOULD: H.264 H.261 Theora
>> MUST: VP8 Theora; SHOULD: H.264 H.261
>> MUST: VP8 H.261; SHOULD: H.264
>> MUST: VP8 H.261; SHOULD: H.264 Theora
>> MUST: VP8 H.261 Theora; SHOULD: H.264
>> MUST: VP8; SHOULD: H.264 H.263
>> MUST: VP8; SHOULD: H.264 H.263 Theora
>> MUST: VP8 Theora; SHOULD: H.264 H.263
>> MUST: VP8; SHOULD: H.264 H.263 H.261
>> MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
>> MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
>> MUST: VP8 H.261; SHOULD: H.264 H.263
>> MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
>> MUST: VP8 H.261 Theora; SHOULD: H.264 H.263
>> MUST: VP8 H.263; SHOULD: H.264
>> MUST: VP8 H.263; SHOULD: H.264 Theora
>> MUST: VP8 H.263 Theora; SHOULD: H.264
>> MUST: VP8 H.263; SHOULD: H.264 H.261
>> MUST: VP8 H.263; SHOULD: H.264 H.261 Theora
>> MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
>> MUST: VP8 H.263 H.261; SHOULD: H.264
>> MUST: VP8 H.263 H.261; SHOULD: H.264 Theora
>> MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
>> MUST: H.264
>> MUST: H.264; SHOULD: Theora
>> MUST: H.264 Theora
>> MUST: H.264; SHOULD: H.261
>> MUST: H.264; SHOULD: H.261 Theora
>> MUST: H.264 Theora; SHOULD: H.261
>> MUST: H.264 H.261
>> MUST: H.264 H.261; SHOULD: Theora
>> MUST: H.264 H.261 Theora
>> MUST: H.264; SHOULD: H.263
>> MUST: H.264; SHOULD: H.263 Theora
>> MUST: H.264 Theora; SHOULD: H.263
>> MUST: H.264; SHOULD: H.263 H.261
>> MUST: H.264; SHOULD: H.263 H.261 Theora
>> MUST: H.264 Theora; SHOULD: H.263 H.261
>> MUST: H.264 H.261; SHOULD: H.263
>> MUST: H.264 H.261; SHOULD: H.263 Theora
>> MUST: H.264 H.261 Theora; SHOULD: H.263
>> MUST: H.264 H.263
>> MUST: H.264 H.263; SHOULD: Theora
>> MUST: H.264 H.263 Theora
>> MUST: H.264 H.263; SHOULD: H.261
>> MUST: H.264 H.263; SHOULD: H.261 Theora
>> MUST: H.264 H.263 Theora; SHOULD: H.261
>> MUST: H.264 H.263 H.261
>> MUST: H.264 H.263 H.261; SHOULD: Theora
>> MUST: H.264 H.263 H.261 Theora
>> MUST: H.264; SHOULD: VP8
>> MUST: H.264; SHOULD: VP8 Theora
>> MUST: H.264 Theora; SHOULD: VP8
>> MUST: H.264; SHOULD: VP8 H.261
>> MUST: H.264; SHOULD: VP8 H.261 Theora
>> MUST: H.264 Theora; SHOULD: VP8 H.261
>> MUST: H.264 H.261; SHOULD: VP8
>> MUST: H.264 H.261; SHOULD: VP8 Theora
>> MUST: H.264 H.261 Theora; SHOULD: VP8
>> MUST: H.264; SHOULD: VP8 H.263
>> MUST: H.264; SHOULD: VP8 H.263 Theora
>> MUST: H.264 Theora; SHOULD: VP8 H.263
>> MUST: H.264; SHOULD: VP8 H.263 H.261
>> MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
>> MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
>> MUST: H.264 H.261; SHOULD: VP8 H.263
>> MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
>> MUST: H.264 H.261 Theora; SHOULD: VP8 H.263
>> MUST: H.264 H.263; SHOULD: VP8
>> MUST: H.264 H.263; SHOULD: VP8 Theora
>> MUST: H.264 H.263 Theora; SHOULD: VP8
>> MUST: H.264 H.263; SHOULD: VP8 H.261
>> MUST: H.264 H.263; SHOULD: VP8 H.261 Theora
>> MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
>> MUST: H.264 H.263 H.261; SHOULD: VP8
>> MUST: H.264 H.263 H.261; SHOULD: VP8 Theora
>> MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
>> MUST: H.264 VP8
>> MUST: H.264 VP8; SHOULD: Theora
>> MUST: H.264 VP8 Theora
>> MUST: H.264 VP8; SHOULD: H.261
>> MUST: H.264 VP8; SHOULD: H.261 Theora
>> MUST: H.264 VP8 Theora; SHOULD: H.261
>> MUST: H.264 VP8 H.261
>> MUST: H.264 VP8 H.261; SHOULD: Theora
>> MUST: H.264 VP8 H.261 Theora
>> MUST: H.264 VP8; SHOULD: H.263
>> MUST: H.264 VP8; SHOULD: H.263 Theora
>> MUST: H.264 VP8 Theora; SHOULD: H.263
>> MUST: H.264 VP8; SHOULD: H.263 H.261
>> MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
>> MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
>> MUST: H.264 VP8 H.261; SHOULD: H.263
>> MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
>> MUST: H.264 VP8 H.261 Theora; SHOULD: H.263
>> MUST: H.264 VP8 H.263
>> MUST: H.264 VP8 H.263; SHOULD: Theora
>> MUST: H.264 VP8 H.263 Theora
>> MUST: H.264 VP8 H.263; SHOULD: H.261
>> MUST: H.264 VP8 H.263; SHOULD: H.261 Theora
>> MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
>> MUST: H.264 VP8 H.263 H.261
>> MUST: H.264 VP8 H.263 H.261; SHOULD: Theora
>> MUST: H.264 VP8 H.263 H.261 Theora
>> SHOULD do 1 of {H.261, Theora}
>> SHOULD do 1 of {H.263, Theora}
>> SHOULD do 1 of {H.263, H.261}
>> SHOULD do 1 of {H.263, H.261, Theora}
>> SHOULD do 2 of {H.263, H.261, Theora}
>> SHOULD do 1 of {VP8, Theora}
>> SHOULD do 1 of {VP8, H.261}
>> SHOULD do 1 of {VP8, H.261, Theora}
>> SHOULD do 2 of {VP8, H.261, Theora}
>> SHOULD do 1 of {VP8, H.263}
>> SHOULD do 1 of {VP8, H.263, Theora}
>> SHOULD do 2 of {VP8, H.263, Theora}
>> SHOULD do 1 of {VP8, H.263, H.261}
>> SHOULD do 2 of {VP8, H.263, H.261}
>> SHOULD do 1 of {VP8, H.263, H.261, Theora}
>> SHOULD do 2 of {VP8, H.263, H.261, Theora}
>> SHOULD do 3 of {VP8, H.263, H.261, Theora}
>> SHOULD do 1 of {H.264, Theora}
>> SHOULD do 1 of {H.264, H.261}
>> SHOULD do 1 of {H.264, H.261, Theora}
>> SHOULD do 2 of {H.264, H.261, Theora}
>> SHOULD do 1 of {H.264, H.263}
>> SHOULD do 1 of {H.264, H.263, Theora}
>> SHOULD do 2 of {H.264, H.263, Theora}
>> SHOULD do 1 of {H.264, H.263, H.261}
>> SHOULD do 2 of {H.264, H.263, H.261}
>> SHOULD do 1 of {H.264, H.263, H.261, Theora}
>> SHOULD do 2 of {H.264, H.263, H.261, Theora}
>> SHOULD do 3 of {H.264, H.263, H.261, Theora}
>> SHOULD do 1 of {H.264, VP8}
>> SHOULD do 1 of {H.264, VP8, Theora}
>> SHOULD do 2 of {H.264, VP8, Theora}
>> SHOULD do 1 of {H.264, VP8, H.261}
>> SHOULD do 2 of {H.264, VP8, H.261}
>> SHOULD do 1 of {H.264, VP8, H.261, Theora}
>> SHOULD do 2 of {H.264, VP8, H.261, Theora}
>> SHOULD do 3 of {H.264, VP8, H.261, Theora}
>> SHOULD do 1 of {H.264, VP8, H.263}
>> SHOULD do 2 of {H.264, VP8, H.263}
>> SHOULD do 1 of {H.264, VP8, H.263, Theora}
>> SHOULD do 2 of {H.264, VP8, H.263, Theora}
>> SHOULD do 3 of {H.264, VP8, H.263, Theora}
>> SHOULD do 1 of {H.264, VP8, H.263, H.261}
>> SHOULD do 2 of {H.264, VP8, H.263, H.261}
>> SHOULD do 3 of {H.264, VP8, H.263, H.261}
>> SHOULD do 1 of {H.264, VP8, H.263, H.261, Theora}
>> SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
>> SHOULD do 3 of {H.264, VP8, H.263, H.261, Theora}
>> SHOULD do 4 of {H.264, VP8, H.263, H.261, Theora}
>> MUST do 1 of {H.261, Theora}
>> MUST do 1 of {H.263, Theora}
>> MUST do 1 of {H.263, H.261}
>> MUST do 1 of {H.263, H.261, Theora}
>> MUST do 2 of {H.263, H.261, Theora}
>> MUST do 1 of {VP8, Theora}
>> MUST do 1 of {VP8, H.261}
>> MUST do 1 of {VP8, H.261, Theora}
>> MUST do 2 of {VP8, H.261, Theora}
>> MUST do 1 of {VP8, H.263}
>> MUST do 1 of {VP8, H.263, Theora}
>> MUST do 2 of {VP8, H.263, Theora}
>> MUST do 1 of {VP8, H.263, H.261}
>> MUST do 2 of {VP8, H.263, H.261}
>> MUST do 1 of {VP8, H.263, H.261, Theora}
>> MUST do 2 of {VP8, H.263, H.261, Theora}
>> MUST do 3 of {VP8, H.263, H.261, Theora}
>> MUST do 1 of {H.264, Theora}
>> MUST do 1 of {H.264, H.261}
>> MUST do 1 of {H.264, H.261, Theora}
>> MUST do 2 of {H.264, H.261, Theora}
>> MUST do 1 of {H.264, H.263}
>> MUST do 1 of {H.264, H.263, Theora}
>> MUST do 2 of {H.264, H.263, Theora}
>> MUST do 1 of {H.264, H.263, H.261}
>> MUST do 2 of {H.264, H.263, H.261}
>> MUST do 1 of {H.264, H.263, H.261, Theora}
>> MUST do 2 of {H.264, H.263, H.261, Theora}
>> MUST do 3 of {H.264, H.263, H.261, Theora}
>> MUST do 1 of {H.264, VP8}
>> MUST do 1 of {H.264, VP8, Theora}
>> MUST do 2 of {H.264, VP8, Theora}
>> MUST do 1 of {H.264, VP8, H.261}
>> MUST do 2 of {H.264, VP8, H.261}
>> MUST do 1 of {H.264, VP8, H.261, Theora}
>> MUST do 2 of {H.264, VP8, H.261, Theora}
>> MUST do 3 of {H.264, VP8, H.261, Theora}
>> MUST do 1 of {H.264, VP8, H.263}
>> MUST do 2 of {H.264, VP8, H.263}
>> MUST do 1 of {H.264, VP8, H.263, Theora}
>> MUST do 2 of {H.264, VP8, H.263, Theora}
>> MUST do 3 of {H.264, VP8, H.263, Theora}
>> MUST do 1 of {H.264, VP8, H.263, H.261}
>> MUST do 2 of {H.264, VP8, H.263, H.261}
>> MUST do 3 of {H.264, VP8, H.263, H.261}
>> MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
>> MUST do 2 of {H.264, VP8, H.263, H.261, Theora}
>> MUST do 3 of {H.264, VP8, H.263, H.261, Theora}
>> MUST do 4 of {H.264, VP8, H.263, H.261, Theora}
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Nov 21, 2013 at 11:27 AM, Cullen Jennings  wrote:
>>>
>>>
>>> Added a
>>>
>>> #11     =95 MUST implement at least two of {VP8, H.264 CBP, H.263}
>>>
>>>
>>> On Nov 21, 2013, at 11:20 AM, David Singer  wrote:
>>>
>>> > Chairs
>>> >
>>> > can we add this as an option to the formal list, so we get formal
>>> > feedback on its acceptability, please?
>>> >
>>> > =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
>>> >
>>> >
>>> > I think this may be the best (maybe only) way to tease out how much
>>> > risk people perceive.
>>> >
>>> > Many thanks
>>> >
>>> > On Nov 21, 2013, at 9:22 , Maik Merten 
>>> > wrote:
>>> >
>>> >> Cleary H.263 is preferable from an engineering standpoint (as is,
>>> >> e.g., MPEG-1 Part 2): better performance, more deployments. The cent=
ral
>>> >> question is, however, if those can actually be implemented without s=
ome sort
>>> >> of licensing.
>>> >>
>>> >> If they can: Aweseome! However, this may not be determinable without=
 a
>>> >> review by people who are knowledgeable in the field of IPR, i.e., "a=
ctual
>>> >> lawyers". I understand that H.263 is not yet old enough to automatic=
ally be
>>> >> considered "safe" (and neither is MPEG-1 Part 2, although it is clos=
er).
>>> >>
>>> >> Best regards,
>>> >>
>>> >> Maik
>>> >>
>>> >> Am 20.11.2013 20:42, schrieb David Singer:
>>> >>> I think we should think hard about H.263 instead of H.261 as the
>>> >>> third fallback.  Why?
>>> >>>
>>> >>> http://www.itu.int/rec/T-REC-H.263/
>>> >>>
>>> >>>
>>> >>>
>>> >>> H.263 was first published in March 1996, so it's 17 years old.  The
>>> >>> restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, =
more
>>> >>> recent amendments deal with this (and a plethora of other issues), =
so we=92d
>>> >>> need to settle on which of those are mandatory (the usual profiling
>>> >>> discussion).
>>> >>>
>>> >>> There are 34 records in the patent database against H.261, mostly
>>> >>> from 1989 but one as recent as 2005 (though that is a re-file).  Th=
at's 2.2
>>> >>> (reciprocity), as was one other I checked.
>>> >>>
>>> >>> Rather surprisingly, there are only 31 against H.263!  The most
>>> >>> recent is 2011, and is also option 2.  Most are 1997-2001.
>>> >>>
>>> >>>
>>> >>> On this quick glance, H.263 appears no worse than H.261. IANAL (as =
I
>>> >>> am sure you have all noticed).
>>> >>>
>>> >>>
>>> >>> H.263 is much more widely supported and mandated.  It has been
>>> >>> mandated in the 3GPP specs for years (for lots of services, includi=
ng
>>> >>> videoconf), and is effectively the fallback codec today in the indu=
stry, as
>>> >>> I understand.  It was ubiquitous in video telephony for years, and =
I suspect
>>> >>> many of those systems still ship it.
>>> >>>
>>> >>> So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 =
work?
>>> >>>
>>> >>> (I am asking the question, not even answering on behalf of my
>>> >>> company, yet.  Let=92s get the issues on the table.)
>>> >>>
>>> >>>
>>> >>> David Singer
>>> >>> Multimedia and Software Standards, Apple Inc.
>>> >>>
>>> >>> _______________________________________________
>>> >>> 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
>>> >
>>> > David Singer
>>> > Multimedia and Software Standards, Apple Inc.
>>> >
>>> > _______________________________________________
>>> > 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
>

From juberti@google.com  Thu Nov 21 12:25:58 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A481AE1BC for ; Thu, 21 Nov 2013 12:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzJjX-fL5yHk for ; Thu, 21 Nov 2013 12:25:54 -0800 (PST)
Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE381AE29B for ; Thu, 21 Nov 2013 12:25:54 -0800 (PST)
Received: by mail-vb0-f48.google.com with SMTP id x16so202263vbf.7 for ; Thu, 21 Nov 2013 12:25:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Jh6nZg38CQm3Qgf1absqx7McW2XtH88LfNBw48/vfBk=; b=WkULlRWB4Zf/z8WoCs5kItryGdPPD7MLDPIskbDgZFu2gP/8BsgixE+XYNx4yiyfX4 riHrIL8ZHe7Fak6DemOxWWyVyX+p/XvokQPwg4EyVf8BFUCIbhS5rYPgt3Wr30tJ6DqC c4BaCZIg4uJNovMX1+KR7zVu+33+fNC9YKxo/6m8fnwCgeYZCXwacjv2HsAvRp9wWBFH PYErMQBS2LB9fS73aYBsGJBwDUPhq6WFYgFiyxAYye1FFePGEqg2IKrKpFVUhsLoq1ZK kC46QJShDLlSTvJNN1frftwgvC/LBNfNO0q6emtLKjJVAcKmF+pJADBO/wRMleChACGe KpUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Jh6nZg38CQm3Qgf1absqx7McW2XtH88LfNBw48/vfBk=; b=d3FBpcHubivoBEKPNDFm2MvIm08iCdmAySOU83k5begopSganaie4iURTwxgzyNDYv GPR76dTobPEZUcX1gI3n6Mf9CFK+098AnmxXnSlI36zU7AzXNCcI/1fdOlKSKzXC3KGw 8xK0+dtp/GjlAOHzZjOeCSszl6sK6jZni+1mIPE0YlbZgRYPaFUHjnILhubna7M+29KE Qqy1utaVs37MyLdfziIavb11Ix5erblrIgXC7J5RVAuN2uLRjX+NA6E16e1rXo5VhW5r IdKrUkMrPjel3UdZoVgLk7jd2niwji8DSh91tVV4Jj9iFgSexyeguHYti9RU/ILAsZv3 rwXQ==
X-Gm-Message-State: ALoCoQkQeQIBeXYZ5p+uLZvRGcMxIWyrwF5gS8DILjMQ86Wll7M4SUVy+pZnhMbaNMLvxzYFJWnQRoDVaiBT4AQu3w1VMrSOIUDpfpN4aXCt1nX5mOlvD6lDPU4cIHm5Ut2WMmN5u+WgNc6DqnRXZIQ0t7JY7XV/kLpF8GTlnCW5pFvbh7dI/YeslVzLBuB8DtUZHtKe1GMh
X-Received: by 10.220.199.5 with SMTP id eq5mr7539674vcb.16.1385065547293; Thu, 21 Nov 2013 12:25:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Thu, 21 Nov 2013 12:25:27 -0800 (PST)
In-Reply-To: <528E5E3C.70008@bbs.darktech.org>
References: <528D6C63.7050607@bbs.darktech.org> <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr> <5A2BC34D-FE4D-4420-B52F-729087815F37@cisco.com>  <528E5E3C.70008@bbs.darktech.org>
From: Justin Uberti 
Date: Thu, 21 Nov 2013 12:25:27 -0800
Message-ID: 
To: Gili 
Content-Type: multipart/alternative; boundary=047d7b5db26af001f104ebb5b39c
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:25:58 -0000

--047d7b5db26af001f104ebb5b39c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Even if we could do this conversion in real-time on a mobile device...
since you have both codecs present, why not just send the desired format in
the first place?


On Thu, Nov 21, 2013 at 11:25 AM, Gili  wrote:

> Cullen,
>
> Thanks for the background information. I also remember them saying that w=
e
> are only at the beginning of this process and that they expect more
> performance improvements in the upcoming months.
>
> It would be nice to gauge how far we are from being able to do this kind
> of conversion in real-time on a mobile device (I suspect very far, but it=
's
> worth asking). This has implications for P2P interoperability between VP8
> and H.264 peers without a middleman.
>
> Gili
>
>
> On 21/11/2013 10:46 AM, Cullen Jennings wrote:
>
>> It's a cool demo and I talked to the team that did it. This is only
>> possible because VP8 and H.264 are very similar codecs. The idea is to n=
ot
>> redo the motion vector computations or the DCT but just reuse the values
>> from one format in the other since they are the same. They hope that thi=
s
>> can provide reduce the CPU by 1/3 from a full decode then re-encode. It
>> also help reduce loss of quality for video. Other people have talked abo=
ut
>> this idea over the years and many people think it can give a 2 to 3 spee=
d
>> up so that seems consistent with their goals.
>>
>> It still requires the same bandwidth, and has similar other impacts. I
>> can not see any way that it would not require MPEG-LA IPR for 264.
>>
>>
>> On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty) 
>> wrote:
>>
>>  This probably refers to an intelligent transcoder versus a brute force
>>> transcoder. An intelligent transcoder harvests more data during decodin=
g
>>> than just the raw output pixels, and uses this extra data to ease encod=
ing.
>>> Data like block partitions, motion vectors, intra modes, quantization
>>> parameters, etc.
>>>
>>> This is common for common conversions, like MPEG2 to H.264. VP8 and
>>> H.264 are much closer formats, so this can significantly improve transc=
oder
>>> performance.
>>>
>>> However, this is strictly a performance optimization, with no impact on
>>> IPR or licensing issues.
>>>
>>> Mo
>>>
>>>
>>> On Nov 21, 2013, at 2:51 AM, "Bossiel"  wrote:
>>>
>>> This could be true if they can also walk on water and change it into
>>> wine.
>>> To be serious, no it's not possible.
>>> Mamadou
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 21, 2013, at 3:13, Gili  wrote:
>>>
>>>  Hi,
>>>>
>>>> I'm at the WebRTC World conference. If I understood correctly, Zingaya
>>>> just demoed what they claim is a VP8 to H.264 bridge that converts the
>>>> video without transcoding. My interpretation is that they convert the
>>>> surrounding packet format without re-encoding the actual video. Someon=
e who
>>>> understands codec internals (I don't) might want to validate this clai=
m,
>>>> because it could have a significant impact on the MTI debate.
>>>>
>>>> It sounds far fetched, but imagine the possibilities:
>>>>         =E2=80=A2 If the video is not being re-encoded, do H.264 royal=
ties
>>>> apply?
>>>>         =E2=80=A2 If the conversion is really cheap, is it feasible to=
 connect
>>>> a H.264 peer to a VP8 peer and have one of them convert in-line (no MC=
U)?
>>>> Gili
>>>> _______________________________________________
>>>> 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
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--047d7b5db26af001f104ebb5b39c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Even if we could do this conversion in real-time on a mobi=
le device... since you have both codecs present, why not just send the desi=
red format in the first place?


    

On Thu, Nov 21, 2013 at 11:25 AM, Gili <cowwoc@bbs.darktech.org&=
gt; wrote:
    

Cullen,
    

    
Thanks for the background information. I also remember them saying that we =
are only at the beginning of this process and that they expect more perform=
ance improvements in the upcoming months.
    

    
It would be nice to gauge how far we are from being able to do this kind of=
 conversion in real-time on a mobile device (I suspect very far, but it'=
;s worth asking). This has implications for P2P interoperability between VP=
8 and H.264 peers without a middleman.
    



    
Gili

    

    
On 21/11/2013 10:46 AM, Cullen Jennings wrote:
    

    
It's a cool demo and I talked to the team that did it. This is only pos=
sible because VP8 and H.264 are very similar codecs. The idea is to not red=
o the motion vector computations or the DCT but just reuse the values from =
one format in the other since they are the same. They hope that this can pr=
ovide reduce the CPU by 1/3 from a full decode then re-encode. It also help=
 reduce loss of quality for video. Other people have talked about this idea=
 over the years and many people think it can give a 2 to 3 speed up so that=
 seems consistent with their goals.
    



    
It still requires the same bandwidth, and has similar other impacts. I can =
not see any way that it would not require MPEG-LA IPR for 264.
    

    

    
On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:
    

    

    
This probably refers to an intelligent transcoder versus a brute force tran=
scoder. An intelligent transcoder harvests more data during decoding than j=
ust the raw output pixels, and uses this extra data to ease encoding. Data =
like block partitions, motion vectors, intra modes, quantization parameters=
, etc.
    



    
This is common for common conversions, like MPEG2 to H.264. VP8 and H.264 a=
re much closer formats, so this can significantly improve transcoder perfor=
mance.
    

    
However, this is strictly a performance optimization, with no impact on IPR=
 or licensing issues.
    

    
Mo
    

    

    
On Nov 21, 2013, at 2:51 AM, "Bossiel" <bossiel@yahoo.fr> wrote:
    

    
This could be true if they can also walk on water and change it into wine.<=
br>
To be serious, no it's not possible.
    
Mamadou
    

    
Sent from my iPhone
    

    
On Nov 21, 2013, at 3:13, Gili <cowwoc@bbs.darktech.org> wrote:
    

    

    
Hi,
    

    
I'm at the WebRTC World conference. If I understood correctly, Zingaya =
just demoed what they claim is a VP8 to H.264 bridge that converts the vide=
o without transcoding. My interpretation is that they convert the surroundi=
ng packet format without re-encoding the actual video. Someone who understa=
nds codec internals (I don't) might want to validate this claim, becaus=
e it could have a significant impact on the MTI debate.
    



    
It sounds far fetched, but imagine the possibilities:
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 If the video is not being re-encoded,=
 do H.264 royalties apply?
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 If the conversion is really cheap, is=
 it feasible to connect a H.264 peer to a VP8 peer and have one of them con=
vert in-line (no MCU)?
    
Gili
    
_______________________________________________
    
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
    

    

    
_______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--047d7b5db26af001f104ebb5b39c--

From juberti@google.com  Thu Nov 21 12:26:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FF01AE2D0 for ; Thu, 21 Nov 2013 12:26:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w84wFppv-520 for ; Thu, 21 Nov 2013 12:26:52 -0800 (PST)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 654951AE1BC for ; Thu, 21 Nov 2013 12:26:52 -0800 (PST)
Received: by mail-vc0-f171.google.com with SMTP id ik5so203946vcb.16 for ; Thu, 21 Nov 2013 12:26:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PBKKglmGu62Vw8MtP/D8E5Xjwdf9N6wGrRAAEJxtNp4=; b=a6YoS+oKmRBnmkEkmIY06FfJgowRt1Otdr45TcdSSv8pwqOTyWBduZJ1dGf0A5q+qn yMVsVnpyfxUrx+frbdsQ+SpHszbAJkUetRr6AlDQMFmnMUavUO40Fk66bK/tPtFQn/0c yXH617+u2FuGEVS2MDClIt/zDtB8N1R95ZuoSTBnpWqJiqJX5TQl+Ym4hjsuBOV/w39P LkBjAYC5/cZmsNo+fYgaZe/FgAaz83DKxUFuHj9yoTLmjVPpryLcHhnUuHX8KSGs3EcQ 44EG5RHOjucXzg28Ca1DPYKGbSZQSNIZAKf5v294QuzhHO8dI+tys8LfbrggqdtNQ2Ed NzWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PBKKglmGu62Vw8MtP/D8E5Xjwdf9N6wGrRAAEJxtNp4=; b=nHXBVX2J9Jx34djK3iyjQCw2Y9PpfxfFbZRqF5y41Wbe9I99zivMlzm4HEg0xDK49u D88NDGUiLzVYYWXNxd7e1u8J6rSpxR/EDA7WThqZtf/kTLiEerlUiHIflFviCIrfouxj 2eFGp34uyjNazf1YjXBcjLdVtcNmvkgJkmTRyLisqv49EXI4i4/2PHLERqhT7gYbwKSk fKzwtvfCwM+qALLOsNMxXQR5wHz7Fn9Q1WgQNLx3zK0+0FT4pG2zEQIOQ87bpQ3r5b8D Vhk+E/msXfT96fVnxHfWdNzK3c+s8wodevYIPcHUKyNp7XfEXCz1ku22kr9IrqP6s4UL sZZg==
X-Gm-Message-State: ALoCoQnD6PvHSPqCoIh42n3bQFgvgCkisYGV78wyVrl8Ye6lxLgtjQJU7U9gNsKPNRRZtle/RBcPTJwxW9TEBFQt5dEx9SUCAhPwAKGHXwfJENrJ48944IY0ZXaf8a/vm/MnwdCKSg83heUjxepjFuFzcbVDZcQjF6RpLD8ZiuNJopEUjX9b3yoE0wX6kfSyMuntKu0qmMa6
X-Received: by 10.221.39.195 with SMTP id tn3mr7474075vcb.2.1385065605298; Thu, 21 Nov 2013 12:26:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Thu, 21 Nov 2013 12:26:25 -0800 (PST)
In-Reply-To: 
References:  <528DFA63.6030404@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C54AE8D@ESESSMB209.ericsson.se> 
From: Justin Uberti 
Date: Thu, 21 Nov 2013 12:26:25 -0800
Message-ID: 
To: Cullen Jennings 
Content-Type: multipart/alternative; boundary=001a113375c265285404ebb5b734
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] "pranswer" be applied as an update to a previously sent "answer"?
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:26:54 -0000

--001a113375c265285404ebb5b734
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes, it is an error. Someone else pointed it out to me right after I
submitted -05; will be fixed in the next rev.


On Thu, Nov 21, 2013 at 10:17 AM, Cullen Jennings  wrote:

>
> On Nov 21, 2013, at 5:05 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> > Hi,
> >
> > I would assume that the text should say =E2=80=9Cupdate to a previously=
 applied
> =E2=80=9Cpranswer=E2=80=9D.
> >
> > Regards,
>
> +1
>
> >
> > Christer
> >
> > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald
> Alvestrand
> > Sent: 21. marraskuuta 2013 14:20
> > To: rtcweb@ietf.org
> > Subject: Re: [rtcweb] "pranswer" be applied as an update to a previousl=
y
> sent "answer"?
> >
> > On 11/20/2013 12:22 PM, Lijing (Jessie) wrote:
> > draft-ietf-rtcweb-jsep-05 -----Section 4.1.3 says:
> >
> > "pranswer" indicates that a description should be parsed as an
> >    answer, but not a final answer, and so should not result in the
> >    freeing of allocated resources.  It may result in the start of media
> >    transmission, if the answer does not specify an inactive media
> >    direction.  A description used as a "pranswer" may be applied as a
> >    response to an "offer", or an update to a previously sent "answer".
> >
> > How can a pranswer be applied as an update to a previously sent answer?
>  I am not sure what=E2=80=99s the corresponding scenario.
> > From the state machine perspective, when answer is received, it enters
> the stable state. At this point, the state machine can not directly jump =
to
> local pranswer or remote pranswer state.
> >
> > My two cents: May be it needs more description or correction here.
> >
> > This makes sense, and is consistent with the state diagrams, if the las=
t
> "answer" is changed to "pranswer".
> >
> > Justin, is this an error in the draft?
> >
> > _______________________________________________
> > 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
>

--001a113375c265285404ebb5b734
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Yes, it is an error. Someone else pointed it out to me rig=
ht after I submitted -05; will be fixed in the next rev.


    On Thu, Nov 21, 2013 at 10=
:17 AM, Cullen Jennings <fluffy@iii.ca> wrote:
    



    
On Nov 21, 2013, at 5:05 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
    

    
> Hi,
    
>
    
> I would assume that the text should say =E2=80=9Cupdate to a previousl=
y applied =E2=80=9Cpranswer=E2=80=9D.
    
>
    
> Regards,
    

    

    +1
    


    
>
    
> Christer
    
>
    
> From: rtcweb [mailto:rtcweb=
-bounces@ietf.org] On Behalf Of Harald Alvestrand
    
> Sent: 21. marraskuuta 2013 14:20
    
> To: rtcweb@ietf.org
    
> Subject: Re: [rtcweb] "pranswer" be applied as an update to =
a previously sent "answer"?
    
>
    
> On 11/20/2013 12:22 PM, Lijing (Jessie) wrote:
    
> draft-ietf-rtcweb-jsep-05 -----Section 4.1.3 says:
    
>
    
> "pranswer" indicates that a description should be parsed as =
an
    
> =C2=A0 =C2=A0answer, but not a final answer, and so should not result =
in the
    
> =C2=A0 =C2=A0freeing of allocated resources. =C2=A0It may result in th=
e start of media
    
> =C2=A0 =C2=A0transmission, if the answer does not specify an inactive =
media
    
> =C2=A0 =C2=A0direction. =C2=A0A description used as a "pranswer&q=
uot; may be applied as a
    
> =C2=A0 =C2=A0response to an "offer", or an update to a previ=
ously sent "answer".
    
>
    
> How can a pranswer be applied as an update to a previously sent answer=
? =C2=A0I am not sure what=E2=80=99s the corresponding scenario.
    
> From the state machine perspective, when answer is received, it enters=
 the stable state. At this point, the state machine can not directly jump t=
o local pranswer or remote pranswer state.
    
>
    
> My two cents: May be it needs more description or correction here.
    
>
    
> This makes sense, and is consistent with the state diagrams, if the la=
st "answer" is changed to "pranswer".
    
>
    
> Justin, is this an error in the draft?
    
>
    

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


    

--001a113375c265285404ebb5b734--

From ekr@rtfm.com  Thu Nov 21 12:30:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1786F1AE27F for ; Thu, 21 Nov 2013 12:30:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kDFbaYwKQdN for ; Thu, 21 Nov 2013 12:30:28 -0800 (PST)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9E35F1AE1B3 for ; Thu, 21 Nov 2013 12:30:27 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hq4so205718wib.8 for ; Thu, 21 Nov 2013 12:30:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iiPahy+CXhI2fmdtF3RRkOTZpn7covg0bQTIMqgnPmo=; b=PpK3mXvwNobndWVJUVhKlZ3/QwemE+P+F5WSsfcaruYurwbiA1TiFh9OczKG/T542m 8Z+a1lpQd4hixSYO2CEdxcub201gYJanw+UO2MCImsCFL15mAzrJVzTPOm9WE25dxPK/ C5uqS5tC8McrHRqPNSRZ3iCyKWscsuMepSdY5UTSU1h9s479TPCgpsQaWn6jtYd1b1gl Q8e6+RZXMw6j1GhO78gFX/5mHwgdNFj9iiut828t+GHkZwGNElRIWchzwoQ1dXIoklsf F/GYGqGkknP6NRpipQ78JtPEoBLwpZ3aF9q98nL/Ibs1bpwxYnxGhU7r7huiO1vk61LI lmBQ==
X-Gm-Message-State: ALoCoQlMeBoUy3lzrL0ELTi68QuLOTvRC1n31NQakHAFkSx0L0OIY6yZIivoh73MZkdzr+656SCG
X-Received: by 10.194.109.167 with SMTP id ht7mr7151970wjb.5.1385065820275; Thu, 21 Nov 2013 12:30:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 21 Nov 2013 12:29:40 -0800 (PST)
X-Originating-IP: [63.245.220.224]
In-Reply-To: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>    
From: Eric Rescorla 
Date: Thu, 21 Nov 2013 12:29:40 -0800
Message-ID: 
To: Steve Kann 
Content-Type: multipart/alternative; boundary=047d7bf10b1a355a2b04ebb5c489
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:30:35 -0000

--047d7bf10b1a355a2b04ebb5c489
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

https://github.com/ekr/codec-options



On Thu, Nov 21, 2013 at 12:17 PM, Eric Rescorla  wrote:

>
>
>
> On Thu, Nov 21, 2013 at 12:14 PM, Steve Kann  wrote:
>
>>
>> Do you plan to open-source your codec option generator?   It would make
>> modifying the list much more efficient.
>>
>
>
> I was thinking of distributing it as a binary module you could link into
> your
> mail client.
>
> -Ekr
>
>
>>
>>
>>
>> -Sent from an iOS mobile device
>>
>> On Nov 21, 2013, at 12:01 PM, Eric Rescorla  wrote:
>>
>> I would like to propose some additional alternatives.
>>
>> SHOULD: Theora
>> MUST: Theora
>> SHOULD: H.261
>> SHOULD: H.261 Theora
>> MUST: Theora; SHOULD: H.261
>> MUST: H.261
>> MUST: H.261; SHOULD: Theora
>> MUST: H.261 Theora
>> SHOULD: H.263
>> SHOULD: H.263 Theora
>> MUST: Theora; SHOULD: H.263
>> SHOULD: H.263 H.261
>> SHOULD: H.263 H.261 Theora
>> MUST: Theora; SHOULD: H.263 H.261
>> MUST: H.261; SHOULD: H.263
>> MUST: H.261; SHOULD: H.263 Theora
>> MUST: H.261 Theora; SHOULD: H.263
>> MUST: H.263
>> MUST: H.263; SHOULD: Theora
>> MUST: H.263 Theora
>> MUST: H.263; SHOULD: H.261
>> MUST: H.263; SHOULD: H.261 Theora
>> MUST: H.263 Theora; SHOULD: H.261
>> MUST: H.263 H.261
>> MUST: H.263 H.261; SHOULD: Theora
>> MUST: H.263 H.261 Theora
>> SHOULD: VP8
>> SHOULD: VP8 Theora
>> MUST: Theora; SHOULD: VP8
>> SHOULD: VP8 H.261
>> SHOULD: VP8 H.261 Theora
>> MUST: Theora; SHOULD: VP8 H.261
>> MUST: H.261; SHOULD: VP8
>> MUST: H.261; SHOULD: VP8 Theora
>> MUST: H.261 Theora; SHOULD: VP8
>> SHOULD: VP8 H.263
>> SHOULD: VP8 H.263 Theora
>> MUST: Theora; SHOULD: VP8 H.263
>> SHOULD: VP8 H.263 H.261
>> SHOULD: VP8 H.263 H.261 Theora
>> MUST: Theora; SHOULD: VP8 H.263 H.261
>> MUST: H.261; SHOULD: VP8 H.263
>> MUST: H.261; SHOULD: VP8 H.263 Theora
>> MUST: H.261 Theora; SHOULD: VP8 H.263
>> MUST: H.263; SHOULD: VP8
>> MUST: H.263; SHOULD: VP8 Theora
>> MUST: H.263 Theora; SHOULD: VP8
>> MUST: H.263; SHOULD: VP8 H.261
>> MUST: H.263; SHOULD: VP8 H.261 Theora
>> MUST: H.263 Theora; SHOULD: VP8 H.261
>> MUST: H.263 H.261; SHOULD: VP8
>> MUST: H.263 H.261; SHOULD: VP8 Theora
>> MUST: H.263 H.261 Theora; SHOULD: VP8
>> MUST: VP8
>> MUST: VP8; SHOULD: Theora
>> MUST: VP8 Theora
>>  MUST: VP8; SHOULD: H.261
>> MUST: VP8; SHOULD: H.261 Theora
>> MUST: VP8 Theora; SHOULD: H.261
>> MUST: VP8 H.261
>> MUST: VP8 H.261; SHOULD: Theora
>> MUST: VP8 H.261 Theora
>> MUST: VP8; SHOULD: H.263
>> MUST: VP8; SHOULD: H.263 Theora
>> MUST: VP8 Theora; SHOULD: H.263
>> MUST: VP8; SHOULD: H.263 H.261
>> MUST: VP8; SHOULD: H.263 H.261 Theora
>> MUST: VP8 Theora; SHOULD: H.263 H.261
>> MUST: VP8 H.261; SHOULD: H.263
>> MUST: VP8 H.261; SHOULD: H.263 Theora
>> MUST: VP8 H.261 Theora; SHOULD: H.263
>> MUST: VP8 H.263
>> MUST: VP8 H.263; SHOULD: Theora
>> MUST: VP8 H.263 Theora
>> MUST: VP8 H.263; SHOULD: H.261
>> MUST: VP8 H.263; SHOULD: H.261 Theora
>> MUST: VP8 H.263 Theora; SHOULD: H.261
>> MUST: VP8 H.263 H.261
>> MUST: VP8 H.263 H.261; SHOULD: Theora
>> MUST: VP8 H.263 H.261 Theora
>> SHOULD: H.264
>> SHOULD: H.264 Theora
>> MUST: Theora; SHOULD: H.264
>> SHOULD: H.264 H.261
>> SHOULD: H.264 H.261 Theora
>> MUST: Theora; SHOULD: H.264 H.261
>> MUST: H.261; SHOULD: H.264
>> MUST: H.261; SHOULD: H.264 Theora
>> MUST: H.261 Theora; SHOULD: H.264
>> SHOULD: H.264 H.263
>> SHOULD: H.264 H.263 Theora
>> MUST: Theora; SHOULD: H.264 H.263
>> SHOULD: H.264 H.263 H.261
>> SHOULD: H.264 H.263 H.261 Theora
>> MUST: Theora; SHOULD: H.264 H.263 H.261
>> MUST: H.261; SHOULD: H.264 H.263
>> MUST: H.261; SHOULD: H.264 H.263 Theora
>> MUST: H.261 Theora; SHOULD: H.264 H.263
>> MUST: H.263; SHOULD: H.264
>> MUST: H.263; SHOULD: H.264 Theora
>> MUST: H.263 Theora; SHOULD: H.264
>> MUST: H.263; SHOULD: H.264 H.261
>> MUST: H.263; SHOULD: H.264 H.261 Theora
>> MUST: H.263 Theora; SHOULD: H.264 H.261
>> MUST: H.263 H.261; SHOULD: H.264
>> MUST: H.263 H.261; SHOULD: H.264 Theora
>> MUST: H.263 H.261 Theora; SHOULD: H.264
>> SHOULD: H.264 VP8
>> SHOULD: H.264 VP8 Theora
>> MUST: Theora; SHOULD: H.264 VP8
>> SHOULD: H.264 VP8 H.261
>> SHOULD: H.264 VP8 H.261 Theora
>> MUST: Theora; SHOULD: H.264 VP8 H.261
>> MUST: H.261; SHOULD: H.264 VP8
>> MUST: H.261; SHOULD: H.264 VP8 Theora
>> MUST: H.261 Theora; SHOULD: H.264 VP8
>> SHOULD: H.264 VP8 H.263
>> SHOULD: H.264 VP8 H.263 Theora
>> MUST: Theora; SHOULD: H.264 VP8 H.263
>> SHOULD: H.264 VP8 H.263 H.261
>> SHOULD: H.264 VP8 H.263 H.261 Theora
>> MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
>> MUST: H.261; SHOULD: H.264 VP8 H.263
>> MUST: H.261; SHOULD: H.264 VP8 H.263 Theora
>> MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
>> MUST: H.263; SHOULD: H.264 VP8
>> MUST: H.263; SHOULD: H.264 VP8 Theora
>> MUST: H.263 Theora; SHOULD: H.264 VP8
>> MUST: H.263; SHOULD: H.264 VP8 H.261
>> MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
>> MUST: H.263 Theora; SHOULD: H.264 VP8 H.261
>> MUST: H.263 H.261; SHOULD: H.264 VP8
>> MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
>> MUST: H.263 H.261 Theora; SHOULD: H.264 VP8
>> MUST: VP8; SHOULD: H.264
>> MUST: VP8; SHOULD: H.264 Theora
>> MUST: VP8 Theora; SHOULD: H.264
>> MUST: VP8; SHOULD: H.264 H.261
>> MUST: VP8; SHOULD: H.264 H.261 Theora
>> MUST: VP8 Theora; SHOULD: H.264 H.261
>> MUST: VP8 H.261; SHOULD: H.264
>> MUST: VP8 H.261; SHOULD: H.264 Theora
>> MUST: VP8 H.261 Theora; SHOULD: H.264
>> MUST: VP8; SHOULD: H.264 H.263
>> MUST: VP8; SHOULD: H.264 H.263 Theora
>> MUST: VP8 Theora; SHOULD: H.264 H.263
>> MUST: VP8; SHOULD: H.264 H.263 H.261
>> MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
>> MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
>> MUST: VP8 H.261; SHOULD: H.264 H.263
>> MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
>> MUST: VP8 H.261 Theora; SHOULD: H.264 H.263
>> MUST: VP8 H.263; SHOULD: H.264
>> MUST: VP8 H.263; SHOULD: H.264 Theora
>> MUST: VP8 H.263 Theora; SHOULD: H.264
>> MUST: VP8 H.263; SHOULD: H.264 H.261
>> MUST: VP8 H.263; SHOULD: H.264 H.261 Theora
>> MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
>> MUST: VP8 H.263 H.261; SHOULD: H.264
>> MUST: VP8 H.263 H.261; SHOULD: H.264 Theora
>> MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
>> MUST: H.264
>> MUST: H.264; SHOULD: Theora
>> MUST: H.264 Theora
>> MUST: H.264; SHOULD: H.261
>> MUST: H.264; SHOULD: H.261 Theora
>> MUST: H.264 Theora; SHOULD: H.261
>> MUST: H.264 H.261
>> MUST: H.264 H.261; SHOULD: Theora
>> MUST: H.264 H.261 Theora
>> MUST: H.264; SHOULD: H.263
>> MUST: H.264; SHOULD: H.263 Theora
>> MUST: H.264 Theora; SHOULD: H.263
>> MUST: H.264; SHOULD: H.263 H.261
>> MUST: H.264; SHOULD: H.263 H.261 Theora
>> MUST: H.264 Theora; SHOULD: H.263 H.261
>> MUST: H.264 H.261; SHOULD: H.263
>> MUST: H.264 H.261; SHOULD: H.263 Theora
>> MUST: H.264 H.261 Theora; SHOULD: H.263
>> MUST: H.264 H.263
>> MUST: H.264 H.263; SHOULD: Theora
>> MUST: H.264 H.263 Theora
>> MUST: H.264 H.263; SHOULD: H.261
>> MUST: H.264 H.263; SHOULD: H.261 Theora
>> MUST: H.264 H.263 Theora; SHOULD: H.261
>> MUST: H.264 H.263 H.261
>> MUST: H.264 H.263 H.261; SHOULD: Theora
>> MUST: H.264 H.263 H.261 Theora
>> MUST: H.264; SHOULD: VP8
>> MUST: H.264; SHOULD: VP8 Theora
>> MUST: H.264 Theora; SHOULD: VP8
>> MUST: H.264; SHOULD: VP8 H.261
>> MUST: H.264; SHOULD: VP8 H.261 Theora
>> MUST: H.264 Theora; SHOULD: VP8 H.261
>> MUST: H.264 H.261; SHOULD: VP8
>> MUST: H.264 H.261; SHOULD: VP8 Theora
>> MUST: H.264 H.261 Theora; SHOULD: VP8
>> MUST: H.264; SHOULD: VP8 H.263
>> MUST: H.264; SHOULD: VP8 H.263 Theora
>> MUST: H.264 Theora; SHOULD: VP8 H.263
>> MUST: H.264; SHOULD: VP8 H.263 H.261
>> MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
>> MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
>> MUST: H.264 H.261; SHOULD: VP8 H.263
>> MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
>> MUST: H.264 H.261 Theora; SHOULD: VP8 H.263
>> MUST: H.264 H.263; SHOULD: VP8
>> MUST: H.264 H.263; SHOULD: VP8 Theora
>> MUST: H.264 H.263 Theora; SHOULD: VP8
>> MUST: H.264 H.263; SHOULD: VP8 H.261
>> MUST: H.264 H.263; SHOULD: VP8 H.261 Theora
>> MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
>> MUST: H.264 H.263 H.261; SHOULD: VP8
>> MUST: H.264 H.263 H.261; SHOULD: VP8 Theora
>> MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
>> MUST: H.264 VP8
>> MUST: H.264 VP8; SHOULD: Theora
>> MUST: H.264 VP8 Theora
>> MUST: H.264 VP8; SHOULD: H.261
>> MUST: H.264 VP8; SHOULD: H.261 Theora
>> MUST: H.264 VP8 Theora; SHOULD: H.261
>> MUST: H.264 VP8 H.261
>> MUST: H.264 VP8 H.261; SHOULD: Theora
>> MUST: H.264 VP8 H.261 Theora
>> MUST: H.264 VP8; SHOULD: H.263
>> MUST: H.264 VP8; SHOULD: H.263 Theora
>> MUST: H.264 VP8 Theora; SHOULD: H.263
>> MUST: H.264 VP8; SHOULD: H.263 H.261
>> MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
>> MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
>> MUST: H.264 VP8 H.261; SHOULD: H.263
>> MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
>> MUST: H.264 VP8 H.261 Theora; SHOULD: H.263
>> MUST: H.264 VP8 H.263
>> MUST: H.264 VP8 H.263; SHOULD: Theora
>> MUST: H.264 VP8 H.263 Theora
>> MUST: H.264 VP8 H.263; SHOULD: H.261
>> MUST: H.264 VP8 H.263; SHOULD: H.261 Theora
>> MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
>> MUST: H.264 VP8 H.263 H.261
>> MUST: H.264 VP8 H.263 H.261; SHOULD: Theora
>> MUST: H.264 VP8 H.263 H.261 Theora
>> SHOULD do 1 of {H.261, Theora}
>> SHOULD do 1 of {H.263, Theora}
>> SHOULD do 1 of {H.263, H.261}
>> SHOULD do 1 of {H.263, H.261, Theora}
>> SHOULD do 2 of {H.263, H.261, Theora}
>> SHOULD do 1 of {VP8, Theora}
>> SHOULD do 1 of {VP8, H.261}
>> SHOULD do 1 of {VP8, H.261, Theora}
>> SHOULD do 2 of {VP8, H.261, Theora}
>> SHOULD do 1 of {VP8, H.263}
>> SHOULD do 1 of {VP8, H.263, Theora}
>> SHOULD do 2 of {VP8, H.263, Theora}
>> SHOULD do 1 of {VP8, H.263, H.261}
>> SHOULD do 2 of {VP8, H.263, H.261}
>> SHOULD do 1 of {VP8, H.263, H.261, Theora}
>> SHOULD do 2 of {VP8, H.263, H.261, Theora}
>> SHOULD do 3 of {VP8, H.263, H.261, Theora}
>> SHOULD do 1 of {H.264, Theora}
>> SHOULD do 1 of {H.264, H.261}
>> SHOULD do 1 of {H.264, H.261, Theora}
>> SHOULD do 2 of {H.264, H.261, Theora}
>> SHOULD do 1 of {H.264, H.263}
>> SHOULD do 1 of {H.264, H.263, Theora}
>> SHOULD do 2 of {H.264, H.263, Theora}
>> SHOULD do 1 of {H.264, H.263, H.261}
>> SHOULD do 2 of {H.264, H.263, H.261}
>> SHOULD do 1 of {H.264, H.263, H.261, Theora}
>> SHOULD do 2 of {H.264, H.263, H.261, Theora}
>> SHOULD do 3 of {H.264, H.263, H.261, Theora}
>> SHOULD do 1 of {H.264, VP8}
>> SHOULD do 1 of {H.264, VP8, Theora}
>> SHOULD do 2 of {H.264, VP8, Theora}
>> SHOULD do 1 of {H.264, VP8, H.261}
>> SHOULD do 2 of {H.264, VP8, H.261}
>> SHOULD do 1 of {H.264, VP8, H.261, Theora}
>> SHOULD do 2 of {H.264, VP8, H.261, Theora}
>> SHOULD do 3 of {H.264, VP8, H.261, Theora}
>> SHOULD do 1 of {H.264, VP8, H.263}
>> SHOULD do 2 of {H.264, VP8, H.263}
>> SHOULD do 1 of {H.264, VP8, H.263, Theora}
>> SHOULD do 2 of {H.264, VP8, H.263, Theora}
>> SHOULD do 3 of {H.264, VP8, H.263, Theora}
>> SHOULD do 1 of {H.264, VP8, H.263, H.261}
>> SHOULD do 2 of {H.264, VP8, H.263, H.261}
>> SHOULD do 3 of {H.264, VP8, H.263, H.261}
>> SHOULD do 1 of {H.264, VP8, H.263, H.261, Theora}
>> SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
>> SHOULD do 3 of {H.264, VP8, H.263, H.261, Theora}
>> SHOULD do 4 of {H.264, VP8, H.263, H.261, Theora}
>> MUST do 1 of {H.261, Theora}
>> MUST do 1 of {H.263, Theora}
>> MUST do 1 of {H.263, H.261}
>> MUST do 1 of {H.263, H.261, Theora}
>> MUST do 2 of {H.263, H.261, Theora}
>> MUST do 1 of {VP8, Theora}
>> MUST do 1 of {VP8, H.261}
>> MUST do 1 of {VP8, H.261, Theora}
>> MUST do 2 of {VP8, H.261, Theora}
>> MUST do 1 of {VP8, H.263}
>> MUST do 1 of {VP8, H.263, Theora}
>> MUST do 2 of {VP8, H.263, Theora}
>> MUST do 1 of {VP8, H.263, H.261}
>> MUST do 2 of {VP8, H.263, H.261}
>> MUST do 1 of {VP8, H.263, H.261, Theora}
>> MUST do 2 of {VP8, H.263, H.261, Theora}
>> MUST do 3 of {VP8, H.263, H.261, Theora}
>> MUST do 1 of {H.264, Theora}
>> MUST do 1 of {H.264, H.261}
>> MUST do 1 of {H.264, H.261, Theora}
>> MUST do 2 of {H.264, H.261, Theora}
>> MUST do 1 of {H.264, H.263}
>> MUST do 1 of {H.264, H.263, Theora}
>> MUST do 2 of {H.264, H.263, Theora}
>> MUST do 1 of {H.264, H.263, H.261}
>> MUST do 2 of {H.264, H.263, H.261}
>> MUST do 1 of {H.264, H.263, H.261, Theora}
>> MUST do 2 of {H.264, H.263, H.261, Theora}
>> MUST do 3 of {H.264, H.263, H.261, Theora}
>> MUST do 1 of {H.264, VP8}
>> MUST do 1 of {H.264, VP8, Theora}
>> MUST do 2 of {H.264, VP8, Theora}
>> MUST do 1 of {H.264, VP8, H.261}
>> MUST do 2 of {H.264, VP8, H.261}
>> MUST do 1 of {H.264, VP8, H.261, Theora}
>> MUST do 2 of {H.264, VP8, H.261, Theora}
>> MUST do 3 of {H.264, VP8, H.261, Theora}
>> MUST do 1 of {H.264, VP8, H.263}
>> MUST do 2 of {H.264, VP8, H.263}
>> MUST do 1 of {H.264, VP8, H.263, Theora}
>> MUST do 2 of {H.264, VP8, H.263, Theora}
>> MUST do 3 of {H.264, VP8, H.263, Theora}
>> MUST do 1 of {H.264, VP8, H.263, H.261}
>> MUST do 2 of {H.264, VP8, H.263, H.261}
>> MUST do 3 of {H.264, VP8, H.263, H.261}
>> MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
>> MUST do 2 of {H.264, VP8, H.263, H.261, Theora}
>> MUST do 3 of {H.264, VP8, H.263, H.261, Theora}
>> MUST do 4 of {H.264, VP8, H.263, H.261, Theora}
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Nov 21, 2013 at 11:27 AM, Cullen Jennings  wrote:
>>
>>>
>>> Added a
>>>
>>> #11     =95 MUST implement at least two of {VP8, H.264 CBP, H.263}
>>>
>>>
>>> On Nov 21, 2013, at 11:20 AM, David Singer  wrote:
>>>
>>> > Chairs
>>> >
>>> > can we add this as an option to the formal list, so we get formal
>>> feedback on its acceptability, please?
>>> >
>>> > =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
>>> >
>>> >
>>> > I think this may be the best (maybe only) way to tease out how much
>>> risk people perceive.
>>> >
>>> > Many thanks
>>> >
>>> > On Nov 21, 2013, at 9:22 , Maik Merten 
>>> wrote:
>>> >
>>> >> Cleary H.263 is preferable from an engineering standpoint (as is,
>>> e.g., MPEG-1 Part 2): better performance, more deployments. The central
>>> question is, however, if those can actually be implemented without some
>>> sort of licensing.
>>> >>
>>> >> If they can: Aweseome! However, this may not be determinable without
>>> a review by people who are knowledgeable in the field of IPR, i.e., "ac=
tual
>>> lawyers". I understand that H.263 is not yet old enough to automaticall=
y be
>>> considered "safe" (and neither is MPEG-1 Part 2, although it is closer)=
.
>>> >>
>>> >> Best regards,
>>> >>
>>> >> Maik
>>> >>
>>> >> Am 20.11.2013 20:42, schrieb David Singer:
>>> >>> I think we should think hard about H.263 instead of H.261 as the
>>> third fallback.  Why?
>>> >>>
>>> >>> http://www.itu.int/rec/T-REC-H.263/
>>> >>>
>>> >>>
>>> >>>
>>> >>> H.263 was first published in March 1996, so it's 17 years old.  The
>>> restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more
>>> recent amendments deal with this (and a plethora of other issues), so w=
e=92d
>>> need to settle on which of those are mandatory (the usual profiling
>>> discussion).
>>> >>>
>>> >>> There are 34 records in the patent database against H.261, mostly
>>> from 1989 but one as recent as 2005 (though that is a re-file).  That's=
 2.2
>>> (reciprocity), as was one other I checked.
>>> >>>
>>> >>> Rather surprisingly, there are only 31 against H.263!  The most
>>> recent is 2011, and is also option 2.  Most are 1997-2001.
>>> >>>
>>> >>>
>>> >>> On this quick glance, H.263 appears no worse than H.261. IANAL (as =
I
>>> am sure you have all noticed).
>>> >>>
>>> >>>
>>> >>> H.263 is much more widely supported and mandated.  It has been
>>> mandated in the 3GPP specs for years (for lots of services, including
>>> videoconf), and is effectively the fallback codec today in the industry=
, as
>>> I understand.  It was ubiquitous in video telephony for years, and I
>>> suspect many of those systems still ship it.
>>> >>>
>>> >>> So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 =
work?
>>> >>>
>>> >>> (I am asking the question, not even answering on behalf of my
>>> company, yet.  Let=92s get the issues on the table.)
>>> >>>
>>> >>>
>>> >>> David Singer
>>> >>> Multimedia and Software Standards, Apple Inc.
>>> >>>
>>> >>> _______________________________________________
>>> >>> 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
>>> >
>>> > David Singer
>>> > Multimedia and Software Standards, Apple Inc.
>>> >
>>> > _______________________________________________
>>> > 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
>>
>>
>

--047d7bf10b1a355a2b04ebb5c489
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




    On Thu, Nov 21, 2013 at 12:17 PM=
, Eric Rescorla <ekr@rtfm.com> wrote:
    





    On Thu, Nov 21, 20=
13 at 12:14 PM, Steve Kann <stevek@stevek.com> wrote:
    




    Do you=
 plan to open-source your codec option generator? =A0 It would make modifyi=
ng the list much more efficient. 
    




    =A0
    I was thinking o=
f distributing it as a binary module you could link into your
    mai=
l client.

    -Ekr
    


    





    -Sent from an<=
span>=A0iOS mobile device

    On Nov 21, 2013, a=
t 12:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:
    



    I would like to p=
ropose some additional alternatives.

    SHOULD: Theora=

    MUST: Theora
    SHOULD: H.261
    SHOULD: H.261 The=
ora
    



    MUST: Theora; SHOULD: H.261
    



    MUST: H.261
    MUST: H.261; SHOULD: Theora
    MUST: H.26=
1 Theora
    SHOULD: H.263
    SHOULD: H.263 Theora
    M=
UST: Theora; SHOULD: H.263
    SHOULD: H.263 H.261
    SHOULD: =
H.263 H.261 Theora
    






    MUST: Theora; SHOULD: H.263 H.261
    MUST: H.261; SHOULD: H.263=

    MUST: H.261; SHOULD: H.263 Theora
    MUST: H.261 Theora; =
SHOULD: H.263
    MUST: H.263
    MUST: H.263; SHOULD: Theora






    MUST: H.263 Theora
    MUST: H.263; SHOULD: H.261
    MUST=
: H.263; SHOULD: H.261 Theora
    MUST: H.263 Theora; SHOULD: H.261
    MUST: H.263 H.261
    MUST: H.263 H.261; SHOULD: Theora






    MUST: H.263 H.261 Theora
    SHOULD: VP8
    SHOULD: VP8 T=
heora
    MUST: Theora; SHOULD: VP8
    SHOULD: VP8 H.261
    =

    SHOULD: VP8 H.261 Theora
    MUST: Theora; SHOULD: VP8 H.261






    MUST: H.261; SHOULD: VP8
    MUST: H.261; SHOULD: VP8 Theora
    MUST: H.261 Theora; SHOULD: VP8
    SHOULD: VP8 H.263
    SHOULD: VP8 H.263 Theora
    MUST: Theora; SHOULD: VP8 H.263
    






    SHOULD: VP8 H.263 H.261
    SHOULD: VP8 H.263 H.261 Theora
    =

    MUST: Theora; SHOULD: VP8 H.263 H.261
    MUST: H.261; SHOULD: V=
P8 H.263
    MUST: H.261; SHOULD: VP8 H.263 Theora
    MUST: H.=
261 Theora; SHOULD: VP8 H.263
    






    MUST: H.263; SHOULD: VP8
    MUST: H.263; SHOULD: VP8 Theora
    MUST: H.263 Theora; SHOULD: VP8
    MUST: H.263; SHOULD: VP8 H=
.261
    MUST: H.263; SHOULD: VP8 H.261 Theora
    MUST: H.263 =
Theora; SHOULD: VP8 H.261
    






    MUST: H.263 H.261; SHOULD: VP8
    MUST: H.263 H.261; SHOULD: VP=
8 Theora
    MUST: H.263 H.261 Theora; SHOULD: VP8
    MUST: VP=
8
    MUST: VP8; SHOULD: Theora
    MUST: VP8 Theora
    





    
MUST: VP8; SHOULD: H.261
    MUST: VP8; SHOULD: H.261 Theora
    MUST: VP8 Theora; SHOULD: H.261
    MUST: VP8 H.261
    MUST:=
 VP8 H.261; SHOULD: Theora
    MUST: VP8 H.261 Theora
    




MUST: VP8; SHOULD: H.263
    

    MUST: VP8; SHOULD: H.263 Theora
    MUST: VP8 Theora; SHOULD: H.=
263
    MUST: VP8; SHOULD: H.263 H.261
    MUST: VP8; SHOULD: H=
.263 H.261 Theora
    MUST: VP8 Theora; SHOULD: H.263 H.261
    






    MUST: VP8 H.261; SHOULD: H.263
    MUST: VP8 H.261; SHOULD: H.26=
3 Theora
    MUST: VP8 H.261 Theora; SHOULD: H.263
    MUST: VP=
8 H.263
    MUST: VP8 H.263; SHOULD: Theora
    MUST: VP8 H.263=
 Theora
    






    MUST: VP8 H.263; SHOULD: H.261
    MUST: VP8 H.263; SHOULD: H.26=
1 Theora
    MUST: VP8 H.263 Theora; SHOULD: H.261
    MUST: VP=
8 H.263 H.261
    MUST: VP8 H.263 H.261; SHOULD: Theora
    





MUST: VP8 H.263 H.261 Theora
    SHOULD: H.264
    SHOULD: H.26=
4 Theora
    MUST: Theora; SHOULD: H.264
    SHOULD: H.264 H.26=
1
    SHOULD: H.264 H.261 Theora
    MUST: Theora; SHOULD: H.26=
4 H.261
    






    MUST: H.261; SHOULD: H.264
    MUST: H.261; SHOULD: H.264 Theora=

    MUST: H.261 Theora; SHOULD: H.264
    SHOULD: H.264 H.263<=
/div>
    SHOULD: H.264 H.263 Theora
    MUST: Theora; SHOULD: H.264 =
H.263
    






    SHOULD: H.264 H.263 H.261
    SHOULD: H.264 H.263 H.261 Theora
    MUST: Theora; SHOULD: H.264 H.263 H.261
    MUST: H.261; SHO=
ULD: H.264 H.263
    MUST: H.261; SHOULD: H.264 H.263 Theora
    






    MUST: H.261 Theora; SHOULD: H.264 H.263
    MUST: H.263; SHOULD:=
 H.264
    MUST: H.263; SHOULD: H.264 Theora
    MUST: H.263 Th=
eora; SHOULD: H.264
    MUST: H.263; SHOULD: H.264 H.261
    





MUST: H.263; SHOULD: H.264 H.261 Theora
    MUST: H.263 Theora; SHOUL=
D: H.264 H.261
    MUST: H.263 H.261; SHOULD: H.264
    MUST: H=
.263 H.261; SHOULD: H.264 Theora
    MUST: H.263 H.261 Theora; SHOULD=
: H.264
    






    SHOULD: H.264 VP8
    SHOULD: H.264 VP8 Theora
    MUST: T=
heora; SHOULD: H.264 VP8
    SHOULD: H.264 VP8 H.261
    SHOULD=
: H.264 VP8 H.261 Theora
    MUST: Theora; SHOULD: H.264 VP8 H.261






    MUST: H.261; SHOULD: H.264 VP8
    MUST: H.261; SHOULD: H.264 VP=
8 Theora
    MUST: H.261 Theora; SHOULD: H.264 VP8
    SHOULD: =
H.264 VP8 H.263
    SHOULD: H.264 VP8 H.263 Theora
    MUST: Th=
eora; SHOULD: H.264 VP8 H.263
    






    SHOULD: H.264 VP8 H.263 H.261
    SHOULD: H.264 VP8 H.263 H.261 =
Theora
    MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
    MUST=
: H.261; SHOULD: H.264 VP8 H.263
    MUST: H.261; SHOULD: H.264 VP8 H=
.263 Theora
    






    MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
    MUST: H.263; SHO=
ULD: H.264 VP8
    MUST: H.263; SHOULD: H.264 VP8 Theora
    MU=
ST: H.263 Theora; SHOULD: H.264 VP8
    MUST: H.263; SHOULD: H.264 VP=
8 H.261
    






    MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
    MUST: H.263 Theo=
ra; SHOULD: H.264 VP8 H.261
    MUST: H.263 H.261; SHOULD: H.264 VP8<=
/div>
    MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
    MUST: H.263=
 H.261 Theora; SHOULD: H.264 VP8
    






    MUST: VP8; SHOULD: H.264
    MUST: VP8; SHOULD: H.264 Theora
    MUST: VP8 Theora; SHOULD: H.264
    MUST: VP8; SHOULD: H.264 H=
.261
    MUST: VP8; SHOULD: H.264 H.261 Theora
    MUST: VP8 Th=
eora; SHOULD: H.264 H.261
    






    MUST: VP8 H.261; SHOULD: H.264
    MUST: VP8 H.261; SHOULD: H.26=
4 Theora
    MUST: VP8 H.261 Theora; SHOULD: H.264
    MUST: VP=
8; SHOULD: H.264 H.263
    MUST: VP8; SHOULD: H.264 H.263 Theora






    MUST: VP8 Theora; SHOULD: H.264 H.263
    MUST: VP8; SHOULD: H.2=
64 H.263 H.261
    MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
    <=
div>MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
    MUST: VP8 H.261; =
SHOULD: H.264 H.263
    






    MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
    MUST: VP8 H.261 =
Theora; SHOULD: H.264 H.263
    MUST: VP8 H.263; SHOULD: H.264
    <=
div>MUST: VP8 H.263; SHOULD: H.264 Theora
    MUST: VP8 H.263 Theora;=
 SHOULD: H.264
    






    MUST: VP8 H.263; SHOULD: H.264 H.261
    MUST: VP8 H.263; SHOULD=
: H.264 H.261 Theora
    MUST: VP8 H.263 Theora; SHOULD: H.264 H.261<=
/div>
    MUST: VP8 H.263 H.261; SHOULD: H.264
    MUST: VP8 H.263 H.=
261; SHOULD: H.264 Theora
    






    MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
    MUST: H.264
    MUST: H.264; SHOULD: Theora
    MUST: H.264 Theora
    MU=
ST: H.264; SHOULD: H.261
    MUST: H.264; SHOULD: H.261 Theora
    






    MUST: H.264 Theora; SHOULD: H.261
    MUST: H.264 H.261
    MUST: H.264 H.261; SHOULD: Theora
    MUST: H.264 H.261 Theora
    MUST: H.264; SHOULD: H.263
    MUST: H.264; SHOULD: H.263 Theor=
a
    






    MUST: H.264 Theora; SHOULD: H.263
    MUST: H.264; SHOULD: H.263=
 H.261
    MUST: H.264; SHOULD: H.263 H.261 Theora
    MUST: H.=
264 Theora; SHOULD: H.263 H.261
    MUST: H.264 H.261; SHOULD: H.263<=
/div>






    MUST: H.264 H.261; SHOULD: H.263 Theora
    MUST: H.264 H.261 Th=
eora; SHOULD: H.263
    MUST: H.264 H.263
    MUST: H.264 H.263=
; SHOULD: Theora
    MUST: H.264 H.263 Theora
    MUST: H.264 H=
.263; SHOULD: H.261
    






    MUST: H.264 H.263; SHOULD: H.261 Theora
    MUST: H.264 H.263 Th=
eora; SHOULD: H.261
    MUST: H.264 H.263 H.261
    MUST: H.264=
 H.263 H.261; SHOULD: Theora
    MUST: H.264 H.263 H.261 Theora
    






    MUST: H.264; SHOULD: VP8
    MUST: H.264; SHOULD: VP8 Theora
    MUST: H.264 Theora; SHOULD: VP8
    MUST: H.264; SHOULD: VP8 H=
.261
    MUST: H.264; SHOULD: VP8 H.261 Theora
    MUST: H.264 =
Theora; SHOULD: VP8 H.261
    






    MUST: H.264 H.261; SHOULD: VP8
    MUST: H.264 H.261; SHOULD: VP=
8 Theora
    MUST: H.264 H.261 Theora; SHOULD: VP8
    MUST: H.=
264; SHOULD: VP8 H.263
    MUST: H.264; SHOULD: VP8 H.263 Theora






    MUST: H.264 Theora; SHOULD: VP8 H.263
    MUST: H.264; SHOULD: V=
P8 H.263 H.261
    MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
    <=
div>MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
    MUST: H.264 H.261=
; SHOULD: VP8 H.263
    






    MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
    MUST: H.264 H.26=
1 Theora; SHOULD: VP8 H.263
    MUST: H.264 H.263; SHOULD: VP8
    <=
div>MUST: H.264 H.263; SHOULD: VP8 Theora
    MUST: H.264 H.263 Theor=
a; SHOULD: VP8
    






    MUST: H.264 H.263; SHOULD: VP8 H.261
    MUST: H.264 H.263; SHOU=
LD: VP8 H.261 Theora
    MUST: H.264 H.263 Theora; SHOULD: VP8 H.261<=
/div>
    MUST: H.264 H.263 H.261; SHOULD: VP8
    MUST: H.264 H.263 =
H.261; SHOULD: VP8 Theora
    






    MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
    MUST: H.264 VP8<=
/div>
    MUST: H.264 VP8; SHOULD: Theora
    MUST: H.264 VP8 Theora<=
/div>
    MUST: H.264 VP8; SHOULD: H.261
    MUST: H.264 VP8; SHOULD:=
 H.261 Theora
    






    MUST: H.264 VP8 Theora; SHOULD: H.261
    MUST: H.264 VP8 H.261<=
/div>
    MUST: H.264 VP8 H.261; SHOULD: Theora
    MUST: H.264 VP8 H=
.261 Theora
    MUST: H.264 VP8; SHOULD: H.263
    MUST: H.264 =
VP8; SHOULD: H.263 Theora
    






    MUST: H.264 VP8 Theora; SHOULD: H.263
    MUST: H.264 VP8; SHOUL=
D: H.263 H.261
    MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
    <=
div>MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
    MUST: H.264 VP8 H=
.261; SHOULD: H.263
    






    MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
    MUST: H.264 VP8 =
H.261 Theora; SHOULD: H.263
    MUST: H.264 VP8 H.263
    MUST:=
 H.264 VP8 H.263; SHOULD: Theora
    MUST: H.264 VP8 H.263 Theora






    MUST: H.264 VP8 H.263; SHOULD: H.261
    MUST: H.264 VP8 H.263; =
SHOULD: H.261 Theora
    MUST: H.264 VP8 H.263 Theora; SHOULD: H.261<=
/div>
    MUST: H.264 VP8 H.263 H.261
    MUST: H.264 VP8 H.263 H.261=
; SHOULD: Theora
    






    MUST: H.264 VP8 H.263 H.261 Theora
    SHOULD do 1 of {H.261, Th=
eora}
    SHOULD do 1 of {H.263, Theora}
    SHOULD do 1 of {H.=
263, H.261}
    SHOULD do 1 of {H.263, H.261, Theora}
    




SHOULD do 2 of {H.263, H.261, Theora}
    

    SHOULD do 1 of {VP8, Theora}
    SHOULD do 1 of {VP8, H.261}
    SHOULD do 1 of {VP8, H.261, Theora}
    SHOULD do 2 of {VP8, H=
.261, Theora}
    SHOULD do 1 of {VP8, H.263}
    SHOULD do 1 o=
f {VP8, H.263, Theora}
    






    SHOULD do 2 of {VP8, H.263, Theora}
    SHOULD do 1 of {VP8, H.2=
63, H.261}
    SHOULD do 2 of {VP8, H.263, H.261}
    SHOULD do=
 1 of {VP8, H.263, H.261, Theora}
    SHOULD do 2 of {VP8, H.263, H.2=
61, Theora}
    






    SHOULD do 3 of {VP8, H.263, H.261, Theora}
    SHOULD do 1 of {H=
.264, Theora}
    SHOULD do 1 of {H.264, H.261}
    SHOULD do 1=
 of {H.264, H.261, Theora}
    SHOULD do 2 of {H.264, H.261, Theora}<=
/div>






    SHOULD do 1 of {H.264, H.263}
    SHOULD do 1 of {H.264, H.263, =
Theora}
    SHOULD do 2 of {H.264, H.263, Theora}
    SHOULD do=
 1 of {H.264, H.263, H.261}
    SHOULD do 2 of {H.264, H.263, H.261}<=
/div>






    SHOULD do 1 of {H.264, H.263, H.261, Theora}
    SHOULD do 2 of =
{H.264, H.263, H.261, Theora}
    SHOULD do 3 of {H.264, H.263, H.261=
, Theora}
    SHOULD do 1 of {H.264, VP8}
    SHOULD do 1 of {H=
.264, VP8, Theora}
    






    SHOULD do 2 of {H.264, VP8, Theora}
    SHOULD do 1 of {H.264, V=
P8, H.261}
    SHOULD do 2 of {H.264, VP8, H.261}
    SHOULD do=
 1 of {H.264, VP8, H.261, Theora}
    SHOULD do 2 of {H.264, VP8, H.2=
61, Theora}
    






    SHOULD do 3 of {H.264, VP8, H.261, Theora}
    SHOULD do 1 of {H=
.264, VP8, H.263}
    SHOULD do 2 of {H.264, VP8, H.263}
    SH=
OULD do 1 of {H.264, VP8, H.263, Theora}
    SHOULD do 2 of {H.264, V=
P8, H.263, Theora}
    






    SHOULD do 3 of {H.264, VP8, H.263, Theora}
    SHOULD do 1 of {H=
.264, VP8, H.263, H.261}
    SHOULD do 2 of {H.264, VP8, H.263, H.261=
}
    SHOULD do 3 of {H.264, VP8, H.263, H.261}
    SHOULD do 1=
 of {H.264, VP8, H.263, H.261, Theora}
    






    SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
    SHOULD do =
3 of {H.264, VP8, H.263, H.261, Theora}
    SHOULD do 4 of {H.264, VP=
8, H.263, H.261, Theora}
    MUST do 1 of {H.261, Theora}
    





MUST do 1 of {H.263, Theora}
    MUST do 1 of {H.263, H.261}
    MUST do 1 of {H.263, H.261, Theora}
    MUST do 2 of {H.263, H.261,=
 Theora}
    MUST do 1 of {VP8, Theora}
    MUST do 1 of {VP8, =
H.261}
    






    MUST do 1 of {VP8, H.261, Theora}
    MUST do 2 of {VP8, H.261, =
Theora}
    MUST do 1 of {VP8, H.263}
    MUST do 1 of {VP8, H.=
263, Theora}
    MUST do 2 of {VP8, H.263, Theora}
    MUST do =
1 of {VP8, H.263, H.261}
    






    MUST do 2 of {VP8, H.263, H.261}
    MUST do 1 of {VP8, H.263, H=
.261, Theora}
    MUST do 2 of {VP8, H.263, H.261, Theora}
    =
MUST do 3 of {VP8, H.263, H.261, Theora}
    MUST do 1 of {H.264, The=
ora}
    






    MUST do 1 of {H.264, H.261}
    MUST do 1 of {H.264, H.261, Theo=
ra}
    MUST do 2 of {H.264, H.261, Theora}
    MUST do 1 of {H=
.264, H.263}
    MUST do 1 of {H.264, H.263, Theora}
    MUST d=
o 2 of {H.264, H.263, Theora}
    






    MUST do 1 of {H.264, H.263, H.261}
    MUST do 2 of {H.264, H.26=
3, H.261}
    MUST do 1 of {H.264, H.263, H.261, Theora}
    MU=
ST do 2 of {H.264, H.263, H.261, Theora}
    MUST do 3 of {H.264, H.2=
63, H.261, Theora}
    






    MUST do 1 of {H.264, VP8}
    MUST do 1 of {H.264, VP8, Theora}<=
/div>
    MUST do 2 of {H.264, VP8, Theora}
    MUST do 1 of {H.264, =
VP8, H.261}
    MUST do 2 of {H.264, VP8, H.261}
    MUST do 1 =
of {H.264, VP8, H.261, Theora}
    






    MUST do 2 of {H.264, VP8, H.261, Theora}
    MUST do 3 of {H.264=
, VP8, H.261, Theora}
    MUST do 1 of {H.264, VP8, H.263}
    =
MUST do 2 of {H.264, VP8, H.263}
    MUST do 1 of {H.264, VP8, H.263,=
 Theora}
    






    MUST do 2 of {H.264, VP8, H.263, Theora}
    MUST do 3 of {H.264=
, VP8, H.263, Theora}
    MUST do 1 of {H.264, VP8, H.263, H.261}
    MUST do 2 of {H.264, VP8, H.263, H.261}
    MUST do 3 of {H.26=
4, VP8, H.263, H.261}
    






    MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
    MUST do 2 of=
 {H.264, VP8, H.263, H.261, Theora}
    MUST do 3 of {H.264, VP8, H.2=
63, H.261, Theora}
    MUST do 4 of {H.264, VP8, H.263, H.261, Theora=
}
    











    =



    On Thu,=
 Nov 21, 2013 at 11:27 AM, Cullen Jennings <fluffy@iii.ca> wrote=
:
    







    
Added a
    

    
#11 =A0 =A0 =95 MUST implement at least two of {VP8, H.264 CBP, H.263}
    


    

    
On Nov 21, 2013, at 11:20 AM, David Singer <singer@apple.com> wrote:
    

    
> Chairs
    
>
    
> can we add this as an option to the formal list, so we get formal feed=
back on its acceptability, please?
    
>
    
> =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
    
>
    
>
    
> I think this may be the best (maybe only) way to tease out how much ri=
sk people perceive.
    
>
    
> Many thanks
    
>
    
> On Nov 21, 2013, at 9:22 , Maik Merten <maikmerten@googlemail.com> wrote=
:
    
>
    
>> Cleary H.263 is preferable from an engineering standpoint (as is, =
e.g., MPEG-1 Part 2): better performance, more deployments. The central que=
stion is, however, if those can actually be implemented without some sort o=
f licensing.
    






>>
    
>> If they can: Aweseome! However, this may not be determinable witho=
ut a review by people who are knowledgeable in the field of IPR, i.e., &quo=
t;actual lawyers". I understand that H.263 is not yet old enough to au=
tomatically be considered "safe" (and neither is MPEG-1 Part 2, a=
lthough it is closer).
    






>>
    
>> Best regards,
    
>>
    
>> Maik
    
>>
    
>> Am 20.11.2013 20:42, schrieb David Singer:
    
>>> I think we should think hard about H.263 instead of H.261 as t=
he third fallback. =A0Why?
    
>>>
    
>>> http://www.itu.int/rec/T-REC-H.263/
    
>>>
    
>>>
    
>>>
    
>>> H.263 was first published in March 1996, so it's 17 years =
old. =A0The restrictions (e.g. on picture size) are no WORSE than H.261. =
=A0Yes, more recent amendments deal with this (and a plethora of other issu=
es), so we=92d need to settle on which of those are mandatory (the usual pr=
ofiling discussion).
    






>>>
    
>>> There are 34 records in the patent database against H.261, mos=
tly from 1989 but one as recent as 2005 (though that is a re-file). =A0That=
's 2.2 (reciprocity), as was one other I checked.
    
>>>
    
>>> Rather surprisingly, there are only 31 against H.263! =A0The m=
ost recent is 2011, and is also option 2. =A0Most are 1997-2001.
    
>>>
    
>>>
    
>>> On this quick glance, H.263 appears no worse than H.261. IANAL=
 (as I am sure you have all noticed).
    
>>>
    
>>>
    
>>> H.263 is much more widely supported and mandated. =A0It has be=
en mandated in the 3GPP specs for years (for lots of services, including vi=
deoconf), and is effectively the fallback codec today in the industry, as I=
 understand. =A0It was ubiquitous in video telephony for years, and I suspe=
ct many of those systems still ship it.
    






>>>
    
>>> So, would =93MUST implement at least two of (H.264, VP8, H.263=
)=94 work?
    
>>>
    
>>> (I am asking the question, not even answering on behalf of my =
company, yet. =A0Let=92s get the issues on the table.)
    
>>>
    
>>>
    
>>> David Singer
    
>>> Multimedia and Software Standards, Apple Inc.
    
>>>
    
>>> _______________________________________________
    
>>> rtcweb mailing list
    
>>> rtcweb@ie=
tf.org
    
>>> https://www.ietf.org/mailman/listinfo/rtcweb
    
>>>
    
>>
    
>> _______________________________________________
    
>> rtcweb mailing list
    
>> rtcweb@ietf.o=
rg
    
>> https://www.ietf.org/mailman/listinfo/rtcweb
    
>
    
> David Singer
    
> Multimedia and Software Standards, Apple Inc.
    
>
    
> _______________________________________________
    
> 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<=
/a>
    


    https://www.ietf.org/mailman/listinfo/rtcweb

    




    

--047d7bf10b1a355a2b04ebb5c489--


From sslivinski@lifesize.com  Thu Nov 21 12:32:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E881AE2E6 for ; Thu, 21 Nov 2013 12:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2JzQaLlxoYc for ; Thu, 21 Nov 2013 12:32:22 -0800 (PST)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id 658E81AE291 for ; Thu, 21 Nov 2013 12:32:22 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUo5tz8BR3e9VlsJmPL6G/SNuYr+l35YI@postini.com; Thu, 21 Nov 2013 12:32:16 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 14:28:37 -0600
From: Stefan Slivinski 
To: "'rtcweb@ietf.org'" 
Date: Thu, 21 Nov 2013 14:28:36 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7m9nH+O39+xfW2QtaUtKuNSDen8gAAc+Lt
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7E0@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <528E69E2.9020208@librevideo.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:32:24 -0000

So this is my concern.  On iOS for example it's pretty easy do decode large=
 resolutions in software only using either h.264 or vp8 (and for that matte=
r vp9 and h.265).  So making both h264 and vp8 decoders mandatory isn't a b=
ig technical problem.  The encoder however is a bigger issue.  A reasonably=
 good implementation requires roughly 3x the compute to do this in software=
.  iOS however supports hardware encoding using H264 so there is an obvious=
 advantage to using that specific codec on that device.  The same might be =
true for VP8 on other architectures.

So requiring all webrtc implementations to support H264 and VP8 gives the f=
lexibility to pick the most appropriate encoder for a given architecture.


----- Original Message -----
From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
Sent: Thursday, November 21, 2013 02:15 PM=0A=
To: rtcweb@ietf.org 
Subject: Re: [rtcweb] Proposed Video Selection Process

On 11/21/2013 03:02 PM, Stefan Slivinski wrote:
> I in no way intended to suggest  a specific implementation of a video cod=
ec.  My question was around whether we are voting on requiring decoders (my=
 assumption) or both encoders and decoders

The discussions, up to this point, have been about choosing an MTI video
format so that rtcweb endpoints can communicate with one-another.  I am
not sure how this goal can be achieved without having an encoder and a
decoder on both ends, sharing at least one common format, whether it is
H.261, Theora, H.264, VP8, or something else.

--=20
Libre Video
http://librevideo.org
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

From mohammedsraad@raadtech.com  Thu Nov 21 12:32:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F1F1AE291 for ; Thu, 21 Nov 2013 12:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zkybqm_YhIOd for ; Thu, 21 Nov 2013 12:32:21 -0800 (PST)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 182AA1AE27F for ; Thu, 21 Nov 2013 12:32:20 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id a1so281390wgh.12 for ; Thu, 21 Nov 2013 12:32:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hzdRETZHS2spv7/m3HFk/uz85nS/Rk+mPu7B9qW+WHY=; b=T+JZvf2h6YwI2wHraGrIcn7d9zfoJiLY6iPrI9cXuhvyQUg0yGW3yFuyWghlFacMc1 E48M6PSqymCze3bp0OpZJEQGtCr5K9l/258L1DGT0U6LEq23/WL6pJVJOZ+fhanA38nA /TaY6uHDieBmS4pBLeOM0TM+vSLyVjPJmci1jC1dh1fk7PZDd7IyDohEKnbj/ITZGSGf SBnPWQ+vHgYxIMynv4ieajNuLBFb/TA8gUykI76jGWyu4sKSkiVdoZSn8Ox2b5fvsaPk 3JmjOt2q2r+Fd/K7bw7a3d7zrP1brfC8YfXBKMoGM2SzMouqdMo4bELQM68wrdzZ1u+U 6UwA==
X-Gm-Message-State: ALoCoQlOIFu/EKCO1+DGUilP4Bt0fvAe0FqMtsMt2UuWsxigHq6Aqkzs1Dy6ADra3+lUgjNaqwyy
MIME-Version: 1.0
X-Received: by 10.194.219.1 with SMTP id pk1mr7088204wjc.36.1385065933870; Thu, 21 Nov 2013 12:32:13 -0800 (PST)
Received: by 10.194.179.166 with HTTP; Thu, 21 Nov 2013 12:32:13 -0800 (PST)
Received: by 10.194.179.166 with HTTP; Thu, 21 Nov 2013 12:32:13 -0800 (PST)
In-Reply-To: 
References: <528D6C63.7050607@bbs.darktech.org> <13BED03E-6853-4E49-BCCE-1FFB39571D36@yahoo.fr> <5A2BC34D-FE4D-4420-B52F-729087815F37@cisco.com>  <528E5E3C.70008@bbs.darktech.org> 
Date: Fri, 22 Nov 2013 07:32:13 +1100
Message-ID: 
From: Mohammed Raad 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=001a11c1a2f0fab4c904ebb5cac5
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 / H.264 conversion without transcoding
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:32:25 -0000

--001a11c1a2f0fab4c904ebb5cac5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

There seems to be a misunderstanding, transcoding really only belongs at
the service provider level. If you have both codecs available there is no
need for it. Also you could simply have one codec with both encoder and
decoder parts and the other with only decoder on your device. That would
mean you dont need transcoding and you dont have both encoders.

Mohammed
On 21 Nov 2013 22:25, "Justin Uberti"  wrote:

> Even if we could do this conversion in real-time on a mobile device...
> since you have both codecs present, why not just send the desired format =
in
> the first place?
>
>
> On Thu, Nov 21, 2013 at 11:25 AM, Gili  wrote:
>
>> Cullen,
>>
>> Thanks for the background information. I also remember them saying that
>> we are only at the beginning of this process and that they expect more
>> performance improvements in the upcoming months.
>>
>> It would be nice to gauge how far we are from being able to do this kind
>> of conversion in real-time on a mobile device (I suspect very far, but i=
t's
>> worth asking). This has implications for P2P interoperability between VP=
8
>> and H.264 peers without a middleman.
>>
>> Gili
>>
>>
>> On 21/11/2013 10:46 AM, Cullen Jennings wrote:
>>
>>> It's a cool demo and I talked to the team that did it. This is only
>>> possible because VP8 and H.264 are very similar codecs. The idea is to =
not
>>> redo the motion vector computations or the DCT but just reuse the value=
s
>>> from one format in the other since they are the same. They hope that th=
is
>>> can provide reduce the CPU by 1/3 from a full decode then re-encode. It
>>> also help reduce loss of quality for video. Other people have talked ab=
out
>>> this idea over the years and many people think it can give a 2 to 3 spe=
ed
>>> up so that seems consistent with their goals.
>>>
>>> It still requires the same bandwidth, and has similar other impacts. I
>>> can not see any way that it would not require MPEG-LA IPR for 264.
>>>
>>>
>>> On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty) 
>>> wrote:
>>>
>>>  This probably refers to an intelligent transcoder versus a brute force
>>>> transcoder. An intelligent transcoder harvests more data during decodi=
ng
>>>> than just the raw output pixels, and uses this extra data to ease enco=
ding.
>>>> Data like block partitions, motion vectors, intra modes, quantization
>>>> parameters, etc.
>>>>
>>>> This is common for common conversions, like MPEG2 to H.264. VP8 and
>>>> H.264 are much closer formats, so this can significantly improve trans=
coder
>>>> performance.
>>>>
>>>> However, this is strictly a performance optimization, with no impact o=
n
>>>> IPR or licensing issues.
>>>>
>>>> Mo
>>>>
>>>>
>>>> On Nov 21, 2013, at 2:51 AM, "Bossiel"  wrote:
>>>>
>>>> This could be true if they can also walk on water and change it into
>>>> wine.
>>>> To be serious, no it's not possible.
>>>> Mamadou
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Nov 21, 2013, at 3:13, Gili  wrote:
>>>>
>>>>  Hi,
>>>>>
>>>>> I'm at the WebRTC World conference. If I understood correctly, Zingay=
a
>>>>> just demoed what they claim is a VP8 to H.264 bridge that converts th=
e
>>>>> video without transcoding. My interpretation is that they convert the
>>>>> surrounding packet format without re-encoding the actual video. Someo=
ne who
>>>>> understands codec internals (I don't) might want to validate this cla=
im,
>>>>> because it could have a significant impact on the MTI debate.
>>>>>
>>>>> It sounds far fetched, but imagine the possibilities:
>>>>>         =95 If the video is not being re-encoded, do H.264 royalties
>>>>> apply?
>>>>>         =95 If the conversion is really cheap, is it feasible to conn=
ect
>>>>> a H.264 peer to a VP8 peer and have one of them convert in-line (no M=
CU)?
>>>>> Gili
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>> _______________________________________________
>> 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
>
>

--001a11c1a2f0fab4c904ebb5cac5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


    There seems to be a misunderstanding, transcoding really only belongs at=
 the service provider level. If you have both codecs available there is no =
need for it. Also you could simply have one codec with both encoder and dec=
oder parts and the other with only decoder on your device. That would mean =
you dont need transcoding and you dont have both encoders.
    


    Mohammed
    

    On 21 Nov 2013 22:25, "Justin Uberti" =
<juberti@google.com> wrote:=

    

    Even if we could do this conversion in real-time on a mobi=
le device... since you have both codecs present, why not just send the desi=
red format in the first place?


    


On Thu, Nov 21, 2013 at 11:25 AM, Gili <cowwoc@bbs.darktech.org&=
gt; wrote:
    


Cullen,
    

    
Thanks for the background information. I also remember them saying that we =
are only at the beginning of this process and that they expect more perform=
ance improvements in the upcoming months.
    

    
It would be nice to gauge how far we are from being able to do this kind of=
 conversion in real-time on a mobile device (I suspect very far, but it'=
;s worth asking). This has implications for P2P interoperability between VP=
8 and H.264 peers without a middleman.
    




    
Gili

    

    
On 21/11/2013 10:46 AM, Cullen Jennings wrote:
    

    
It's a cool demo and I talked to the team that did it. This is only pos=
sible because VP8 and H.264 are very similar codecs. The idea is to not red=
o the motion vector computations or the DCT but just reuse the values from =
one format in the other since they are the same. They hope that this can pr=
ovide reduce the CPU by 1/3 from a full decode then re-encode. It also help=
 reduce loss of quality for video. Other people have talked about this idea=
 over the years and many people think it can give a 2 to 3 speed up so that=
 seems consistent with their goals.
    




    
It still requires the same bandwidth, and has similar other impacts. I can =
not see any way that it would not require MPEG-LA IPR for 264.
    

    

    
On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:
    

    

    
This probably refers to an intelligent transcoder versus a brute force tran=
scoder. An intelligent transcoder harvests more data during decoding than j=
ust the raw output pixels, and uses this extra data to ease encoding. Data =
like block partitions, motion vectors, intra modes, quantization parameters=
, etc.
    




    
This is common for common conversions, like MPEG2 to H.264. VP8 and H.264 a=
re much closer formats, so this can significantly improve transcoder perfor=
mance.
    

    
However, this is strictly a performance optimization, with no impact on IPR=
 or licensing issues.
    

    
Mo
    

    

    
On Nov 21, 2013, at 2:51 AM, "Bossiel" <bossiel@yahoo.fr> wrote:
    

    
This could be true if they can also walk on water and change it into wine.<=
br>
To be serious, no it's not possible.
    
Mamadou
    

    
Sent from my iPhone
    

    
On Nov 21, 2013, at 3:13, Gili <cowwoc@bbs.darktech.org> wrote:
    

    

    
Hi,
    

    
I'm at the WebRTC World conference. If I understood correctly, Zingaya =
just demoed what they claim is a VP8 to H.264 bridge that converts the vide=
o without transcoding. My interpretation is that they convert the surroundi=
ng packet format without re-encoding the actual video. Someone who understa=
nds codec internals (I don't) might want to validate this claim, becaus=
e it could have a significant impact on the MTI debate.
    




    
It sounds far fetched, but imagine the possibilities:
    
=A0 =A0 =A0 =A0 =95 If the video is not being re-encoded, do H.264 royaltie=
s apply?
    
=A0 =A0 =A0 =A0 =95 If the conversion is really cheap, is it feasible to co=
nnect a H.264 peer to a VP8 peer and have one of them convert in-line (no M=
CU)?
    
Gili
    
_______________________________________________
    
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
    

    

    
_______________________________________________
    
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
    

    

--001a11c1a2f0fab4c904ebb5cac5--

From juberti@google.com  Thu Nov 21 12:36:59 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F411AE2F4 for ; Thu, 21 Nov 2013 12:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4vjsfr3TeaS for ; Thu, 21 Nov 2013 12:36:57 -0800 (PST)
Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6C71AE2ED for ; Thu, 21 Nov 2013 12:36:56 -0800 (PST)
Received: by mail-vb0-f47.google.com with SMTP id x11so216471vbb.6 for ; Thu, 21 Nov 2013 12:36:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yd28zMIneX5j5fj06E0d5dBYXJNnnrJIomJMu6YP0YM=; b=FoBaWE/1zo0Slx6oSqW885LhMFSbTG/v6MC92/RXMI69kGkfvklyNZHANVhnNxoDrO GouVdiJ6uGDRC6fdDd8anO/fxsMqn5RKK211I6e9tn36TgSBceFTHx41EnQoEGxn2ZY+ OTNzDmoiuesJlr1fd8C1murkaLtZdxo0R3Zm93Kpmg3RQO7FFEZ+3KEQr5EL/Q/PoaRa vBLXAiLEOLH/H3nJ4gsMcB5fhuG2Zu4I7mdjqsPW6LzLkBtye6BFjwifIO9wmYK6WGP2 RbVhrq71atY/8jKtNQHJju44GEXCIrejC5T9ibFAr1YtuRP7k6OZZ31G5CCzzPsUzc42 tiQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yd28zMIneX5j5fj06E0d5dBYXJNnnrJIomJMu6YP0YM=; b=mZ7LKX5iwouVNxhysicIUAV5HICy5GCrIK9AJmFrmAhYTZiF9lW8GAJnSVak/OBfyY OvcH9Wot1yVAbGHixifl6fVm/uYcIoYh8zTxyqM5lkEvP6UUu9DqWyWAfjB5n6flOoge X+RUe6atiaQ7wWrDiHUJyYBH3t5nnwnCBxSMHbHFndEm6YlhT/fdLAIA3qq0tdh+yf/f /Jmst9ECQJ+Z9r4xFlXw1syXVMRzY8fyQfRpFj8efSjRkkO5Qma3D6sxkwVn9HwkSDck jC/SAw2Z5m4K5dykHV7lOBJxEK7WJiBYe+wQzwHZO6idOTKORs6mvu5K4UIf0kSSZ0ty w5NA==
X-Gm-Message-State: ALoCoQk2Y8pLBXuueGR3oiN20jtBUMHT7D9do/vuBDX2DeZc2aUAqzQAJWLbVTUwrvq/We9J8hjDe/Kbpq3eX6mmt/s/DbdHtLxq0j3stHj5ZToFaadOU/x0q02IS2Lm9APXfRTSdVVQviWqLxVD534Fl+jeunsInoJtrwWoSAHvMO/C0gjW2iE1OPgguSeCZOm6iGR0UQuY
X-Received: by 10.221.51.206 with SMTP id vj14mr7563414vcb.17.1385066210007; Thu, 21 Nov 2013 12:36:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Thu, 21 Nov 2013 12:36:29 -0800 (PST)
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA8AD7E0@ausmsex00.austin.kmvtechnologies.com>
References: <528E69E2.9020208@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA8AD7E0@ausmsex00.austin.kmvtechnologies.com>
From: Justin Uberti 
Date: Thu, 21 Nov 2013 12:36:29 -0800
Message-ID: 
To: Stefan Slivinski 
Content-Type: multipart/alternative; boundary=001a11332252703f7e04ebb5db1e
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:36:59 -0000

--001a11332252703f7e04ebb5db1e
Content-Type: text/plain; charset=UTF-8

iOS doesn't expose APIs for said hardware decoding, so you're doing
software no matter what, and VP8 and H.264 are therefore on level ground.

That said, I think the general understanding here is that this is no longer
a technical decision.


On Thu, Nov 21, 2013 at 12:28 PM, Stefan Slivinski
wrote:

> So this is my concern.  On iOS for example it's pretty easy do decode
> large resolutions in software only using either h.264 or vp8 (and for that
> matter vp9 and h.265).  So making both h264 and vp8 decoders mandatory
> isn't a big technical problem.  The encoder however is a bigger issue.  A
> reasonably good implementation requires roughly 3x the compute to do this
> in software.  iOS however supports hardware encoding using H264 so there is
> an obvious advantage to using that specific codec on that device.  The same
> might be true for VP8 on other architectures.
>
> So requiring all webrtc implementations to support H264 and VP8 gives the
> flexibility to pick the most appropriate encoder for a given architecture.
>
>
> ----- Original Message -----
> From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
> Sent: Thursday, November 21, 2013 02:15 PM
> To: rtcweb@ietf.org 
> Subject: Re: [rtcweb] Proposed Video Selection Process
>
> On 11/21/2013 03:02 PM, Stefan Slivinski wrote:
> > I in no way intended to suggest  a specific implementation of a video
> codec.  My question was around whether we are voting on requiring decoders
> (my assumption) or both encoders and decoders
>
> The discussions, up to this point, have been about choosing an MTI video
> format so that rtcweb endpoints can communicate with one-another.  I am
> not sure how this goal can be achieved without having an encoder and a
> decoder on both ends, sharing at least one common format, whether it is
> H.261, Theora, H.264, VP8, or something else.
>
> --
> Libre Video
> http://librevideo.org
> _______________________________________________
> 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
>

--001a11332252703f7e04ebb5db1e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    iOS doesn't expose APIs for said hardware decoding, so=
 you're doing software no matter what, and VP8 and H.264 are therefore =
on level ground.

    That said, I think the general understa=
nding here is that this is no longer a technical decision.
    




    On Thu,=
 Nov 21, 2013 at 12:28 PM, Stefan Slivinski <sslivinski@lifesize.c=
om> wrote:
    


    So this is my concern. =C2=A0On iOS for exam=
ple it's pretty easy do decode large resolutions in software only using=
 either h.264 or vp8 (and for that matter vp9 and h.265). =C2=A0So making b=
oth h264 and vp8 decoders mandatory isn't a big technical problem. =C2=
=A0The encoder however is a bigger issue. =C2=A0A reasonably good implement=
ation requires roughly 3x the compute to do this in software. =C2=A0iOS how=
ever supports hardware encoding using H264 so there is an obvious advantage=
 to using that specific codec on that device. =C2=A0The same might be true =
for VP8 on other architectures.
    



    
So requiring all webrtc implementations to support H264 and VP8 gives the f=
lexibility to pick the most appropriate encoder for a given architecture.


    

    
----- Original Message -----
    
From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
    

    Sent: Thursday, November 21, 2013 02:15 PM
To: rtcweb@ietf.org <rtcweb@ietf.org>
    
Subject: Re: [rtcweb] Proposed Video Selection Process
    

    

    On 11/21/2013 03:02 PM, Stefa=
n Slivinski wrote:
    
> I in no way intended to suggest =C2=A0a specific implementation of a v=
ideo codec. =C2=A0My question was around whether we are voting on requiring=
 decoders (my assumption) or both encoders and decoders
    

    
The discussions, up to this point, have been about choosing an MTI video
format so that rtcweb endpoints can communicate with one-another. =C2=A0I a=
m
    
not sure how this goal can be achieved without having an encoder and a
    
decoder on both ends, sharing at least one common format, whether it is
    
H.261, Theora, H.264, VP8, or something else.
    

    
--
    
Libre Video
    
http://librevideo.org
    
_______________________________________________
    
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
    


    

--001a11332252703f7e04ebb5db1e--

From randell-ietf@jesup.org  Thu Nov 21 12:37:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7B51AE2FE for ; Thu, 21 Nov 2013 12:37:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtG-ITvmjDlc for ; Thu, 21 Nov 2013 12:37:12 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5221AE2F4 for ; Thu, 21 Nov 2013 12:37:12 -0800 (PST)
Received: from pool-173-49-144-199.phlapa.fios.verizon.net ([173.49.144.199]:1210 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Vjazp-000AT0-9Z for rtcweb@ietf.org; Thu, 21 Nov 2013 14:37:05 -0600
Message-ID: <528E6E9F.6020009@jesup.org>
Date: Thu, 21 Nov 2013 15:35:43 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com>  <827DC810-21FD-494D-9E44-6C7406887464@iii.ca>
In-Reply-To: <827DC810-21FD-494D-9E44-6C7406887464@iii.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:37:14 -0000

On 11/21/2013 1:14 PM, Cullen Jennings wrote:
> If there are any people in that category that wish to vote, could they email the chairs with full name and affiliation. That would make it easier to figure out how to deal with this issue. I think it will be hard to take votes from someone that will not provide the information required to be on a blue sheet due to questions about double counting.

I think anyone who certifies they participated in one or more of the 
IETF rtcweb meetings via jabber should be allowed to vote, so long as 
they give their name and affiliation, and which meeting they 
participated in.  The list of people who vote in this manner should 
perhaps be made public, but I'm not sure that's needed barring any 
belief by the chairs someone is trying to game the system.

It does point out a weakness in the IETF jabber participation 
mechanisms; we should have a "virtual bluesheet" for jabber attendees.

-- 
Randell Jesup -- rjesup a t mozilla d o t com


From ron@debian.org  Thu Nov 21 12:42:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3481AE1C8 for ; Thu, 21 Nov 2013 12:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwGgxgdmMz8Y for ; Thu, 21 Nov 2013 12:41:58 -0800 (PST)
Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 7C77F1AE1B5 for ; Thu, 21 Nov 2013 12:41:57 -0800 (PST)
Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail04.adl6.internode.on.net with ESMTP; 22 Nov 2013 07:11:49 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id EFBFD4F8F3 for ; Fri, 22 Nov 2013 07:11:47 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OOcrx3o+Ftuj for ; Fri, 22 Nov 2013 07:11:47 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 784424F902; Fri, 22 Nov 2013 07:11:47 +1030 (CST)
Date: Fri, 22 Nov 2013 07:11:47 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20131121204147.GV3245@audi.shelbyville.oz>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <528E5B47.70702@nostrum.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:42:00 -0000

On Thu, Nov 21, 2013 at 11:13:11AM -0800, Adam Roach wrote:
> On 11/21/13 10:56, Justin Uberti wrote:
> >Following an IETF meeting on Jabber doesn't count as participating?
> >
> >The "big guy vs little guy" narrative continues...
> 
> I think that's a bit specious. If someone is following the issue at
> such a distance that they haven't expressed an opinion on the
> mailing list, I can't see how taking a vote from them counts as
> anything other than simple, old-fashioned ballot stuffing.
> 
> I'll take it one step further. I find the prospect that we're
> allowing blue sheets to stand in for participation to be highly
> questionable: letting the tourists vote is weighting the opinion of
> demonstrably uninvolved (or less-involved) parties at the same level
> as those who have actually been working on the topic. I do not think
> that a blue-sheet sign in without any on-list participation should
> be sufficient to participate in the kind of process the chairs are
> proposing.
> 
> Or perhaps I'm missing something.

I'd assumed that Justin was referring to the fact that people were
objecting to jabber participants but not the blue sheet tourists
who packed the room for the session with a hum.

So I'm glad you've made that (IMO obvious and important) extra detail
quite specific.


But that said, I think I'm firmly with Peter Saint-Andre here.
Taking this straight to (another) vote seems like a questionable
choice, with a very high chance of an even more questionable and
protested outcome (and precedent). [1]


My understanding of the current situation is:

 - We established consensus long ago that MTI codecs are a very
   important part of this specification.

 - We've had 2 seriously proposed codecs prior to the last meeting.

 - We have people expressing objections to both of them, that the
   chairs consider sufficient to declare there is no workable
   consensus for either at present.

 - The sustainable objections to both all boil down to people claiming
   there are insurmountable IPR difficulties.  Whether that be mythical
   risk, or clear impossibilities of obtaining a licence.

 - We've now had people resign themselves to the fact that this is the
   blocking issue for consensus that needs to be resolved, and propose
   solutions that directly address that issue, through the use of a
   codec that is broadly agreed does not have this problem.


So to me the obvious next step would be to probe for consensus about
the codec options that _do_ remain on the table - and see if anybody
has an actually sustainable objection that would prevent achieving a
rough consensus that the concerns surrounding our original preferred
choices are indeed satisfied by taking this path.

The strong objections that people have had to H.264 and VP8 aren't
going to go away, however a vote might decide - so unless those people
are going to retract their objections now (or the chairs are going to
declare them vexatious and irrelevant), then 'voting' for either of
those as MTI seems utterly pointless.

By my understanding we so far have 2 possible candidates for a MTI
codec that may satisfy the IPR and licencing concerns that have
blocked us from a decision to date:

 - H.261, for which everyone seems to agree the IPR is exhausted.

 - MPEG1, which Stephan raised some oblique concerns about, that
   might still prove unfounded with a little more investigation.

Theora I'm assuming will attract the same FUD that it did with W3C
(since people have already quoted the farce that occurred there)
and that VP8 has attracted.  All the other H.xxx codecs are still
within the lifetime of live patents.  So if we can rule out H.264
and VP8, then we can immediately rule these out too without going
through the motions of repeating all the same arguments again,
with a just some search and replace for the codec names.


So wouldn't a better first step be to:

 - See if MPEG1 can actually be ruled out with plausible indications
   of real remaining IPR trouble.

 - If it is, we only have one codec left for people to try to raise
   objections about that might be sustained.

 - If it isn't, we really still only have one codec left for people
   to raise objections about, since there's obvious agreement that
   it would be superior to H.261 in every other way.


Given the agreement we've previously seen on what a MTI codec is
supposed to achieve, I'm having a hard time seeing how consensus
couldn't be established for at the worst H.261.  We'll all agree
that it sucks -- but I'm yet to see any reasonable objection about
why it _can't_ satisfy the requirements for being the MTI fallback,
in the absence of working agreement for a better alternative.

So why don't we just skip straight to seeking consensus on this?

Instead of having a vote stacked with multiple options that will remain
just as unacceptable as they are today, for all the same reasons, where
people won't have to actually _justify_ why they consider some option
or another to be unacceptable.

  Ron


[1] - though I'm not at all questioning the good faith of the chairs
      in trying to find an adequate way to resolve this (or envious
      of their predicament here).


From miconda@gmail.com  Thu Nov 21 12:42:40 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F831AE2ED for ; Thu, 21 Nov 2013 12:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level: 
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id extbTO0C7c2n for ; Thu, 21 Nov 2013 12:42:37 -0800 (PST)
Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 475A41AE1B5 for ; Thu, 21 Nov 2013 12:42:37 -0800 (PST)
Received: by mail-ee0-f53.google.com with SMTP id b57so121632eek.12 for ; Thu, 21 Nov 2013 12:42:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/ore4nqiQbaQ3QfXebWaJFv8A+i9tvZVV9U2qA7JxWU=; b=zE78NLsIZXF54yoc0f6cxRh3w3elSjOJrrWRv+oBErpuNxZ1fcG/l4CR3IgDJqdpFw VPxaUYRQS9QAJnCqlppgADqfmKthza9dDdUtZ0m4XKqg89L7boFQNhjYayGcPx/7jIgn rbLktdVnc3ckCBZk3Bd1H0cf/ZIUjGC7rOXwfnPCrwjuHJY57aAhA3XUnOjScc2PlTH/ lXmvZgjL0N9PJJXwA3HZp7CXA/1aU9lCnUkWlF+w8YXzHCJtCd/gbZTbHClDqYWK4auN GuUy39jeacofwJrX0l7f02iDOrITCoejSoJElaE8bQElcd9ZL2BgyVB0LTNAcXPj19uw DCUQ==
X-Received: by 10.15.64.1 with SMTP id n1mr11104253eex.15.1385066550049; Thu, 21 Nov 2013 12:42:30 -0800 (PST)
Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id h8sm73620494eew.16.2013.11.21.12.42.28 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 12:42:29 -0800 (PST)
Message-ID: <528E7033.2090502@gmail.com>
Date: Thu, 21 Nov 2013 21:42:27 +0100
From: Daniel-Constantin Mierla 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Thunderbird/25.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: miconda@gmail.com
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: Thu, 21 Nov 2013 20:42:40 -0000

On 11/21/13 8:24 PM, David Singer wrote:
> On Nov 21, 2013, at 10:26 , Peter Saint-Andre  wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 11/21/13 9:51 AM, Magnus Westerlund wrote:
>>
>>> The method we propose is based on Instant-runoff voting,
>>> http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
>>> understanding that the choice will be the winner according to the
>>> Instant-runoff voting process.
>> I have the greatest respect for the chairs, but this is an engraved
>> invitation for people to appeal whatever decision might be reached.
>>
>> More fundamentally: Voting? At the IETF?? Really?!?
>>
>> I sincerely hope we can figure out a better process…
>>
> Me too.
>
> For example, the W3C uses a Call for Objections process, where the option with the weakest technical objection is selected.  I fear that voting will result in a decision that won’t be honored by a significant part of the population.  We don’t need just a mandate, we want the effect of an effective mandate.
Same opinion here.

IMO, it's very unlikely that only such voting will have proper 
effectiveness and, more important, fairness. No matter 
jabber/blue-sheets persons are allowed to vote or not, there was a lot 
of activity on the mailing lists only from lobbyists. That said, it is 
going to be a lot of influence from companies that bet on 'send many and 
speak loud'. But there were many entities that preferred to speak with a 
single and clear voice so far, not involving an army of email bots.

Just dismissing everyone (people/companies/projects) that simply relied 
on the usual 'consensus' policy, which doesn't require to step in front 
unless the decision is likely to be what one doesn't want, does not look 
fair at all. Many spent lot of time in actually doing work/implementing 
webrtc specs so far.

As highlighted before, the issue now is about selecting the voters. For 
example, I see no reason not to allow anyone that was subscribed to any 
webrtc mailing lists hosted by IETF and W3C - it is an indication of 
interest more that many people that go at IEFT for touristic reasons. 
Those that didn't actively participated in discussions so far on mailing 
lists, they should eventually prove their involvement in other related 
activities, with public references, such as:

- implemented webrtc releated specs in an application or product
- they participated to webrtc interop events
- they presented on webrtc topic at some conferences out there
- they wrote related IETF drafts

Probably the list can continue with other activities ... but is clear 
that the range of people interested in the topic is way larger. The 
process of deciding who can vote might create a bigger issue than 
deciding for vp8 or h264 (or other codec) with a flipping coin.

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda


From martin.thomson@gmail.com  Thu Nov 21 12:45:32 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75711AE314 for ; Thu, 21 Nov 2013 12:45:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjhjerm2vxHD for ; Thu, 21 Nov 2013 12:45:31 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFE21AE1C8 for ; Thu, 21 Nov 2013 12:45:31 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id z12so294943wgg.15 for ; Thu, 21 Nov 2013 12:45:24 -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=Eu+72QnEFdV4Jwe/eo4LXHjKIRNi8WTLkz9LHulL28k=; b=ZpqyiAMxeTkeYcMmbtZ8fkGRXr6I8r4MVi+IxWGylIq/lAcBT4hzOzzLXCSVoMi/Ac CLWLxW0Yh6HYs8Q1BV6f6woXjR6eqvYkPcbTfYGtgpUKW56Pr6agdtZFqdEpAMkft0yZ C8w9Xf6f95ycNISC71ETblvnsBTk25rP3k/3HfYxwuCNv5vDqQHS7xc8TGT42ZIpWJfO mVvELoyFW33KJnTSRhMGvzkzffp9fQGRj7fo2iuNtxLyfD5WaBsq9o7lF2j44AGEMm14 BmTGJHfjTCg49WMN18puVulKJJNYH9hhywVBQaa8gPjKas6gBKi1C8PfAbII69AokJ+w nf0Q==
MIME-Version: 1.0
X-Received: by 10.180.208.49 with SMTP id mb17mr31735025wic.64.1385066724042;  Thu, 21 Nov 2013 12:45:24 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Thu, 21 Nov 2013 12:45:23 -0800 (PST)
In-Reply-To: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>     
Date: Thu, 21 Nov 2013 12:45:23 -0800
Message-ID: 
From: Martin Thomson 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:45:33 -0000

On 21 November 2013 12:29, Eric Rescorla  wrote:
> https://github.com/ekr/codec-options

You didn't include the 6919 options:

https://github.com/ekr/codec-options/pull/1

From basilgohar@librevideo.org  Thu Nov 21 12:48:56 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638E31AE32B for ; Thu, 21 Nov 2013 12:48:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level: 
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jJNWZscR1Hv for ; Thu, 21 Nov 2013 12:48:54 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 52D7A1AE329 for ; Thu, 21 Nov 2013 12:48:54 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 594A2659691 for ; Thu, 21 Nov 2013 15:48:47 -0500 (EST)
Message-ID: <528E71AC.4040202@librevideo.org>
Date: Thu, 21 Nov 2013 15:48:44 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz>
In-Reply-To: <20131121204147.GV3245@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:48:56 -0000

On 11/21/2013 03:41 PM, Ron wrote:
> 
> I'd assumed that Justin was referring to the fact that people were
> objecting to jabber participants but not the blue sheet tourists
> who packed the room for the session with a hum.
> 
> So I'm glad you've made that (IMO obvious and important) extra detail
> quite specific.
> 
> 
> But that said, I think I'm firmly with Peter Saint-Andre here.
> Taking this straight to (another) vote seems like a questionable
> choice, with a very high chance of an even more questionable and
> protested outcome (and precedent). [1]
> 
> 
> My understanding of the current situation is:
> 
>  - We established consensus long ago that MTI codecs are a very
>    important part of this specification.
> 
>  - We've had 2 seriously proposed codecs prior to the last meeting.
> 
>  - We have people expressing objections to both of them, that the
>    chairs consider sufficient to declare there is no workable
>    consensus for either at present.
> 
>  - The sustainable objections to both all boil down to people claiming
>    there are insurmountable IPR difficulties.  Whether that be mythical
>    risk, or clear impossibilities of obtaining a licence.
> 
>  - We've now had people resign themselves to the fact that this is the
>    blocking issue for consensus that needs to be resolved, and propose
>    solutions that directly address that issue, through the use of a
>    codec that is broadly agreed does not have this problem.
> 
> 
> So to me the obvious next step would be to probe for consensus about
> the codec options that _do_ remain on the table - and see if anybody
> has an actually sustainable objection that would prevent achieving a
> rough consensus that the concerns surrounding our original preferred
> choices are indeed satisfied by taking this path.
> 
> The strong objections that people have had to H.264 and VP8 aren't
> going to go away, however a vote might decide - so unless those people
> are going to retract their objections now (or the chairs are going to
> declare them vexatious and irrelevant), then 'voting' for either of
> those as MTI seems utterly pointless.
> 
> By my understanding we so far have 2 possible candidates for a MTI
> codec that may satisfy the IPR and licencing concerns that have
> blocked us from a decision to date:
> 
>  - H.261, for which everyone seems to agree the IPR is exhausted.
> 
>  - MPEG1, which Stephan raised some oblique concerns about, that
>    might still prove unfounded with a little more investigation.
> 
> Theora I'm assuming will attract the same FUD that it did with W3C
> (since people have already quoted the farce that occurred there)
> and that VP8 has attracted.  All the other H.xxx codecs are still
> within the lifetime of live patents.  So if we can rule out H.264
> and VP8, then we can immediately rule these out too without going
> through the motions of repeating all the same arguments again,
> with a just some search and replace for the codec names.
> 
> 
> So wouldn't a better first step be to:
> 
>  - See if MPEG1 can actually be ruled out with plausible indications
>    of real remaining IPR trouble.
> 
>  - If it is, we only have one codec left for people to try to raise
>    objections about that might be sustained.
> 
>  - If it isn't, we really still only have one codec left for people
>    to raise objections about, since there's obvious agreement that
>    it would be superior to H.261 in every other way.
> 
> 
> Given the agreement we've previously seen on what a MTI codec is
> supposed to achieve, I'm having a hard time seeing how consensus
> couldn't be established for at the worst H.261.  We'll all agree
> that it sucks -- but I'm yet to see any reasonable objection about
> why it _can't_ satisfy the requirements for being the MTI fallback,
> in the absence of working agreement for a better alternative.
> 
> So why don't we just skip straight to seeking consensus on this?
> 
> Instead of having a vote stacked with multiple options that will remain
> just as unacceptable as they are today, for all the same reasons, where
> people won't have to actually _justify_ why they consider some option
> or another to be unacceptable.
> 
>   Ron
> 
> 
> [1] - though I'm not at all questioning the good faith of the chairs
>       in trying to find an adequate way to resolve this (or envious
>       of their predicament here).
> 

I think that what Ron is presenting here is likely the only sensible
action that's left for us.  I am not sure if there's a possibility to
just condense all the options down into this one.

Has anyone actually objected to H.261 being the one MTI codec, while
leaving VP8 and H.264 as shoulds, as a whole and complete resolution to
our situation?

-- 
Libre Video
http://librevideo.org

From maikmerten@googlemail.com  Thu Nov 21 12:52:04 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0611AE32D for ; Thu, 21 Nov 2013 12:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-P9NRjcxDTV for ; Thu, 21 Nov 2013 12:52:00 -0800 (PST)
Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 184561AE291 for ; Thu, 21 Nov 2013 12:51:59 -0800 (PST)
Received: by mail-ea0-f182.google.com with SMTP id o10so155131eaj.27 for ; Thu, 21 Nov 2013 12:51:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=md3Kj1vsSv4kz+hlUhFGl63AL+FsRvloFqez2tK4aLw=; b=sbeiPRe3epD6GF0+7h+LJ7eoVvk+0V1X6AHU5786rOMUX/7w50TOGKqapFWKuJ+M0H TL8SFXeWzZzJaStBgrrxMgm1aqxz4i+ew/J4NUiUwq9lYPn1KJkgkIV8F7pG7PKA9Fr9 lcmFx4zbrEAt62bXQz0j1hfFgPzRd8EvX8B1slNI+jHcRXyAovv9pfzL0HSaj+uVRt5y Y5KyJAFOZ1k7TJZZ7czuJOgwKFKhZwG1uBO8lIda3KEyFLiVlFdTJ+FKGvteOYKAUT/9 iY/28JlVB+2/PCG+QQA6C1NX0/Cj+o3gtnFtiCAzE0ITqcMBfm0fRdk+L7PQ4QXv9jiw pf+g==
X-Received: by 10.14.199.1 with SMTP id w1mr11191922een.29.1385067112754; Thu, 21 Nov 2013 12:51:52 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id 8sm73687818eem.15.2013.11.21.12.51.50 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 12:51:51 -0800 (PST)
Message-ID: <528E7265.7010303@googlemail.com>
Date: Thu, 21 Nov 2013 21:51:49 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz>
In-Reply-To: <20131121204147.GV3245@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:52:04 -0000

This is IMO a very nice summary of issues and options.

Maik

Am 21.11.2013 21:41, schrieb Ron:
> On Thu, Nov 21, 2013 at 11:13:11AM -0800, Adam Roach wrote:
>> On 11/21/13 10:56, Justin Uberti wrote:
>>> Following an IETF meeting on Jabber doesn't count as participating?
>>>
>>> The "big guy vs little guy" narrative continues...
>>
>> I think that's a bit specious. If someone is following the issue at
>> such a distance that they haven't expressed an opinion on the
>> mailing list, I can't see how taking a vote from them counts as
>> anything other than simple, old-fashioned ballot stuffing.
>>
>> I'll take it one step further. I find the prospect that we're
>> allowing blue sheets to stand in for participation to be highly
>> questionable: letting the tourists vote is weighting the opinion of
>> demonstrably uninvolved (or less-involved) parties at the same level
>> as those who have actually been working on the topic. I do not think
>> that a blue-sheet sign in without any on-list participation should
>> be sufficient to participate in the kind of process the chairs are
>> proposing.
>>
>> Or perhaps I'm missing something.
>
> I'd assumed that Justin was referring to the fact that people were
> objecting to jabber participants but not the blue sheet tourists
> who packed the room for the session with a hum.
>
> So I'm glad you've made that (IMO obvious and important) extra detail
> quite specific.
>
>
> But that said, I think I'm firmly with Peter Saint-Andre here.
> Taking this straight to (another) vote seems like a questionable
> choice, with a very high chance of an even more questionable and
> protested outcome (and precedent). [1]
>
>
> My understanding of the current situation is:
>
>   - We established consensus long ago that MTI codecs are a very
>     important part of this specification.
>
>   - We've had 2 seriously proposed codecs prior to the last meeting.
>
>   - We have people expressing objections to both of them, that the
>     chairs consider sufficient to declare there is no workable
>     consensus for either at present.
>
>   - The sustainable objections to both all boil down to people claiming
>     there are insurmountable IPR difficulties.  Whether that be mythical
>     risk, or clear impossibilities of obtaining a licence.
>
>   - We've now had people resign themselves to the fact that this is the
>     blocking issue for consensus that needs to be resolved, and propose
>     solutions that directly address that issue, through the use of a
>     codec that is broadly agreed does not have this problem.
>
>
> So to me the obvious next step would be to probe for consensus about
> the codec options that _do_ remain on the table - and see if anybody
> has an actually sustainable objection that would prevent achieving a
> rough consensus that the concerns surrounding our original preferred
> choices are indeed satisfied by taking this path.
>
> The strong objections that people have had to H.264 and VP8 aren't
> going to go away, however a vote might decide - so unless those people
> are going to retract their objections now (or the chairs are going to
> declare them vexatious and irrelevant), then 'voting' for either of
> those as MTI seems utterly pointless.
>
> By my understanding we so far have 2 possible candidates for a MTI
> codec that may satisfy the IPR and licencing concerns that have
> blocked us from a decision to date:
>
>   - H.261, for which everyone seems to agree the IPR is exhausted.
>
>   - MPEG1, which Stephan raised some oblique concerns about, that
>     might still prove unfounded with a little more investigation.
>
> Theora I'm assuming will attract the same FUD that it did with W3C
> (since people have already quoted the farce that occurred there)
> and that VP8 has attracted.  All the other H.xxx codecs are still
> within the lifetime of live patents.  So if we can rule out H.264
> and VP8, then we can immediately rule these out too without going
> through the motions of repeating all the same arguments again,
> with a just some search and replace for the codec names.
>
>
> So wouldn't a better first step be to:
>
>   - See if MPEG1 can actually be ruled out with plausible indications
>     of real remaining IPR trouble.
>
>   - If it is, we only have one codec left for people to try to raise
>     objections about that might be sustained.
>
>   - If it isn't, we really still only have one codec left for people
>     to raise objections about, since there's obvious agreement that
>     it would be superior to H.261 in every other way.
>
>
> Given the agreement we've previously seen on what a MTI codec is
> supposed to achieve, I'm having a hard time seeing how consensus
> couldn't be established for at the worst H.261.  We'll all agree
> that it sucks -- but I'm yet to see any reasonable objection about
> why it _can't_ satisfy the requirements for being the MTI fallback,
> in the absence of working agreement for a better alternative.
>
> So why don't we just skip straight to seeking consensus on this?
>
> Instead of having a vote stacked with multiple options that will remain
> just as unacceptable as they are today, for all the same reasons, where
> people won't have to actually _justify_ why they consider some option
> or another to be unacceptable.
>
>    Ron
>
>
> [1] - though I'm not at all questioning the good faith of the chairs
>        in trying to find an adequate way to resolve this (or envious
>        of their predicament here).
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From martin.thomson@gmail.com  Thu Nov 21 12:52:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CFA1AE337 for ; Thu, 21 Nov 2013 12:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrfoXhGbr_JS for ; Thu, 21 Nov 2013 12:52:23 -0800 (PST)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A92DF1AE33F for ; Thu, 21 Nov 2013 12:52:22 -0800 (PST)
Received: by mail-wg0-f42.google.com with SMTP id k14so572553wgh.5 for ; Thu, 21 Nov 2013 12:52:15 -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=xi36cCy3ZD6mlo/LO1i+GxGZhIjSBDrKiy3I3ERsPrc=; b=cc6nhqi3xro1LE3uFFhqX0AhGvGoxCdTc+jMSzpnOjSC3vkMdWBMj2UtA9l5UpVhRU JQw9W1GnsbfFrWr6abiyeTJGQCf/98e5fyYNtQe0Jwcuwi+3I82jfb2Zw++/MRSRH7e8 ZkvcdnpbAUIGE6IkGelOkhS/p4elgyM00tjPrmqZ/WTyuOWSTd/Y6sukUKcCUZRWa6z1 /wRVGJ+zO8no5gSi4RfJYVrFHWfIXsrprZ74GxFsvw3NiCz3GBU8NyuRnddkCQOxxMFC 1Yn5h3FjtOaRyEgwLMYdMJXMN6QR3GLYPuLhY5uhGF+ygdCOQjBHRHYuPt8MOiNk2zEe Lc3g==
MIME-Version: 1.0
X-Received: by 10.195.13.45 with SMTP id ev13mr7202794wjd.20.1385067135304; Thu, 21 Nov 2013 12:52:15 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Thu, 21 Nov 2013 12:52:15 -0800 (PST)
In-Reply-To: <528E71AC.4040202@librevideo.org>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>
Date: Thu, 21 Nov 2013 12:52:15 -0800
Message-ID: 
From: Martin Thomson 
To: Basil Mohamed Gohar 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 20:52:24 -0000

On 21 November 2013 12:48, Basil Mohamed Gohar
 wrote:
> Has anyone actually objected to H.261 being the one MTI codec [...] ?

More than one person has already.

And I find the argument raised quite compelling.  It's hard to justify
spending valuable time and resources on implementing something that
crappy.

From lgeyser@gmail.com  Thu Nov 21 13:01:52 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A711AE2FE for ; Thu, 21 Nov 2013 13:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuGiHFEjW_AL for ; Thu, 21 Nov 2013 13:01:48 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B7D4E1AE2FD for ; Thu, 21 Nov 2013 13:01:47 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id eh20so257018lab.18 for ; Thu, 21 Nov 2013 13:01:40 -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=5vLz7c/z5ZvhKb8WlZqsZZJyxVIgrE9Vtlyz8qLhLbA=; b=CLfDYAiFrVTFlz+QUWfzitKIp7UWYAxklAYQEs3yCJkqnIpUMs5VJLgQktrNWHkmf2 xKioKX44ea09WjMHwxo5RZrXsZf8wlkDYqiMZK6NmiHuELbGwJAq5VkpsuyRwDxBRDYO /oJWUAvneItWJcx6U8jND6usM2e2QZKxUwAju4tQodoNAu3JsU2iB8tJGPypC18O+DDq fvpSPpb1od7Ho/w4WwUIaugSZiVXVu0o1anaOdvCydEIOKxgLc+iv7zHdZwhxO/QGtWT M0rejF4Txtw7Y+nhUFVCGoNE/XOhXM8t4yn7HA3Q2dIz3427XHmDVZOKXJl1I5n5ndGX F5jw==
MIME-Version: 1.0
X-Received: by 10.112.200.170 with SMTP id jt10mr6176638lbc.10.1385067700243;  Thu, 21 Nov 2013 13:01:40 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 21 Nov 2013 13:01:40 -0800 (PST)
In-Reply-To: <528E7265.7010303@googlemail.com>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E7265.7010303@googlemail.com>
Date: Thu, 21 Nov 2013 23:01:40 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c265b843514504ebb63499
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:01:52 -0000

--001a11c265b843514504ebb63499
Content-Type: text/plain; charset=ISO-8859-1

>>This is IMO a very nice summary of issues and options.
>>
>>Maik

+1


On 21 November 2013 22:51, Maik Merten  wrote:

> This is IMO a very nice summary of issues and options.
>
> Maik
>
> Am 21.11.2013 21:41, schrieb Ron:
>
>  On Thu, Nov 21, 2013 at 11:13:11AM -0800, Adam Roach wrote:
>>
>>> On 11/21/13 10:56, Justin Uberti wrote:
>>>
>>>> Following an IETF meeting on Jabber doesn't count as participating?
>>>>
>>>> The "big guy vs little guy" narrative continues...
>>>>
>>>
>>> I think that's a bit specious. If someone is following the issue at
>>> such a distance that they haven't expressed an opinion on the
>>> mailing list, I can't see how taking a vote from them counts as
>>> anything other than simple, old-fashioned ballot stuffing.
>>>
>>> I'll take it one step further. I find the prospect that we're
>>> allowing blue sheets to stand in for participation to be highly
>>> questionable: letting the tourists vote is weighting the opinion of
>>> demonstrably uninvolved (or less-involved) parties at the same level
>>> as those who have actually been working on the topic. I do not think
>>> that a blue-sheet sign in without any on-list participation should
>>> be sufficient to participate in the kind of process the chairs are
>>> proposing.
>>>
>>> Or perhaps I'm missing something.
>>>
>>
>> I'd assumed that Justin was referring to the fact that people were
>> objecting to jabber participants but not the blue sheet tourists
>> who packed the room for the session with a hum.
>>
>> So I'm glad you've made that (IMO obvious and important) extra detail
>> quite specific.
>>
>>
>> But that said, I think I'm firmly with Peter Saint-Andre here.
>> Taking this straight to (another) vote seems like a questionable
>> choice, with a very high chance of an even more questionable and
>> protested outcome (and precedent). [1]
>>
>>
>> My understanding of the current situation is:
>>
>>   - We established consensus long ago that MTI codecs are a very
>>     important part of this specification.
>>
>>   - We've had 2 seriously proposed codecs prior to the last meeting.
>>
>>   - We have people expressing objections to both of them, that the
>>     chairs consider sufficient to declare there is no workable
>>     consensus for either at present.
>>
>>   - The sustainable objections to both all boil down to people claiming
>>     there are insurmountable IPR difficulties.  Whether that be mythical
>>     risk, or clear impossibilities of obtaining a licence.
>>
>>   - We've now had people resign themselves to the fact that this is the
>>     blocking issue for consensus that needs to be resolved, and propose
>>     solutions that directly address that issue, through the use of a
>>     codec that is broadly agreed does not have this problem.
>>
>>
>> So to me the obvious next step would be to probe for consensus about
>> the codec options that _do_ remain on the table - and see if anybody
>> has an actually sustainable objection that would prevent achieving a
>> rough consensus that the concerns surrounding our original preferred
>> choices are indeed satisfied by taking this path.
>>
>> The strong objections that people have had to H.264 and VP8 aren't
>> going to go away, however a vote might decide - so unless those people
>> are going to retract their objections now (or the chairs are going to
>> declare them vexatious and irrelevant), then 'voting' for either of
>> those as MTI seems utterly pointless.
>>
>> By my understanding we so far have 2 possible candidates for a MTI
>> codec that may satisfy the IPR and licencing concerns that have
>> blocked us from a decision to date:
>>
>>   - H.261, for which everyone seems to agree the IPR is exhausted.
>>
>>   - MPEG1, which Stephan raised some oblique concerns about, that
>>     might still prove unfounded with a little more investigation.
>>
>> Theora I'm assuming will attract the same FUD that it did with W3C
>> (since people have already quoted the farce that occurred there)
>> and that VP8 has attracted.  All the other H.xxx codecs are still
>> within the lifetime of live patents.  So if we can rule out H.264
>> and VP8, then we can immediately rule these out too without going
>> through the motions of repeating all the same arguments again,
>> with a just some search and replace for the codec names.
>>
>>
>> So wouldn't a better first step be to:
>>
>>   - See if MPEG1 can actually be ruled out with plausible indications
>>     of real remaining IPR trouble.
>>
>>   - If it is, we only have one codec left for people to try to raise
>>     objections about that might be sustained.
>>
>>   - If it isn't, we really still only have one codec left for people
>>     to raise objections about, since there's obvious agreement that
>>     it would be superior to H.261 in every other way.
>>
>>
>> Given the agreement we've previously seen on what a MTI codec is
>> supposed to achieve, I'm having a hard time seeing how consensus
>> couldn't be established for at the worst H.261.  We'll all agree
>> that it sucks -- but I'm yet to see any reasonable objection about
>> why it _can't_ satisfy the requirements for being the MTI fallback,
>> in the absence of working agreement for a better alternative.
>>
>> So why don't we just skip straight to seeking consensus on this?
>>
>> Instead of having a vote stacked with multiple options that will remain
>> just as unacceptable as they are today, for all the same reasons, where
>> people won't have to actually _justify_ why they consider some option
>> or another to be unacceptable.
>>
>>    Ron
>>
>>
>> [1] - though I'm not at all questioning the good faith of the chairs
>>        in trying to find an adequate way to resolve this (or envious
>>        of their predicament here).
>>
>> _______________________________________________
>> 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
>

--001a11c265b843514504ebb63499
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    >>This is IMO a very nice summary of issues and opti=
ons.
    >>
    
>>Maik

    +1


    On 21 November 2013 22:51, Maik Merten <<=
a href=3D"mailto:maikmerten@googlemail.com" target=3D"_blank">maikmerten@go=
oglemail.com> wrote:
    

    This is IMO a very nice s=
ummary of issues and options.
    

    
Maik
    

    
Am 21.11.2013 21:41, schrieb Ron:

    

    
On Thu, Nov 21, 2013 at 11:13:11AM -0800, Adam Roach wrote:
    

    
On 11/21/13 10:56, Justin Uberti wrote:
    

    
Following an IETF meeting on Jabber doesn't count as participating?
    

    
The "big guy vs little guy" narrative continues...
    

    

    
I think that's a bit specious. If someone is following the issue at
    
such a distance that they haven't expressed an opinion on the
    
mailing list, I can't see how taking a vote from them counts as
    
anything other than simple, old-fashioned ballot stuffing.
    

    
I'll take it one step further. I find the prospect that we're
    
allowing blue sheets to stand in for participation to be highly
    
questionable: letting the tourists vote is weighting the opinion of
    
demonstrably uninvolved (or less-involved) parties at the same level
    
as those who have actually been working on the topic. I do not think
    
that a blue-sheet sign in without any on-list participation should
    
be sufficient to participate in the kind of process the chairs are
    
proposing.
    

    
Or perhaps I'm missing something.
    

    

    
I'd assumed that Justin was referring to the fact that people were
    
objecting to jabber participants but not the blue sheet tourists
    
who packed the room for the session with a hum.
    

    
So I'm glad you've made that (IMO obvious and important) extra deta=
il
    
quite specific.
    

    

    
But that said, I think I'm firmly with Peter Saint-Andre here.
    
Taking this straight to (another) vote seems like a questionable
    
choice, with a very high chance of an even more questionable and
    
protested outcome (and precedent). [1]
    

    

    
My understanding of the current situation is:
    

    
=A0 - We established consensus long ago that MTI codecs are a very
    
=A0 =A0 important part of this specification.
    

    
=A0 - We've had 2 seriously proposed codecs prior to the last meeting.<=
br>

    
=A0 - We have people expressing objections to both of them, that the
    
=A0 =A0 chairs consider sufficient to declare there is no workable
    
=A0 =A0 consensus for either at present.
    

    
=A0 - The sustainable objections to both all boil down to people claiming
=A0 =A0 there are insurmountable IPR difficulties. =A0Whether that be mythi=
cal
    
=A0 =A0 risk, or clear impossibilities of obtaining a licence.
    

    
=A0 - We've now had people resign themselves to the fact that this is t=
he
    
=A0 =A0 blocking issue for consensus that needs to be resolved, and propose=

    
=A0 =A0 solutions that directly address that issue, through the use of a
=A0 =A0 codec that is broadly agreed does not have this problem.
    

    

    
So to me the obvious next step would be to probe for consensus about
    
the codec options that _do_ remain on the table - and see if anybody
    
has an actually sustainable objection that would prevent achieving a
    
rough consensus that the concerns surrounding our original preferred
    
choices are indeed satisfied by taking this path.
    

    
The strong objections that people have had to H.264 and VP8 aren't
    
going to go away, however a vote might decide - so unless those people
    
are going to retract their objections now (or the chairs are going to
    
declare them vexatious and irrelevant), then 'voting' for either of=

    
those as MTI seems utterly pointless.
    

    
By my understanding we so far have 2 possible candidates for a MTI
    
codec that may satisfy the IPR and licencing concerns that have
    
blocked us from a decision to date:
    

    
=A0 - H.261, for which everyone seems to agree the IPR is exhausted.
    

    
=A0 - MPEG1, which Stephan raised some oblique concerns about, that
    
=A0 =A0 might still prove unfounded with a little more investigation.
    

    
Theora I'm assuming will attract the same FUD that it did with W3C
    
(since people have already quoted the farce that occurred there)
    
and that VP8 has attracted. =A0All the other H.xxx codecs are still
    
within the lifetime of live patents. =A0So if we can rule out H.264
    
and VP8, then we can immediately rule these out too without going
    
through the motions of repeating all the same arguments again,
    
with a just some search and replace for the codec names.
    

    

    
So wouldn't a better first step be to:
    

    
=A0 - See if MPEG1 can actually be ruled out with plausible indications
    
=A0 =A0 of real remaining IPR trouble.
    

    
=A0 - If it is, we only have one codec left for people to try to raise
    
=A0 =A0 objections about that might be sustained.
    

    
=A0 - If it isn't, we really still only have one codec left for people<=
br>
=A0 =A0 to raise objections about, since there's obvious agreement that=

    
=A0 =A0 it would be superior to H.261 in every other way.
    

    

    
Given the agreement we've previously seen on what a MTI codec is
    
supposed to achieve, I'm having a hard time seeing how consensus
    
couldn't be established for at the worst H.261. =A0We'll all agree<=
br>
that it sucks -- but I'm yet to see any reasonable objection about
    
why it _can't_ satisfy the requirements for being the MTI fallback,
    
in the absence of working agreement for a better alternative.
    

    
So why don't we just skip straight to seeking consensus on this?
    

    
Instead of having a vote stacked with multiple options that will remain
    
just as unacceptable as they are today, for all the same reasons, where
    
people won't have to actually _justify_ why they consider some option
or another to be unacceptable.
    

    
=A0 =A0Ron
    

    

    
[1] - though I'm not at all questioning the good faith of the chairs
=A0 =A0 =A0 =A0in trying to find an adequate way to resolve this (or enviou=
s
    
=A0 =A0 =A0 =A0of their predicament here).
    

    
_______________________________________________
    
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
    


    

--001a11c265b843514504ebb63499--

From enrico.marocco@telecomitalia.it  Thu Nov 21 13:05:49 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AFF1AE2FE for ; Thu, 21 Nov 2013 13:05:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.246
X-Spam-Level: 
X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkWC1yQnbYVh for ; Thu, 21 Nov 2013 13:05:47 -0800 (PST)
Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 723B91AE27F for ; Thu, 21 Nov 2013 13:05:46 -0800 (PST)
Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 21 Nov 2013 22:05:38 +0100
Received: from airlab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 21 Nov 2013 22:05:38 +0100
Message-ID: <528E759F.4030903@telecomitalia.it>
Date: Thu, 21 Nov 2013 22:05:35 +0100
From: Enrico Marocco 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>      
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050604090708020903040809"
X-TI-Disclaimer: Disclaimer1
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:05:49 -0000

--------------ms050604090708020903040809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

I knew yesterday it was bank holiday in Brazil, didn't know today it is=20
drunk holiday in US. Thanks for making that clear folks!

On 11/21/13 9:45 PM, Martin Thomson wrote:
> On 21 November 2013 12:29, Eric Rescorla  wrote:
>> https://github.com/ekr/codec-options
>
> You didn't include the 6919 options:
>
> https://github.com/ekr/codec-options/pull/1
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



--------------ms050604090708020903040809
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMojCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGZjCCBU6gAwIBAgIDByD0MA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwNzI0MTg1NjUz
WhcNMTQwNzI1MTExMzEwWjB1MRkwFwYDVQQNExBJcWRVZVdCRExxaEZ2N1hrMSgwJgYDVQQD
DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp
Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA078rvuWkIkHhL41Zi2MjXjy5TU71hLgnrstLepYUATbwALhWSs0Kk6l8FhKrOyCl
MPT8NMR5OPG91nEIloDY/AJL7GahjQXomtyqCPXWoRQL95sh+QhlCktlmGhVXm98YAcFWm8E
WoanJmv7UxKhJ6bdXLADn/dtxZGNiACG2U+fBaSyUT0Sa12SQ+u59yOZNWoaLRi2tos0hbZx
eKKVk7a+vxaIS5IIsvUUgJ3tGwFTsz+o3AFWLI/8U1u2LitbpKF/G91ReDA9bb10k5ay43r+
o1TigZEdHd683i7j4DIdjkY3FybFibDtzx+O054BPx5v4C4Nk8vHOHtif2czMwIDAQABo4IC
5TCCAuEwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG
AQUFBwMEMB0GA1UdDgQWBBSjX2uvKQFc1dKQOjONZZ1hVH42cTAfBgNVHSMEGDAWgBRTcu2S
nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh
bGlhLml0MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUH
AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHq
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp
ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g
cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg
Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg
cGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAQ9Ff1giJV3UOk090vsVroHHsBy4J4eITcDLGg+wJ+M+4kULtKS7i+kJjfd5VZb1e
ZsnezvgmhmAaJRy+xl/j7l3UKbSVXfUcnKQ1IVnPVedA+4g6L8nA2cBTGj+vFScEC03HSFqy
Q2Shh3AkCo1L6HLoohHxTvSi7+A4P4uayaHSC0OSdVOXWyDOrjnkSWKQiPX4jc0nJofA7b+H
TppvjgzM5t+c9EQ0v8ldDfP4Pl6HhJ/xwMAETn3VG3hVuT321Gx/BXCS1TDMyUnXVf5BB+S8
vGlgwoPfX2o2ti0/ZXSt/VRUOmBF5kiePNIJ7MLOa15cbxI/2bF0xXKHEjBcETGCA90wggPZ
AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwcg9DAJBgUrDgMC
GgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEx
MjEyMTA1MzZaMCMGCSqGSIb3DQEJBDEWBBTJ6HvojC6iZ33SNRzO6G+m+eSZ9DBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkr
BgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD
Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDByD0
MIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx
ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50
IENBAgMHIPQwDQYJKoZIhvcNAQEBBQAEggEARYZsyv5E1x/nz0o6JR90xzcYTmC3a7jKRRAw
SNaRTot/u/PNnyHGj8h2YBju7sACJRodIYUXK3dvv00Lmw9XOsqvx8y4ShnMpwsa1KXg/LKJ
z/Zv5U6iz4tNpdJ7W+RSXyvO06lN+qz67nNzYPjA+O6t3xFlAGHp7r3qfGsUNpKKLfnHbytm
NwjBUsH0P5hbMtOXhoKX6urLRUEmO7vVJefUjodeEt/cw3FQxN2grogvyktOP6uaupQooXP7
h/jezTE5pN9Sfdskpa4D8E4eLRQ5NXbEvxAeeVVgJJkdBTpczxK3ueeZR1kQfV2XCuBNhLV4
eZcw7UHAKIjeYl4CxwAAAAAAAA==
--------------ms050604090708020903040809--

From sslivinski@lifesize.com  Thu Nov 21 13:06:44 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94791AE325 for ; Thu, 21 Nov 2013 13:06:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.7
X-Spam-Level: 
X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPT_G5CB2PeZ for ; Thu, 21 Nov 2013 13:06:41 -0800 (PST)
Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with SMTP id 8246D1AE092 for ; Thu, 21 Nov 2013 13:06:41 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKUo512cmCapHruxMelNNnJEzkzlSJnj7a@postini.com; Thu, 21 Nov 2013 13:06:35 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 14:52:21 -0600
From: Stefan Slivinski 
To: "'juberti@google.com'" 
Date: Thu, 21 Nov 2013 14:52:20 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7m+Wkuj2mIHLT6RqGggeJ08Fj8vwAAikvT
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7E1@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E1ausmsex00aust_"
MIME-Version: 1.0
Cc: "'rtcweb@ietf.org'" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:06:44 -0000

--_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E1ausmsex00aust_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB0aGluayB0aGlzIGhhcyBkZXZpYXRlZCBmcm9tIG15IG9yaWdpbmFsIHF1ZXN0aW9uIGJ1dC4u
LnRoYXQncyBub3QgdG8gc3VnZ2VzdCBhcHBsZSB3b3VsZG4ndCBleHBvc2UgYSB3ZWJydGMgYXBp
IGluIHRoZSBmdXR1cmUgZ2l2ZW4gYWRlcXVhdGUgc3VwcG9ydCBmb3IgY29kZWNzIHRoZXkgZG8g
c3VwcG9ydCBpbiBoYXJkd2FyZQ0KDQpCYWNrIHRvIG15IG9yaWdpbmFsIHBvaW50LCBhcmUgd2Ug
dm90aW5nIG9uIGJvdGggZW5jb2RlcnMgYW5kIGRlY29kZXJzIG9yIGp1c3QgdGhlIGRlY29kZXIg
Zm9yIHRoZSBtYW5kYXRvcnkgc3VwcG9ydGVkIGNvZGVjcy4NCg0KDQpGcm9tOiBKdXN0aW4gVWJl
cnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVy
IDIxLCAyMDEzIDAyOjM2IFBNDQpUbzogU3RlZmFuIFNsaXZpbnNraQ0KQ2M6IHJ0Y3dlYkBpZXRm
Lm9yZyA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFByb3Bvc2VkIFZp
ZGVvIFNlbGVjdGlvbiBQcm9jZXNzDQoNCmlPUyBkb2Vzbid0IGV4cG9zZSBBUElzIGZvciBzYWlk
IGhhcmR3YXJlIGRlY29kaW5nLCBzbyB5b3UncmUgZG9pbmcgc29mdHdhcmUgbm8gbWF0dGVyIHdo
YXQsIGFuZCBWUDggYW5kIEguMjY0IGFyZSB0aGVyZWZvcmUgb24gbGV2ZWwgZ3JvdW5kLg0KDQpU
aGF0IHNhaWQsIEkgdGhpbmsgdGhlIGdlbmVyYWwgdW5kZXJzdGFuZGluZyBoZXJlIGlzIHRoYXQg
dGhpcyBpcyBubyBsb25nZXIgYSB0ZWNobmljYWwgZGVjaXNpb24uDQoNCg0KT24gVGh1LCBOb3Yg
MjEsIDIwMTMgYXQgMTI6MjggUE0sIFN0ZWZhbiBTbGl2aW5za2kgPHNzbGl2aW5za2lAbGlmZXNp
emUuY29tPG1haWx0bzpzc2xpdmluc2tpQGxpZmVzaXplLmNvbT4+IHdyb3RlOg0KU28gdGhpcyBp
cyBteSBjb25jZXJuLiAgT24gaU9TIGZvciBleGFtcGxlIGl0J3MgcHJldHR5IGVhc3kgZG8gZGVj
b2RlIGxhcmdlIHJlc29sdXRpb25zIGluIHNvZnR3YXJlIG9ubHkgdXNpbmcgZWl0aGVyIGguMjY0
IG9yIHZwOCAoYW5kIGZvciB0aGF0IG1hdHRlciB2cDkgYW5kIGguMjY1KS4gIFNvIG1ha2luZyBi
b3RoIGgyNjQgYW5kIHZwOCBkZWNvZGVycyBtYW5kYXRvcnkgaXNuJ3QgYSBiaWcgdGVjaG5pY2Fs
IHByb2JsZW0uICBUaGUgZW5jb2RlciBob3dldmVyIGlzIGEgYmlnZ2VyIGlzc3VlLiAgQSByZWFz
b25hYmx5IGdvb2QgaW1wbGVtZW50YXRpb24gcmVxdWlyZXMgcm91Z2hseSAzeCB0aGUgY29tcHV0
ZSB0byBkbyB0aGlzIGluIHNvZnR3YXJlLiAgaU9TIGhvd2V2ZXIgc3VwcG9ydHMgaGFyZHdhcmUg
ZW5jb2RpbmcgdXNpbmcgSDI2NCBzbyB0aGVyZSBpcyBhbiBvYnZpb3VzIGFkdmFudGFnZSB0byB1
c2luZyB0aGF0IHNwZWNpZmljIGNvZGVjIG9uIHRoYXQgZGV2aWNlLiAgVGhlIHNhbWUgbWlnaHQg
YmUgdHJ1ZSBmb3IgVlA4IG9uIG90aGVyIGFyY2hpdGVjdHVyZXMuDQoNClNvIHJlcXVpcmluZyBh
bGwgd2VicnRjIGltcGxlbWVudGF0aW9ucyB0byBzdXBwb3J0IEgyNjQgYW5kIFZQOCBnaXZlcyB0
aGUgZmxleGliaWxpdHkgdG8gcGljayB0aGUgbW9zdCBhcHByb3ByaWF0ZSBlbmNvZGVyIGZvciBh
IGdpdmVuIGFyY2hpdGVjdHVyZS4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpG
cm9tOiBCYXNpbCBNb2hhbWVkIEdvaGFyIFttYWlsdG86YmFzaWxnb2hhckBsaWJyZXZpZGVvLm9y
ZzxtYWlsdG86YmFzaWxnb2hhckBsaWJyZXZpZGVvLm9yZz5dDQpTZW50OiBUaHVyc2RheSwgTm92
ZW1iZXIgMjEsIDIwMTMgMDI6MTUgUE0NClRvOiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dl
YkBpZXRmLm9yZz4gPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1
YmplY3Q6IFJlOiBbcnRjd2ViXSBQcm9wb3NlZCBWaWRlbyBTZWxlY3Rpb24gUHJvY2Vzcw0KDQpP
biAxMS8yMS8yMDEzIDAzOjAyIFBNLCBTdGVmYW4gU2xpdmluc2tpIHdyb3RlOg0KPiBJIGluIG5v
IHdheSBpbnRlbmRlZCB0byBzdWdnZXN0ICBhIHNwZWNpZmljIGltcGxlbWVudGF0aW9uIG9mIGEg
dmlkZW8gY29kZWMuICBNeSBxdWVzdGlvbiB3YXMgYXJvdW5kIHdoZXRoZXIgd2UgYXJlIHZvdGlu
ZyBvbiByZXF1aXJpbmcgZGVjb2RlcnMgKG15IGFzc3VtcHRpb24pIG9yIGJvdGggZW5jb2RlcnMg
YW5kIGRlY29kZXJzDQoNClRoZSBkaXNjdXNzaW9ucywgdXAgdG8gdGhpcyBwb2ludCwgaGF2ZSBi
ZWVuIGFib3V0IGNob29zaW5nIGFuIE1USSB2aWRlbw0KZm9ybWF0IHNvIHRoYXQgcnRjd2ViIGVu
ZHBvaW50cyBjYW4gY29tbXVuaWNhdGUgd2l0aCBvbmUtYW5vdGhlci4gIEkgYW0NCm5vdCBzdXJl
IGhvdyB0aGlzIGdvYWwgY2FuIGJlIGFjaGlldmVkIHdpdGhvdXQgaGF2aW5nIGFuIGVuY29kZXIg
YW5kIGENCmRlY29kZXIgb24gYm90aCBlbmRzLCBzaGFyaW5nIGF0IGxlYXN0IG9uZSBjb21tb24g
Zm9ybWF0LCB3aGV0aGVyIGl0IGlzDQpILjI2MSwgVGhlb3JhLCBILjI2NCwgVlA4LCBvciBzb21l
dGhpbmcgZWxzZS4NCg0KLS0NCkxpYnJlIFZpZGVvDQpodHRwOi8vbGlicmV2aWRlby5vcmcNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFp
bGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRj
d2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo=

--_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E1ausmsex00aust_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KSSB0aGluayB0aGlz
IGhhcyBkZXZpYXRlZCBmcm9tIG15IG9yaWdpbmFsIHF1ZXN0aW9uIGJ1dC4uLnRoYXQncyBub3Qg
dG8gc3VnZ2VzdCBhcHBsZSB3b3VsZG4ndCBleHBvc2UgYSB3ZWJydGMgYXBpIGluIHRoZSBmdXR1
cmUgZ2l2ZW4gYWRlcXVhdGUgc3VwcG9ydCBmb3IgY29kZWNzIHRoZXkgZG8gc3VwcG9ydCBpbiBo
YXJkd2FyZTxicj48YnI+QmFjayB0byBteSBvcmlnaW5hbCBwb2ludCwgYXJlIHdlIHZvdGluZyBv
biBib3RoIGVuY29kZXJzIGFuZCBkZWNvZGVycyBvciBqdXN0IHRoZSBkZWNvZGVyIGZvciB0aGUg
bWFuZGF0b3J5IHN1cHBvcnRlZCBjb2RlY3MuPGJyPjwvZm9udD48YnI+Jm5ic3A7PGJyPg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGI+
RnJvbTwvYj46IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDTxicj48
Yj5TZW50PC9iPjogVGh1cnNkYXksIE5vdmVtYmVyIDIxLCAyMDEzIDAyOjM2IFBNPGJyPjxiPlRv
PC9iPjogU3RlZmFuIFNsaXZpbnNraQ08YnI+PGI+Q2M8L2I+OiBydGN3ZWJAaWV0Zi5vcmcgJmx0
O3J0Y3dlYkBpZXRmLm9yZyZndDsNPGJyPjxiPlN1YmplY3Q8L2I+OiBSZTogW3J0Y3dlYl0gUHJv
cG9zZWQgVmlkZW8gU2VsZWN0aW9uIFByb2Nlc3MNPGJyPjwvZm9udD4mbmJzcDs8YnI+PC9kaXY+
DQo8ZGl2IGRpcj0ibHRyIj5pT1MgZG9lc24mIzM5O3QgZXhwb3NlIEFQSXMgZm9yIHNhaWQgaGFy
ZHdhcmUgZGVjb2RpbmcsIHNvIHlvdSYjMzk7cmUgZG9pbmcgc29mdHdhcmUgbm8gbWF0dGVyIHdo
YXQsIGFuZCBWUDggYW5kIEguMjY0IGFyZSB0aGVyZWZvcmUgb24gbGV2ZWwgZ3JvdW5kLjxkaXY+
PGJyPjwvZGl2PjxkaXY+VGhhdCBzYWlkLCBJIHRoaW5rIHRoZSBnZW5lcmFsIHVuZGVyc3RhbmRp
bmcgaGVyZSBpcyB0aGF0IHRoaXMgaXMgbm8gbG9uZ2VyIGEgdGVjaG5pY2FsIGRlY2lzaW9uLjwv
ZGl2Pg0KDQo8L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxicj48ZGl2IGNsYXNz
PSJnbWFpbF9xdW90ZSI+T24gVGh1LCBOb3YgMjEsIDIwMTMgYXQgMTI6MjggUE0sIFN0ZWZhbiBT
bGl2aW5za2kgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86c3NsaXZpbnNraUBs
aWZlc2l6ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5zc2xpdmluc2tpQGxpZmVzaXplLmNvbTwvYT4m
Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQoNCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg
c3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRp
bmctbGVmdDoxZXgiPlNvIHRoaXMgaXMgbXkgY29uY2Vybi4gwqBPbiBpT1MgZm9yIGV4YW1wbGUg
aXQmIzM5O3MgcHJldHR5IGVhc3kgZG8gZGVjb2RlIGxhcmdlIHJlc29sdXRpb25zIGluIHNvZnR3
YXJlIG9ubHkgdXNpbmcgZWl0aGVyIGguMjY0IG9yIHZwOCAoYW5kIGZvciB0aGF0IG1hdHRlciB2
cDkgYW5kIGguMjY1KS4gwqBTbyBtYWtpbmcgYm90aCBoMjY0IGFuZCB2cDggZGVjb2RlcnMgbWFu
ZGF0b3J5IGlzbiYjMzk7dCBhIGJpZyB0ZWNobmljYWwgcHJvYmxlbS4gwqBUaGUgZW5jb2RlciBo
b3dldmVyIGlzIGEgYmlnZ2VyIGlzc3VlLiDCoEEgcmVhc29uYWJseSBnb29kIGltcGxlbWVudGF0
aW9uIHJlcXVpcmVzIHJvdWdobHkgM3ggdGhlIGNvbXB1dGUgdG8gZG8gdGhpcyBpbiBzb2Z0d2Fy
ZS4gwqBpT1MgaG93ZXZlciBzdXBwb3J0cyBoYXJkd2FyZSBlbmNvZGluZyB1c2luZyBIMjY0IHNv
IHRoZXJlIGlzIGFuIG9idmlvdXMgYWR2YW50YWdlIHRvIHVzaW5nIHRoYXQgc3BlY2lmaWMgY29k
ZWMgb24gdGhhdCBkZXZpY2UuIMKgVGhlIHNhbWUgbWlnaHQgYmUgdHJ1ZSBmb3IgVlA4IG9uIG90
aGVyIGFyY2hpdGVjdHVyZXMuPGJyPg0KDQoNCjxicj4NClNvIHJlcXVpcmluZyBhbGwgd2VicnRj
IGltcGxlbWVudGF0aW9ucyB0byBzdXBwb3J0IEgyNjQgYW5kIFZQOCBnaXZlcyB0aGUgZmxleGli
aWxpdHkgdG8gcGljayB0aGUgbW9zdCBhcHByb3ByaWF0ZSBlbmNvZGVyIGZvciBhIGdpdmVuIGFy
Y2hpdGVjdHVyZS48YnI+DQo8ZGl2IGNsYXNzPSJpbSBIT0VuWmIiPjxicj4NCjxicj4NCi0tLS0t
IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnI+DQpGcm9tOiBCYXNpbCBNb2hhbWVkIEdvaGFyIFtt
YWlsdG86PGEgaHJlZj0ibWFpbHRvOmJhc2lsZ29oYXJAbGlicmV2aWRlby5vcmciPmJhc2lsZ29o
YXJAbGlicmV2aWRlby5vcmc8L2E+XTxicj4NCjwvZGl2PjxkaXYgY2xhc3M9ImltIEhPRW5aYiI+
U2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIxLCAyMDEzIDAyOjE1IFBNPGJyPg0KVG86IDxhIGhy
ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4gJmx0OzxhIGhy
ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K
U3ViamVjdDogUmU6IFtydGN3ZWJdIFByb3Bvc2VkIFZpZGVvIFNlbGVjdGlvbiBQcm9jZXNzPGJy
Pg0KPGJyPg0KPC9kaXY+PGRpdiBjbGFzcz0iSE9FblpiIj48ZGl2IGNsYXNzPSJoNSI+T24gMTEv
MjEvMjAxMyAwMzowMiBQTSwgU3RlZmFuIFNsaXZpbnNraSB3cm90ZTo8YnI+DQomZ3Q7IEkgaW4g
bm8gd2F5IGludGVuZGVkIHRvIHN1Z2dlc3QgwqBhIHNwZWNpZmljIGltcGxlbWVudGF0aW9uIG9m
IGEgdmlkZW8gY29kZWMuIMKgTXkgcXVlc3Rpb24gd2FzIGFyb3VuZCB3aGV0aGVyIHdlIGFyZSB2
b3Rpbmcgb24gcmVxdWlyaW5nIGRlY29kZXJzIChteSBhc3N1bXB0aW9uKSBvciBib3RoIGVuY29k
ZXJzIGFuZCBkZWNvZGVyczxicj4NCjxicj4NClRoZSBkaXNjdXNzaW9ucywgdXAgdG8gdGhpcyBw
b2ludCwgaGF2ZSBiZWVuIGFib3V0IGNob29zaW5nIGFuIE1USSB2aWRlbzxicj4NCmZvcm1hdCBz
byB0aGF0IHJ0Y3dlYiBlbmRwb2ludHMgY2FuIGNvbW11bmljYXRlIHdpdGggb25lLWFub3RoZXIu
IMKgSSBhbTxicj4NCm5vdCBzdXJlIGhvdyB0aGlzIGdvYWwgY2FuIGJlIGFjaGlldmVkIHdpdGhv
dXQgaGF2aW5nIGFuIGVuY29kZXIgYW5kIGE8YnI+DQpkZWNvZGVyIG9uIGJvdGggZW5kcywgc2hh
cmluZyBhdCBsZWFzdCBvbmUgY29tbW9uIGZvcm1hdCwgd2hldGhlciBpdCBpczxicj4NCkguMjYx
LCBUaGVvcmEsIEguMjY0LCBWUDgsIG9yIHNvbWV0aGluZyBlbHNlLjxicj4NCjxicj4NCi0tPGJy
Pg0KTGlicmUgVmlkZW88YnI+DQo8YSBocmVmPSJodHRwOi8vbGlicmV2aWRlby5vcmciIHRhcmdl
dD0iX2JsYW5rIj5odHRwOi8vbGlicmV2aWRlby5vcmc8L2E+PGJyPg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0
PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9h
Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj
d2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9ydGN3ZWI8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0
Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PGJyPg0KPC9kaXY+
PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4NCg==

--_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E1ausmsex00aust_--

From maikmerten@googlemail.com  Thu Nov 21 13:07:17 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB251AE27F for ; Thu, 21 Nov 2013 13:07:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm-Zf_2HUh5u for ; Thu, 21 Nov 2013 13:07:16 -0800 (PST)
Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7780F1AE092 for ; Thu, 21 Nov 2013 13:07:16 -0800 (PST)
Received: by mail-ea0-f172.google.com with SMTP id q10so126459ead.17 for ; Thu, 21 Nov 2013 13:07:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=125aR1hkRucme0YGA+WOCtC4VBapPBFBDx58iHUL/qs=; b=LaPUZvuMNXTzcNNrvf5H4lYQZdSfgZb4W2BNZP2V8d2aKhVTD94jrCRM4uJF3leaCb LDvTO1gA+aQABDp3RIKOQJbBJaONx11WJNvBYgySRWp26n4ZHLy/q5QIWfDX0P2bM/ME fZSTCFCEZ0PMWwzE7y2M/Qd0DRn1m8Gq43EGn+zDs8y6R6eD0MvcvFKqKMIY+jyY5OK2 cTKDkIy3HJkqTpQcN+Ou0J4AMwBDetBXjeaH+vMQuu6U4gdJX6aC7Baw43qqsRcytLcB ea1zNw88hDoAfjRv8hSa63YxrCvvTFCVG/jW+LYZ0kyvlwbimw4q2UGm90+Nmm9VE/o2 8RMA==
X-Received: by 10.14.0.72 with SMTP id 48mr33830eea.50.1385068029235; Thu, 21 Nov 2013 13:07:09 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id x4sm73712389eef.1.2013.11.21.13.07.07 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 13:07:08 -0800 (PST)
Message-ID: <528E75FA.4000101@googlemail.com>
Date: Thu, 21 Nov 2013 22:07:06 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:07:17 -0000

Am 21.11.2013 21:52, schrieb Martin Thomson:
> And I find the argument raised quite compelling.  It's hard to justify
> spending valuable time and resources on implementing something that
> crappy.

The justification would be "to enable P2P video interoperability, at 
least on a basic level". Interoperability apparently sometimes (often? 
always?) comes at a price.

However, I'm completely with you: It *is* (very!) unfortunate that IPR 
concerns seem to block anything but technologically vastly outdated formats.


Maik


From sslivinski@lifesize.com  Thu Nov 21 13:15:01 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729FE1AE351 for ; Thu, 21 Nov 2013 13:15:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.18
X-Spam-Level: 
X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gE23BhhBjc4 for ; Thu, 21 Nov 2013 13:14:59 -0800 (PST)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id 868E61AE1ED for ; Thu, 21 Nov 2013 13:14:59 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUo53zG28RwD+/esONDQmRdNA3x9LDFn/@postini.com; Thu, 21 Nov 2013 13:14:53 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 15:04:41 -0600
From: Stefan Slivinski 
CC: "'rtcweb@ietf.org'" 
Date: Thu, 21 Nov 2013 15:04:40 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7m+6NPI5UjoGpaQZWrJ062akRmWgAAagmZ
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7E2@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:15:01 -0000

I think arguing in favor of a legacy codec is completely counter productive=
 to the proliferation of webrtc.  This working group is attempting to avoid=
 dealing with the obvious IPR issues with vp8 and h.264 that any and every =
webrtc vendor is going to have to deal with.  We are basically saying 'we d=
on't know how to deal with this problem so you're on your own' which is com=
pletely the wrong message to send as an organization.

Can you imagine if the bluray groups said we don't want to deal with h.264 =
IPR issues so we'll just mandate h.261?=20



----- Original Message -----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: Thursday, November 21, 2013 02:52 PM=0A=
To: Basil Mohamed Gohar 
Cc: rtcweb@ietf.org 
Subject: Re: [rtcweb] Proposed Video Selection Process

On 21 November 2013 12:48, Basil Mohamed Gohar
 wrote:
> Has anyone actually objected to H.261 being the one MTI codec [...] ?

More than one person has already.

And I find the argument raised quite compelling.  It's hard to justify
spending valuable time and resources on implementing something that
crappy.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

From ekr@rtfm.com  Thu Nov 21 13:15:12 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3011AE1ED for ; Thu, 21 Nov 2013 13:15:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKcgjk26sIR9 for ; Thu, 21 Nov 2013 13:15:11 -0800 (PST)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id E7D581AE35B for ; Thu, 21 Nov 2013 13:15:10 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id hm4so3764686wib.6 for ; Thu, 21 Nov 2013 13:15:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+ZLolvDKyN+n+fvkmEHr2rrHlzQAeiPqFwtzctprmho=; b=D149EdvliPxoe5gbB/IfoD0Om/CsN+4l5X/NnEMimF97Bay//C0ehx+tIKdjCGUd5J 8Wicghp3b+A5hJIknUSJyBVCF7Qx66m3CAkdepMd3GIj+u8v/rBox1HGOW8ZnfDvCt+j mZ/b5OiiY20I2rA5fUH9xzZrEsE7IMVoG7q4t86SDoxKvozEkhZL+h3ghkbbLNabia8d 6ZfG6W9p+KrpKtVWJLuxl1tPSpmBP7we9Qam+8fKrM48/8c2pXbpWrhobSVGslGFc16h P4SW8Wo3NGjN+XhV0WWy1UbQp0nWk6vJHF77FtBN2l4IGZuKHwTP6gXDp9AVVaB4svfP 8HjQ==
X-Gm-Message-State: ALoCoQn2JUONJfsG3+xySO8cqzCT1Muala2C4R6BGj9EcvOMs+v0IbCYgZDoYleExyhTO7RjZtQo
X-Received: by 10.180.12.179 with SMTP id z19mr31594804wib.24.1385068503548; Thu, 21 Nov 2013 13:15:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 21 Nov 2013 13:14:23 -0800 (PST)
X-Originating-IP: [2620:101:8003:300:481b:90de:7d1a:71eb]
In-Reply-To: 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org> 
From: Eric Rescorla 
Date: Thu, 21 Nov 2013 13:14:23 -0800
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=001a11c3533a24dc4b04ebb66402
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:15:12 -0000

--001a11c3533a24dc4b04ebb66402
Content-Type: text/plain; charset=ISO-8859-1

Agreed.

To take a not-so-random example, given that Firefox will soon
support both H.264 and VP8, what additional implementations
will it be able to talk to if it does H.261?

-Ekr




On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson
wrote:

> On 21 November 2013 12:48, Basil Mohamed Gohar
>  wrote:
> > Has anyone actually objected to H.261 being the one MTI codec [...] ?
>
> More than one person has already.
>
> And I find the argument raised quite compelling.  It's hard to justify
> spending valuable time and resources on implementing something that
> crappy.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--001a11c3533a24dc4b04ebb66402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



--001a11c3533a24dc4b04ebb66402--

From enrico.marocco@telecomitalia.it  Thu Nov 21 13:20:17 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FCB1AE2DA for ; Thu, 21 Nov 2013 13:20:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Level: 
X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9Vz8xUQiwuT for ; Thu, 21 Nov 2013 13:20:15 -0800 (PST)
Received: from TELEDG002RM001.telecomitalia.it (teledg002rm001.telecomitalia.it [217.169.121.30]) by ietfa.amsl.com (Postfix) with ESMTP id B32AF1AE293 for ; Thu, 21 Nov 2013 13:20:14 -0800 (PST)
Received: from grfhub701rm001.griffon.local (10.19.3.8) by TELEDG002RM001.telecomitalia.it (10.19.3.112) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Nov 2013 22:20:06 +0100
Received: from airlab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.234) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 21 Nov 2013 22:19:39 +0100
Message-ID: <528E78E9.9010904@telecomitalia.it>
Date: Thu, 21 Nov 2013 22:19:37 +0100
From: Enrico Marocco 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: 
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>
In-Reply-To: <528E5057.30408@stpeter.im>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020407010200010709080404"
X-TI-Disclaimer: Disclaimer1
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:20:18 -0000

--------------ms020407010200010709080404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Just want to +1 this sub-thread of the discussion.

The RFC series turned to success >40y ago by documenting running code=20
and best practices. If the specs produced by this WG today end up=20
documenting the preference of a restricted group of mailing list posters =

rather than the reality of real world deployments, that will have the=20
only effect of undermining the relevance of the IETF.

No MTI is certainly better than a random MTI. For everyone.

Enrico

On 11/21/13 7:26 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/21/13 9:51 AM, Magnus Westerlund wrote:
>
>> The method we propose is based on Instant-runoff voting,
>> http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
>> understanding that the choice will be the winner according to the
>> Instant-runoff voting process.
>
> I have the greatest respect for the chairs, but this is an engraved
> invitation for people to appeal whatever decision might be reached.
>
> More fundamentally: Voting? At the IETF?? Really?!?
>
> I sincerely hope we can figure out a better process...
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSjlBXAAoJEOoGpJErxa2pxmoP/2cCm8UEteJlhNkpV+kTrgYc
> epj1s0LHlQYS/XBWvTpa6d/DeBS0N/mWUAHg+QDj1J5kXiCol3PVpZB7yp2YP4p+
> OcsF/y4KTJCZz+Qs/SBj6o68eX4Cuk68FZ5nrSK6/jSuRFLH6LYTbXW7jvF/Y4pX
> ER5kUg14c+s+NFo575ru3PjYJy2NoSUHVJfB/pLtmlFSH+WKZXw7RFR+Sivlyw3p
> RSJ2fsGldRRa/5aLFajDXxVmViwOtDbuoIFpKKfSSw76a3Q4IbPPX+gezQi7p0ky
> cJCED5/U6IR4wtyWxsfQTV7XDvebYtWTXk2smzKPmQCdRnUiHmT5fmtR6bxDVbSu
> h7xrLCTJeW8qx4IN9zvXCg6QUKUzPdtJuhRF/HouCiZQs9v+d0jmSaR/ZUiZ0Ho9
> 1uXHkiUezkksDKjxB9hsJDmMj24BMzu8TmkndZd3Q4lSg0PI+R1ALd6MgXupBCif
> L8lwYm+JG4cT548O1AfFrBmYcqKnNuTilAA7ZwwJtk6eLcpzpwbLFvRq0LVhsmJC
> dDiNKGSFmgj8wTgT7Z3SQ+km++gecDILGvnJU5hXo6RmnErcjzkis7YMootreSUi
> qCA1fJm7s1TZMn18X79XzHRF6run0C9UaYZORSPwlpmTzAdjRKN5WimstXO2yIQJ
> IZFFqvSNutklVl36Limg
> =3DG59C
> -----END PGP SIGNATURE-----
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



--------------ms020407010200010709080404
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMojCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGZjCCBU6gAwIBAgIDByD0MA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwNzI0MTg1NjUz
WhcNMTQwNzI1MTExMzEwWjB1MRkwFwYDVQQNExBJcWRVZVdCRExxaEZ2N1hrMSgwJgYDVQQD
DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp
Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA078rvuWkIkHhL41Zi2MjXjy5TU71hLgnrstLepYUATbwALhWSs0Kk6l8FhKrOyCl
MPT8NMR5OPG91nEIloDY/AJL7GahjQXomtyqCPXWoRQL95sh+QhlCktlmGhVXm98YAcFWm8E
WoanJmv7UxKhJ6bdXLADn/dtxZGNiACG2U+fBaSyUT0Sa12SQ+u59yOZNWoaLRi2tos0hbZx
eKKVk7a+vxaIS5IIsvUUgJ3tGwFTsz+o3AFWLI/8U1u2LitbpKF/G91ReDA9bb10k5ay43r+
o1TigZEdHd683i7j4DIdjkY3FybFibDtzx+O054BPx5v4C4Nk8vHOHtif2czMwIDAQABo4IC
5TCCAuEwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG
AQUFBwMEMB0GA1UdDgQWBBSjX2uvKQFc1dKQOjONZZ1hVH42cTAfBgNVHSMEGDAWgBRTcu2S
nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh
bGlhLml0MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUH
AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHq
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp
ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g
cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg
Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg
cGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAQ9Ff1giJV3UOk090vsVroHHsBy4J4eITcDLGg+wJ+M+4kULtKS7i+kJjfd5VZb1e
ZsnezvgmhmAaJRy+xl/j7l3UKbSVXfUcnKQ1IVnPVedA+4g6L8nA2cBTGj+vFScEC03HSFqy
Q2Shh3AkCo1L6HLoohHxTvSi7+A4P4uayaHSC0OSdVOXWyDOrjnkSWKQiPX4jc0nJofA7b+H
TppvjgzM5t+c9EQ0v8ldDfP4Pl6HhJ/xwMAETn3VG3hVuT321Gx/BXCS1TDMyUnXVf5BB+S8
vGlgwoPfX2o2ti0/ZXSt/VRUOmBF5kiePNIJ7MLOa15cbxI/2bF0xXKHEjBcETGCA90wggPZ
AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwcg9DAJBgUrDgMC
GgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEx
MjEyMTE5MzdaMCMGCSqGSIb3DQEJBDEWBBTZGlkSXQKWvcHmXeDEJUZByTkn/DBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkr
BgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD
Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDByD0
MIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx
ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50
IENBAgMHIPQwDQYJKoZIhvcNAQEBBQAEggEAaHpOM/3PdK9coqWGjpkZVm4KQ9G3hh2XUaad
7gliXs3m6+U9fG6t0IkRyTWg1EKKd+B4dbnbAho3dMX5qYdbc6OlDhcF8HMSXpmx/zcgJtrl
cpai99mjU+Hr+MMrg9O6O+sMdzWpheuIB5DnPHa9RhZB6YZc7xrGmwDd8/7OMn6xKfnIl/5x
83Q3Af07R2h/yn+oIRf/l5PYHxw8YtwkGfDxkDD2209QAk/+xug/a1lMTonIh40qr7FIT6dK
FamrDCS/qGuIAAP08xJ8GQbyc3/H2eVy+/UxxcL0LnC63f02tNxgshYdTpNbKrxxtUEU46BI
HoTDNGxTLSlF9KVljQAAAAAAAA==
--------------ms020407010200010709080404--

From emcho@sip-communicator.org  Thu Nov 21 13:21:33 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFEC1AE368 for ; Thu, 21 Nov 2013 13:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.278
X-Spam-Level: 
X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHf7Qqjks1uc for ; Thu, 21 Nov 2013 13:21:30 -0800 (PST)
Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id A593C1AE2DA for ; Thu, 21 Nov 2013 13:21:30 -0800 (PST)
Received: by mail-pd0-f171.google.com with SMTP id z10so307813pdj.30 for ; Thu, 21 Nov 2013 13:21:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pOLIrT4oZToQ7kwei8oj6fqzQS9cGzF1Gd22yhkkFT0=; b=hsBXZAStbTgn4r2kgqo2JE5+ffxS3T4w6UvU3MbEr5ao5khtUm8iFatqNmyp3lUYj+ ArLBUKkz+D8ZG0vTzLOdxjB0eDA7rCWGGGkJnNCvNVjI2883eN8p6HgfD+c9y+rW7WKj +9djWhng5PNWy6V2jIhomGzOVPdwxir5W4yHegXLNf9tTLLmuzX3CiYdELLla0c1WrGH PsT6RKm3HwuBYNFYapxfe5MCW7qoDBquya0xS9zV1cysAb4TysP5agBjzwL8gdfIHgHG kyHRZeGKltF+2RXCz71kvobbhwampNgN6BQ8nMPBlDJwzURO7BtRR0XS1gjB085lvaP2 FIQg==
X-Gm-Message-State: ALoCoQnfSn6Xpz8hPMeMv9IFgQssAxvoaEdswtNLOA6mZJU0v/QrhH2wSJ2zqs32gjZoK3zXClfD
X-Received: by 10.66.144.40 with SMTP id sj8mr8401660pab.4.1385068883701; Thu, 21 Nov 2013 13:21:23 -0800 (PST)
Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by mx.google.com with ESMTPSA id ik1sm21433014pbc.9.2013.11.21.13.20.52 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 13:20:52 -0800 (PST)
Received: by mail-pa0-f52.google.com with SMTP id ld10so324599pab.11 for ; Thu, 21 Nov 2013 13:20:52 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.68.189.229 with SMTP id gl5mr56649pbc.195.1385068852082; Thu, 21 Nov 2013 13:20:52 -0800 (PST)
Received: by 10.66.13.234 with HTTP; Thu, 21 Nov 2013 13:20:51 -0800 (PST)
Received: by 10.66.13.234 with HTTP; Thu, 21 Nov 2013 13:20:51 -0800 (PST)
In-Reply-To: <528E5057.30408@stpeter.im>
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>
Date: Thu, 21 Nov 2013 22:20:51 +0100
Message-ID: 
From: Emil Ivov 
To: "Peter St Andre, (stpeter)" 
Content-Type: multipart/alternative; boundary=e89a8f642b52eb1b8904ebb6787f
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:21:33 -0000

--e89a8f642b52eb1b8904ebb6787f
Content-Type: text/plain; charset=ISO-8859-1

The IETF does not vote!

This is not a democracy!

We reach consensus based on technical arguments or we declare lack thereof.

The fact that I could afford a plane ticket to this meeting, had the time
to post on that mailing list or sent a +1 message on an XMPP MUC does not
make me more or less qualified to cast a vote on this topic than anyone
else.

The criteria that is being suggested for picking a voter's base here is so
desperately arbitrary that it makes a coin flip pale in comparison. It also
shows how ill suited the IETF is for such things.

In other words, +1 to what Peter said and let's stick to what we actually
can do.

--sent from my mobile
On 21 Nov 2013 19:26, "Peter Saint-Andre"  wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/21/13 9:51 AM, Magnus Westerlund wrote:
>
> > The method we propose is based on Instant-runoff voting,
> > http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
> > understanding that the choice will be the winner according to the
> > Instant-runoff voting process.
>
> I have the greatest respect for the chairs, but this is an engraved
> invitation for people to appeal whatever decision might be reached.
>
> More fundamentally: Voting? At the IETF?? Really?!?
>
> I sincerely hope we can figure out a better process...
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSjlBXAAoJEOoGpJErxa2pxmoP/2cCm8UEteJlhNkpV+kTrgYc
> epj1s0LHlQYS/XBWvTpa6d/DeBS0N/mWUAHg+QDj1J5kXiCol3PVpZB7yp2YP4p+
> OcsF/y4KTJCZz+Qs/SBj6o68eX4Cuk68FZ5nrSK6/jSuRFLH6LYTbXW7jvF/Y4pX
> ER5kUg14c+s+NFo575ru3PjYJy2NoSUHVJfB/pLtmlFSH+WKZXw7RFR+Sivlyw3p
> RSJ2fsGldRRa/5aLFajDXxVmViwOtDbuoIFpKKfSSw76a3Q4IbPPX+gezQi7p0ky
> cJCED5/U6IR4wtyWxsfQTV7XDvebYtWTXk2smzKPmQCdRnUiHmT5fmtR6bxDVbSu
> h7xrLCTJeW8qx4IN9zvXCg6QUKUzPdtJuhRF/HouCiZQs9v+d0jmSaR/ZUiZ0Ho9
> 1uXHkiUezkksDKjxB9hsJDmMj24BMzu8TmkndZd3Q4lSg0PI+R1ALd6MgXupBCif
> L8lwYm+JG4cT548O1AfFrBmYcqKnNuTilAA7ZwwJtk6eLcpzpwbLFvRq0LVhsmJC
> dDiNKGSFmgj8wTgT7Z3SQ+km++gecDILGvnJU5hXo6RmnErcjzkis7YMootreSUi
> qCA1fJm7s1TZMn18X79XzHRF6run0C9UaYZORSPwlpmTzAdjRKN5WimstXO2yIQJ
> IZFFqvSNutklVl36Limg
> =G59C
> -----END PGP SIGNATURE-----
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--e89a8f642b52eb1b8904ebb6787f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    The IETF does not vote!
    

    This is not a democracy!
    

    We reach consensus based on technical arguments or we declar=
e lack thereof.
    

    The fact that I could afford a plane ticket to this meeting,=
 had the time to post on that mailing list or sent a +1 message on an XMPP =
MUC does not make me more or less qualified to cast a vote on this topic th=
an anyone else.
    


    The criteria that is being suggested for picking a voter'=
;s base here is so desperately arbitrary that it makes a coin flip pale in =
comparison. It also shows how ill suited the IETF is for such things.
    


    In other words, +1 to what Peter said and let's stick to=
 what we actually can do.
    

    --sent from my mobile
    

    On 21 Nov 2013 19:26, "Peter Saint-Andre&qu=
ot; <stpeter@stpeter.im> wr=
ote:
    
-----BEGIN PGP SIGNED MESSAGE-----
    
Hash: SHA1
    

    
On 11/21/13 9:51 AM, Magnus Westerlund wrote:
    

    
> The method we propose is based on Instant-runoff voting,
    
> http://en.wikipedia.org/wiki/Instant-runoff_voting, with th=
e
    
> understanding that the choice will be the winner according to the
    
> Instant-runoff voting process.
    

    
I have the greatest respect for the chairs, but this is an engraved
    
invitation for people to appeal whatever decision might be reached.
    

    
More fundamentally: Voting? At the IETF?? Really?!?
    

    
I sincerely hope we can figure out a better process...
    

    
Peter
    

    
- --
    
Peter Saint-Andre
    
https://stpeter.im/

    

    
-----BEGIN PGP SIGNATURE-----
    
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
    
Comment: GPGTools - http:=
//gpgtools.org
    
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
    

    
iQIcBAEBAgAGBQJSjlBXAAoJEOoGpJErxa2pxmoP/2cCm8UEteJlhNkpV+kTrgYc
    
epj1s0LHlQYS/XBWvTpa6d/DeBS0N/mWUAHg+QDj1J5kXiCol3PVpZB7yp2YP4p+
    
OcsF/y4KTJCZz+Qs/SBj6o68eX4Cuk68FZ5nrSK6/jSuRFLH6LYTbXW7jvF/Y4pX
    
ER5kUg14c+s+NFo575ru3PjYJy2NoSUHVJfB/pLtmlFSH+WKZXw7RFR+Sivlyw3p
    
RSJ2fsGldRRa/5aLFajDXxVmViwOtDbuoIFpKKfSSw76a3Q4IbPPX+gezQi7p0ky
    
cJCED5/U6IR4wtyWxsfQTV7XDvebYtWTXk2smzKPmQCdRnUiHmT5fmtR6bxDVbSu
    
h7xrLCTJeW8qx4IN9zvXCg6QUKUzPdtJuhRF/HouCiZQs9v+d0jmSaR/ZUiZ0Ho9
    
1uXHkiUezkksDKjxB9hsJDmMj24BMzu8TmkndZd3Q4lSg0PI+R1ALd6MgXupBCif
    
L8lwYm+JG4cT548O1AfFrBmYcqKnNuTilAA7ZwwJtk6eLcpzpwbLFvRq0LVhsmJC
    
dDiNKGSFmgj8wTgT7Z3SQ+km++gecDILGvnJU5hXo6RmnErcjzkis7YMootreSUi
    
qCA1fJm7s1TZMn18X79XzHRF6run0C9UaYZORSPwlpmTzAdjRKN5WimstXO2yIQJ
    
IZFFqvSNutklVl36Limg
    
=3DG59C
    
-----END PGP SIGNATURE-----
    
_______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    

    

--e89a8f642b52eb1b8904ebb6787f--

From lgeyser@gmail.com  Thu Nov 21 13:21:34 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DB71AE2DA for ; Thu, 21 Nov 2013 13:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7Z8V1mVyPDC for ; Thu, 21 Nov 2013 13:21:31 -0800 (PST)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2C43D1AE35B for ; Thu, 21 Nov 2013 13:21:30 -0800 (PST)
Received: by mail-la0-f41.google.com with SMTP id eo20so284522lab.0 for ; Thu, 21 Nov 2013 13:21:23 -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=pvVzeLYBy6WPlB5Gb0Vgbo3E/GMFAJNrciQLtqt2x6o=; b=JMF2hG/gEpo3w0v3xw4YHWzNsSrgaX7qNaBnxlHUrf4WpOqxKip4W8v4SIFDPlj/P3 gzTgl1cuSLr3gz6n13z+MwBTMDMjRt/0XQewrJxPsSgrXMwBEHVGT3x1RuCG64K4eMrs fOGXl9GjDaMHh5h5pqBSQAL10I/j0srukK2X91LImzISl5aSlUeicA2NWS0EsvZX42u+ uP3vCtPMBXmCNZ2N6mWSV2U2fZji8hWzKgEDJyJ0A/BgL8FojQnwkitT33YOTNkMABpD J/AAcAe6BsSn01Pr4KACcE+wlhgA8XTpN9Uz38d6JWJgtIRaXUMLFi1RT2rm0VpN5PcC kYxg==
MIME-Version: 1.0
X-Received: by 10.152.10.99 with SMTP id h3mr6523932lab.13.1385068883368; Thu, 21 Nov 2013 13:21:23 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 21 Nov 2013 13:21:23 -0800 (PST)
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA8AD7E2@ausmsex00.austin.kmvtechnologies.com>
References:  <7949EED078736C4881C92F656DC6F6C130EA8AD7E2@ausmsex00.austin.kmvtechnologies.com>
Date: Thu, 21 Nov 2013 23:21:23 +0200
Message-ID: 
From: Leon Geyser 
To: Stefan Slivinski 
Content-Type: multipart/alternative; boundary=001a1132f26ac85ef004ebb67a34
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:21:34 -0000

--001a1132f26ac85ef004ebb67a34
Content-Type: text/plain; charset=ISO-8859-1

That is a completely different situation. We are talking about the open
web. Not some propriety disc format controlled by big companies.
They can deal with IPR easily. Average people who want to work out of their
garage do want other options even if it isn't the best.
Besides this has been pointed out millions of times: Nothing stops anyone
to implement VP8 or H.264 if H.261 is made MTI.


On 21 November 2013 23:04, Stefan Slivinski  wrote:

> I think arguing in favor of a legacy codec is completely counter
> productive to the proliferation of webrtc.  This working group is
> attempting to avoid dealing with the obvious IPR issues with vp8 and h.264
> that any and every webrtc vendor is going to have to deal with.  We are
> basically saying 'we don't know how to deal with this problem so you're on
> your own' which is completely the wrong message to send as an organization.
>
> Can you imagine if the bluray groups said we don't want to deal with h.264
> IPR issues so we'll just mandate h.261?
>
>
>
> ----- Original Message -----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Thursday, November 21, 2013 02:52 PM
> To: Basil Mohamed Gohar 
> Cc: rtcweb@ietf.org 
> Subject: Re: [rtcweb] Proposed Video Selection Process
>
> On 21 November 2013 12:48, Basil Mohamed Gohar
>  wrote:
> > Has anyone actually objected to H.261 being the one MTI codec [...] ?
>
> More than one person has already.
>
> And I find the argument raised quite compelling.  It's hard to justify
> spending valuable time and resources on implementing something that
> crappy.
> _______________________________________________
> 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
>

--001a1132f26ac85ef004ebb67a34
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    That is a completely different situation. We are=
 talking about the open web. Not some propriety disc format controlled by b=
ig companies.
    They can deal with IPR easily. Average people who wa=
nt to work out of their garage do want other options even if it isn't t=
he best.
    

    Besides this has been pointed out millions of times: Nothing stops an=
yone to implement VP8 or H.264 if H.261 is made MTI.


    On 21 November 2013 23:04,=
 Stefan Slivinski <sslivinski@lifesize.com> wrote:
    

    I think arguing in favor of a legacy codec i=
s completely counter productive to the proliferation of webrtc. =A0This wor=
king group is attempting to avoid dealing with the obvious IPR issues with =
vp8 and h.264 that any and every webrtc vendor is going to have to deal wit=
h. =A0We are basically saying 'we don't know how to deal with this =
problem so you're on your own' which is completely the wrong messag=
e to send as an organization.
    


    
Can you imagine if the bluray groups said we don't want to deal with h.=
264 IPR issues so we'll just mandate h.261?
    


    

    

    
----- Original Message -----
    
From: Martin Thomson [mailto:ma=
rtin.thomson@gmail.com]
    
Sent: Thursday, November 21, 2013 02:52 PM
    
To: Basil Mohamed Gohar <ba=
silgohar@librevideo.org>
    
Cc: rtcweb@ietf.org <rtcweb@ietf.org>
    
Subject: Re: [rtcweb] Proposed Video Selection Process
    

    

    On 21 November 2013 12:48, Ba=
sil Mohamed Gohar
    
<basilgohar@librevideo.org<=
/a>> wrote:
    
> Has anyone actually objected to H.261 being the one MTI codec [...] ?<=
br>

    
More than one person has already.
    

    
And I find the argument raised quite compelling. =A0It's hard to justif=
y
    
spending valuable time and resources on implementing something that
    
crappy.
    
_______________________________________________
    
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
    


    

--001a1132f26ac85ef004ebb67a34--

From ron@debian.org  Thu Nov 21 13:27:43 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB161AE1C3 for ; Thu, 21 Nov 2013 13:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooYyq0NE_fFT for ; Thu, 21 Nov 2013 13:27:42 -0800 (PST)
Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 326C01AE00B for ; Thu, 21 Nov 2013 13:27:42 -0800 (PST)
Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail04.adl6.internode.on.net with ESMTP; 22 Nov 2013 07:57:34 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id EACD34F8F3 for ; Fri, 22 Nov 2013 07:57:31 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PtpbKgjQup0Z for ; Fri, 22 Nov 2013 07:57:31 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 1455C4F902; Fri, 22 Nov 2013 07:57:31 +1030 (CST)
Date: Fri, 22 Nov 2013 07:57:31 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20131121212730.GW3245@audi.shelbyville.oz>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:27:44 -0000

On Thu, Nov 21, 2013 at 12:52:15PM -0800, Martin Thomson wrote:
> On 21 November 2013 12:48, Basil Mohamed Gohar
>  wrote:
> > Has anyone actually objected to H.261 being the one MTI codec [...] ?
> 
> More than one person has already.
> 
> And I find the argument raised quite compelling.  It's hard to justify
> spending valuable time and resources on implementing something that
> crappy.

That argument is only 'compelling' if it can overcome the implicit
assumption it carries - that we should revert the existing consensus
that there should be a MTI codec.

If we all agree the preferred codecs have impossible IPR problems,
then the race to the bottom has been run.

There is no further distance to fall, aside from abandoning the
requirement for guaranteed interoperability.  And I'll be interested
to see what compelling argument can be made for that which doesn't
look like simply trying to completely hijack the chartered goals of
this WG and mandate the failure of this specification.


If you don't want something crappy, well, last chance to recant the
FUD about VP8 ...

  Going, going,
  Ron



From fluffy@iii.ca  Thu Nov 21 13:31:41 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEF41ADFF9 for ; Thu, 21 Nov 2013 13:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5n5YEFZUkHx for ; Thu, 21 Nov 2013 13:31:36 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8908D1ADFF3 for ; Thu, 21 Nov 2013 13:31:36 -0800 (PST)
Received: from sjc-vpn2-1025.cisco.com (unknown [128.107.239.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E7B5E509B8; Thu, 21 Nov 2013 16:31:28 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: 
Date: Thu, 21 Nov 2013 13:32:04 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <73739EBC-F92E-4907-88E7-57437355A729@iii.ca>
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>  
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:31:41 -0000

I assume you were joking with that but I think if we have at least a =
handful of people arguing that some particular choice is their first =
choice seems like a reasonable bar to add it. Sound reasonable ?=20


On Nov 21, 2013, at 12:01 PM, Eric Rescorla  wrote:

> I would like to propose some additional alternatives.
>=20
> SHOULD: Theora
> MUST: Theora
> SHOULD: H.261
> SHOULD: H.261 Theora
> MUST: Theora; SHOULD: H.261
> MUST: H.261
> MUST: H.261; SHOULD: Theora
> MUST: H.261 Theora
> SHOULD: H.263
> SHOULD: H.263 Theora
> MUST: Theora; SHOULD: H.263
> SHOULD: H.263 H.261
> SHOULD: H.263 H.261 Theora
> MUST: Theora; SHOULD: H.263 H.261
> MUST: H.261; SHOULD: H.263
> MUST: H.261; SHOULD: H.263 Theora
> MUST: H.261 Theora; SHOULD: H.263
> MUST: H.263
> MUST: H.263; SHOULD: Theora
> MUST: H.263 Theora
> MUST: H.263; SHOULD: H.261
> MUST: H.263; SHOULD: H.261 Theora
> MUST: H.263 Theora; SHOULD: H.261
> MUST: H.263 H.261
> MUST: H.263 H.261; SHOULD: Theora
> MUST: H.263 H.261 Theora
> SHOULD: VP8
> SHOULD: VP8 Theora
> MUST: Theora; SHOULD: VP8
> SHOULD: VP8 H.261
> SHOULD: VP8 H.261 Theora
> MUST: Theora; SHOULD: VP8 H.261
> MUST: H.261; SHOULD: VP8
> MUST: H.261; SHOULD: VP8 Theora
> MUST: H.261 Theora; SHOULD: VP8
> SHOULD: VP8 H.263
> SHOULD: VP8 H.263 Theora
> MUST: Theora; SHOULD: VP8 H.263
> SHOULD: VP8 H.263 H.261
> SHOULD: VP8 H.263 H.261 Theora
> MUST: Theora; SHOULD: VP8 H.263 H.261
> MUST: H.261; SHOULD: VP8 H.263
> MUST: H.261; SHOULD: VP8 H.263 Theora
> MUST: H.261 Theora; SHOULD: VP8 H.263
> MUST: H.263; SHOULD: VP8
> MUST: H.263; SHOULD: VP8 Theora
> MUST: H.263 Theora; SHOULD: VP8
> MUST: H.263; SHOULD: VP8 H.261
> MUST: H.263; SHOULD: VP8 H.261 Theora
> MUST: H.263 Theora; SHOULD: VP8 H.261
> MUST: H.263 H.261; SHOULD: VP8
> MUST: H.263 H.261; SHOULD: VP8 Theora
> MUST: H.263 H.261 Theora; SHOULD: VP8
> MUST: VP8
> MUST: VP8; SHOULD: Theora
> MUST: VP8 Theora
> MUST: VP8; SHOULD: H.261
> MUST: VP8; SHOULD: H.261 Theora
> MUST: VP8 Theora; SHOULD: H.261
> MUST: VP8 H.261
> MUST: VP8 H.261; SHOULD: Theora
> MUST: VP8 H.261 Theora
> MUST: VP8; SHOULD: H.263
> MUST: VP8; SHOULD: H.263 Theora
> MUST: VP8 Theora; SHOULD: H.263
> MUST: VP8; SHOULD: H.263 H.261
> MUST: VP8; SHOULD: H.263 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.263 H.261
> MUST: VP8 H.261; SHOULD: H.263
> MUST: VP8 H.261; SHOULD: H.263 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.263
> MUST: VP8 H.263
> MUST: VP8 H.263; SHOULD: Theora
> MUST: VP8 H.263 Theora
> MUST: VP8 H.263; SHOULD: H.261
> MUST: VP8 H.263; SHOULD: H.261 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.261
> MUST: VP8 H.263 H.261
> MUST: VP8 H.263 H.261; SHOULD: Theora
> MUST: VP8 H.263 H.261 Theora
> SHOULD: H.264
> SHOULD: H.264 Theora
> MUST: Theora; SHOULD: H.264
> SHOULD: H.264 H.261
> SHOULD: H.264 H.261 Theora
> MUST: Theora; SHOULD: H.264 H.261
> MUST: H.261; SHOULD: H.264
> MUST: H.261; SHOULD: H.264 Theora
> MUST: H.261 Theora; SHOULD: H.264
> SHOULD: H.264 H.263
> SHOULD: H.264 H.263 Theora
> MUST: Theora; SHOULD: H.264 H.263
> SHOULD: H.264 H.263 H.261
> SHOULD: H.264 H.263 H.261 Theora
> MUST: Theora; SHOULD: H.264 H.263 H.261
> MUST: H.261; SHOULD: H.264 H.263
> MUST: H.261; SHOULD: H.264 H.263 Theora
> MUST: H.261 Theora; SHOULD: H.264 H.263
> MUST: H.263; SHOULD: H.264
> MUST: H.263; SHOULD: H.264 Theora
> MUST: H.263 Theora; SHOULD: H.264
> MUST: H.263; SHOULD: H.264 H.261
> MUST: H.263; SHOULD: H.264 H.261 Theora
> MUST: H.263 Theora; SHOULD: H.264 H.261
> MUST: H.263 H.261; SHOULD: H.264
> MUST: H.263 H.261; SHOULD: H.264 Theora
> MUST: H.263 H.261 Theora; SHOULD: H.264
> SHOULD: H.264 VP8
> SHOULD: H.264 VP8 Theora
> MUST: Theora; SHOULD: H.264 VP8
> SHOULD: H.264 VP8 H.261
> SHOULD: H.264 VP8 H.261 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.261
> MUST: H.261; SHOULD: H.264 VP8
> MUST: H.261; SHOULD: H.264 VP8 Theora
> MUST: H.261 Theora; SHOULD: H.264 VP8
> SHOULD: H.264 VP8 H.263
> SHOULD: H.264 VP8 H.263 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.263
> SHOULD: H.264 VP8 H.263 H.261
> SHOULD: H.264 VP8 H.263 H.261 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
> MUST: H.261; SHOULD: H.264 VP8 H.263
> MUST: H.261; SHOULD: H.264 VP8 H.263 Theora
> MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
> MUST: H.263; SHOULD: H.264 VP8
> MUST: H.263; SHOULD: H.264 VP8 Theora
> MUST: H.263 Theora; SHOULD: H.264 VP8
> MUST: H.263; SHOULD: H.264 VP8 H.261
> MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
> MUST: H.263 Theora; SHOULD: H.264 VP8 H.261
> MUST: H.263 H.261; SHOULD: H.264 VP8
> MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
> MUST: H.263 H.261 Theora; SHOULD: H.264 VP8
> MUST: VP8; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 Theora
> MUST: VP8 Theora; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 H.261
> MUST: VP8; SHOULD: H.264 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.261
> MUST: VP8 H.261; SHOULD: H.264
> MUST: VP8 H.261; SHOULD: H.264 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 H.263
> MUST: VP8; SHOULD: H.264 H.263 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.263
> MUST: VP8; SHOULD: H.264 H.263 H.261
> MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
> MUST: VP8 H.261; SHOULD: H.264 H.263
> MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.264 H.263
> MUST: VP8 H.263; SHOULD: H.264
> MUST: VP8 H.263; SHOULD: H.264 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.264
> MUST: VP8 H.263; SHOULD: H.264 H.261
> MUST: VP8 H.263; SHOULD: H.264 H.261 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
> MUST: VP8 H.263 H.261; SHOULD: H.264
> MUST: VP8 H.263 H.261; SHOULD: H.264 Theora
> MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
> MUST: H.264
> MUST: H.264; SHOULD: Theora
> MUST: H.264 Theora
> MUST: H.264; SHOULD: H.261
> MUST: H.264; SHOULD: H.261 Theora
> MUST: H.264 Theora; SHOULD: H.261
> MUST: H.264 H.261
> MUST: H.264 H.261; SHOULD: Theora
> MUST: H.264 H.261 Theora
> MUST: H.264; SHOULD: H.263
> MUST: H.264; SHOULD: H.263 Theora
> MUST: H.264 Theora; SHOULD: H.263
> MUST: H.264; SHOULD: H.263 H.261
> MUST: H.264; SHOULD: H.263 H.261 Theora
> MUST: H.264 Theora; SHOULD: H.263 H.261
> MUST: H.264 H.261; SHOULD: H.263
> MUST: H.264 H.261; SHOULD: H.263 Theora
> MUST: H.264 H.261 Theora; SHOULD: H.263
> MUST: H.264 H.263
> MUST: H.264 H.263; SHOULD: Theora
> MUST: H.264 H.263 Theora
> MUST: H.264 H.263; SHOULD: H.261
> MUST: H.264 H.263; SHOULD: H.261 Theora
> MUST: H.264 H.263 Theora; SHOULD: H.261
> MUST: H.264 H.263 H.261
> MUST: H.264 H.263 H.261; SHOULD: Theora
> MUST: H.264 H.263 H.261 Theora
> MUST: H.264; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 Theora
> MUST: H.264 Theora; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 H.261
> MUST: H.264; SHOULD: VP8 H.261 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.261
> MUST: H.264 H.261; SHOULD: VP8
> MUST: H.264 H.261; SHOULD: VP8 Theora
> MUST: H.264 H.261 Theora; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 H.263
> MUST: H.264; SHOULD: VP8 H.263 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.263
> MUST: H.264; SHOULD: VP8 H.263 H.261
> MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
> MUST: H.264 H.261; SHOULD: VP8 H.263
> MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
> MUST: H.264 H.261 Theora; SHOULD: VP8 H.263
> MUST: H.264 H.263; SHOULD: VP8
> MUST: H.264 H.263; SHOULD: VP8 Theora
> MUST: H.264 H.263 Theora; SHOULD: VP8
> MUST: H.264 H.263; SHOULD: VP8 H.261
> MUST: H.264 H.263; SHOULD: VP8 H.261 Theora
> MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
> MUST: H.264 H.263 H.261; SHOULD: VP8
> MUST: H.264 H.263 H.261; SHOULD: VP8 Theora
> MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
> MUST: H.264 VP8
> MUST: H.264 VP8; SHOULD: Theora
> MUST: H.264 VP8 Theora
> MUST: H.264 VP8; SHOULD: H.261
> MUST: H.264 VP8; SHOULD: H.261 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.261
> MUST: H.264 VP8 H.261
> MUST: H.264 VP8 H.261; SHOULD: Theora
> MUST: H.264 VP8 H.261 Theora
> MUST: H.264 VP8; SHOULD: H.263
> MUST: H.264 VP8; SHOULD: H.263 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.263
> MUST: H.264 VP8; SHOULD: H.263 H.261
> MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
> MUST: H.264 VP8 H.261; SHOULD: H.263
> MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
> MUST: H.264 VP8 H.261 Theora; SHOULD: H.263
> MUST: H.264 VP8 H.263
> MUST: H.264 VP8 H.263; SHOULD: Theora
> MUST: H.264 VP8 H.263 Theora
> MUST: H.264 VP8 H.263; SHOULD: H.261
> MUST: H.264 VP8 H.263; SHOULD: H.261 Theora
> MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
> MUST: H.264 VP8 H.263 H.261
> MUST: H.264 VP8 H.263 H.261; SHOULD: Theora
> MUST: H.264 VP8 H.263 H.261 Theora
> SHOULD do 1 of {H.261, Theora}
> SHOULD do 1 of {H.263, Theora}
> SHOULD do 1 of {H.263, H.261}
> SHOULD do 1 of {H.263, H.261, Theora}
> SHOULD do 2 of {H.263, H.261, Theora}
> SHOULD do 1 of {VP8, Theora}
> SHOULD do 1 of {VP8, H.261}
> SHOULD do 1 of {VP8, H.261, Theora}
> SHOULD do 2 of {VP8, H.261, Theora}
> SHOULD do 1 of {VP8, H.263}
> SHOULD do 1 of {VP8, H.263, Theora}
> SHOULD do 2 of {VP8, H.263, Theora}
> SHOULD do 1 of {VP8, H.263, H.261}
> SHOULD do 2 of {VP8, H.263, H.261}
> SHOULD do 1 of {VP8, H.263, H.261, Theora}
> SHOULD do 2 of {VP8, H.263, H.261, Theora}
> SHOULD do 3 of {VP8, H.263, H.261, Theora}
> SHOULD do 1 of {H.264, Theora}
> SHOULD do 1 of {H.264, H.261}
> SHOULD do 1 of {H.264, H.261, Theora}
> SHOULD do 2 of {H.264, H.261, Theora}
> SHOULD do 1 of {H.264, H.263}
> SHOULD do 1 of {H.264, H.263, Theora}
> SHOULD do 2 of {H.264, H.263, Theora}
> SHOULD do 1 of {H.264, H.263, H.261}
> SHOULD do 2 of {H.264, H.263, H.261}
> SHOULD do 1 of {H.264, H.263, H.261, Theora}
> SHOULD do 2 of {H.264, H.263, H.261, Theora}
> SHOULD do 3 of {H.264, H.263, H.261, Theora}
> SHOULD do 1 of {H.264, VP8}
> SHOULD do 1 of {H.264, VP8, Theora}
> SHOULD do 2 of {H.264, VP8, Theora}
> SHOULD do 1 of {H.264, VP8, H.261}
> SHOULD do 2 of {H.264, VP8, H.261}
> SHOULD do 1 of {H.264, VP8, H.261, Theora}
> SHOULD do 2 of {H.264, VP8, H.261, Theora}
> SHOULD do 3 of {H.264, VP8, H.261, Theora}
> SHOULD do 1 of {H.264, VP8, H.263}
> SHOULD do 2 of {H.264, VP8, H.263}
> SHOULD do 1 of {H.264, VP8, H.263, Theora}
> SHOULD do 2 of {H.264, VP8, H.263, Theora}
> SHOULD do 3 of {H.264, VP8, H.263, Theora}
> SHOULD do 1 of {H.264, VP8, H.263, H.261}
> SHOULD do 2 of {H.264, VP8, H.263, H.261}
> SHOULD do 3 of {H.264, VP8, H.263, H.261}
> SHOULD do 1 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 3 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 4 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 1 of {H.261, Theora}
> MUST do 1 of {H.263, Theora}
> MUST do 1 of {H.263, H.261}
> MUST do 1 of {H.263, H.261, Theora}
> MUST do 2 of {H.263, H.261, Theora}
> MUST do 1 of {VP8, Theora}
> MUST do 1 of {VP8, H.261}
> MUST do 1 of {VP8, H.261, Theora}
> MUST do 2 of {VP8, H.261, Theora}
> MUST do 1 of {VP8, H.263}
> MUST do 1 of {VP8, H.263, Theora}
> MUST do 2 of {VP8, H.263, Theora}
> MUST do 1 of {VP8, H.263, H.261}
> MUST do 2 of {VP8, H.263, H.261}
> MUST do 1 of {VP8, H.263, H.261, Theora}
> MUST do 2 of {VP8, H.263, H.261, Theora}
> MUST do 3 of {VP8, H.263, H.261, Theora}
> MUST do 1 of {H.264, Theora}
> MUST do 1 of {H.264, H.261}
> MUST do 1 of {H.264, H.261, Theora}
> MUST do 2 of {H.264, H.261, Theora}
> MUST do 1 of {H.264, H.263}
> MUST do 1 of {H.264, H.263, Theora}
> MUST do 2 of {H.264, H.263, Theora}
> MUST do 1 of {H.264, H.263, H.261}
> MUST do 2 of {H.264, H.263, H.261}
> MUST do 1 of {H.264, H.263, H.261, Theora}
> MUST do 2 of {H.264, H.263, H.261, Theora}
> MUST do 3 of {H.264, H.263, H.261, Theora}
> MUST do 1 of {H.264, VP8}
> MUST do 1 of {H.264, VP8, Theora}
> MUST do 2 of {H.264, VP8, Theora}
> MUST do 1 of {H.264, VP8, H.261}
> MUST do 2 of {H.264, VP8, H.261}
> MUST do 1 of {H.264, VP8, H.261, Theora}
> MUST do 2 of {H.264, VP8, H.261, Theora}
> MUST do 3 of {H.264, VP8, H.261, Theora}
> MUST do 1 of {H.264, VP8, H.263}
> MUST do 2 of {H.264, VP8, H.263}
> MUST do 1 of {H.264, VP8, H.263, Theora}
> MUST do 2 of {H.264, VP8, H.263, Theora}
> MUST do 3 of {H.264, VP8, H.263, Theora}
> MUST do 1 of {H.264, VP8, H.263, H.261}
> MUST do 2 of {H.264, VP8, H.263, H.261}
> MUST do 3 of {H.264, VP8, H.263, H.261}
> MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 2 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 3 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 4 of {H.264, VP8, H.263, H.261, Theora}
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On Thu, Nov 21, 2013 at 11:27 AM, Cullen Jennings  =
wrote:
>=20
> Added a
>=20
> #11     =95 MUST implement at least two of {VP8, H.264 CBP, H.263}
>=20
>=20
> On Nov 21, 2013, at 11:20 AM, David Singer  wrote:
>=20
> > Chairs
> >
> > can we add this as an option to the formal list, so we get formal =
feedback on its acceptability, please?
> >
> > =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
> >
> >
> > I think this may be the best (maybe only) way to tease out how much =
risk people perceive.
> >
> > Many thanks
> >
> > On Nov 21, 2013, at 9:22 , Maik Merten  =
wrote:
> >
> >> Cleary H.263 is preferable from an engineering standpoint (as is, =
e.g., MPEG-1 Part 2): better performance, more deployments. The central =
question is, however, if those can actually be implemented without some =
sort of licensing.
> >>
> >> If they can: Aweseome! However, this may not be determinable =
without a review by people who are knowledgeable in the field of IPR, =
i.e., "actual lawyers". I understand that H.263 is not yet old enough to =
automatically be considered "safe" (and neither is MPEG-1 Part 2, =
although it is closer).
> >>
> >> Best regards,
> >>
> >> Maik
> >>
> >> Am 20.11.2013 20:42, schrieb David Singer:
> >>> I think we should think hard about H.263 instead of H.261 as the =
third fallback.  Why?
> >>>
> >>> http://www.itu.int/rec/T-REC-H.263/
> >>>
> >>>
> >>>
> >>> H.263 was first published in March 1996, so it's 17 years old.  =
The restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, =
more recent amendments deal with this (and a plethora of other issues), =
so we=92d need to settle on which of those are mandatory (the usual =
profiling discussion).
> >>>
> >>> There are 34 records in the patent database against H.261, mostly =
from 1989 but one as recent as 2005 (though that is a re-file).  That's =
2.2 (reciprocity), as was one other I checked.
> >>>
> >>> Rather surprisingly, there are only 31 against H.263!  The most =
recent is 2011, and is also option 2.  Most are 1997-2001.
> >>>
> >>>
> >>> On this quick glance, H.263 appears no worse than H.261. IANAL (as =
I am sure you have all noticed).
> >>>
> >>>
> >>> H.263 is much more widely supported and mandated.  It has been =
mandated in the 3GPP specs for years (for lots of services, including =
videoconf), and is effectively the fallback codec today in the industry, =
as I understand.  It was ubiquitous in video telephony for years, and I =
suspect many of those systems still ship it.
> >>>
> >>> So, would =93MUST implement at least two of (H.264, VP8, H.263)=94 =
work?
> >>>
> >>> (I am asking the question, not even answering on behalf of my =
company, yet.  Let=92s get the issues on the table.)
> >>>
> >>>
> >>> David Singer
> >>> Multimedia and Software Standards, Apple Inc.
> >>>
> >>> _______________________________________________
> >>> 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
> >
> > David Singer
> > Multimedia and Software Standards, Apple Inc.
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20


From maikmerten@googlemail.com  Thu Nov 21 13:33:38 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDC11ADFF3 for ; Thu, 21 Nov 2013 13:33:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbprtKt2zo7R for ; Thu, 21 Nov 2013 13:33:37 -0800 (PST)
Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DDF4E1ADF81 for ; Thu, 21 Nov 2013 13:33:36 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id d51so142939eek.3 for ; Thu, 21 Nov 2013 13:33:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oHHHM4OGxwSrBejIi85FZdvM90nSv75rrvFbkYlixqY=; b=aWOMUNK7U7mmpDYCfnmWvYYtUcc2gyPt58XxqJgSh6FW9Kk+Y0lAqO20tYXDmlnKR1 zHetKFNW1rX4yO2AXwrC3pzr8ghIQVqBgYdhHbYtZs0oSHJ5faVdKd0mni6io9GFNPnw oUEvSz8qT8UllnyMVhfC8dFlk+A0JA5rM/Vqw9aJxR3hkGR+sMWOm27jKPGpavUaOTI+ YHG42zqhOfl/B7iVHttsVjzKFSrZyN+TGpqsGJcvTJ52LpqaIb6MlTrsAEAx/vcNQC1O vUjoKfyhNh2pvRokfknglSj3sQTbuDiqpfOgBnxndBy1WkogsHO10NRRPbquRtr5KEZ7 AC6w==
X-Received: by 10.15.26.131 with SMTP id n3mr11444540eeu.21.1385069609604; Thu, 21 Nov 2013 13:33:29 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id g8sm74069007eep.20.2013.11.21.13.33.28 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 13:33:28 -0800 (PST)
Message-ID: <528E7C26.3000100@googlemail.com>
Date: Thu, 21 Nov 2013 22:33:26 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:33:39 -0000

My understanding is that WebRTC is not a browser-only thing. Also: Just 
because Mozilla may have found a way to sidestep the H.264 licensing 
issues with the help of Cisco, this doesn't mean this "fix" applies 
everywhere. For example, is the blob acceptable for Iceweasel? And what 
do the limited distribution rights of OpenH264 mean regarding system 
administration (e.g., replicating machines with disk images)?

Maik

Am 21.11.2013 22:14, schrieb Eric Rescorla:
> Agreed.
>
> To take a not-so-random example, given that Firefox will soon
> support both H.264 and VP8, what additional implementations
> will it be able to talk to if it does H.261?
>
> -Ekr
>
>
>
>
> On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson
> > wrote:
>
>     On 21 November 2013 12:48, Basil Mohamed Gohar
>     > wrote:
>      > Has anyone actually objected to H.261 being the one MTI codec [...] ?
>
>     More than one person has already.
>
>     And I find the argument raised quite compelling.  It's hard to justify
>     spending valuable time and resources on implementing something that
>     crappy.
>     _______________________________________________
>     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
>


From sslivinski@lifesize.com  Thu Nov 21 13:35:57 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FB81ADFF3 for ; Thu, 21 Nov 2013 13:35:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.7
X-Spam-Level: 
X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_cMFbG4APuw for ; Thu, 21 Nov 2013 13:35:55 -0800 (PST)
Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with SMTP id E2C121ADF81 for ; Thu, 21 Nov 2013 13:35:54 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKUo58snqeA09HNIx2zP9z8/Y4A7XYtrz2@postini.com; Thu, 21 Nov 2013 13:35:48 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 15:31:29 -0600
From: Stefan Slivinski 
To: "'lgeyser@gmail.com'" 
Date: Thu, 21 Nov 2013 15:31:28 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7m/6a6UpXz8++dQCix6PRpJqOl4QAAWMIK
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7E3@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E3ausmsex00aust_"
MIME-Version: 1.0
Cc: "'rtcweb@ietf.org'" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:35:57 -0000

--_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E3ausmsex00aust_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2hpbGUgSSB3aWxsIHJlYWRpbHkgYWRtaXQgdGhpcyBpc24ndCB0aGUgYmVzdCBhbmFsb2d5IEkg
dGhpbmsgdGFraW5nIHRoaXMgdG8gZXh0cmVtZXMgYW5kIHN1Z2dlc3RpbmcgdGhhdCBzb21lb25l
IHdvcmtpbmcgaW4gdGhlaXIgZ2FyYWdlIGlzIGF0IHJpc2sgb2YgYmVpbmcgc3VlZCBmb3IgSVAg
aW5mcmluZ2VtZW50IGFuZCB0aGVuIHVzaW5nIHRoYXQgYXMganVzdGlmaWNhdGlvbiBmb3IganVz
dCByZXF1aXJpbmcgSC4yNjEgaXMgYSBiaXQgb2YgYSBzdHJldGNoLg0KDQoNCg0KDQpGcm9tOiBM
ZW9uIEdleXNlciBbbWFpbHRvOmxnZXlzZXJAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIE5v
dmVtYmVyIDIxLCAyMDEzIDAzOjIxIFBNDQpUbzogU3RlZmFuIFNsaXZpbnNraQ0KQ2M6IHJ0Y3dl
YkBpZXRmLm9yZyA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFByb3Bv
c2VkIFZpZGVvIFNlbGVjdGlvbiBQcm9jZXNzDQoNClRoYXQgaXMgYSBjb21wbGV0ZWx5IGRpZmZl
cmVudCBzaXR1YXRpb24uIFdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBvcGVuIHdlYi4gTm90IHNv
bWUgcHJvcHJpZXR5IGRpc2MgZm9ybWF0IGNvbnRyb2xsZWQgYnkgYmlnIGNvbXBhbmllcy4NClRo
ZXkgY2FuIGRlYWwgd2l0aCBJUFIgZWFzaWx5LiBBdmVyYWdlIHBlb3BsZSB3aG8gd2FudCB0byB3
b3JrIG91dCBvZiB0aGVpciBnYXJhZ2UgZG8gd2FudCBvdGhlciBvcHRpb25zIGV2ZW4gaWYgaXQg
aXNuJ3QgdGhlIGJlc3QuDQpCZXNpZGVzIHRoaXMgaGFzIGJlZW4gcG9pbnRlZCBvdXQgbWlsbGlv
bnMgb2YgdGltZXM6IE5vdGhpbmcgc3RvcHMgYW55b25lIHRvIGltcGxlbWVudCBWUDggb3IgSC4y
NjQgaWYgSC4yNjEgaXMgbWFkZSBNVEkuDQoNCg0KT24gMjEgTm92ZW1iZXIgMjAxMyAyMzowNCwg
U3RlZmFuIFNsaXZpbnNraSA8c3NsaXZpbnNraUBsaWZlc2l6ZS5jb208bWFpbHRvOnNzbGl2aW5z
a2lAbGlmZXNpemUuY29tPj4gd3JvdGU6DQpJIHRoaW5rIGFyZ3VpbmcgaW4gZmF2b3Igb2YgYSBs
ZWdhY3kgY29kZWMgaXMgY29tcGxldGVseSBjb3VudGVyIHByb2R1Y3RpdmUgdG8gdGhlIHByb2xp
ZmVyYXRpb24gb2Ygd2VicnRjLiAgVGhpcyB3b3JraW5nIGdyb3VwIGlzIGF0dGVtcHRpbmcgdG8g
YXZvaWQgZGVhbGluZyB3aXRoIHRoZSBvYnZpb3VzIElQUiBpc3N1ZXMgd2l0aCB2cDggYW5kIGgu
MjY0IHRoYXQgYW55IGFuZCBldmVyeSB3ZWJydGMgdmVuZG9yIGlzIGdvaW5nIHRvIGhhdmUgdG8g
ZGVhbCB3aXRoLiAgV2UgYXJlIGJhc2ljYWxseSBzYXlpbmcgJ3dlIGRvbid0IGtub3cgaG93IHRv
IGRlYWwgd2l0aCB0aGlzIHByb2JsZW0gc28geW91J3JlIG9uIHlvdXIgb3duJyB3aGljaCBpcyBj
b21wbGV0ZWx5IHRoZSB3cm9uZyBtZXNzYWdlIHRvIHNlbmQgYXMgYW4gb3JnYW5pemF0aW9uLg0K
DQpDYW4geW91IGltYWdpbmUgaWYgdGhlIGJsdXJheSBncm91cHMgc2FpZCB3ZSBkb24ndCB3YW50
IHRvIGRlYWwgd2l0aCBoLjI2NCBJUFIgaXNzdWVzIHNvIHdlJ2xsIGp1c3QgbWFuZGF0ZSBoLjI2
MT8NCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IE1hcnRpbiBUaG9t
c29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNv
bkBnbWFpbC5jb20+XQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIxLCAyMDEzIDAyOjUyIFBN
DQpUbzogQmFzaWwgTW9oYW1lZCBHb2hhciA8YmFzaWxnb2hhckBsaWJyZXZpZGVvLm9yZzxtYWls
dG86YmFzaWxnb2hhckBsaWJyZXZpZGVvLm9yZz4+DQpDYzogcnRjd2ViQGlldGYub3JnPG1haWx0
bzpydGN3ZWJAaWV0Zi5vcmc+IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y
Zz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUHJvcG9zZWQgVmlkZW8gU2VsZWN0aW9uIFByb2Nl
c3MNCg0KT24gMjEgTm92ZW1iZXIgMjAxMyAxMjo0OCwgQmFzaWwgTW9oYW1lZCBHb2hhcg0KPGJh
c2lsZ29oYXJAbGlicmV2aWRlby5vcmc8bWFpbHRvOmJhc2lsZ29oYXJAbGlicmV2aWRlby5vcmc+
PiB3cm90ZToNCj4gSGFzIGFueW9uZSBhY3R1YWxseSBvYmplY3RlZCB0byBILjI2MSBiZWluZyB0
aGUgb25lIE1USSBjb2RlYyBbLi4uXSA/DQoNCk1vcmUgdGhhbiBvbmUgcGVyc29uIGhhcyBhbHJl
YWR5Lg0KDQpBbmQgSSBmaW5kIHRoZSBhcmd1bWVudCByYWlzZWQgcXVpdGUgY29tcGVsbGluZy4g
IEl0J3MgaGFyZCB0byBqdXN0aWZ5DQpzcGVuZGluZyB2YWx1YWJsZSB0aW1lIGFuZCByZXNvdXJj
ZXMgb24gaW1wbGVtZW50aW5nIHNvbWV0aGluZyB0aGF0DQpjcmFwcHkuDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0K
cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9y
ZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9ydGN3ZWINCg0K

--_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E3ausmsex00aust_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KV2hpbGUgSSB3aWxs
IHJlYWRpbHkgYWRtaXQgdGhpcyBpc24ndCB0aGUgYmVzdCBhbmFsb2d5IEkgdGhpbmsgdGFraW5n
IHRoaXMgdG8gZXh0cmVtZXMgYW5kIHN1Z2dlc3RpbmcgdGhhdCBzb21lb25lIHdvcmtpbmcgaW4g
dGhlaXIgZ2FyYWdlIGlzIGF0IHJpc2sgb2YgYmVpbmcgc3VlZCBmb3IgSVAgaW5mcmluZ2VtZW50
IGFuZCB0aGVuIHVzaW5nIHRoYXQgYXMganVzdGlmaWNhdGlvbiBmb3IganVzdCByZXF1aXJpbmcg
SC4yNjEgaXMgYSBiaXQgb2YgYSBzdHJldGNoLjxicj48YnI+PGJyPjwvZm9udD48YnI+Jm5ic3A7
PGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPg0KPGI+RnJvbTwvYj46IExlb24gR2V5c2VyIFttYWlsdG86bGdleXNlckBnbWFpbC5jb21d
DTxicj48Yj5TZW50PC9iPjogVGh1cnNkYXksIE5vdmVtYmVyIDIxLCAyMDEzIDAzOjIxIFBNPGJy
PjxiPlRvPC9iPjogU3RlZmFuIFNsaXZpbnNraQ08YnI+PGI+Q2M8L2I+OiBydGN3ZWJAaWV0Zi5v
cmcgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDsNPGJyPjxiPlN1YmplY3Q8L2I+OiBSZTogW3J0Y3dl
Yl0gUHJvcG9zZWQgVmlkZW8gU2VsZWN0aW9uIFByb2Nlc3MNPGJyPjwvZm9udD4mbmJzcDs8YnI+
PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48ZGl2PjxkaXY+VGhhdCBpcyBhIGNvbXBsZXRlbHkgZGlm
ZmVyZW50IHNpdHVhdGlvbi4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIG9wZW4gd2ViLiBOb3Qg
c29tZSBwcm9wcmlldHkgZGlzYyBmb3JtYXQgY29udHJvbGxlZCBieSBiaWcgY29tcGFuaWVzLjxi
cj48L2Rpdj5UaGV5IGNhbiBkZWFsIHdpdGggSVBSIGVhc2lseS4gQXZlcmFnZSBwZW9wbGUgd2hv
IHdhbnQgdG8gd29yayBvdXQgb2YgdGhlaXIgZ2FyYWdlIGRvIHdhbnQgb3RoZXIgb3B0aW9ucyBl
dmVuIGlmIGl0IGlzbiYjMzk7dCB0aGUgYmVzdC48YnI+DQo8L2Rpdj5CZXNpZGVzIHRoaXMgaGFz
IGJlZW4gcG9pbnRlZCBvdXQgbWlsbGlvbnMgb2YgdGltZXM6IE5vdGhpbmcgc3RvcHMgYW55b25l
IHRvIGltcGxlbWVudCBWUDggb3IgSC4yNjQgaWYgSC4yNjEgaXMgbWFkZSBNVEkuPGJyPjwvZGl2
PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl
Ij5PbiAyMSBOb3ZlbWJlciAyMDEzIDIzOjA0LCBTdGVmYW4gU2xpdmluc2tpIDxzcGFuIGRpcj0i
bHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNzbGl2aW5za2lAbGlmZXNpemUuY29tIiB0YXJnZXQ9
Il9ibGFuayI+c3NsaXZpbnNraUBsaWZlc2l6ZS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJy
Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44
ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+SSB0aGluayBh
cmd1aW5nIGluIGZhdm9yIG9mIGEgbGVnYWN5IGNvZGVjIGlzIGNvbXBsZXRlbHkgY291bnRlciBw
cm9kdWN0aXZlIHRvIHRoZSBwcm9saWZlcmF0aW9uIG9mIHdlYnJ0Yy4gwqBUaGlzIHdvcmtpbmcg
Z3JvdXAgaXMgYXR0ZW1wdGluZyB0byBhdm9pZCBkZWFsaW5nIHdpdGggdGhlIG9idmlvdXMgSVBS
IGlzc3VlcyB3aXRoIHZwOCBhbmQgaC4yNjQgdGhhdCBhbnkgYW5kIGV2ZXJ5IHdlYnJ0YyB2ZW5k
b3IgaXMgZ29pbmcgdG8gaGF2ZSB0byBkZWFsIHdpdGguIMKgV2UgYXJlIGJhc2ljYWxseSBzYXlp
bmcgJiMzOTt3ZSBkb24mIzM5O3Qga25vdyBob3cgdG8gZGVhbCB3aXRoIHRoaXMgcHJvYmxlbSBz
byB5b3UmIzM5O3JlIG9uIHlvdXIgb3duJiMzOTsgd2hpY2ggaXMgY29tcGxldGVseSB0aGUgd3Jv
bmcgbWVzc2FnZSB0byBzZW5kIGFzIGFuIG9yZ2FuaXphdGlvbi48YnI+DQoNCjxicj4NCkNhbiB5
b3UgaW1hZ2luZSBpZiB0aGUgYmx1cmF5IGdyb3VwcyBzYWlkIHdlIGRvbiYjMzk7dCB3YW50IHRv
IGRlYWwgd2l0aCBoLjI2NCBJUFIgaXNzdWVzIHNvIHdlJiMzOTtsbCBqdXN0IG1hbmRhdGUgaC4y
NjE/PGJyPg0KPGRpdiBjbGFzcz0iaW0gSE9FblpiIj48YnI+DQo8YnI+DQo8YnI+DQotLS0tLSBP
cmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPg0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzo8
YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0aW4udGhvbXNvbkBn
bWFpbC5jb208L2E+XTxicj4NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyMSwgMjAxMyAwMjo1
MiBQTTxicj4NClRvOiBCYXNpbCBNb2hhbWVkIEdvaGFyICZsdDs8YSBocmVmPSJtYWlsdG86YmFz
aWxnb2hhckBsaWJyZXZpZGVvLm9yZyI+YmFzaWxnb2hhckBsaWJyZXZpZGVvLm9yZzwvYT4mZ3Q7
PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9y
ZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9y
ZzwvYT4mZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFByb3Bvc2VkIFZpZGVvIFNlbGVj
dGlvbiBQcm9jZXNzPGJyPg0KPGJyPg0KPC9kaXY+PGRpdiBjbGFzcz0iSE9FblpiIj48ZGl2IGNs
YXNzPSJoNSI+T24gMjEgTm92ZW1iZXIgMjAxMyAxMjo0OCwgQmFzaWwgTW9oYW1lZCBHb2hhcjxi
cj4NCiZsdDs8YSBocmVmPSJtYWlsdG86YmFzaWxnb2hhckBsaWJyZXZpZGVvLm9yZyI+YmFzaWxn
b2hhckBsaWJyZXZpZGVvLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgSGFzIGFueW9uZSBh
Y3R1YWxseSBvYmplY3RlZCB0byBILjI2MSBiZWluZyB0aGUgb25lIE1USSBjb2RlYyBbLi4uXSA/
PGJyPg0KPGJyPg0KTW9yZSB0aGFuIG9uZSBwZXJzb24gaGFzIGFscmVhZHkuPGJyPg0KPGJyPg0K
QW5kIEkgZmluZCB0aGUgYXJndW1lbnQgcmFpc2VkIHF1aXRlIGNvbXBlbGxpbmcuIMKgSXQmIzM5
O3MgaGFyZCB0byBqdXN0aWZ5PGJyPg0Kc3BlbmRpbmcgdmFsdWFibGUgdGltZSBhbmQgcmVzb3Vy
Y2VzIG9uIGltcGxlbWVudGluZyBzb21ldGhpbmcgdGhhdDxicj4NCmNyYXBweS48YnI+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBt
YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJA
aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm
PSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0i
X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48
YnI+DQo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2Pg0K

--_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E3ausmsex00aust_--

From martin.thomson@gmail.com  Thu Nov 21 13:36:01 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AF71AE2CA for ; Thu, 21 Nov 2013 13:36:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpJhWQj_LF1m for ; Thu, 21 Nov 2013 13:36:00 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 14DD21AE2A8 for ; Thu, 21 Nov 2013 13:35:59 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id hq4so264574wib.3 for ; Thu, 21 Nov 2013 13:35:52 -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=8UHf6euk3gfBCqasbvwR0kI2aXkIopvtXuVvH7hTEMU=; b=IRcwGoByc7A2u3XjyqmGPFzI86t4Zvs3Na7HGNL4UFTruCFPWnxEOX/oAdBB7t9lHV kMmTG+EEUXybbkTTG+SDxZYfKgTSDzblkfXwKAT13OHiC3PaJwx/L5STp++1yGKqkzkX s8/lw108AVG9xkJ8F5p0dEGSkxeyYQFbCL/ipbZAQ5L7oP2J8s82E4L60xL6MKayKuS9 gk581U2dFIkUzCDiAzzB9dvuFQmU+xhaZnuoXFPcKac6A1lLu8rs5Px6244WOXrv1ox3 jjdqN+5n1jTbHW/6+NAl1U1dzQf03fjjMPTx+ExKrqCnu53ISsH4ZKCUVqCXhMXCEx3F GaKg==
MIME-Version: 1.0
X-Received: by 10.180.206.18 with SMTP id lk18mr7657323wic.64.1385069752818; Thu, 21 Nov 2013 13:35:52 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Thu, 21 Nov 2013 13:35:52 -0800 (PST)
In-Reply-To: <20131121212730.GW3245@audi.shelbyville.oz>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>  <20131121212730.GW3245@audi.shelbyville.oz>
Date: Thu, 21 Nov 2013 13:35:52 -0800
Message-ID: 
From: Martin Thomson 
To: Ron 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:36:01 -0000

On 21 November 2013 13:27, Ron  wrote:
> If you don't want something crappy, [...]

You're making some big assumptions here about what I want.

But we're well beyond "want" at this point.  We need to figure out
what people would settle for.  I don't think that the proposed process
does that.

From derhoermi@gmx.net  Thu Nov 21 13:40:36 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB151AE34B for ; Thu, 21 Nov 2013 13:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level: 
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGKPVezqc-Js for ; Thu, 21 Nov 2013 13:40:34 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id E7EF81AE34C for ; Thu, 21 Nov 2013 13:40:33 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.61.205]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0M7ojs-1VWSmv3qCm-00vLnJ for ; Thu, 21 Nov 2013 22:40:26 +0100
From: Bjoern Hoehrmann 
To: Ron 
Date: Thu, 21 Nov 2013 22:40:27 +0100
Message-ID: 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz>
In-Reply-To: <20131121204147.GV3245@audi.shelbyville.oz>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:A/D6xQEcAYyyf3+ZkC9JcjsXnCn2HX1YGvCgjDLoFmoBdxFmpqx 1Y71iq7ezvxaMLSQj6GF6g7V6gtCcP3Rs5ftxlWF5LY0zj/0uHMB0f1ErcwwRIz5x8swiHS 6eRpj68QczXkfwPyEOjXK9yaKjJszZpKcu6cYjeOJejO853Vt1fWAoiRSYKFmPdAswTrsRf jTjyTZDi4yTAe8AmpQ7Qg==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:40:36 -0000

* Ron wrote:
>Theora I'm assuming will attract the same FUD that it did with W3C
>(since people have already quoted the farce that occurred there)
>and that VP8 has attracted.

The mailing list archive holds 10 000 messages. Up until the thread
"Video Codec Selection Plan" two months ago, there have been only 23
mails that mention "Theora" in any way. Ignoring two mails where it's
mentioned only in HTML code, the last mention was over a year ago,
.

I think it would be fair to say the Working Group has given no con-
sideration to making Theora a mandatory-to-implement codec. I went
through those few messages again just now and do not really see any
argument against it. So unless my mail client is failing me, I would
not make such an assumption.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From matthew@matthew.at  Thu Nov 21 13:41:18 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BAD1AE34B for ; Thu, 21 Nov 2013 13:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWZr5wAvcwv5 for ; Thu, 21 Nov 2013 13:41:13 -0800 (PST)
Received: from mail.eeph.com (mail.eeph.com [IPv6:2001:470:826a:d2::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF8F1AE32B for ; Thu, 21 Nov 2013 13:41:13 -0800 (PST)
Received: from [10.1.146.164] (173-10-121-193-BusName-Washington.hfc.comcastbusiness.net [173.10.121.193]) (Authenticated sender: matthew@matthew.at) by mail.eeph.com (Postfix) with ESMTPSA id F19894244D5; Thu, 21 Nov 2013 13:41:05 -0800 (PST)
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>  
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-90E435E5-ED6C-47BB-82BB-52F948F7EC99
Content-Transfer-Encoding: 7bit
Message-Id: <0C9620D2-58BC-410E-9BED-D3FE0C5C2A2F@matthew.at>
X-Mailer: iPhone Mail (11A501)
From: Matthew Kaufman 
Date: Thu, 21 Nov 2013 13:41:04 -0800
To: Eric Rescorla 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:41:18 -0000

--Apple-Mail-90E435E5-ED6C-47BB-82BB-52F948F7EC99
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1

Matthew Kaufman

(Sent from my iPhone)

> On Nov 21, 2013, at 12:01 PM, Eric Rescorla  wrote:
>=20
> I would like to propose some additional alternatives.
>=20
> SHOULD: Theora
> MUST: Theora
> SHOULD: H.261
> SHOULD: H.261 Theora
> MUST: Theora; SHOULD: H.261
> MUST: H.261
> MUST: H.261; SHOULD: Theora
> MUST: H.261 Theora
> SHOULD: H.263
> SHOULD: H.263 Theora
> MUST: Theora; SHOULD: H.263
> SHOULD: H.263 H.261
> SHOULD: H.263 H.261 Theora
> MUST: Theora; SHOULD: H.263 H.261
> MUST: H.261; SHOULD: H.263
> MUST: H.261; SHOULD: H.263 Theora
> MUST: H.261 Theora; SHOULD: H.263
> MUST: H.263
> MUST: H.263; SHOULD: Theora
> MUST: H.263 Theora
> MUST: H.263; SHOULD: H.261
> MUST: H.263; SHOULD: H.261 Theora
> MUST: H.263 Theora; SHOULD: H.261
> MUST: H.263 H.261
> MUST: H.263 H.261; SHOULD: Theora
> MUST: H.263 H.261 Theora
> SHOULD: VP8
> SHOULD: VP8 Theora
> MUST: Theora; SHOULD: VP8
> SHOULD: VP8 H.261
> SHOULD: VP8 H.261 Theora
> MUST: Theora; SHOULD: VP8 H.261
> MUST: H.261; SHOULD: VP8
> MUST: H.261; SHOULD: VP8 Theora
> MUST: H.261 Theora; SHOULD: VP8
> SHOULD: VP8 H.263
> SHOULD: VP8 H.263 Theora
> MUST: Theora; SHOULD: VP8 H.263
> SHOULD: VP8 H.263 H.261
> SHOULD: VP8 H.263 H.261 Theora
> MUST: Theora; SHOULD: VP8 H.263 H.261
> MUST: H.261; SHOULD: VP8 H.263
> MUST: H.261; SHOULD: VP8 H.263 Theora
> MUST: H.261 Theora; SHOULD: VP8 H.263
> MUST: H.263; SHOULD: VP8
> MUST: H.263; SHOULD: VP8 Theora
> MUST: H.263 Theora; SHOULD: VP8
> MUST: H.263; SHOULD: VP8 H.261
> MUST: H.263; SHOULD: VP8 H.261 Theora
> MUST: H.263 Theora; SHOULD: VP8 H.261
> MUST: H.263 H.261; SHOULD: VP8
> MUST: H.263 H.261; SHOULD: VP8 Theora
> MUST: H.263 H.261 Theora; SHOULD: VP8
> MUST: VP8
> MUST: VP8; SHOULD: Theora
> MUST: VP8 Theora
> MUST: VP8; SHOULD: H.261
> MUST: VP8; SHOULD: H.261 Theora
> MUST: VP8 Theora; SHOULD: H.261
> MUST: VP8 H.261
> MUST: VP8 H.261; SHOULD: Theora
> MUST: VP8 H.261 Theora
> MUST: VP8; SHOULD: H.263
> MUST: VP8; SHOULD: H.263 Theora
> MUST: VP8 Theora; SHOULD: H.263
> MUST: VP8; SHOULD: H.263 H.261
> MUST: VP8; SHOULD: H.263 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.263 H.261
> MUST: VP8 H.261; SHOULD: H.263
> MUST: VP8 H.261; SHOULD: H.263 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.263
> MUST: VP8 H.263
> MUST: VP8 H.263; SHOULD: Theora
> MUST: VP8 H.263 Theora
> MUST: VP8 H.263; SHOULD: H.261
> MUST: VP8 H.263; SHOULD: H.261 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.261
> MUST: VP8 H.263 H.261
> MUST: VP8 H.263 H.261; SHOULD: Theora
> MUST: VP8 H.263 H.261 Theora
> SHOULD: H.264
> SHOULD: H.264 Theora
> MUST: Theora; SHOULD: H.264
> SHOULD: H.264 H.261
> SHOULD: H.264 H.261 Theora
> MUST: Theora; SHOULD: H.264 H.261
> MUST: H.261; SHOULD: H.264
> MUST: H.261; SHOULD: H.264 Theora
> MUST: H.261 Theora; SHOULD: H.264
> SHOULD: H.264 H.263
> SHOULD: H.264 H.263 Theora
> MUST: Theora; SHOULD: H.264 H.263
> SHOULD: H.264 H.263 H.261
> SHOULD: H.264 H.263 H.261 Theora
> MUST: Theora; SHOULD: H.264 H.263 H.261
> MUST: H.261; SHOULD: H.264 H.263
> MUST: H.261; SHOULD: H.264 H.263 Theora
> MUST: H.261 Theora; SHOULD: H.264 H.263
> MUST: H.263; SHOULD: H.264
> MUST: H.263; SHOULD: H.264 Theora
> MUST: H.263 Theora; SHOULD: H.264
> MUST: H.263; SHOULD: H.264 H.261
> MUST: H.263; SHOULD: H.264 H.261 Theora
> MUST: H.263 Theora; SHOULD: H.264 H.261
> MUST: H.263 H.261; SHOULD: H.264
> MUST: H.263 H.261; SHOULD: H.264 Theora
> MUST: H.263 H.261 Theora; SHOULD: H.264
> SHOULD: H.264 VP8
> SHOULD: H.264 VP8 Theora
> MUST: Theora; SHOULD: H.264 VP8
> SHOULD: H.264 VP8 H.261
> SHOULD: H.264 VP8 H.261 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.261
> MUST: H.261; SHOULD: H.264 VP8
> MUST: H.261; SHOULD: H.264 VP8 Theora
> MUST: H.261 Theora; SHOULD: H.264 VP8
> SHOULD: H.264 VP8 H.263
> SHOULD: H.264 VP8 H.263 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.263
> SHOULD: H.264 VP8 H.263 H.261
> SHOULD: H.264 VP8 H.263 H.261 Theora
> MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
> MUST: H.261; SHOULD: H.264 VP8 H.263
> MUST: H.261; SHOULD: H.264 VP8 H.263 Theora
> MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
> MUST: H.263; SHOULD: H.264 VP8
> MUST: H.263; SHOULD: H.264 VP8 Theora
> MUST: H.263 Theora; SHOULD: H.264 VP8
> MUST: H.263; SHOULD: H.264 VP8 H.261
> MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
> MUST: H.263 Theora; SHOULD: H.264 VP8 H.261
> MUST: H.263 H.261; SHOULD: H.264 VP8
> MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
> MUST: H.263 H.261 Theora; SHOULD: H.264 VP8
> MUST: VP8; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 Theora
> MUST: VP8 Theora; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 H.261
> MUST: VP8; SHOULD: H.264 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.261
> MUST: VP8 H.261; SHOULD: H.264
> MUST: VP8 H.261; SHOULD: H.264 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.264
> MUST: VP8; SHOULD: H.264 H.263
> MUST: VP8; SHOULD: H.264 H.263 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.263
> MUST: VP8; SHOULD: H.264 H.263 H.261
> MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
> MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
> MUST: VP8 H.261; SHOULD: H.264 H.263
> MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
> MUST: VP8 H.261 Theora; SHOULD: H.264 H.263
> MUST: VP8 H.263; SHOULD: H.264
> MUST: VP8 H.263; SHOULD: H.264 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.264
> MUST: VP8 H.263; SHOULD: H.264 H.261
> MUST: VP8 H.263; SHOULD: H.264 H.261 Theora
> MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
> MUST: VP8 H.263 H.261; SHOULD: H.264
> MUST: VP8 H.263 H.261; SHOULD: H.264 Theora
> MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
> MUST: H.264
> MUST: H.264; SHOULD: Theora
> MUST: H.264 Theora
> MUST: H.264; SHOULD: H.261
> MUST: H.264; SHOULD: H.261 Theora
> MUST: H.264 Theora; SHOULD: H.261
> MUST: H.264 H.261
> MUST: H.264 H.261; SHOULD: Theora
> MUST: H.264 H.261 Theora
> MUST: H.264; SHOULD: H.263
> MUST: H.264; SHOULD: H.263 Theora
> MUST: H.264 Theora; SHOULD: H.263
> MUST: H.264; SHOULD: H.263 H.261
> MUST: H.264; SHOULD: H.263 H.261 Theora
> MUST: H.264 Theora; SHOULD: H.263 H.261
> MUST: H.264 H.261; SHOULD: H.263
> MUST: H.264 H.261; SHOULD: H.263 Theora
> MUST: H.264 H.261 Theora; SHOULD: H.263
> MUST: H.264 H.263
> MUST: H.264 H.263; SHOULD: Theora
> MUST: H.264 H.263 Theora
> MUST: H.264 H.263; SHOULD: H.261
> MUST: H.264 H.263; SHOULD: H.261 Theora
> MUST: H.264 H.263 Theora; SHOULD: H.261
> MUST: H.264 H.263 H.261
> MUST: H.264 H.263 H.261; SHOULD: Theora
> MUST: H.264 H.263 H.261 Theora
> MUST: H.264; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 Theora
> MUST: H.264 Theora; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 H.261
> MUST: H.264; SHOULD: VP8 H.261 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.261
> MUST: H.264 H.261; SHOULD: VP8
> MUST: H.264 H.261; SHOULD: VP8 Theora
> MUST: H.264 H.261 Theora; SHOULD: VP8
> MUST: H.264; SHOULD: VP8 H.263
> MUST: H.264; SHOULD: VP8 H.263 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.263
> MUST: H.264; SHOULD: VP8 H.263 H.261
> MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
> MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
> MUST: H.264 H.261; SHOULD: VP8 H.263
> MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
> MUST: H.264 H.261 Theora; SHOULD: VP8 H.263
> MUST: H.264 H.263; SHOULD: VP8
> MUST: H.264 H.263; SHOULD: VP8 Theora
> MUST: H.264 H.263 Theora; SHOULD: VP8
> MUST: H.264 H.263; SHOULD: VP8 H.261
> MUST: H.264 H.263; SHOULD: VP8 H.261 Theora
> MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
> MUST: H.264 H.263 H.261; SHOULD: VP8
> MUST: H.264 H.263 H.261; SHOULD: VP8 Theora
> MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
> MUST: H.264 VP8
> MUST: H.264 VP8; SHOULD: Theora
> MUST: H.264 VP8 Theora
> MUST: H.264 VP8; SHOULD: H.261
> MUST: H.264 VP8; SHOULD: H.261 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.261
> MUST: H.264 VP8 H.261
> MUST: H.264 VP8 H.261; SHOULD: Theora
> MUST: H.264 VP8 H.261 Theora
> MUST: H.264 VP8; SHOULD: H.263
> MUST: H.264 VP8; SHOULD: H.263 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.263
> MUST: H.264 VP8; SHOULD: H.263 H.261
> MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
> MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
> MUST: H.264 VP8 H.261; SHOULD: H.263
> MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
> MUST: H.264 VP8 H.261 Theora; SHOULD: H.263
> MUST: H.264 VP8 H.263
> MUST: H.264 VP8 H.263; SHOULD: Theora
> MUST: H.264 VP8 H.263 Theora
> MUST: H.264 VP8 H.263; SHOULD: H.261
> MUST: H.264 VP8 H.263; SHOULD: H.261 Theora
> MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
> MUST: H.264 VP8 H.263 H.261
> MUST: H.264 VP8 H.263 H.261; SHOULD: Theora
> MUST: H.264 VP8 H.263 H.261 Theora
> SHOULD do 1 of {H.261, Theora}
> SHOULD do 1 of {H.263, Theora}
> SHOULD do 1 of {H.263, H.261}
> SHOULD do 1 of {H.263, H.261, Theora}
> SHOULD do 2 of {H.263, H.261, Theora}
> SHOULD do 1 of {VP8, Theora}
> SHOULD do 1 of {VP8, H.261}
> SHOULD do 1 of {VP8, H.261, Theora}
> SHOULD do 2 of {VP8, H.261, Theora}
> SHOULD do 1 of {VP8, H.263}
> SHOULD do 1 of {VP8, H.263, Theora}
> SHOULD do 2 of {VP8, H.263, Theora}
> SHOULD do 1 of {VP8, H.263, H.261}
> SHOULD do 2 of {VP8, H.263, H.261}
> SHOULD do 1 of {VP8, H.263, H.261, Theora}
> SHOULD do 2 of {VP8, H.263, H.261, Theora}
> SHOULD do 3 of {VP8, H.263, H.261, Theora}
> SHOULD do 1 of {H.264, Theora}
> SHOULD do 1 of {H.264, H.261}
> SHOULD do 1 of {H.264, H.261, Theora}
> SHOULD do 2 of {H.264, H.261, Theora}
> SHOULD do 1 of {H.264, H.263}
> SHOULD do 1 of {H.264, H.263, Theora}
> SHOULD do 2 of {H.264, H.263, Theora}
> SHOULD do 1 of {H.264, H.263, H.261}
> SHOULD do 2 of {H.264, H.263, H.261}
> SHOULD do 1 of {H.264, H.263, H.261, Theora}
> SHOULD do 2 of {H.264, H.263, H.261, Theora}
> SHOULD do 3 of {H.264, H.263, H.261, Theora}
> SHOULD do 1 of {H.264, VP8}
> SHOULD do 1 of {H.264, VP8, Theora}
> SHOULD do 2 of {H.264, VP8, Theora}
> SHOULD do 1 of {H.264, VP8, H.261}
> SHOULD do 2 of {H.264, VP8, H.261}
> SHOULD do 1 of {H.264, VP8, H.261, Theora}
> SHOULD do 2 of {H.264, VP8, H.261, Theora}
> SHOULD do 3 of {H.264, VP8, H.261, Theora}
> SHOULD do 1 of {H.264, VP8, H.263}
> SHOULD do 2 of {H.264, VP8, H.263}
> SHOULD do 1 of {H.264, VP8, H.263, Theora}
> SHOULD do 2 of {H.264, VP8, H.263, Theora}
> SHOULD do 3 of {H.264, VP8, H.263, Theora}
> SHOULD do 1 of {H.264, VP8, H.263, H.261}
> SHOULD do 2 of {H.264, VP8, H.263, H.261}
> SHOULD do 3 of {H.264, VP8, H.263, H.261}
> SHOULD do 1 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 3 of {H.264, VP8, H.263, H.261, Theora}
> SHOULD do 4 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 1 of {H.261, Theora}
> MUST do 1 of {H.263, Theora}
> MUST do 1 of {H.263, H.261}
> MUST do 1 of {H.263, H.261, Theora}
> MUST do 2 of {H.263, H.261, Theora}
> MUST do 1 of {VP8, Theora}
> MUST do 1 of {VP8, H.261}
> MUST do 1 of {VP8, H.261, Theora}
> MUST do 2 of {VP8, H.261, Theora}
> MUST do 1 of {VP8, H.263}
> MUST do 1 of {VP8, H.263, Theora}
> MUST do 2 of {VP8, H.263, Theora}
> MUST do 1 of {VP8, H.263, H.261}
> MUST do 2 of {VP8, H.263, H.261}
> MUST do 1 of {VP8, H.263, H.261, Theora}
> MUST do 2 of {VP8, H.263, H.261, Theora}
> MUST do 3 of {VP8, H.263, H.261, Theora}
> MUST do 1 of {H.264, Theora}
> MUST do 1 of {H.264, H.261}
> MUST do 1 of {H.264, H.261, Theora}
> MUST do 2 of {H.264, H.261, Theora}
> MUST do 1 of {H.264, H.263}
> MUST do 1 of {H.264, H.263, Theora}
> MUST do 2 of {H.264, H.263, Theora}
> MUST do 1 of {H.264, H.263, H.261}
> MUST do 2 of {H.264, H.263, H.261}
> MUST do 1 of {H.264, H.263, H.261, Theora}
> MUST do 2 of {H.264, H.263, H.261, Theora}
> MUST do 3 of {H.264, H.263, H.261, Theora}
> MUST do 1 of {H.264, VP8}
> MUST do 1 of {H.264, VP8, Theora}
> MUST do 2 of {H.264, VP8, Theora}
> MUST do 1 of {H.264, VP8, H.261}
> MUST do 2 of {H.264, VP8, H.261}
> MUST do 1 of {H.264, VP8, H.261, Theora}
> MUST do 2 of {H.264, VP8, H.261, Theora}
> MUST do 3 of {H.264, VP8, H.261, Theora}
> MUST do 1 of {H.264, VP8, H.263}
> MUST do 2 of {H.264, VP8, H.263}
> MUST do 1 of {H.264, VP8, H.263, Theora}
> MUST do 2 of {H.264, VP8, H.263, Theora}
> MUST do 3 of {H.264, VP8, H.263, Theora}
> MUST do 1 of {H.264, VP8, H.263, H.261}
> MUST do 2 of {H.264, VP8, H.263, H.261}
> MUST do 3 of {H.264, VP8, H.263, H.261}
> MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 2 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 3 of {H.264, VP8, H.263, H.261, Theora}
> MUST do 4 of {H.264, VP8, H.263, H.261, Theora}
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>> On Thu, Nov 21, 2013 at 11:27 AM, Cullen Jennings  wrote:
>>=20
>> Added a
>>=20
>> #11     =E2=80=A2 MUST implement at least two of {VP8, H.264 CBP, H.263}
>>=20
>>=20
>> On Nov 21, 2013, at 11:20 AM, David Singer  wrote:
>>=20
>> > Chairs
>> >
>> > can we add this as an option to the formal list, so we get formal feedb=
ack on its acceptability, please?
>> >
>> > =E2=80=9CLike option ??, pick at least two of {VP8, H.264 CBP, H.263}=E2=
=80=9D
>> >
>> >
>> > I think this may be the best (maybe only) way to tease out how much ris=
k people perceive.
>> >
>> > Many thanks
>> >
>> > On Nov 21, 2013, at 9:22 , Maik Merten  wrot=
e:
>> >
>> >> Cleary H.263 is preferable from an engineering standpoint (as is, e.g.=
, MPEG-1 Part 2): better performance, more deployments. The central question=
 is, however, if those can actually be implemented without some sort of lice=
nsing.
>> >>
>> >> If they can: Aweseome! However, this may not be determinable without a=
 review by people who are knowledgeable in the field of IPR, i.e., "actual l=
awyers". I understand that H.263 is not yet old enough to automatically be c=
onsidered "safe" (and neither is MPEG-1 Part 2, although it is closer).
>> >>
>> >> Best regards,
>> >>
>> >> Maik
>> >>
>> >> Am 20.11.2013 20:42, schrieb David Singer:
>> >>> I think we should think hard about H.263 instead of H.261 as the thir=
d fallback.  Why?
>> >>>
>> >>> http://www.itu.int/rec/T-REC-H.263/
>> >>>
>> >>>
>> >>>
>> >>> H.263 was first published in March 1996, so it's 17 years old.  The r=
estrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more recen=
t amendments deal with this (and a plethora of other issues), so we=E2=80=99=
d need to settle on which of those are mandatory (the usual profiling discus=
sion).
>> >>>
>> >>> There are 34 records in the patent database against H.261, mostly fro=
m 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2 (re=
ciprocity), as was one other I checked.
>> >>>
>> >>> Rather surprisingly, there are only 31 against H.263!  The most recen=
t is 2011, and is also option 2.  Most are 1997-2001.
>> >>>
>> >>>
>> >>> On this quick glance, H.263 appears no worse than H.261. IANAL (as I a=
m sure you have all noticed).
>> >>>
>> >>>
>> >>> H.263 is much more widely supported and mandated.  It has been mandat=
ed in the 3GPP specs for years (for lots of services, including videoconf), a=
nd is effectively the fallback codec today in the industry, as I understand.=
  It was ubiquitous in video telephony for years, and I suspect many of thos=
e systems still ship it.
>> >>>
>> >>> So, would =E2=80=9CMUST implement at least two of (H.264, VP8, H.263)=
=E2=80=9D work?
>> >>>
>> >>> (I am asking the question, not even answering on behalf of my company=
, yet.  Let=E2=80=99s get the issues on the table.)
>> >>>
>> >>>
>> >>> David Singer
>> >>> Multimedia and Software Standards, Apple Inc.
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> > David Singer
>> > Multimedia and Software Standards, Apple Inc.
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

--Apple-Mail-90E435E5-ED6C-47BB-82BB-52F948F7EC99
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    +1

    Matthew Kaufman

    (Sen=
t from my iPhone)

    On Nov 21, 2013, at 12:01 PM, Eric Res=
corla <ekr@rtfm.com> wrote:
    I would like to propo=
se some additional alternatives.

    SHOULD: Theora
    MUST: Theora
    SHOULD: H.261
    SHOULD: H.261 Theora
    MUST: Theora; SHOULD: H.261
    



    MUST: H.261
    MUST: H.261; SHOULD: Theora
    MUST: H.261=
 Theora
    SHOULD: H.263
    SHOULD: H.263 Theora
    MUS=
T: Theora; SHOULD: H.263
    SHOULD: H.263 H.261
    SHOULD: H.2=
63 H.261 Theora
    



    MUST: Theora; SHOULD: H.263 H.261
    MUST: H.261; SHOULD: H.263<=
/div>
    MUST: H.261; SHOULD: H.263 Theora
    MUST: H.261 Theora; SH=
OULD: H.263
    MUST: H.263
    MUST: H.263; SHOULD: Theora



    MUST: H.263 Theora
    MUST: H.263; SHOULD: H.261
    MUST:=
 H.263; SHOULD: H.261 Theora
    MUST: H.263 Theora; SHOULD: H.261
    MUST: H.263 H.261
    MUST: H.263 H.261; SHOULD: Theora
    



    MUST: H.263 H.261 Theora
    SHOULD: VP8
    SHOULD: VP8 Th=
eora
    MUST: Theora; SHOULD: VP8
    SHOULD: VP8 H.261
    SHOULD: VP8 H.261 Theora
    MUST: Theora; SHOULD: VP8 H.261
    



    MUST: H.261; SHOULD: VP8
    MUST: H.261; SHOULD: VP8 Theora
    MUST: H.261 Theora; SHOULD: VP8
    SHOULD: VP8 H.263
    =
SHOULD: VP8 H.263 Theora
    MUST: Theora; SHOULD: VP8 H.263
    



    SHOULD: VP8 H.263 H.261
    SHOULD: VP8 H.263 H.261 Theora
    <=
div>MUST: Theora; SHOULD: VP8 H.263 H.261
    MUST: H.261; SHOULD: VP8=
 H.263
    MUST: H.261; SHOULD: VP8 H.263 Theora
    MUST: H.261=
 Theora; SHOULD: VP8 H.263
    



    MUST: H.263; SHOULD: VP8
    MUST: H.263; SHOULD: VP8 Theora
    MUST: H.263 Theora; SHOULD: VP8
    MUST: H.263; SHOULD: VP8 H.2=
61
    MUST: H.263; SHOULD: VP8 H.261 Theora
    MUST: H.263 The=
ora; SHOULD: VP8 H.261
    



    MUST: H.263 H.261; SHOULD: VP8
    MUST: H.263 H.261; SHOULD: VP8=
 Theora
    MUST: H.263 H.261 Theora; SHOULD: VP8
    MUST: VP8<=
/div>
    MUST: VP8; SHOULD: Theora
    MUST: VP8 Theora
    


    
MUST: VP8; SHOULD: H.261
    MUST: VP8; SHOULD: H.261 Theora
    MUST: VP8 Theora; SHOULD: H.261
    MUST: VP8 H.261
    MUST: V=
P8 H.261; SHOULD: Theora
    MUST: VP8 H.261 Theora
    

MUST: VP8; SHOULD: H.263
    

    MUST: VP8; SHOULD: H.263 Theora
    MUST: VP8 Theora; SHOULD: H.2=
63
    MUST: VP8; SHOULD: H.263 H.261
    MUST: VP8; SHOULD: H.2=
63 H.261 Theora
    MUST: VP8 Theora; SHOULD: H.263 H.261
    



    MUST: VP8 H.261; SHOULD: H.263
    MUST: VP8 H.261; SHOULD: H.263=
 Theora
    MUST: VP8 H.261 Theora; SHOULD: H.263
    MUST: VP8 H=
.263
    MUST: VP8 H.263; SHOULD: Theora
    MUST: VP8 H.263 The=
ora
    



    MUST: VP8 H.263; SHOULD: H.261
    MUST: VP8 H.263; SHOULD: H.261=
 Theora
    MUST: VP8 H.263 Theora; SHOULD: H.261
    MUST: VP8 H=
.263 H.261
    MUST: VP8 H.263 H.261; SHOULD: Theora
    


MUST: VP8 H.263 H.261 Theora
    SHOULD: H.264
    SHOULD: H.264=
 Theora
    MUST: Theora; SHOULD: H.264
    SHOULD: H.264 H.261<=
/div>
    SHOULD: H.264 H.261 Theora
    MUST: Theora; SHOULD: H.264 H=
.261
    



    MUST: H.261; SHOULD: H.264
    MUST: H.261; SHOULD: H.264 Theora<=
/div>
    MUST: H.261 Theora; SHOULD: H.264
    SHOULD: H.264 H.263
    SHOULD: H.264 H.263 Theora
    MUST: Theora; SHOULD: H.264 H.2=
63
    



    SHOULD: H.264 H.263 H.261
    SHOULD: H.264 H.263 H.261 Theora
    MUST: Theora; SHOULD: H.264 H.263 H.261
    MUST: H.261; SHOUL=
D: H.264 H.263
    MUST: H.261; SHOULD: H.264 H.263 Theora
    



    MUST: H.261 Theora; SHOULD: H.264 H.263
    MUST: H.263; SHOULD: H=
.264
    MUST: H.263; SHOULD: H.264 Theora
    MUST: H.263 Theor=
a; SHOULD: H.264
    MUST: H.263; SHOULD: H.264 H.261
    


MUST: H.263; SHOULD: H.264 H.261 Theora
    MUST: H.263 Theora; SHOULD=
: H.264 H.261
    MUST: H.263 H.261; SHOULD: H.264
    MUST: H.2=
63 H.261; SHOULD: H.264 Theora
    MUST: H.263 H.261 Theora; SHOULD: H=
.264
    



    SHOULD: H.264 VP8
    SHOULD: H.264 VP8 Theora
    MUST: Th=
eora; SHOULD: H.264 VP8
    SHOULD: H.264 VP8 H.261
    SHOULD: H=
.264 VP8 H.261 Theora
    MUST: Theora; SHOULD: H.264 VP8 H.261
    



    MUST: H.261; SHOULD: H.264 VP8
    MUST: H.261; SHOULD: H.264 VP8=
 Theora
    MUST: H.261 Theora; SHOULD: H.264 VP8
    SHOULD: H.=
264 VP8 H.263
    SHOULD: H.264 VP8 H.263 Theora
    MUST: Theor=
a; SHOULD: H.264 VP8 H.263
    



    SHOULD: H.264 VP8 H.263 H.261
    SHOULD: H.264 VP8 H.263 H.261 T=
heora
    MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
    MUST: H=
.261; SHOULD: H.264 VP8 H.263
    MUST: H.261; SHOULD: H.264 VP8 H.263=
 Theora
    



    MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
    MUST: H.263; SHOU=
LD: H.264 VP8
    MUST: H.263; SHOULD: H.264 VP8 Theora
    MUST=
: H.263 Theora; SHOULD: H.264 VP8
    MUST: H.263; SHOULD: H.264 VP8 H=
.261
    



    MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
    MUST: H.263 Theor=
a; SHOULD: H.264 VP8 H.261
    MUST: H.263 H.261; SHOULD: H.264 VP8
    MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
    MUST: H.263 H.=
261 Theora; SHOULD: H.264 VP8
    



    MUST: VP8; SHOULD: H.264
    MUST: VP8; SHOULD: H.264 Theora
    MUST: VP8 Theora; SHOULD: H.264
    MUST: VP8; SHOULD: H.264 H.2=
61
    MUST: VP8; SHOULD: H.264 H.261 Theora
    MUST: VP8 Theor=
a; SHOULD: H.264 H.261
    



    MUST: VP8 H.261; SHOULD: H.264
    MUST: VP8 H.261; SHOULD: H.264=
 Theora
    MUST: VP8 H.261 Theora; SHOULD: H.264
    MUST: VP8;=
 SHOULD: H.264 H.263
    MUST: VP8; SHOULD: H.264 H.263 Theora
    



    MUST: VP8 Theora; SHOULD: H.264 H.263
    MUST: VP8; SHOULD: H.26=
4 H.263 H.261
    MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
    MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
    MUST: VP8 H.261; SHO=
ULD: H.264 H.263
    



    MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
    MUST: VP8 H.261 T=
heora; SHOULD: H.264 H.263
    MUST: VP8 H.263; SHOULD: H.264
    MUST: VP8 H.263; SHOULD: H.264 Theora
    MUST: VP8 H.263 Theora; SH=
OULD: H.264
    



    MUST: VP8 H.263; SHOULD: H.264 H.261
    MUST: VP8 H.263; SHOULD:=
 H.264 H.261 Theora
    MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
    MUST: VP8 H.263 H.261; SHOULD: H.264
    MUST: VP8 H.263 H.261=
; SHOULD: H.264 Theora
    



    MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
    MUST: H.264
    =

    MUST: H.264; SHOULD: Theora
    MUST: H.264 Theora
    MUST=
: H.264; SHOULD: H.261
    MUST: H.264; SHOULD: H.261 Theora
    



    MUST: H.264 Theora; SHOULD: H.261
    MUST: H.264 H.261
    MUST: H.264 H.261; SHOULD: Theora
    MUST: H.264 H.261 Theora
    <=
div>MUST: H.264; SHOULD: H.263
    MUST: H.264; SHOULD: H.263 Theora



    MUST: H.264 Theora; SHOULD: H.263
    MUST: H.264; SHOULD: H.263 H=
.261
    MUST: H.264; SHOULD: H.263 H.261 Theora
    MUST: H.264=
 Theora; SHOULD: H.263 H.261
    MUST: H.264 H.261; SHOULD: H.263



    MUST: H.264 H.261; SHOULD: H.263 Theora
    MUST: H.264 H.261 The=
ora; SHOULD: H.263
    MUST: H.264 H.263
    MUST: H.264 H.263; S=
HOULD: Theora
    MUST: H.264 H.263 Theora
    MUST: H.264 H.263=
; SHOULD: H.261
    



    MUST: H.264 H.263; SHOULD: H.261 Theora
    MUST: H.264 H.263 The=
ora; SHOULD: H.261
    MUST: H.264 H.263 H.261
    MUST: H.264 H=
.263 H.261; SHOULD: Theora
    MUST: H.264 H.263 H.261 Theora
    



    MUST: H.264; SHOULD: VP8
    MUST: H.264; SHOULD: VP8 Theora
    MUST: H.264 Theora; SHOULD: VP8
    MUST: H.264; SHOULD: VP8 H.2=
61
    MUST: H.264; SHOULD: VP8 H.261 Theora
    MUST: H.264 The=
ora; SHOULD: VP8 H.261
    



    MUST: H.264 H.261; SHOULD: VP8
    MUST: H.264 H.261; SHOULD: VP8=
 Theora
    MUST: H.264 H.261 Theora; SHOULD: VP8
    MUST: H.26=
4; SHOULD: VP8 H.263
    MUST: H.264; SHOULD: VP8 H.263 Theora
    



    MUST: H.264 Theora; SHOULD: VP8 H.263
    MUST: H.264; SHOULD: VP=
8 H.263 H.261
    MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
    MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
    MUST: H.264 H.261; S=
HOULD: VP8 H.263
    



    MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
    MUST: H.264 H.261=
 Theora; SHOULD: VP8 H.263
    MUST: H.264 H.263; SHOULD: VP8
    MUST: H.264 H.263; SHOULD: VP8 Theora
    MUST: H.264 H.263 Theora; S=
HOULD: VP8
    



    MUST: H.264 H.263; SHOULD: VP8 H.261
    MUST: H.264 H.263; SHOUL=
D: VP8 H.261 Theora
    MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
    MUST: H.264 H.263 H.261; SHOULD: VP8
    MUST: H.264 H.263 H.2=
61; SHOULD: VP8 Theora
    



    MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
    MUST: H.264 VP8
    MUST: H.264 VP8; SHOULD: Theora
    MUST: H.264 VP8 Theora
    MUST: H.264 VP8; SHOULD: H.261
    MUST: H.264 VP8; SHOULD: H.=
261 Theora
    



    MUST: H.264 VP8 Theora; SHOULD: H.261
    MUST: H.264 VP8 H.261
    MUST: H.264 VP8 H.261; SHOULD: Theora
    MUST: H.264 VP8 H.2=
61 Theora
    MUST: H.264 VP8; SHOULD: H.263
    MUST: H.264 VP8=
; SHOULD: H.263 Theora
    



    MUST: H.264 VP8 Theora; SHOULD: H.263
    MUST: H.264 VP8; SHOULD=
: H.263 H.261
    MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
    MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
    MUST: H.264 VP8 H.26=
1; SHOULD: H.263
    



    MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
    MUST: H.264 VP8 H=
.261 Theora; SHOULD: H.263
    MUST: H.264 VP8 H.263
    MUST: H=
.264 VP8 H.263; SHOULD: Theora
    MUST: H.264 VP8 H.263 Theora
    



    MUST: H.264 VP8 H.263; SHOULD: H.261
    MUST: H.264 VP8 H.263; S=
HOULD: H.261 Theora
    MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
    MUST: H.264 VP8 H.263 H.261
    MUST: H.264 VP8 H.263 H.261; S=
HOULD: Theora
    



    MUST: H.264 VP8 H.263 H.261 Theora
    SHOULD do 1 of {H.261, The=
ora}
    SHOULD do 1 of {H.263, Theora}
    SHOULD do 1 of {H.26=
3, H.261}
    SHOULD do 1 of {H.263, H.261, Theora}
    

SHOULD do 2 of {H.263, H.261, Theora}
    

    SHOULD do 1 of {VP8, Theora}
    SHOULD do 1 of {VP8, H.261}
    SHOULD do 1 of {VP8, H.261, Theora}
    SHOULD do 2 of {VP8, H.2=
61, Theora}
    SHOULD do 1 of {VP8, H.263}
    SHOULD do 1 of {=
VP8, H.263, Theora}
    



    SHOULD do 2 of {VP8, H.263, Theora}
    SHOULD do 1 of {VP8, H.26=
3, H.261}
    SHOULD do 2 of {VP8, H.263, H.261}
    SHOULD do 1=
 of {VP8, H.263, H.261, Theora}
    SHOULD do 2 of {VP8, H.263, H.261,=
 Theora}
    



    SHOULD do 3 of {VP8, H.263, H.261, Theora}
    SHOULD do 1 of {H.=
264, Theora}
    SHOULD do 1 of {H.264, H.261}
    SHOULD do 1 o=
f {H.264, H.261, Theora}
    SHOULD do 2 of {H.264, H.261, Theora}



    SHOULD do 1 of {H.264, H.263}
    SHOULD do 1 of {H.264, H.263, T=
heora}
    SHOULD do 2 of {H.264, H.263, Theora}
    SHOULD do 1=
 of {H.264, H.263, H.261}
    SHOULD do 2 of {H.264, H.263, H.261}



    SHOULD do 1 of {H.264, H.263, H.261, Theora}
    SHOULD do 2 of {=
H.264, H.263, H.261, Theora}
    SHOULD do 3 of {H.264, H.263, H.261, T=
heora}
    SHOULD do 1 of {H.264, VP8}
    SHOULD do 1 of {H.264=
, VP8, Theora}
    



    SHOULD do 2 of {H.264, VP8, Theora}
    SHOULD do 1 of {H.264, VP=
8, H.261}
    SHOULD do 2 of {H.264, VP8, H.261}
    SHOULD do 1=
 of {H.264, VP8, H.261, Theora}
    SHOULD do 2 of {H.264, VP8, H.261,=
 Theora}
    



    SHOULD do 3 of {H.264, VP8, H.261, Theora}
    SHOULD do 1 of {H.=
264, VP8, H.263}
    SHOULD do 2 of {H.264, VP8, H.263}
    SHOU=
LD do 1 of {H.264, VP8, H.263, Theora}
    SHOULD do 2 of {H.264, VP8,=
 H.263, Theora}
    



    SHOULD do 3 of {H.264, VP8, H.263, Theora}
    SHOULD do 1 of {H.=
264, VP8, H.263, H.261}
    SHOULD do 2 of {H.264, VP8, H.263, H.261}<=
/div>
    SHOULD do 3 of {H.264, VP8, H.263, H.261}
    SHOULD do 1 of=
 {H.264, VP8, H.263, H.261, Theora}
    



    SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
    SHOULD do 3=
 of {H.264, VP8, H.263, H.261, Theora}
    SHOULD do 4 of {H.264, VP8,=
 H.263, H.261, Theora}
    MUST do 1 of {H.261, Theora}
    


MUST do 1 of {H.263, Theora}
    MUST do 1 of {H.263, H.261}
    MUST do 1 of {H.263, H.261, Theora}
    MUST do 2 of {H.263, H.261, T=
heora}
    MUST do 1 of {VP8, Theora}
    MUST do 1 of {VP8, H.2=
61}
    



    MUST do 1 of {VP8, H.261, Theora}
    MUST do 2 of {VP8, H.261, T=
heora}
    MUST do 1 of {VP8, H.263}
    MUST do 1 of {VP8, H.26=
3, Theora}
    MUST do 2 of {VP8, H.263, Theora}
    MUST do 1 o=
f {VP8, H.263, H.261}
    



    MUST do 2 of {VP8, H.263, H.261}
    MUST do 1 of {VP8, H.263, H.=
261, Theora}
    MUST do 2 of {VP8, H.263, H.261, Theora}
    MU=
ST do 3 of {VP8, H.263, H.261, Theora}
    MUST do 1 of {H.264, Theora=
}
    



    MUST do 1 of {H.264, H.261}
    MUST do 1 of {H.264, H.261, Theor=
a}
    MUST do 2 of {H.264, H.261, Theora}
    MUST do 1 of {H.2=
64, H.263}
    MUST do 1 of {H.264, H.263, Theora}
    MUST do 2=
 of {H.264, H.263, Theora}
    



    MUST do 1 of {H.264, H.263, H.261}
    MUST do 2 of {H.264, H.263=
, H.261}
    MUST do 1 of {H.264, H.263, H.261, Theora}
    MUST=
 do 2 of {H.264, H.263, H.261, Theora}
    MUST do 3 of {H.264, H.263,=
 H.261, Theora}
    



    MUST do 1 of {H.264, VP8}
    MUST do 1 of {H.264, VP8, Theora}
    MUST do 2 of {H.264, VP8, Theora}
    MUST do 1 of {H.264, VP=
8, H.261}
    MUST do 2 of {H.264, VP8, H.261}
    MUST do 1 of {=
H.264, VP8, H.261, Theora}
    



    MUST do 2 of {H.264, VP8, H.261, Theora}
    MUST do 3 of {H.264,=
 VP8, H.261, Theora}
    MUST do 1 of {H.264, VP8, H.263}
    MU=
ST do 2 of {H.264, VP8, H.263}
    MUST do 1 of {H.264, VP8, H.263, Th=
eora}
    



    MUST do 2 of {H.264, VP8, H.263, Theora}
    MUST do 3 of {H.264,=
 VP8, H.263, Theora}
    MUST do 1 of {H.264, VP8, H.263, H.261}
    =

    MUST do 2 of {H.264, VP8, H.263, H.261}
    MUST do 3 of {H.264, V=
P8, H.263, H.261}
    



    MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
    MUST do 2 of {=
H.264, VP8, H.263, H.261, Theora}
    MUST do 3 of {H.264, VP8, H.263,=
 H.261, Theora}
    MUST do 4 of {H.264, VP8, H.263, H.261, Theora}








    <=
/div>


    On Thu, N=
ov 21, 2013 at 11:27 AM, Cullen Jennings <fluffy@iii.ca> wrote:




    
Added a
    

    
#11     =E2=80=A2 MUST implement at least two of {VP8, H.264 CBP, H=
.263}
    


    

    
On Nov 21, 2013, at 11:20 AM, David Singer <singer@apple.com> wrote:
    

    
> Chairs
    
>
    
> can we add this as an option to the formal list, so we get formal feedb=
ack on its acceptability, please?
    
>
    
> =E2=80=9CLike option ??, pick at least two of {VP8, H.264 CBP, H.263}=E2=
=80=9D
    
>
    
>
    
> I think this may be the best (maybe only) way to tease out how much ris=
k people perceive.
    
>
    
> Many thanks
    
>
    
> On Nov 21, 2013, at 9:22 , Maik Merten <maikmerten@googlemail.com> wrote:<=
br>
>
    
>> Cleary H.263 is preferable from an engineering standpoint (as is, e=
.g., MPEG-1 Part 2): better performance, more deployments. The central quest=
ion is, however, if those can actually be implemented without some sort of l=
icensing.
    



>>
    
>> If they can: Aweseome! However, this may not be determinable withou=
t a review by people who are knowledgeable in the field of IPR, i.e., "actua=
l lawyers". I understand that H.263 is not yet old enough to automatically b=
e considered "safe" (and neither is MPEG-1 Part 2, although it is closer).



>>
    
>> Best regards,
    
>>
    
>> Maik
    
>>
    
>> Am 20.11.2013 20:42, schrieb David Singer:
    
>>> I think we should think hard about H.263 instead of H.261 as th=
e third fallback.  Why?
    
>>>
    
>>> http://www.itu.int/rec/T-REC-H.263/
    
>>>
    
>>>
    
>>>
    
>>> H.263 was first published in March 1996, so it's 17 years old. &=
nbsp;The restrictions (e.g. on picture size) are no WORSE than H.261.  =
Yes, more recent amendments deal with this (and a plethora of other issues),=
 so we=E2=80=99d need to settle on which of those are mandatory (the usual p=
rofiling discussion).
    



>>>
    
>>> There are 34 records in the patent database against H.261, most=
ly from 1989 but one as recent as 2005 (though that is a re-file).  Tha=
t's 2.2 (reciprocity), as was one other I checked.
    
>>>
    
>>> Rather surprisingly, there are only 31 against H.263!  The=
 most recent is 2011, and is also option 2.  Most are 1997-2001.
    
>>>
    
>>>
    
>>> On this quick glance, H.263 appears no worse than H.261. IANAL (=
as I am sure you have all noticed).
    
>>>
    
>>>
    
>>> H.263 is much more widely supported and mandated.  It has b=
een mandated in the 3GPP specs for years (for lots of services, including vi=
deoconf), and is effectively the fallback codec today in the industry, as I u=
nderstand.  It was ubiquitous in video telephony for years, and I suspe=
ct many of those systems still ship it.
    



>>>
    
>>> So, would =E2=80=9CMUST implement at least two of (H.264, VP8, H=
.263)=E2=80=9D work?
    
>>>
    
>>> (I am asking the question, not even answering on behalf of my c=
ompany, yet.  Let=E2=80=99s get the issues on the table.)
    
>>>
    
>>>
    
>>> David Singer
    
>>> Multimedia and Software Standards, Apple Inc.
    
>>>
    
>>> _______________________________________________
    
>>> rtcweb mailing list
    
>>> rtcweb@iet=
f.org
    
>>> https://www.ietf.org/mailman/listinfo/rtcweb
    
>>>
    
>>
    
>> _______________________________________________
    
>> rtcweb mailing list
    
>> rtcweb@ietf.or=
g
    
>> https://www.ietf.org/mailman/listinfo/rtcweb
    
>
    
> David Singer
    
> Multimedia and Software Standards, Apple Inc.
    
>
    
> _______________________________________________
    
> rtcweb mailing list
    
> rtcweb@ietf.org
    
>     https://www.ietf.org/mailman/listinfo/rtcweb
    

    
_______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    =

h=
ttps://www.ietf.org/mailman/listinfo/rtcweb
    


    

    ____________________=
___________________________
    rtcweb mailing list
    rtcweb@ietf.org
    <=
a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org=
/mailman/listinfo/rtcweb
    =

--Apple-Mail-90E435E5-ED6C-47BB-82BB-52F948F7EC99--


From ekr@rtfm.com  Thu Nov 21 13:41:33 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C074A1AE380 for ; Thu, 21 Nov 2013 13:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlQ64YAJ5w7Q for ; Thu, 21 Nov 2013 13:41:31 -0800 (PST)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id CE1611AE37F for ; Thu, 21 Nov 2013 13:41:30 -0800 (PST)
Received: by mail-wi0-f178.google.com with SMTP id ca18so1751517wib.17 for ; Thu, 21 Nov 2013 13:41:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Pql//zK7fu8zndPdrdIYmE29saAyji6zzlmDn59Wtt0=; b=Wlg5Ht3noD/PQm1HqMCnx/jPWIvCprXfIgQqEJFNiiRhKjS8ROjhke7HCBJO9VgfCA ZUFXf+wJDbjIZmy/UXNlKJ4CpekAdavUv4HF3x5ZZG6HjS5fptQGaNgXJ0YC0foQ96mR sm60Qs8tTiaeCE38FcsnA9kNquL664GOm/t8Js/1TIkUDA0aLYog3KdMnJoYWrLdQ0q9 rzucd5U1lvcJywEcMjopW4oOKo0nckV75wiDH+Pd9U9hCnj9g4v7xqZXa5I0X/z7RHc8 /vR0gbG8Qp1HAmSO0EwkgL5x+hEuXlqt+nVKCcX8E9YogbDYi15WCS++oaB919eY/pKA GiLg==
X-Gm-Message-State: ALoCoQmAdlwUEBnDsr5CwhABd/SUiYnxdzQ9Ju3o7egzOFJxfcSlJ6zEBI7sGzFDWsNwf536tHTY
X-Received: by 10.180.24.137 with SMTP id u9mr7720862wif.5.1385070083524; Thu, 21 Nov 2013 13:41:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 21 Nov 2013 13:40:43 -0800 (PST)
X-Originating-IP: [2620:101:8003:300:481b:90de:7d1a:71eb]
In-Reply-To: <528E7C26.3000100@googlemail.com>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>   <528E7C26.3000100@googlemail.com>
From: Eric Rescorla 
Date: Thu, 21 Nov 2013 13:40:43 -0800
Message-ID: 
To: Maik Merten 
Content-Type: multipart/alternative; boundary=f46d04447f67515c7204ebb6c2a5
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:41:34 -0000

--f46d04447f67515c7204ebb6c2a5
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 21, 2013 at 1:33 PM, Maik Merten wrote:

> My understanding is that WebRTC is not a browser-only thing.


I don't recall anyone saying that it was, and that's missing the point.
Rather, given that H.261 is really lame and that most everyone is
going to deploy *either* VP8 or H.264, I'm trying to figure out why
mandating H.261 is useful


 Also: Just because Mozilla may have found a way to sidestep the H.264
> licensing issues with the help of Cisco, this doesn't mean this "fix"
> applies everywhere. For example, is the blob acceptable for Iceweasel? And
> what do the limited distribution rights of OpenH264 mean regarding system
> administration (e.g., replicating machines with disk images)?
>

These may be relevant questions in some other thread, but not here.

However, with that said, Cisco's blob should be usable for IceWeasel.
Whether the IceWeasel people opt to use it is of course up to them.
WRT the second question, 100k images is a lot of images.

-Ekr

Maik
>
> Am 21.11.2013 22:14, schrieb Eric Rescorla:
>
>> Agreed.
>>
>> To take a not-so-random example, given that Firefox will soon
>> support both H.264 and VP8, what additional implementations
>> will it be able to talk to if it does H.261?
>>
>> -Ekr
>>
>>
>>
>>
>> On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson
>> > wrote:
>>
>>     On 21 November 2013 12:48, Basil Mohamed Gohar
>>     > wrote:
>>      > Has anyone actually objected to H.261 being the one MTI codec
>> [...] ?
>>
>>     More than one person has already.
>>
>>     And I find the argument raised quite compelling.  It's hard to justify
>>     spending valuable time and resources on implementing something that
>>     crappy.
>>     _______________________________________________
>>     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
>

--f46d04447f67515c7204ebb6c2a5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    On T=
hu, Nov 21, 2013 at 1:33 PM, Maik Merten <maikmerten@googlemail.co=
m> wrote:
    



    My understanding is that WebRTC is not a bro=
wser-only thing.

    I don't recall anyone =
saying that it was, and that's missing the point.
    


    Rather, given that H.261 is really lame and that most everyone is
    going to deploy *either* VP8 or H.264, I'm trying to figure out w=
hy
    mandating H.261 is useful


    


     Also: Just because Mozilla may have found a=
 way to sidestep the H.264 licensing issues with the help of Cisco, this do=
esn't mean this "fix" applies everywhere. For example, is the=
 blob acceptable for Iceweasel? And what do the limited distribution rights=
 of OpenH264 mean regarding system administration (e.g., replicating machin=
es with disk images)?
    



    These may be relevant questions in some ot=
her thread, but not here.

    However, with that said,=
 Cisco's blob should be usable for IceWeasel.
    Whether the Ice=
Weasel people opt to use it is of course up to them.
    


    WRT the second question, 100k images is a lot of images.
    -Ekr

    
Maik
    

    
Am 21.11.2013 22:14, schrieb Eric Rescorla:
    

    
Agreed.
    

    
To take a not-so-random example, given that Firefox will soon
    
support both H.264 and VP8, what additional implementations
    
will it be able to talk to if it does H.261?
    

    
-Ekr
    

    

    

    

    
On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson
    
<martin.th=
omson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
    

    
=A0 =A0 On 21 November 2013 12:48, Basil Mohamed Gohar
    
=A0 =A0 <=
basilgohar@librevideo.org <mailto:basilgohar@librevideo.org>> w=
rote:
    



=A0 =A0 =A0> Has anyone actually objected to H.261 being the one MTI cod=
ec [...] ?
    

    
=A0 =A0 More than one person has already.
    

    
=A0 =A0 And I find the argument raised quite compelling. =A0It's hard t=
o justify
    
=A0 =A0 spending valuable time and resources on implementing something that=

    
=A0 =A0 crappy.
    
=A0 =A0 _______________________________________________
    
=A0 =A0 rtcweb mailing list
    
=A0 =A0 rtcweb@ietf.or=
g <mailto:rtcwe=
b@ietf.org>
    
=A0 =A0 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
    


    

--f46d04447f67515c7204ebb6c2a5--

From Markus.Isomaki@nokia.com  Thu Nov 21 13:43:57 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF671AE389 for ; Thu, 21 Nov 2013 13:43:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.725
X-Spam-Level: 
X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsEJnWVGm9yH for ; Thu, 21 Nov 2013 13:43:55 -0800 (PST)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id DF33E1AE37E for ; Thu, 21 Nov 2013 13:43:54 -0800 (PST)
Received: from smtp.mgd.nokia.com ([65.54.30.50]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rALLXmmi001075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 21 Nov 2013 23:33:49 +0200
Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.35]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.03.0136.001;  Thu, 21 Nov 2013 21:33:48 +0000
From: 
To: 
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: AQHO5tnkMqQSi3Uo8kudbR+N6LyUKZov+9iAgAACNgCAAAr/gIAABK+AgAAYwYCAAAHxAIAAAPyAgAAGL4CAAAVsrQ==
Date: Thu, 21 Nov 2013 21:33:47 +0000
Message-ID: <2CA8952C-9AD0-49F0-A8E9-160099D09DC9@nokia.com>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org> , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_2CA8952C9AD049F0A8E9160099D09DC9nokiacom_"
MIME-Version: 1.0
X-Nokia-AV: Clean
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:43:57 -0000

--_000_2CA8952C9AD049F0A8E9160099D09DC9nokiacom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Would the implement any two of {VP8, H.264 CBP, H.261} option solve your pr=
oblem?

+1 for Ron's reasoning.

Markus

Sent from my iPad

On Nov 21, 2013, at 23:15, "ext Eric Rescorla" > wrote:

Agreed.

To take a not-so-random example, given that Firefox will soon
support both H.264 and VP8, what additional implementations
will it be able to talk to if it does H.261?

-Ekr




On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson > wrote:
On 21 November 2013 12:48, Basil Mohamed Gohar
> wrote:
> Has anyone actually objected to H.261 being the one MTI codec [...] ?

More than one person has already.

And I find the argument raised quite compelling.  It's hard to justify
spending valuable time and resources on implementing something that
crappy.
_______________________________________________
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

--_000_2CA8952C9AD049F0A8E9160099D09DC9nokiacom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







    Would the implement any two of {VP8, H.264 CBP, H.261} option solve yo=
ur problem?
    


    

    

    +1 for Ron's reasoning.
    


    

    

    Markus
    

    
Sent from my iPad
    


    
On Nov 21, 2013, at 23:15, "ext Eric Rescorla" <ekr@rtfm.com> wrote:
    

    

    

    


    

    

    _______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
https://www.=
ietf.org/mailman/listinfo/rtcweb
    

    

    



--_000_2CA8952C9AD049F0A8E9160099D09DC9nokiacom_--

From ekr@rtfm.com  Thu Nov 21 13:47:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA711AE397 for ; Thu, 21 Nov 2013 13:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG6GV6G0Brha for ; Thu, 21 Nov 2013 13:47:11 -0800 (PST)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8251AE37E for ; Thu, 21 Nov 2013 13:47:10 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hq4so298578wib.8 for ; Thu, 21 Nov 2013 13:47:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ae44BzXEjf6+JbmJjeyr14xaUL/xYdOmf5obxXlFqXA=; b=KKT3fvqCgvS2s31B73azcx68YqA5f2AyK8Zamstt67FtMZ85y91zlYYKm7byY2ofzn wBUgmdze6tImWiO23JE7iOm01jUkB7E0ot3PdFNrHC+xKCSTTc0pdNHqiJ77w0A+oYy4 Rl5kIRaFo6DZlnpctBqZPCCdpPDMzGL8Vbg7I/X/mnIJRhKVeHV5VOyEaSWIRnufa9Ek wx3lFnnyqaV6Tw3hdc7V0C5p8SMZWTYjfwiBdDw3ubjJYd+dcmqVdPzYq9QnVuOPpUvG lCdHL/kiV2DXkm1arQ1hnqU2A9mrQduTyIdgqSRgwHW93q/lG9uZsmensAmljYa/0B8m M0Rg==
X-Gm-Message-State: ALoCoQkHXPOMh5SjEyVLXv98duJOFnPxbUOs81MPQYcmA5X0qqfU1RRI0VjebiMIllxiF8deCjfP
X-Received: by 10.194.122.99 with SMTP id lr3mr7182484wjb.21.1385070423524; Thu, 21 Nov 2013 13:47:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 21 Nov 2013 13:46:23 -0800 (PST)
X-Originating-IP: [2620:101:8003:300:481b:90de:7d1a:71eb]
In-Reply-To: <2CA8952C-9AD0-49F0-A8E9-160099D09DC9@nokia.com>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>   <2CA8952C-9AD0-49F0-A8E9-160099D09DC9@nokia.com>
From: Eric Rescorla 
Date: Thu, 21 Nov 2013 13:46:23 -0800
Message-ID: 
To: "Isomaki Markus (Nokia-SIR/Espoo)" 
Content-Type: multipart/alternative; boundary=089e011779b595688804ebb6d6e2
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:47:13 -0000

--089e011779b595688804ebb6d6e2
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 21, 2013 at 1:33 PM,  wrote:

>  Would the implement any two of {VP8, H.264 CBP, H.261} option solve your
> problem?
>

Well, for my specific problem, essentially anything that mandates
either VP8 or H.264 or both or the user's choice would. H.261
doesn't bring anything to the party. I'm trying to figure out who it
does benefit and coming up a bit short.

-Ekr

 +1 for Ron's reasoning.
>
>  Markus
>
> Sent from my iPad
>
> On Nov 21, 2013, at 23:15, "ext Eric Rescorla"  wrote:
>
>   Agreed.
>
>  To take a not-so-random example, given that Firefox will soon
> support both H.264 and VP8, what additional implementations
> will it be able to talk to if it does H.261?
>
>  -Ekr
>
>
>
>
> On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson  > wrote:
>
>> On 21 November 2013 12:48, Basil Mohamed Gohar
>>  wrote:
>> > Has anyone actually objected to H.261 being the one MTI codec [...] ?
>>
>> More than one person has already.
>>
>> And I find the argument raised quite compelling.  It's hard to justify
>> spending valuable time and resources on implementing something that
>> crappy.
>>  _______________________________________________
>> 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
>
>

--089e011779b595688804ebb6d6e2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    On T=
hu, Nov 21, 2013 at 1:33 PM,  <Markus.Isomaki@nokia.com> wrote:
    


    




    

    Would the implement any two of {VP8, H.264 CBP, H.261} option solve yo=
ur problem?

    Well, for my specif=
ic problem, essentially anything that mandates
    either VP8 or H.26=
4 or both or the user's choice would. H.261
    


    doesn't bring anything to the party. I'm trying to figure out =
who it
    does benefit and coming up a bit short.

    -Ekr

    


    

    +1 for Ron's reasoning.
    


    

    

    Markus
    

    
Sent from my iPad
    


    
On Nov 21, 2013, at 23:15, "ext Eric Rescorla" <ekr@rtfm.com> wrote:
    

    

    

    

    

    Agreed.


    

    

    To take a not-so-random example, given that Firefox will soon
    

    support both H.264 and VP8, what additional implementations
    

    will it be able to talk to if it does H.261?
    


    

    

    -Ekr
    


    

    


    

    


    

    

    On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson=
 
<martin.th=
omson@gmail.com> wrote:
    

    
On 21 November 2013 12:48, Basil Mohamed Gohar
    
<basilgoh=
ar@librevideo.org> wrote:
    
> Has anyone actually objected to H.261 being the one MTI codec [...] ?<=
br>

    
More than one person has already.
    

    
And I find the argument raised quite compelling. =A0It's hard to justif=
y
    
spending valuable time and resources on implementing something that
    
crappy.
    

    

    _______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb
    

    

    

    

    

    

    

    

    

    

    

    _______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org<=
/a>
    
    https://www.ietf.org/mailman/listinfo/rtcweb
    

    

    

    



    

--089e011779b595688804ebb6d6e2--

From lgeyser@gmail.com  Thu Nov 21 13:47:49 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DD81AE39C for ; Thu, 21 Nov 2013 13:47:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T831UNdl6QOB for ; Thu, 21 Nov 2013 13:47:47 -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 599561AE37E for ; Thu, 21 Nov 2013 13:47:47 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id c11so296871lbj.5 for ; Thu, 21 Nov 2013 13:47:39 -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=DUk0fk79jB8w3Xwxe2omO6eU+xa8iX+Z856YrY5AtMk=; b=dttj9mt+/qEI14y+Jc+lqygVH6cD07yMju6D2TVhXJES0kfBLVPk3oldai+ZI5+qDD 4FlNhU14g28XdfH4cnKo3AhXw4tpbcT+Lz/YoOyA2vgzIj38SWTLKhaX63uzOMzYnALV hNyoq54Dk+9FlA71ClN51cZI895Pj2cfe4OBsgkW3NDoGtvNA4MFm4UUkCpSDbv4iAED XgWurI0CDwad4lgPYEmU3RnZhH8Uo2Mr2UxLqnMxR2IgX+xEIu3HwnKVkbDEgMWbVOze ey4N1r4dBe4qK0N22czivJy+cZ1dvNyEItiuTPO1CV2Qoa3GqNY+VqPwYjrv3M8tW47B yy3A==
MIME-Version: 1.0
X-Received: by 10.152.4.230 with SMTP id n6mr6540667lan.1.1385070459784; Thu, 21 Nov 2013 13:47:39 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 21 Nov 2013 13:47:39 -0800 (PST)
In-Reply-To: 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>   <528E7C26.3000100@googlemail.com> 
Date: Thu, 21 Nov 2013 23:47:39 +0200
Message-ID: 
From: Leon Geyser 
To: Eric Rescorla 
Content-Type: multipart/alternative; boundary=089e013d1e8ebe941304ebb6d893
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:47:50 -0000

--089e013d1e8ebe941304ebb6d893
Content-Type: text/plain; charset=ISO-8859-1

>>I don't recall anyone saying that it was, and that's missing the point.
>>Rather, given that H.261 is really lame and that most everyone is
>>going to deploy *either* VP8 or H.264, I'm trying to figure out why
>>mandating H.261 is useful

No interoperability if nothing is between the two clients to transcode the
video. *either* doesn't always mean both H.264 and VP8. So H.261 will be
useful if transcoding can't be done.


On 21 November 2013 23:40, Eric Rescorla  wrote:

> On Thu, Nov 21, 2013 at 1:33 PM, Maik Merten wrote:
>
>> My understanding is that WebRTC is not a browser-only thing.
>
>
> I don't recall anyone saying that it was, and that's missing the point.
> Rather, given that H.261 is really lame and that most everyone is
> going to deploy *either* VP8 or H.264, I'm trying to figure out why
> mandating H.261 is useful
>
>
>  Also: Just because Mozilla may have found a way to sidestep the H.264
>> licensing issues with the help of Cisco, this doesn't mean this "fix"
>> applies everywhere. For example, is the blob acceptable for Iceweasel? And
>> what do the limited distribution rights of OpenH264 mean regarding system
>> administration (e.g., replicating machines with disk images)?
>>
>
> These may be relevant questions in some other thread, but not here.
>
> However, with that said, Cisco's blob should be usable for IceWeasel.
> Whether the IceWeasel people opt to use it is of course up to them.
> WRT the second question, 100k images is a lot of images.
>
> -Ekr
>
> Maik
>>
>> Am 21.11.2013 22:14, schrieb Eric Rescorla:
>>
>>> Agreed.
>>>
>>> To take a not-so-random example, given that Firefox will soon
>>> support both H.264 and VP8, what additional implementations
>>> will it be able to talk to if it does H.261?
>>>
>>> -Ekr
>>>
>>>
>>>
>>>
>>> On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson
>>> > wrote:
>>>
>>>     On 21 November 2013 12:48, Basil Mohamed Gohar
>>>     >
>>> wrote:
>>>      > Has anyone actually objected to H.261 being the one MTI codec
>>> [...] ?
>>>
>>>     More than one person has already.
>>>
>>>     And I find the argument raised quite compelling.  It's hard to
>>> justify
>>>     spending valuable time and resources on implementing something that
>>>     crappy.
>>>     _______________________________________________
>>>     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
>
>

--089e013d1e8ebe941304ebb6d893
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    >>I don't recall anyone saying that it was,=
 and that's missing the point.
    


    >>Rather, given that H.261 is really lame and that most everyone=
 is
    >>going to deploy *either* VP8 or H.264, I'm trying=
 to figure out why
    >>mandating H.261 is useful

    
No interoperability if nothing is between the two clients to transcode the =
video. *either* doesn't always mean both H.264 and VP8. So H.261 will b=
e useful if transcoding can't be done.
    


    On 21 November 2013 23:40, Eric Rescorla=
 <ek=
r@rtfm.com> wrote:
    

    On Thu, Nov 21, 2013 at 1:33 PM, Maik Merten <maikme=
rten@googlemail.com> wrote:
    




    My understanding is that =
WebRTC is not a browser-only thing.

    
I don't recall anyone saying that it was, and that's missing the po=
int.
    


    Rather, given that H.261 is really lame and that most everyone is
    going to deploy *either* VP8 or H.264, I'm trying to figure out w=
hy
    mandating H.261 is useful

    


    


     Also: Just because Mozil=
la may have found a way to sidestep the H.264 licensing issues with the hel=
p of Cisco, this doesn't mean this "fix" applies everywhere. =
For example, is the blob acceptable for Iceweasel? And what do the limited =
distribution rights of OpenH264 mean regarding system administration (e.g.,=
 replicating machines with disk images)?
    




    These may be relevant questions in s=
ome other thread, but not here.

    However, with that=
 said, Cisco's blob should be usable for IceWeasel.
    Whether t=
he IceWeasel people opt to use it is of course up to them.
    



    WRT the second question, 100k images is a lot of images.
    -Ekr

    

Maik
    

    
Am 21.11.2013 22:14, schrieb Eric Rescorla:
    

    
Agreed.
    

    
To take a not-so-random example, given that Firefox will soon
    
support both H.264 and VP8, what additional implementations
    
will it be able to talk to if it does H.261?
    

    
-Ekr
    

    

    

    

    
On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson
    
<martin.th=
omson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
    

    
=A0 =A0 On 21 November 2013 12:48, Basil Mohamed Gohar
    
=A0 =A0 <=
basilgohar@librevideo.org <mailto:basilgohar@librevideo.org>> w=
rote:
    




=A0 =A0 =A0> Has anyone actually objected to H.261 being the one MTI cod=
ec [...] ?
    

    
=A0 =A0 More than one person has already.
    

    
=A0 =A0 And I find the argument raised quite compelling. =A0It's hard t=
o justify
    
=A0 =A0 spending valuable time and resources on implementing something that=

    
=A0 =A0 crappy.
    
=A0 =A0 _______________________________________________
    
=A0 =A0 rtcweb mailing list
    
=A0 =A0 rtcweb@ietf.or=
g <mailto:rtcwe=
b@ietf.org>
    
=A0 =A0 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
    


    

--089e013d1e8ebe941304ebb6d893--

From basilgohar@librevideo.org  Thu Nov 21 13:54:15 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4ED31AE1F5 for ; Thu, 21 Nov 2013 13:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INlix65v4JZg for ; Thu, 21 Nov 2013 13:54:13 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 859FF1AE1D6 for ; Thu, 21 Nov 2013 13:54:13 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 732AD659871 for ; Thu, 21 Nov 2013 16:54:06 -0500 (EST)
Message-ID: <528E80FB.4080802@librevideo.org>
Date: Thu, 21 Nov 2013 16:54:03 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:54:16 -0000

On 11/21/2013 04:14 PM, Eric Rescorla wrote:
> Agreed.
> 
> To take a not-so-random example, given that Firefox will soon
> support both H.264 and VP8, what additional implementations
> will it be able to talk to if it does H.261?
> 
> -Ekr

(I apparently replied only to Ekr, and not the whole list originally)

None, but that's not the point.  Firefox is a special case for which VP8
is not considered a legal liability (by Mozilla) and they can be
satisfied, for the most part, by Cisco's proposal with OpenH264 as a
downloadable plugin/module.

So, this doesn't open up anything for Firefox that it is not already
planning to handle.

What it does open up is for, say, a small firm that cannot afford H.264
licensing, and cannot make use of Cisco's binary plugin for legal or
technical reasons, and can only implement VP8 and H.261, and, say, a
device whose manufacturers do not wish to implement VP8 for perceived
IPR risk but already license H.264.

Both cases above have an H.261 implementation that will allow mutual
video, even though they do not share a common high-end codec implementation.

There are cases outside of browsers that are interested in rtcweb, after
all.


-- 
Libre Video
http://librevideo.org

From basilgohar@librevideo.org  Thu Nov 21 13:55:25 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBA21AE397 for ; Thu, 21 Nov 2013 13:55:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9-WOkMuVRj1 for ; Thu, 21 Nov 2013 13:55:23 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id A48071AE388 for ; Thu, 21 Nov 2013 13:55:23 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id BD4476597BE for ; Thu, 21 Nov 2013 16:55:16 -0500 (EST)
Message-ID: <528E8142.1050309@librevideo.org>
Date: Thu, 21 Nov 2013 16:55:14 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:55:25 -0000

On 11/21/2013 03:52 PM, Martin Thomson wrote:
> On 21 November 2013 12:48, Basil Mohamed Gohar
>  wrote:
>> Has anyone actually objected to H.261 being the one MTI codec [...] ?
> 
> More than one person has already.
> 
> And I find the argument raised quite compelling.  It's hard to justify
> spending valuable time and resources on implementing something that
> crappy.
> 

(another case of replying to the person and not the list)

It's no more crappy than having G.711 as a fallback audio codec for
legacy purposes, which we've already done for rtcweb audio.  I realize
that it's not the same thing, but no other alternative codec has been
presented that satisfies the blocking issues for choosing either VP8 or
H.264 as MTI, namely, the IPR- or possibly-IPR-related issues.

-- 
Libre Video
http://librevideo.org

From martin.thomson@gmail.com  Thu Nov 21 13:58:49 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25A91AE2DA for ; Thu, 21 Nov 2013 13:58:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Gz1Gke1fBLw for ; Thu, 21 Nov 2013 13:58:48 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 50DCA1AE1F5 for ; Thu, 21 Nov 2013 13:58:48 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id q58so378747wes.30 for ; Thu, 21 Nov 2013 13:58:41 -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=3YRcrqCWBflpTuTwACf+1HOWALnoyh7JRf9go+o7QMs=; b=q19KAbIzpJlzcJ+QcA1jbpvlQnCsMlHRkIg5QmpT90aGSUyzmsJ0IJoysnP/MxuP3q toWjsVagAOyLcumuwDOV3D5fjPzgwcAHXmH3WrHYUP2BsCzE6BRvvtXIWIZeyGVVKikm hKrsQRSwDSG1SK1mSs2KzROHaQTDX7Pumyc2BbR/SE6VvOF0J4JRqJiNQhcwE/77b8wm IAjOEhQRd+tSoVpCNbHuGCVDddZ/pZdZ/MFo9Xnuml43e72EKJa8FZZGE5UryypNHAnl we0pN02NYmitP4X/f7DAcRvYcbjS0mdP/BkaWDFzzdKOvMPSjEhVk46bhg4KQ2vnM1p6 YOOg==
MIME-Version: 1.0
X-Received: by 10.194.178.166 with SMTP id cz6mr3499285wjc.53.1385071120947; Thu, 21 Nov 2013 13:58:40 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Thu, 21 Nov 2013 13:58:40 -0800 (PST)
In-Reply-To: <528E8142.1050309@librevideo.org>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>  <528E8142.1050309@librevideo.org>
Date: Thu, 21 Nov 2013 13:58:40 -0800
Message-ID: 
From: Martin Thomson 
To: Basil Mohamed Gohar 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:58:50 -0000

On 21 November 2013 13:55, Basil Mohamed Gohar
 wrote:
> It's no more crappy than having G.711 as a fallback audio codec for
> legacy purposes,

Actually, it is.  G.711 is close to free to implement.  And, despite
it actually being crappy, there's still a lot of it around.

From ekr@rtfm.com  Thu Nov 21 13:59:49 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C670D1AE2DA for ; Thu, 21 Nov 2013 13:59:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXUuadMePY3R for ; Thu, 21 Nov 2013 13:59:48 -0800 (PST)
Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id B59BC1AE058 for ; Thu, 21 Nov 2013 13:59:47 -0800 (PST)
Received: by mail-we0-f180.google.com with SMTP id u56so367362wes.39 for ; Thu, 21 Nov 2013 13:59:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1d+BXgpx3GSEwBR3mhDc02jgCJEtNBobZ7tFccibIoE=; b=mmwqu1Kr9+xxEOj1DELBGXzt43PnfT/BG8i45mD4rVkixYMIfBG4ZVqq5nn/Y7EHx+ VD0ieOkrFUV4KrzEvBXKneaHrfvEWVfuGvxh98dblYLe+qN7pac81Q13UmRg6Jse3y11 cIaUzrmESa4aGb/46EqlSea203W9afqY+p/kffI+fDq5IsCccj30TAbJQumDyr+l4NJY 5VPx+O6ehvaYvw5o7eR1SQsxwTxiOLnH7YSHH0OXkrljrKOsy3hNFBjt5HAf+7+b9LIl sK8RnKW8r9tpPOQwvxkEHlJ3LLqzQNK4dlbVsbTziHhOyYsGV7JdBNudVQZUNIk//O1U 81fg==
X-Gm-Message-State: ALoCoQkYrBEB7H2JVxoqM8GeCa1vwndegnleYLnnbz2mMHEYnWWXi7wdAPVBc3Wei6WnDPTYXhK0
X-Received: by 10.180.12.179 with SMTP id z19mr31725784wib.24.1385071180020; Thu, 21 Nov 2013 13:59:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 21 Nov 2013 13:58:59 -0800 (PST)
X-Originating-IP: [2620:101:8003:300:481b:90de:7d1a:71eb]
In-Reply-To: <528E8142.1050309@librevideo.org>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>  <528E8142.1050309@librevideo.org>
From: Eric Rescorla 
Date: Thu, 21 Nov 2013 13:58:59 -0800
Message-ID: 
To: Basil Mohamed Gohar 
Content-Type: multipart/alternative; boundary=001a11c3533aacafb504ebb70338
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 21:59:50 -0000

--001a11c3533aacafb504ebb70338
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 21, 2013 at 1:55 PM, Basil Mohamed Gohar <
basilgohar@librevideo.org> wrote:

> On 11/21/2013 03:52 PM, Martin Thomson wrote:
> > On 21 November 2013 12:48, Basil Mohamed Gohar
> >  wrote:
> >> Has anyone actually objected to H.261 being the one MTI codec [...] ?
> >
> > More than one person has already.
> >
> > And I find the argument raised quite compelling.  It's hard to justify
> > spending valuable time and resources on implementing something that
> > crappy.
> >
>
> (another case of replying to the person and not the list)
>
> It's no more crappy than having G.711 as a fallback audio codec for
> legacy purposes, which we've already done for rtcweb audio.


And there was really significant debate about that. The argument that
ultimately carried the day was that

(a) G.711 was trivial
(b) There were major interop advantages for the PSTN.

Neither of these two considerations applies here.

-Ekr


>  I realize
> that it's not the same thing, but no other alternative codec has been
> presented that satisfies the blocking issues for choosing either VP8 or
> H.264 as MTI, namely, the IPR- or possibly-IPR-related issues.
>
> --
> Libre Video
> http://librevideo.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--001a11c3533aacafb504ebb70338
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





    On Thu, Nov 21, 2013 at 1:55 PM, Basil Mohamed Gohar <basi=
lgohar@librevideo.org> wrote:
    


    On 11/21/2013 03:52 PM, Ma=
rtin Thomson wrote:
    
> On 21 November 2013 12:48, Basil Mohamed Gohar
    
> <basilgohar@librevideo=
.org> wrote:
    
>> Has anyone actually objected to H.261 being the one MTI codec [...=
] ?
    
>
    
> More than one person has already.
    
>
    
> And I find the argument raised quite compelling. =A0It's hard to j=
ustify
    
> spending valuable time and resources on implementing something that
> crappy.
    
>
    

    

    (another case of replying to the person and not the list)
    

    
It's no more crappy than having G.711 as a fallback audio codec for
    
legacy purposes, which we've already done for rtcweb audio. 

    And there was really significant debate about that. T=
he argument that
    ultimately carried the day was that
    


    (a) G.711 was trivial
    (b) There were major interop=
 advantages for the PSTN.

    Neither of these two con=
siderations applies here.

    -Ekr
    =A0
    


    =A0I realize
    
that it's not the same thing, but no other alternative codec has been
presented that satisfies the blocking issues for choosing either VP8 or
    
H.264 as MTI, namely, the IPR- or possibly-IPR-related issues.
    


    
--
    
Libre Video
    
http://librevideo.org
    

    _____________________________=
__________________
    
rtcweb mailing list
    
    rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--001a11c3533aacafb504ebb70338--

From ekr@rtfm.com  Thu Nov 21 14:00:30 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D491AE2DA for ; Thu, 21 Nov 2013 14:00:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePedT9VkmoDi for ; Thu, 21 Nov 2013 14:00:28 -0800 (PST)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2171AE38B for ; Thu, 21 Nov 2013 14:00:28 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id y10so366550wgg.21 for ; Thu, 21 Nov 2013 14:00:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Mf8KFjld4RE8W2e4UcGGvetLh86P2m9FQBApi8nGDHI=; b=RaFCv4J2aBy6I7KMO75qZKeKNj+f+6GmWn9VAZOAoFDakM/a8kYtD8y72b4L6Au2By gnZ5mno5K7XofaqOGg1p9VkWgGjL+tPUJr3Vzggir4K5XDFeZsxJK1tEmw3kTIaCAH13 09gbvGG+qnYrD4cWQtB6Cdib5n/bTh/4uyErehO5FJPCuJrxJWs2/SqdDPAuuYh/hRV0 Of+R3+nzdhSWAYV/GmfvqPopEXMFd36zdvPYJjQB9hn6F/DJohae+DG5ZwfCpnk9n9O0 gOebyvMXltJn7LMirqtLmLpWPl+g4Mggk69xOiI6mz0gOwrs1gAOGp/rS60PhxZe+g73 rv1g==
X-Gm-Message-State: ALoCoQnR1jN2gqaiaFDvdCvYnMr0ceefw238hq3QL0FAz+bWGHIf2K+NqXZOxUeM2S+CKVXn30oA
X-Received: by 10.194.20.65 with SMTP id l1mr7480008wje.4.1385071220965; Thu, 21 Nov 2013 14:00:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 21 Nov 2013 13:59:40 -0800 (PST)
X-Originating-IP: [2620:101:8003:300:481b:90de:7d1a:71eb]
In-Reply-To: <528E80FB.4080802@librevideo.org>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>   <528E80FB.4080802@librevideo.org>
From: Eric Rescorla 
Date: Thu, 21 Nov 2013 13:59:40 -0800
Message-ID: 
To: Basil Mohamed Gohar 
Content-Type: multipart/alternative; boundary=047d7b4512a21d7d6004ebb70625
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:00:30 -0000

--047d7b4512a21d7d6004ebb70625
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 21, 2013 at 1:54 PM, Basil Mohamed Gohar <
basilgohar@librevideo.org> wrote:

> On 11/21/2013 04:14 PM, Eric Rescorla wrote:
> > Agreed.
> >
> > To take a not-so-random example, given that Firefox will soon
> > support both H.264 and VP8, what additional implementations
> > will it be able to talk to if it does H.261?
> >
> > -Ekr
>
> (I apparently replied only to Ekr, and not the whole list originally)
>
> None, but that's not the point.  Firefox is a special case for which VP8
> is not considered a legal liability (by Mozilla) and they can be
> satisfied, for the most part, by Cisco's proposal with OpenH264 as a
> downloadable plugin/module.
>
> So, this doesn't open up anything for Firefox that it is not already
> planning to handle.
>
> What it does open up is for, say, a small firm that cannot afford H.264
> licensing, and cannot make use of Cisco's binary plugin for legal or
> technical reasons, and can only implement VP8 and H.261, and, say, a
> device whose manufacturers do not wish to implement VP8 for perceived
> IPR risk but already license H.264.
>
> Both cases above have an H.261 implementation that will allow mutual
> video, even though they do not share a common high-end codec
> implementation.
>
> There are cases outside of browsers that are interested in rtcweb, after
> all.


Which of those cases are going to want to not talk to browsers?

Which browsers want to do H.261?

-Ekr


>  --
> Libre Video
> http://librevideo.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--047d7b4512a21d7d6004ebb70625
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





    On Thu, Nov 21, 2013 at 1:54 PM, Basil Mohamed Gohar <basi=
lgohar@librevideo.org> wrote:
    


    On 11/21/2013 04:14 PM, Er=
ic Rescorla wrote:
    
> Agreed.
    
>
    
> To take a not-so-random example, given that Firefox will soon
    
> support both H.264 and VP8, what additional implementations
    
> will it be able to talk to if it does H.261?
    
>
    
> -Ekr
    

    

    (I apparently replied only to Ekr, and not the whole list originally)=

    

    
None, but that's not the point. =A0Firefox is a special case for which =
VP8
    
is not considered a legal liability (by Mozilla) and they can be
    
satisfied, for the most part, by Cisco's proposal with OpenH264 as a
downloadable plugin/module.
    

    
So, this doesn't open up anything for Firefox that it is not already
planning to handle.
    

    
What it does open up is for, say, a small firm that cannot afford H.264
    
licensing, and cannot make use of Cisco's binary plugin for legal or
technical reasons, and can only implement VP8 and H.261, and, say, a
    
device whose manufacturers do not wish to implement VP8 for perceived
    
IPR risk but already license H.264.
    

    
Both cases above have an H.261 implementation that will allow mutual
    
video, even though they do not share a common high-end codec implementation=
.
    

    
There are cases outside of browsers that are interested in rtcweb, after
all.

    Which of those cases are going to want=
 to not talk to browsers?

    Which browsers want to d=
o H.261?

    -Ekr
    =A0
    


    
--
    
Libre Video
    
http://librevideo.org
    

    _____________________________=
__________________
    
rtcweb mailing list
    
    rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--047d7b4512a21d7d6004ebb70625--

From martin.thomson@gmail.com  Thu Nov 21 14:03:18 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE01F1AE395 for ; Thu, 21 Nov 2013 14:03:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmANcuLwNgx4 for ; Thu, 21 Nov 2013 14:03:17 -0800 (PST)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9151AE2DA for ; Thu, 21 Nov 2013 14:03:17 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id ez12so1786489wid.0 for ; Thu, 21 Nov 2013 14:03:10 -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=+a8J51scmcvVzcTeLzEQbXKfwbWTPj/cCbvove+tcgA=; b=uaJ3CE2uAp/uwtEgfoIxJ08ptgz0QE36D3hjK1OeURF51FU+H2FCP5Gkz4dNKJBm/z IVVs9DBa5b3mVLc9rMpI3lIoShK1xkMaZq+vNQD7+y5//m2+WZKqOPh5wNtMWhO5aHvo XHhV9xLn8gNwscf8kNh6obo1h7euq9igJfGlxtVQLVmZNn8fAtF9kVQUfPG884X82Bg3 1Jv+DLAyzm5EIR5GgwBjwK9R52IQjFrEgeAUcWxDF0jCRUwkmSiNhAxhA3Yb5U1XgbLL Ftv3tWcTmSJOzpEW2YOsBwwEJQElCTH8oC5mBV14cRY139s2elbx61lpmEVKQkPG+eGA /ShQ==
MIME-Version: 1.0
X-Received: by 10.180.20.102 with SMTP id m6mr7765833wie.22.1385071389998; Thu, 21 Nov 2013 14:03:09 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Thu, 21 Nov 2013 14:03:09 -0800 (PST)
In-Reply-To: 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>  <528E8142.1050309@librevideo.org> 
Date: Thu, 21 Nov 2013 14:03:09 -0800
Message-ID: 
From: Martin Thomson 
To: Basil Mohamed Gohar 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:03:19 -0000

On 21 November 2013 13:58, Martin Thomson  wrote:
> On 21 November 2013 13:55, Basil Mohamed Gohar
>  wrote:
>> It's no more crappy than having G.711 as a fallback audio codec for
>> legacy purposes,
>
> Actually, it is.  G.711 is close to free to implement.  And, despite
> it actually being crappy, there's still a lot of it around.


I forgot, if you want directly analogous, B&W RFC 4715 at QCIF might
be a good fit.

From creslin@digium.com  Thu Nov 21 14:04:17 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703D11AE395 for ; Thu, 21 Nov 2013 14:04:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8TIe6WFsbRC for ; Thu, 21 Nov 2013 14:04:15 -0800 (PST)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2242F1AE2DA for ; Thu, 21 Nov 2013 14:04:14 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id w7so304010lbi.29 for ; Thu, 21 Nov 2013 14:04:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xClQiA8AZ7i4w0nryfAbR4u8KTAh8DNcnVeOrxVHm/k=; b=ZYrq2BiQq0x4bX0UlYM5dzHoeeZBsxH7s/rRIzLI3xyfzHZ5V0uWumAHnS+x8YKsfU Ze/Q1vB9bsGMtm4ctlNPLD8NoDs7BWpd3CUmBkyZt8/V1IYUajlzB/r4Z1EtmgqZmLAs YB/8KIseyiT3l6hysas4aeL5YV5pM3QvmSUL8SHlw6dgAIqi/bHou8EVtyAS1h+Lyyfc oDrdrtMSOYLsUHidmtKfgVQ/FioF+1qlD3yPmOf75VfFWocHhZYAphJFI408xVFf6Pmh 7KNVpUgFis2nshPn6mVDqhePEv49t9xca6kBIozAIYarwQfa1U1y1lGsVRdRou9bG9f+ AQfg==
X-Gm-Message-State: ALoCoQkvUzr03rh63k/oLp3/ZyOUY5KawAmU82BSWjhxRmdX9/x08Z8rR+3yIDHfocQXShJwhlhc
MIME-Version: 1.0
X-Received: by 10.152.140.193 with SMTP id ri1mr6707277lab.18.1385071447602; Thu, 21 Nov 2013 14:04:07 -0800 (PST)
Received: by 10.112.132.102 with HTTP; Thu, 21 Nov 2013 14:04:07 -0800 (PST)
In-Reply-To: <2CA8952C-9AD0-49F0-A8E9-160099D09DC9@nokia.com>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>   <2CA8952C-9AD0-49F0-A8E9-160099D09DC9@nokia.com>
Date: Thu, 21 Nov 2013 16:04:07 -0600
Message-ID: 
From: Matt Fredrickson 
To: Markus.Isomaki@nokia.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:04:17 -0000

I also agree with Ron's suggestion....

Implement 2 of 3 seems to be the best way to absolutely preserve interop.

Matthew Fredrickson

On Thu, Nov 21, 2013 at 3:33 PM,   wrote:
> Would the implement any two of {VP8, H.264 CBP, H.261} option solve your
> problem?
>
> +1 for Ron's reasoning.
>
> Markus
>
> Sent from my iPad
>
> On Nov 21, 2013, at 23:15, "ext Eric Rescorla"  wrote:
>
> Agreed.
>
> To take a not-so-random example, given that Firefox will soon
> support both H.264 and VP8, what additional implementations
> will it be able to talk to if it does H.261?
>
> -Ekr
>
>
>
>
> On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson 
> wrote:
>>
>> On 21 November 2013 12:48, Basil Mohamed Gohar
>>  wrote:
>> > Has anyone actually objected to H.261 being the one MTI codec [...] ?
>>
>> More than one person has already.
>>
>> And I find the argument raised quite compelling.  It's hard to justify
>> spending valuable time and resources on implementing something that
>> crappy.
>> _______________________________________________
>> 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
>

From martin.thomson@gmail.com  Thu Nov 21 14:06:09 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50C61AE3B5 for ; Thu, 21 Nov 2013 14:06:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24NxP6Ahe1IQ for ; Thu, 21 Nov 2013 14:06:08 -0800 (PST)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 224431AE3B3 for ; Thu, 21 Nov 2013 14:06:07 -0800 (PST)
Received: by mail-wg0-f47.google.com with SMTP id y10so379135wgg.2 for ; Thu, 21 Nov 2013 14:06:00 -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=uSwmNB8Jcst5Ikk8WAFIZIXNZiDEAZlVvvHbgWUncWs=; b=wf+YXFxQ6ovA91qlgy4RoqVz7DcH0dtBxKKpoRQnQlI6u3Z9XI0ZbHRp3pgcJKDfmu XDUaAoyZbHurxnobVRDR7RuPo8HpN4F/y9NeFXhpQcOT0c8uE/rjqHZdiAQQZH1d4c3L NpddWEEbgMgqHvHhLavIQZYF10sEWFY6k9v6NdWCuEnrtdBAmtWNo6O4oz7/95rAQJTW Gt4EY50j2jRXRdm2yzV5rzB9sJajWKE6sMvcZtd1qPBXRpLlYr3NTHB2DkRgHFkY+sC5 93oJqOr7T8VfBL+nyrQxYFTs5vzgz89vLrlz1szp4Pao9BIR37dImhP/T6h8AiDcVzrQ rqJw==
MIME-Version: 1.0
X-Received: by 10.180.77.49 with SMTP id p17mr13368916wiw.30.1385071560878; Thu, 21 Nov 2013 14:06:00 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Thu, 21 Nov 2013 14:06:00 -0800 (PST)
In-Reply-To: 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>  <528E8142.1050309@librevideo.org>  
Date: Thu, 21 Nov 2013 14:06:00 -0800
Message-ID: 
From: Martin Thomson 
To: Basil Mohamed Gohar 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:06:10 -0000

On 21 November 2013 14:03, Martin Thomson  wrote:
> I forgot, if you want directly analogous, B&W RFC 4715 at QCIF might
> be a good fit.

Correction, B&W RFC 4175 QCIF =~ G.711.

From basilgohar@librevideo.org  Thu Nov 21 14:12:42 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74661AE2D8 for ; Thu, 21 Nov 2013 14:12:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KonRROSMDXnx for ; Thu, 21 Nov 2013 14:12:41 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id D75161AE2A8 for ; Thu, 21 Nov 2013 14:12:40 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id B4A9565989C for ; Thu, 21 Nov 2013 17:12:33 -0500 (EST)
Message-ID: <528E854F.4030201@librevideo.org>
Date: Thu, 21 Nov 2013 17:12:31 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>   <528E80FB.4080802@librevideo.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:12:43 -0000

On 11/21/2013 04:59 PM, Eric Rescorla wrote:
> 
> 
> 
> On Thu, Nov 21, 2013 at 1:54 PM, Basil Mohamed Gohar
> > wrote:
> 
>     On 11/21/2013 04:14 PM, Eric Rescorla wrote:
>     > Agreed.
>     >
>     > To take a not-so-random example, given that Firefox will soon
>     > support both H.264 and VP8, what additional implementations
>     > will it be able to talk to if it does H.261?
>     >
>     > -Ekr
> 
>     (I apparently replied only to Ekr, and not the whole list originally)
> 
>     None, but that's not the point.  Firefox is a special case for which VP8
>     is not considered a legal liability (by Mozilla) and they can be
>     satisfied, for the most part, by Cisco's proposal with OpenH264 as a
>     downloadable plugin/module.
> 
>     So, this doesn't open up anything for Firefox that it is not already
>     planning to handle.
> 
>     What it does open up is for, say, a small firm that cannot afford H.264
>     licensing, and cannot make use of Cisco's binary plugin for legal or
>     technical reasons, and can only implement VP8 and H.261, and, say, a
>     device whose manufacturers do not wish to implement VP8 for perceived
>     IPR risk but already license H.264.
> 
>     Both cases above have an H.261 implementation that will allow mutual
>     video, even though they do not share a common high-end codec
>     implementation.
> 
>     There are cases outside of browsers that are interested in rtcweb, after
>     all.
> 
> 
> Which of those cases are going to want to not talk to browsers?
> 
> Which browsers want to do H.261?
> 
> -Ekr

Of course, all of them want to talk to browsers.  But not all of them
will be guaranteed to implement BOTH VP8 or H.264 (nor are browsers, and
this is key).

So, I write myself a small little device that attaches to my camera that
implements RTCweb.  I cannot afford the license for H.264, and my
platform is not supported by OpenH264.  I do, however, write-up my own
basic VP8 implementation as well, because it is is royalty-free.  I also
implement H.261 for the same reason, it's royalty free.  I need things
to be royalty free because I plan to publish my designs under a CC
license and want others to also be able to make my device.

So, I can talk to browsers that support VP8 with VP8, and browsers that
do not support VP8, but because it's MTI, do support H.261, but with
degraded quality.  BUT I CAN STILL TALK (or SEE) them, as opposed to
being unable to if H.261 was not mandated.

This example, though perhaps somewhat contrived, is a case that would be
allowed if H.261 is permitted, and would be impossible if it were left
out, because there would be some rtcweb endpoints excluded from
interoperability.

-- 
Libre Video
http://librevideo.org

From fluffy@iii.ca  Thu Nov 21 14:13:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609A11AE0B3 for ; Thu, 21 Nov 2013 14:13:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.88
X-Spam-Level: 
X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LAW0ytpLTmJ for ; Thu, 21 Nov 2013 14:13:34 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 854CB1AE04F for ; Thu, 21 Nov 2013 14:13:34 -0800 (PST)
Received: from sjc-vpn2-1025.cisco.com (unknown [128.107.239.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9599350A73 for ; Thu, 21 Nov 2013 17:13:27 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: 
Date: Thu, 21 Nov 2013 14:14:03 -0800
Cc: rtcweb@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3249225E-6709-4022-88CF-75020C1A4CEC@iii.ca>
References: <528E69E2.9020208@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA8AD7E0@ausmsex00.austin.kmvtechnologies.com> 
X-Mailer: Apple Mail (2.1510)
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:13:35 -0000

On Nov 21, 2013, at 12:36 PM, Justin Uberti  wrote:

> That said, I think the general understanding here is that this is no =
longer a technical decision.
>=20

I'll note that some people strongly disagree with this is not a =
technical decision but there are others who do think it is is no longer =
a technical decision.=20


From sslivinski@lifesize.com  Thu Nov 21 14:20:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF3E1AE151 for ; Thu, 21 Nov 2013 14:20:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzQLwxcF0sMD for ; Thu, 21 Nov 2013 14:20:32 -0800 (PST)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id 0E3DA1AE06D for ; Thu, 21 Nov 2013 14:20:31 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUo6HJa3lA1uG8pQsYlXjrBGst8bR1jjz@postini.com; Thu, 21 Nov 2013 14:20:25 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 16:13:04 -0600
From: Stefan Slivinski 
To: "'creslin@digium.com'" , "'Markus.Isomaki@nokia.com'" 
Date: Thu, 21 Nov 2013 16:13:04 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7nBZ2DtZ6r5EQkSgW8jOxOEZwhKAAATuia
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7E5@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "'rtcweb@ietf.org'" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:20:35 -0000

But how does this avoid IPR issues?=20


----- Original Message -----
From: Matt Fredrickson [mailto:creslin@digium.com]
Sent: Thursday, November 21, 2013 04:04 PM=0A=
To: Markus.Isomaki@nokia.com 
Cc: rtcweb@ietf.org 
Subject: Re: [rtcweb] Proposed Video Selection Process

I also agree with Ron's suggestion....

Implement 2 of 3 seems to be the best way to absolutely preserve interop.

Matthew Fredrickson

On Thu, Nov 21, 2013 at 3:33 PM,   wrote:
> Would the implement any two of {VP8, H.264 CBP, H.261} option solve your
> problem?
>
> +1 for Ron's reasoning.
>
> Markus
>
> Sent from my iPad
>
> On Nov 21, 2013, at 23:15, "ext Eric Rescorla"  wrote:
>
> Agreed.
>
> To take a not-so-random example, given that Firefox will soon
> support both H.264 and VP8, what additional implementations
> will it be able to talk to if it does H.261?
>
> -Ekr
>
>
>
>
> On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson 
> wrote:
>>
>> On 21 November 2013 12:48, Basil Mohamed Gohar
>>  wrote:
>> > Has anyone actually objected to H.261 being the one MTI codec [...] ?
>>
>> More than one person has already.
>>
>> And I find the argument raised quite compelling.  It's hard to justify
>> spending valuable time and resources on implementing something that
>> crappy.
>> _______________________________________________
>> 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

From martin.thomson@gmail.com  Thu Nov 21 14:22:29 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8CE1AE06D for ; Thu, 21 Nov 2013 14:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPZopIkD0o_v for ; Thu, 21 Nov 2013 14:22:28 -0800 (PST)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id EDE2B1AE04F for ; Thu, 21 Nov 2013 14:22:27 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id m15so389129wgh.1 for ; Thu, 21 Nov 2013 14:22:20 -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=tn5qf+PXMGzbxwCVdrrJ0udBFp6rRmGemx5u+l/w+ZA=; b=JVGzWmtxvO0So5bG/iMJ0SXPSPI8idtz9KUdgI5KwGQT2iR2RtaszXGqQWTHqHq/M5 b40+dSW11K3K3fhxcL2h3hU2bmnLDRLjqM3pyCFdflQgpFpqJ/DpjENpVKpNP8gSYV5J qTM3t+F4MVC6P1gdpbZUrrFJ3Vz4chREaHqop3wzlww6uH+Z11ycr18am7z2BfHCa/kl u/aVyckcSaRXzTqIPe1bTSrUYCxlfa9upwbuZ5gse/6A0uqjoSAroQIxYe8JqDMNzg0t VnYZALScW70pf+R0flR9y40cHN2kvAhc1WMFXyBh5EKMab+ZkxVhHPFGNIHLUhGhQQp3 mjmQ==
MIME-Version: 1.0
X-Received: by 10.180.86.102 with SMTP id o6mr7860503wiz.30.1385072540601; Thu, 21 Nov 2013 14:22:20 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Thu, 21 Nov 2013 14:22:20 -0800 (PST)
In-Reply-To: <3249225E-6709-4022-88CF-75020C1A4CEC@iii.ca>
References: <528E69E2.9020208@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA8AD7E0@ausmsex00.austin.kmvtechnologies.com>  <3249225E-6709-4022-88CF-75020C1A4CEC@iii.ca>
Date: Thu, 21 Nov 2013 14:22:20 -0800
Message-ID: 
From: Martin Thomson 
To: Cullen Jennings 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:22:30 -0000

On 21 November 2013 14:14, Cullen Jennings  wrote:
> I'll note that some people strongly disagree with this is not a technical decision but there are others who do think it is is no longer a technical decision.

Is that a chair statement declaring lack of consensus on whether the
MTI video codec debate has a technical basis?

From basilgohar@librevideo.org  Thu Nov 21 14:26:04 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229D31AE04F for ; Thu, 21 Nov 2013 14:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wD6t7hybfRKT for ; Thu, 21 Nov 2013 14:26:01 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id CD9C71AE092 for ; Thu, 21 Nov 2013 14:26:01 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id BBE3E65989C for ; Thu, 21 Nov 2013 17:25:54 -0500 (EST)
Message-ID: <528E8870.20706@librevideo.org>
Date: Thu, 21 Nov 2013 17:25:52 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7E5@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA8AD7E5@ausmsex00.austin.kmvtechnologies.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:26:04 -0000

It is impossible to completely avoid IPR issues altogether to everyone's
satisfaction.  But there are two camps that have emerged, that is to
say, one that says H.264 IPR issues are a no go, and those that say the
same for VP8 (mostly in light of contentment with either MPEG-LA's
licensing terms or Cisco's plugin/module).

So, both camps' concerns can be addressed by allowing each camp to still
implement their own preferences, while H.261 is presented as an option
to allow interop between those that fall strictly into one of the two
above camps, with H.261 being asserted as confidently possibly to be
implemented, albeit perhaps in a basic form, without much IPR concern
from anyone.

On 11/21/2013 05:13 PM, Stefan Slivinski wrote:
> But how does this avoid IPR issues? 
> 
> 
> ----- Original Message -----
> From: Matt Fredrickson [mailto:creslin@digium.com]
> Sent: Thursday, November 21, 2013 04:04 PM
> To: Markus.Isomaki@nokia.com 
> Cc: rtcweb@ietf.org 
> Subject: Re: [rtcweb] Proposed Video Selection Process
> 
> I also agree with Ron's suggestion....
> 
> Implement 2 of 3 seems to be the best way to absolutely preserve interop.
> 
> Matthew Fredrickson
> 
> On Thu, Nov 21, 2013 at 3:33 PM,   wrote:
>> Would the implement any two of {VP8, H.264 CBP, H.261} option solve your
>> problem?
>>
>> +1 for Ron's reasoning.
>>
>> Markus
>>
>> Sent from my iPad
>>
>> On Nov 21, 2013, at 23:15, "ext Eric Rescorla"  wrote:
>>
>> Agreed.
>>
>> To take a not-so-random example, given that Firefox will soon
>> support both H.264 and VP8, what additional implementations
>> will it be able to talk to if it does H.261?
>>
>> -Ekr
>>
>>
>>
>>
>> On Thu, Nov 21, 2013 at 12:52 PM, Martin Thomson 
>> wrote:
>>>
>>> On 21 November 2013 12:48, Basil Mohamed Gohar
>>>  wrote:
>>>> Has anyone actually objected to H.261 being the one MTI codec [...] ?
>>>
>>> More than one person has already.
>>>
>>> And I find the argument raised quite compelling.  It's hard to justify
>>> spending valuable time and resources on implementing something that
>>> crappy.
>>> _______________________________________________
>>> 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 


-- 
Libre Video
http://librevideo.org

From fluffy@iii.ca  Thu Nov 21 14:28:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C54C1AE1D8 for ; Thu, 21 Nov 2013 14:28:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZ9zf3eyVY_r for ; Thu, 21 Nov 2013 14:28:53 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id DF8AE1AE199 for ; Thu, 21 Nov 2013 14:28:52 -0800 (PST)
Received: from sjc-vpn2-1025.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C2B9922E25C; Thu, 21 Nov 2013 17:28:39 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: 
Date: Thu, 21 Nov 2013 14:29:16 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <528E69E2.9020208@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA8AD7E0@ausmsex00.austin.kmvtechnologies.com>  <3249225E-6709-4022-88CF-75020C1A4CEC@iii.ca> 
To: Martin Thomson 
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:28:54 -0000

On Nov 21, 2013, at 2:22 PM, Martin Thomson  =
wrote:

> On 21 November 2013 14:14, Cullen Jennings  wrote:
>> I'll note that some people strongly disagree with this is not a =
technical decision but there are others who do think it is is no longer =
a technical decision.
>=20
> Is that a chair statement declaring lack of consensus on whether the
> MTI video codec debate has a technical basis?

Sure I will upgrade that to be one of the chairs saying that some people =
think the decisions involves technical issues and some people do not. It =
is not a statement from the chair if the debate is technical or not - =
just a statement that people disagree on this.=20

Cullen 



From juberti@google.com  Thu Nov 21 14:32:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD451AE199 for ; Thu, 21 Nov 2013 14:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2OSH_sDZn1G for ; Thu, 21 Nov 2013 14:32:27 -0800 (PST)
Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id C38201AE04F for ; Thu, 21 Nov 2013 14:32:26 -0800 (PST)
Received: by mail-ve0-f180.google.com with SMTP id jz11so333734veb.11 for ; Thu, 21 Nov 2013 14:32:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Rj7D09FvkailcjEjq004uahvGN7vFhpWd+Y6nQFO0dA=; b=jRnVgWs4mAwB0s0E5Wq6zgAIfD0R/4cgM1yZvJZlxCgIvpBr85p2WEi71K5yv/qT1Z M3mvnu2r1DO4YOK78LyOca3UBAA9+j0JRsaxXnSkqtrcEWnKrXhKIaYXLT/M4arCV0fd zuOw4g+Ar3L5oufosp56l2CtoUeUpO+9aZpble8hMGGl4vnz5f0b9XqSl6gMdTHyp6LH 96lf5UP8JyF7QUmzN0Rh7cvp+LEzuIW0OurjIGneG3EF9tegEJUo6n7yGxL3M1OLSG72 ikgpb09NzhqWMY8LteWxNpBsUTTGmKWu8HVkEut7PFLxcJG/clSd6XtBauKDQujydqnE ZruQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Rj7D09FvkailcjEjq004uahvGN7vFhpWd+Y6nQFO0dA=; b=XWn8i9wvEG3DXN2WqIP4/hCJKx9tcASWgsVPx1DDh74RTVCUU1eJSvd4bZ1nUr56Ne HqX9zJ/+dDWT3cbact+OLvd5hPC+8IoTfe8sObwWWchFjy2DML7yLew3FwKm4PVGftwH /APrbWk6p2HbmtLStK1EeX/PqwdSCa4Vwq1BIwqjXP5fb+OMDxp7Up3APRk0c96jm+me jq/DxL7XAOs4RJFHL440Ba8Fno3pf/KUC0bkfbVq8ZiRor3m4pjmrV1zN9sH/NHTQOwA cgvI/xr4lt+0pXIvV7kMrQCJqiDG5eCj50EnqqFLcuL15b+3KhxXEjXZEevp1m90fAFU pO2Q==
X-Gm-Message-State: ALoCoQn8jjzkOgc4kI3CWIpLyOQ26QFumFgp57AGYcsyzWiknrYPu10Hq8lLVVYxIeaQ0ELIAAcHCMQDhUsH+bPbSy+UQC3tNEKvJm6C4uYcgoKAoXKJ8IyJmI9ybYRrbqS/X2Tt/gemBX0JILKq+45yB7See0Q3nfO0W+iV0hmpK7O4PmXzgbftRv52SHohBpUhaPm0DjZX
X-Received: by 10.52.28.243 with SMTP id e19mr269589vdh.36.1385073139567; Thu, 21 Nov 2013 14:32:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Thu, 21 Nov 2013 14:31:58 -0800 (PST)
In-Reply-To: <3249225E-6709-4022-88CF-75020C1A4CEC@iii.ca>
References: <528E69E2.9020208@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA8AD7E0@ausmsex00.austin.kmvtechnologies.com>  <3249225E-6709-4022-88CF-75020C1A4CEC@iii.ca>
From: Justin Uberti 
Date: Thu, 21 Nov 2013 14:31:58 -0800
Message-ID: 
To: Cullen Jennings 
Content-Type: multipart/alternative; boundary=20cf307d069278e9b604ebb778f1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:32:28 -0000

--20cf307d069278e9b604ebb778f1
Content-Type: text/plain; charset=UTF-8

Even the proposal that recommended H.264 as MTI indicated that the
technical merit of the currently proposed codecs is equivalent, and the
fundamental question is IPR.
http://tools.ietf.org/agenda/88/slides/slides-88-rtcweb-8.pdf

Put another way, if the alleged IPR issues associated with either H.264 or
VP8 disappeared overnight, this discussion would be instantly over.


On Thu, Nov 21, 2013 at 2:14 PM, Cullen Jennings  wrote:

>
> On Nov 21, 2013, at 12:36 PM, Justin Uberti  wrote:
>
> > That said, I think the general understanding here is that this is no
> longer a technical decision.
> >
>
> I'll note that some people strongly disagree with this is not a technical
> decision but there are others who do think it is is no longer a technical
> decision.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--20cf307d069278e9b604ebb778f1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Even the proposal that recommended H.264 as MTI indicated =
that the technical merit of the currently proposed codecs is equivalent, an=
d the fundamental question is IPR.

    Put another way, if the alleged IPR issues associ=
ated with either H.264 or VP8 disappeared overnight, this discussion would =
be instantly over.


    

On Thu, Nov 21, 2013 at 2:14 PM, Cullen Jennings <fluffy@iii.ca>=
 wrote:
    



    
On Nov 21, 2013, at 12:36 PM, Justin Uberti <juberti@google.com> wrote:
    

    
> That said, I think the general understanding here is that this is no l=
onger a technical decision.
    
>
    

    

    I'll note that some people strongly disagree with this is not a t=
echnical decision but there are others who do think it is is no longer a te=
chnical decision.
    


    
_______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--20cf307d069278e9b604ebb778f1--

From fluffy@iii.ca  Thu Nov 21 14:32:49 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5E91AE12F for ; Thu, 21 Nov 2013 14:32:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obRmSZPIjNAp for ; Thu, 21 Nov 2013 14:32:49 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id DCA021AE04F for ; Thu, 21 Nov 2013 14:32:48 -0800 (PST)
Received: from sjc-vpn2-1025.cisco.com (unknown [128.107.239.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 882CD50A84; Thu, 21 Nov 2013 17:32:39 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: 
Date: Thu, 21 Nov 2013 14:33:15 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>     
To: Matt Fredrickson 
X-Mailer: Apple Mail (2.1510)
Cc: rtcweb@ietf.org
Subject: [rtcweb] cisco binary on ec2
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:32:50 -0000

On Nov 21, 2013, at 12:21 PM, Matt Fredrickson  =
wrote:

>  I cannot use that on my dynamically
> deployed EC2 instances due to licensing restrictions. :-)


My understanding of the legal situation is that you can use the cisco =
binary on your EC2 instance and have Cisco pay the MPEG-LA fees.=20=

From fluffy@iii.ca  Thu Nov 21 14:38:11 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA0D1AE3B4 for ; Thu, 21 Nov 2013 14:38:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level: 
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GUARANTEED_100_PERCENT=2.699, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS2IcNruFVZ0 for ; Thu, 21 Nov 2013 14:38:10 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 573721AE3AC for ; Thu, 21 Nov 2013 14:37:43 -0800 (PST)
Received: from sjc-vpn2-1025.cisco.com (unknown [128.107.239.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4269350A84; Thu, 21 Nov 2013 17:37:36 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: 
Date: Thu, 21 Nov 2013 14:38:12 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <528E69E2.9020208@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA8AD7E0@ausmsex00.austin.kmvtechnologies.com>  <3249225E-6709-4022-88CF-75020C1A4CEC@iii.ca> 
To: Justin Uberti 
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:38:11 -0000

On Nov 21, 2013, at 2:31 PM, Justin Uberti  wrote:

> Put another way, if the alleged IPR issues associated with either =
H.264 or VP8 disappeared overnight, this discussion would be instantly =
over.

Justin, I don't think everyone agrees with you on this. If VP8 was =
magically 100% guaranteed to be free of all patents tomorrow, there =
would still be a large block of people arguing for H.264.  I'm not =
trying to say there is consensus on this topic, one way or the other, =
just that not everyone agrees with that.=20




From sslivinski@lifesize.com  Thu Nov 21 14:42:01 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8E71AE1A8 for ; Thu, 21 Nov 2013 14:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.7
X-Spam-Level: 
X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsKWQEP6BzG0 for ; Thu, 21 Nov 2013 14:41:59 -0800 (PST)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id 237111AE117 for ; Thu, 21 Nov 2013 14:41:59 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUo6MLxLNXUXdTtb45O4mLCtZIdjPCfTG@postini.com; Thu, 21 Nov 2013 14:41:52 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 16:37:52 -0600
From: Stefan Slivinski 
To: "'juberti@google.com'" , "'fluffy@iii.ca'" 
Date: Thu, 21 Nov 2013 16:37:51 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7nCY1UVfbilTf/R/G3xSUBSsvtlQAAMKQR
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7E8@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E8ausmsex00aust_"
MIME-Version: 1.0
Cc: "'rtcweb@ietf.org'" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:42:01 -0000

--_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E8ausmsex00aust_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGF2aW5nIHNvbWUgZXhwZXJpZW5jZSB3aXRoIHBhdGVudCB0cm9sbHMgSSBoYXZlIGNvbWUgdG8g
dGhlIHJlYWxpemF0aW9uIHRoYXQgaWYgeW91IGhhdmUgbWVhbnMgdGhleSB3aWxsIHN1ZSB5b3Ug
Zm9yIHByZXR0eSBtdWNoIGFueXRoaW5nIGV2ZW4gaWYgeW91IGRvIG5vdCBhY3R1YWxseSBpbmZy
aW5nZSBvbiB0aGVpciBwYXRlbnRzLiBZb3UgYXJlIHRoZW4gaW4gdGhlIHBvc2l0aW9uIG9mIGZp
Z2h0aW5nIHRoZW0gb3IgcGF5aW5nIHRoZW0gb2ZmLg0KDQpJIHRoaW5rIGl0IGlzIG5hw692ZSB0
byBiZWxpZXZlIHlvdSBjYW4gZXZlciBjb21wbGV0ZWx5IGF2b2lkIElQUiBieSBwaWNraW5nIHNv
bWUgYXJjaGFpYyBjb2RlYy4gSSB0aGluayB3ZSBuZWVkIHRvIGNvbWUgdXAgd2l0aCBhIGRpZmZl
cmVudCBzb2x1dGlvbiB0byBkZWZlbmQgYWdhaW5zdCBpbmZyaW5nZW1lbnQgY2xhaW1zIHJhdGhl
ciB0aGFuIHRyeWluZyB0byBhdm9pZCB0aGVtDQoNCg0KRnJvbTogSnVzdGluIFViZXJ0aSBbbWFp
bHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyMSwgMjAx
MyAwNDozMSBQTQ0KVG86IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlpaS5jYT4NCkNjOiBydGN3
ZWJAaWV0Zi5vcmcgPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBQcm9w
b3NlZCBWaWRlbyBTZWxlY3Rpb24gUHJvY2Vzcw0KDQpFdmVuIHRoZSBwcm9wb3NhbCB0aGF0IHJl
Y29tbWVuZGVkIEguMjY0IGFzIE1USSBpbmRpY2F0ZWQgdGhhdCB0aGUgdGVjaG5pY2FsIG1lcml0
IG9mIHRoZSBjdXJyZW50bHkgcHJvcG9zZWQgY29kZWNzIGlzIGVxdWl2YWxlbnQsIGFuZCB0aGUg
ZnVuZGFtZW50YWwgcXVlc3Rpb24gaXMgSVBSLg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2FnZW5k
YS84OC9zbGlkZXMvc2xpZGVzLTg4LXJ0Y3dlYi04LnBkZg0KDQpQdXQgYW5vdGhlciB3YXksIGlm
IHRoZSBhbGxlZ2VkIElQUiBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIGVpdGhlciBILjI2NCBvciBW
UDggZGlzYXBwZWFyZWQgb3Zlcm5pZ2h0LCB0aGlzIGRpc2N1c3Npb24gd291bGQgYmUgaW5zdGFu
dGx5IG92ZXIuDQoNCg0KT24gVGh1LCBOb3YgMjEsIDIwMTMgYXQgMjoxNCBQTSwgQ3VsbGVuIEpl
bm5pbmdzIDxmbHVmZnlAaWlpLmNhPG1haWx0bzpmbHVmZnlAaWlpLmNhPj4gd3JvdGU6DQoNCk9u
IE5vdiAyMSwgMjAxMywgYXQgMTI6MzYgUE0sIEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xl
LmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6DQoNCj4gVGhhdCBzYWlkLCBJ
IHRoaW5rIHRoZSBnZW5lcmFsIHVuZGVyc3RhbmRpbmcgaGVyZSBpcyB0aGF0IHRoaXMgaXMgbm8g
bG9uZ2VyIGEgdGVjaG5pY2FsIGRlY2lzaW9uLg0KPg0KDQpJJ2xsIG5vdGUgdGhhdCBzb21lIHBl
b3BsZSBzdHJvbmdseSBkaXNhZ3JlZSB3aXRoIHRoaXMgaXMgbm90IGEgdGVjaG5pY2FsIGRlY2lz
aW9uIGJ1dCB0aGVyZSBhcmUgb3RoZXJzIHdobyBkbyB0aGluayBpdCBpcyBpcyBubyBsb25nZXIg
YSB0ZWNobmljYWwgZGVjaXNpb24uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFp
bHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vcnRjd2ViDQoNCg==

--_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E8ausmsex00aust_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KSGF2aW5nIHNvbWUg
ZXhwZXJpZW5jZSB3aXRoIHBhdGVudCB0cm9sbHMgSSBoYXZlIGNvbWUgdG8gdGhlIHJlYWxpemF0
aW9uIHRoYXQgaWYgeW91IGhhdmUgbWVhbnMgdGhleSB3aWxsIHN1ZSB5b3UgZm9yIHByZXR0eSBt
dWNoIGFueXRoaW5nIGV2ZW4gaWYgeW91IGRvIG5vdCBhY3R1YWxseSBpbmZyaW5nZSBvbiB0aGVp
ciBwYXRlbnRzLiAgWW91IGFyZSB0aGVuIGluIHRoZSBwb3NpdGlvbiBvZiBmaWdodGluZyB0aGVt
IG9yIHBheWluZyB0aGVtIG9mZi4gIDxicj48YnI+SSB0aGluayBpdCBpcyBuYcOvdmUgdG8gYmVs
aWV2ZSB5b3UgY2FuIGV2ZXIgY29tcGxldGVseSBhdm9pZCBJUFIgYnkgcGlja2luZyBzb21lIGFy
Y2hhaWMgY29kZWMuICBJIHRoaW5rIHdlIG5lZWQgdG8gY29tZSB1cCB3aXRoIGEgZGlmZmVyZW50
IHNvbHV0aW9uIHRvIGRlZmVuZCBhZ2FpbnN0IGluZnJpbmdlbWVudCBjbGFpbXMgcmF0aGVyIHRo
YW4gdHJ5aW5nIHRvIGF2b2lkIHRoZW08YnI+PC9mb250Pjxicj4mbmJzcDs8YnI+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8Yj5Gcm9t
PC9iPjogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NPGJyPjxiPlNl
bnQ8L2I+OiBUaHVyc2RheSwgTm92ZW1iZXIgMjEsIDIwMTMgMDQ6MzEgUE08YnI+PGI+VG88L2I+
OiBDdWxsZW4gSmVubmluZ3MgJmx0O2ZsdWZmeUBpaWkuY2EmZ3Q7DTxicj48Yj5DYzwvYj46IHJ0
Y3dlYkBpZXRmLm9yZyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ow08YnI+PGI+U3ViamVjdDwvYj46
IFJlOiBbcnRjd2ViXSBQcm9wb3NlZCBWaWRlbyBTZWxlY3Rpb24gUHJvY2Vzcw08YnI+PC9mb250
PiZuYnNwOzxicj48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPkV2ZW4gdGhlIHByb3Bvc2FsIHRoYXQg
cmVjb21tZW5kZWQgSC4yNjQgYXMgTVRJIGluZGljYXRlZCB0aGF0IHRoZSB0ZWNobmljYWwgbWVy
aXQgb2YgdGhlIGN1cnJlbnRseSBwcm9wb3NlZCBjb2RlY3MgaXMgZXF1aXZhbGVudCwgYW5kIHRo
ZSBmdW5kYW1lbnRhbCBxdWVzdGlvbiBpcyBJUFIuPGRpdj48YSBocmVmPSJodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvYWdlbmRhLzg4L3NsaWRlcy9zbGlkZXMtODgtcnRjd2ViLTgucGRmIj5odHRwOi8v
dG9vbHMuaWV0Zi5vcmcvYWdlbmRhLzg4L3NsaWRlcy9zbGlkZXMtODgtcnRjd2ViLTgucGRmPC9h
Pjxicj4NCg0KPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5QdXQgYW5vdGhlciB3YXksIGlmIHRo
ZSBhbGxlZ2VkIElQUiBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIGVpdGhlciBILjI2NCBvciBWUDgg
ZGlzYXBwZWFyZWQgb3Zlcm5pZ2h0LCB0aGlzIGRpc2N1c3Npb24gd291bGQgYmUgaW5zdGFudGx5
IG92ZXIuPC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48YnI+PGRpdiBj
bGFzcz0iZ21haWxfcXVvdGUiPg0KDQpPbiBUaHUsIE5vdiAyMSwgMjAxMyBhdCAyOjE0IFBNLCBD
dWxsZW4gSmVubmluZ3MgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86Zmx1ZmZ5
QGlpaS5jYSIgdGFyZ2V0PSJfYmxhbmsiPmZsdWZmeUBpaWkuY2E8L2E+Jmd0Ozwvc3Bhbj4gd3Jv
dGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAg
MCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KDQo8
ZGl2IGNsYXNzPSJpbSI+PGJyPg0KT24gTm92IDIxLCAyMDEzLCBhdCAxMjozNiBQTSwgSnVzdGlu
IFViZXJ0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSI+anViZXJ0aUBn
b29nbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBUaGF0IHNhaWQsIEkgdGhp
bmsgdGhlIGdlbmVyYWwgdW5kZXJzdGFuZGluZyBoZXJlIGlzIHRoYXQgdGhpcyBpcyBubyBsb25n
ZXIgYSB0ZWNobmljYWwgZGVjaXNpb24uPGJyPg0KJmd0Ozxicj4NCjxicj4NCjwvZGl2PkkmIzM5
O2xsIG5vdGUgdGhhdCBzb21lIHBlb3BsZSBzdHJvbmdseSBkaXNhZ3JlZSB3aXRoIHRoaXMgaXMg
bm90IGEgdGVjaG5pY2FsIGRlY2lzaW9uIGJ1dCB0aGVyZSBhcmUgb3RoZXJzIHdobyBkbyB0aGlu
ayBpdCBpcyBpcyBubyBsb25nZXIgYSB0ZWNobmljYWwgZGVjaXNpb24uPGJyPg0KPGRpdiBjbGFz
cz0iSE9FblpiIj48ZGl2IGNsYXNzPSJoNSI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEg
aHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8
L2E+PGJyPg0KPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4NCg==

--_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E8ausmsex00aust_--

From metajack@gmail.com  Thu Nov 21 14:42:06 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A5F1AE3B3 for ; Thu, 21 Nov 2013 14:42:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHmXfa6LHrJq for ; Thu, 21 Nov 2013 14:42:05 -0800 (PST)
Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 32CA71AE3AC for ; Thu, 21 Nov 2013 14:42:05 -0800 (PST)
Received: by mail-oa0-f51.google.com with SMTP id i7so501793oag.38 for ; Thu, 21 Nov 2013 14:41:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vsBFRWtzsj1SzpOsxezNRGhldIEDViORCWFYvk9Gk/U=; b=NctWeiGGeOn8UkrXDzZW00uqsvNcgq4iSLiS69GqiNhr9A+9ebH1NSkxYZSTr3rR5z 4wML0tjgBFLK0gkBsov16QKQFyCDL+OQp53JDRPoKFFnRjL1iBEw2hZnDmKeQGynG7mU habC+c6ZQ5EGwCR4qGvPrlcDY9UbTQLAuOsdOycc3gMARc3TikvOXnOpga+cbUR1smZZ AeTr6BeahLT6AX5d9dcizYwd0I9Ri2yNy3rON2Ldxber74WOBLKXqeYf8WGobTaArDYy 7tjuiMe3ulmKyPizsHbEvOsWHMZA6B9kFrZ9+v2ngSTijjlIsF18hLyk4N7bHRW3dx+f uLZA==
MIME-Version: 1.0
X-Received: by 10.182.129.201 with SMTP id ny9mr7708176obb.0.1385073718235; Thu, 21 Nov 2013 14:41:58 -0800 (PST)
Sender: metajack@gmail.com
Received: by 10.60.17.70 with HTTP; Thu, 21 Nov 2013 14:41:58 -0800 (PST)
In-Reply-To: <528E78E9.9010904@telecomitalia.it>
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im> <528E78E9.9010904@telecomitalia.it>
Date: Thu, 21 Nov 2013 15:41:58 -0700
X-Google-Sender-Auth: ad2WlTCKXdgrSuS6_EIuxuu_Csw
Message-ID: 
From: Jack Moffitt 
To: Enrico Marocco 
Content-Type: text/plain; charset=ISO-8859-1
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:42:06 -0000

> The RFC series turned to success >40y ago by documenting running code and
> best practices.

All the running code for WebRTC is VP8.

Not claiming this is the best source, but the shipping implementations
of VP8 WebRTC represent ~60% of all desktop browsers:
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

This doesn't include mobile (where market share is still significant
but not as high), but the two shipping browsers have no problem with
VP8 even though they ship mobile browsers too.

Running code with majority market share doesn't seem to count for much.

jack.

From ron@debian.org  Thu Nov 21 14:42:43 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC05A1AE3BE for ; Thu, 21 Nov 2013 14:42:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ1Pf-q4UCWJ for ; Thu, 21 Nov 2013 14:42:42 -0800 (PST)
Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 085C91AE117 for ; Thu, 21 Nov 2013 14:42:41 -0800 (PST)
Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail04.adl6.internode.on.net with ESMTP; 22 Nov 2013 09:12:34 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id DF1D94F8F3 for ; Fri, 22 Nov 2013 09:12:31 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GKnQ2Vq4BWJR for ; Fri, 22 Nov 2013 09:12:31 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id B21D04F908; Fri, 22 Nov 2013 09:12:23 +1030 (CST)
Date: Fri, 22 Nov 2013 09:12:23 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20131121224223.GX3245@audi.shelbyville.oz>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>  <528E8142.1050309@librevideo.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:42:44 -0000

On Thu, Nov 21, 2013 at 01:58:59PM -0800, Eric Rescorla wrote:
> On Thu, Nov 21, 2013 at 1:55 PM, Basil Mohamed Gohar <
> >
> > It's no more crappy than having G.711 as a fallback audio codec for
> > legacy purposes, which we've already done for rtcweb audio.
> 
> 
> And there was really significant debate about that. The argument that
> ultimately carried the day was that
> 
> (a) G.711 was trivial
> (b) There were major interop advantages for the PSTN.
> 
> Neither of these two considerations applies here.

H.261 was in fact designed for use in the same 64kbs timeslots of the
same ISDN that G.711 was designed for and is still used on, and both
are still part of the same standards that define what to use there.

So if transparent interop with the PSTN is a major consideration ... :)

  Blocky turtles all the way down,
  Ron



From creslin@digium.com  Thu Nov 21 14:47:14 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88181AE3C5 for ; Thu, 21 Nov 2013 14:47:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDFu6hz0tYNf for ; Thu, 21 Nov 2013 14:47:13 -0800 (PST)
Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id F0E391AE3C4 for ; Thu, 21 Nov 2013 14:47:12 -0800 (PST)
Received: by mail-ee0-f41.google.com with SMTP id t10so176191eei.0 for ; Thu, 21 Nov 2013 14:47:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Hn1ur/h7fRXtzaqILPAmXjD3omwN3EbsKSScJC0JMSQ=; b=BhV2nLLVcyjO+BAbsRcxeIYEVdnlUQYZAEaHZwSOQ72T2zHZyuUQpdgxLKzeNLa6eu EwqT6sdF0hr6qeIE6M3SrrSKtP5lGoZ/tSDaDpu5RzG/ri1ZuuNdQP4m21fOUyWI2Ys+ 5zGntXzDbXM2+MO+ahJlwAC5Scz8YIHr21m7eYbl+5i9OR/EJffpQ2kCpbJ4SyzVRTnK pdyBsRXHEoZ7EEp3TUhsBukNBwpLN/kOySHYpmMqu5IfjaWK0e4S53k42YdjjKJb7DbK 9JPg8t3GJFOMNVNdcLyrnOpiLi90o+SkBulkPVFdzzq2w84JZZ09CdHNXIOyIQdToakt lFpw==
X-Gm-Message-State: ALoCoQnhbJBinVd8d7lwYBG58A+WZ2Ll0eDvNxScphagDOeDOm91ZjMfaUmeEaoD/Spfobg3SotP
MIME-Version: 1.0
X-Received: by 10.14.101.4 with SMTP id a4mr11863784eeg.28.1385074023816; Thu, 21 Nov 2013 14:47:03 -0800 (PST)
Received: by 10.14.220.7 with HTTP; Thu, 21 Nov 2013 14:47:03 -0800 (PST)
In-Reply-To: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>      
Date: Thu, 21 Nov 2013 16:47:03 -0600
Message-ID: 
From: Matt Fredrickson 
To: Cullen Jennings 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] cisco binary on ec2
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:47:15 -0000

Sorry, my facetiousness didn't get through in my email.  Clearly we
need to be discussing enhancements to emoticons for email instead of
this silly MTI debate.

I concur, and I don't know of any insurmountable problems with using
the Cisco H.264 plugin on EC2 cloud instances.

Matthew Fredrickson

On Thu, Nov 21, 2013 at 4:33 PM, Cullen Jennings  wrote:
>
> On Nov 21, 2013, at 12:21 PM, Matt Fredrickson  wrote:
>
>>  I cannot use that on my dynamically
>> deployed EC2 instances due to licensing restrictions. :-)
>
>
> My understanding of the legal situation is that you can use the cisco binary on your EC2 instance and have Cisco pay the MPEG-LA fees.

From lorenzo@meetecho.com  Thu Nov 21 14:47:20 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8121AE3CE for ; Thu, 21 Nov 2013 14:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.02
X-Spam-Level: 
X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd8PUDGiaRbC for ; Thu, 21 Nov 2013 14:47:19 -0800 (PST)
Received: from smtpdg3.aruba.it (smtpdg1.aruba.it [62.149.158.231]) by ietfa.amsl.com (Postfix) with ESMTP id A74811AE3CB for ; Thu, 21 Nov 2013 14:47:18 -0800 (PST)
Received: from rainpc ([87.6.118.125]) by smtpcmd01.ad.aruba.it with bizsmtp id sNn61m01Z2iQqnr01Nn7Z0; Thu, 21 Nov 2013 23:47:10 +0100
Date: Thu, 21 Nov 2013 23:47:06 +0100
From: Lorenzo Miniero 
To: Cullen Jennings 
Message-ID: <20131121234706.09a04878@rainpc>
In-Reply-To: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>      
Organization: Meetecho
X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] cisco binary on ec2
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:47:20 -0000

On Thu, 21 Nov 2013 14:33:15 -0800
Cullen Jennings  wrote:

> 
> On Nov 21, 2013, at 12:21 PM, Matt Fredrickson  wrote:
> 
> >  I cannot use that on my dynamically
> > deployed EC2 instances due to licensing restrictions. :-)
> 
> 
> My understanding of the legal situation is that you can use the cisco binary on your EC2 instance and have Cisco pay the MPEG-LA fees. 


The issue that was mentioned was cloned/frozen VM images that you could spawn to increase scalability. In that case, you would prepare/install an image just once, freeze it, and then launch a new one whenever you need it. Ideally you'd have the plugin installed that first time only, but then all cloned instances would fall out of the license agreement, as they'd actually be different machines with the plugin reinstalled rather than downloaded on the fly. Downloading the plugin for each new image that is spawned as it unfreezes would be a problem, as 1) the image wouldn't be ready right away, and 2) any problem in the download process would make the machine useless with respect to H.264.

Lorenzo


> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From martin.thomson@gmail.com  Thu Nov 21 14:47:57 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFD11AE3CF for ; Thu, 21 Nov 2013 14:47:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgFIw0h1k88f for ; Thu, 21 Nov 2013 14:47:55 -0800 (PST)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2382C1AE3CE for ; Thu, 21 Nov 2013 14:47:54 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id t61so422182wes.4 for ; Thu, 21 Nov 2013 14:47:47 -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=Rw9JLDmNlgvYCqN0+1RTHjyeAh0eFHoE65E/LtH8i0g=; b=N+WujqFw6yLnL0DvOQPcuXw3NaN3fCoo0fCb49DDqATEihXgReEYDSpT+CoztkTgLt WDxSgQ7WQd6wicII5Iu1KLHHYzbM1jfukyQ6s2sVY84BJYpPls5O7tvCVlBtDgOgX+a+ ytMGPEre1tSpOUdkhpmVU58BwmEK5h17ApzYzWbWRIRLMuhxMzR2uzD9YZ9gZFP4onhc i/pbhlOnH+1oaT/D9Gj56ckeaXFAu7Y6npIfRM5FIvsqt/qlppxWMhfOaAu9hBcEsdXL t1rmIuOCvljytX2Xs964wPwdJDzI4lc+kkQKQZ8Z8jHaIc/IIC/1AhRdveWRnOdJ6LVJ 9Pnw==
MIME-Version: 1.0
X-Received: by 10.180.208.49 with SMTP id mb17mr32105969wic.64.1385074067936;  Thu, 21 Nov 2013 14:47:47 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Thu, 21 Nov 2013 14:47:47 -0800 (PST)
In-Reply-To: 
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im> <528E78E9.9010904@telecomitalia.it> 
Date: Thu, 21 Nov 2013 14:47:47 -0800
Message-ID: 
From: Martin Thomson 
To: Jack Moffitt 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:47:57 -0000

On 21 November 2013 14:41, Jack Moffitt  wrote:
> All the running code for WebRTC is VP8.

All the running code *that you have seen* ...

From lorenzo@meetecho.com  Thu Nov 21 14:52:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E271AE3C5 for ; Thu, 21 Nov 2013 14:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.02
X-Spam-Level: 
X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIJ2627eLst3 for ; Thu, 21 Nov 2013 14:52:12 -0800 (PST)
Received: from smtpdg3.aruba.it (smtpdg1.aruba.it [62.149.158.231]) by ietfa.amsl.com (Postfix) with ESMTP id 67F2C1AE3DA for ; Thu, 21 Nov 2013 14:52:12 -0800 (PST)
Received: from rainpc ([87.6.118.125]) by smtpcmd01.ad.aruba.it with bizsmtp id sNs41m0072iQqnr01Ns4cj; Thu, 21 Nov 2013 23:52:04 +0100
Date: Thu, 21 Nov 2013 23:52:03 +0100
From: Lorenzo Miniero 
To: Martin Thomson 
Message-ID: <20131121235203.043d4d80@rainpc>
In-Reply-To: 
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im> <528E78E9.9010904@telecomitalia.it>  
Organization: Meetecho
X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:52:14 -0000

On Thu, 21 Nov 2013 14:47:47 -0800
Martin Thomson  wrote:

> On 21 November 2013 14:41, Jack Moffitt  wrote:
> > All the running code for WebRTC is VP8.
> 
> All the running code *that you have seen* ...


I have never seen Santa either...

L.


> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From creslin@digium.com  Thu Nov 21 14:57:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC021AE3E0 for ; Thu, 21 Nov 2013 14:57:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Gox6IqjYzX0 for ; Thu, 21 Nov 2013 14:57:11 -0800 (PST)
Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 810831AE17A for ; Thu, 21 Nov 2013 14:57:11 -0800 (PST)
Received: by mail-lb0-f171.google.com with SMTP id q8so339704lbi.2 for ; Thu, 21 Nov 2013 14:57:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=psgCe8aVuzmY1HKU6bZ3zlxkHXGNaMyumNDfKQeGQOM=; b=InGHuJzdcvQGu0wpM5zExI9DGvS35LxRDZ7rddmdKlJJ5yXEItJfhITcDjh0b/x+j4 0W8IiB06SXHD2q5dINgxgBV+WxfvJ5BexokURMNqnAHTrsP49X/1oaXwANJxZTTeAXJs YrjQmPcWd12MEGFO6jFRrYPn95YYIgfFFQScYe+ISrL3MJGc6ukdEzo0shrwc7TQCUs/ pCRZ4FKX/j6WzpNhfL8ugAZi2B9LdTM2Xx4fYHitKiuF/4r1CzvM3djGlPCY1t17Ps59 yov6nORxmg02il60SWqrnMmV8VkDftaLxMAuPyh2WC2jag62K9Hj6PGPeMQqH+mAgm8S TpQg==
X-Gm-Message-State: ALoCoQmrTUDyE12CZyTB+fuLy8DbL9f3mERYyVr0J1M+bl6kJf9bwI+qUvdwpaE2eIo//AEp83jJ
MIME-Version: 1.0
X-Received: by 10.112.53.134 with SMTP id b6mr6490724lbp.5.1385074623780; Thu, 21 Nov 2013 14:57:03 -0800 (PST)
Received: by 10.112.132.102 with HTTP; Thu, 21 Nov 2013 14:57:03 -0800 (PST)
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA8AD7E8@ausmsex00.austin.kmvtechnologies.com>
References:  <7949EED078736C4881C92F656DC6F6C130EA8AD7E8@ausmsex00.austin.kmvtechnologies.com>
Date: Thu, 21 Nov 2013 16:57:03 -0600
Message-ID: 
From: Matt Fredrickson 
To: Stefan Slivinski 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 22:57:13 -0000

Isn't the point to pick a codec old enough that the codec standard
itself should be considered prior art on any claims made against it?

Matthew Fredrickson

On Thu, Nov 21, 2013 at 4:37 PM, Stefan Slivinski
 wrote:
> Having some experience with patent trolls I have come to the realization
> that if you have means they will sue you for pretty much anything even if
> you do not actually infringe on their patents. You are then in the positi=
on
> of fighting them or paying them off.
>
> I think it is na=EFve to believe you can ever completely avoid IPR by pic=
king
> some archaic codec. I think we need to come up with a different solution =
to
> defend against infringement claims rather than trying to avoid them
>
>
> From: Justin Uberti [mailto:juberti@google.com]
> Sent: Thursday, November 21, 2013 04:31 PM
> To: Cullen Jennings 
> Cc: rtcweb@ietf.org 
> Subject: Re: [rtcweb] Proposed Video Selection Process
>
> Even the proposal that recommended H.264 as MTI indicated that the techni=
cal
> merit of the currently proposed codecs is equivalent, and the fundamental
> question is IPR.
> http://tools.ietf.org/agenda/88/slides/slides-88-rtcweb-8.pdf
>
> Put another way, if the alleged IPR issues associated with either H.264 o=
r
> VP8 disappeared overnight, this discussion would be instantly over.
>
>
> On Thu, Nov 21, 2013 at 2:14 PM, Cullen Jennings  wrote:
>>
>>
>> On Nov 21, 2013, at 12:36 PM, Justin Uberti  wrote:
>>
>> > That said, I think the general understanding here is that this is no
>> > longer a technical decision.
>> >
>>
>> I'll note that some people strongly disagree with this is not a technica=
l
>> decision but there are others who do think it is is no longer a technica=
l
>> decision.
>>
>> _______________________________________________
>> 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
>

From sslivinski@lifesize.com  Thu Nov 21 15:33:30 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43DF1AE1B2 for ; Thu, 21 Nov 2013 15:33:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdW4O24KkWiX for ; Thu, 21 Nov 2013 15:33:28 -0800 (PST)
Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with SMTP id 0F7721ADFE7 for ; Thu, 21 Nov 2013 15:33:28 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKUo6YPufkO0AzLPgWN1OofBJt8NOiQhGH@postini.com; Thu, 21 Nov 2013 15:33:21 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 17:28:19 -0600
From: Stefan Slivinski 
To: "'creslin@digium.com'" 
Date: Thu, 21 Nov 2013 17:28:18 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7nDQE6Fr5xRIFBS9ipSUsbJ9AHogABFqQk
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7EA@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "'rtcweb@ietf.org'" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Thu, 21 Nov 2013 23:33:30 -0000

So not to confuse licensing fees with ip infringement litigation but...I sh=
ould first point out that I am not an expert in this space but I have had a=
 reasonable amount of experience in this area and I can say that many paten=
ts are so generic and rarely specific to a particular codec, there may simp=
ly be a rate control algorithm patent that has the potential to apply to an=
y video encoder, past/present or future.


----- Original Message -----
From: Matt Fredrickson [mailto:creslin@digium.com]
Sent: Thursday, November 21, 2013 04:57 PM=0A=
To: Stefan Slivinski
Cc: juberti@google.com ; fluffy@iii.ca ;=
 rtcweb@ietf.org 
Subject: Re: [rtcweb] Proposed Video Selection Process

Isn't the point to pick a codec old enough that the codec standard
itself should be considered prior art on any claims made against it?

Matthew Fredrickson

On Thu, Nov 21, 2013 at 4:37 PM, Stefan Slivinski
 wrote:
> Having some experience with patent trolls I have come to the realization
> that if you have means they will sue you for pretty much anything even if
> you do not actually infringe on their patents. You are then in the positi=
on
> of fighting them or paying them off.
>
> I think it is na=EFve to believe you can ever completely avoid IPR by pic=
king
> some archaic codec. I think we need to come up with a different solution =
to
> defend against infringement claims rather than trying to avoid them
>
>
> From: Justin Uberti [mailto:juberti@google.com]
> Sent: Thursday, November 21, 2013 04:31 PM
> To: Cullen Jennings 
> Cc: rtcweb@ietf.org 
> Subject: Re: [rtcweb] Proposed Video Selection Process
>
> Even the proposal that recommended H.264 as MTI indicated that the techni=
cal
> merit of the currently proposed codecs is equivalent, and the fundamental
> question is IPR.
> http://tools.ietf.org/agenda/88/slides/slides-88-rtcweb-8.pdf
>
> Put another way, if the alleged IPR issues associated with either H.264 o=
r
> VP8 disappeared overnight, this discussion would be instantly over.
>
>
> On Thu, Nov 21, 2013 at 2:14 PM, Cullen Jennings  wrote:
>>
>>
>> On Nov 21, 2013, at 12:36 PM, Justin Uberti  wrote:
>>
>> > That said, I think the general understanding here is that this is no
>> > longer a technical decision.
>> >
>>
>> I'll note that some people strongly disagree with this is not a technica=
l
>> decision but there are others who do think it is is no longer a technica=
l
>> decision.
>>
>> _______________________________________________
>> 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
>

From fluffy@iii.ca  Thu Nov 21 16:11:19 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718561AE2CA for ; Thu, 21 Nov 2013 16:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUyEF7n0lbji for ; Thu, 21 Nov 2013 16:11:17 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BE1011AE376 for ; Thu, 21 Nov 2013 16:11:17 -0800 (PST)
Received: from [10.21.77.77] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DF4D222E1F3; Thu, 21 Nov 2013 19:11:07 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: 
Date: Thu, 21 Nov 2013 16:11:43 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <6C0B6BF5-97ED-4E88-B8A0-5FEA327115A4@iii.ca>
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im> <528E78E9.9010904@telecomitalia.it>  
To: Martin Thomson 
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 00:11:19 -0000

On Nov 21, 2013, at 2:47 PM, Martin Thomson  wrote:

> On 21 November 2013 14:41, Jack Moffitt  wrote:
>> All the running code for WebRTC is VP8.
> 
> All the running code *that you have seen* ...

Other than of course the first wbertc browser on Andoid, and many more ...


From singer@apple.com  Thu Nov 21 16:57:21 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFA81AE2CF for ; Thu, 21 Nov 2013 16:57:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Level: 
X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xvurn-bhP-CC for ; Thu, 21 Nov 2013 16:57:19 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9A01AE211 for ; Thu, 21 Nov 2013 16:57:19 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWN006U13ZBF3W1@mail-out.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 16:57:12 -0800 (PST)
X-AuditID: 11807166-b7f8b6d000001072-a0-528eabe818bb
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay8.apple.com (Apple SCV relay) with SMTP id 7E.16.04210.8EBAE825; Thu, 21 Nov 2013 16:57:12 -0800 (PST)
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWN007Q93ZCMJ40@spicerack.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 16:57:12 -0800 (PST)
From: David Singer 
In-reply-to: 
Date: Thu, 21 Nov 2013 16:57:11 -0800
Content-transfer-encoding: quoted-printable
Message-id: <8AE7D014-DED6-48EB-99C7-CF9952CF4FA6@apple.com>
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>  <528E8142.1050309@librevideo.org> 
To: Martin Thomson 
X-Mailer: Apple Mail (2.1822)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FCsoftidV+Qwblz6hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+nnnWwFC9kqrpytaWD8w9LFyMkhIWAisXrmBUYIW0ziwr31 bF2MXBxCApOZJG7/W8kE4axmkni39xlrFyMHB7OAnsT9i1ogDbxA5q3m+8wgtrCAmcSH+x3s IDabgKrEgznHwIZyCgRLHH12AayGBSi+5upfqDFREnuveoGEmQW0JZ68u8AKMdJGonP5a0aI tb0sEhtOnANLiAjoSiw6+4Ad4lBZid3PvzNPYBSYhXDRLCQXzUIydgEj8ypGgaLUnMRKC73E goKcVL3k/NxNjOCgK0zbwdi03OoQowAHoxIP7w7LviAh1sSy4srcQ4wSHMxKIrxTC4FCvCmJ lVWpRfnxRaU5qcWHGKU5WJTEea1WAaUE0hNLUrNTUwtSi2CyTBycUg2MceFNzxLEGGevfV19 te3NvdOiVqybp641O19Vdl9UJtrmb8iReys9N85XKhO6GrRD/WOc8e6YO6oCaWo/VBgPF/x9 zVclnutm2emeI23zh9EwcPLLR2IPKr243rqqRP9x7LxubSBXVvbQODnkcg/r+t6wx3u2FC9i /mVyK/RdfhfXvI2cGQlKLMUZiYZazEXFiQC3DhR7NgIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 00:57:21 -0000

On Nov 21, 2013, at 13:58 , Martin Thomson  =
wrote:

> On 21 November 2013 13:55, Basil Mohamed Gohar
>  wrote:
>> It's no more crappy than having G.711 as a fallback audio codec for
>> legacy purposes,
>=20
> Actually, it is.  G.711 is close to free to implement.  And, despite
> it actually being crappy, there's still a lot of it around.

well, it=92s band-limited and hardly compressed, but within those limits =
it=92s OK.  Whereas I seem to recall having trouble getting decent =
quality out of H.261 no matter what I did with it (but it has been =
*years* since I used H.261 for  anything, and it=92s only because I am =
an old geezer that I used it at all).

David Singer
Multimedia and Software Standards, Apple Inc.


From sslivinski@lifesize.com  Thu Nov 21 17:19:05 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275DD1AE351 for ; Thu, 21 Nov 2013 17:19:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qrl8FBHxsUVw for ; Thu, 21 Nov 2013 17:19:02 -0800 (PST)
Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with SMTP id 549C81ADF7F for ; Thu, 21 Nov 2013 17:19:02 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKUo6w/QenIUr15robRXkFvtL6mjSKbN0y@postini.com; Thu, 21 Nov 2013 17:18:55 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 19:15:04 -0600
From: Stefan Slivinski 
To: "'singer@apple.com'" , "'martin.thomson@gmail.com'" 
Date: Thu, 21 Nov 2013 19:15:03 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7nHc1jYUYPOTGrTme2meE3vJiZpQAAnhQd
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <8AE7D014-DED6-48EB-99C7-CF9952CF4FA6@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "'rtcweb@ietf.org'" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 01:19:05 -0000

RGF2aWQgeW91ciBwb2ludCBpcyBhYnNvbHV0ZWx5IGNvcnJlY3QuICBILjI2MSB3b3VsZCBiZSBj
b21wbGV0ZWx5IHVudXNhYmxlLiAgVGhlIG1heCByZXNvbHV0aW9uIGlzIDM1MngyODggbm90IHRv
IG1lbnRpb24gbWFueSBvdGhlciBhbGdvcml0aG0gIGlzc3VlcyB0aGF0IG1ha2UgdGhlIHF1YWxp
dHkgZXZlbiBhdCBsb3cgcXAncyB1bmFjY2VwdGFibGUgZXNwZWNpYWxseSBvbiBhIG1vYmlsZSBk
ZXZpY2Ugd2hlcmUgdGhlIGNhbWVyYSBpcyBhbnl0aGluZyBidXQgc3RlYWR5DQoNClRoZSBmYWN0
IHRoYXQgaC4yNjEgaXMgZ2V0dGluZyBzbyBtdWNoIGF0dGVudGlvbiBpcyBkaXN0cmVzc2luZyAg
DQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogRGF2aWQgU2luZ2VyIFtt
YWlsdG86c2luZ2VyQGFwcGxlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyMSwgMjAx
MyAwNjo1NyBQTQpUbzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4N
CkNjOiBydGN3ZWJAaWV0Zi5vcmcgPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRj
d2ViXSBQcm9wb3NlZCBWaWRlbyBTZWxlY3Rpb24gUHJvY2Vzcw0KDQoNCk9uIE5vdiAyMSwgMjAx
MywgYXQgMTM6NTggLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPiB3
cm90ZToNCg0KPiBPbiAyMSBOb3ZlbWJlciAyMDEzIDEzOjU1LCBCYXNpbCBNb2hhbWVkIEdvaGFy
DQo+IDxiYXNpbGdvaGFyQGxpYnJldmlkZW8ub3JnPiB3cm90ZToNCj4+IEl0J3Mgbm8gbW9yZSBj
cmFwcHkgdGhhbiBoYXZpbmcgRy43MTEgYXMgYSBmYWxsYmFjayBhdWRpbyBjb2RlYyBmb3INCj4+
IGxlZ2FjeSBwdXJwb3NlcywNCj4gDQo+IEFjdHVhbGx5LCBpdCBpcy4gIEcuNzExIGlzIGNsb3Nl
IHRvIGZyZWUgdG8gaW1wbGVtZW50LiAgQW5kLCBkZXNwaXRlDQo+IGl0IGFjdHVhbGx5IGJlaW5n
IGNyYXBweSwgdGhlcmUncyBzdGlsbCBhIGxvdCBvZiBpdCBhcm91bmQuDQoNCndlbGwsIGl04oCZ
cyBiYW5kLWxpbWl0ZWQgYW5kIGhhcmRseSBjb21wcmVzc2VkLCBidXQgd2l0aGluIHRob3NlIGxp
bWl0cyBpdOKAmXMgT0suICBXaGVyZWFzIEkgc2VlbSB0byByZWNhbGwgaGF2aW5nIHRyb3VibGUg
Z2V0dGluZyBkZWNlbnQgcXVhbGl0eSBvdXQgb2YgSC4yNjEgbm8gbWF0dGVyIHdoYXQgSSBkaWQg
d2l0aCBpdCAoYnV0IGl0IGhhcyBiZWVuICp5ZWFycyogc2luY2UgSSB1c2VkIEguMjYxIGZvciAg
YW55dGhpbmcsIGFuZCBpdOKAmXMgb25seSBiZWNhdXNlIEkgYW0gYW4gb2xkIGdlZXplciB0aGF0
IEkgdXNlZCBpdCBhdCBhbGwpLg0KDQpEYXZpZCBTaW5nZXINCk11bHRpbWVkaWEgYW5kIFNvZnR3
YXJlIFN0YW5kYXJkcywgQXBwbGUgSW5jLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3Jn
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K

From singer@apple.com  Thu Nov 21 17:23:45 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8392D1AE3AD for ; Thu, 21 Nov 2013 17:23:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Level: 
X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oytRqY0IEy43 for ; Thu, 21 Nov 2013 17:23:43 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 207591AE351 for ; Thu, 21 Nov 2013 17:23:43 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWN00E5E57B30B1@mail-out.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 17:23:36 -0800 (PST)
X-AuditID: 11807166-b7f8b6d000001072-05-528eb218de74
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay8.apple.com (Apple SCV relay) with SMTP id A8.A1.04210.812BE825; Thu, 21 Nov 2013 17:23:36 -0800 (PST)
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWN00AXW57CK940@spicerack.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 17:23:36 -0800 (PST)
From: David Singer 
In-reply-to: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>
Date: Thu, 21 Nov 2013 17:23:35 -0800
Content-transfer-encoding: quoted-printable
Message-id: 
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>
To: Stefan Slivinski 
X-Mailer: Apple Mail (2.1822)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FCsoSuxqS/I4M8/MYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseLMa+aCTsGK2z1vGBsYn/B2MXJySAiYSHTff84IYYtJXLi3 nq2LkYtDSGAyk8TuS2+YIZzVTBI/zl0HquLgYBbQk7h/UQukgRfIvNV8nxnEFhYwk/hwv4Md xGYTUJV4MOcY2FBOgQSJq++/gcVZgOInO3+D1TMDxZcdOsQIYWtLPHl3gRVipo1E8+NTYLaQ QLzEi3PNLCC2CNCuL0s+MkEcKiux+/l35gmMArMQLpqF5KJZSKYuYGRexShQlJqTWGmhl1hQ kJOql5yfu4kRHHaFaTsYm5ZbHWIU4GBU4uHdYdkXJMSaWFZcmXuIUYKDWUmE12MDUIg3JbGy KrUoP76oNCe1+BCjNAeLkjhvxxqglEB6YklqdmpqQWoRTJaJg1OqgZGhyWP5jwWXbVsl3q5o blTV2zKh/eqVvFrdTWtLCl6GRLaGz7szMdexsfGORf2xfX7XZskFv2bc8H5Vfdii8tArZl+5 P8q5H8kWf2TOYMVbLVfxMqYpr++KJnPKvlPuwp+iJium7uSMya4P5W18G6kzde8zr+iF/xlL p3Xln6oW8cm6tY7xhxJLcUaioRZzUXEiAPNSjGI3AgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 01:23:45 -0000

On Nov 21, 2013, at 17:15 , Stefan Slivinski  =
wrote:

> David your point is absolutely correct.  H.261 would be completely =
unusable.  The max resolution is 352x288 not to mention many other =
algorithm  issues that make the quality even at low qp's unacceptable =
especially on a mobile device where the camera is anything but steady
>=20
> The fact that h.261 is getting so much attention is distressing =20

Yes, that=92s my gut.  If we ask our engineers to implement it (I mean =
we in the sense of members of the WebRTC group) I am fairly sure that we =
will get a mix of =93you want me to do WHAT?=94, =93are you insane?=94, =
=93what century are YOU from?=94, and the like.

Can someone remind me why classic H.263 (with possibly the minor tweaks =
for picture size limits etc.) is problematic?

>=20
>=20
> ----- Original Message -----
> From: David Singer [mailto:singer@apple.com]
> Sent: Thursday, November 21, 2013 06:57 PM
> To: Martin Thomson 
> Cc: rtcweb@ietf.org 
> Subject: Re: [rtcweb] Proposed Video Selection Process
>=20
>=20
> On Nov 21, 2013, at 13:58 , Martin Thomson  =
wrote:
>=20
>> On 21 November 2013 13:55, Basil Mohamed Gohar
>>  wrote:
>>> It's no more crappy than having G.711 as a fallback audio codec for
>>> legacy purposes,
>>=20
>> Actually, it is.  G.711 is close to free to implement.  And, despite
>> it actually being crappy, there's still a lot of it around.
>=20
> well, it=92s band-limited and hardly compressed, but within those =
limits it=92s OK.  Whereas I seem to recall having trouble getting =
decent quality out of H.261 no matter what I did with it (but it has =
been *years* since I used H.261 for  anything, and it=92s only because I =
am an old geezer that I used it at all).
>=20
> David Singer
> Multimedia and Software Standards, Apple Inc.
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

David Singer
Multimedia and Software Standards, Apple Inc.


From derhoermi@gmx.net  Thu Nov 21 17:39:02 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5ED1AC43E for ; Thu, 21 Nov 2013 17:39:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level: 
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rsXvKvAhErw for ; Thu, 21 Nov 2013 17:39:00 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 67B821A1F19 for ; Thu, 21 Nov 2013 17:39:00 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.61.205]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MLA45-1Vjwgn0fI1-000NNv for ; Fri, 22 Nov 2013 02:38:52 +0100
From: Bjoern Hoehrmann 
To: Stefan Slivinski 
Date: Fri, 22 Nov 2013 02:38:53 +0100
Message-ID: 
References: <8AE7D014-DED6-48EB-99C7-CF9952CF4FA6@apple.com> <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:NkHehzdYvTZffD9j5TbmZ1vUoxZPPPlqtBYWeSAK8uls2PGPmMW wDTZVcrcywX4TfoFyCukLCaU1vs/fVWtZeixAMz7pl/8L5z1+OZxnC95XAzpqaLkLZ+oQDo vFs8trtrXk3nyV+07GtDkunxHVltrGOjxCP7mqyP8W7De4yMt34E2ii25hlKrHz3Y3zZN+g Cc3O76bD1CWamoydVWRCQ==
Cc: "'rtcweb@ietf.org'" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 01:39:02 -0000

* Stefan Slivinski wrote:
>The fact that h.261 is getting so much attention is distressing  

It might be helpful if someone explained how H.261 compares to something
people can relate to better. Like animated GIFs, or sending a bunch of
JPEG images in a row at certain frame rates, resolutions, compression
ratios.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From basilgohar@librevideo.org  Thu Nov 21 18:00:37 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7775B1AE2AA for ; Thu, 21 Nov 2013 18:00:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HJvmv8Ju8Ih for ; Thu, 21 Nov 2013 18:00:35 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id D6BCD1AE2A7 for ; Thu, 21 Nov 2013 18:00:35 -0800 (PST)
Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id B373E6598E0 for ; Thu, 21 Nov 2013 21:00:28 -0500 (EST)
Message-ID: <528EBAB0.2010906@librevideo.org>
Date: Thu, 21 Nov 2013 21:00:16 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 02:00:37 -0000

On 11/21/2013 08:23 PM, David Singer wrote:
> 
> Can someone remind me why classic H.263 (with possibly the minor tweaks for picture size limits etc.) is problematic?
> 

For exactly the same reasons H.264 (for some) and VP8 (for others) - IPR
issues due to not being old enough for anything patented in the standard
to be guaranteed to have expired.

-- 
Libre Video
http://librevideo.org

From singer@apple.com  Thu Nov 21 18:05:51 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3881AE29B for ; Thu, 21 Nov 2013 18:05:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Level: 
X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Jn6_gr4qQYv for ; Thu, 21 Nov 2013 18:05:49 -0800 (PST)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id B92351ADED6 for ; Thu, 21 Nov 2013 18:05:49 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWN00KUD75HV430@mail-out.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 18:05:42 -0800 (PST)
X-AuditID: 11807165-b7f8e6d000004de8-22-528ebbf56844
Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay7.apple.com (Apple SCV relay) with SMTP id DE.A4.19944.5FBBE825; Thu, 21 Nov 2013 18:05:41 -0800 (PST)
Received: from [192.168.10.39] (sftp.tritondataservices.com [76.74.153.49]) by koseret.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWN00AX875D6520@koseret.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 18:05:41 -0800 (PST)
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>  <528EBAB0.2010906@librevideo.org>
In-reply-to: <528EBAB0.2010906@librevideo.org>
Message-id: 
X-Mailer: iPad Mail (11B554a)
From: David Singer 
Date: Thu, 21 Nov 2013 18:05:37 -0800
To: Basil Mohamed Gohar 
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUiON1OXffr7r4ggzkNFhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9K0VywF/1grVv14ydbA+J6li5GDQ0LAROLQrtQuRk4gU0zi wr31bF2MXBxCAi1MEkcf7mSFcDYySez/sIEJwtnGKLHi8UxGkBZeAXGJ10engNmcAnoSb5ds ZAWxmQW0JNbvPM4EYWtLPHl3gRWi3kZiY2crO0RcXWLp5AY2iNWyEmduTwGLswmoSjyYcwxs prCAmcSH+x1gcRag+Lefy1lAbBEBY4nPh+YwT2AUmIXkjFlIVs9CsnoBI/MqRoGi1JzESnO9 xIKCnFS95PzcTYyg0GsoTN3B2Ljc6hCjAAejEg/vDsu+ICHWxLLiytxDjBIczEoivB4bgEK8 KYmVValF+fFFpTmpxYcYpTlYlMR5O9YApQTSE0tSs1NTC1KLYLJMHJxSDYwuJXxP6i5dVFxd cvHjnJ1z+nIjmXd88LVb+qugY9nxfZJOktydHVr/HNWDli+XTJqdWNItk2G53Ooa+6sdjbOl a64JxK684He++sT95CVVU2apR7rfMYmJ+rDf//uh+ykHfG8VRC+8z2yQPsHnf3ptSJjytUeL Mmdu2V+y6uunueuuTTkZ899diaU4I9FQi7moOBEAeZ3V1zkCAAA=
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 02:05:51 -0000

Ok, even though the standard issued in early 1996, more than 17 years ago?

Sent from my iPad

> On Nov 21, 2013, at 6:00 PM, Basil Mohamed Gohar  wrote:
> 
>> On 11/21/2013 08:23 PM, David Singer wrote:
>> 
>> Can someone remind me why classic H.263 (with possibly the minor tweaks for picture size limits etc.) is problematic?
> 
> For exactly the same reasons H.264 (for some) and VP8 (for others) - IPR
> issues due to not being old enough for anything patented in the standard
> to be guaranteed to have expired.
> 
> -- 
> Libre Video
> http://librevideo.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From basilgohar@librevideo.org  Thu Nov 21 18:11:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216381ACCE0 for ; Thu, 21 Nov 2013 18:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.924
X-Spam-Level: **
X-Spam-Status: No, score=2.924 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CAN_LONGER=4.824] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdSt876OyUBJ for ; Thu, 21 Nov 2013 18:11:34 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 211E61A1F19 for ; Thu, 21 Nov 2013 18:11:34 -0800 (PST)
Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 1DC0B659A56; Thu, 21 Nov 2013 21:11:27 -0500 (EST)
Message-ID: <528EBD4C.8070504@librevideo.org>
Date: Thu, 21 Nov 2013 21:11:24 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: David Singer 
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>  <528EBAB0.2010906@librevideo.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 02:11:35 -0000

Patents can last longer than 17 years.

http://patents.stackexchange.com/questions/312/how-long-are-software-patents-valid

On 11/21/2013 09:05 PM, David Singer wrote:
> Ok, even though the standard issued in early 1996, more than 17 years ago?
> 
> Sent from my iPad
> 
>> On Nov 21, 2013, at 6:00 PM, Basil Mohamed Gohar  wrote:
>>
>>> On 11/21/2013 08:23 PM, David Singer wrote:
>>>
>>> Can someone remind me why classic H.263 (with possibly the minor tweaks for picture size limits etc.) is problematic?
>>
>> For exactly the same reasons H.264 (for some) and VP8 (for others) - IPR
>> issues due to not being old enough for anything patented in the standard
>> to be guaranteed to have expired.
>>
>> -- 
>> Libre Video
>> http://librevideo.org
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Libre Video
http://librevideo.org

From juberti@google.com  Thu Nov 21 18:19:02 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EAC1AD0F0 for ; Thu, 21 Nov 2013 18:19:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.921
X-Spam-Level: **
X-Spam-Status: No, score=2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_CAN_LONGER=4.824, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57xE7N_nY9qa for ; Thu, 21 Nov 2013 18:19:00 -0800 (PST)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 883DA1AD94A for ; Thu, 21 Nov 2013 18:19:00 -0800 (PST)
Received: by mail-vc0-f182.google.com with SMTP id lc6so445010vcb.27 for ; Thu, 21 Nov 2013 18:18:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KWFiNuCnKacwXQpBiaO6WmR16lUcjHp20HFigOdFWWQ=; b=I1GljS3KiPwsS7hUWcfhnD+Uf6TLtKVYEIRiT6AmWj5j3Yo8HmbAfUse5IQyy+l5wh quRG/XcxPHvEqbBD56Uy9WRPQKDswnRiwLI4qMRlL+9ETtKg+VfbAdc2QzWQrKYxTqqZ FCtByhqU15v4XBQ89oU6FPOiSmITuKc62x433TjemDw2ptqJpfE9mRKSvw8ra72bsIhc PkTl/rzhVBokOB9GWRP4pO8R0nZ272QWtjYHK/AiGvcpkSegzMFJ97OphIKjw7yqr3tt sGaYz6WS9Ucsi2dXUvMSHVM9MFyTuLiQByNlsz2l6ZWa6D1BDfySNiYwRe3Nvjn09F49 xnVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KWFiNuCnKacwXQpBiaO6WmR16lUcjHp20HFigOdFWWQ=; b=jyvMLWJEj5BUK8bTvvXCDHirYZKkujgoAzyhhNLIGuBsw93ZCGoG9h+XoaycWLSA7R XP89XPtSmgf85LWnz7uVrqI6Q9wTUECrC2WPjpsk9Qw5YJ/vy/MA7Esk4E3RAIN0Jdtn F+syLkHB2c+TgRSy1yz/lizx3OvIbdvngmYku8h68rYicFg2MrteUNaXS6hcDqr8ME21 7s6JFxbJSlrhkspt8DsKsa8eEIFe1LLDhV23vun6C+piIu2DRrOccHVDDV+WcwbBaZ7z X/332B1+3wmY0evqbGdMa4+fD9I4pB09xskATyWzHtl9OtCwN3UzFSOZPluU3M3VC0Cr 3aTw==
X-Gm-Message-State: ALoCoQmZnwjTVXqTWH3v2RePwKWWY8whKylmMm0IDm7HsRFjbJU226aVKH6wjOZKk9ivcyBiK4jwg4xYvhajQBEwZR9zy9Uje9qH61Ic7RxRzMcHXRan1jGjKYxnPxAFg+G8LeyIq79s/nDB2DPP+SPV7w5RC3UlBmF9qGjzm+j2+n9qRXPUxH8fXtCmWOC928GW4pHHPnTh
MIME-Version: 1.0
X-Received: by 10.220.169.203 with SMTP id a11mr191049vcz.26.1385086733360; Thu, 21 Nov 2013 18:18:53 -0800 (PST)
Received: by 10.52.110.101 with HTTP; Thu, 21 Nov 2013 18:18:52 -0800 (PST)
Received: by 10.52.110.101 with HTTP; Thu, 21 Nov 2013 18:18:52 -0800 (PST)
In-Reply-To: <528EBD4C.8070504@librevideo.org>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>  <528EBAB0.2010906@librevideo.org>  <528EBD4C.8070504@librevideo.org>
Date: Thu, 21 Nov 2013 18:18:52 -0800
Message-ID: 
From: Justin Uberti 
To: Basil Mohamed Gohar 
Content-Type: multipart/alternative; boundary=047d7b6721c4b9b57804ebbaa24b
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 02:19:02 -0000

--047d7b6721c4b9b57804ebbaa24b
Content-Type: text/plain; charset=UTF-8

Stefan Wenger posted a fairly detailed analysis of the H.263 situation,
which I think also applies to MPEG-2.

TL;DR: no, because patents.
On Nov 21, 2013 6:11 PM, "Basil Mohamed Gohar" 
wrote:

> Patents can last longer than 17 years.
>
>
> http://patents.stackexchange.com/questions/312/how-long-are-software-patents-valid
>
> On 11/21/2013 09:05 PM, David Singer wrote:
> > Ok, even though the standard issued in early 1996, more than 17 years
> ago?
> >
> > Sent from my iPad
> >
> >> On Nov 21, 2013, at 6:00 PM, Basil Mohamed Gohar <
> basilgohar@librevideo.org> wrote:
> >>
> >>> On 11/21/2013 08:23 PM, David Singer wrote:
> >>>
> >>> Can someone remind me why classic H.263 (with possibly the minor
> tweaks for picture size limits etc.) is problematic?
> >>
> >> For exactly the same reasons H.264 (for some) and VP8 (for others) - IPR
> >> issues due to not being old enough for anything patented in the standard
> >> to be guaranteed to have expired.
> >>
> >> --
> >> Libre Video
> >> http://librevideo.org
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> --
> Libre Video
> http://librevideo.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--047d7b6721c4b9b57804ebbaa24b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Stefan Wenger posted a fairly detailed analysis of the H.263=
 situation, which I think also applies to MPEG-2. 
    

    TL;DR: no, because patents.
    

    On Nov 21, 2013 6:11 PM, "Basil Mohamed Goh=
ar" <basilgohar@librev=
ideo.org> wrote:
    
Patents can last longer than 17 years.
    

    
http://patents.stackexchange.com/ques=
tions/312/how-long-are-software-patents-valid
    

    
On 11/21/2013 09:05 PM, David Singer wrote:
    
> Ok, even though the standard issued in early 1996, more than 17 years =
ago?
    
>
    
> Sent from my iPad
    
>
    
>> On Nov 21, 2013, at 6:00 PM, Basil Mohamed Gohar <basilgohar@librevideo.org> wrote:
>>
    
>>> On 11/21/2013 08:23 PM, David Singer wrote:
    
>>>
    
>>> Can someone remind me why classic H.263 (with possibly the min=
or tweaks for picture size limits etc.) is problematic?
    
>>
    
>> For exactly the same reasons H.264 (for some) and VP8 (for others)=
 - IPR
    
>> issues due to not being old enough for anything patented in the st=
andard
    
>> to be guaranteed to have expired.
    
>>
    
>> --
    
>> Libre Video
    
>> http://librevi=
deo.org
    
>> _______________________________________________
    
>> rtcweb mailing list
    
>> rtcweb@ietf.org
    
>> https://www.ietf.org/mailman/listinfo/rtcweb
    

    

    
--
    
Libre Video
    
http://librevideo.org
    
_______________________________________________
    
rtcweb mailing list
    
    rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    

    

--047d7b6721c4b9b57804ebbaa24b--

From cb.list6@gmail.com  Thu Nov 21 19:15:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9581ADF4E for ; Thu, 21 Nov 2013 19:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GROrEhmm4n1F for ; Thu, 21 Nov 2013 19:15:05 -0800 (PST)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 93BD51ADFFE for ; Thu, 21 Nov 2013 19:15:04 -0800 (PST)
Received: by mail-wi0-f169.google.com with SMTP id hm6so999971wib.4 for ; Thu, 21 Nov 2013 19:14:57 -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=1uMmgyLzjZCvYgsk4LdckNQeFqnxoIG6Q/qBl/yZpOs=; b=yrsdmS9Wzkg6+1sPMekYdnJhzooewnr6YCuyF2Y8rmXXa+tyQRGX8CBx4TIPPKcqIp 7jwJvig4cuH2uHo+qdX2AFDiaYj3xQkrt3B1g1UpGY4WhKI0eu+QD5O8Xz2BQZnWWJgE 1TJYywKguAL2rCCFBwF8jJCdbYJsUPRRgNjhJDZo+/GQjNugjGEdX7wxT+g2NdwsRwyB MN49GsoggvSYv4YkQymPWohi6rNHgB69Bk7cTSIF7JMx8mm2Vvd6DPjqTxiCjC9PhsUD 4MyiDk8i94ZTIAGevaUVbNqjdn9s415SrrfZLkayTa4czn5pWEUM9NCqgYLdvHsHS+AI 0XCQ==
MIME-Version: 1.0
X-Received: by 10.180.12.179 with SMTP id z19mr704310wib.24.1385090097171; Thu, 21 Nov 2013 19:14:57 -0800 (PST)
Received: by 10.217.58.133 with HTTP; Thu, 21 Nov 2013 19:14:56 -0800 (PST)
Received: by 10.217.58.133 with HTTP; Thu, 21 Nov 2013 19:14:56 -0800 (PST)
In-Reply-To: 
References:  <52891EDB.2050607@googlemail.com>  <528B2ABE.4040701@googlemail.com>  <528C79AD.10608@googlemail.com>  <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>    
Date: Thu, 21 Nov 2013 19:14:56 -0800
Message-ID: 
From: "cb.list6" 
To: Eric Rescorla 
Content-Type: multipart/alternative; boundary=001a11c3533a3952dc04ebbb6bc2
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 03:15:10 -0000

--001a11c3533a3952dc04ebbb6bc2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Nov 21, 2013 12:18 PM, "Eric Rescorla"  wrote:
>
>
>
>
> On Thu, Nov 21, 2013 at 12:14 PM, Steve Kann  wrote:
>>
>>
>> Do you plan to open-source your codec option generator?   It would make
modifying the list much more efficient.
>
>
>
> I was thinking of distributing it as a binary module you could link into
your
> mail client.
>
> -Ekr
>

That sounds real good. Promise not to fork my private correspondence or
meta data to the NSA?

>>
>>
>>
>>
>> -Sent from an iOS mobile device
>>
>> On Nov 21, 2013, at 12:01 PM, Eric Rescorla  wrote:
>>
>>> I would like to propose some additional alternatives.
>>>
>>> SHOULD: Theora
>>> MUST: Theora
>>> SHOULD: H.261
>>> SHOULD: H.261 Theora
>>> MUST: Theora; SHOULD: H.261
>>> MUST: H.261
>>> MUST: H.261; SHOULD: Theora
>>> MUST: H.261 Theora
>>> SHOULD: H.263
>>> SHOULD: H.263 Theora
>>> MUST: Theora; SHOULD: H.263
>>> SHOULD: H.263 H.261
>>> SHOULD: H.263 H.261 Theora
>>> MUST: Theora; SHOULD: H.263 H.261
>>> MUST: H.261; SHOULD: H.263
>>> MUST: H.261; SHOULD: H.263 Theora
>>> MUST: H.261 Theora; SHOULD: H.263
>>> MUST: H.263
>>> MUST: H.263; SHOULD: Theora
>>> MUST: H.263 Theora
>>> MUST: H.263; SHOULD: H.261
>>> MUST: H.263; SHOULD: H.261 Theora
>>> MUST: H.263 Theora; SHOULD: H.261
>>> MUST: H.263 H.261
>>> MUST: H.263 H.261; SHOULD: Theora
>>> MUST: H.263 H.261 Theora
>>> SHOULD: VP8
>>> SHOULD: VP8 Theora
>>> MUST: Theora; SHOULD: VP8
>>> SHOULD: VP8 H.261
>>> SHOULD: VP8 H.261 Theora
>>> MUST: Theora; SHOULD: VP8 H.261
>>> MUST: H.261; SHOULD: VP8
>>> MUST: H.261; SHOULD: VP8 Theora
>>> MUST: H.261 Theora; SHOULD: VP8
>>> SHOULD: VP8 H.263
>>> SHOULD: VP8 H.263 Theora
>>> MUST: Theora; SHOULD: VP8 H.263
>>> SHOULD: VP8 H.263 H.261
>>> SHOULD: VP8 H.263 H.261 Theora
>>> MUST: Theora; SHOULD: VP8 H.263 H.261
>>> MUST: H.261; SHOULD: VP8 H.263
>>> MUST: H.261; SHOULD: VP8 H.263 Theora
>>> MUST: H.261 Theora; SHOULD: VP8 H.263
>>> MUST: H.263; SHOULD: VP8
>>> MUST: H.263; SHOULD: VP8 Theora
>>> MUST: H.263 Theora; SHOULD: VP8
>>> MUST: H.263; SHOULD: VP8 H.261
>>> MUST: H.263; SHOULD: VP8 H.261 Theora
>>> MUST: H.263 Theora; SHOULD: VP8 H.261
>>> MUST: H.263 H.261; SHOULD: VP8
>>> MUST: H.263 H.261; SHOULD: VP8 Theora
>>> MUST: H.263 H.261 Theora; SHOULD: VP8
>>> MUST: VP8
>>> MUST: VP8; SHOULD: Theora
>>> MUST: VP8 Theora
>>> MUST: VP8; SHOULD: H.261
>>> MUST: VP8; SHOULD: H.261 Theora
>>> MUST: VP8 Theora; SHOULD: H.261
>>> MUST: VP8 H.261
>>> MUST: VP8 H.261; SHOULD: Theora
>>> MUST: VP8 H.261 Theora
>>> MUST: VP8; SHOULD: H.263
>>> MUST: VP8; SHOULD: H.263 Theora
>>> MUST: VP8 Theora; SHOULD: H.263
>>> MUST: VP8; SHOULD: H.263 H.261
>>> MUST: VP8; SHOULD: H.263 H.261 Theora
>>> MUST: VP8 Theora; SHOULD: H.263 H.261
>>> MUST: VP8 H.261; SHOULD: H.263
>>> MUST: VP8 H.261; SHOULD: H.263 Theora
>>> MUST: VP8 H.261 Theora; SHOULD: H.263
>>> MUST: VP8 H.263
>>> MUST: VP8 H.263; SHOULD: Theora
>>> MUST: VP8 H.263 Theora
>>> MUST: VP8 H.263; SHOULD: H.261
>>> MUST: VP8 H.263; SHOULD: H.261 Theora
>>> MUST: VP8 H.263 Theora; SHOULD: H.261
>>> MUST: VP8 H.263 H.261
>>> MUST: VP8 H.263 H.261; SHOULD: Theora
>>> MUST: VP8 H.263 H.261 Theora
>>> SHOULD: H.264
>>> SHOULD: H.264 Theora
>>> MUST: Theora; SHOULD: H.264
>>> SHOULD: H.264 H.261
>>> SHOULD: H.264 H.261 Theora
>>> MUST: Theora; SHOULD: H.264 H.261
>>> MUST: H.261; SHOULD: H.264
>>> MUST: H.261; SHOULD: H.264 Theora
>>> MUST: H.261 Theora; SHOULD: H.264
>>> SHOULD: H.264 H.263
>>> SHOULD: H.264 H.263 Theora
>>> MUST: Theora; SHOULD: H.264 H.263
>>> SHOULD: H.264 H.263 H.261
>>> SHOULD: H.264 H.263 H.261 Theora
>>> MUST: Theora; SHOULD: H.264 H.263 H.261
>>> MUST: H.261; SHOULD: H.264 H.263
>>> MUST: H.261; SHOULD: H.264 H.263 Theora
>>> MUST: H.261 Theora; SHOULD: H.264 H.263
>>> MUST: H.263; SHOULD: H.264
>>> MUST: H.263; SHOULD: H.264 Theora
>>> MUST: H.263 Theora; SHOULD: H.264
>>> MUST: H.263; SHOULD: H.264 H.261
>>> MUST: H.263; SHOULD: H.264 H.261 Theora
>>> MUST: H.263 Theora; SHOULD: H.264 H.261
>>> MUST: H.263 H.261; SHOULD: H.264
>>> MUST: H.263 H.261; SHOULD: H.264 Theora
>>> MUST: H.263 H.261 Theora; SHOULD: H.264
>>> SHOULD: H.264 VP8
>>> SHOULD: H.264 VP8 Theora
>>> MUST: Theora; SHOULD: H.264 VP8
>>> SHOULD: H.264 VP8 H.261
>>> SHOULD: H.264 VP8 H.261 Theora
>>> MUST: Theora; SHOULD: H.264 VP8 H.261
>>> MUST: H.261; SHOULD: H.264 VP8
>>> MUST: H.261; SHOULD: H.264 VP8 Theora
>>> MUST: H.261 Theora; SHOULD: H.264 VP8
>>> SHOULD: H.264 VP8 H.263
>>> SHOULD: H.264 VP8 H.263 Theora
>>> MUST: Theora; SHOULD: H.264 VP8 H.263
>>> SHOULD: H.264 VP8 H.263 H.261
>>> SHOULD: H.264 VP8 H.263 H.261 Theora
>>> MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
>>> MUST: H.261; SHOULD: H.264 VP8 H.263
>>> MUST: H.261; SHOULD: H.264 VP8 H.263 Theora
>>> MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
>>> MUST: H.263; SHOULD: H.264 VP8
>>> MUST: H.263; SHOULD: H.264 VP8 Theora
>>> MUST: H.263 Theora; SHOULD: H.264 VP8
>>> MUST: H.263; SHOULD: H.264 VP8 H.261
>>> MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
>>> MUST: H.263 Theora; SHOULD: H.264 VP8 H.261
>>> MUST: H.263 H.261; SHOULD: H.264 VP8
>>> MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
>>> MUST: H.263 H.261 Theora; SHOULD: H.264 VP8
>>> MUST: VP8; SHOULD: H.264
>>> MUST: VP8; SHOULD: H.264 Theora
>>> MUST: VP8 Theora; SHOULD: H.264
>>> MUST: VP8; SHOULD: H.264 H.261
>>> MUST: VP8; SHOULD: H.264 H.261 Theora
>>> MUST: VP8 Theora; SHOULD: H.264 H.261
>>> MUST: VP8 H.261; SHOULD: H.264
>>> MUST: VP8 H.261; SHOULD: H.264 Theora
>>> MUST: VP8 H.261 Theora; SHOULD: H.264
>>> MUST: VP8; SHOULD: H.264 H.263
>>> MUST: VP8; SHOULD: H.264 H.263 Theora
>>> MUST: VP8 Theora; SHOULD: H.264 H.263
>>> MUST: VP8; SHOULD: H.264 H.263 H.261
>>> MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
>>> MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
>>> MUST: VP8 H.261; SHOULD: H.264 H.263
>>> MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
>>> MUST: VP8 H.261 Theora; SHOULD: H.264 H.263
>>> MUST: VP8 H.263; SHOULD: H.264
>>> MUST: VP8 H.263; SHOULD: H.264 Theora
>>> MUST: VP8 H.263 Theora; SHOULD: H.264
>>> MUST: VP8 H.263; SHOULD: H.264 H.261
>>> MUST: VP8 H.263; SHOULD: H.264 H.261 Theora
>>> MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
>>> MUST: VP8 H.263 H.261; SHOULD: H.264
>>> MUST: VP8 H.263 H.261; SHOULD: H.264 Theora
>>> MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
>>> MUST: H.264
>>> MUST: H.264; SHOULD: Theora
>>> MUST: H.264 Theora
>>> MUST: H.264; SHOULD: H.261
>>> MUST: H.264; SHOULD: H.261 Theora
>>> MUST: H.264 Theora; SHOULD: H.261
>>> MUST: H.264 H.261
>>> MUST: H.264 H.261; SHOULD: Theora
>>> MUST: H.264 H.261 Theora
>>> MUST: H.264; SHOULD: H.263
>>> MUST: H.264; SHOULD: H.263 Theora
>>> MUST: H.264 Theora; SHOULD: H.263
>>> MUST: H.264; SHOULD: H.263 H.261
>>> MUST: H.264; SHOULD: H.263 H.261 Theora
>>> MUST: H.264 Theora; SHOULD: H.263 H.261
>>> MUST: H.264 H.261; SHOULD: H.263
>>> MUST: H.264 H.261; SHOULD: H.263 Theora
>>> MUST: H.264 H.261 Theora; SHOULD: H.263
>>> MUST: H.264 H.263
>>> MUST: H.264 H.263; SHOULD: Theora
>>> MUST: H.264 H.263 Theora
>>> MUST: H.264 H.263; SHOULD: H.261
>>> MUST: H.264 H.263; SHOULD: H.261 Theora
>>> MUST: H.264 H.263 Theora; SHOULD: H.261
>>> MUST: H.264 H.263 H.261
>>> MUST: H.264 H.263 H.261; SHOULD: Theora
>>> MUST: H.264 H.263 H.261 Theora
>>> MUST: H.264; SHOULD: VP8
>>> MUST: H.264; SHOULD: VP8 Theora
>>> MUST: H.264 Theora; SHOULD: VP8
>>> MUST: H.264; SHOULD: VP8 H.261
>>> MUST: H.264; SHOULD: VP8 H.261 Theora
>>> MUST: H.264 Theora; SHOULD: VP8 H.261
>>> MUST: H.264 H.261; SHOULD: VP8
>>> MUST: H.264 H.261; SHOULD: VP8 Theora
>>> MUST: H.264 H.261 Theora; SHOULD: VP8
>>> MUST: H.264; SHOULD: VP8 H.263
>>> MUST: H.264; SHOULD: VP8 H.263 Theora
>>> MUST: H.264 Theora; SHOULD: VP8 H.263
>>> MUST: H.264; SHOULD: VP8 H.263 H.261
>>> MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
>>> MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
>>> MUST: H.264 H.261; SHOULD: VP8 H.263
>>> MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
>>> MUST: H.264 H.261 Theora; SHOULD: VP8 H.263
>>> MUST: H.264 H.263; SHOULD: VP8
>>> MUST: H.264 H.263; SHOULD: VP8 Theora
>>> MUST: H.264 H.263 Theora; SHOULD: VP8
>>> MUST: H.264 H.263; SHOULD: VP8 H.261
>>> MUST: H.264 H.263; SHOULD: VP8 H.261 Theora
>>> MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
>>> MUST: H.264 H.263 H.261; SHOULD: VP8
>>> MUST: H.264 H.263 H.261; SHOULD: VP8 Theora
>>> MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
>>> MUST: H.264 VP8
>>> MUST: H.264 VP8; SHOULD: Theora
>>> MUST: H.264 VP8 Theora
>>> MUST: H.264 VP8; SHOULD: H.261
>>> MUST: H.264 VP8; SHOULD: H.261 Theora
>>> MUST: H.264 VP8 Theora; SHOULD: H.261
>>> MUST: H.264 VP8 H.261
>>> MUST: H.264 VP8 H.261; SHOULD: Theora
>>> MUST: H.264 VP8 H.261 Theora
>>> MUST: H.264 VP8; SHOULD: H.263
>>> MUST: H.264 VP8; SHOULD: H.263 Theora
>>> MUST: H.264 VP8 Theora; SHOULD: H.263
>>> MUST: H.264 VP8; SHOULD: H.263 H.261
>>> MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
>>> MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
>>> MUST: H.264 VP8 H.261; SHOULD: H.263
>>> MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
>>> MUST: H.264 VP8 H.261 Theora; SHOULD: H.263
>>> MUST: H.264 VP8 H.263
>>> MUST: H.264 VP8 H.263; SHOULD: Theora
>>> MUST: H.264 VP8 H.263 Theora
>>> MUST: H.264 VP8 H.263; SHOULD: H.261
>>> MUST: H.264 VP8 H.263; SHOULD: H.261 Theora
>>> MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
>>> MUST: H.264 VP8 H.263 H.261
>>> MUST: H.264 VP8 H.263 H.261; SHOULD: Theora
>>> MUST: H.264 VP8 H.263 H.261 Theora
>>> SHOULD do 1 of {H.261, Theora}
>>> SHOULD do 1 of {H.263, Theora}
>>> SHOULD do 1 of {H.263, H.261}
>>> SHOULD do 1 of {H.263, H.261, Theora}
>>> SHOULD do 2 of {H.263, H.261, Theora}
>>> SHOULD do 1 of {VP8, Theora}
>>> SHOULD do 1 of {VP8, H.261}
>>> SHOULD do 1 of {VP8, H.261, Theora}
>>> SHOULD do 2 of {VP8, H.261, Theora}
>>> SHOULD do 1 of {VP8, H.263}
>>> SHOULD do 1 of {VP8, H.263, Theora}
>>> SHOULD do 2 of {VP8, H.263, Theora}
>>> SHOULD do 1 of {VP8, H.263, H.261}
>>> SHOULD do 2 of {VP8, H.263, H.261}
>>> SHOULD do 1 of {VP8, H.263, H.261, Theora}
>>> SHOULD do 2 of {VP8, H.263, H.261, Theora}
>>> SHOULD do 3 of {VP8, H.263, H.261, Theora}
>>> SHOULD do 1 of {H.264, Theora}
>>> SHOULD do 1 of {H.264, H.261}
>>> SHOULD do 1 of {H.264, H.261, Theora}
>>> SHOULD do 2 of {H.264, H.261, Theora}
>>> SHOULD do 1 of {H.264, H.263}
>>> SHOULD do 1 of {H.264, H.263, Theora}
>>> SHOULD do 2 of {H.264, H.263, Theora}
>>> SHOULD do 1 of {H.264, H.263, H.261}
>>> SHOULD do 2 of {H.264, H.263, H.261}
>>> SHOULD do 1 of {H.264, H.263, H.261, Theora}
>>> SHOULD do 2 of {H.264, H.263, H.261, Theora}
>>> SHOULD do 3 of {H.264, H.263, H.261, Theora}
>>> SHOULD do 1 of {H.264, VP8}
>>> SHOULD do 1 of {H.264, VP8, Theora}
>>> SHOULD do 2 of {H.264, VP8, Theora}
>>> SHOULD do 1 of {H.264, VP8, H.261}
>>> SHOULD do 2 of {H.264, VP8, H.261}
>>> SHOULD do 1 of {H.264, VP8, H.261, Theora}
>>> SHOULD do 2 of {H.264, VP8, H.261, Theora}
>>> SHOULD do 3 of {H.264, VP8, H.261, Theora}
>>> SHOULD do 1 of {H.264, VP8, H.263}
>>> SHOULD do 2 of {H.264, VP8, H.263}
>>> SHOULD do 1 of {H.264, VP8, H.263, Theora}
>>> SHOULD do 2 of {H.264, VP8, H.263, Theora}
>>> SHOULD do 3 of {H.264, VP8, H.263, Theora}
>>> SHOULD do 1 of {H.264, VP8, H.263, H.261}
>>> SHOULD do 2 of {H.264, VP8, H.263, H.261}
>>> SHOULD do 3 of {H.264, VP8, H.263, H.261}
>>> SHOULD do 1 of {H.264, VP8, H.263, H.261, Theora}
>>> SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
>>> SHOULD do 3 of {H.264, VP8, H.263, H.261, Theora}
>>> SHOULD do 4 of {H.264, VP8, H.263, H.261, Theora}
>>> MUST do 1 of {H.261, Theora}
>>> MUST do 1 of {H.263, Theora}
>>> MUST do 1 of {H.263, H.261}
>>> MUST do 1 of {H.263, H.261, Theora}
>>> MUST do 2 of {H.263, H.261, Theora}
>>> MUST do 1 of {VP8, Theora}
>>> MUST do 1 of {VP8, H.261}
>>> MUST do 1 of {VP8, H.261, Theora}
>>> MUST do 2 of {VP8, H.261, Theora}
>>> MUST do 1 of {VP8, H.263}
>>> MUST do 1 of {VP8, H.263, Theora}
>>> MUST do 2 of {VP8, H.263, Theora}
>>> MUST do 1 of {VP8, H.263, H.261}
>>> MUST do 2 of {VP8, H.263, H.261}
>>> MUST do 1 of {VP8, H.263, H.261, Theora}
>>> MUST do 2 of {VP8, H.263, H.261, Theora}
>>> MUST do 3 of {VP8, H.263, H.261, Theora}
>>> MUST do 1 of {H.264, Theora}
>>> MUST do 1 of {H.264, H.261}
>>> MUST do 1 of {H.264, H.261, Theora}
>>> MUST do 2 of {H.264, H.261, Theora}
>>> MUST do 1 of {H.264, H.263}
>>> MUST do 1 of {H.264, H.263, Theora}
>>> MUST do 2 of {H.264, H.263, Theora}
>>> MUST do 1 of {H.264, H.263, H.261}
>>> MUST do 2 of {H.264, H.263, H.261}
>>> MUST do 1 of {H.264, H.263, H.261, Theora}
>>> MUST do 2 of {H.264, H.263, H.261, Theora}
>>> MUST do 3 of {H.264, H.263, H.261, Theora}
>>> MUST do 1 of {H.264, VP8}
>>> MUST do 1 of {H.264, VP8, Theora}
>>> MUST do 2 of {H.264, VP8, Theora}
>>> MUST do 1 of {H.264, VP8, H.261}
>>> MUST do 2 of {H.264, VP8, H.261}
>>> MUST do 1 of {H.264, VP8, H.261, Theora}
>>> MUST do 2 of {H.264, VP8, H.261, Theora}
>>> MUST do 3 of {H.264, VP8, H.261, Theora}
>>> MUST do 1 of {H.264, VP8, H.263}
>>> MUST do 2 of {H.264, VP8, H.263}
>>> MUST do 1 of {H.264, VP8, H.263, Theora}
>>> MUST do 2 of {H.264, VP8, H.263, Theora}
>>> MUST do 3 of {H.264, VP8, H.263, Theora}
>>> MUST do 1 of {H.264, VP8, H.263, H.261}
>>> MUST do 2 of {H.264, VP8, H.263, H.261}
>>> MUST do 3 of {H.264, VP8, H.263, H.261}
>>> MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
>>> MUST do 2 of {H.264, VP8, H.263, H.261, Theora}
>>> MUST do 3 of {H.264, VP8, H.263, H.261, Theora}
>>> MUST do 4 of {H.264, VP8, H.263, H.261, Theora}
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Nov 21, 2013 at 11:27 AM, Cullen Jennings  wrote=
:
>>>>
>>>>
>>>> Added a
>>>>
>>>> #11     =95 MUST implement at least two of {VP8, H.264 CBP, H.263}
>>>>
>>>>
>>>> On Nov 21, 2013, at 11:20 AM, David Singer  wrote:
>>>>
>>>> > Chairs
>>>> >
>>>> > can we add this as an option to the formal list, so we get formal
feedback on its acceptability, please?
>>>> >
>>>> > =93Like option ??, pick at least two of {VP8, H.264 CBP, H.263}=94
>>>> >
>>>> >
>>>> > I think this may be the best (maybe only) way to tease out how much
risk people perceive.
>>>> >
>>>> > Many thanks
>>>> >
>>>> > On Nov 21, 2013, at 9:22 , Maik Merten 
wrote:
>>>> >
>>>> >> Cleary H.263 is preferable from an engineering standpoint (as is,
e.g., MPEG-1 Part 2): better performance, more deployments. The central
question is, however, if those can actually be implemented without some
sort of licensing.
>>>> >>
>>>> >> If they can: Aweseome! However, this may not be determinable
without a review by people who are knowledgeable in the field of IPR, i.e.,
"actual lawyers". I understand that H.263 is not yet old enough to
automatically be considered "safe" (and neither is MPEG-1 Part 2, although
it is closer).
>>>> >>
>>>> >> Best regards,
>>>> >>
>>>> >> Maik
>>>> >>
>>>> >> Am 20.11.2013 20:42, schrieb David Singer:
>>>> >>> I think we should think hard about H.263 instead of H.261 as the
third fallback.  Why?
>>>> >>>
>>>> >>> http://www.itu.int/rec/T-REC-H.263/
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> H.263 was first published in March 1996, so it's 17 years old.
 The restrictions (e.g. on picture size) are no WORSE than H.261.  Yes,
more recent amendments deal with this (and a plethora of other issues), so
we=92d need to settle on which of those are mandatory (the usual profiling
discussion).
>>>> >>>
>>>> >>> There are 34 records in the patent database against H.261, mostly
from 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2
(reciprocity), as was one other I checked.
>>>> >>>
>>>> >>> Rather surprisingly, there are only 31 against H.263!  The most
recent is 2011, and is also option 2.  Most are 1997-2001.
>>>> >>>
>>>> >>>
>>>> >>> On this quick glance, H.263 appears no worse than H.261. IANAL (as
I am sure you have all noticed).
>>>> >>>
>>>> >>>
>>>> >>> H.263 is much more widely supported and mandated.  It has been
mandated in the 3GPP specs for years (for lots of services, including
videoconf), and is effectively the fallback codec today in the industry, as
I understand.  It was ubiquitous in video telephony for years, and I
suspect many of those systems still ship it.
>>>> >>>
>>>> >>> So, would =93MUST implement at least two of (H.264, VP8, H.263)=94
work?
>>>> >>>
>>>> >>> (I am asking the question, not even answering on behalf of my
company, yet.  Let=92s get the issues on the table.)
>>>> >>>
>>>> >>>
>>>> >>> David Singer
>>>> >>> Multimedia and Software Standards, Apple Inc.
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> 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
>>>> >
>>>> > David Singer
>>>> > Multimedia and Software Standards, Apple Inc.
>>>> >
>>>> > _______________________________________________
>>>> > 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
>

--001a11c3533a3952dc04ebbb6bc2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



    
On Nov 21, 2013 12:18 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:
    
>
    
>
    
>
    
>
    
> On Thu, Nov 21, 2013 at 12:14 PM, Steve Kann <stevek@stevek.com> wrote:
    
>>
    
>>
    
>> Do you plan to open-source your codec option generator? =A0 It wou=
ld make modifying the list much more efficient.
    
>
    
>
    
> =A0
    
> I was thinking of distributing it as a binary module you could link in=
to your
    
> mail client.
    
>
    
> -Ekr
    
>
    

    That sounds real good. Promise not to fork my private corres=
pondence or meta data to the NSA? 
    

    >>
    
>>
    
>>
    
>>
    
>> -Sent from an=A0iOS mobile device
    
>>
    
>> On Nov 21, 2013, at 12:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:
    
>>
    
>>> I would like to propose some additional alternatives.
    
>>>
    
>>> SHOULD: Theora
    
>>> MUST: Theora
    
>>> SHOULD: H.261
    
>>> SHOULD: H.261 Theora
    
>>> MUST: Theora; SHOULD: H.261
    
>>> MUST: H.261
    
>>> MUST: H.261; SHOULD: Theora
    
>>> MUST: H.261 Theora
    
>>> SHOULD: H.263
    
>>> SHOULD: H.263 Theora
    
>>> MUST: Theora; SHOULD: H.263
    
>>> SHOULD: H.263 H.261
    
>>> SHOULD: H.263 H.261 Theora
    
>>> MUST: Theora; SHOULD: H.263 H.261
    
>>> MUST: H.261; SHOULD: H.263
    
>>> MUST: H.261; SHOULD: H.263 Theora
    
>>> MUST: H.261 Theora; SHOULD: H.263
    
>>> MUST: H.263
    
>>> MUST: H.263; SHOULD: Theora
    
>>> MUST: H.263 Theora
    
>>> MUST: H.263; SHOULD: H.261
    
>>> MUST: H.263; SHOULD: H.261 Theora
    
>>> MUST: H.263 Theora; SHOULD: H.261
    
>>> MUST: H.263 H.261
    
>>> MUST: H.263 H.261; SHOULD: Theora
    
>>> MUST: H.263 H.261 Theora
    
>>> SHOULD: VP8
    
>>> SHOULD: VP8 Theora
    
>>> MUST: Theora; SHOULD: VP8
    
>>> SHOULD: VP8 H.261
    
>>> SHOULD: VP8 H.261 Theora
    
>>> MUST: Theora; SHOULD: VP8 H.261
    
>>> MUST: H.261; SHOULD: VP8
    
>>> MUST: H.261; SHOULD: VP8 Theora
    
>>> MUST: H.261 Theora; SHOULD: VP8
    
>>> SHOULD: VP8 H.263
    
>>> SHOULD: VP8 H.263 Theora
    
>>> MUST: Theora; SHOULD: VP8 H.263
    
>>> SHOULD: VP8 H.263 H.261
    
>>> SHOULD: VP8 H.263 H.261 Theora
    
>>> MUST: Theora; SHOULD: VP8 H.263 H.261
    
>>> MUST: H.261; SHOULD: VP8 H.263
    
>>> MUST: H.261; SHOULD: VP8 H.263 Theora
    
>>> MUST: H.261 Theora; SHOULD: VP8 H.263
    
>>> MUST: H.263; SHOULD: VP8
    
>>> MUST: H.263; SHOULD: VP8 Theora
    
>>> MUST: H.263 Theora; SHOULD: VP8
    
>>> MUST: H.263; SHOULD: VP8 H.261
    
>>> MUST: H.263; SHOULD: VP8 H.261 Theora
    
>>> MUST: H.263 Theora; SHOULD: VP8 H.261
    
>>> MUST: H.263 H.261; SHOULD: VP8
    
>>> MUST: H.263 H.261; SHOULD: VP8 Theora
    
>>> MUST: H.263 H.261 Theora; SHOULD: VP8
    
>>> MUST: VP8
    
>>> MUST: VP8; SHOULD: Theora
    
>>> MUST: VP8 Theora
    
>>> MUST: VP8; SHOULD: H.261
    
>>> MUST: VP8; SHOULD: H.261 Theora
    
>>> MUST: VP8 Theora; SHOULD: H.261
    
>>> MUST: VP8 H.261
    
>>> MUST: VP8 H.261; SHOULD: Theora
    
>>> MUST: VP8 H.261 Theora
    
>>> MUST: VP8; SHOULD: H.263
    
>>> MUST: VP8; SHOULD: H.263 Theora
    
>>> MUST: VP8 Theora; SHOULD: H.263
    
>>> MUST: VP8; SHOULD: H.263 H.261
    
>>> MUST: VP8; SHOULD: H.263 H.261 Theora
    
>>> MUST: VP8 Theora; SHOULD: H.263 H.261
    
>>> MUST: VP8 H.261; SHOULD: H.263
    
>>> MUST: VP8 H.261; SHOULD: H.263 Theora
    
>>> MUST: VP8 H.261 Theora; SHOULD: H.263
    
>>> MUST: VP8 H.263
    
>>> MUST: VP8 H.263; SHOULD: Theora
    
>>> MUST: VP8 H.263 Theora
    
>>> MUST: VP8 H.263; SHOULD: H.261
    
>>> MUST: VP8 H.263; SHOULD: H.261 Theora
    
>>> MUST: VP8 H.263 Theora; SHOULD: H.261
    
>>> MUST: VP8 H.263 H.261
    
>>> MUST: VP8 H.263 H.261; SHOULD: Theora
    
>>> MUST: VP8 H.263 H.261 Theora
    
>>> SHOULD: H.264
    
>>> SHOULD: H.264 Theora
    
>>> MUST: Theora; SHOULD: H.264
    
>>> SHOULD: H.264 H.261
    
>>> SHOULD: H.264 H.261 Theora
    
>>> MUST: Theora; SHOULD: H.264 H.261
    
>>> MUST: H.261; SHOULD: H.264
    
>>> MUST: H.261; SHOULD: H.264 Theora
    
>>> MUST: H.261 Theora; SHOULD: H.264
    
>>> SHOULD: H.264 H.263
    
>>> SHOULD: H.264 H.263 Theora
    
>>> MUST: Theora; SHOULD: H.264 H.263
    
>>> SHOULD: H.264 H.263 H.261
    
>>> SHOULD: H.264 H.263 H.261 Theora
    
>>> MUST: Theora; SHOULD: H.264 H.263 H.261
    
>>> MUST: H.261; SHOULD: H.264 H.263
    
>>> MUST: H.261; SHOULD: H.264 H.263 Theora
    
>>> MUST: H.261 Theora; SHOULD: H.264 H.263
    
>>> MUST: H.263; SHOULD: H.264
    
>>> MUST: H.263; SHOULD: H.264 Theora
    
>>> MUST: H.263 Theora; SHOULD: H.264
    
>>> MUST: H.263; SHOULD: H.264 H.261
    
>>> MUST: H.263; SHOULD: H.264 H.261 Theora
    
>>> MUST: H.263 Theora; SHOULD: H.264 H.261
    
>>> MUST: H.263 H.261; SHOULD: H.264
    
>>> MUST: H.263 H.261; SHOULD: H.264 Theora
    
>>> MUST: H.263 H.261 Theora; SHOULD: H.264
    
>>> SHOULD: H.264 VP8
    
>>> SHOULD: H.264 VP8 Theora
    
>>> MUST: Theora; SHOULD: H.264 VP8
    
>>> SHOULD: H.264 VP8 H.261
    
>>> SHOULD: H.264 VP8 H.261 Theora
    
>>> MUST: Theora; SHOULD: H.264 VP8 H.261
    
>>> MUST: H.261; SHOULD: H.264 VP8
    
>>> MUST: H.261; SHOULD: H.264 VP8 Theora
    
>>> MUST: H.261 Theora; SHOULD: H.264 VP8
    
>>> SHOULD: H.264 VP8 H.263
    
>>> SHOULD: H.264 VP8 H.263 Theora
    
>>> MUST: Theora; SHOULD: H.264 VP8 H.263
    
>>> SHOULD: H.264 VP8 H.263 H.261
    
>>> SHOULD: H.264 VP8 H.263 H.261 Theora
    
>>> MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
    
>>> MUST: H.261; SHOULD: H.264 VP8 H.263
    
>>> MUST: H.261; SHOULD: H.264 VP8 H.263 Theora
    
>>> MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
    
>>> MUST: H.263; SHOULD: H.264 VP8
    
>>> MUST: H.263; SHOULD: H.264 VP8 Theora
    
>>> MUST: H.263 Theora; SHOULD: H.264 VP8
    
>>> MUST: H.263; SHOULD: H.264 VP8 H.261
    
>>> MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
    
>>> MUST: H.263 Theora; SHOULD: H.264 VP8 H.261
    
>>> MUST: H.263 H.261; SHOULD: H.264 VP8
    
>>> MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
    
>>> MUST: H.263 H.261 Theora; SHOULD: H.264 VP8
    
>>> MUST: VP8; SHOULD: H.264
    
>>> MUST: VP8; SHOULD: H.264 Theora
    
>>> MUST: VP8 Theora; SHOULD: H.264
    
>>> MUST: VP8; SHOULD: H.264 H.261
    
>>> MUST: VP8; SHOULD: H.264 H.261 Theora
    
>>> MUST: VP8 Theora; SHOULD: H.264 H.261
    
>>> MUST: VP8 H.261; SHOULD: H.264
    
>>> MUST: VP8 H.261; SHOULD: H.264 Theora
    
>>> MUST: VP8 H.261 Theora; SHOULD: H.264
    
>>> MUST: VP8; SHOULD: H.264 H.263
    
>>> MUST: VP8; SHOULD: H.264 H.263 Theora
    
>>> MUST: VP8 Theora; SHOULD: H.264 H.263
    
>>> MUST: VP8; SHOULD: H.264 H.263 H.261
    
>>> MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
    
>>> MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
    
>>> MUST: VP8 H.261; SHOULD: H.264 H.263
    
>>> MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
    
>>> MUST: VP8 H.261 Theora; SHOULD: H.264 H.263
    
>>> MUST: VP8 H.263; SHOULD: H.264
    
>>> MUST: VP8 H.263; SHOULD: H.264 Theora
    
>>> MUST: VP8 H.263 Theora; SHOULD: H.264
    
>>> MUST: VP8 H.263; SHOULD: H.264 H.261
    
>>> MUST: VP8 H.263; SHOULD: H.264 H.261 Theora
    
>>> MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
    
>>> MUST: VP8 H.263 H.261; SHOULD: H.264
    
>>> MUST: VP8 H.263 H.261; SHOULD: H.264 Theora
    
>>> MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
    
>>> MUST: H.264
    
>>> MUST: H.264; SHOULD: Theora
    
>>> MUST: H.264 Theora
    
>>> MUST: H.264; SHOULD: H.261
    
>>> MUST: H.264; SHOULD: H.261 Theora
    
>>> MUST: H.264 Theora; SHOULD: H.261
    
>>> MUST: H.264 H.261
    
>>> MUST: H.264 H.261; SHOULD: Theora
    
>>> MUST: H.264 H.261 Theora
    
>>> MUST: H.264; SHOULD: H.263
    
>>> MUST: H.264; SHOULD: H.263 Theora
    
>>> MUST: H.264 Theora; SHOULD: H.263
    
>>> MUST: H.264; SHOULD: H.263 H.261
    
>>> MUST: H.264; SHOULD: H.263 H.261 Theora
    
>>> MUST: H.264 Theora; SHOULD: H.263 H.261
    
>>> MUST: H.264 H.261; SHOULD: H.263
    
>>> MUST: H.264 H.261; SHOULD: H.263 Theora
    
>>> MUST: H.264 H.261 Theora; SHOULD: H.263
    
>>> MUST: H.264 H.263
    
>>> MUST: H.264 H.263; SHOULD: Theora
    
>>> MUST: H.264 H.263 Theora
    
>>> MUST: H.264 H.263; SHOULD: H.261
    
>>> MUST: H.264 H.263; SHOULD: H.261 Theora
    
>>> MUST: H.264 H.263 Theora; SHOULD: H.261
    
>>> MUST: H.264 H.263 H.261
    
>>> MUST: H.264 H.263 H.261; SHOULD: Theora
    
>>> MUST: H.264 H.263 H.261 Theora
    
>>> MUST: H.264; SHOULD: VP8
    
>>> MUST: H.264; SHOULD: VP8 Theora
    
>>> MUST: H.264 Theora; SHOULD: VP8
    
>>> MUST: H.264; SHOULD: VP8 H.261
    
>>> MUST: H.264; SHOULD: VP8 H.261 Theora
    
>>> MUST: H.264 Theora; SHOULD: VP8 H.261
    
>>> MUST: H.264 H.261; SHOULD: VP8
    
>>> MUST: H.264 H.261; SHOULD: VP8 Theora
    
>>> MUST: H.264 H.261 Theora; SHOULD: VP8
    
>>> MUST: H.264; SHOULD: VP8 H.263
    
>>> MUST: H.264; SHOULD: VP8 H.263 Theora
    
>>> MUST: H.264 Theora; SHOULD: VP8 H.263
    
>>> MUST: H.264; SHOULD: VP8 H.263 H.261
    
>>> MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
    
>>> MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
    
>>> MUST: H.264 H.261; SHOULD: VP8 H.263
    
>>> MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
    
>>> MUST: H.264 H.261 Theora; SHOULD: VP8 H.263
    
>>> MUST: H.264 H.263; SHOULD: VP8
    
>>> MUST: H.264 H.263; SHOULD: VP8 Theora
    
>>> MUST: H.264 H.263 Theora; SHOULD: VP8
    
>>> MUST: H.264 H.263; SHOULD: VP8 H.261
    
>>> MUST: H.264 H.263; SHOULD: VP8 H.261 Theora
    
>>> MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
    
>>> MUST: H.264 H.263 H.261; SHOULD: VP8
    
>>> MUST: H.264 H.263 H.261; SHOULD: VP8 Theora
    
>>> MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
    
>>> MUST: H.264 VP8
    
>>> MUST: H.264 VP8; SHOULD: Theora
    
>>> MUST: H.264 VP8 Theora
    
>>> MUST: H.264 VP8; SHOULD: H.261
    
>>> MUST: H.264 VP8; SHOULD: H.261 Theora
    
>>> MUST: H.264 VP8 Theora; SHOULD: H.261
    
>>> MUST: H.264 VP8 H.261
    
>>> MUST: H.264 VP8 H.261; SHOULD: Theora
    
>>> MUST: H.264 VP8 H.261 Theora
    
>>> MUST: H.264 VP8; SHOULD: H.263
    
>>> MUST: H.264 VP8; SHOULD: H.263 Theora
    
>>> MUST: H.264 VP8 Theora; SHOULD: H.263
    
>>> MUST: H.264 VP8; SHOULD: H.263 H.261
    
>>> MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
    
>>> MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
    
>>> MUST: H.264 VP8 H.261; SHOULD: H.263
    
>>> MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
    
>>> MUST: H.264 VP8 H.261 Theora; SHOULD: H.263
    
>>> MUST: H.264 VP8 H.263
    
>>> MUST: H.264 VP8 H.263; SHOULD: Theora
    
>>> MUST: H.264 VP8 H.263 Theora
    
>>> MUST: H.264 VP8 H.263; SHOULD: H.261
    
>>> MUST: H.264 VP8 H.263; SHOULD: H.261 Theora
    
>>> MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
    
>>> MUST: H.264 VP8 H.263 H.261
    
>>> MUST: H.264 VP8 H.263 H.261; SHOULD: Theora
    
>>> MUST: H.264 VP8 H.263 H.261 Theora
    
>>> SHOULD do 1 of {H.261, Theora}
    
>>> SHOULD do 1 of {H.263, Theora}
    
>>> SHOULD do 1 of {H.263, H.261}
    
>>> SHOULD do 1 of {H.263, H.261, Theora}
    
>>> SHOULD do 2 of {H.263, H.261, Theora}
    
>>> SHOULD do 1 of {VP8, Theora}
    
>>> SHOULD do 1 of {VP8, H.261}
    
>>> SHOULD do 1 of {VP8, H.261, Theora}
    
>>> SHOULD do 2 of {VP8, H.261, Theora}
    
>>> SHOULD do 1 of {VP8, H.263}
    
>>> SHOULD do 1 of {VP8, H.263, Theora}
    
>>> SHOULD do 2 of {VP8, H.263, Theora}
    
>>> SHOULD do 1 of {VP8, H.263, H.261}
    
>>> SHOULD do 2 of {VP8, H.263, H.261}
    
>>> SHOULD do 1 of {VP8, H.263, H.261, Theora}
    
>>> SHOULD do 2 of {VP8, H.263, H.261, Theora}
    
>>> SHOULD do 3 of {VP8, H.263, H.261, Theora}
    
>>> SHOULD do 1 of {H.264, Theora}
    
>>> SHOULD do 1 of {H.264, H.261}
    
>>> SHOULD do 1 of {H.264, H.261, Theora}
    
>>> SHOULD do 2 of {H.264, H.261, Theora}
    
>>> SHOULD do 1 of {H.264, H.263}
    
>>> SHOULD do 1 of {H.264, H.263, Theora}
    
>>> SHOULD do 2 of {H.264, H.263, Theora}
    
>>> SHOULD do 1 of {H.264, H.263, H.261}
    
>>> SHOULD do 2 of {H.264, H.263, H.261}
    
>>> SHOULD do 1 of {H.264, H.263, H.261, Theora}
    
>>> SHOULD do 2 of {H.264, H.263, H.261, Theora}
    
>>> SHOULD do 3 of {H.264, H.263, H.261, Theora}
    
>>> SHOULD do 1 of {H.264, VP8}
    
>>> SHOULD do 1 of {H.264, VP8, Theora}
    
>>> SHOULD do 2 of {H.264, VP8, Theora}
    
>>> SHOULD do 1 of {H.264, VP8, H.261}
    
>>> SHOULD do 2 of {H.264, VP8, H.261}
    
>>> SHOULD do 1 of {H.264, VP8, H.261, Theora}
    
>>> SHOULD do 2 of {H.264, VP8, H.261, Theora}
    
>>> SHOULD do 3 of {H.264, VP8, H.261, Theora}
    
>>> SHOULD do 1 of {H.264, VP8, H.263}
    
>>> SHOULD do 2 of {H.264, VP8, H.263}
    
>>> SHOULD do 1 of {H.264, VP8, H.263, Theora}
    
>>> SHOULD do 2 of {H.264, VP8, H.263, Theora}
    
>>> SHOULD do 3 of {H.264, VP8, H.263, Theora}
    
>>> SHOULD do 1 of {H.264, VP8, H.263, H.261}
    
>>> SHOULD do 2 of {H.264, VP8, H.263, H.261}
    
>>> SHOULD do 3 of {H.264, VP8, H.263, H.261}
    
>>> SHOULD do 1 of {H.264, VP8, H.263, H.261, Theora}
    
>>> SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
    
>>> SHOULD do 3 of {H.264, VP8, H.263, H.261, Theora}
    
>>> SHOULD do 4 of {H.264, VP8, H.263, H.261, Theora}
    
>>> MUST do 1 of {H.261, Theora}
    
>>> MUST do 1 of {H.263, Theora}
    
>>> MUST do 1 of {H.263, H.261}
    
>>> MUST do 1 of {H.263, H.261, Theora}
    
>>> MUST do 2 of {H.263, H.261, Theora}
    
>>> MUST do 1 of {VP8, Theora}
    
>>> MUST do 1 of {VP8, H.261}
    
>>> MUST do 1 of {VP8, H.261, Theora}
    
>>> MUST do 2 of {VP8, H.261, Theora}
    
>>> MUST do 1 of {VP8, H.263}
    
>>> MUST do 1 of {VP8, H.263, Theora}
    
>>> MUST do 2 of {VP8, H.263, Theora}
    
>>> MUST do 1 of {VP8, H.263, H.261}
    
>>> MUST do 2 of {VP8, H.263, H.261}
    
>>> MUST do 1 of {VP8, H.263, H.261, Theora}
    
>>> MUST do 2 of {VP8, H.263, H.261, Theora}
    
>>> MUST do 3 of {VP8, H.263, H.261, Theora}
    
>>> MUST do 1 of {H.264, Theora}
    
>>> MUST do 1 of {H.264, H.261}
    
>>> MUST do 1 of {H.264, H.261, Theora}
    
>>> MUST do 2 of {H.264, H.261, Theora}
    
>>> MUST do 1 of {H.264, H.263}
    
>>> MUST do 1 of {H.264, H.263, Theora}
    
>>> MUST do 2 of {H.264, H.263, Theora}
    
>>> MUST do 1 of {H.264, H.263, H.261}
    
>>> MUST do 2 of {H.264, H.263, H.261}
    
>>> MUST do 1 of {H.264, H.263, H.261, Theora}
    
>>> MUST do 2 of {H.264, H.263, H.261, Theora}
    
>>> MUST do 3 of {H.264, H.263, H.261, Theora}
    
>>> MUST do 1 of {H.264, VP8}
    
>>> MUST do 1 of {H.264, VP8, Theora}
    
>>> MUST do 2 of {H.264, VP8, Theora}
    
>>> MUST do 1 of {H.264, VP8, H.261}
    
>>> MUST do 2 of {H.264, VP8, H.261}
    
>>> MUST do 1 of {H.264, VP8, H.261, Theora}
    
>>> MUST do 2 of {H.264, VP8, H.261, Theora}
    
>>> MUST do 3 of {H.264, VP8, H.261, Theora}
    
>>> MUST do 1 of {H.264, VP8, H.263}
    
>>> MUST do 2 of {H.264, VP8, H.263}
    
>>> MUST do 1 of {H.264, VP8, H.263, Theora}
    
>>> MUST do 2 of {H.264, VP8, H.263, Theora}
    
>>> MUST do 3 of {H.264, VP8, H.263, Theora}
    
>>> MUST do 1 of {H.264, VP8, H.263, H.261}
    
>>> MUST do 2 of {H.264, VP8, H.263, H.261}
    
>>> MUST do 3 of {H.264, VP8, H.263, H.261}
    
>>> MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
    
>>> MUST do 2 of {H.264, VP8, H.263, H.261, Theora}
    
>>> MUST do 3 of {H.264, VP8, H.263, H.261, Theora}
    
>>> MUST do 4 of {H.264, VP8, H.263, H.261, Theora}
    
>>>
    
>>>
    
>>>
    
>>>
    
>>>
    
>>>
    
>>>
    
>>> On Thu, Nov 21, 2013 at 11:27 AM, Cullen Jennings <fluffy@iii.ca> wrote:
    
>>>>
    
>>>>
    
>>>> Added a
    
>>>>
    
>>>> #11 =A0 =A0 =95 MUST implement at least two of {VP8, H.264=
 CBP, H.263}
    
>>>>
    
>>>>
    
>>>> On Nov 21, 2013, at 11:20 AM, David Singer <singer@apple.com> wrote:
    
>>>>
    
>>>> > Chairs
    
>>>> >
    
>>>> > can we add this as an option to the formal list, so w=
e get formal feedback on its acceptability, please?
    
>>>> >
    
>>>> > =93Like option ??, pick at least two of {VP8, H.264 C=
BP, H.263}=94
    
>>>> >
    
>>>> >
    
>>>> > I think this may be the best (maybe only) way to teas=
e out how much risk people perceive.
    
>>>> >
    
>>>> > Many thanks
    
>>>> >
    
>>>> > On Nov 21, 2013, at 9:22 , Maik Merten <maikmerten@googlemail.com> wrote:=

    
>>>> >
    
>>>> >> Cleary H.263 is preferable from an engineering st=
andpoint (as is, e.g., MPEG-1 Part 2): better performance, more deployments=
. The central question is, however, if those can actually be implemented wi=
thout some sort of licensing.
    

>>>> >>
    
>>>> >> If they can: Aweseome! However, this may not be d=
eterminable without a review by people who are knowledgeable in the field o=
f IPR, i.e., "actual lawyers". I understand that H.263 is not yet=
 old enough to automatically be considered "safe" (and neither is=
 MPEG-1 Part 2, although it is closer).
    

>>>> >>
    
>>>> >> Best regards,
    
>>>> >>
    
>>>> >> Maik
    
>>>> >>
    
>>>> >> Am 20.11.2013 20:42, schrieb David Singer:
    
>>>> >>> I think we should think hard about H.263 inst=
ead of H.261 as the third fallback. =A0Why?
    
>>>> >>>
    
>>>> >>> http://www.itu.int/rec/T-REC-H.263/
    
>>>> >>>
    
>>>> >>>
    
>>>> >>>
    
>>>> >>> H.263 was first published in March 1996, so i=
t's 17 years old. =A0The restrictions (e.g. on picture size) are no WOR=
SE than H.261. =A0Yes, more recent amendments deal with this (and a plethor=
a of other issues), so we=92d need to settle on which of those are mandator=
y (the usual profiling discussion).
    

>>>> >>>
    
>>>> >>> There are 34 records in the patent database a=
gainst H.261, mostly from 1989 but one as recent as 2005 (though that is a =
re-file). =A0That's 2.2 (reciprocity), as was one other I checked.
    

>>>> >>>
    
>>>> >>> Rather surprisingly, there are only 31 agains=
t H.263! =A0The most recent is 2011, and is also option 2. =A0Most are 1997=
-2001.
    
>>>> >>>
    
>>>> >>>
    
>>>> >>> On this quick glance, H.263 appears no worse =
than H.261. IANAL (as I am sure you have all noticed).
    
>>>> >>>
    
>>>> >>>
    
>>>> >>> H.263 is much more widely supported and manda=
ted. =A0It has been mandated in the 3GPP specs for years (for lots of servi=
ces, including videoconf), and is effectively the fallback codec today in t=
he industry, as I understand. =A0It was ubiquitous in video telephony for y=
ears, and I suspect many of those systems still ship it.
    

>>>> >>>
    
>>>> >>> So, would =93MUST implement at least two of (=
H.264, VP8, H.263)=94 work?
    
>>>> >>>
    
>>>> >>> (I am asking the question, not even answering=
 on behalf of my company, yet. =A0Let=92s get the issues on the table.)
    
>>>> >>>
    
>>>> >>>
    
>>>> >>> David Singer
    
>>>> >>> Multimedia and Software Standards, Apple Inc.=

    
>>>> >>>
    
>>>> >>> _____________________________________________=
__
    
>>>> >>> rtcweb mailing list
    
>>>> >>> rtcweb@iet=
f.org
    
>>>> >>> https://www.ietf.org/mailman/listinfo/rtcweb
    
>>>> >>>
    
>>>> >>
    
>>>> >> _______________________________________________
>>>> >> rtcweb mailing list
    
>>>> >> rtcweb@ietf.or=
g
    
>>>> >> https://www.ietf.org/mailman/listinfo/rtcweb
    
>>>> >
    
>>>> > David Singer
    
>>>> > Multimedia and Software Standards, Apple Inc.
    
>>>> >
    
>>>> > _______________________________________________
    
>>>> > rtcweb mailing list
    
>>>> > rtcweb@ietf.org
    
>>>> >     https://www.ietf.org/mailman/listinfo/rtcweb
    
>>>>
    
>>>> _______________________________________________
    
>>>> rtcweb mailing list
    
>>>> rtcweb@ietf.org
    
>>>> h=
ttps://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.i=
etf.org/mailman/listinfo/rtcweb
    
>
    

    

--001a11c3533a3952dc04ebbb6bc2--


From lijing80@huawei.com  Thu Nov 21 19:22:09 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32311AE30C for ; Thu, 21 Nov 2013 19:22:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.212
X-Spam-Level: 
X-Spam-Status: No, score=-3.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XsN5TL7VO_q for ; Thu, 21 Nov 2013 19:22:07 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B49A1AE2FF for ; Thu, 21 Nov 2013 19:22:07 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAO75696; Fri, 22 Nov 2013 03:21:59 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Nov 2013 03:21:25 +0000
Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Nov 2013 03:21:23 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.229]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Fri, 22 Nov 2013 11:21:16 +0800
From: "Lijing (Jessie)" 
To: Magnus Westerlund , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Proposal for API mapping for RTP
Thread-Index: AQHO2+cyVVFwmo7V50mHFGGHzQ8lvZowolNA
Date: Fri, 22 Nov 2013 03:21:15 +0000
Message-ID: 
References: <527BD94C.2070900@ericsson.com>
In-Reply-To: <527BD94C.2070900@ericsson.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.171.171]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [rtcweb] Proposal for API mapping for RTP
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 03:22:09 -0000

A MediaStream contains multiple MediaStreamTrack, and different MediaStream=
s can share the same MediaStreamTrack. MediaStreamTrack within one MediaStr=
eam is synchronized.

-----Does anywhere define how to describe same MST in different mediastream=
s in SDP? As I know, the current unified plan defines" One m-line =3D=3D on=
e MediaStreamTrack", so how can we mark multiple mediastreams in msid attri=
bute?
Allow msid carry more mediastream id?
m=3Dvideo1
a=3Dmsid: ma ta; mb ta

or have multiple msid attribute in one m line?
m=3Dvido1
a=3Dmsid: ma ta
a=3Dmsid: mb ta

or we should expand other attribute?=20


-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Magnus Westerlund
Sent: Friday, November 08, 2013 2:18 AM
To: rtcweb@ietf.org
Subject: [rtcweb] Proposal for API mapping for RTP

WG,
(As draft-ietf-rtcweb-rtp-usage Editor)

There was discussion yesterday afternoon on the W3C MediaStream to RTP mapp=
ing. This did arrive on some conclusions that I here try to word into a pro=
posal for everyones review.

A MediaStreamTrack is sent over a source packet stream (one SSRC) and can h=
ave additionally redundancy packet streams (SSRCs). These redundnacy stream=
s are RTP retranmission streams or FEC.

When multiple MediaStreamTracks have the same Media Source, then the fact t=
hat one has creaeted multiple MediaStreamTracks and added these through a M=
ediaStream to the PeerConnection is going to result in that each MediaStrea=
mTrack will have its own source packet stream (one SSRC).
This will be true, even if there are no difference in the configuration of =
the MediaStreamTrack. Thus no optimizations in regards to collapsing or agg=
regating multiple MediaStreamTrack onto a single source packet stream (SSRC=
). This is done for keeping things simple and straightforward.

When it comes to the use of CNAME, an RTCWEB end-point shall within the con=
text of one origin, i.e. a particular JS creating PeerConnections, use the =
same CNAME in all these PeerConnections, for all outgoing mediaStreamTracks=
. However, a end-point MUST be capable of receiving multiple different CNAM=
Es both within and between different RTP sessions and PeerConnections. This=
 definition comes from the following observations.

A MediaStream contains multiple MediaStreamTrack, and different MediaStream=
s can share the same MediaStreamTrack. MediaStreamTrack within one MediaStr=
eam is synchronized. Thus, at any point the JS application can create a new=
 MediaStream that includes MediaStreamTrack from different context. To avoi=
d needing to change all SSRC and put the SSRCs into a single CNAME at that =
point, we ensure that this can't happen.

MediaStreamTracks that are being received in one PeerConnection and then fo=
rward by being added to another one will need to be re-synchronzied into th=
e endpoints outgoing. We discussed and came to the agreement on Monday that=
 forwarding would need to be done equivalent of decoding and recoding when =
forwarding. Implementations may do other things, but must function equivale=
nt to this.

The above have some forward interoperability properties. If one like to be =
able to use multiple CNAMEs that can be added given that W3C API ensures th=
at you don't cause issue with what CNAME a particular SSRC belongs to. In a=
ddition if one like to optimize the cases where multiple MediaStreamTrack h=
ave a common media source that can be added.

Disagreements, requests for clarifications?


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
F=E4r=F6gatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

From sslivinski@lifesize.com  Thu Nov 21 21:12:46 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBBE1AE005 for ; Thu, 21 Nov 2013 21:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.624
X-Spam-Level: 
X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CAN_LONGER=4.824, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEF2rScTldZk for ; Thu, 21 Nov 2013 21:12:43 -0800 (PST)
Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with SMTP id DC3511ADFA0 for ; Thu, 21 Nov 2013 21:12:42 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKUo7nw9oQDjoUKyJOeBCHN84/hHUmeWC0@postini.com; Thu, 21 Nov 2013 21:12:36 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 23:07:29 -0600
From: Stefan Slivinski 
To: "rtcweb@ietf.org" 
Date: Thu, 21 Nov 2013 23:07:27 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7nKTQT2ldyNVUSS1+R3z4Of11duwAEM++w
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E6618@ausmsex00.austin.kmvtechnologies.com>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>  <528EBAB0.2010906@librevideo.org>  <528EBD4C.8070504@librevideo.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7949EED078736C4881C92F656DC6F6C130EA9E6618ausmsex00aust_"
MIME-Version: 1.0
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 05:12:46 -0000

--_000_7949EED078736C4881C92F656DC6F6C130EA9E6618ausmsex00aust_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlcmUgYXBwZWFycyB0byBiZSBzb21lIGNvbmZ1c2lvbiBhYm91dCBjb2RlYyBzcGVjaWZpYyBw
YXRlbnRzIGFuZCBnZW5lcmFsIHZpZGVvIGNvZGluZyBwYXRlbnRzIHNvIGxldCBtZSB0cnkgdG8g
Y2xhcmlmeToNCg0KQm90aCBILjI2NCBhbmQgVlA4IHNwZWNpZmljYXRpb24gZGVzY3JpYmUgdGhl
IERFQ09ERVIsIHNwZWNpZmljYWxseSB0aGUgZm9ybWF0IGFuZCBvcmRlciBvZiB0aGUgZGF0YSBp
biB0aGUgYml0c3RyZWFtLiAgV2hhdCBkb2VzIHRoYXQgbWVhbj8gIEl0IG1lYW5zIHRoYXQgZm9y
IGVhY2ggbWFjcm9ibG9jayB0aGVyZSB3aWxsIGJlIGluZm9ybWF0aW9uIGluZGljYXRpbmcgdGhl
IGJsb2NrIHR5cGUsIHRoZSBtb3Rpb24gdmVjdG9ycywgdGhlIHF1YW50aXplciwgdGhlIHJlc2lk
dWFsLCBldGMuICAgV2hhdCB0aGUgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBzYXkgaXMgSE9XIHlv
dSBkZWNpZGUgd2hhdCBibG9jayB0eXBlIHRvIHVzZSwgd2hhdCBtb3Rpb24gdmVjdG9yIHRvIHVz
ZSwgd2hhdCBxdWFudGl6ZXIgdG8gdXNlLCBldGMuDQoNCkEgbGljZW5zZSBmcm9tIG1wZWctbGEg
YW5kIHByZXN1bWFibHkgZnJvbSBnb29nbGUgd2lsbCBwcm90ZWN0IHlvdSB3aGVuIGltcGxlbWVu
dGluZyBhbnl0aGluZyBkZXNjcmliZWQgaW4gdGhlIGRlY29kZXIgc3BlY2lmaWNhdGlvbi4gIEl0
IHdpbGwgbm90IHByb3RlY3QgeW91IGZyb20gdGhlIEhPVy4gIFNvIGlmIHlvdSB0aGluayBvZiBh
IHJlYWxseSBzaW1wbGUgbW90aW9uIGVzdGltYXRlIGVuZ2luZSB3aGVyZSB5b3Ugc2VhcmNoIGV2
ZXJ5IHBvc3NpYmxlIGxvY2F0aW9uIGluIHRoZSByZWZlcmVuY2UgZnJhbWUgdG8gZmluZCB0aGUg
YmVzdCBtYXRjaCB1c2luZyBTQUQgYXMgYSBibG9jayBtYXRjaGluZyBhbGdvcml0aG3igKZndWVz
cyB3aGF0PyAgVGhlcmXigJlzIGEgcGF0ZW50IGZvciB0aGF0LiAgSWYgeW91IHRoZW4gZGVjaWRl
IHRoYXQgaWYgdGhlcmUgaXNu4oCZdCBhIHJlYWxseSBnb29kIG1hdGNoIChoaWdoIFNBRCksIGFu
ZCB5b3UgZGVjaWRlIHRvIGRvIGFuIGludHJhIHNlYXJjaCBpbnN0ZWFk4oCmZ3Vlc3Mgd2hhdD8g
IFRoZXJl4oCZcyBhIHBhdGVudCBmb3IgdGhhdC4gIFlvdXIgbXBlZy1sYSBsaWNlbnNlIChhbmQg
SeKAmW0gd2lsbGluZyB0byBiZXQgdnA4IGFsc28pIHdvbuKAmXQgcHJvdGVjdCB5b3UgaWYgeW91
IGhhcHBlbiB0byBpbmZyaW5nZSBvbiB0aG9zZS4NCg0KSeKAmW0gbm90IHRyeWluZyB0byBzY2Fy
ZSBldmVyeW9uZSBidXQgdG8gYXJndWUgdGhhdCBILjI2MSBpcyBzb21laG93IGdvaW5nIHRvIHBy
b3RlY3QgeW91IGZyb20gcGF0ZW50IGluZnJpbmdlbWVudCBpcyBjb21wbGV0ZWx5IHdpdGhvdXQg
bWVyaXQuDQoNClNvbWV0aGluZyBlbHNlIHRvIGtlZXAgaW4gbWluZCwgbWFueSBvZiB5b3UgYXJl
IGF3YXJlIHRoYXQgYXBwbGUgcmVjZW50bHkgbG9zdCBhIHBhdGVudCBpbmZyaW5nZW1lbnQgc3Vp
dCBmcm9tIFZpbWV0WCByZWdhcmRpbmcgcDJwIGNhbGxpbmcgd2l0aCBmYWNldGltZS4NCldoYXQg
dGhleSBhcmUgZG9pbmcgaXNu4oCZdCBhbGwgdG8gZGlmZmVyZW50IHRoYW4gYSBwMnAgdXNpbmcg
YSBzdHVuIHNlcnZlci4NCg0KTXkgcG9pbnQgaGVyZSBpcyB3ZSBzaG91bGQgYmUgZm9jdXNpbmcg
b24gY2hvb3NpbmcgdGhlIGJlc3QgdGVjaG5vbG9neSBhbmQgY29tZSB1cCB3aXRoIGEgc29sdXRp
b24gZm9yIGRlYWxpbmcgd2l0aCBwYXRlbnQgdHJvbGxzIGF0IHNvbWUgb3RoZXIgbGV2ZWwgYmVj
YXVzZSBpdOKAmXMgZ29pbmcgdG8gYmUgYSB3aWRlIHNwcmVhZCBjb25jZXJuLCBub3QganVzdCBh
IHZpZGVvIHByb2JsZW0uDQoNCg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IFRodXJzZGF5LCBO
b3ZlbWJlciAyMSwgMjAxMyA2OjE5IFBNDQpUbzogQmFzaWwgTW9oYW1lZCBHb2hhcg0KQ2M6IHJ0
Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFByb3Bvc2VkIFZpZGVvIFNlbGVj
dGlvbiBQcm9jZXNzDQoNCg0KU3RlZmFuIFdlbmdlciBwb3N0ZWQgYSBmYWlybHkgZGV0YWlsZWQg
YW5hbHlzaXMgb2YgdGhlIEguMjYzIHNpdHVhdGlvbiwgd2hpY2ggSSB0aGluayBhbHNvIGFwcGxp
ZXMgdG8gTVBFRy0yLg0KDQpUTDtEUjogbm8sIGJlY2F1c2UgcGF0ZW50cy4NCk9uIE5vdiAyMSwg
MjAxMyA2OjExIFBNLCAiQmFzaWwgTW9oYW1lZCBHb2hhciIgPGJhc2lsZ29oYXJAbGlicmV2aWRl
by5vcmc8bWFpbHRvOmJhc2lsZ29oYXJAbGlicmV2aWRlby5vcmc+PiB3cm90ZToNClBhdGVudHMg
Y2FuIGxhc3QgbG9uZ2VyIHRoYW4gMTcgeWVhcnMuDQoNCmh0dHA6Ly9wYXRlbnRzLnN0YWNrZXhj
aGFuZ2UuY29tL3F1ZXN0aW9ucy8zMTIvaG93LWxvbmctYXJlLXNvZnR3YXJlLXBhdGVudHMtdmFs
aWQNCg0KT24gMTEvMjEvMjAxMyAwOTowNSBQTSwgRGF2aWQgU2luZ2VyIHdyb3RlOg0KPiBPaywg
ZXZlbiB0aG91Z2ggdGhlIHN0YW5kYXJkIGlzc3VlZCBpbiBlYXJseSAxOTk2LCBtb3JlIHRoYW4g
MTcgeWVhcnMgYWdvPw0KPg0KPiBTZW50IGZyb20gbXkgaVBhZA0KPg0KPj4gT24gTm92IDIxLCAy
MDEzLCBhdCA2OjAwIFBNLCBCYXNpbCBNb2hhbWVkIEdvaGFyIDxiYXNpbGdvaGFyQGxpYnJldmlk
ZW8ub3JnPG1haWx0bzpiYXNpbGdvaGFyQGxpYnJldmlkZW8ub3JnPj4gd3JvdGU6DQo+Pg0KPj4+
IE9uIDExLzIxLzIwMTMgMDg6MjMgUE0sIERhdmlkIFNpbmdlciB3cm90ZToNCj4+Pg0KPj4+IENh
biBzb21lb25lIHJlbWluZCBtZSB3aHkgY2xhc3NpYyBILjI2MyAod2l0aCBwb3NzaWJseSB0aGUg
bWlub3IgdHdlYWtzIGZvciBwaWN0dXJlIHNpemUgbGltaXRzIGV0Yy4pIGlzIHByb2JsZW1hdGlj
Pw0KPj4NCj4+IEZvciBleGFjdGx5IHRoZSBzYW1lIHJlYXNvbnMgSC4yNjQgKGZvciBzb21lKSBh
bmQgVlA4IChmb3Igb3RoZXJzKSAtIElQUg0KPj4gaXNzdWVzIGR1ZSB0byBub3QgYmVpbmcgb2xk
IGVub3VnaCBmb3IgYW55dGhpbmcgcGF0ZW50ZWQgaW4gdGhlIHN0YW5kYXJkDQo+PiB0byBiZSBn
dWFyYW50ZWVkIHRvIGhhdmUgZXhwaXJlZC4NCj4+DQo+PiAtLQ0KPj4gTGlicmUgVmlkZW8NCj4+
IGh0dHA6Ly9saWJyZXZpZGVvLm9yZw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+IHJ0Y3dlYkBpZXRm
Lm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9ydGN3ZWINCg0KDQotLQ0KTGlicmUgVmlkZW8NCmh0dHA6Ly9saWJyZXZp
ZGVvLm9yZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
CnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg==

--_000_7949EED078736C4881C92F656DC6F6C130EA9E6618ausmsex00aust_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpz
cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No
cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg
ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv
ZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp
b24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZXJlIGFwcGVh
cnMgdG8gYmUgc29tZSBjb25mdXNpb24gYWJvdXQgY29kZWMgc3BlY2lmaWMgcGF0ZW50cyBhbmQg
Z2VuZXJhbCB2aWRlbyBjb2RpbmcgcGF0ZW50cyBzbyBsZXQgbWUgdHJ5IHRvIGNsYXJpZnk6PG86
cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
Ijtjb2xvcjojMUY0OTdEJz5Cb3RoIEguMjY0IGFuZCBWUDggc3BlY2lmaWNhdGlvbiBkZXNjcmli
ZSB0aGUgREVDT0RFUiwgc3BlY2lmaWNhbGx5IHRoZSBmb3JtYXQgYW5kIG9yZGVyIG9mIHRoZSBk
YXRhIGluIHRoZSBiaXRzdHJlYW0uwqAgV2hhdCBkb2VzIHRoYXQgbWVhbj/CoCBJdCBtZWFucyB0
aGF0IGZvciBlYWNoIG1hY3JvYmxvY2sgdGhlcmUgd2lsbCBiZSBpbmZvcm1hdGlvbiBpbmRpY2F0
aW5nIHRoZSBibG9jayB0eXBlLCB0aGUgbW90aW9uIHZlY3RvcnMsIHRoZSBxdWFudGl6ZXIsIHRo
ZSByZXNpZHVhbCwgZXRjLsKgwqAgV2hhdCB0aGUgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBzYXkg
aXMgSE9XIHlvdSBkZWNpZGUgd2hhdCBibG9jayB0eXBlIHRvIHVzZSwgd2hhdCBtb3Rpb24gdmVj
dG9yIHRvIHVzZSwgd2hhdCBxdWFudGl6ZXIgdG8gdXNlLCBldGMuPG86cD48L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE
Jz5BIGxpY2Vuc2UgZnJvbSBtcGVnLWxhIGFuZCBwcmVzdW1hYmx5IGZyb20gZ29vZ2xlIHdpbGwg
cHJvdGVjdCB5b3Ugd2hlbiBpbXBsZW1lbnRpbmcgYW55dGhpbmcgZGVzY3JpYmVkIGluIHRoZSBk
ZWNvZGVyIHNwZWNpZmljYXRpb24uwqAgSXQgd2lsbCBub3QgcHJvdGVjdCB5b3UgZnJvbSB0aGUg
SE9XLsKgIFNvIGlmIHlvdSB0aGluayBvZiBhIHJlYWxseSBzaW1wbGUgbW90aW9uIGVzdGltYXRl
IGVuZ2luZSB3aGVyZSB5b3Ugc2VhcmNoIGV2ZXJ5IHBvc3NpYmxlIGxvY2F0aW9uIGluIHRoZSBy
ZWZlcmVuY2UgZnJhbWUgdG8gZmluZCB0aGUgYmVzdCBtYXRjaCB1c2luZyBTQUQgYXMgYSBibG9j
ayBtYXRjaGluZyBhbGdvcml0aG3igKZndWVzcyB3aGF0P8KgIFRoZXJl4oCZcyBhIHBhdGVudCBm
b3IgdGhhdC7CoCBJZiB5b3UgdGhlbiBkZWNpZGUgdGhhdCBpZiB0aGVyZSBpc27igJl0IGEgcmVh
bGx5IGdvb2QgbWF0Y2ggKGhpZ2ggU0FEKSwgYW5kIHlvdSBkZWNpZGUgdG8gZG8gYW4gaW50cmEg
c2VhcmNoIGluc3RlYWTigKZndWVzcyB3aGF0P8KgIFRoZXJl4oCZcyBhIHBhdGVudCBmb3IgdGhh
dC7CoCBZb3VyIG1wZWctbGEgbGljZW5zZSAoYW5kIEnigJltIHdpbGxpbmcgdG8gYmV0IHZwOCBh
bHNvKSB3b27igJl0IHByb3RlY3QgeW91IGlmIHlvdSBoYXBwZW4gdG8gaW5mcmluZ2Ugb24gdGhv
c2UuwqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv
bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5J4oCZbSBub3QgdHJ5aW5nIHRvIHNjYXJlIGV2ZXJ5
b25lIGJ1dCB0byBhcmd1ZSB0aGF0IEguMjYxIGlzIHNvbWVob3cgZ29pbmcgdG8gcHJvdGVjdCB5
b3UgZnJvbSBwYXRlbnQgaW5mcmluZ2VtZW50IGlzIGNvbXBsZXRlbHkgd2l0aG91dCBtZXJpdC7C
oCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6
IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNvbWV0aGluZyBlbHNlIHRvIGtlZXAgaW4gbWluZCwgbWFu
eSBvZiB5b3UgYXJlIGF3YXJlIHRoYXQgYXBwbGUgcmVjZW50bHkgbG9zdCBhIHBhdGVudCBpbmZy
aW5nZW1lbnQgc3VpdCBmcm9tIFZpbWV0WCByZWdhcmRpbmcgcDJwIGNhbGxpbmcgd2l0aCBmYWNl
dGltZS7CoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
Y29sb3I6IzFGNDk3RCc+V2hhdCB0aGV5IGFyZSBkb2luZyBpc27igJl0IGFsbCB0byBkaWZmZXJl
bnQgdGhhbiBhIHAycCB1c2luZyBhIHN0dW4gc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+TXkg
cG9pbnQgaGVyZSBpcyB3ZSBzaG91bGQgYmUgZm9jdXNpbmcgb24gY2hvb3NpbmcgdGhlIGJlc3Qg
dGVjaG5vbG9neSBhbmQgY29tZSB1cCB3aXRoIGEgc29sdXRpb24gZm9yIGRlYWxpbmcgd2l0aCBw
YXRlbnQgdHJvbGxzIGF0IHNvbWUgb3RoZXIgbGV2ZWwgYmVjYXVzZSBpdOKAmXMgZ29pbmcgdG8g
YmUgYSB3aWRlIHNwcmVhZCBjb25jZXJuLCBub3QganVzdCBhIHZpZGVvIHByb2JsZW0uPG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj
b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y
bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBydGN3
ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5K
dXN0aW4gVWJlcnRpPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMjEsIDIwMTMg
NjoxOSBQTTxicj48Yj5Ubzo8L2I+IEJhc2lsIE1vaGFtZWQgR29oYXI8YnI+PGI+Q2M6PC9iPiBy
dGN3ZWJAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBQcm9wb3NlZCBW
aWRlbyBTZWxlY3Rpb24gUHJvY2VzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O
b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHA+U3RlZmFuIFdlbmdlciBwb3N0ZWQgYSBmYWly
bHkgZGV0YWlsZWQgYW5hbHlzaXMgb2YgdGhlIEguMjYzIHNpdHVhdGlvbiwgd2hpY2ggSSB0aGlu
ayBhbHNvIGFwcGxpZXMgdG8gTVBFRy0yLiA8bzpwPjwvbzpwPjwvcD48cD5UTDtEUjogbm8sIGJl
Y2F1c2UgcGF0ZW50cy48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBO
b3YgMjEsIDIwMTMgNjoxMSBQTSwgJnF1b3Q7QmFzaWwgTW9oYW1lZCBHb2hhciZxdW90OyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmJhc2lsZ29oYXJAbGlicmV2aWRlby5vcmciPmJhc2lsZ29oYXJAbGli
cmV2aWRlby5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt
YWw+UGF0ZW50cyBjYW4gbGFzdCBsb25nZXIgdGhhbiAxNyB5ZWFycy48YnI+PGJyPjxhIGhyZWY9
Imh0dHA6Ly9wYXRlbnRzLnN0YWNrZXhjaGFuZ2UuY29tL3F1ZXN0aW9ucy8zMTIvaG93LWxvbmct
YXJlLXNvZnR3YXJlLXBhdGVudHMtdmFsaWQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vcGF0ZW50
cy5zdGFja2V4Y2hhbmdlLmNvbS9xdWVzdGlvbnMvMzEyL2hvdy1sb25nLWFyZS1zb2Z0d2FyZS1w
YXRlbnRzLXZhbGlkPC9hPjxicj48YnI+T24gMTEvMjEvMjAxMyAwOTowNSBQTSwgRGF2aWQgU2lu
Z2VyIHdyb3RlOjxicj4mZ3Q7IE9rLCBldmVuIHRob3VnaCB0aGUgc3RhbmRhcmQgaXNzdWVkIGlu
IGVhcmx5IDE5OTYsIG1vcmUgdGhhbiAxNyB5ZWFycyBhZ28/PGJyPiZndDs8YnI+Jmd0OyBTZW50
IGZyb20gbXkgaVBhZDxicj4mZ3Q7PGJyPiZndDsmZ3Q7IE9uIE5vdiAyMSwgMjAxMywgYXQgNjow
MCBQTSwgQmFzaWwgTW9oYW1lZCBHb2hhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhc2lsZ29oYXJA
bGlicmV2aWRlby5vcmciPmJhc2lsZ29oYXJAbGlicmV2aWRlby5vcmc8L2E+Jmd0OyB3cm90ZTo8
YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IE9uIDExLzIxLzIwMTMgMDg6MjMgUE0sIERhdmlk
IFNpbmdlciB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBDYW4gc29tZW9u
ZSByZW1pbmQgbWUgd2h5IGNsYXNzaWMgSC4yNjMgKHdpdGggcG9zc2libHkgdGhlIG1pbm9yIHR3
ZWFrcyBmb3IgcGljdHVyZSBzaXplIGxpbWl0cyBldGMuKSBpcyBwcm9ibGVtYXRpYz88YnI+Jmd0
OyZndDs8YnI+Jmd0OyZndDsgRm9yIGV4YWN0bHkgdGhlIHNhbWUgcmVhc29ucyBILjI2NCAoZm9y
IHNvbWUpIGFuZCBWUDggKGZvciBvdGhlcnMpIC0gSVBSPGJyPiZndDsmZ3Q7IGlzc3VlcyBkdWUg
dG8gbm90IGJlaW5nIG9sZCBlbm91Z2ggZm9yIGFueXRoaW5nIHBhdGVudGVkIGluIHRoZSBzdGFu
ZGFyZDxicj4mZ3Q7Jmd0OyB0byBiZSBndWFyYW50ZWVkIHRvIGhhdmUgZXhwaXJlZC48YnI+Jmd0
OyZndDs8YnI+Jmd0OyZndDsgLS08YnI+Jmd0OyZndDsgTGlicmUgVmlkZW88YnI+Jmd0OyZndDsg
PGEgaHJlZj0iaHR0cDovL2xpYnJldmlkZW8ub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2xp
YnJldmlkZW8ub3JnPC9hPjxicj4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyBydGN3ZWIgbWFpbGluZyBsaXN0PGJyPiZn
dDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwv
YT48YnI+Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3J0Y3dlYjwvYT48YnI+PGJyPjxicj4tLTxicj5MaWJyZSBWaWRlbzxicj48YSBo
cmVmPSJodHRwOi8vbGlicmV2aWRlby5vcmciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbGlicmV2
aWRlby5vcmc8L2E+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPGJyPnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBp
ZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2
PjwvZGl2PjwvYm9keT48L2h0bWw+

--_000_7949EED078736C4881C92F656DC6F6C130EA9E6618ausmsex00aust_--

From mzanaty@cisco.com  Thu Nov 21 21:17:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FAF1ADFA0 for ; Thu, 21 Nov 2013 21:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.511
X-Spam-Level: 
X-Spam-Status: No, score=-8.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNQxzh1fw4fd for ; Thu, 21 Nov 2013 21:17:53 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id BC8191A1F61 for ; Thu, 21 Nov 2013 21:17:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4543; q=dns/txt; s=iport; t=1385097466; x=1386307066; h=from:to:cc:subject:date:message-id:mime-version; bh=/p4oK4ND2uzO9BFHpIRyeNHYhl4aCAL4kHJId6Eo8P0=; b=L3D8ZawIsv8ycy0HutnabEv5Z6NULI5lqZ9s7ousujFXrpsFp2ViaD8p 9Bs4ogbdI46RQC3YYq9TLrye/+vx/gAzBbMb9Q04OkIjNU4UJXAkqQ38a ymz8lHlQUXzaNa/xAhZ7uRc1Ukylkj8sDe0NryrK+/moOJwfrFghT1dlV o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAOvnjlKtJV2b/2dsb2JhbABZgkNEOFO8O4EkFnSCLHkSAQw7ORQTBA4FiAENwHYXjwGEOQOYE5IQgyiCKg
X-IronPort-AV: E=Sophos;i="4.93,750,1378857600"; d="scan'208,217";a="1421143"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 22 Nov 2013 05:17:45 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAM5Hjh1020663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 05:17:45 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 23:17:45 -0600
From: "Mo Zanaty (mzanaty)" 
To: Basil Mohamed Gohar 
Thread-Topic: H.261
Thread-Index: AQHO50Itstn9eh6B8EejB0XcQHHKMg==
Date: Fri, 22 Nov 2013 05:17:45 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.82.237.72]
Content-Type: multipart/alternative; boundary="_000_CEB4350B1E7B2mzanatyciscocom_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: [rtcweb] H.261
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 05:17:55 -0000

--_000_CEB4350B1E7B2mzanatyciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

On 11/21/13 12:48, Basil Mohamed Gohar > wrote:
Has anyone actually objected to H.261 being the one MTI codec [...] ?

Assume this wins and all obey. Chrome does H.261+VP8, Firefox does H.261+H.=
264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According to various=
 (incredibly extrapolated, possibly inaccurate and sometimes conflicting) s=
ources [1] on who uses what browser, the chance of H.261 fallback is a whop=
ping 30% [2]. Not the minor insignificant case some had assumed.

How will these users react to H.261 QCIF/CIF compared to what they use toda=
y, say Skype for example? "This web shit really sucks. I=92m going back to =
Skype and never trying it again." Is that the first (and perhaps last) impr=
ession we want from users that try webrtc? Those arguing crappy video is be=
tter than no video are ignoring the critical importance of first impression=
s. While some may accept crappy video as usable, many more may be permanent=
ly turned off and tune out even faster than if they got only (good) audio. =
It=92s not as if webrtc is the only game in town. Users have options, so it=
 needs to be competitive with competitive technology which has already set =
the bar.

We previously narrowed the options down to H.264 and VP8 for good reasons o=
ver the course of this excruciatingly long decision. Reopening discarded ta=
ngents like H.261 does not move us forward as a workgroup, and certainly do=
es not move webrtc forward as a technology.

Mo

[1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
[2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x (IE%=
 + Safari%)


--_000_CEB4350B1E7B2mzanatyciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <1A44D49EB285AB4682D4FEE4AC607596@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







    On 11/21/13 12:48, Basil Mohamed Gohar <basilgohar@librevideo.org> wrote:
    

    

    Has anyone actually objected to H.261 being the one MTI codec [...] ?<=
/div>

    


    

    

    Assume this wins and all obey. Chrome does H.261+VP8, Firefox does=
 H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.=
264. According to various (incredibly extrapolated, possibly inaccurate and=
 sometimes conflicting) sources [1] on who uses what
 browser, the chance of H.261 fallback is a whopping 30% [2]. Not the minor=
 insignificant case some had assumed.
    


    

    

    How will these users react to H.261 QCIF/CIF compared to what they use=
 today, say Skype for example? "This web shit really sucks. I=92m goin=
g back to Skype and never trying it again." Is that the first (and per=
haps last) impression we want from users that
 try webrtc? Those arguing crappy video is better than no video are ignorin=
g the critical importance of first impressions. While some may accept crapp=
y video as usable, many more may be permanently turned off and tune out eve=
n faster than if they got only (good)
 audio. It=92s not as if webrtc is the only game in town. Users have option=
s, so it needs to be competitive with competitive technology which has alre=
ady set the bar.
    


    

    

    We previously narrowed the options down to H.264 and VP8 for good reas=
ons over the course of this excruciatingly long decision. Reopening discard=
ed tangents like H.261 does not move us forward as a workgroup, and certain=
ly does not move webrtc forward
 as a technology.
    


    

    

    Mo
    


    

    

    

    [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
    

    [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x=
 (IE% + Safari%)
    

    


    

    



--_000_CEB4350B1E7B2mzanatyciscocom_--

From lgeyser@gmail.com  Thu Nov 21 21:41:11 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCE21AE01E for ; Thu, 21 Nov 2013 21:41:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.485
X-Spam-Level: 
X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYWEH1nQ32O7 for ; Thu, 21 Nov 2013 21:41:09 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 04BBD1AE0B4 for ; Thu, 21 Nov 2013 21:41:08 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id n7so581662lam.30 for ; Thu, 21 Nov 2013 21:41:01 -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=ucSURQ3i6dJRgl3tHj/culGeZDrt8dCUDLctJEN8vgU=; b=cXlFM9/jggPoE5D0R3jZTEaoNp0HTLRe6ncXebePvv5iJuWctkwUIsRcvfqocCeu+i iIAJcyCP944YOjsMtSlKLXaIuwjwZHbnFyXbJhJu5ajHv4rIUzBuRO/C8lgWjChzW6iB xk+0+mJ43UbwJFoTNwDC4DoMvRKFW86adyqor45/T5jWLcemZ7kduBhcJFgvOZa7qsMj E+VCRBcVZbf7yup+4Pa+kadefa+JMO+dImVFgVWqPE78ZrvCcKlJOTw972OLN7PAjWMT 5VKDkDqsPt47T5WXjeESiDdcbWx3/h2NL4xv5gJwE2iMJWiocdTYo2PdMB6wU1UzanOO 1n2w==
MIME-Version: 1.0
X-Received: by 10.152.87.142 with SMTP id ay14mr2072320lab.7.1385098861215; Thu, 21 Nov 2013 21:41:01 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 21 Nov 2013 21:41:01 -0800 (PST)
In-Reply-To: 
References: 
Date: Fri, 22 Nov 2013 07:41:01 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c3560c9a05ad04ebbd750e
Subject: Re: [rtcweb] H.261
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 05:41:11 -0000

--001a11c3560c9a05ad04ebbd750e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

>>How will these users react to H.261 QCIF/CIF compared to what they use
today, say Skype for example? "This web shit >>really sucks. I=92m going ba=
ck
to Skype and never trying it again."
How different is this from: "This WebRTC thing is crap, because it doesn't
even show basic video."
What option do you suggest?

>>We previously narrowed the options down to H.264 and VP8 for good reasons
over the course of this excruciatingly long >>decision. Reopening discarded
tangents like H.261 does not move us forward as a workgroup, and certainly
does not move >>webrtc forward as a technology.

No consensus was reached between H.264 and VP8. All that is left now is
H.261, Theora and maybe MPEG 1 Part 2.

On 22 November 2013 07:17, Mo Zanaty (mzanaty)  wrote:

>  On 11/21/13 12:48, Basil Mohamed Gohar  wrote=
:
>
> Has anyone actually objected to H.261 being the one MTI codec [...] ?
>
>
>  Assume this wins and all obey. Chrome does H.261+VP8, Firefox does
> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According =
to
> various (incredibly extrapolated, possibly inaccurate and sometimes
> conflicting) sources [1] on who uses what browser, the chance of H.261
> fallback is a whopping 30% [2]. Not the minor insignificant case some had
> assumed.
>
>  How will these users react to H.261 QCIF/CIF compared to what they use
> today, say Skype for example? "This web shit really sucks. I=92m going ba=
ck
> to Skype and never trying it again." Is that the first (and perhaps last)
> impression we want from users that try webrtc? Those arguing crappy video
> is better than no video are ignoring the critical importance of first
> impressions. While some may accept crappy video as usable, many more may =
be
> permanently turned off and tune out even faster than if they got only
> (good) audio. It=92s not as if webrtc is the only game in town. Users hav=
e
> options, so it needs to be competitive with competitive technology which
> has already set the bar.
>
>  We previously narrowed the options down to H.264 and VP8 for good
> reasons over the course of this excruciatingly long decision. Reopening
> discarded tangents like H.261 does not move us forward as a workgroup, an=
d
> certainly does not move webrtc forward as a technology.
>
>  Mo
>
>  [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
> [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x (I=
E% +
> Safari%)
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a11c3560c9a05ad04ebbd750e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


    >>How will these users react to H.261 QCIF=
/CIF compared to what they use=20
today, say Skype for example? "This web shit >>really sucks. I=
=92m going=20
back to Skype and never trying it again."
    How different is this fro=
m: "This WebRTC thing is crap, because it doesn't even show basic =
video."
    What option do you suggest?

    >>We previou=
sly narrowed the options down to H.264 and VP8 for good=20
reasons over the course of this excruciatingly long >>decision. Reope=
ning=20
discarded tangents like H.261 does not move us forward as a workgroup,=20
and certainly does not move >>webrtc forward
 as a technology.

    No consensus was reached between  H.264 and =
VP8. All that is left now is H.261, Theora and maybe MPEG 1 Part 2.

    On 22 November 2=
013 07:17, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

    




    

    On 11/21/13 12:48, Basil Mohamed Gohar <basilgohar@librevideo.org> wrote=
:
    

    

    Has anyone actually objected to H.261 being the one MTI codec [...] ?<=
/div>

    


    

    

    Assume this wins and all obey. Chrome does H.261+VP8, Firefox does H.2=
61+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According to va=
rious (incredibly extrapolated, possibly inaccurate and sometimes conflicti=
ng) sources [1] on who uses what
 browser, the chance of H.261 fallback is a whopping 30% [2]. Not the minor=
 insignificant case some had assumed.
    


    

    

    How will these users react to H.261 QCIF/CIF compared to what they use=
 today, say Skype for example? "This web shit really sucks. I=92m goin=
g back to Skype and never trying it again." Is that the first (and per=
haps last) impression we want from users that
 try webrtc? Those arguing crappy video is better than no video are ignorin=
g the critical importance of first impressions. While some may accept crapp=
y video as usable, many more may be permanently turned off and tune out eve=
n faster than if they got only (good)
 audio. It=92s not as if webrtc is the only game in town. Users have option=
s, so it needs to be competitive with competitive technology which has alre=
ady set the bar.
    


    

    

    We previously narrowed the options down to H.264 and VP8 for good reas=
ons over the course of this excruciatingly long decision. Reopening discard=
ed tangents like H.261 does not move us forward as a workgroup, and certain=
ly does not move webrtc forward
 as a technology.
    


    

    

    Mo
    


    

    

    


    [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x=
 (IE% + Safari%)
    

    


    

    

    


    _______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--001a11c3560c9a05ad04ebbd750e--

From stevek@stevek.com  Thu Nov 21 22:12:11 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC821ADEB7 for ; Thu, 21 Nov 2013 22:12:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.084
X-Spam-Level: 
X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_RHS_DOB=1.514] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7HscBvPtgOu for ; Thu, 21 Nov 2013 22:12:08 -0800 (PST)
Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 758381A1F3E for ; Thu, 21 Nov 2013 22:12:08 -0800 (PST)
Received: by mail-pb0-f41.google.com with SMTP id jt11so862841pbb.0 for ; Thu, 21 Nov 2013 22:12:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=2s3LdUzrQyv2aMaFevaSADy5EZKmzaiDxFfpEKALp+E=; b=eHCbbV6ChVfG2If2ujeBAI+s1W4llUgHehp5Com8NYnE68h/aW0NSxZY+rskVvfTzK DHwjsDkdUPRKwaHBg7bQ0Uqaxu5iWuay9OF+lWSLsRl21J/V06fyYnUFhRC6bEBLS6xr Y30orYNLubnxOHr5ip13XuQrR8Fk+ueRJZ6uyLtk8cWPRX4XVXT7dCA6wagSufngYmRJ kacZ2S4XIEpudMQPySr+PwwRe4Do56faKVIM6X8NiiKG16XNGxMMfxpDz9w5OpDBFpNg g6IyZfhd3ClCszu89Cbi1x5PMFav6+NhwU/USIaw6Rymk2+Qjqvg8T+jLyilZgwv/gQo OM9Q==
X-Gm-Message-State: ALoCoQlvsmI4Gt7anaRUSn2KhXqp8XBtEuzAmEpxajBnYb4qwiXPzJ08dLYydJIhraCaynyRq0Th
X-Received: by 10.66.248.168 with SMTP id yn8mr10595544pac.11.1385100720105; Thu, 21 Nov 2013 22:12:00 -0800 (PST)
Received: from [184.208.20.115] (184-208-20-115.pools.spcsdns.net. [184.208.20.115]) by mx.google.com with ESMTPSA id y9sm57171917pas.10.2013.11.21.22.11.54 for  (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 Nov 2013 22:11:59 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.3.8.130913
Date: Thu, 21 Nov 2013 22:11:48 -0800
From: Steve Kann 
To: "Mo Zanaty (mzanaty)" , Basil Mohamed Gohar 
Message-ID: 
Thread-Topic: [rtcweb] H.261
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3467916718_23836479"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] H.261
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 06:12:11 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3467916718_23836479
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


Mo,

I think we all agree that choosing H.264 or VP8 would be better, but it is
clear that neither option today has consensus.    Circumstances could chang=
e
in the future, but it seems that OpenH264 was not enough to change that
circumstance.

I think that where your scenario might go astray is that users won=B9t
associate their poor experience with =B3WebRTC=B2, or =B3that web stuff=B2 =8B they
will associate it with the brand of the service which they are using at the
time.

So, for example, if Facebook builds video chat using WebRTC, and they do no
transcoding, 30% of users might associate their poor video with Facebook,
but most of them won=B9t call it =B3that web shit=B2 =8B they would say Facebook
video sucks.

Of course, Facebook could decide to transcode 30% of the time, in which cas=
e
the user would have a different experience.

Facebook obviously just being used as an example service which might
implement WebRTC video.

-SteveK



From:  "Mo Zanaty (mzanaty)" 
Date:  Thursday, November 21, 2013 at 9:17 PM
To:  Basil Mohamed Gohar 
Cc:  "rtcweb@ietf.org" 
Subject:  [rtcweb] H.261

> On 11/21/13 12:48, Basil Mohamed Gohar  wrote:
>> Has anyone actually objected to H.261 being the one MTI codec [...] ?
>=20
> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does
> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According =
to
> various (incredibly extrapolated, possibly inaccurate and sometimes
> conflicting) sources [1] on who uses what browser, the chance of H.261
> fallback is a whopping 30% [2]. Not the minor insignificant case some had
> assumed.
>=20
> How will these users react to H.261 QCIF/CIF compared to what they use to=
day,
> say Skype for example? "This web shit really sucks. I=B9m going back to Sky=
pe
> and never trying it again." Is that the first (and perhaps last) impressi=
on we
> want from users that try webrtc? Those arguing crappy video is better tha=
n no
> video are ignoring the critical importance of first impressions. While so=
me
> may accept crappy video as usable, many more may be permanently turned of=
f and
> tune out even faster than if they got only (good) audio. It=B9s not as if w=
ebrtc
> is the only game in town. Users have options, so it needs to be competiti=
ve
> with competitive technology which has already set the bar.
>=20
> We previously narrowed the options down to H.264 and VP8 for good reasons=
 over
> the course of this excruciatingly long decision. Reopening discarded tang=
ents
> like H.261 does not move us forward as a workgroup, and certainly does no=
t
> move webrtc forward as a technology.
>=20
> Mo
>=20
> [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
> [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x (IE% +
> Safari%)
>=20
> _______________________________________________ rtcweb mailing list
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb



--B_3467916718_23836479
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable



    Mo,

    I think we all agree that choosing H.264 or VP8 woul=
d be better, but it is clear that neither option today has consensus.  =
  Circumstances could change in the future, but it seems that OpenH264 =
was not enough to change that circumstance.

    I think=
 that where your scenario might go astray is that users won’t associat=
e their poor experience with “WebRTC”, or “that web stuff&=
#8221; — they will associate it with the brand of the service which th=
ey are using at the time.

    So, for example, if Faceb=
ook builds video chat using WebRTC, and they do no transcoding, 30% of users=
 might associate their poor video with Facebook, but most of them won’=
t call it “that web shit” — they would say Facebook video =
sucks.

    Of course, Facebook could decide to transcod=
e 30% of the time, in which case the user would have a different experience.=


    Facebook obviously just being used as an example s=
ervice which might implement WebRTC video.

    -SteveK<=
/div>



    From:  "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
    Date:  T=
hursday, November 21, 2013 at 9:17 PM
    To: =
 Basil Mohamed Gohar <b=
asilgohar@librevideo.org>
    Cc:  "rtcweb@ietf.org" <rtcweb@ietf.org>
    Subject:  [rtcweb] H.261

    On 11/21/13 12:48, Ba=
sil Mohamed Gohar <basilgohar@=
librevideo.org> wrote:
    Has anyone actually objected to H.261 being the one MTI codec [..=
.] ?

    Assume this wins and all obey. Ch=
rome does H.261+VP8, Firefox does H.261+H.264+VP8, IE does H.261+H.264, Safa=
ri does H.261+H.264. According to various (incredibly extrapolated, possibly=
 inaccurate and sometimes conflicting) sources [1] on who uses what
 browser, the chance of H.261 fallback is a whopping 30% [2]. Not the minor=
 insignificant case some had assumed.

    How will thes=
e users react to H.261 QCIF/CIF compared to what they use today, say Skype f=
or example? "This web shit really sucks. I’m going back to Skype and n=
ever trying it again." Is that the first (and perhaps last) impression we wa=
nt from users that
 try webrtc? Those arguing crappy video is better than no video are ignorin=
g the critical importance of first impressions. While some may accept crappy=
 video as usable, many more may be permanently turned off and tune out even =
faster than if they got only (good)
 audio. It’s not as if webrtc is the only game in town. Users have op=
tions, so it needs to be competitive with competitive technology which has a=
lready set the bar.

    We previously narrowed the opti=
ons down to H.264 and VP8 for good reasons over the course of this excruciat=
ingly long decision. Reopening discarded tangents like H.261 does not move u=
s forward as a workgroup, and certainly does not move webrtc forward
 as a technology.

    Mo

    [2] H.261=
 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x (IE% + Safari%)

    
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org=
/mailman/listinfo/rtcweb

    

--B_3467916718_23836479--



From mzanaty@cisco.com  Thu Nov 21 22:15:27 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A5C1AE03C for ; Thu, 21 Nov 2013 22:15:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.511
X-Spam-Level: 
X-Spam-Status: No, score=-8.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foanbtkkgVpB for ; Thu, 21 Nov 2013 22:15:24 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id A1AA11ADEB7 for ; Thu, 21 Nov 2013 22:15:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9103; q=dns/txt; s=iport; t=1385100918; x=1386310518; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hGQsSiXeZ7cplaWboOkJih3pIOEMHhl4aj/c+7hy7Yc=; b=dPp0JtwLiEVMSnhkrO5JwmqGarQe1jBzl9aqER6k4LiSyx7omSgwVZw5 ffY6ixQIJSfjA2whJ0V469kUNTfKZvsHV5IIYVRQ/Qlb7IXkwMvvZtbv/ hokO3fuEtFzwYhr25hE2dvMK+4h/dVC96ULLwlFgtAx8ELhBvh6nyQKsk w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAKz1jlKtJV2c/2dsb2JhbABZgkNEOFO7W06BIRZ0giUBAQEEAQEBawsMBAIBCA4DBAEBAScHIQYLFAMBBQgCBAENBYdvAw8NuFANiCwTBIxyggsEBgEGhCwDliiBa4xYhTiDKIIq
X-IronPort-AV: E=Sophos;i="4.93,750,1378857600"; d="scan'208,217";a="1425251"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 22 Nov 2013 06:15:17 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAM6FHKj024482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 06:15:17 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 00:15:17 -0600
From: "Mo Zanaty (mzanaty)" 
To: Stefan Slivinski , "'lgeyser@gmail.com'" 
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: AQHO50o2WLjqtBKzQUWWibpBBMXuCQ==
Date: Fri, 22 Nov 2013 06:15:16 +0000
Message-ID: 
References:  <7949EED078736C4881C92F656DC6F6C130EA8AD7E3@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA8AD7E3@ausmsex00.austin.kmvtechnologies.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.82.237.72]
Content-Type: multipart/alternative; boundary="_000_CEB4569A1E8BEmzanatyciscocom_"
MIME-Version: 1.0
Cc: "'rtcweb@ietf.org'" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 06:15:27 -0000

--_000_CEB4569A1E8BEmzanatyciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Bluray is actually a good analogy. It mandates both H.264 and VC1. VC1 is t=
he MPEG standard for Microsoft=92s proprietary Windows Media Video (WMV). J=
ust like VCB is the MPEG standard-in-progress for Google=92s proprietary VP=
8. VC1 was intended to be RF, but MPEG LA formed a pool of licensors with c=
laims on VC1, and Microsoft didn=92t pay them off adequately to dissolve th=
e pool. Fast forward to today:

s/bluray/webrtc/
s/Microsoft/Google/
s/WMV/VP8/
s/VC1/VCB/
s/and H264/xor H264/
(xor may be impeding consensus)


On 11/21/13, 4:31 PM, Stefan Slivinski > wrote:

While I will readily admit this isn't the best analogy I think taking this =
to extremes and suggesting that someone working in their garage is at risk =
of being sued for IP infringement and then using that as justification for =
just requiring H.261 is a bit of a stretch.




From: Leon Geyser [mailto:lgeyser@gmail.com]
Sent: Thursday, November 21, 2013 03:21 PM
To: Stefan Slivinski
Cc: rtcweb@ietf.org >
Subject: Re: [rtcweb] Proposed Video Selection Process

That is a completely different situation. We are talking about the open web=
. Not some propriety disc format controlled by big companies.
They can deal with IPR easily. Average people who want to work out of their=
 garage do want other options even if it isn't the best.
Besides this has been pointed out millions of times: Nothing stops anyone t=
o implement VP8 or H.264 if H.261 is made MTI.


On 21 November 2013 23:04, Stefan Slivinski > wrote:
I think arguing in favor of a legacy codec is completely counter productive=
 to the proliferation of webrtc.  This working group is attempting to avoid=
 dealing with the obvious IPR issues with vp8 and h.264 that any and every =
webrtc vendor is going to have to deal with.  We are basically saying 'we d=
on't know how to deal with this problem so you're on your own' which is com=
pletely the wrong message to send as an organization.

Can you imagine if the bluray groups said we don't want to deal with h.264 =
IPR issues so we'll just mandate h.261?



----- Original Message -----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: Thursday, November 21, 2013 02:52 PM
To: Basil Mohamed Gohar >
Cc: rtcweb@ietf.org >
Subject: Re: [rtcweb] Proposed Video Selection Process

On 21 November 2013 12:48, Basil Mohamed Gohar
> wrote:
> Has anyone actually objected to H.261 being the one MTI codec [...] ?

More than one person has already.

And I find the argument raised quite compelling.  It's hard to justify
spending valuable time and resources on implementing something that
crappy.
_______________________________________________
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


--_000_CEB4569A1E8BEmzanatyciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <28FE0539763ADD45BE099369EDB3BD20@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







    Bluray is actually a good analogy. It mandates both H.264 and VC1. VC1=
 is the MPEG standard for Microsoft=92s proprietary Windows Media Video (WM=
V). Just like VCB is the MPEG standard-in-progress for Google=92s proprieta=
ry VP8. VC1 was intended to be RF, but
 MPEG LA formed a pool of licensors with claims on VC1, and Microsoft didn=
=92t pay them off adequately to dissolve the pool. Fast forward to today:


    

    

    s/bluray/webrtc/
    

    s/Microsoft/Google/
    

    s/WMV/VP8/
    

    s/VC1/VCB/
    

    s/and H264/xor H264/
    

    (xor may be impeding consensus)
    


    

    


    

    


    

    On 11/21/13, 4:31 PM, Stefan Slivinski <sslivinski@lifesize.com> wrote:
    

    


    

    

    

    While I will readily admit this isn't the b=
est analogy I think taking this to extremes and suggesting that someone wor=
king in their garage is at risk of being sued for IP infringement
 and then using that as justification for just requiring H.261 is a bit of =
a stretch.
    

    

    

    
 
    

    
From: Leon Geyser [=
mailto:lgeyser@gmail.com]

    
Sent: Thursday, November 21, 2013 03:21 PM
    
To: Stefan Slivinski 
    
Cc: rtcweb@ietf.org <rtcweb@ietf.org>

    
Subject: Re: [rtcweb] Proposed Video Selection Process 
    
     
    

    

    

    

    That is a completely different situation. We are talking about the ope=
n web. Not some propriety disc format controlled by big companies.
    

    
They can deal with IPR easily. Average people who want to work out of their=
 garage do want other options even if it isn't the best.
    

    
Besides this has been pointed out millions of times: Nothing stops anyone t=
o implement VP8 or H.264 if H.261 is made MTI.
    

    


    

    

    On 21 November 2013 23:04, Stefan Slivinski 
<sslivinski=
@lifesize.com> wrote:
    

    
I think arguing in favor of a legacy codec is completely counter productive=
 to the proliferation of webrtc.  This working group is attempting to =
avoid dealing with the obvious IPR issues with vp8 and h.264 that any and e=
very webrtc vendor is going to have to
 deal with.  We are basically saying 'we don't know how to deal with t=
his problem so you're on your own' which is completely the wrong message to=
 send as an organization.
    

    
Can you imagine if the bluray groups said we don't want to deal with h.264 =
IPR issues so we'll just mandate h.261?
    


    

    

    
----- Original Message -----
    
From: Martin Thomson [mailto:ma=
rtin.thomson@gmail.com]
    
Sent: Thursday, November 21, 2013 02:52 PM
    
To: Basil Mohamed Gohar <ba=
silgohar@librevideo.org>
    
Cc: rtcweb@ietf.org <rtcweb@ietf.org>
    
Subject: Re: [rtcweb] Proposed Video Selection Process
    

    

    

    

    On 21 November 2013 12:48, Basil Mohamed Gohar
    
<basilgohar@librevideo.org<=
/a>> wrote:
    
> Has anyone actually objected to H.261 being the one MTI codec [...] ?<=
br>

    
More than one person has already.
    

    
And I find the argument raised quite compelling.  It's hard to justify=

    
spending valuable time and resources on implementing something that
    
crappy.
    
_______________________________________________
    
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
    

    

    

    

    

    

    

    

    
    



--_000_CEB4569A1E8BEmzanatyciscocom_--

From maikmerten@googlemail.com  Thu Nov 21 22:55:41 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96451ADFAF for ; Thu, 21 Nov 2013 22:55:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wboSx9mv8oPg for ; Thu, 21 Nov 2013 22:55:39 -0800 (PST)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1A81ADF82 for ; Thu, 21 Nov 2013 22:55:39 -0800 (PST)
Received: by mail-bk0-f50.google.com with SMTP id e11so652776bkh.37 for ; Thu, 21 Nov 2013 22:55:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yP9KXlAK1ddUo41DRT1kU/ty4WUcNdtzrZEIOxEbvK0=; b=XO9RitVrwyxfcZpRxtCHjUkkaEACgX/7rP5790ayH3TkzxbK+jd3tJ094L2oj6Yha5 UrEEIAC32jQatIcqwVjo2P9TnuWAmhop3itaRwhw5DmNdBeR6oq+NfUbbUu4ZMeEuN7w seRJJ+fHNZoClwj8rwpLdp59NI0EJxEwgbrMgClVmqAA3KtEGfQpaJBNQcNjILjLxo7p C9DXaLtvxESDyf7sf49Y65Jy/zZg8eYbkywV8u2gSAFtgoqSzeDduNY0yFCCl6ZrJ38V xymDyD2/u2ehmVsNZvtuydepv9oLfg1ptU2z22NOyWiT4AbmyneFBJNGHQzDO5VHyGJ8 o4jw==
X-Received: by 10.205.74.69 with SMTP id yv5mr407341bkb.35.1385103331990; Thu, 21 Nov 2013 22:55:31 -0800 (PST)
Received: from [0.0.0.0] (v2201202116457532.yourvserver.net. [46.38.243.75]) by mx.google.com with ESMTPSA id pn6sm30824968bkb.14.2013.11.21.22.55.30 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 22:55:30 -0800 (PST)
Message-ID: <528F0051.6030006@googlemail.com>
Date: Fri, 22 Nov 2013 07:57:21 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7E3@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA8AD7E3@ausmsex00.austin.kmvtechnologies.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 06:55:41 -0000

There are also proposals where H.261 is only required if one cannot 
implement both VP8 and H.264.

Maik

Am 21.11.2013 22:31, schrieb Stefan Slivinski:
> While I will readily admit this isn't the best analogy I think taking
> this to extremes and suggesting that someone working in their garage is
> at risk of being sued for IP infringement and then using that as
> justification for just requiring H.261 is a bit of a stretch.
>
>
>
>
> *From*: Leon Geyser [mailto:lgeyser@gmail.com]
> *Sent*: Thursday, November 21, 2013 03:21 PM
> *To*: Stefan Slivinski
> *Cc*: rtcweb@ietf.org 
> *Subject*: Re: [rtcweb] Proposed Video Selection Process
>
> That is a completely different situation. We are talking about the open
> web. Not some propriety disc format controlled by big companies.
> They can deal with IPR easily. Average people who want to work out of
> their garage do want other options even if it isn't the best.
> Besides this has been pointed out millions of times: Nothing stops
> anyone to implement VP8 or H.264 if H.261 is made MTI.
>
>
> On 21 November 2013 23:04, Stefan Slivinski  > wrote:
>
>     I think arguing in favor of a legacy codec is completely counter
>     productive to the proliferation of webrtc.  This working group is
>     attempting to avoid dealing with the obvious IPR issues with vp8 and
>     h.264 that any and every webrtc vendor is going to have to deal
>     with.  We are basically saying 'we don't know how to deal with this
>     problem so you're on your own' which is completely the wrong message
>     to send as an organization.
>
>     Can you imagine if the bluray groups said we don't want to deal with
>     h.264 IPR issues so we'll just mandate h.261?
>
>
>
>     ----- Original Message -----
>     From: Martin Thomson [mailto:martin.thomson@gmail.com
>     ]
>     Sent: Thursday, November 21, 2013 02:52 PM
>     To: Basil Mohamed Gohar      >
>     Cc: rtcweb@ietf.org       >
>     Subject: Re: [rtcweb] Proposed Video Selection Process
>
>     On 21 November 2013 12:48, Basil Mohamed Gohar
>     > wrote:
>      > Has anyone actually objected to H.261 being the one MTI codec [...] ?
>
>     More than one person has already.
>
>     And I find the argument raised quite compelling.  It's hard to justify
>     spending valuable time and resources on implementing something that
>     crappy.
>     _______________________________________________
>     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
>


From duerst@it.aoyama.ac.jp  Fri Nov 22 02:14:02 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D5B1AC862 for ; Fri, 22 Nov 2013 02:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level: 
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x293VOVd69Px for ; Fri, 22 Nov 2013 02:14:00 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7FC1AC829 for ; Fri, 22 Nov 2013 02:13:58 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAMADmAN007989; Fri, 22 Nov 2013 19:13:49 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2095_186d_c7545cf0_535e_11e3_98d5_001e6722eec2; Fri, 22 Nov 2013 19:13:48 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 04A3FBF50F; Fri, 22 Nov 2013 19:13:48 +0900 (JST)
Message-ID: <528F2E4A.4060802@it.aoyama.ac.jp>
Date: Fri, 22 Nov 2013 19:13:30 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Eric Rescorla 
References: <528E39F4.4010706@ericsson.com>  <8647A71C-CDCF-4897-96D6-4CD1C6566BE6@cisco.com>  <528E5B47.70702@nostrum.com> <20131121204147.GV3245@audi.shelbyville.oz> <528E71AC.4040202@librevideo.org>   <528E80FB.4080802@librevideo.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 10:14:02 -0000

On 2013/11/22 6:59, Eric Rescorla wrote:
> On Thu, Nov 21, 2013 at 1:54 PM, Basil Mohamed Gohar<
> basilgohar@librevideo.org>  wrote:
>
>> On 11/21/2013 04:14 PM, Eric Rescorla wrote:
>>> Agreed.
>>>
>>> To take a not-so-random example, given that Firefox will soon
>>> support both H.264 and VP8, what additional implementations
>>> will it be able to talk to if it does H.261?

The Firefox example shows that making H.261 MTI is a bad idea. But it 
works out if this is changed to "two of three (of H.264, VP8, and 
H.261). Firefox will then soon be compliant. H.261 would be left for 
those who absolutely, definitely want to avoid one of VP8 or H.264 (of 
which there are many enough; otherwise we wouldn't have this whole 
discussion).

Regards,   Martin.

>>> -Ekr
>>
>> (I apparently replied only to Ekr, and not the whole list originally)
>>
>> None, but that's not the point.  Firefox is a special case for which VP8
>> is not considered a legal liability (by Mozilla) and they can be
>> satisfied, for the most part, by Cisco's proposal with OpenH264 as a
>> downloadable plugin/module.
>>
>> So, this doesn't open up anything for Firefox that it is not already
>> planning to handle.
>>
>> What it does open up is for, say, a small firm that cannot afford H.264
>> licensing, and cannot make use of Cisco's binary plugin for legal or
>> technical reasons, and can only implement VP8 and H.261, and, say, a
>> device whose manufacturers do not wish to implement VP8 for perceived
>> IPR risk but already license H.264.
>>
>> Both cases above have an H.261 implementation that will allow mutual
>> video, even though they do not share a common high-end codec
>> implementation.
>>
>> There are cases outside of browsers that are interested in rtcweb, after
>> all.
>
>
> Which of those cases are going to want to not talk to browsers?
>
> Which browsers want to do H.261?
>
> -Ekr
>
>
>>   --
>> Libre Video
>> http://librevideo.org
>> _______________________________________________
>> 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

From duerst@it.aoyama.ac.jp  Fri Nov 22 02:24:32 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4401F1ACC86 for ; Fri, 22 Nov 2013 02:24:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level: 
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4OPSwMOGczD for ; Fri, 22 Nov 2013 02:24:30 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 91D951AC829 for ; Fri, 22 Nov 2013 02:24:30 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAMAOKHP015857; Fri, 22 Nov 2013 19:24:20 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2091_0829_3fae9746_5360_11e3_a6e0_001e6722eec2; Fri, 22 Nov 2013 19:24:19 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 68810BF50F; Fri, 22 Nov 2013 19:24:19 +0900 (JST)
Message-ID: <528F30C1.8040208@it.aoyama.ac.jp>
Date: Fri, 22 Nov 2013 19:24:01 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Stefan Slivinski 
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "'rtcweb@ietf.org'" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 10:24:32 -0000

On 2013/11/22 5:02, Stefan Slivinski wrote:
> I in no way intended to suggest  a specific implementation of a video codec.  My question was around whether we are voting on requiring decoders (my assumption) or both encoders and decoders

My understanding is that all the proposals in each instance mean "both 
encoder and decoder". So as an example, a proposal of "MUST implement 
both VP8 and H.264" means "MUST implement both VP8 encoder and decoder, 
and H.264 encoder and decoder".

Your question brings up other choices. For example, interoperability 
would be satisfied by something like "MUST implement both VP8 and H.264 
decoders, and MUST implement at least one of VP8 and H.264 encoders".

One condition for this to work is the possibility of asymmetric 
communication, i.e. if side A implemented only a VP8 encoder, and side B 
only implemented a H.264 encoder, then traffic A->B would be VP8, 
whereas traffic B->A would be H.264. I don't know the in's and out's of 
the negotiation and protocol machinery to confirm or deny that this is 
possible.

Choices like the one above definitely open new horizons for Eric's 
selection generator. But frankly speaking, except for the specific 
choice of "MUST implement both VP8 and H.264 decoders, and MUST 
implement at least one of VP8 and H.264 encoders", which is less onerous 
than "MUST implement both VP8 and H.264", but still interoperable, I 
don't see any choices with different requirements for encoders and 
decoders that would make sense.

Regards,   Martin.


> ----- Original Message -----
> From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
> Sent: Thursday, November 21, 2013 01:56 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Proposed Video Selection Process
>
> On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
>> I'm a new comer, so just a brief intro: I have a background developing real time video codecs for embedded devices so I'm in a position to comment at a technical level within this group
>>
>> For clarity purposes the proposed alternatives in Magnus' email on nov 18th; are we strictly speaking about decoders?  Historically mandatory requirements are they relate to video compatibility define just the decoders.  Obviously if there is only a single mandatory video decoder this implies a mandatory encoder, however in the case where there are 2 mandatory decoders only a single encoder is technically required.
>>
>> Clarifying this is fairly important because in the case of both h264 and vp8 (and in the future vp9 and h265) the decoder complexity is fairly low and hardware acceleration is not critical but in the case of the encoders where the complexity can be 3x or worse, hardware acceleration becomes increasingly important
>>
>> Stefan
>
> What is being specified as MTI is a format, and not a specific
> implementation.  So, MTI will not take the form of "OpenH264" or
> "libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8".
>
> The same was done for the MTI audio codec, which is Opus, not *libopus*,
> which is one specific implementation of the codec.
>
> There was a suggestion that the WG also offer a reference implementation
> of the MTI codec choice, but that seems like it won't happen, nor is it
> really the purpose of the WG to do so.  We are picking from
> already-existing and implemented formats in the first place.
>

From harald@alvestrand.no  Fri Nov 22 04:39:11 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922B11ADF7B for ; Fri, 22 Nov 2013 04:39:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.911
X-Spam-Level: 
X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, URIBL_RHS_DOB=1.514] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JDUuZeq5Jhe for ; Fri, 22 Nov 2013 04:39:08 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 818A71AD9B8 for ; Fri, 22 Nov 2013 04:39:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E517739E4C2; Fri, 22 Nov 2013 13:38:58 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVL-WhOl4AWE; Fri, 22 Nov 2013 13:38:54 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AAAF139E240; Fri, 22 Nov 2013 13:38:54 +0100 (CET)
Message-ID: <528F505C.30200@alvestrand.no>
Date: Fri, 22 Nov 2013 13:38:52 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Lijing (Jessie)" ,  Magnus Westerlund , "rtcweb@ietf.org" 
References: <527BD94C.2070900@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Proposal for API mapping for RTP
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 12:39:11 -0000

On 11/22/2013 04:21 AM, Lijing (Jessie) wrote:
> A MediaStream contains multiple MediaStreamTrack, and different MediaStreams can share the same MediaStreamTrack. MediaStreamTrack within one MediaStream is synchronized.
>
> -----Does anywhere define how to describe same MST in different mediastreams in SDP? As I know, the current unified plan defines" One m-line == one MediaStreamTrack", so how can we mark multiple mediastreams in msid attribute?
> Allow msid carry more mediastream id?
> m=video1
> a=msid: ma ta; mb ta
>
> or have multiple msid attribute in one m line?
> m=vido1
> a=msid: ma ta
> a=msid: mb ta
>
> or we should expand other attribute?

My thinking is that the last one is the one to use; I have not defined 
special semantics for semicolons in MSID values, but the spec 
(draft-ietf-mmusic-msid-02) does say that there can be multiple msid 
attributes on a single m-line, and it seems logical to go that route.


>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund
> Sent: Friday, November 08, 2013 2:18 AM
> To: rtcweb@ietf.org
> Subject: [rtcweb] Proposal for API mapping for RTP
>
> WG,
> (As draft-ietf-rtcweb-rtp-usage Editor)
>
> There was discussion yesterday afternoon on the W3C MediaStream to RTP mapping. This did arrive on some conclusions that I here try to word into a proposal for everyones review.
>
> A MediaStreamTrack is sent over a source packet stream (one SSRC) and can have additionally redundancy packet streams (SSRCs). These redundnacy streams are RTP retranmission streams or FEC.
>
> When multiple MediaStreamTracks have the same Media Source, then the fact that one has creaeted multiple MediaStreamTracks and added these through a MediaStream to the PeerConnection is going to result in that each MediaStreamTrack will have its own source packet stream (one SSRC).
> This will be true, even if there are no difference in the configuration of the MediaStreamTrack. Thus no optimizations in regards to collapsing or aggregating multiple MediaStreamTrack onto a single source packet stream (SSRC). This is done for keeping things simple and straightforward.
>
> When it comes to the use of CNAME, an RTCWEB end-point shall within the context of one origin, i.e. a particular JS creating PeerConnections, use the same CNAME in all these PeerConnections, for all outgoing mediaStreamTracks. However, a end-point MUST be capable of receiving multiple different CNAMEs both within and between different RTP sessions and PeerConnections. This definition comes from the following observations.
>
> A MediaStream contains multiple MediaStreamTrack, and different MediaStreams can share the same MediaStreamTrack. MediaStreamTrack within one MediaStream is synchronized. Thus, at any point the JS application can create a new MediaStream that includes MediaStreamTrack from different context. To avoid needing to change all SSRC and put the SSRCs into a single CNAME at that point, we ensure that this can't happen.
>
> MediaStreamTracks that are being received in one PeerConnection and then forward by being added to another one will need to be re-synchronzied into the endpoints outgoing. We discussed and came to the agreement on Monday that forwarding would need to be done equivalent of decoding and recoding when forwarding. Implementations may do other things, but must function equivalent to this.
>
> The above have some forward interoperability properties. If one like to be able to use multiple CNAMEs that can be added given that W3C API ensures that you don't cause issue with what CNAME a particular SSRC belongs to. In addition if one like to optimize the cases where multiple MediaStreamTrack have a common media source that can be added.
>
> Disagreements, requests for clarifications?
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> 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


From bryandonnovan@gmail.com  Fri Nov 22 04:48:05 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A67E1AD9B8 for ; Fri, 22 Nov 2013 04:48:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.485
X-Spam-Level: 
X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptAvvisgHG-Q for ; Fri, 22 Nov 2013 04:48:02 -0800 (PST)
Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5B61C1AD9AD for ; Fri, 22 Nov 2013 04:48:02 -0800 (PST)
Received: by mail-ve0-f170.google.com with SMTP id oy12so850040veb.15 for ; Fri, 22 Nov 2013 04:47:55 -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=S/Lmn57l1wbylj3CvD/vs3CVI7MlxF6W3e6nwQP7Yw8=; b=nJmpRatXS9wzMg5cAx/t4RDl1236sNIrOSeI+2bSzd7Wa3378jzuEoW7zO2LEGOac8 3+h29WexEbN4cWkZ57IJOFmKuH93oWXClwQ8v0UA7B0QEQ8cvMYI6BSkMAMq1ps/a3ff bE5u2SOmFGPFduKnwyNOkg+/XEJwYfE2E/Is41Z1OhL83T/XXjwHEanbcRR5xHUgYk1h faqLrZEdqM5Ue7gYfwGEvYHywpKbd9qHeVsq9FJMYEV6YfIk3jDHvyL77I2sRijvKg9r x2ouG4oZc2KdrLB/8kKzn1kDws1KN6/S+UNL2Rr1f62iw1FxPIfnpfzptKBFO8QvStfG yzmQ==
MIME-Version: 1.0
X-Received: by 10.52.166.200 with SMTP id zi8mr465553vdb.38.1385124475129; Fri, 22 Nov 2013 04:47:55 -0800 (PST)
Received: by 10.52.231.233 with HTTP; Fri, 22 Nov 2013 04:47:55 -0800 (PST)
In-Reply-To: 
References:  
Date: Fri, 22 Nov 2013 04:47:55 -0800
Message-ID: 
From: bryandonnovan@gmail.com
To: Steve Kann 
Content-Type: multipart/alternative; boundary=089e01634aa64f5a5a04ebc36c98
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] H.261
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 12:48:05 -0000

--089e01634aa64f5a5a04ebc36c98
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Lots of uses will be 1:1 calls, and maybe 30% fallback applies in this
case.  My use of WebRTC involves 1:many group calls in the browser with an
MCU.  For 1:many, the options are 1) fallback to common codec and 2)
transcode.  So, for 1:many we can say that the chance of using the fallback
codec is 100%.  Assuming IE and Safari actually ship WebRTC.



On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann  wrote:

>
> Mo,
>
> I think we all agree that choosing H.264 or VP8 would be better, but it i=
s
> clear that neither option today has consensus.    Circumstances could
> change in the future, but it seems that OpenH264 was not enough to change
> that circumstance.
>
> I think that where your scenario might go astray is that users won=E2=80=
=99t
> associate their poor experience with =E2=80=9CWebRTC=E2=80=9D, or =E2=80=
=9Cthat web stuff=E2=80=9D =E2=80=94 they
> will associate it with the brand of the service which they are using at t=
he
> time.
>
> So, for example, if Facebook builds video chat using WebRTC, and they do
> no transcoding, 30% of users might associate their poor video with
> Facebook, but most of them won=E2=80=99t call it =E2=80=9Cthat web shit=
=E2=80=9D =E2=80=94 they would say
> Facebook video sucks.
>
> Of course, Facebook could decide to transcode 30% of the time, in which
> case the user would have a different experience.
>
> Facebook obviously just being used as an example service which might
> implement WebRTC video.
>
> -SteveK
>
>
>
> From: "Mo Zanaty (mzanaty)" 
> Date: Thursday, November 21, 2013 at 9:17 PM
> To: Basil Mohamed Gohar 
> Cc: "rtcweb@ietf.org" 
> Subject: [rtcweb] H.261
>
> On 11/21/13 12:48, Basil Mohamed Gohar  wrote:
>
> Has anyone actually objected to H.261 being the one MTI codec [...] ?
>
>
> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does
> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According =
to
> various (incredibly extrapolated, possibly inaccurate and sometimes
> conflicting) sources [1] on who uses what browser, the chance of H.261
> fallback is a whopping 30% [2]. Not the minor insignificant case some had
> assumed.
>
> How will these users react to H.261 QCIF/CIF compared to what they use
> today, say Skype for example? "This web shit really sucks. I=E2=80=99m go=
ing back
> to Skype and never trying it again." Is that the first (and perhaps last)
> impression we want from users that try webrtc? Those arguing crappy video
> is better than no video are ignoring the critical importance of first
> impressions. While some may accept crappy video as usable, many more may =
be
> permanently turned off and tune out even faster than if they got only
> (good) audio. It=E2=80=99s not as if webrtc is the only game in town. Use=
rs have
> options, so it needs to be competitive with competitive technology which
> has already set the bar.
>
> We previously narrowed the options down to H.264 and VP8 for good reasons
> over the course of this excruciatingly long decision. Reopening discarded
> tangents like H.261 does not move us forward as a workgroup, and certainl=
y
> does not move webrtc forward as a technology.
>
> Mo
>
> [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
> [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x (I=
E% +
> Safari%)
>
> _______________________________________________ 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
>
>

--089e01634aa64f5a5a04ebc36c98
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Lots of uses will be 1:1 calls, and maybe 30% fallback app=
lies in this case. =C2=A0My use of WebRTC involves 1:many group calls in th=
e browser with an MCU. =C2=A0For 1:many, the options are 1) fallback to com=
mon codec and 2) transcode. =C2=A0So, for 1:many we can say that the chance=
 of using the fallback codec is 100%. =C2=A0Assuming IE and Safari actually=
 ship WebRTC. =C2=A0
    



    On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann <stevek@stevek.com>=
 wrote:
    


    =
Mo,
    


    I think we all agree that choosing H.264 or VP8 would b=
e better, but it is clear that neither option today has consensus. =C2=A0 =
=C2=A0Circumstances could change in the future, but it seems that OpenH264 =
was not enough to change that circumstance.
    


    I think that where your scenario might go astray is tha=
t users won=E2=80=99t associate their poor experience with =E2=80=9CWebRTC=
=E2=80=9D, or =E2=80=9Cthat web stuff=E2=80=9D =E2=80=94 they will associat=
e it with the brand of the service which they are using at the time.
    


    So, for example, if Facebook builds video chat using We=
bRTC, and they do no transcoding, 30% of users might associate their poor v=
ideo with Facebook, but most of them won=E2=80=99t call it =E2=80=9Cthat we=
b shit=E2=80=9D =E2=80=94 they would say Facebook video sucks.
    


    Of course, Facebook could decide to transcode 30% of th=
e time, in which case the user would have a different experience.

    Facebook obviously just being used as an example service wh=
ich might implement WebRTC video.
    


    -SteveK



    
From:  "Mo Zanaty (mzanaty)&qu=
ot; <mzanaty@cisc=
o.com>
    Date:  Thursday, N=
ovember 21, 2013 at 9:17 PM
    
To:  Basil Mohamed Gohar <basilgohar@librevi=
deo.org>
    Cc:  "rtcweb@ietf.org" &=
lt;rtcweb@ietf.org=
>
    
Subject:  [rtcweb] H.261
    <=
div>
    

    On 11/21/13 12:48, Basil Mohamed Gohar <basilgohar@librevideo.org> wrote=
:
    

    Has anyone actually objected to H.261 being the one MTI codec [...] ?<=
/div>

    Assume this wins and all obey. Chrome=
 does H.261+VP8, Firefox does H.261+H.264+VP8, IE does H.261+H.264, Safari =
does H.261+H.264. According to various (incredibly extrapolated, possibly i=
naccurate and sometimes conflicting) sources [1] on who uses what
 browser, the chance of H.261 fallback is a whopping 30% [2]. Not the minor=
 insignificant case some had assumed.

    How will the=
se users react to H.261 QCIF/CIF compared to what they use today, say Skype=
 for example? "This web shit really sucks. I=E2=80=99m going back to S=
kype and never trying it again." Is that the first (and perhaps last) =
impression we want from users that
 try webrtc? Those arguing crappy video is better than no video are ignorin=
g the critical importance of first impressions. While some may accept crapp=
y video as usable, many more may be permanently turned off and tune out eve=
n faster than if they got only (good)
 audio. It=E2=80=99s not as if webrtc is the only game in town. Users have =
options, so it needs to be competitive with competitive technology which ha=
s already set the bar.

    We previously narrowed the =
options down to H.264 and VP8 for good reasons over the course of this excr=
uciatingly long decision. Reopening discarded tangents like H.261 does not =
move us forward as a workgroup, and certainly does not move webrtc forward
 as a technology.

    Mo

    

    [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x=
 (IE% + Safari%)

    

    _______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--089e01634aa64f5a5a04ebc36c98--

From srdonovan@usdonovans.com  Fri Nov 22 06:23:32 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86171ADF10 for ; Fri, 22 Nov 2013 06:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.12
X-Spam-Level: 
X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyCV7hoLFd1W for ; Fri, 22 Nov 2013 06:23:27 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [192.249.113.76]) by ietfa.amsl.com (Postfix) with ESMTP id D80A51AE142 for ; Fri, 22 Nov 2013 06:23:23 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50758 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VjrdU-0005HX-PA for rtcweb@ietf.org; Fri, 22 Nov 2013 06:23:13 -0800
Message-ID: <528F68CC.40106@usdonovans.com>
Date: Fri, 22 Nov 2013 08:23:08 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>  <528E7033.2090502@gmail.com>
In-Reply-To: <528E7033.2090502@gmail.com>
Content-Type: multipart/alternative; boundary="------------000409050107020200050403"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 14:23:32 -0000

This is a multi-part message in MIME format.
--------------000409050107020200050403
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

The conversation seems to have veered into an argument about the
alternatives and not the proposed selection process.  I'll attempt to
focus on the topic in the subject line.

I am personally uncomfortable with the process as proposed.  I am one of
those referred to as a "lurker" in previous emails.  This is my first
post to this mailing list.  I have, however, read hundreds/thousands of
emails sent to this list.  I have also signed the previous three rtcWEB
blue lists.  I have not participated in meetings via Jabber.

I do think it is very important for the WEBrtc ecosystem to have at
least one MTI video codec.  I am not an expert in video codecs.  I don't
care which codec is chosen but I do consider it very important that
there be at least one MTI codec. 

I do NOT think that inventing arbitrary criteria for determining if I am
eligible to vote is a good precedent to be setting in the IETF. 

I fully understand the desire to attempt to eliminate ballot-box
stuffing in this proposed process.  Especially after the rumors of
double humming during the hum/Jabber +1'ing in Vancouver.  Personally I
think it is a fools game to try to eliminate attempts to game the
system.  It is going to happen anytime there is as much passion tied to
the outcome as in this case.  Ballot box stuffing happens.  It happens
with humming -- witness the increase in meeting attendance for sessions
with important hums.  I happens with voting -- witness the problems
established entities/governments that have extensive experience with
running elections still have keeping elections free and fair.

I don't see the IETF, who has very little experience with voting, being
successful at running a free and fair vote.  I say this with utmost
respect for the IETF.  Much of that respect coming because it is built
on consensus, not voting.

How do I think the working group should move forward?  I see three
viable options:

1) A coin flip
2) Two modern MTI codes
3) MTI of h.261 plus a modern MTI codec

I like the coin flip options as it results in a lot less email from the
lobbyists.

Regards,

Steve

On 11/21/13 2:42 PM, Daniel-Constantin Mierla wrote:
> On 11/21/13 8:24 PM, David Singer wrote:
>> On Nov 21, 2013, at 10:26 , Peter Saint-Andre  wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 11/21/13 9:51 AM, Magnus Westerlund wrote:
>>>
>>>> The method we propose is based on Instant-runoff voting,
>>>> http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
>>>> understanding that the choice will be the winner according to the
>>>> Instant-runoff voting process.
>>> I have the greatest respect for the chairs, but this is an engraved
>>> invitation for people to appeal whatever decision might be reached.
>>>
>>> More fundamentally: Voting? At the IETF?? Really?!?
>>>
>>> I sincerely hope we can figure out a better process…
>>>
>> Me too.
>>
>> For example, the W3C uses a Call for Objections process, where the option with the weakest technical objection is selected.  I fear that voting will result in a decision that won’t be honored by a significant part of the population.  We don’t need just a mandate, we want the effect of an effective mandate.
> Same opinion here.
>
> IMO, it's very unlikely that only such voting will have proper 
> effectiveness and, more important, fairness. No matter 
> jabber/blue-sheets persons are allowed to vote or not, there was a lot 
> of activity on the mailing lists only from lobbyists. That said, it is 
> going to be a lot of influence from companies that bet on 'send many and 
> speak loud'. But there were many entities that preferred to speak with a 
> single and clear voice so far, not involving an army of email bots.
>
> Just dismissing everyone (people/companies/projects) that simply relied 
> on the usual 'consensus' policy, which doesn't require to step in front 
> unless the decision is likely to be what one doesn't want, does not look 
> fair at all. Many spent lot of time in actually doing work/implementing 
> webrtc specs so far.
>
> As highlighted before, the issue now is about selecting the voters. For 
> example, I see no reason not to allow anyone that was subscribed to any 
> webrtc mailing lists hosted by IETF and W3C - it is an indication of 
> interest more that many people that go at IEFT for touristic reasons. 
> Those that didn't actively participated in discussions so far on mailing 
> lists, they should eventually prove their involvement in other related 
> activities, with public references, such as:
>
> - implemented webrtc releated specs in an application or product
> - they participated to webrtc interop events
> - they presented on webrtc topic at some conferences out there
> - they wrote related IETF drafts
>
> Probably the list can continue with other activities ... but is clear 
> that the range of people interested in the topic is way larger. The 
> process of deciding who can vote might create a bigger issue than 
> deciding for vp8 or h264 (or other codec) with a flipping coin.
>
> Daniel
>


--------------000409050107020200050403
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    The conversation seems to
      have veered into an argument about the alternatives and not the
      proposed selection process.  I'll attempt to focus on the topic in
      the subject line.
    
      
    
      I am personally uncomfortable with the process as proposed.  I am
      one of those referred to as a "lurker" in previous emails.  This
      is my first post to this mailing list.  I have, however, read
      hundreds/thousands of emails sent to this list.  I have also
      signed the previous three rtcWEB blue lists.  I have not
      participated in meetings via Jabber.
    
      
    
      I do think it is very important for the WEBrtc ecosystem to have
      at least one MTI video codec.  I am not an expert in video
      codecs.  I don't care which codec is chosen but I do consider it
      very important that there be at least one MTI codec.  
    
      
    
      I do NOT think that inventing arbitrary criteria for determining
      if I am eligible to vote is a good precedent to be setting in the
      IETF.  
    
      
    
      I fully understand the desire to attempt to eliminate ballot-box
      stuffing in this proposed process.  Especially after the rumors of
      double humming during the hum/Jabber +1'ing in Vancouver. 
      Personally I think it is a fools game to try to eliminate attempts
      to game the system.  It is going to happen anytime there is as
      much passion tied to the outcome as in this case.  Ballot box
      stuffing happens.  It happens with humming -- witness the increase
      in meeting attendance for sessions with important hums.  I happens
      with voting -- witness the problems established
      entities/governments that have extensive experience with running
      elections still have keeping elections free and fair.
    
      
    
      I don't see the IETF, who has very little experience with voting,
      being successful at running a free and fair vote.  I say this with
      utmost respect for the IETF.  Much of that respect coming because
      it is built on consensus, not voting.
    
      
    
      How do I think the working group should move forward?  I see three
      viable options:
    
      
    
      1) A coin flip
    
      2) Two modern MTI codes
    
      3) MTI of h.261 plus a modern MTI codec
    
      
    
      I like the coin flip options as it results in a lot less email
      from the lobbyists.
    
      
    
      Regards,
    
      
    
      Steve
    
      
    
        
    
    On 11/21/13 2:42 PM, Daniel-Constantin
      Mierla wrote:
    
    
    
    
    
      
    On 11/21/13 8:24 PM, David Singer wrote:

    
      
    
        
    On Nov 21, 2013, at 10:26 , Peter Saint-Andre <stpeter@stpeter.im> wrote:


    
        
    
          
    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/21/13 9:51 AM, Magnus Westerlund wrote:


    
          
    
            
    The method we propose is based on Instant-runoff voting,
http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
understanding that the choice will be the winner according to the
Instant-runoff voting process.

    
          
    
          
    I have the greatest respect for the chairs, but this is an engraved
invitation for people to appeal whatever decision might be reached.

More fundamentally: Voting? At the IETF?? Really?!?

I sincerely hope we can figure out a better process…


    
        
    
        
    Me too.

For example, the W3C uses a Call for Objections process, where the option with the weakest technical objection is selected.  I fear that voting will result in a decision that won’t be honored by a significant part of the population.  We don’t need just a mandate, we want the effect of an effective mandate.

    
      
    
      
    Same opinion here.

IMO, it's very unlikely that only such voting will have proper 
effectiveness and, more important, fairness. No matter 
jabber/blue-sheets persons are allowed to vote or not, there was a lot 
of activity on the mailing lists only from lobbyists. That said, it is 
going to be a lot of influence from companies that bet on 'send many and 
speak loud'. But there were many entities that preferred to speak with a 
single and clear voice so far, not involving an army of email bots.

Just dismissing everyone (people/companies/projects) that simply relied 
on the usual 'consensus' policy, which doesn't require to step in front 
unless the decision is likely to be what one doesn't want, does not look 
fair at all. Many spent lot of time in actually doing work/implementing 
webrtc specs so far.

As highlighted before, the issue now is about selecting the voters. For 
example, I see no reason not to allow anyone that was subscribed to any 
webrtc mailing lists hosted by IETF and W3C - it is an indication of 
interest more that many people that go at IEFT for touristic reasons. 
Those that didn't actively participated in discussions so far on mailing 
lists, they should eventually prove their involvement in other related 
activities, with public references, such as:

- implemented webrtc releated specs in an application or product
- they participated to webrtc interop events
- they presented on webrtc topic at some conferences out there
- they wrote related IETF drafts

Probably the list can continue with other activities ... but is clear 
that the range of people interested in the topic is way larger. The 
process of deciding who can vote might create a bigger issue than 
deciding for vp8 or h264 (or other codec) with a flipping coin.

Daniel


    
    
    
    
    
  


--------------000409050107020200050403--

From john@jlc.net  Fri Nov 22 06:28:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D27F1AE0DB for ; Fri, 22 Nov 2013 06:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.725
X-Spam-Level: 
X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxIZhTfMf2cT for ; Fri, 22 Nov 2013 06:28:34 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B775E1ADFAA for ; Fri, 22 Nov 2013 06:28:34 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 0900AC94C0; Fri, 22 Nov 2013 09:28:26 -0500 (EST)
Date: Fri, 22 Nov 2013 09:28:26 -0500
From: John Leslie 
To: Stefan Slivinski 
Message-ID: <20131122142825.GB59496@verdi>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>  <528EBAB0.2010906@librevideo.org>  <528EBD4C.8070504@librevideo.org>  <7949EED078736C4881C92F656DC6F6C130EA9E6618@ausmsex00.austin.kmvtechnologies.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E6618@ausmsex00.austin.kmvtechnologies.com>
User-Agent: Mutt/1.4.1i
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 14:28:39 -0000

Stefan Slivinski  wrote:
> 
> So if you think of a really simple motion estimate engine where you
> search every possible location in the reference frame to find the
> best match using SAD as a block matching algorithm...guess what?
> There's a patent for that. If you then decide that if there isn'?t
> a really good match (high SAD), and you decide to do an intra search
> instead...guess what? There's a patent for that.

   Yes, we know -- software patents are big-time damage...

> I'm not trying to scare everyone but to argue that H.261 is somehow
> going to protect you from patent infringement is completely without
> merit.

   There's an important point here, which many folks _do_ seem to be
missing: you _can_ run afoul of perfectly "valid" patents implementing
20-year-old technology. It is not the job of the IETF to even warn you
about this; and it's _definitely_ not our job to say how you should
deal with it.

> My point here is we should be focusing on choosing the best technology

   No.

   We're absolutely not trying to find the "best technology". We all
agree that H.265 is better than H.264 and VP9 is better than VP8,
but we're not focusing on either of them. Likewise, we all agree
that H.263, while worse than either H.264 or VP8, is better than
H.261.

   We're trying to find a "good enough" technology to be Mandatory
To Implement. We've been trying for a long time; and we may end up
failing.

   H.261 holds real promise there -- you can find an _implementation_
that's more than 20 years old and copy it bit-for-bit, and have a
rock-solid "prior art" defense. (We're not saying that's what you
should do; but it's an option available to you.)

> and come up with a solution for dealing with patent trolls at some
> other level because it's going to be a wide spread concern, not just
> a video problem.

   That's not a problem for _us_ to solve -- nor is it entirely
rational to believe we will ever see it solved. I certainly agree
the problem is quite widespread; but different companies will choose
different paths to manage the risks. (As they should!)

--
John Leslie 

From derhoermi@gmx.net  Fri Nov 22 07:28:47 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59F81AE150 for ; Fri, 22 Nov 2013 07:28:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level: 
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h159p8RBD3qu for ; Fri, 22 Nov 2013 07:28:42 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 132951ADF77 for ; Fri, 22 Nov 2013 07:28:42 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.1.197]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MGXV6-1Vx1nu0KOG-00DJjW for ; Fri, 22 Nov 2013 16:28:34 +0100
From: Bjoern Hoehrmann 
To: Steve Donovan 
Date: Fri, 22 Nov 2013 16:28:36 +0100
Message-ID: <8uru89ha1p0cccvq5qr8mtcnl4mvmkelhk@hive.bjoern.hoehrmann.de>
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>  <528E7033.2090502@gmail.com> <528F68CC.40106@usdonovans.com>
In-Reply-To: <528F68CC.40106@usdonovans.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:BcI/i8YFxibASlHXP6oBQpUZcrfXLCUpKmf4kYnyLSJDHHBBOZr LE6U4nWC0NDc1svLlENX7s2yLVNvagKAZk7nk17tVCDsc9r9+l9Y+DlNfiU+bHDhIAH5oA+ zZbeo1vyooW/QMf/TarAluagMkgQ0j/s3hoKjJPSlIwwSwwvi2xxIj4THA3JoFhlMcjFrgn p8As8kMxk6LiVCljcWKUA==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 15:28:47 -0000

* Steve Donovan wrote:
>I am personally uncomfortable with the process as proposed.  I am one of
>those referred to as a "lurker" in previous emails.  This is my first
>post to this mailing list.  I have, however, read hundreds/thousands of
>emails sent to this list.  I have also signed the previous three rtcWEB
>blue lists.  I have not participated in meetings via Jabber.

>I do NOT think that inventing arbitrary criteria for determining if I am
>eligible to vote is a good precedent to be setting in the IETF. 

The proposed criteria boil down to that anyone who can point to public
IETF records of their past participation in the Working Group can vote.
That is the most predictable set of criteria, and not arbitrary at all.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From emcho@sip-communicator.org  Fri Nov 22 07:49:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EB41ADF8F for ; Fri, 22 Nov 2013 07:49:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lmMpuDC8SHB for ; Fri, 22 Nov 2013 07:49:34 -0800 (PST)
Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id E949A1AE19B for ; Fri, 22 Nov 2013 07:49:27 -0800 (PST)
Received: by mail-pb0-f52.google.com with SMTP id uo5so1465678pbc.11 for ; Fri, 22 Nov 2013 07:49:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BXU0Z4fwILGzWKBcVhTZ8N2T/VuY3czq816RQYS0Ff8=; b=msrfCDF5twI+AfnQWuluCwQrhB9O7rU9/aB9cBBTKaIdrwpGEPZqoOk74UM/exCfSd gbVMJwwE0LYQVkJ2uE+0ddsTIhyR2Cy3YMQ9CYaOqx/2ijhcOA3J18rlo4xAc8LXBDQc lXxkAW5GjEnv8dBFoBTOs0eJaEiGNRWxOCNBu4ETvjbUeaM2EEtJg60K7/IC4iZpMXxE f1VHCh9+ixkGsqyg1pHc4tvac5FFo/gsGttzfGPzl+sMPEjNa8WVEkJv2ih9neWZr5UI EwSyxtKQEuB83Qo9/hTa0kDEIFICvnS1EH4hMPxraOtehB4V5AE8P5X7p0v2kIBUT8F7 XCgQ==
X-Gm-Message-State: ALoCoQm2lS9sS3A1ex4hhayrn1zPnoZIwvsHBqiUW7t7WVTy9HNu7hr8O9rCj3831Z2GKqDwTFDC
X-Received: by 10.68.244.2 with SMTP id xc2mr3461008pbc.58.1385135360954; Fri, 22 Nov 2013 07:49:20 -0800 (PST)
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by mx.google.com with ESMTPSA id ik1sm27268811pbc.9.2013.11.22.07.49.20 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 07:49:20 -0800 (PST)
Received: by mail-pa0-f48.google.com with SMTP id rd3so1465551pab.35 for ; Fri, 22 Nov 2013 07:49:20 -0800 (PST)
X-Received: by 10.68.113.130 with SMTP id iy2mr4143311pbb.2.1385135360150; Fri, 22 Nov 2013 07:49:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.66.13.234 with HTTP; Fri, 22 Nov 2013 07:49:00 -0800 (PST)
In-Reply-To: <8uru89ha1p0cccvq5qr8mtcnl4mvmkelhk@hive.bjoern.hoehrmann.de>
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>  <528E7033.2090502@gmail.com> <528F68CC.40106@usdonovans.com> <8uru89ha1p0cccvq5qr8mtcnl4mvmkelhk@hive.bjoern.hoehrmann.de>
From: Emil Ivov 
Date: Fri, 22 Nov 2013 16:49:00 +0100
Message-ID: 
To: Bjoern Hoehrmann 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 15:49:39 -0000

On Fri, Nov 22, 2013 at 4:28 PM, Bjoern Hoehrmann  wrote:
> * Steve Donovan wrote:
>>I am personally uncomfortable with the process as proposed.  I am one of
>>those referred to as a "lurker" in previous emails.  This is my first
>>post to this mailing list.  I have, however, read hundreds/thousands of
>>emails sent to this list.  I have also signed the previous three rtcWEB
>>blue lists.  I have not participated in meetings via Jabber.
>
>>I do NOT think that inventing arbitrary criteria for determining if I am
>>eligible to vote is a good precedent to be setting in the IETF.
>
> The proposed criteria boil down to that anyone who can point to public
> IETF records of their past participation in the Working Group can vote.
> That is the most predictable set of criteria, and not arbitrary at all.

It does however produce a voter base that is of arbitrary relevance to
the choice that we are trying to make.

Emil

--
https://jitsi.org

From basilgohar@librevideo.org  Fri Nov 22 07:54:27 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7991AE3F9 for ; Fri, 22 Nov 2013 07:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJkDO0TIflUD for ; Fri, 22 Nov 2013 07:54:23 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id E8FA71AE3F7 for ; Fri, 22 Nov 2013 07:54:19 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id AAB7D659332 for ; Fri, 22 Nov 2013 10:54:12 -0500 (EST)
Message-ID: <528F7E21.7010803@librevideo.org>
Date: Fri, 22 Nov 2013 10:54:09 -0500
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>  <528E7033.2090502@gmail.com> <528F68CC.40106@usdonovans.com> <8uru89ha1p0cccvq5qr8mtcnl4mvmkelhk@hive.bjoern.hoehrmann.de> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 15:54:27 -0000

On 11/22/2013 10:49 AM, Emil Ivov wrote:
> On Fri, Nov 22, 2013 at 4:28 PM, Bjoern Hoehrmann  wrote:
>> * Steve Donovan wrote:
>>> I am personally uncomfortable with the process as proposed.  I am one of
>>> those referred to as a "lurker" in previous emails.  This is my first
>>> post to this mailing list.  I have, however, read hundreds/thousands of
>>> emails sent to this list.  I have also signed the previous three rtcWEB
>>> blue lists.  I have not participated in meetings via Jabber.
>>
>>> I do NOT think that inventing arbitrary criteria for determining if I am
>>> eligible to vote is a good precedent to be setting in the IETF.
>>
>> The proposed criteria boil down to that anyone who can point to public
>> IETF records of their past participation in the Working Group can vote.
>> That is the most predictable set of criteria, and not arbitrary at all.
> 
> It does however produce a voter base that is of arbitrary relevance to
> the choice that we are trying to make.
> 
> Emil
> 
> --
> https://jitsi.org

I'm not intentionally trying to be contrary here, but the ones making
the choice are exactly the ones mentioned - those that have, somehow,
participated (with some kind of documentation) in any of the venues
through which IETF operates and discusses the matter at hand.

How else should someone's relevance for voting be determined?  IETF
(historically) makes decisions via consensus at meetings and on e-mail
lists.

-- 
Libre Video
http://librevideo.org

From srdonovan@usdonovans.com  Fri Nov 22 07:57:23 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4FD1AE3FA for ; Fri, 22 Nov 2013 07:57:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RknwYUu0KXSN for ; Fri, 22 Nov 2013 07:57:21 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [192.249.113.76]) by ietfa.amsl.com (Postfix) with ESMTP id AA8111AE3F9 for ; Fri, 22 Nov 2013 07:57:21 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51098 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vjt6Y-00010B-05; Fri, 22 Nov 2013 07:57:14 -0800
Message-ID: <528F7ED9.7040908@usdonovans.com>
Date: Fri, 22 Nov 2013 09:57:13 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Bjoern Hoehrmann 
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>  <528E7033.2090502@gmail.com> <528F68CC.40106@usdonovans.com> <8uru89ha1p0cccvq5qr8mtcnl4mvmkelhk@hive.bjoern.hoehrmann.de>
In-Reply-To: <8uru89ha1p0cccvq5qr8mtcnl4mvmkelhk@hive.bjoern.hoehrmann.de>
Content-Type: multipart/alternative; boundary="------------010403020703080409010705"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 15:57:23 -0000

This is a multi-part message in MIME format.
--------------010403020703080409010705
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I've seen at least three criteria defined, each with its own logic and
each with its own flaws.

1) List posting by chair decided date + blue list
2) List posting by a chair decided date + blue list + Jabber participation
3) List membership + other related involvement where the burden of proof
of that involvement rests on the shoulders of the would be voter.

Labeling these "arbitrary" was maybe inappropriate.  My point, however,
is that the IETF does not have experience with running this kind of a
vote, at least not to my knowledge.  Attempting to define criteria at
this stage does strike me as a bit arbitrary and a process rife with
opportunity to actually lengthen the time it takes to make a decision.

Steve

On 11/22/13 9:28 AM, Bjoern Hoehrmann wrote:
> * Steve Donovan wrote:
>> I am personally uncomfortable with the process as proposed.  I am one of
>> those referred to as a "lurker" in previous emails.  This is my first
>> post to this mailing list.  I have, however, read hundreds/thousands of
>> emails sent to this list.  I have also signed the previous three rtcWEB
>> blue lists.  I have not participated in meetings via Jabber.
>> I do NOT think that inventing arbitrary criteria for determining if I am
>> eligible to vote is a good precedent to be setting in the IETF. 
> The proposed criteria boil down to that anyone who can point to public
> IETF records of their past participation in the Working Group can vote.
> That is the most predictable set of criteria, and not arbitrary at all.


--------------010403020703080409010705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I've seen at least three
      criteria defined, each with its own logic and each with its own
      flaws.
    
      
    
      1) List posting by chair decided date + blue list
    
      2) List posting by a chair decided date + blue list + Jabber
      participation
    
      3) List membership + other related involvement where the burden of
      proof of that involvement rests on the shoulders of the would be
      voter.
    
      
    
      Labeling these "arbitrary" was maybe inappropriate.  My point,
      however, is that the IETF does not have experience with running
      this kind of a vote, at least not to my knowledge.  Attempting to
      define criteria at this stage does strike me as a bit arbitrary
      and a process rife with opportunity to actually lengthen the time
      it takes to make a decision.
    
      
    
      Steve
    
      
    
        
    
    On 11/22/13 9:28 AM, Bjoern Hoehrmann
      wrote:
    
    
    
    
    
      
    * Steve Donovan wrote:

    
      
    
        
    I am personally uncomfortable with the process as proposed.  I am one of
those referred to as a "lurker" in previous emails.  This is my first
post to this mailing list.  I have, however, read hundreds/thousands of
emails sent to this list.  I have also signed the previous three rtcWEB
blue lists.  I have not participated in meetings via Jabber.

    
      
    
      
    
      
    
        
    I do NOT think that inventing arbitrary criteria for determining if I am
eligible to vote is a good precedent to be setting in the IETF. 

    
      
    
      
    The proposed criteria boil down to that anyone who can point to public
IETF records of their past participation in the Working Group can vote.
That is the most predictable set of criteria, and not arbitrary at all.

    
    
    
    
    
  


--------------010403020703080409010705--

From sslivinski@lifesize.com  Fri Nov 22 08:16:27 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071E51AE163 for ; Fri, 22 Nov 2013 08:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsI2E0fv4ipF for ; Fri, 22 Nov 2013 08:16:24 -0800 (PST)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id 1B4CB1ADFDA for ; Fri, 22 Nov 2013 08:16:22 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUo+DTng5K3Uvt863Ja37tbnfIeH458t/@postini.com; Fri, 22 Nov 2013 08:16:17 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 10:09:52 -0600
From: Stefan Slivinski 
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Date: Fri, 22 Nov 2013 10:09:49 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7nbQV3sTFvF7d3RpyCmDUGOXlt8AALveuw
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E6693@ausmsex00.austin.kmvtechnologies.com>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com> <528F30C1.8040208@it.aoyama.ac.jp>
In-Reply-To: <528F30C1.8040208@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "'rtcweb@ietf.org'" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 16:16:27 -0000

U29tZXRoaW5nIGVsc2Ugd29ydGggbm90aW5nIHdpdGggdGhlIHByb3Bvc2FsIG9mICJNVVNUIGlt
cGxlbWVudCBib3RoIFZQOCBhbmQgSC4yNjQgZGVjb2RlcnMsIGFuZCBNVVNUIGltcGxlbWVudCBh
dCBsZWFzdCBvbmUgb2YgVlA4IGFuZCBILjI2NCBlbmNvZGVycyIsIA0KSXQgYWxsb3dzIHlvdSB0
byBjaG9vc2UgdGhlIGFwcHJvcHJpYXRlIGNvZGVjIGZvciB5b3VyIGFyY2hpdGVjdHVyZSwgZXNw
ZWNpYWxseSB0aG9zZSBhcmNoaXRlY3R1cmVzIHdoZXJlIHRoZXJlIGlzIGhhcmR3YXJlIGFjY2Vs
ZXJhdGlvbiBmb3Igb25seSBvbmUgZW5jb2Rlci4gIEl0IHdvdWxkIGJlIHZlcnkgdW5kZXNpcmFi
bGUgZm9yIGEgdmVuZG9yIGJlIGFibGUgdG8gc2VuZCBILjI2NCBhdCAxMDgwcCBidXQgb25seSAz
NjBwIGZvciBWUDggYmVjYXVzZSB0aGV5IGRpZG7igJl0IGhhdmUgaGFyZHdhcmUgYWNjZWxlcmF0
aW9uIGF2YWlsYWJsZSBmb3IgaXQuICBEZWNvZGVycyBhcmUgbGVzcyBvZiBhIGNvbmNlcm4gYmVj
YXVzZSB0aGV5IGFyZSBmYXIgbGVzcyBjb21wbGV4Lg0KDQpBbm90aGVyIHBvaW50IHdvcnRoIG5v
dGluZzogIHRoZXJlIGFyZSBmYXIgbGVzcyBwYXRlbnRzIG9uIGRlY29kZXJzIHRoYW4gb24gZW5j
b2RlcnMsIHNvIGl0IGFsbG93cyBhIHZlbmRvciB0byBtaXRpZ2F0ZSB0aGVpciByaXNrIGJ5IGNo
b29zaW5nIHRoZSBlbmNvZGVyIHRoZXkgZmVlbCBtb3N0IGNvbWZvcnRhYmxlIHdpdGguDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiTWFydGluIEouIETDvHJzdCIgW21haWx0
bzpkdWVyc3RAaXQuYW95YW1hLmFjLmpwXSANClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMjIsIDIw
MTMgMjoyNCBBTQ0KVG86IFN0ZWZhbiBTbGl2aW5za2kNCkNjOiAncnRjd2ViQGlldGYub3JnJw0K
U3ViamVjdDogUmU6IFtydGN3ZWJdIFByb3Bvc2VkIFZpZGVvIFNlbGVjdGlvbiBQcm9jZXNzDQoN
Ck9uIDIwMTMvMTEvMjIgNTowMiwgU3RlZmFuIFNsaXZpbnNraSB3cm90ZToNCj4gSSBpbiBubyB3
YXkgaW50ZW5kZWQgdG8gc3VnZ2VzdCAgYSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiBvZiBhIHZp
ZGVvIA0KPiBjb2RlYy4gIE15IHF1ZXN0aW9uIHdhcyBhcm91bmQgd2hldGhlciB3ZSBhcmUgdm90
aW5nIG9uIHJlcXVpcmluZyANCj4gZGVjb2RlcnMgKG15IGFzc3VtcHRpb24pIG9yIGJvdGggZW5j
b2RlcnMgYW5kIGRlY29kZXJzDQoNCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBhbGwgdGhlIHBy
b3Bvc2FscyBpbiBlYWNoIGluc3RhbmNlIG1lYW4gImJvdGggZW5jb2RlciBhbmQgZGVjb2RlciIu
IFNvIGFzIGFuIGV4YW1wbGUsIGEgcHJvcG9zYWwgb2YgIk1VU1QgaW1wbGVtZW50IGJvdGggVlA4
IGFuZCBILjI2NCIgbWVhbnMgIk1VU1QgaW1wbGVtZW50IGJvdGggVlA4IGVuY29kZXIgYW5kIGRl
Y29kZXIsIGFuZCBILjI2NCBlbmNvZGVyIGFuZCBkZWNvZGVyIi4NCg0KWW91ciBxdWVzdGlvbiBi
cmluZ3MgdXAgb3RoZXIgY2hvaWNlcy4gRm9yIGV4YW1wbGUsIGludGVyb3BlcmFiaWxpdHkgd291
bGQgYmUgc2F0aXNmaWVkIGJ5IHNvbWV0aGluZyBsaWtlICJNVVNUIGltcGxlbWVudCBib3RoIFZQ
OCBhbmQgSC4yNjQgZGVjb2RlcnMsIGFuZCBNVVNUIGltcGxlbWVudCBhdCBsZWFzdCBvbmUgb2Yg
VlA4IGFuZCBILjI2NCBlbmNvZGVycyIuDQoNCk9uZSBjb25kaXRpb24gZm9yIHRoaXMgdG8gd29y
ayBpcyB0aGUgcG9zc2liaWxpdHkgb2YgYXN5bW1ldHJpYyBjb21tdW5pY2F0aW9uLCBpLmUuIGlm
IHNpZGUgQSBpbXBsZW1lbnRlZCBvbmx5IGEgVlA4IGVuY29kZXIsIGFuZCBzaWRlIEIgb25seSBp
bXBsZW1lbnRlZCBhIEguMjY0IGVuY29kZXIsIHRoZW4gdHJhZmZpYyBBLT5CIHdvdWxkIGJlIFZQ
OCwgd2hlcmVhcyB0cmFmZmljIEItPkEgd291bGQgYmUgSC4yNjQuIEkgZG9uJ3Qga25vdyB0aGUg
aW4ncyBhbmQgb3V0J3Mgb2YgdGhlIG5lZ290aWF0aW9uIGFuZCBwcm90b2NvbCBtYWNoaW5lcnkg
dG8gY29uZmlybSBvciBkZW55IHRoYXQgdGhpcyBpcyBwb3NzaWJsZS4NCg0KQ2hvaWNlcyBsaWtl
IHRoZSBvbmUgYWJvdmUgZGVmaW5pdGVseSBvcGVuIG5ldyBob3Jpem9ucyBmb3IgRXJpYydzIHNl
bGVjdGlvbiBnZW5lcmF0b3IuIEJ1dCBmcmFua2x5IHNwZWFraW5nLCBleGNlcHQgZm9yIHRoZSBz
cGVjaWZpYyBjaG9pY2Ugb2YgIk1VU1QgaW1wbGVtZW50IGJvdGggVlA4IGFuZCBILjI2NCBkZWNv
ZGVycywgYW5kIE1VU1QgaW1wbGVtZW50IGF0IGxlYXN0IG9uZSBvZiBWUDggYW5kIEguMjY0IGVu
Y29kZXJzIiwgd2hpY2ggaXMgbGVzcyBvbmVyb3VzIHRoYW4gIk1VU1QgaW1wbGVtZW50IGJvdGgg
VlA4IGFuZCBILjI2NCIsIGJ1dCBzdGlsbCBpbnRlcm9wZXJhYmxlLCBJIGRvbid0IHNlZSBhbnkg
Y2hvaWNlcyB3aXRoIGRpZmZlcmVudCByZXF1aXJlbWVudHMgZm9yIGVuY29kZXJzIGFuZCBkZWNv
ZGVycyB0aGF0IHdvdWxkIG1ha2Ugc2Vuc2UuDQoNClJlZ2FyZHMsICAgTWFydGluLg0KDQoNCj4g
LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiBCYXNpbCBNb2hhbWVkIEdvaGFy
IFttYWlsdG86YmFzaWxnb2hhckBsaWJyZXZpZGVvLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIE5v
dmVtYmVyIDIxLCAyMDEzIDAxOjU2IFBNDQo+IFRvOiBydGN3ZWJAaWV0Zi5vcmc8cnRjd2ViQGll
dGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUHJvcG9zZWQgVmlkZW8gU2VsZWN0aW9u
IFByb2Nlc3MNCj4NCj4gT24gMTEvMjEvMjAxMyAwMjozMSBQTSwgU3RlZmFuIFNsaXZpbnNraSB3
cm90ZToNCj4+IEknbSBhIG5ldyBjb21lciwgc28ganVzdCBhIGJyaWVmIGludHJvOiBJIGhhdmUg
YSBiYWNrZ3JvdW5kIA0KPj4gZGV2ZWxvcGluZyByZWFsIHRpbWUgdmlkZW8gY29kZWNzIGZvciBl
bWJlZGRlZCBkZXZpY2VzIHNvIEknbSBpbiBhIA0KPj4gcG9zaXRpb24gdG8gY29tbWVudCBhdCBh
IHRlY2huaWNhbCBsZXZlbCB3aXRoaW4gdGhpcyBncm91cA0KPj4NCj4+IEZvciBjbGFyaXR5IHB1
cnBvc2VzIHRoZSBwcm9wb3NlZCBhbHRlcm5hdGl2ZXMgaW4gTWFnbnVzJyBlbWFpbCBvbiBub3Yg
MTh0aDsgYXJlIHdlIHN0cmljdGx5IHNwZWFraW5nIGFib3V0IGRlY29kZXJzPyAgSGlzdG9yaWNh
bGx5IG1hbmRhdG9yeSByZXF1aXJlbWVudHMgYXJlIHRoZXkgcmVsYXRlIHRvIHZpZGVvIGNvbXBh
dGliaWxpdHkgZGVmaW5lIGp1c3QgdGhlIGRlY29kZXJzLiAgT2J2aW91c2x5IGlmIHRoZXJlIGlz
IG9ubHkgYSBzaW5nbGUgbWFuZGF0b3J5IHZpZGVvIGRlY29kZXIgdGhpcyBpbXBsaWVzIGEgbWFu
ZGF0b3J5IGVuY29kZXIsIGhvd2V2ZXIgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlcmUgYXJlIDIgbWFu
ZGF0b3J5IGRlY29kZXJzIG9ubHkgYSBzaW5nbGUgZW5jb2RlciBpcyB0ZWNobmljYWxseSByZXF1
aXJlZC4NCj4+DQo+PiBDbGFyaWZ5aW5nIHRoaXMgaXMgZmFpcmx5IGltcG9ydGFudCBiZWNhdXNl
IGluIHRoZSBjYXNlIG9mIGJvdGggaDI2NCANCj4+IGFuZCB2cDggKGFuZCBpbiB0aGUgZnV0dXJl
IHZwOSBhbmQgaDI2NSkgdGhlIGRlY29kZXIgY29tcGxleGl0eSBpcyANCj4+IGZhaXJseSBsb3cg
YW5kIGhhcmR3YXJlIGFjY2VsZXJhdGlvbiBpcyBub3QgY3JpdGljYWwgYnV0IGluIHRoZSBjYXNl
IA0KPj4gb2YgdGhlIGVuY29kZXJzIHdoZXJlIHRoZSBjb21wbGV4aXR5IGNhbiBiZSAzeCBvciB3
b3JzZSwgaGFyZHdhcmUgDQo+PiBhY2NlbGVyYXRpb24gYmVjb21lcyBpbmNyZWFzaW5nbHkgaW1w
b3J0YW50DQo+Pg0KPj4gU3RlZmFuDQo+DQo+IFdoYXQgaXMgYmVpbmcgc3BlY2lmaWVkIGFzIE1U
SSBpcyBhIGZvcm1hdCwgYW5kIG5vdCBhIHNwZWNpZmljIA0KPiBpbXBsZW1lbnRhdGlvbi4gIFNv
LCBNVEkgd2lsbCBub3QgdGFrZSB0aGUgZm9ybSBvZiAiT3BlbkgyNjQiIG9yIA0KPiAibGlidnB4
IiwgYnV0IHJhdGhlciwgIkguMjY0IENvbnN0cmFpbnRlZCBCYXNlbGluZSBQcm9maWxlIiBvciAi
VlA4Ii4NCj4NCj4gVGhlIHNhbWUgd2FzIGRvbmUgZm9yIHRoZSBNVEkgYXVkaW8gY29kZWMsIHdo
aWNoIGlzIE9wdXMsIG5vdCANCj4gKmxpYm9wdXMqLCB3aGljaCBpcyBvbmUgc3BlY2lmaWMgaW1w
bGVtZW50YXRpb24gb2YgdGhlIGNvZGVjLg0KPg0KPiBUaGVyZSB3YXMgYSBzdWdnZXN0aW9uIHRo
YXQgdGhlIFdHIGFsc28gb2ZmZXIgYSByZWZlcmVuY2UgDQo+IGltcGxlbWVudGF0aW9uIG9mIHRo
ZSBNVEkgY29kZWMgY2hvaWNlLCBidXQgdGhhdCBzZWVtcyBsaWtlIGl0IHdvbid0IA0KPiBoYXBw
ZW4sIG5vciBpcyBpdCByZWFsbHkgdGhlIHB1cnBvc2Ugb2YgdGhlIFdHIHRvIGRvIHNvLiAgV2Ug
YXJlIA0KPiBwaWNraW5nIGZyb20gYWxyZWFkeS1leGlzdGluZyBhbmQgaW1wbGVtZW50ZWQgZm9y
bWF0cyBpbiB0aGUgZmlyc3QgcGxhY2UuDQo+DQo=

From emcho@sip-communicator.org  Fri Nov 22 08:20:50 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0611ADFA5 for ; Fri, 22 Nov 2013 08:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51oZiCCZdeo7 for ; Fri, 22 Nov 2013 08:20:48 -0800 (PST)
Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id ABB9C1ADEA1 for ; Fri, 22 Nov 2013 08:20:48 -0800 (PST)
Received: by mail-pb0-f52.google.com with SMTP id uo5so1503785pbc.11 for ; Fri, 22 Nov 2013 08:20:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8+cMseVtQDF6z4upoJmu6EWZQPCnWZR8LOxvfHW/MDg=; b=G1wYAmT79aCF6IiB+MyIyWuwxCQ3cwucn+BZOKnISkkX9o8vLjTWBBftUlgRtOL2hh vmSmW+rDHsyH+AeizXnElBJhIohi6SXzb2XM/8X5QV6+qzUDxtyAC/QFxzZ2dwqatuBz dhsmeaSyrBglaFhvlP3PvZdjfzDAS2OfNz3KC2BZ0g4Bwkt3xlBFgB3EEZz4/RSL6+VV iyXTeE9JtAS/g7D14NikrLg8qBYs9fLVUlxN5ZqbtH9w/7O9c+X45kIDZ3fhYI/Se6XF xMqE7czKPKXHkQgTWjSfcLu8XirrqsklTB5gfRqibFOvSQdiWB2fyzG0wd5NQhsw1nK0 xZ4Q==
X-Gm-Message-State: ALoCoQmRduIWaJKcJ+o8nUiFIVpWX0j/+OzUi1r6JNGu4ma2j6IRGJXBwrmUMPWC/A0g5X0bbwKy
X-Received: by 10.68.106.98 with SMTP id gt2mr3594648pbb.61.1385137241740; Fri, 22 Nov 2013 08:20:41 -0800 (PST)
Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by mx.google.com with ESMTPSA id yh1sm54235809pbc.21.2013.11.22.08.20.41 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 08:20:41 -0800 (PST)
Received: by mail-pd0-f174.google.com with SMTP id y13so1448427pdi.19 for ; Fri, 22 Nov 2013 08:20:41 -0800 (PST)
X-Received: by 10.68.189.229 with SMTP id gl5mr1624850pbc.195.1385137241174; Fri, 22 Nov 2013 08:20:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.66.13.234 with HTTP; Fri, 22 Nov 2013 08:20:21 -0800 (PST)
In-Reply-To: <528F7E21.7010803@librevideo.org>
References: <528E39F4.4010706@ericsson.com> <528E5057.30408@stpeter.im>  <528E7033.2090502@gmail.com> <528F68CC.40106@usdonovans.com> <8uru89ha1p0cccvq5qr8mtcnl4mvmkelhk@hive.bjoern.hoehrmann.de>  <528F7E21.7010803@librevideo.org>
From: Emil Ivov 
Date: Fri, 22 Nov 2013 17:20:21 +0100
Message-ID: 
To: Basil Mohamed Gohar 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 16:20:50 -0000

On Fri, Nov 22, 2013 at 4:54 PM, Basil Mohamed Gohar
 wrote:
> On 11/22/2013 10:49 AM, Emil Ivov wrote:
>> On Fri, Nov 22, 2013 at 4:28 PM, Bjoern Hoehrmann  wrote:
>>> * Steve Donovan wrote:
>>>> I am personally uncomfortable with the process as proposed.  I am one of
>>>> those referred to as a "lurker" in previous emails.  This is my first
>>>> post to this mailing list.  I have, however, read hundreds/thousands of
>>>> emails sent to this list.  I have also signed the previous three rtcWEB
>>>> blue lists.  I have not participated in meetings via Jabber.
>>>
>>>> I do NOT think that inventing arbitrary criteria for determining if I am
>>>> eligible to vote is a good precedent to be setting in the IETF.
>>>
>>> The proposed criteria boil down to that anyone who can point to public
>>> IETF records of their past participation in the Working Group can vote.
>>> That is the most predictable set of criteria, and not arbitrary at all.
>>
>> It does however produce a voter base that is of arbitrary relevance to
>> the choice that we are trying to make.
>>
>> Emil
>>
>> --
>> https://jitsi.org
>
> I'm not intentionally trying to be contrary here, but the ones making
> the choice are exactly the ones mentioned - those that have, somehow,
> participated

Exactly, and the result is that this specific group of people get to
express their preference while everyone else doesn't

Why? What does make the former group more qualified than the latter to
make a choice that would impact the Internet? Are they somehow
expected to

A) have better understanding in international patent law?
B) possess considerable knowledge on existing video related patents worldwide?
C) have better knowledge of video encoding mechanisms?
D) possess Solomonic wisdom and capability to properly balance the
WebRTC ecosystem?
E) wield Psychic skills?
F) represent 51% of the expected WebRTC population?

I haven't seen any indication to that.

What I have seen is an intention to ask frequent flyers and SMTP users
to tell us what their favourite horse in the race is.

> (with some kind of documentation)

I don't think anyone has so far mentioned participation with
documentation as part of the criteria.

> in any of the venues
> through which IETF operates and discusses the matter at hand.
>
> How else should someone's relevance for voting be determined?

It can't be. It shouldn't be. That's why the IETF does not vote.

> IETF
> (historically) makes decisions via consensus at meetings and on e-mail
> lists.

Decisions via consensus are very, very different than opinion polls on
a subject where lack of consensus has been demonstrated.

If we can't reach consensus then we are in no position to mandate.

Emil

--
https://jitsi.org

From silviapfeiffer1@gmail.com  Fri Nov 22 08:24:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF62D1ADEA1 for ; Fri, 22 Nov 2013 08:24:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level: 
X-Spam-Status: No, score=-1.449 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjZLpF8m13Z2 for ; Fri, 22 Nov 2013 08:24:23 -0800 (PST)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDFC1ADBE5 for ; Fri, 22 Nov 2013 08:24:23 -0800 (PST)
Received: by mail-ob0-f180.google.com with SMTP id wo20so1530074obc.11 for ; Fri, 22 Nov 2013 08:24:16 -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=2CyxzvWf3QuOXwGDz2OihVdr4kS3M+iH1zzQBjMFouo=; b=ZX8qnkfQ6bE7Ck3xt6zMJbkRpotddhg2Gq78YJxRJ4rST8qcH+bs4oGTGAozk8gWKl 45Lye/E6VJS4jBn8lTBtTf91azNYs3SVlwha/PMfOvbaMGJtLch4wMOtTzThJGHonMRT W1//kkcFsakK1ywjjhJa9Y1KU3oPU2GVcmFr0L1ZRq+nMGGsH/iDQt1Wz+ClrNi/kFeg SkgdC9EFgRF21X5t4cGoOYtqPzip7JDeiVp6ep4r9WBvfkaMvTw5yORhIbuUYmduFdCf 7eLUkJN0qp/eh4TLVi2vlbd0BoVQfEVAlFei2ur0qNYlBHCIIRopPMXInY5eUM7a5J/K 9KKw==
MIME-Version: 1.0
X-Received: by 10.60.177.66 with SMTP id co2mr275794oec.85.1385137456217; Fri, 22 Nov 2013 08:24:16 -0800 (PST)
Received: by 10.76.68.164 with HTTP; Fri, 22 Nov 2013 08:24:15 -0800 (PST)
Received: by 10.76.68.164 with HTTP; Fri, 22 Nov 2013 08:24:15 -0800 (PST)
In-Reply-To: <528F30C1.8040208@it.aoyama.ac.jp>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com> <528F30C1.8040208@it.aoyama.ac.jp>
Date: Fri, 22 Nov 2013 08:24:15 -0800
Message-ID: 
From: Silvia Pfeiffer 
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= 
Content-Type: multipart/alternative; boundary=047d7bd6b03a0b0b6a04ebc67200
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 16:24:28 -0000

--047d7bd6b03a0b0b6a04ebc67200
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think this has value. It might bring apple and Microsoft to the table,
since decoding-only is often the less patent-affecting part.

Silvia.
On 22 Nov 2013 02:24, Martin J. D=FCrst  wrote:

> On 2013/11/22 5:02, Stefan Slivinski wrote:
>
>> I in no way intended to suggest  a specific implementation of a video
>> codec.  My question was around whether we are voting on requiring decode=
rs
>> (my assumption) or both encoders and decoders
>>
>
> My understanding is that all the proposals in each instance mean "both
> encoder and decoder". So as an example, a proposal of "MUST implement bot=
h
> VP8 and H.264" means "MUST implement both VP8 encoder and decoder, and
> H.264 encoder and decoder".
>
> Your question brings up other choices. For example, interoperability woul=
d
> be satisfied by something like "MUST implement both VP8 and H.264 decoder=
s,
> and MUST implement at least one of VP8 and H.264 encoders".
>
> One condition for this to work is the possibility of asymmetric
> communication, i.e. if side A implemented only a VP8 encoder, and side B
> only implemented a H.264 encoder, then traffic A->B would be VP8, whereas
> traffic B->A would be H.264. I don't know the in's and out's of the
> negotiation and protocol machinery to confirm or deny that this is possib=
le.
>
> Choices like the one above definitely open new horizons for Eric's
> selection generator. But frankly speaking, except for the specific choice
> of "MUST implement both VP8 and H.264 decoders, and MUST implement at lea=
st
> one of VP8 and H.264 encoders", which is less onerous than "MUST implemen=
t
> both VP8 and H.264", but still interoperable, I don't see any choices wit=
h
> different requirements for encoders and decoders that would make sense.
>
> Regards,   Martin.
>
>
>  ----- Original Message -----
>> From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
>> Sent: Thursday, November 21, 2013 01:56 PM
>> To: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Proposed Video Selection Process
>>
>> On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
>>
>>> I'm a new comer, so just a brief intro: I have a background developing
>>> real time video codecs for embedded devices so I'm in a position to com=
ment
>>> at a technical level within this group
>>>
>>> For clarity purposes the proposed alternatives in Magnus' email on nov
>>> 18th; are we strictly speaking about decoders?  Historically mandatory
>>> requirements are they relate to video compatibility define just the
>>> decoders.  Obviously if there is only a single mandatory video decoder =
this
>>> implies a mandatory encoder, however in the case where there are 2
>>> mandatory decoders only a single encoder is technically required.
>>>
>>> Clarifying this is fairly important because in the case of both h264 an=
d
>>> vp8 (and in the future vp9 and h265) the decoder complexity is fairly l=
ow
>>> and hardware acceleration is not critical but in the case of the encode=
rs
>>> where the complexity can be 3x or worse, hardware acceleration becomes
>>> increasingly important
>>>
>>> Stefan
>>>
>>
>> What is being specified as MTI is a format, and not a specific
>> implementation.  So, MTI will not take the form of "OpenH264" or
>> "libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8".
>>
>> The same was done for the MTI audio codec, which is Opus, not *libopus*,
>> which is one specific implementation of the codec.
>>
>> There was a suggestion that the WG also offer a reference implementation
>> of the MTI codec choice, but that seems like it won't happen, nor is it
>> really the purpose of the WG to do so.  We are picking from
>> already-existing and implemented formats in the first place.
>>
>>  _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--047d7bd6b03a0b0b6a04ebc67200
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    I think this has value. It might bring apple and Microsoft t=
o the table, since decoding-only is often the less patent-affecting part.

    Silvia.
    

    On 22 Nov 2013 02:24, Martin J. D=FCrst <duerst@it.aoyama.ac.jp> wrote:=

    
On 2013/11/22 5:02, Stefan Slivinski wrote:
    

    
I in no way intended to suggest =A0a specific implementation of a video cod=
ec. =A0My question was around whether we are voting on requiring decoders (=
my assumption) or both encoders and decoders
    

    

    
My understanding is that all the proposals in each instance mean "both=
 encoder and decoder". So as an example, a proposal of "MUST impl=
ement both VP8 and H.264" means "MUST implement both VP8 encoder =
and decoder, and H.264 encoder and decoder".
    


    
Your question brings up other choices. For example, interoperability would =
be satisfied by something like "MUST implement both VP8 and H.264 deco=
ders, and MUST implement at least one of VP8 and H.264 encoders".
    


    
One condition for this to work is the possibility of asymmetric communicati=
on, i.e. if side A implemented only a VP8 encoder, and side B only implemen=
ted a H.264 encoder, then traffic A->B would be VP8, whereas traffic B-&=
gt;A would be H.264. I don't know the in's and out's of the neg=
otiation and protocol machinery to confirm or deny that this is possible.


    
Choices like the one above definitely open new horizons for Eric's sele=
ction generator. But frankly speaking, except for the specific choice of &q=
uot;MUST implement both VP8 and H.264 decoders, and MUST implement at least=
 one of VP8 and H.264 encoders", which is less onerous than "MUST=
 implement both VP8 and H.264", but still interoperable, I don't s=
ee any choices with different requirements for encoders and decoders that w=
ould make sense.
    


    
Regards, =A0 Martin.
    

    

    

    
----- Original Message -----
    
From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
    
Sent: Thursday, November 21, 2013 01:56 PM
    
To: rtcweb@ietf.org<rtcweb@ietf.org>
    
Subject: Re: [rtcweb] Proposed Video Selection Process
    

    
On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
    

    
I'm a new comer, so just a brief intro: I have a background developing =
real time video codecs for embedded devices so I'm in a position to com=
ment at a technical level within this group
    

    
For clarity purposes the proposed alternatives in Magnus' email on nov =
18th; are we strictly speaking about decoders? =A0Historically mandatory re=
quirements are they relate to video compatibility define just the decoders.=
 =A0Obviously if there is only a single mandatory video decoder this implie=
s a mandatory encoder, however in the case where there are 2 mandatory deco=
ders only a single encoder is technically required.
    


    
Clarifying this is fairly important because in the case of both h264 and vp=
8 (and in the future vp9 and h265) the decoder complexity is fairly low and=
 hardware acceleration is not critical but in the case of the encoders wher=
e the complexity can be 3x or worse, hardware acceleration becomes increasi=
ngly important
    


    
Stefan
    

    

    
What is being specified as MTI is a format, and not a specific
    
implementation. =A0So, MTI will not take the form of "OpenH264" o=
r
    
"libvpx", but rather, "H.264 Constrainted Baseline Profile&q=
uot; or "VP8".
    

    
The same was done for the MTI audio codec, which is Opus, not *libopus*,
which is one specific implementation of the codec.
    

    
There was a suggestion that the WG also offer a reference implementation
of the MTI codec choice, but that seems like it won't happen, nor is it=

    
really the purpose of the WG to do so. =A0We are picking from
    
already-existing and implemented formats in the first place.
    

    

    
_______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb
    

    

--047d7bd6b03a0b0b6a04ebc67200--

From tim@phonefromhere.com  Fri Nov 22 08:41:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8DF1ADF72 for ; Fri, 22 Nov 2013 08:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSkQW1fP6OUX for ; Fri, 22 Nov 2013 08:40:57 -0800 (PST)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC8C1ADBE5 for ; Fri, 22 Nov 2013 08:40:56 -0800 (PST)
Received: (qmail 28962 invoked from network); 22 Nov 2013 16:40:48 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 10136
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 22 Nov 2013 16:40:48 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 2243218A036D; Fri, 22 Nov 2013 16:40:48 +0000 (GMT)
Received: from [10.10.5.18] (205.158.164.101.ptr.us.xo.net [205.158.164.101]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B47BA18A05C2; Fri, 22 Nov 2013 16:40:46 +0000 (GMT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_71F1EABD-1B6F-4BAC-ACAC-C3AA988DF887"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: tim panton 
In-Reply-To: 
Date: Fri, 22 Nov 2013 08:40:48 -0800
Message-Id: <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com> <528F30C1.8040208@it.aoyama.ac.jp> 
To: Silvia Pfeiffer 
X-Mailer: Apple Mail (2.1822)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 16:41:00 -0000

--Apple-Mail=_71F1EABD-1B6F-4BAC-ACAC-C3AA988DF887
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Surely this flies in the face of the whole O/A model, which imposes a =
sort of symmetry on the endpoints ?
(Unless there is some arcane SDP FRACK at play here).

T.

On 22 Nov 2013, at 08:24, Silvia Pfeiffer  =
wrote:

> I think this has value. It might bring apple and Microsoft to the =
table, since decoding-only is often the less patent-affecting part.
>=20
> Silvia.
>=20
> On 22 Nov 2013 02:24, Martin J. D=FCrst  =
wrote:
> On 2013/11/22 5:02, Stefan Slivinski wrote:
> I in no way intended to suggest  a specific implementation of a video =
codec.  My question was around whether we are voting on requiring =
decoders (my assumption) or both encoders and decoders
>=20
> My understanding is that all the proposals in each instance mean "both =
encoder and decoder". So as an example, a proposal of "MUST implement =
both VP8 and H.264" means "MUST implement both VP8 encoder and decoder, =
and H.264 encoder and decoder".
>=20
> Your question brings up other choices. For example, interoperability =
would be satisfied by something like "MUST implement both VP8 and H.264 =
decoders, and MUST implement at least one of VP8 and H.264 encoders".
>=20
> One condition for this to work is the possibility of asymmetric =
communication, i.e. if side A implemented only a VP8 encoder, and side B =
only implemented a H.264 encoder, then traffic A->B would be VP8, =
whereas traffic B->A would be H.264. I don't know the in's and out's of =
the negotiation and protocol machinery to confirm or deny that this is =
possible.
>=20
> Choices like the one above definitely open new horizons for Eric's =
selection generator. But frankly speaking, except for the specific =
choice of "MUST implement both VP8 and H.264 decoders, and MUST =
implement at least one of VP8 and H.264 encoders", which is less onerous =
than "MUST implement both VP8 and H.264", but still interoperable, I =
don't see any choices with different requirements for encoders and =
decoders that would make sense.
>=20
> Regards,   Martin.
>=20
>=20
> ----- Original Message -----
> From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
> Sent: Thursday, November 21, 2013 01:56 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Proposed Video Selection Process
>=20
> On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
> I'm a new comer, so just a brief intro: I have a background developing =
real time video codecs for embedded devices so I'm in a position to =
comment at a technical level within this group
>=20
> For clarity purposes the proposed alternatives in Magnus' email on nov =
18th; are we strictly speaking about decoders?  Historically mandatory =
requirements are they relate to video compatibility define just the =
decoders.  Obviously if there is only a single mandatory video decoder =
this implies a mandatory encoder, however in the case where there are 2 =
mandatory decoders only a single encoder is technically required.
>=20
> Clarifying this is fairly important because in the case of both h264 =
and vp8 (and in the future vp9 and h265) the decoder complexity is =
fairly low and hardware acceleration is not critical but in the case of =
the encoders where the complexity can be 3x or worse, hardware =
acceleration becomes increasingly important
>=20
> Stefan
>=20
> What is being specified as MTI is a format, and not a specific
> implementation.  So, MTI will not take the form of "OpenH264" or
> "libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8".
>=20
> The same was done for the MTI audio codec, which is Opus, not =
*libopus*,
> which is one specific implementation of the codec.
>=20
> There was a suggestion that the WG also offer a reference =
implementation
> of the MTI codec choice, but that seems like it won't happen, nor is =
it
> really the purpose of the WG to do so.  We are picking from
> already-existing and implemented formats in the first place.
>=20
> _______________________________________________
> 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


--Apple-Mail=_71F1EABD-1B6F-4BAC-ACAC-C3AA988DF887
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Surely =
this flies in the face of the whole O/A model, which imposes a sort of =
symmetry on the endpoints ?
    (Unless there is some arcane SDP FRACK =
at play =
here).

    T.

    On =
22 Nov 2013, at 08:24, Silvia Pfeiffer <silviapfeiffer1@gmail.com>=
; wrote:

    I think this has value. It might bring =
apple and Microsoft to the table, since decoding-only is often the less =
patent-affecting part.
    Silvia.
    

    On 22 Nov 2013 02:24, Martin J. D=FCrst =
<duerst@it.aoyama.ac.jp> =
wrote:
    
On 2013/11/22 5:02, Stefan Slivinski wrote:
    

    
I in no way intended to suggest  a specific implementation of a =
video codec.  My question was around whether we are voting on =
requiring decoders (my assumption) or both encoders and decoders
    

    

    
My understanding is that all the proposals in each instance mean "both =
encoder and decoder". So as an example, a proposal of "MUST implement =
both VP8 and H.264" means "MUST implement both VP8 encoder and decoder, =
and H.264 encoder and decoder".
    


    
Your question brings up other choices. For example, interoperability =
would be satisfied by something like "MUST implement both VP8 and H.264 =
decoders, and MUST implement at least one of VP8 and H.264 =
encoders".
    


    
One condition for this to work is the possibility of asymmetric =
communication, i.e. if side A implemented only a VP8 encoder, and side B =
only implemented a H.264 encoder, then traffic A->B would be VP8, =
whereas traffic B->A would be H.264. I don't know the in's and out's =
of the negotiation and protocol machinery to confirm or deny that this =
is possible.
    


    
Choices like the one above definitely open new horizons for Eric's =
selection generator. But frankly speaking, except for the specific =
choice of "MUST implement both VP8 and H.264 decoders, and MUST =
implement at least one of VP8 and H.264 encoders", which is less onerous =
than "MUST implement both VP8 and H.264", but still interoperable, I =
don't see any choices with different requirements for encoders and =
decoders that would make sense.
    


    
Regards,   Martin.
    

    

    

    
----- Original Message -----
    
From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
    
Sent: Thursday, November 21, 2013 01:56 PM
    
To: rtcweb@ietf.org<rtcweb@ietf.org>
    
Subject: Re: [rtcweb] Proposed Video Selection Process
    

    
On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
    

    
I'm a new comer, so just a brief intro: I have a background developing =
real time video codecs for embedded devices so I'm in a position to =
comment at a technical level within this group
    

    
For clarity purposes the proposed alternatives in Magnus' email on nov =
18th; are we strictly speaking about decoders?  Historically =
mandatory requirements are they relate to video compatibility define =
just the decoders.  Obviously if there is only a single mandatory =
video decoder this implies a mandatory encoder, however in the case =
where there are 2 mandatory decoders only a single encoder is =
technically required.
    


    
Clarifying this is fairly important because in the case of both h264 and =
vp8 (and in the future vp9 and h265) the decoder complexity is fairly =
low and hardware acceleration is not critical but in the case of the =
encoders where the complexity can be 3x or worse, hardware acceleration =
becomes increasingly important
    


    
Stefan
    

    

    
What is being specified as MTI is a format, and not a specific
    
implementation.  So, MTI will not take the form of "OpenH264" =
or
    
"libvpx", but rather, "H.264 Constrainted Baseline Profile" or =
"VP8".
    

    
The same was done for the MTI audio codec, which is Opus, not =
*libopus*,
    
which is one specific implementation of the codec.
    

    
There was a suggestion that the WG also offer a reference =
implementation
    
of the MTI codec choice, but that seems like it won't happen, nor is =
it
    
really the purpose of the WG to do so.  We are picking from
    
already-existing and implemented formats in the first place.
    

    

    
_______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
https://www.ietf.org/mailman/listinfo/rtcweb<=
br>

    
_______________________________________________
    rtcweb mailing =
list
    rtcweb@ietf.org
    https://www.ietf.or=
g/mailman/listinfo/rtcweb

    =

--Apple-Mail=_71F1EABD-1B6F-4BAC-ACAC-C3AA988DF887--

From bryandonnovan@gmail.com  Fri Nov 22 08:48:22 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68E31AE1F3 for ; Fri, 22 Nov 2013 08:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4IjTqToe_7Z for ; Fri, 22 Nov 2013 08:48:18 -0800 (PST)
Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id B6E1D1AE3EE for ; Fri, 22 Nov 2013 08:48:02 -0800 (PST)
Received: by mail-vb0-f48.google.com with SMTP id x16so1034303vbf.35 for ; Fri, 22 Nov 2013 08:47:55 -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=EktRLO48LXaF5Xlk1hbouysJ+fqB0JRgTo4rhRr+u1I=; b=DhstUYQxwIsHF1Vi3+rGGdxbkRVgZF8g/uN0xkD4pVE0vzPISlqeZ9ZgRYvoaX0+zc gl9XtaPRdlmJf3DCkuElXvs78stjJyvb8Cy99eR4tPp39KyXjflOyXq+kG/wDr5DcliJ 4sZYtBtQsRR7x8osNLogJ33PcCu/5qAMHyTTbvyQ85ZHZXvqrOtoCcTkQckr6mASrgXe bgEtdnICV8BOSxMArZmpFLqONIxOw/KTmLaaJlH4/xQvu6h7FjJCxFjfld4T4tz1/uuA 4sPvzqjnS+XTQmZLCDk+r06g8nKQlpSyIO4AjJA88B2IqyQa0RFMsOGEXZWpfR1UTSmv WKgA==
MIME-Version: 1.0
X-Received: by 10.52.160.130 with SMTP id xk2mr10218764vdb.24.1385138875508; Fri, 22 Nov 2013 08:47:55 -0800 (PST)
Received: by 10.52.231.233 with HTTP; Fri, 22 Nov 2013 08:47:55 -0800 (PST)
In-Reply-To: <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com> <528F30C1.8040208@it.aoyama.ac.jp>  <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com>
Date: Fri, 22 Nov 2013 08:47:55 -0800
Message-ID: 
From: bryandonnovan@gmail.com
To: tim panton 
Content-Type: multipart/alternative; boundary=089e0160caaea3bbe104ebc6c660
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 16:48:23 -0000

--089e0160caaea3bbe104ebc6c660
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

SDP can express sendonly and recvonly streams, so there is no inherent
problem with assymetry of codec choice.  But it would certainly complicate
things.

I would be in favor of a solution that allowed anyone (all browsers) to
decode both VP8 and h.264, no matter what they are capable of encoding.  In
my 1-to-many conference software, all streams are unidirectional.




On Fri, Nov 22, 2013 at 8:40 AM, tim panton  wrote:

> Surely this flies in the face of the whole O/A model, which imposes a sor=
t
> of symmetry on the endpoints ?
> (Unless there is some arcane SDP FRACK at play here).
>
> T.
>
>
> On 22 Nov 2013, at 08:24, Silvia Pfeiffer 
> wrote:
>
> I think this has value. It might bring apple and Microsoft to the table,
> since decoding-only is often the less patent-affecting part.
>
> Silvia.
> On 22 Nov 2013 02:24, Martin J. D=C3=BCrst  wrote=
:
>
>> On 2013/11/22 5:02, Stefan Slivinski wrote:
>>
>>> I in no way intended to suggest  a specific implementation of a video
>>> codec.  My question was around whether we are voting on requiring decod=
ers
>>> (my assumption) or both encoders and decoders
>>>
>>
>> My understanding is that all the proposals in each instance mean "both
>> encoder and decoder". So as an example, a proposal of "MUST implement bo=
th
>> VP8 and H.264" means "MUST implement both VP8 encoder and decoder, and
>> H.264 encoder and decoder".
>>
>> Your question brings up other choices. For example, interoperability
>> would be satisfied by something like "MUST implement both VP8 and H.264
>> decoders, and MUST implement at least one of VP8 and H.264 encoders".
>>
>> One condition for this to work is the possibility of asymmetric
>> communication, i.e. if side A implemented only a VP8 encoder, and side B
>> only implemented a H.264 encoder, then traffic A->B would be VP8, wherea=
s
>> traffic B->A would be H.264. I don't know the in's and out's of the
>> negotiation and protocol machinery to confirm or deny that this is possi=
ble.
>>
>> Choices like the one above definitely open new horizons for Eric's
>> selection generator. But frankly speaking, except for the specific choic=
e
>> of "MUST implement both VP8 and H.264 decoders, and MUST implement at le=
ast
>> one of VP8 and H.264 encoders", which is less onerous than "MUST impleme=
nt
>> both VP8 and H.264", but still interoperable, I don't see any choices wi=
th
>> different requirements for encoders and decoders that would make sense.
>>
>> Regards,   Martin.
>>
>>
>>  ----- Original Message -----
>>> From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
>>> Sent: Thursday, November 21, 2013 01:56 PM
>>> To: rtcweb@ietf.org
>>> Subject: Re: [rtcweb] Proposed Video Selection Process
>>>
>>> On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
>>>
>>>> I'm a new comer, so just a brief intro: I have a background developing
>>>> real time video codecs for embedded devices so I'm in a position to co=
mment
>>>> at a technical level within this group
>>>>
>>>> For clarity purposes the proposed alternatives in Magnus' email on nov
>>>> 18th; are we strictly speaking about decoders?  Historically mandatory
>>>> requirements are they relate to video compatibility define just the
>>>> decoders.  Obviously if there is only a single mandatory video decoder=
 this
>>>> implies a mandatory encoder, however in the case where there are 2
>>>> mandatory decoders only a single encoder is technically required.
>>>>
>>>> Clarifying this is fairly important because in the case of both h264
>>>> and vp8 (and in the future vp9 and h265) the decoder complexity is fai=
rly
>>>> low and hardware acceleration is not critical but in the case of the
>>>> encoders where the complexity can be 3x or worse, hardware acceleratio=
n
>>>> becomes increasingly important
>>>>
>>>> Stefan
>>>>
>>>
>>> What is being specified as MTI is a format, and not a specific
>>> implementation.  So, MTI will not take the form of "OpenH264" or
>>> "libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8".
>>>
>>> The same was done for the MTI audio codec, which is Opus, not *libopus*=
,
>>> which is one specific implementation of the codec.
>>>
>>> There was a suggestion that the WG also offer a reference implementatio=
n
>>> of the MTI codec choice, but that seems like it won't happen, nor is it
>>> really the purpose of the WG to do so.  We are picking from
>>> already-existing and implemented formats in the first place.
>>>
>>>  _______________________________________________
>> 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
>
>

--089e0160caaea3bbe104ebc6c660
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    SDP can express sendonly and recvonly streams, so the=
re is no inherent problem with assymetry of codec choice. =C2=A0But it woul=
d certainly complicate things.

    I would be in favor=
 of a solution that allowed anyone (all browsers) to decode both VP8 and h.=
264, no matter what they are capable of encoding. =C2=A0In my 1-to-many con=
ference software, all streams are unidirectional.=C2=A0
    





    On Fri, Nov 22, 2013 at 8:40 AM, tim panton &=
lt;tim@phonefrom=
here.com> wrote:
    

    Surely t=
his flies in the face of the whole O/A model, which imposes a sort of symme=
try on the endpoints ?
    
(Unless there is some arcane SDP FRACK at play here).

    T.

    

    On 22 Nov 2013, at 08:24, Silvia Pfeiffer <silviapfeiffer1@=
gmail.com> wrote:

    =
I think this has value. It might bring apple and Microsoft to the table, si=
nce decoding-only is often the less patent-affecting part.
    

    Silvia.
    

    On 22 Nov 2013 02:24, Martin J. D=C3=BCrst <<=
a href=3D"mailto:duerst@it.aoyama.ac.jp" target=3D"_blank">duerst@it.aoyama=
.ac.jp> wrote:
    
I in no way intended to suggest =C2=A0a specific implementation of a video =
codec. =C2=A0My question was around whether we are voting on requiring deco=
ders (my assumption) or both encoders and decoders
    

    

    
My understanding is that all the proposals in each instance mean "both=
 encoder and decoder". So as an example, a proposal of "MUST impl=
ement both VP8 and H.264" means "MUST implement both VP8 encoder =
and decoder, and H.264 encoder and decoder".
    



    
Your question brings up other choices. For example, interoperability would =
be satisfied by something like "MUST implement both VP8 and H.264 deco=
ders, and MUST implement at least one of VP8 and H.264 encoders".
    



    
One condition for this to work is the possibility of asymmetric communicati=
on, i.e. if side A implemented only a VP8 encoder, and side B only implemen=
ted a H.264 encoder, then traffic A->B would be VP8, whereas traffic B-&=
gt;A would be H.264. I don't know the in's and out's of the neg=
otiation and protocol machinery to confirm or deny that this is possible.



    
Choices like the one above definitely open new horizons for Eric's sele=
ction generator. But frankly speaking, except for the specific choice of &q=
uot;MUST implement both VP8 and H.264 decoders, and MUST implement at least=
 one of VP8 and H.264 encoders", which is less onerous than "MUST=
 implement both VP8 and H.264", but still interoperable, I don't s=
ee any choices with different requirements for encoders and decoders that w=
ould make sense.
    



    
Regards, =C2=A0 Martin.
    

    

    

    
----- Original Message -----
    
From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
    
Sent: Thursday, November 21, 2013 01:56 PM
    
To: rtcweb@ietf.org<rtcweb@ietf.org>
    
Subject: Re: [rtcweb] Proposed Video Selection Process
    

    
On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
    

    
I'm a new comer, so just a brief intro: I have a background developing =
real time video codecs for embedded devices so I'm in a position to com=
ment at a technical level within this group
    

    
For clarity purposes the proposed alternatives in Magnus' email on nov =
18th; are we strictly speaking about decoders? =C2=A0Historically mandatory=
 requirements are they relate to video compatibility define just the decode=
rs. =C2=A0Obviously if there is only a single mandatory video decoder this =
implies a mandatory encoder, however in the case where there are 2 mandator=
y decoders only a single encoder is technically required.
    



    
Clarifying this is fairly important because in the case of both h264 and vp=
8 (and in the future vp9 and h265) the decoder complexity is fairly low and=
 hardware acceleration is not critical but in the case of the encoders wher=
e the complexity can be 3x or worse, hardware acceleration becomes increasi=
ngly important
    



    
Stefan
    

    

    
What is being specified as MTI is a format, and not a specific
    
implementation. =C2=A0So, MTI will not take the form of "OpenH264"=
; or
    
"libvpx", but rather, "H.264 Constrainted Baseline Profile&q=
uot; or "VP8".
    

    
The same was done for the MTI audio codec, which is Opus, not *libopus*,
which is one specific implementation of the codec.
    

    
There was a suggestion that the WG also offer a reference implementation
of the MTI codec choice, but that seems like it won't happen, nor is it=

    
really the purpose of the WG to do so. =C2=A0We are picking from
    
already-existing and implemented formats in the first place.
    

    

    
_______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb
    

    
_______________________________________________
    rtcweb mailing list
    <=
a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
    =
=
https://www.ietf.org/mailman/listinfo/rtcweb
    



    __________________=
_____________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
    
=
https://www.ietf.org/mailman/listinfo/rtcweb
    


    

--089e0160caaea3bbe104ebc6c660--

From sslivinski@lifesize.com  Fri Nov 22 08:52:37 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A1F1AE3A5 for ; Fri, 22 Nov 2013 08:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNy49N_uXotH for ; Fri, 22 Nov 2013 08:52:35 -0800 (PST)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id 4BF381AE39B for ; Fri, 22 Nov 2013 08:52:35 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUo+Lxi1BECxttIFYaLJeQtlmi7vz6U2H@postini.com; Fri, 22 Nov 2013 08:52:28 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 10:47:35 -0600
From: Stefan Slivinski 
To: John Leslie 
Date: Fri, 22 Nov 2013 10:47:33 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7njx5J16lJ9RueT6OPd4nzhYEJ4QADjCaQ
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E66A6@ausmsex00.austin.kmvtechnologies.com>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>  <528EBAB0.2010906@librevideo.org>  <528EBD4C.8070504@librevideo.org>  <7949EED078736C4881C92F656DC6F6C130EA9E6618@ausmsex00.austin.kmvtechnologies.com> <20131122142825.GB59496@verdi>
In-Reply-To: <20131122142825.GB59496@verdi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 16:52:37 -0000

The best technology is not simply which codec has the greatest compression =
efficiency, it is a function of complexity, performance, cost, error resili=
ency and many more. =20

Today there exists no hardware acceleration for H.265 which means you will =
be hard pressed to do 720p30 encode on a high end laptop, something that ev=
en a low end, 3 year old intel can do without breaking a sweat.  On portabl=
e platforms like tablets and smartphones doing the encoder is software is g=
oing to make it impossible to do larger resolutions and it's going to kill =
the battery.  All of these have to be factors in deciding what is the best =
technology.

-----Original Message-----
From: John Leslie [mailto:john@jlc.net]=20
Sent: Friday, November 22, 2013 6:28 AM
To: Stefan Slivinski
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process

Stefan Slivinski  wrote:
>=20
> So if you think of a really simple motion estimate engine where you=20
> search every possible location in the reference frame to find the best=20
> match using SAD as a block matching algorithm...guess what?
> There's a patent for that. If you then decide that if there isn'?t a=20
> really good match (high SAD), and you decide to do an intra search=20
> instead...guess what? There's a patent for that.

   Yes, we know -- software patents are big-time damage...

> I'm not trying to scare everyone but to argue that H.261 is somehow=20
> going to protect you from patent infringement is completely without=20
> merit.

   There's an important point here, which many folks _do_ seem to be
missing: you _can_ run afoul of perfectly "valid" patents implementing 20-y=
ear-old technology. It is not the job of the IETF to even warn you about th=
is; and it's _definitely_ not our job to say how you should deal with it.

> My point here is we should be focusing on choosing the best technology

   No.

   We're absolutely not trying to find the "best technology". We all agree =
that H.265 is better than H.264 and VP9 is better than VP8, but we're not f=
ocusing on either of them. Likewise, we all agree that H.263, while worse t=
han either H.264 or VP8, is better than H.261.

   We're trying to find a "good enough" technology to be Mandatory To Imple=
ment. We've been trying for a long time; and we may end up failing.

   H.261 holds real promise there -- you can find an _implementation_ that'=
s more than 20 years old and copy it bit-for-bit, and have a rock-solid "pr=
ior art" defense. (We're not saying that's what you should do; but it's an =
option available to you.)

> and come up with a solution for dealing with patent trolls at some=20
> other level because it's going to be a wide spread concern, not just a=20
> video problem.

   That's not a problem for _us_ to solve -- nor is it entirely rational to=
 believe we will ever see it solved. I certainly agree the problem is quite=
 widespread; but different companies will choose different paths to manage =
the risks. (As they should!)

--
John Leslie 

From juberti@google.com  Fri Nov 22 08:53:53 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6901AE3BD for ; Fri, 22 Nov 2013 08:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.389
X-Spam-Level: 
X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffRquL8ll56f for ; Fri, 22 Nov 2013 08:53:51 -0800 (PST)
Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 364021ADFB6 for ; Fri, 22 Nov 2013 08:53:51 -0800 (PST)
Received: by mail-vb0-f50.google.com with SMTP id 10so1083506vbe.9 for ; Fri, 22 Nov 2013 08:53:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=f/zcYLrlxe3RLojdToGXDiZ+CLbtmgI4bXyH5/Dg9B4=; b=dP/49C7Qni9Cq6sH3rw2FbczvL6h4j4AQTLgwh39V/x10HnblbILwsYH58J93ffI4y NoDU3v1gXh6wWi7OpNk3sOXvZw6np9J9wTQ41ABtDc6kqKCEQlUCsEjCMlj+qphHyMvy Yj7l+p7S2ReqtocdsAJMbIHqZcuF4kBRnhXhL5I8BvGWMdrZpDhjKV+6sqqoZ5grKM5z xpX8SLHCMI+tmmTPADqhUVJMe1oiMqmqzXIIsOYHc8LuvqKJIEdfZ2DAUSAmyCIY4Yv2 lIlkdJIQdICtrjQ5WnRRn7BcD/CxGyHe9IozxeYG7Z4e9RJJUokJofrp6HGAv0RPDrC6 1lbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=f/zcYLrlxe3RLojdToGXDiZ+CLbtmgI4bXyH5/Dg9B4=; b=YrGPx/6XcnWrdK0f0OLlLHlkoHU3SqYufxUgCYVY2lGDaJcR+CVUmpH1QljgLBGwBr RK1ExbWcRokCqiiNLE0/tcAs4Yonp/HNMpD8K8K5SP3udwITNKocGwCV9DsmEok62L38 R/q8wBUM/9QZnE7psfANaL7kwPmxU0tLd6xVkM2HPw0fmNfeyAS28ueJuhmoGB4C9e2S M2AXe4BKHIb9ZbyaRY9VS9cF2l+rZNFbi5fJo5fw42Vl9+WSYb6McG0ayMrE8Kt2tYZI TMNKOqdx0xJQWFLGi4tFFTBpVl2RlYKxcRuWJiW4v9IsAl4e0YD82KU3p/uPcRCrBSkc 369A==
X-Gm-Message-State: ALoCoQl4CH/2fBZdotGZEwGszjv1/g/wZuTj0gChLgy9RvtuBuYL/ezkopuh6oqNzsim/IR9Yoo2TEnaPcTfgekKk88swtXWyANHjy3d56NMZUSNyr5b5cDEXh4PPOtMBXgi+3AxnznO57wKONVHT9SMeh9W4mKTvh0sYeUMdQGjimb/l+XjSPvucu1vEreutq9GizkCji01
X-Received: by 10.58.23.33 with SMTP id j1mr2670621vef.27.1385139223920; Fri, 22 Nov 2013 08:53:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 22 Nov 2013 08:53:23 -0800 (PST)
In-Reply-To: 
References:   
From: Justin Uberti 
Date: Fri, 22 Nov 2013 08:53:23 -0800
Message-ID: 
To: bryandonnovan@gmail.com
Content-Type: multipart/alternative; boundary=047d7b339df96818de04ebc6dbb6
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] H.261
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 16:53:53 -0000

--047d7b339df96818de04ebc6dbb6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

For 1:many with MCU, I don't understand why you wouldn't do #2, i.e.
transcode. As stated earlier, the bandwidth costs of using an inefficient
codec (which any MCU service will incur) exceed the CPU cost of transcode.


On Fri, Nov 22, 2013 at 4:47 AM,  wrote:

> Lots of uses will be 1:1 calls, and maybe 30% fallback applies in this
> case.  My use of WebRTC involves 1:many group calls in the browser with a=
n
> MCU.  For 1:many, the options are 1) fallback to common codec and 2)
> transcode.  So, for 1:many we can say that the chance of using the fallba=
ck
> codec is 100%.  Assuming IE and Safari actually ship WebRTC.
>
>
>
> On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann  wrote:
>
>>
>> Mo,
>>
>> I think we all agree that choosing H.264 or VP8 would be better, but it
>> is clear that neither option today has consensus.    Circumstances could
>> change in the future, but it seems that OpenH264 was not enough to chang=
e
>> that circumstance.
>>
>> I think that where your scenario might go astray is that users won=E2=80=
=99t
>> associate their poor experience with =E2=80=9CWebRTC=E2=80=9D, or =E2=80=
=9Cthat web stuff=E2=80=9D =E2=80=94 they
>> will associate it with the brand of the service which they are using at =
the
>> time.
>>
>> So, for example, if Facebook builds video chat using WebRTC, and they do
>> no transcoding, 30% of users might associate their poor video with
>> Facebook, but most of them won=E2=80=99t call it =E2=80=9Cthat web shit=
=E2=80=9D =E2=80=94 they would say
>> Facebook video sucks.
>>
>> Of course, Facebook could decide to transcode 30% of the time, in which
>> case the user would have a different experience.
>>
>> Facebook obviously just being used as an example service which might
>> implement WebRTC video.
>>
>> -SteveK
>>
>>
>>
>> From: "Mo Zanaty (mzanaty)" 
>> Date: Thursday, November 21, 2013 at 9:17 PM
>> To: Basil Mohamed Gohar 
>> Cc: "rtcweb@ietf.org" 
>> Subject: [rtcweb] H.261
>>
>> On 11/21/13 12:48, Basil Mohamed Gohar  wrote=
:
>>
>> Has anyone actually objected to H.261 being the one MTI codec [...] ?
>>
>>
>> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does
>> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. According=
 to
>> various (incredibly extrapolated, possibly inaccurate and sometimes
>> conflicting) sources [1] on who uses what browser, the chance of H.261
>> fallback is a whopping 30% [2]. Not the minor insignificant case some ha=
d
>> assumed.
>>
>> How will these users react to H.261 QCIF/CIF compared to what they use
>> today, say Skype for example? "This web shit really sucks. I=E2=80=99m g=
oing back
>> to Skype and never trying it again." Is that the first (and perhaps last=
)
>> impression we want from users that try webrtc? Those arguing crappy vide=
o
>> is better than no video are ignoring the critical importance of first
>> impressions. While some may accept crappy video as usable, many more may=
 be
>> permanently turned off and tune out even faster than if they got only
>> (good) audio. It=E2=80=99s not as if webrtc is the only game in town. Us=
ers have
>> options, so it needs to be competitive with competitive technology which
>> has already set the bar.
>>
>> We previously narrowed the options down to H.264 and VP8 for good reason=
s
>> over the course of this excruciatingly long decision. Reopening discarde=
d
>> tangents like H.261 does not move us forward as a workgroup, and certain=
ly
>> does not move webrtc forward as a technology.
>>
>> Mo
>>
>> [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
>> [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x (=
IE% +
>> Safari%)
>>
>> _______________________________________________ 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
>
>

--047d7b339df96818de04ebc6dbb6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    For 1:many with MCU, I don't understand why you wouldn=
't do #2, i.e. transcode. As stated earlier, the bandwidth costs of usi=
ng an inefficient codec (which any MCU service will incur) exceed the CPU c=
ost of transcode.
    




    On Fri, Nov 2=
2, 2013 at 4:47 AM,  <bryandonnovan@gmail.com> wrote:<=
br>
    


    Lots of uses will be 1:1 calls, and maybe 30% fallback app=
lies in this case. =C2=A0My use of WebRTC involves 1:many group calls in th=
e browser with an MCU. =C2=A0For 1:many, the options are 1) fallback to com=
mon codec and 2) transcode. =C2=A0So, for 1:many we can say that the chance=
 of using the fallback codec is 100%. =C2=A0Assuming IE and Safari actually=
 ship WebRTC. =C2=A0
    





    On Thu, Nov 21, 2013 at 10:11 PM=
, Steve Kann <stevek@stevek.com> wrote:
    




    =
Mo,
    




    I think we all agree that choosing H.264 or VP8 would b=
e better, but it is clear that neither option today has consensus. =C2=A0 =
=C2=A0Circumstances could change in the future, but it seems that OpenH264 =
was not enough to change that circumstance.
    




    I think that where your scenario might go astray is tha=
t users won=E2=80=99t associate their poor experience with =E2=80=9CWebRTC=
=E2=80=9D, or =E2=80=9Cthat web stuff=E2=80=9D =E2=80=94 they will associat=
e it with the brand of the service which they are using at the time.
    




    So, for example, if Facebook builds video chat using We=
bRTC, and they do no transcoding, 30% of users might associate their poor v=
ideo with Facebook, but most of them won=E2=80=99t call it =E2=80=9Cthat we=
b shit=E2=80=9D =E2=80=94 they would say Facebook video sucks.
    




    Of course, Facebook could decide to transcode 30% of th=
e time, in which case the user would have a different experience.

    Facebook obviously just being used as an example service wh=
ich might implement WebRTC video.
    




    -SteveK



    


From:  "Mo Zanaty (mzanaty)&qu=
ot; <mzanaty@cisc=
o.com>
    Date:  Thursday, N=
ovember 21, 2013 at 9:17 PM
    


To:  Basil Mohamed Gohar <basilgohar@librevi=
deo.org>
    Cc:  "rtcweb@ietf.org" &=
lt;rtcweb@ietf.org=
>
    


Subject:  [rtcweb] H.261
    <=
div>
    



    On 11/21/13 12:48, Basil Mohamed Gohar <basilgohar@librevideo.org> wrote=
:
    



    Has anyone actually objected to H.261 being the one MTI codec [...] ?<=
/div>

    Assume this wins and all obey. Chrome=
 does H.261+VP8, Firefox does H.261+H.264+VP8, IE does H.261+H.264, Safari =
does H.261+H.264. According to various (incredibly extrapolated, possibly i=
naccurate and sometimes conflicting) sources [1] on who uses what
 browser, the chance of H.261 fallback is a whopping 30% [2]. Not the minor=
 insignificant case some had assumed.

    How will the=
se users react to H.261 QCIF/CIF compared to what they use today, say Skype=
 for example? "This web shit really sucks. I=E2=80=99m going back to S=
kype and never trying it again." Is that the first (and perhaps last) =
impression we want from users that
 try webrtc? Those arguing crappy video is better than no video are ignorin=
g the critical importance of first impressions. While some may accept crapp=
y video as usable, many more may be permanently turned off and tune out eve=
n faster than if they got only (good)
 audio. It=E2=80=99s not as if webrtc is the only game in town. Users have =
options, so it needs to be competitive with competitive technology which ha=
s already set the bar.

    We previously narrowed the =
options down to H.264 and VP8 for good reasons over the course of this excr=
uciatingly long decision. Reopening discarded tangents like H.261 does not =
move us forward as a workgroup, and certainly does not move webrtc forward
 as a technology.

    Mo

    



    [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x=
 (IE% + Safari%)

    

    _______________________________________________
    
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
    


    

--047d7b339df96818de04ebc6dbb6--

From sslivinski@lifesize.com  Fri Nov 22 08:59:46 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261671AE3F6 for ; Fri, 22 Nov 2013 08:59:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxuF3LCdSlwb for ; Fri, 22 Nov 2013 08:59:43 -0800 (PST)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id 9CCDD1AE3FC for ; Fri, 22 Nov 2013 08:59:43 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUo+Nd144ECKg/BGVkQvjVwTYrJHfCZD/@postini.com; Fri, 22 Nov 2013 08:59:36 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 10:54:08 -0600
From: Stefan Slivinski 
To: John Leslie 
Date: Fri, 22 Nov 2013 10:54:06 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7njx5J16lJ9RueT6OPd4nzhYEJ4QADjCaQAAGCbZA=
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E66A8@ausmsex00.austin.kmvtechnologies.com>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com>  <528EBAB0.2010906@librevideo.org>  <528EBD4C.8070504@librevideo.org>  <7949EED078736C4881C92F656DC6F6C130EA9E6618@ausmsex00.austin.kmvtechnologies.com> <20131122142825.GB59496@verdi> <7949EED078736C4881C92F656DC6F6C130EA9E66A6@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E66A6@ausmsex00.austin.kmvtechnologies.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 16:59:46 -0000

Sorry, that should have read "something that even a low end, 3 year old int=
el can do __using H.264__ without breaking a sweat"

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Slivinski
Sent: Friday, November 22, 2013 8:48 AM
To: John Leslie
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process

The best technology is not simply which codec has the greatest compression =
efficiency, it is a function of complexity, performance, cost, error resili=
ency and many more. =20

Today there exists no hardware acceleration for H.265 which means you will =
be hard pressed to do 720p30 encode on a high end laptop, something that ev=
en a low end, 3 year old intel can do without breaking a sweat.  On portabl=
e platforms like tablets and smartphones doing the encoder is software is g=
oing to make it impossible to do larger resolutions and it's going to kill =
the battery.  All of these have to be factors in deciding what is the best =
technology.

-----Original Message-----
From: John Leslie [mailto:john@jlc.net]
Sent: Friday, November 22, 2013 6:28 AM
To: Stefan Slivinski
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process

Stefan Slivinski  wrote:
>=20
> So if you think of a really simple motion estimate engine where you=20
> search every possible location in the reference frame to find the best=20
> match using SAD as a block matching algorithm...guess what?
> There's a patent for that. If you then decide that if there isn'?t a=20
> really good match (high SAD), and you decide to do an intra search=20
> instead...guess what? There's a patent for that.

   Yes, we know -- software patents are big-time damage...

> I'm not trying to scare everyone but to argue that H.261 is somehow=20
> going to protect you from patent infringement is completely without=20
> merit.

   There's an important point here, which many folks _do_ seem to be
missing: you _can_ run afoul of perfectly "valid" patents implementing 20-y=
ear-old technology. It is not the job of the IETF to even warn you about th=
is; and it's _definitely_ not our job to say how you should deal with it.

> My point here is we should be focusing on choosing the best technology

   No.

   We're absolutely not trying to find the "best technology". We all agree =
that H.265 is better than H.264 and VP9 is better than VP8, but we're not f=
ocusing on either of them. Likewise, we all agree that H.263, while worse t=
han either H.264 or VP8, is better than H.261.

   We're trying to find a "good enough" technology to be Mandatory To Imple=
ment. We've been trying for a long time; and we may end up failing.

   H.261 holds real promise there -- you can find an _implementation_ that'=
s more than 20 years old and copy it bit-for-bit, and have a rock-solid "pr=
ior art" defense. (We're not saying that's what you should do; but it's an =
option available to you.)

> and come up with a solution for dealing with patent trolls at some=20
> other level because it's going to be a wide spread concern, not just a=20
> video problem.

   That's not a problem for _us_ to solve -- nor is it entirely rational to=
 believe we will ever see it solved. I certainly agree the problem is quite=
 widespread; but different companies will choose different paths to manage =
the risks. (As they should!)

--
John Leslie 
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

From juberti@google.com  Fri Nov 22 09:04:03 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811D21AE06F for ; Fri, 22 Nov 2013 09:04:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtSVsdYl6TtQ for ; Fri, 22 Nov 2013 09:04:00 -0800 (PST)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0559A1ADFC6 for ; Fri, 22 Nov 2013 09:03:59 -0800 (PST)
Received: by mail-ve0-f172.google.com with SMTP id jw12so1121305veb.3 for ; Fri, 22 Nov 2013 09:03:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=csGZNeNa3QQ0+QYUPkapFnbMe9m7KGDkhxP1hKKQ4Ro=; b=Arhhb1DDTKbjPakuLlkYpdRdliG/c5DomqaqJ3fwjHFI8vKj15eStD9D2+isl91yHx puHHNo7uNZU0WqM6ItFjV3UCoH6Df3TDQOxfcRTFQF0Pa3l3vHRiLlBJ831LG0BVOuKf z0xFdLVo6z/qnpZu/9KSwH9vRHhpuZ+Bz/meZ7f30aUCbwFcqgWzf6w8leN5qSpoTar5 nRW6YhULzRc1iHh6rx11TeaseabcqNiNyWvIF4sTAHCIUXPvVoIQOWNHmUwR5m0S56OO SzlOfCHMCjerGfmNw26iqaRCJ6ynK3bd8NojLsU2k8L7ckqzXmfnKtJ6PMo3hyV6MYIt sjEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=csGZNeNa3QQ0+QYUPkapFnbMe9m7KGDkhxP1hKKQ4Ro=; b=cTCPOQS5WETq5BFIIy996QgAVfnYiTuytTFf60RB3TUWw2vKVRoy5RY4ZCcVdsHove O+v/VB7ptXI+M6qeaf5FLgIV4xLSp1bqQCM5Mjpr/eufAeOFFxS8QslaEkPzeLl++/gR e3Zi3TClhD91OcvJS/HCOiztfWOh+qj0j15wcivoPGdVPAtuJDDLtw3EShyk0uhBGAzP tAV+DxkF69qh0uj15TeBj/qg+R0x45x3DwOXtNbaPLqLQTgGEkOW8BAmcnFo0MK4KhOh qNONqALHYt7dNlK0P//mSQCEPl9ZJokpgyVwjmPvC7SZ5rO53MOEIDUWVafGOl1WUrUA sQrA==
X-Gm-Message-State: ALoCoQni14wFGNScDjeV2ekxwosMRsnxeFae07LunM/iqOk9lemLbZBs1P1GME+m54+98k0/JHeyqlx68fyIbnq2spDDE4OPcm6eoGi09U6DssAkwz+gtN0ftA5XxCJoV1NozcAjzJjIv7yFwqT8fTNMeiByfb7yMtiWZZ6iMCagtQljBn3h5pihZ0ZIWaLewks9SaBLqRg+
X-Received: by 10.53.2.36 with SMTP id bl4mr513589vdd.32.1385139832509; Fri, 22 Nov 2013 09:03:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 22 Nov 2013 09:03:32 -0800 (PST)
In-Reply-To: 
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7DD@ausmsex00.austin.kmvtechnologies.com> <528F30C1.8040208@it.aoyama.ac.jp>  <4D2FF0AC-74D6-4083-B8A0-15FE0B3C7911@phonefromhere.com> 
From: Justin Uberti 
Date: Fri, 22 Nov 2013 09:03:32 -0800
Message-ID: 
To: bryandonnovan@gmail.com
Content-Type: multipart/alternative; boundary=001a113637d4ae6fa004ebc6ffdb
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 17:04:03 -0000

--001a113637d4ae6fa004ebc6ffdb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In the basic case, I don't think O/A will have a problem with this, without
even needing to resort to 1-way streams.

Each side would offer both codec X and codec Y, and the remote side will
simply choose to send the one it supports (or prefers, if it supports both)


On Fri, Nov 22, 2013 at 8:47 AM,  wrote:

> SDP can express sendonly and recvonly streams, so there is no inherent
> problem with assymetry of codec choice.  But it would certainly complicat=
e
> things.
>
> I would be in favor of a solution that allowed anyone (all browsers) to
> decode both VP8 and h.264, no matter what they are capable of encoding.  =
In
> my 1-to-many conference software, all streams are unidirectional.
>
>
>
>
> On Fri, Nov 22, 2013 at 8:40 AM, tim panton  wrote=
:
>
>> Surely this flies in the face of the whole O/A model, which imposes a
>> sort of symmetry on the endpoints ?
>> (Unless there is some arcane SDP FRACK at play here).
>>
>> T.
>>
>>
>> On 22 Nov 2013, at 08:24, Silvia Pfeiffer 
>> wrote:
>>
>> I think this has value. It might bring apple and Microsoft to the table,
>> since decoding-only is often the less patent-affecting part.
>>
>> Silvia.
>> On 22 Nov 2013 02:24, Martin J. D=C3=BCrst  wrot=
e:
>>
>>> On 2013/11/22 5:02, Stefan Slivinski wrote:
>>>
>>>> I in no way intended to suggest  a specific implementation of a video
>>>> codec.  My question was around whether we are voting on requiring deco=
ders
>>>> (my assumption) or both encoders and decoders
>>>>
>>>
>>> My understanding is that all the proposals in each instance mean "both
>>> encoder and decoder". So as an example, a proposal of "MUST implement b=
oth
>>> VP8 and H.264" means "MUST implement both VP8 encoder and decoder, and
>>> H.264 encoder and decoder".
>>>
>>> Your question brings up other choices. For example, interoperability
>>> would be satisfied by something like "MUST implement both VP8 and H.264
>>> decoders, and MUST implement at least one of VP8 and H.264 encoders".
>>>
>>> One condition for this to work is the possibility of asymmetric
>>> communication, i.e. if side A implemented only a VP8 encoder, and side =
B
>>> only implemented a H.264 encoder, then traffic A->B would be VP8, where=
as
>>> traffic B->A would be H.264. I don't know the in's and out's of the
>>> negotiation and protocol machinery to confirm or deny that this is poss=
ible.
>>>
>>> Choices like the one above definitely open new horizons for Eric's
>>> selection generator. But frankly speaking, except for the specific choi=
ce
>>> of "MUST implement both VP8 and H.264 decoders, and MUST implement at l=
east
>>> one of VP8 and H.264 encoders", which is less onerous than "MUST implem=
ent
>>> both VP8 and H.264", but still interoperable, I don't see any choices w=
ith
>>> different requirements for encoders and decoders that would make sense.
>>>
>>> Regards,   Martin.
>>>
>>>
>>>  ----- Original Message -----
>>>> From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
>>>> Sent: Thursday, November 21, 2013 01:56 PM
>>>> To: rtcweb@ietf.org
>>>> Subject: Re: [rtcweb] Proposed Video Selection Process
>>>>
>>>> On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
>>>>
>>>>> I'm a new comer, so just a brief intro: I have a background developin=
g
>>>>> real time video codecs for embedded devices so I'm in a position to c=
omment
>>>>> at a technical level within this group
>>>>>
>>>>> For clarity purposes the proposed alternatives in Magnus' email on no=
v
>>>>> 18th; are we strictly speaking about decoders?  Historically mandator=
y
>>>>> requirements are they relate to video compatibility define just the
>>>>> decoders.  Obviously if there is only a single mandatory video decode=
r this
>>>>> implies a mandatory encoder, however in the case where there are 2
>>>>> mandatory decoders only a single encoder is technically required.
>>>>>
>>>>> Clarifying this is fairly important because in the case of both h264
>>>>> and vp8 (and in the future vp9 and h265) the decoder complexity is fa=
irly
>>>>> low and hardware acceleration is not critical but in the case of the
>>>>> encoders where the complexity can be 3x or worse, hardware accelerati=
on
>>>>> becomes increasingly important
>>>>>
>>>>> Stefan
>>>>>
>>>>
>>>> What is being specified as MTI is a format, and not a specific
>>>> implementation.  So, MTI will not take the form of "OpenH264" or
>>>> "libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8".
>>>>
>>>> The same was done for the MTI audio codec, which is Opus, not *libopus=
*,
>>>> which is one specific implementation of the codec.
>>>>
>>>> There was a suggestion that the WG also offer a reference implementati=
on
>>>> of the MTI codec choice, but that seems like it won't happen, nor is i=
t
>>>> really the purpose of the WG to do so.  We are picking from
>>>> already-existing and implemented formats in the first place.
>>>>
>>>>  _______________________________________________
>>> 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
>
>

--001a113637d4ae6fa004ebc6ffdb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    In the basic case, I don't think O/A will have a probl=
em with this, without even needing to resort to 1-way streams.

    Each side would offer both codec X and codec Y, and the remote side =
will simply choose to send the one it supports (or prefers, if it supports =
both)
    




    On Fri,=
 Nov 22, 2013 at 8:47 AM,  <bryandonnovan@gmail.com> w=
rote:
    


    SDP can express sendon=
ly and recvonly streams, so there is no inherent problem with assymetry of =
codec choice. =C2=A0But it would certainly complicate things.
    



    I would be in favor of a solution that allowed anyone (=
all browsers) to decode both VP8 and h.264, no matter what they are capable=
 of encoding. =C2=A0In my 1-to-many conference software, all streams are un=
idirectional.=C2=A0
    







    On Fri, Nov 22, 2013 at=
 8:40 AM, tim panton <tim@phonefromhere.com> wrote:
    



    Surely t=
his flies in the face of the whole O/A model, which imposes a sort of symme=
try on the endpoints ?
    


(Unless there is some arcane SDP FRACK at play here).

    T.

    

    On 22 Nov 2013, at 08:24, Silvia Pfeiffer <silviapfeiffer1@=
gmail.com> wrote:

    =
I think this has value. It might bring apple and Microsoft to the table, si=
nce decoding-only is often the less patent-affecting part.
    



    Silvia.
    

    On 22 Nov 2013 02:24, Martin J. D=C3=BCrst <<=
a href=3D"mailto:duerst@it.aoyama.ac.jp" target=3D"_blank">duerst@it.aoyama=
.ac.jp> wrote:
    
I in no way intended to suggest =C2=A0a specific implementation of a video =
codec. =C2=A0My question was around whether we are voting on requiring deco=
ders (my assumption) or both encoders and decoders
    

    

    
My understanding is that all the proposals in each instance mean "both=
 encoder and decoder". So as an example, a proposal of "MUST impl=
ement both VP8 and H.264" means "MUST implement both VP8 encoder =
and decoder, and H.264 encoder and decoder".
    





    
Your question brings up other choices. For example, interoperability would =
be satisfied by something like "MUST implement both VP8 and H.264 deco=
ders, and MUST implement at least one of VP8 and H.264 encoders".
    





    
One condition for this to work is the possibility of asymmetric communicati=
on, i.e. if side A implemented only a VP8 encoder, and side B only implemen=
ted a H.264 encoder, then traffic A->B would be VP8, whereas traffic B-&=
gt;A would be H.264. I don't know the in's and out's of the neg=
otiation and protocol machinery to confirm or deny that this is possible.





    
Choices like the one above definitely open new horizons for Eric's sele=
ction generator. But frankly speaking, except for the specific choice of &q=
uot;MUST implement both VP8 and H.264 decoders, and MUST implement at least=
 one of VP8 and H.264 encoders", which is less onerous than "MUST=
 implement both VP8 and H.264", but still interoperable, I don't s=
ee any choices with different requirements for encoders and decoders that w=
ould make sense.
    





    
Regards, =C2=A0 Martin.
    

    

    

    
----- Original Message -----
    
From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org]
    
Sent: Thursday, November 21, 2013 01:56 PM
    
To: rtcweb@ietf.org<rtcweb@ietf.org>
    
Subject: Re: [rtcweb] Proposed Video Selection Process
    

    
On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
    

    
I'm a new comer, so just a brief intro: I have a background developing =
real time video codecs for embedded devices so I'm in a position to com=
ment at a technical level within this group
    

    
For clarity purposes the proposed alternatives in Magnus' email on nov =
18th; are we strictly speaking about decoders? =C2=A0Historically mandatory=
 requirements are they relate to video compatibility define just the decode=
rs. =C2=A0Obviously if there is only a single mandatory video decoder this =
implies a mandatory encoder, however in the case where there are 2 mandator=
y decoders only a single encoder is technically required.
    





    
Clarifying this is fairly important because in the case of both h264 and vp=
8 (and in the future vp9 and h265) the decoder complexity is fairly low and=
 hardware acceleration is not critical but in the case of the encoders wher=
e the complexity can be 3x or worse, hardware acceleration becomes increasi=
ngly important
    





    
Stefan
    

    

    
What is being specified as MTI is a format, and not a specific
    
implementation. =C2=A0So, MTI will not take the form of "OpenH264"=
; or
    
"libvpx", but rather, "H.264 Constrainted Baseline Profile&q=
uot; or "VP8".
    

    
The same was done for the MTI audio codec, which is Opus, not *libopus*,
which is one specific implementation of the codec.
    

    
There was a suggestion that the WG also offer a reference implementation
of the MTI codec choice, but that seems like it won't happen, nor is it=

    
really the purpose of the WG to do so. =C2=A0We are picking from
    
already-existing and implemented formats in the first place.
    

    

    
_______________________________________________
    
rtcweb mailing list
    
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb
    

    
_______________________________________________
    rtcweb mailing list
    <=
a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">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
    


    

--001a113637d4ae6fa004ebc6ffdb--

From maikmerten@googlemail.com  Fri Nov 22 09:06:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B551AE04C for ; Fri, 22 Nov 2013 09:06:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.486
X-Spam-Level: 
X-Spam-Status: No, score=-0.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kUgQNf6hHnk for ; Fri, 22 Nov 2013 09:06:26 -0800 (PST)
Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1761AE002 for ; Fri, 22 Nov 2013 09:06:26 -0800 (PST)
Received: by mail-ee0-f49.google.com with SMTP id c41so614592eek.36 for ; Fri, 22 Nov 2013 09:06:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uLcQ4X5vXtmP+F9xrw+U6SSGSceWejbYV6vziJYmQB0=; b=XTDhe+p/K0RQ9nICZ7T1zobxxpklLYF/3KL0GG6eoreslQ3qHEBEkln0HGD02n57/v 3q/bHb8bk9bAmjkBc3g0RHhP755rZ63x/BafGFLLx6fn5+MbV72HsO0OMpVfCL5/Qkb6 T/fP40f/7NIAtDXVdvk8bIiGEqb0iX+xMoW0PsyXzP/UGvWTHQy300YjeLYxtb2F9dF+ u2ZGh+sJJKcCiBlTEDoxRsxZlPcxeuW/FY9C/bcH6WeftkPBeqfn5HqOblbFDh9ShGRv 4RGG/1kojcADDCFf8KJH32sXpLBB8LYn9scwnpRoO2HeedPsdM7J+p9Fv3wol2xgYBeG jhWw==
X-Received: by 10.14.199.1 with SMTP id w1mr17864853een.29.1385139978688; Fri, 22 Nov 2013 09:06:18 -0800 (PST)
Received: from [192.168.2.109] (port-92-201-19-228.dynamic.qsc.de. [92.201.19.228]) by mx.google.com with ESMTPSA id a45sm62019707eem.6.2013.11.22.09.06.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 09:06:17 -0800 (PST)
Message-ID: <528F8F05.2040800@googlemail.com>
Date: Fri, 22 Nov 2013 18:06:13 +0100
From: Maik Merten 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:    
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] H.261
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 17:06:28 -0000

The best way to not run into bandwidth problems is *not* to go for 
transcoding. After all, all those video calls need to go through your 
transcoding infrastructure, directing all the traffic your way.

In P2P scenarios there's a much much higher chance of traffic finding a 
nice and direct route.

And talking about H.261: We're talking about video in the range of 0.2 
to 0.8 Mbps. Compression efficiency per-pixel certainly leaves much to 
be desired, but we're talking CIF resolution here.


Maik


Am 22.11.2013 17:53, schrieb Justin Uberti:
> For 1:many with MCU, I don't understand why you wouldn't do #2, i.e.
> transcode. As stated earlier, the bandwidth costs of using an
> inefficient codec (which any MCU service will incur) exceed the CPU cost
> of transcode.
>
>
> On Fri, Nov 22, 2013 at 4:47 AM,  > wrote:
>
>     Lots of uses will be 1:1 calls, and maybe 30% fallback applies in
>     this case.  My use of WebRTC involves 1:many group calls in the
>     browser with an MCU.  For 1:many, the options are 1) fallback to
>     common codec and 2) transcode.  So, for 1:many we can say that the
>     chance of using the fallback codec is 100%.  Assuming IE and Safari
>     actually ship WebRTC.
>
>
>
>     On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann      > wrote:
>
>
>         Mo,
>
>         I think we all agree that choosing H.264 or VP8 would be better,
>         but it is clear that neither option today has consensus.
>           Circumstances could change in the future, but it seems that
>         OpenH264 was not enough to change that circumstance.
>
>         I think that where your scenario might go astray is that users
>         won’t associate their poor experience with “WebRTC”, or “that
>         web stuff” — they will associate it with the brand of the
>         service which they are using at the time.
>
>         So, for example, if Facebook builds video chat using WebRTC, and
>         they do no transcoding, 30% of users might associate their poor
>         video with Facebook, but most of them won’t call it “that web
>         shit” — they would say Facebook video sucks.
>
>         Of course, Facebook could decide to transcode 30% of the time,
>         in which case the user would have a different experience.
>
>         Facebook obviously just being used as an example service which
>         might implement WebRTC video.
>
>         -SteveK
>
>
>
>         From: "Mo Zanaty (mzanaty)"          >
>         Date: Thursday, November 21, 2013 at 9:17 PM
>         To: Basil Mohamed Gohar          >
>         Cc: "rtcweb@ietf.org "          >
>         Subject: [rtcweb] H.261
>
>             On 11/21/13 12:48, Basil Mohamed Gohar
>                          > wrote:
>
>                 Has anyone actually objected to H.261 being the one MTI
>                 codec [...] ?
>
>
>             Assume this wins and all obey. Chrome does H.261+VP8,
>             Firefox does H.261+H.264+VP8, IE does H.261+H.264, Safari
>             does H.261+H.264. According to various (incredibly
>             extrapolated, possibly inaccurate and sometimes conflicting)
>             sources [1] on who uses what browser, the chance of H.261
>             fallback is a whopping 30% [2]. Not the minor insignificant
>             case some had assumed.
>
>             How will these users react to H.261 QCIF/CIF compared to
>             what they use today, say Skype for example? "This web shit
>             really sucks. I’m going back to Skype and never trying it
>             again." Is that the first (and perhaps last) impression we
>             want from users that try webrtc? Those arguing crappy video
>             is better than no video are ignoring the critical importance
>             of first impressions. While some may accept crappy video as
>             usable, many more may be permanently turned off and tune out
>             even faster than if they got only (good) audio. It’s not as
>             if webrtc is the only game in town. Users have options, so
>             it needs to be competitive with competitive technology which
>             has already set the bar.
>
>             We previously narrowed the options down to H.264 and VP8 for
>             good reasons over the course of this excruciatingly long
>             decision. Reopening discarded tangents like H.261 does not
>             move us forward as a workgroup, and certainly does not move
>             webrtc forward as a technology.
>
>             Mo
>
>             [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
>             [2] H.261 fallback % = 2 x VP8-only% x H.264-only% = 2 x
>             Chrome% x (IE% + Safari%)
>
>             _______________________________________________ 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
>


From bryandonnovan@gmail.com  Fri Nov 22 09:06:49 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BB91AE002 for ; Fri, 22 Nov 2013 09:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.485
X-Spam-Level: 
X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbO2gCZCLdpq for ; Fri, 22 Nov 2013 09:06:46 -0800 (PST)
Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 964511ADFC6 for ; Fri, 22 Nov 2013 09:06:46 -0800 (PST)
Received: by mail-vc0-f179.google.com with SMTP id ie18so1076893vcb.10 for ; Fri, 22 Nov 2013 09:06:39 -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=MXhuTneusH15TvNCWYCxCF8VSBLuL9J+HsoIMztmRiY=; b=T1fKba/Zm5SsxPfp1p/L8wfJOQVqwT38aKWi/MoAjXjkaKztnrt6wvKnsgZQrQL0uZ gmfM7cWAoQMYeSvuCvzmy6H9qqSkXPY+HE1omUMH2qeW/0E4+NdwMj3LW80jY/tb95/4 GeWi4MGAv6uq0Q3E9wnrv/hQqVMLdLGHyKt5mW2d0G4c4iJ86QrDwvc1VW/EnngD1G8H 0K7Dv6ncqZ69Z+EnD7fp6tVvkqJr7xZVtBM81/kJh7CoCz0k2cPY7xgqYrWkk1fepynn 5phlx1jbOoTSWh7asNt6ihAktY1NSn5Si4T+1rYB6xWIQnK2yGxu69JZEpKRoDgiH6L2 AKGA==
MIME-Version: 1.0
X-Received: by 10.58.143.17 with SMTP id sa17mr12450631veb.14.1385139999306; Fri, 22 Nov 2013 09:06:39 -0800 (PST)
Received: by 10.52.231.233 with HTTP; Fri, 22 Nov 2013 09:06:39 -0800 (PST)
In-Reply-To: 
References:    
Date: Fri, 22 Nov 2013 09:06:39 -0800
Message-ID: 
From: bryandonnovan@gmail.com
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=047d7b6d95ee9f7a8d04ebc70965
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] H.261
X-BeenThere: rtcweb@ietf.org
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: Fri, 22 Nov 2013 17:06:49 -0000

--047d7b6d95ee9f7a8d04ebc70965
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The point that I was making (perhaps not very clearly) is that in many use
cases, the common codec is much more important than that 30% number would
suggest.  My priority is having an efficient common video codec.  I would
transcode as a last resort.

Also, my concern with transcoding is not cost, but scalability.  I can find
a dedicated server for a couple hundred dollars per month that would give
me 100TB of bandwidth.  If I had to transcode, then I would run out of cpu
cycles long before I ran out of bandwidth.  If I only have to route packets
and transcrypt, then the balance between cpu and bandwidth allows much more
efficient resource utilization.

Perhaps the math on cpu vs bandwidth cost that you are referring to was
based on AWS -- I use dedicated hardware.


On Fri, Nov 22, 2013 at 8:53 AM, Justin Uberti  wrote:

> For 1:many with MCU, I don't understand why you wouldn't do #2, i.e.
> transcode. As stated earlier, the bandwidth costs of using an inefficient
> codec (which any MCU service will incur) exceed the CPU cost of transcode=
.
>
>
> On Fri, Nov 22, 2013 at 4:47 AM,  wrote:
>
>> Lots of uses will be 1:1 calls, and maybe 30% fallback applies in this
>> case.  My use of WebRTC involves 1:many group calls in the browser with =
an
>> MCU.  For 1:many, the options are 1) fallback to common codec and 2)
>> transcode.  So, for 1:many we can say that the chance of using the fallb=
ack
>> codec is 100%.  Assuming IE and Safari actually ship WebRTC.
>>
>>
>>
>> On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann  wrote:
>>
>>>
>>> Mo,
>>>
>>> I think we all agree that choosing H.264 or VP8 would be better, but it
>>> is clear that neither option today has consensus.    Circumstances coul=
d
>>> change in the future, but it seems that OpenH264 was not enough to chan=
ge
>>> that circumstance.
>>>
>>> I think that where your scenario might go astray is that users won=E2=
=80=99t
>>> associate their poor experience with =E2=80=9CWebRTC=E2=80=9D, or =E2=
=80=9Cthat web stuff=E2=80=9D =E2=80=94 they
>>> will associate it with the brand of the service which they are using at=
 the
>>> time.
>>>
>>> So, for example, if Facebook builds video chat using WebRTC, and they d=
o
>>> no transcoding, 30% of users might associate their poor video with
>>> Facebook, but most of them won=E2=80=99t call it =E2=80=9Cthat web shit=
=E2=80=9D =E2=80=94 they would say
>>> Facebook video sucks.
>>>
>>> Of course, Facebook could decide to transcode 30% of the time, in which
>>> case the user would have a different experience.
>>>
>>> Facebook obviously just being used as an example service which might
>>> implement WebRTC video.
>>>
>>> -SteveK
>>>
>>>
>>>
>>> From: "Mo Zanaty (mzanaty)" 
>>> Date: Thursday, November 21, 2013 at 9:17 PM
>>> To: Basil Mohamed Gohar 
>>> Cc: "rtcweb@ietf.org" 
>>> Subject: [rtcweb] H.261
>>>
>>> On 11/21/13 12:48, Basil Mohamed Gohar 
>>> wrote:
>>>
>>> Has anyone actually objected to H.261 being the one MTI codec [...] ?
>>>
>>>
>>> Assume this wins and all obey. Chrome does H.261+VP8, Firefox does
>>> H.261+H.264+VP8, IE does H.261+H.264, Safari does H.261+H.264. Accordin=
g to
>>> various (incredibly extrapolated, possibly inaccurate and sometimes
>>> conflicting) sources [1] on who uses what browser, the chance of H.261
>>> fallback is a whopping 30% [2]. Not the minor insignificant case some h=
ad
>>> assumed.
>>>
>>> How will these users react to H.261 QCIF/CIF compared to what they use
>>> today, say Skype for example? "This web shit really sucks. I=E2=80=99m =
going back
>>> to Skype and never trying it again." Is that the first (and perhaps las=
t)
>>> impression we want from users that try webrtc? Those arguing crappy vid=
eo
>>> is better than no video are ignoring the critical importance of first
>>> impressions. While some may accept crappy video as usable, many more ma=
y be
>>> permanently turned off and tune out even faster than if they got only
>>> (good) audio. It=E2=80=99s not as if webrtc is the only game in town. U=
sers have
>>> options, so it needs to be competitive with competitive technology whic=
h
>>> has already set the bar.
>>>
>>> We previously narrowed the options down to H.264 and VP8 for good
>>> reasons over the course of this excruciatingly long decision. Reopening
>>> discarded tangents like H.261 does not move us forward as a workgroup, =
and
>>> certainly does not move webrtc forward as a technology.
>>>
>>> Mo
>>>
>>> [1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
>>> [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x =
(IE%
>>> + Safari%)
>>>
>>> _______________________________________________ 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
>>
>>
>

--047d7b6d95ee9f7a8d04ebc70965
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    The point that I was making (perhaps not very clearly) is =
that in many use cases, the common codec is much more important than that 3=
0% number would suggest. =C2=A0My priority is having an efficient common vi=
deo codec. =C2=A0I would transcode as a last resort.
    

    Also, my concern with transcoding is not cost, but scalabili=
ty. =C2=A0I can find a dedicated server for a couple hundred dollars per mo=
nth that would give me 100TB of bandwidth. =C2=A0If I had to transcode, the=
n I would run out of cpu cycles long before I ran out of bandwidth. =C2=A0I=
f I only have to route packets and transcrypt, then the balance between cpu=
 and bandwidth allows much more efficient resource utilization.
    


    Perhaps the math on cpu vs bandwidth cost that you are =
referring to was based on AWS -- I use dedicated hardware.


    On Fri, Nov 22, 20=
13 at 8:53 AM, Justin Uberti <juberti@google.com> wrote:

    For 1:many with MCU, I don&=
#39;t understand why you wouldn't do #2, i.e. transcode. As stated earl=
ier, the bandwidth costs of using an inefficient codec (which any MCU servi=
ce will incur) exceed the CPU cost of transcode.
    

    




    On Fri, Nov 2=
2, 2013 at 4:47 AM,  <bryandonnovan@gmail.com> wrote:<=
br>
    



    Lots of uses will be 1:1 calls, and maybe 30% fallback app=
lies in this case. =C2=A0My use of WebRTC involves 1:many group calls in th=
e browser with an MCU. =C2=A0For 1:many, the options are 1) fallback to com=
mon codec and 2) transcode. =C2=A0So, for 1:many we can say that the chance=
 of using the fallback codec is 100%. =C2=A0Assuming IE and Safari actually=
 ship WebRTC. =C2=A0
    






    On Thu, Nov 21, 2013 at 10:11 PM, Steve Kann <stevek@stevek.c=
om> wrote:
    





    =
Mo,
    





    I think we all agree that choosing H.264 or VP8 would b=
e better, but it is clear that neither option today has consensus. =C2=A0 =
=C2=A0Circumstances could change in the future, but it seems that OpenH264 =
was not enough to change that circumstance.
    





    I think that where your scenario might go astray is tha=
t users won=E2=80=99t associate their poor experience with =E2=80=9CWebRTC=
=E2=80=9D, or =E2=80=9Cthat web stuff=E2=80=9D =E2=80=94 they will associat=
e it with the brand of the service which they are using at the time.
    





    So, for example, if Facebook builds video chat using We=
bRTC, and they do no transcoding, 30% of users might associate their poor v=
ideo with Facebook, but most of them won=E2=80=99t call it =E2=80=9Cthat we=
b shit=E2=80=9D =E2=80=94 they would say Facebook video sucks.
    





    Of course, Facebook could decide to transcode 30% of th=
e time, in which case the user would have a different experience.

    Facebook obviously just being used as an example service wh=
ich might implement WebRTC video.
    





    -SteveK



    



From:  "Mo Zanaty (mzanaty)&qu=
ot; <mzanaty@cisc=
o.com>
    Date:  Thursday, N=
ovember 21, 2013 at 9:17 PM
    



To:  Basil Mohamed Gohar <basilgohar@librevi=
deo.org>
    Cc:  "rtcweb@ietf.org" &=
lt;rtcweb@ietf.org=
>
    



Subject:  [rtcweb] H.261
    <=
div>
    




    On 11/21/13 12:48, Basil Mohamed Gohar <basilgohar@librevideo.org> wrote=
:
    




    Has anyone actually objected to H.261 being the one MTI codec [...] ?<=
/div>

    Assume this wins and all obey. Chrome=
 does H.261+VP8, Firefox does H.261+H.264+VP8, IE does H.261+H.264, Safari =
does H.261+H.264. According to various (incredibly extrapolated, possibly i=
naccurate and sometimes conflicting) sources [1] on who uses what
 browser, the chance of H.261 fallback is a whopping 30% [2]. Not the minor=
 insignificant case some had assumed.

    How will the=
se users react to H.261 QCIF/CIF compared to what they use today, say Skype=
 for example? "This web shit really sucks. I=E2=80=99m going back to S=
kype and never trying it again." Is that the first (and perhaps last) =
impression we want from users that
 try webrtc? Those arguing crappy video is better than no video are ignorin=
g the critical importance of first impressions. While some may accept crapp=
y video as usable, many more may be permanently turned off and tune out eve=
n faster than if they got only (good)
 audio. It=E2=80=99s not as if webrtc is the only game in town. Users have =
options, so it needs to be competitive with competitive technology which ha=
s already set the bar.

    We previously narrowed the =
options down to H.264 and VP8 for good reasons over the course of this excr=
uciatingly long decision. Reopening discarded tangents like H.261 does not =
move us forward as a workgroup, and certainly does not move webrtc forward
 as a technology.

    Mo

    




    [2] H.261 fallback % =3D 2 x VP8-only% x H.264-only% =3D 2 x Chrome% x=
 (IE% + Safari%)

    

    _______________________________________________
    
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