Hi Peter, all, About the video codec: Are there any arguments on why VP8 would not have IPR issues? It is available as an open source implementation, but that does not mean there are no IPR against it. My understanding is that the IPR situation wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as far as I know, the lack of a clear spec out of which independent interoperable implementations can be created. So I don't at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons. I'm working on a separate review on Harald's drafts (thanks for putting them together) and will come back to the codec issue there in more detail, but just wanted to respond to Peter's point here. Regards, Markus From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 I'd also like to echo Alan's thanks for these drafts. The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-) ] One observation to the group. The mandatory to implement video CODEC is VP8 (presumably since it does not have IPR issues - which some other choices would have). Regards, Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is there. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) From: IETF I-D Submission Tool <idsubmission@ietf.org><mailto:idsubmission@ietf.org> To: harald@alvestrand.no<mailto:harald@alvestrand.no> A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-dispatch-rtcweb-protocols Revision: 00 Title: Overview: Real Time Protocols for Brower-based Applications Creation_date: 2010-11-11 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document gives an overview of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion. The IETF Secretariat. _______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch

Yes, as the guy who tried to get Speex into the specs years ago, these are exactly the same arguments that I heard then. Here's the most simple reason I can imagine to include a 'free' codec: you *preserve the option* for open source developers to innovate something new and amazing by allowing *them* to make the choice around IPR. The codec may have patents that read onto it, or it may be clean. Let the developer take the risk - he or she is probably so small that no one would pursue them anyway. By excluding 'free' codecs from the specifications you force the open source folks to write their own specs. Which they then can try to get through the WG. But as a volunteer, it's all your own effort, no funds to go to IETF meetings and make your case, no way to really move the momentum against the mass of folks who are paid to participate in the IETF. I've always thought that the best way for the big boys to seed innovation and find thee extraordinary Engineers would be for them to actively support the developers out there innovating - including supporting the inclusion of the free codecs in the specs. And if their products supported a way for the end user to load the free codecs themselves (thus placing the risk on the user and not on the vendor) that would be ideal. Just like browsers. Of course, the reality is that in many cases the owners of the IP around the non-free codecs have a vested interest in not seeing free codecs in the market. I understand that force, as well. It's the IP game, is all. --------------------------------------------------------------------------------------------------------------------------------------------- Greg Herlein | 415-368-7546 | SMS <4153687546@tmomail.net%20> | Blog <http://blog.herlein.com/> | Twitter Timeline<http://twitter.com/gherlein> | LinkedIn <http://www.linkedin.com/in/gherlein> Walking on water and developing software from a specification are easy if both are frozen *- Edward V Berard* On Tue, Dec 21, 2010 at 6:32 PM, Henry Sinnreich <henry.sinnreich@gmail.com>wrote:

It is interesting, almost funny (or sad depending on the perspective) how the reaction to a _God Forbid_ IP-free video codec is mirroring the opposition to the Internet audio codec. That opposition proved eventually futile and we have now a CODEC WG. I hope the AD’s will have now the same fortitude as was shown when the Internet audio codec WG was formed.

I have taken the liberty to copy the CODEC WG and hope they can participate now in the video codec discussion as well. My apology for the double posting.

Thanks, Henry

On 12/21/10 3:38 PM, "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com> wrote:

Hi Peter, all,

About the video codec: Are there any arguments on why VP8 would not have IPR issues? It is available as an open source implementation, but that does not mean there are no IPR against it. My understanding is that the IPR situation wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as far as I know, the lack of a clear spec out of which independent interoperable implementations can be created.

So I don’t at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons.

I’m working on a separate review on Harald’s drafts (thanks for putting them together) and will come back to the codec issue there in more detail, but just wanted to respond to Peter’s point here.

Regards, Markus

*From:* dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org<dispatch-bounces@ietf.org>] *On Behalf Of *ext Peter Musgrave *Sent:* 17 December, 2010 13:48 *To:* Harald Alvestrand *Cc:* rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie *Subject:* Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

I'd also like to echo Alan's thanks for these drafts.

The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-) ]

One observation to the group. The mandatory to implement video CODEC is VP8 (presumably since it does not have IPR issues - which some other choices would have).

Regards,

Peter Musgrave

Nits

Introduction

s/veichle/vehicle/

Section 2 Para "Within each.."

s/implementaiton/implementation/

Section 4 Para1

"such as" (something missing here?)

Section 5 Para2

"There is no third mandatory to implement"

? Was there a mention of a third before. Not sure why this statement is there.

On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:

