Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
I have to agree. If IPR issues are what we want to avoid, VP8 seems like a poor choice (e.g. <http://www.digitaltrends.com/computing/mpeg-la-looking-at-patents-for-googles-vp8webm-video/>). On Dec 21, 2010, at 13:38 , 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] 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> 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
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
David Singer Multimedia and Software Standards, Apple Inc.
I also feel that it's not appropriate to choose VP8 as a mandatory codec. It makes sense to limit any mandatory codecs to standards. If VP8 does need to be standardized, the IETF CODEC WG comes to my mind as a possible place to carry out such a standard - I do understand that this WG is currently only focused on audio. I suppose the charter could be changed to include video. One advantage of this WG is that it aims to deliver a royalty-free spec. There's also a Call-for-Evidence put out by ISO/MPEG with the aim of starting a royalty-free codec development activity. Regards Gerard Fernando ________________________________ From: David Singer <singer@apple.com> To: markus.isomaki@nokia.com Cc: rtc-web@alvestrand.no; dispatch@ietf.org; ted.ietf@gmail.com Sent: Tue, 21 December, 2010 13:46:00 Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 I have to agree. If IPR issues are what we want to avoid, VP8 seems like a poor choice (e.g. <http://www.digitaltrends.com/computing/mpeg-la-looking-at-patents-for-googles-vp8webm-video/>). On Dec 21, 2010, at 13:38 , 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] 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> 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
_______________________________________________
dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
David Singer Multimedia and Software Standards, Apple Inc.
Where is the MPEG-LA patent pool for WebM? As far as I can tell this has just been a hollow announcement, but MPEG-LA have not been able to set up such a patent pool yet. Maybe it's because there aren't any patents out there that are being infringed? Unfortunately, the non-existence of infringing patents can never be proven and this situation is therefore always open to creating fear, uncertainty and doubt. Also note that going through an actual standardisation process and becoming part of a license pool by MPEG-LA doesn't actually protect you from lawsuits for patent infringement, see e.g. http://www.itnews.com.au/News/74186,apple-samsung-and-sandisk-hit-by-mp3-pat... MPEG-LA patent pools are only there to protect you from lawsuits of patents that are being made available through the pool. The pool is not an insurance against patent infringement lawsuits - not even from those that have joined the patent pool, as the law suit of Lucent against MicroSoft has taught us: http://en.wikipedia.org/wiki/Alcatel-Lucent_v._Microsoft As said before: IPR issues are not a good decision factor on which to select a codec for common use. Royalty-free is important. And the rest should be based on technical merit. Regards, Silvia. On Tue, Dec 21, 2010 at 10:46 PM, David Singer <singer@apple.com> wrote:
I have to agree. If IPR issues are what we want to avoid, VP8 seems like a poor choice (e.g. < http://www.digitaltrends.com/computing/mpeg-la-looking-at-patents-for-google...
).
On Dec 21, 2010, at 13:38 , 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] *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
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
David Singer Multimedia and Software Standards, Apple Inc.
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
I agree with what Silvia says here. Similarly, I believe royalty free is the goal/requirement for the new internet audio codec currently being standardized by the IETF. Furthermore, the term IPR free is also wrong since the designers/contributors that make the codec royalty free usually have IPR in th codec. The best one can do is to do your best in avoiding other known IPR. Roar On Wed, Dec 22, 2010 at 8:31 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>wrote:
Where is the MPEG-LA patent pool for WebM? As far as I can tell this has just been a hollow announcement, but MPEG-LA have not been able to set up such a patent pool yet. Maybe it's because there aren't any patents out there that are being infringed? Unfortunately, the non-existence of infringing patents can never be proven and this situation is therefore always open to creating fear, uncertainty and doubt.
Also note that going through an actual standardisation process and becoming part of a license pool by MPEG-LA doesn't actually protect you from lawsuits for patent infringement, see e.g.
http://www.itnews.com.au/News/74186,apple-samsung-and-sandisk-hit-by-mp3-pat...
MPEG-LA patent pools are only there to protect you from lawsuits of patents that are being made available through the pool. The pool is not an insurance against patent infringement lawsuits - not even from those that have joined the patent pool, as the law suit of Lucent against MicroSoft has taught us: http://en.wikipedia.org/wiki/Alcatel-Lucent_v._Microsoft
As said before: IPR issues are not a good decision factor on which to select a codec for common use. Royalty-free is important. And the rest should be based on technical merit.
Regards, Silvia.
On Tue, Dec 21, 2010 at 10:46 PM, David Singer <singer@apple.com> wrote:
I have to agree. If IPR issues are what we want to avoid, VP8 seems like a poor choice (e.g. < http://www.digitaltrends.com/computing/mpeg-la-looking-at-patents-for-google...
).
On Dec 21, 2010, at 13:38 , 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] *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
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
David Singer Multimedia and Software Standards, Apple Inc.
_______________________________________________
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/21/10 22:46, David Singer wrote:
I have to agree. If IPR issues are what we want to avoid, VP8 seems like a poor choice (e.g. <http://www.digitaltrends.com/computing/mpeg-la-looking-at-patents-for-googles-vp8webm-video/>). That article is by now 7 months old (May 2010), and AFAIK, no specific IPR claims have been made public.
I wouldn't presume to claim that this proves anything. Harald
On Dec 21, 2010, at 13:38 , markus.isomaki@nokia.com <mailto: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>[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 <mailto:rtc-web@alvestrand.no>;dispatch@ietf.org <mailto: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 _______________________________________________ dispatch mailing list dispatch@ietf.org <mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch
David Singer Multimedia and Software Standards, Apple Inc.
participants (5)
-
David Singer -
Gerard Fernando -
Harald Alvestrand -
Roar Hagen -
Silvia Pfeiffer