This is the overview document for the IETF-related RTC-WEB work.

-------- Original Message --------

Similarly, codecs that have gone through a standardisation process and have been made available for licensing have later been found to be not "free of encumbrance" and attracted lawsuits, so this argument does not hold up as an argument against open codecs. The IPR situation of any codec is simply never clear. IPR is not a good argument for or against the choice of a codec. The need to pay royalties, however, is a good argument against a codec, since it limits which parts of the population can use it and which can't. As for the question about an open specification document for VP8, it is available and can be downloaded from http://www.webmproject.org/media/pdf/vp8-bitstream.pdf . An independent implementation of VP8 can be made by anyone, see http://www.webmproject.org/license/bitstream/ . Regards, Silvia. On Wed, Dec 22, 2010 at 7:18 AM, Bernard Aboba <bernard_aboba@hotmail.com>wrote:

It does appear presumptive to suggest that a codec that hasn't completed a standardization process be made "mandatory to implement."

Since there have been some large judgments over use of allegedly "free" codecs, the lesson is that codecs that are claimed to be "free of encumbrance" may in time be discovered not to be. The IETF process can potentially be useful in helping to clarify the IPR status of codecs. However, those wheels grind slowly.

------------------------------ From: Markus.Isomaki@nokia.com To: peter.musgrave@magorcorp.com; harald@alvestrand.no Date: Tue, 21 Dec 2010 21:38:42 +0000 CC: rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com Subject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

Hi Peter, all,

About the video codec: Are there any arguments on why VP8 would not have IPR issues? It is available as an open source implementation, but that does not mean there are no IPR against it. My understanding is that the IPR situation wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as far as I know, the lack of a clear spec out of which independent interoperable implementations can be created.

So I don’t at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons.

I’m working on a separate review on Harald’s drafts (thanks for putting them together) and will come back to the codec issue there in more detail, but just wanted to respond to Peter’s point here.

Regards,

Markus

*From:* dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] *On Behalf Of *ext Peter Musgrave *Sent:* 17 December, 2010 13:48 *To:* Harald Alvestrand *Cc:* rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie *Subject:* Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

I'd also like to echo Alan's thanks for these drafts.

The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-) ]

One observation to the group. The mandatory to implement video CODEC is VP8 (presumably since it does not have IPR issues - which some other choices would have).

Regards,

Peter Musgrave

Nits

Introduction

s/veichle/vehicle/

Section 2 Para "Within each.."

s/implementaiton/implementation/

Section 4 Para1

"such as" (something missing here?)

Section 5 Para2

"There is no third mandatory to implement"

? Was there a mention of a third before. Not sure why this statement is there.

On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:

This is the overview document for the IETF-related RTC-WEB work.

-------- Original Message --------

*Subject: *

New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00

*Date: *

Wed, 10 Nov 2010 03:31:05 -0800 (PST)

*From: *

IETF I-D Submission Tool <idsubmission@ietf.org> <idsubmission@ietf.org>

*To: *

harald@alvestrand.no

A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.

Filename: draft-alvestrand-dispatch-rtcweb-protocols

Revision: 00

Title: Overview: Real Time Protocols for Brower-based Applications

Creation_date: 2010-11-11

WG ID: Independent Submission

Number_of_pages: 9

Abstract:

This document gives an overview of a protocol suite intended for use

with real-time applications that can be deployed in browsers - "real

time communication on the Web".

It intends to serve as a starting and coordination point to make sure

all the parts that are needed to achieve this goal are findable, and

that the parts that belong in the Internet protocol suite are fully

specified and on the right publication track.

This work is an attempt to synthesize the input of many people, but

makes no claims to fully represent the views of any of them. All

parts of the document should be regarded as open for discussion.

The IETF Secretariat.

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

_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

On 12/22/10 07:18, Bernard Aboba wrote:

It does appear presumptive to suggest that a codec that hasn't completed a standardization process be made "mandatory to implement."

Since there have been some large judgments over use of allegedly "free" codecs, the lesson is that codecs that are claimed to be "free of encumbrance" may in time be discovered not to be. The IETF process can potentially be useful in helping to clarify the IPR status of codecs. However, those wheels grind slowly. I agree that we can't make anything mandatory to implement that we don't have an accepted stable, publicly available reference for. (I'm working on solving that for the case of VP8).

However, I don't agree that we necessarily have to complete a standards process in order to refer to it; that would put, for instance, the Zip format (used, among other places, in OOXML and ODF) out of scope for standards. WRT IPR issues: I think we just have to push forward on the assumption that all IPR holders who are part of the process will do their duty and disclose any relevant IPR, and hope that IPR held by nonparticipants in the process is not serious enough to cause us to regret our decision. Note: The statement about VP8 in the rtcweb-protocols document is a placeholder, put in there to indicate that we need to have the discussion. It's not a WG decision, but input to a WG discussion. Harald

The statement about VP8 in the rtcweb-protocols document is a placeholder, put in there to indicate that we need to have the discussion. It's not a WG decision, but input to a WG discussion.

This is an excellent position, thanks Harald! Now that many people agree on the need for an ³IP-free as possible² RTC Web codec, it would be a good start to make a short list of candidates and then discuss them on merit. Such as IMO (sorry I am not a video codec expert): V8, Theora and what other may contribute that require no IP. Even just starting with a table like http://en.wikipedia.org/wiki/Comparison_of_video_codecs To avoid rat holes and flames, I suggest not even to mention H.264 :-) except as an example for what not to adopt. Henry On 12/22/10 9:14 AM, "Harald Alvestrand" <harald@alvestrand.no> wrote:

On 12/22/10 07:18, Bernard Aboba wrote:

...

It does appear presumptive to suggest that a codec that hasn't completed a standardization process be made "mandatory to implement."

Since there have been some large judgments over use of allegedly "free" codecs, the lesson is that codecs that are claimed to be "free of encumbrance" may in time be discovered not to be.  The IETF process can potentially be useful in helping to clarify the IPR status of codecs.  However, those wheels grind slowly.

I agree that we can't make anything mandatory to implement that we don't have an accepted stable, publicly available reference for. (I'm working on solving that for the case of VP8).

However, I don't agree that we necessarily have to complete a standards process in order to refer to it; that would put, for instance, the Zip format (used, among other places, in OOXML and ODF) out of scope for standards.

WRT IPR issues: I think we just have to push forward on the assumption that all IPR holders who are part of the process will do their duty and disclose any relevant IPR, and hope that IPR held by nonparticipants in the process is not serious enough to cause us to regret our decision.

Note: The statement about VP8 in the rtcweb-protocols document is a placeholder, put in there to indicate that we need to have the discussion. It's not a WG decision, but input to a WG discussion.

                      Harald

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

On 12/22/10 22:12, Markus.Isomaki@nokia.com wrote:

Hi Harald,

We can reference things as long as they are public and stable. But I also think that if we were to mandate some technology as part of an IETF standard, the future development of that technology should preferably be done under an open process. How does the future development of VP8 (or VP9) will happen from that point of view? I've seen some concerns about this so it would be good to get the facts.

VP8 (the bitstream format) is not going to change in any incompatible way. Too much software and hardware is already dependent on the current definition. It seems reasonable to do the development of a successor specification in a standards body, but that's probably going to take a few years.

As long as VP8 spec itself is not published as an Internet-draft, I don't suppose the IETF IPR rules apply to it. So I'm not sure which process we are following with it right now. That would be good to clarify.

I'm hoping to make that clearer within a few weeks - sorry that I can't say more yet.

Regards,

Markus

*From:*ext Harald Alvestrand [mailto:harald@alvestrand.no] *Sent:* 22 December, 2010 17:14 *To:* Bernard Aboba *Cc:* Isomaki Markus (Nokia-CIC/Espoo); peter.musgrave@magorcorp.com; rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com *Subject:* Codec standardization (Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)

On 12/22/10 07:18, Bernard Aboba wrote:

It does appear presumptive to suggest that a codec that hasn't completed a standardization process be made "mandatory to implement."

Since there have been some large judgments over use of allegedly "free" codecs, the lesson is that codecs that are claimed to be "free of encumbrance" may in time be discovered not to be. The IETF process can potentially be useful in helping to clarify the IPR status of codecs. However, those wheels grind slowly.

I agree that we can't make anything mandatory to implement that we don't have an accepted stable, publicly available reference for. (I'm working on solving that for the case of VP8).

However, I don't agree that we necessarily have to complete a standards process in order to refer to it; that would put, for instance, the Zip format (used, among other places, in OOXML and ODF) out of scope for standards.

WRT IPR issues: I think we just have to push forward on the assumption that all IPR holders who are part of the process will do their duty and disclose any relevant IPR, and hope that IPR held by nonparticipants in the process is not serious enough to cause us to regret our decision.

Note: The statement about VP8 in the rtcweb-protocols document is a placeholder, put in there to indicate that we need to have the discussion. It's not a WG decision, but input to a WG discussion.

Harald