Subject: [rtcweb] VP8 vs H.264 - the core issue

From: Harald Alvestrand <[email-masked]>
Date: Wed, 23 Oct 2013 20:51:02 +0200

Just a reminder:
The back-and-forth of numbers doesn't change the core question of this
debate.
Both codecs are capable of high quality video encoding, and performance
numbers are comparable.

The real core question is the IPR issue.

The tradition of the IETF says that allowing only business models that
can sustain royalty agreements and royalty payments is Bad for the Internet.

The dominant video codec, H.264, is a royalty-required codec.

Do we switch now, or do we give up and live with royalties forever?

-- 
Surveillance is pervasive. Go Dark.

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Wed, 23 Oct 2013 15:42:39 -0400

> Do we switch now, or do we give up and live with royalties forever?

Harald,

I would like to see some references to the tradition of the IETF that
you've quoted.

For the record, I agree with the sentiment, but I'd like to be able to
back up the claim itself with references or explicit decisions that were
made in that regard.  I'm not trying to be a thorn in your side, just
looking for citations to back up the arguments, both on and off list.

-- 
Libre Video
http://librevideo.org

---

From: cowwoc <[email-masked]>
Date: Wed, 23 Oct 2013 16:55:17 -0400

Harald,

     I think it is premature to imply that VP8 is royalty free. I have 
nothing against the codec (it's great) but it's my understanding that 
Google can't guarantee that someone else won't exercise IPR rights 
against VP8 in the future. The best we can say is that H264 requires 
royalties today and VP8 *might* require royalties in the future. H264 
has a slight advantage in this space in that we have well-understood 
licensing terms.

     I just wanted to put that out there so there are no confusions in 
the future.

Gili

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Wed, 23 Oct 2013 17:05:32 -0400

>     I just wanted to put that out there so there are no confusions in

Actually, this is exactly the kind of FUD that has stifled the adoption
of VP8 and, before it, Theora and Vorbis, as universally-available
multimedia format.  It serves only to confuse the issue further, as I
will explain below.

For starters, there is no evidence whatsoever that there is a viable IPR
concern with VP8, but there exist baseless allegations.  In fact, what
little doubt that there might have been one was settled by the agreement
signed between Google and MPEG-LA [1] a short while ago, which resulted
in MPEG-LA withdrawing their attempt a forming a patent pool for VP8
altogether.  An attempt, I might add, that had little public activity
save for its initial announcement once VP8 was being concerned for
international standards.  In fact, the extremely generous terms of the
agreement lend credence to the fact that there was little that existing
that would have been enforceable.

Furthermore, the fact that there is an existing licensing structure for
H.264 give exactly zero assurances of protections from IPR claims,
because not all licensors of H.264 technology are a member of the
MPEG-LA patent pool agreement, and there have been numerous patent cases
related to H.264 and other technologies thought to be covered by RAND
and FRAND terms.

Finally, the current patent and IPR landscape, at least in the US, and
widely in other portions of the world, eliminates the possibility of
something *never* being under a patent threat, due to the presence of
patent trolls that actively wait for adoption as well the sheer
magnitude of patents and the very ease with which patent legislation can
be brought up (including for those already "covered" by existing patent
pools, e.g., H.264).

So, in actuality, H.264 holds no advantage over VP8 in this regard, and
the claim that VP8 is a liability to use is not evidenced by any actual
unique tangible threat to date.

[1] http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html

-- 
Libre Video
http://librevideo.org

---

From: Monty Montgomery <[email-masked]>
Date: Wed, 23 Oct 2013 17:37:51 -0400

> I think it is premature to imply that VP8 is royalty free.

...and we can't be 100% sure vaccines don't cause autism.  Throw 'em all out!

Seriously, at this point, I've been hearing this exact IPR line for
twenty years as an excuse for not doing the right thing.  'They' were
going to come after Vorbis, 'they' were going to come after Theora,
'they' were going to come after Speex, 'they're' supposedly coming
after Opus, and now 'they're' coming after VP8.  I'm sure we'll repeat
it for VP9, VP10 and Daala.  Fool me once, shame on you.  Fool me
twice, shame on me.  Fool me indefinitely, you have a wonderful future
waiting in sales and marketing.

If you want to contend that using VP8 is riskier because it is going
against the traditional, established industry channels, that's a
defensible argument.  But that isn't about the IPR.   Someone who
wants to litigate rather than compete on merit is going to find a way
to litigate, IPR or no.  That is true of both the VP8 and MPEG
positions.  However, we should not make technical decisions based upon
identifying and standing with the most economically powerful external
faction.

Monty

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 24 Oct 2013 08:46:04 +1100

> [1] http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html

On top of all this, it seems to me that
http://www.ietf.org/rfc/rfc3979.txt requires all IPR holders on a
technology that is made part of an RFC to disclose their IPR and sign
a patent disclosure: http://tools.ietf.org/html/rfc3905 . I think this
process is trivial for VP8, but will require lengthy delays for
sorting out for H.264. In the interest of the Internet Community,
given that both codecs provide comparable quality at comparable
bitrates, we need to choose what is best for the Internet community.
RFC3979 even states this explicitly:

" In all matters of Intellectual Property Rights, the intent is to
   benefit the Internet community and the public at large, while
   respecting the legitimate rights of others."

It seems clear that given that there is no substantial technical
difference between the two, given that the IRP situation is so much
cleaner for VP8, and that the only known IPR holder for VP8 (ever
after challenges) is Google who are providing a perpetual royalty-free
license (http://www.webmproject.org/license/bitstream/), the
preference of the Internet community must clearly lie with VP8.

I would be surprised if the IESG - who has to consider IPR rights when
approving an RFC for publication - wouldn't have to overrule any
decision made by this WG to choose H.264 over VP8.

RFC3979 states:
" In general, IETF working groups prefer technologies with no known IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing."

Best Regards,
Silvia.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Oct 2013 15:55:24 -0600

On 10/23/13 3:46 PM, Silvia Pfeiffer wrote:

> technology that is made part of an RFC to disclose their IPR and
> sign a patent disclosure:

That's not true. Only those who contribute to the relevant work need
to disclose. You can sit in all the WG sessions, but if you never say
a word you're not a contributor and you have no obligation to file a
disclosure.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 24 Oct 2013 10:32:58 +1100

On Thu, Oct 24, 2013 at 8:55 AM, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

It also talks about known IPR from non-contributing people and that
that has to be disclosed, too.

Regards,
Silvia.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Oct 2013 18:24:08 -0600

On 10/23/13 5:32 PM, Silvia Pfeiffer wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>>> http://www.ietf.org/rfc/rfc3979.txt requires all IPR holders on
>>> a technology that is made part of an RFC to disclose their IPR
>>> and sign a patent disclosure:
>> 
>> That's not true. Only those who contribute to the relevant work
>> need to disclose. You can sit in all the WG sessions, but if you
>> never say a word you're not a contributor and you have no
>> obligation to file a disclosure.
> 
> It also talks about known IPR from non-contributing people and
> that that has to be disclosed, too.

Your use of the passive voice here is misleading.

Certainly non-contributors might have IPR. But they have no obligation
to disclose.

I might wish that what you say is true, but it isn't (IMHO). If you
have questions about the IETF's IPR rules, I suggest that you talk
with the responsible Area Director.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Thu, 24 Oct 2013 08:33:33 +0000

Hi,

Basil Mohamed Gohar wrote:
> concern with VP8, but there exist baseless allegations.  In fact, what little
> doubt that there might have been one was settled by the agreement signed
> between Google and MPEG-LA [1] a short while ago, which resulted in
> MPEG-LA withdrawing their attempt a forming a patent pool for VP8
> altogether.  An attempt, I might add, that had little public activity save for its
> initial announcement once VP8 was being concerned for international
> standards.  In fact, the extremely generous terms of the agreement lend
> credence to the fact that there was little that existing that would have been
> enforceable.
>

Please remember that Nokia has submitted an IPR declaration about VP8:
https://datatracker.ietf.org/ipr/2035/
 
VP8 has been proposed as basis for standardization in MPEG. If that proceeds, there will be points in the process where companies need to make IPR declarations (RF, RAND, or neither). In that case we would eventually know more about VP8 IPR status than what is currently in public. 

> H.264 give exactly zero assurances of protections from IPR claims, because
> not all licensors of H.264 technology are a member of the MPEG-LA patent
> pool agreement, and there have been numerous patent cases related to
> H.264 and other technologies thought to be covered by RAND and FRAND
> terms.
>

The H.264 RAND/FRAND commitments do not depend on MPEG-LA membership but stem from the MPEG IPR rules and declarations. 

Markus

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 24 Oct 2013 11:05:19 +0000

"requires all IPR holders on a technology that is made part of an RFC to disclose"

Is not what the document actually says.

If you are going to attribute please attribute correctly. 

Regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Silvia Pfeiffer
> Sent: 23 October 2013 22:46
> To: Basil Mohamed Gohar
> Cc: [email-masked]
> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
> 
> > Actually, this is exactly the kind of FUD that has stifled the 
> > adoption of VP8 and, before it, Theora and Vorbis, as 
> > universally-available multimedia format.  It serves only to confuse 
> > the issue further, as I will explain below.
> >
> > For starters, there is no evidence whatsoever that there is 
> a viable 
> > IPR concern with VP8, but there exist baseless allegations. 
>  In fact, 
> > what little doubt that there might have been one was settled by the 
> > agreement signed between Google and MPEG-LA [1] a short while ago, 
> > which resulted in MPEG-LA withdrawing their attempt a 
> forming a patent 
> > pool for VP8 altogether.  An attempt, I might add, that had little 
> > public activity save for its initial announcement once VP8 
> was being 
> > concerned for international standards.  In fact, the extremely 
> > generous terms of the agreement lend credence to the fact 
> that there 
> > was little that existing that would have been enforceable.
> >
> > MPEG-LA patent pool agreement, and there have been numerous patent 
> > cases related to H.264 and other technologies thought to be 
> covered by 
> > RAND and FRAND terms.
> >
> > magnitude of patents and the very ease with which patent 
> legislation 
> > can be brought up (including for those already "covered" by 
> existing 
> > patent pools, e.g., H.264).
> >
> > So, in actuality, H.264 holds no advantage over VP8 in this regard, 
> > and the claim that VP8 is a liability to use is not 
> evidenced by any 
> > actual unique tangible threat to date.
> >
> http://www.ietf.org/rfc/rfc3979.txt requires all IPR holders 
> on a technology that is made part of an RFC to disclose their 
> IPR and sign a patent disclosure: 
> http://tools.ietf.org/html/rfc3905 . I think this process is 
> trivial for VP8, but will require lengthy delays for sorting 
> out for H.264. In the interest of the Internet Community, 
> given that both codecs provide comparable quality at 
> comparable bitrates, we need to choose what is best for the 
> Internet community.
> It seems clear that given that there is no substantial 
> technical difference between the two, given that the IRP 
> situation is so much cleaner for VP8, and that the only known 
> IPR holder for VP8 (ever after challenges) is Google who are 
> providing a perpetual royalty-free license 
> (http://www.webmproject.org/license/bitstream/), the 
> I would be surprised if the IESG - who has to consider IPR 
> rights when approving an RFC for publication - wouldn't have 
> to overrule any decision made by this WG to choose H.264 over VP8.
> 
> RFC3979 states:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 24 Oct 2013 13:12:16 +0200

> looking for citations to back up the arguments, both on and off list.
Basil, very happy to provide references!

RFC 3979, a core document about IPR in the IETF, 2005:

8.  Evaluating Alternative Technologies in IETF Working Groups

   In general, IETF working groups prefer technologies with no known IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.

The complete section gives some more details, but this is the central quote.

You may also enjoy reading the section of RFC 6569 (the guidelines that
were followed in the OPUS work) that deals with IPR:

http://tools.ietf.org/html/rfc6569#page-8

---

From: Bo Burman <[email-masked]>
Date: Thu, 24 Oct 2013 13:26:30 +0000

1) We do agree that H.264 Constrained Baseline and VP8 are comparable in terms of video quality. But do not forget that Constrained Baseline's twin sister H.264 Constrained High outperforms VP8 by a huge margin. This is also relevant.

2) The "back-and forth of numbers" seems to refer to Ericsson's work where we tried to make a fair comparison to evaluate the extraordinary claims from Google that VP8 is 70 or 40 percent better than x264. We found serious issues with the way Google performed the test, maybe the most striking were the use of padding (+8% for x264) and excessive number of threads (+10% to +40% for x264) to add overhead to x264. That Google managed to remember the threading parameter only when it helped
VP8 (the speed test) is also quite remarkable.

3) Regarding IPR, this is a difficult topic, but we're not at all convinced that VP8 is royalty free. For example, there is an IETF IPR disclosure (https://datatracker.ietf.org/ipr/2035/) where the IPR holder seems unwilling to license (on any terms), and http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.html and http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias.html show that there are in fact ongoing litigations regarding VP8 - and this is only skimming the surface of what is available in public space.

/Bo

From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: den 24 oktober 2013 13:12
To: [email-masked]
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

Just a reminder:

debate.

numbers are comparable.

Harald,

you've quoted.

You may also enjoy reading the section of RFC 6569 (the guidelines that were followed in the OPUS work) that deals with IPR:

--

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 24 Oct 2013 16:09:37 +0200

On 10/24/2013 03:26 PM, Bo Burman wrote:
>
> 1) We do agree that H.264 Constrained Baseline and VP8 are comparable
> in terms of video quality. But do not forget that Constrained
> Baseline's twin sister H.264 Constrained High outperforms VP8 by a
> huge margin. This is also relevant.
>

I actually haven't seen a test I can quote on that - at least not with
parameters that make sense in a videoconferencing setting (use of rate
control, no B-frames and CBR mode).

There was a series of tests (both subjective and objective) done on both
High Profile and VP8 as part of the MPEG evaluation of VP8 as a response
to the last Call for Proposals, but after the discussions we had in
Incheon, MPEG decided to not publish the results of this viewing as a
"comparision", so I won't call it that.

>  
>
> 2) The "back-and forth of numbers" seems to refer to Ericsson's work
> where we tried to make a fair comparison to evaluate the extraordinary
> claims from Google that VP8 is 70 or 40 percent better than x264. We
> found serious issues with the way Google performed the test, maybe the
> most striking were the use of padding (+8% for x264) and excessive
> number of threads (+10% to +40% for x264) to add overhead to x264.
> That Google managed to remember the threading parameter only when it
> helped
>

I was also astonished to learn that x264's default value for "threads"
gave a 10-40% performance penalty over "threads=1"!

On a speed test, we tried to do a bit of "like against like" - the VP8
encoder is by default single-threaded, so it seemed only reasonable to
run the other encoder single-threaded too. I haven't pursued the speed
tests since then; they are quite a bit harder to get consistent results
from than tests that have a deterministic result.

Yes, we should have tested each piece of the advice we got from the x264
developers on how to run x264 in something close to "constant bitrate
mode", instead of just dumping all the flags on our command line
uncritically. That was a mistake, and led to the nal-unit parameter,
whch we should never have used.

We have published our tests, exactly so that they can be evaluated.
We want to do a good job of incorporating feedback - but we will keep on
insisting that the tests should have some relationship to a realistic
WebRTC scenario.

In our opinion, that means working in one pass and using rate control.

>  
>
> 3) Regarding IPR, this is a difficult topic, but we're not at all
> convinced that VP8 is royalty free. For example, there is an IETF IPR
> disclosure (https://datatracker.ietf.org/ipr/2035/) where the IPR
> holder seems unwilling to license (on any terms), and
> http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.html
> and
> http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias.html
> show that there are in fact ongoing litigations regarding VP8 - and
> this is only skimming the surface of what is available in public space.
>

If you have more specific information, feel free to share it.
The continued use of "there's more information out there" is not helpful
to anyone. Either you have specific information to bring, or you don't.

And since you bring a June mention of the German case, I should mention
this August note from the same case, which I also quoted in the VP8
internet-draft:

http://blog.webmproject.org/2013/08/good-news-from-germany.html

I refuse to comment on fosspatents.com's commentary.

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 24 Oct 2013 10:21:03 -0400

> I refuse to comment on fosspatents.com's commentary.

Of course, as we do, after all, want to keep things civil, right?  ;)

-- 
Libre Video
http://librevideo.org

---

From: Ted Hardie <[email-masked]>
Date: Thu, 24 Oct 2013 07:30:02 -0700

On Thu, Oct 24, 2013 at 6:26 AM, Bo Burman <[email-masked]> wrote:

>  1) We do agree that H.264 Constrained Baseline and VP8 are comparable in
> terms of video quality. But do not forget that Constrained Baseline's twin
> sister H.264 Constrained High outperforms VP8 by a huge margin. This is
> also relevant.****
>
> ** **
>
>
Hi Bo,

I note that one of the recent editorial updates you made to the draft is
this:

 H.264 Constrained High Profile Level 1.3, logically extended to
      support 720p resolution at 30 Hz framerate is RECOMMENDED.

that is, you added the word "logically".  Is "logically extended" a term of
art here, or do you simply mean you think it makes sense to extend the

support to Constrained High Profile Level 1.3?

I also note that the discussion here is about a Mandatory to Implement codec
(that is, something at a MUST level that avoids negotiation failure).  Your
document appears to assign that to Constrained Baseline Profile Level 1.2.

The discussion of Constrained High seems to me about an optimization and
is at most an aside, and not part of the core issue to be decided.
If you have changed your view and  believe that Constrained High Profile
Level 1.3 should be mandatory to implement, then it would be useful to say
so more forcefully than above. If you have not, then I believe it is not,
strictly speaking, relevant.

My personal view,

regards,

Ted Hardie

---

From: Bo Burman <[email-masked]>
Date: Thu, 24 Oct 2013 15:40:35 +0000

From: Ted Hardie [mailto:[email-masked]]
Sent: den 24 oktober 2013 16:30
To: Bo Burman
Cc: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

On Thu, Oct 24, 2013 at 6:26 AM, Bo Burman <[email-masked]<mailto:[email-masked]>> wrote:
1) We do agree that H.264 Constrained Baseline and VP8 are comparable in terms of video quality. But do not forget that Constrained Baseline's twin sister H.264 Constrained High outperforms VP8 by a huge margin. This is also relevant.

Hi Bo,
I note that one of the recent editorial updates you made to the draft is this:

support to Constrained High Profile Level 1.3?
[BoB] Maybe the text is unclear. It is not meant to modify the MTI in any way. See further discussion at the bottom of this mail.

What "logically extended" intends to achieve is to specify a set of parameter values applied to the encoding process, starting from the set called "level 1.3" and increasing a few parameter values beyond "level 1.3". The word "extended" for this operation is fully in line with existing text in RFC 6184 specifying how to signal H.264 codec capability. "Logically extended" is not a term of art but was chosen due to a comment that an H.264 level cannot formally be "extended" in ISO/ITU-T terms even though the term is used in RFC 6184, but you will have to restrict a higher level instead. The result is however the same; a set of specified parameter values applied to the encoding process.

[BoB] Yes, and still do.

[BoB] I did not change my mind on MTI; it is Constrained Baseline.

I do believe the discussion on Constrained High is relevant; it is part of the overall argumentation for H.264 and relates to the important aspect of potential for improvement beyond MTI. H.264 Profiles and Levels are essentially parameter restrictions on a single codec specification. If you have H.264 CBP as MTI but want access to even better performance, you don't have to implement or license yet another codec but can still make use of H.264, only with another parameter setting (given that the specific implementation supports both CBP and CHP). Given that there are many other possible ways to set parameters to "H.264", pointing to a specific "good" one beyond MTI seemed reasonable. This is arguably an optimization, but not only that.

My personal view,

regards,

Ted Hardie

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 24 Oct 2013 16:02:37 +0000

On the IPR issue, Google reached agreement with 11 patent holders. There are at least 31 companies in the MPEG-LA H.264 pool. There is considerable technical overlap between VP8 and H.264.

My employer is one of those in the H.264 pool, and wasn't one of the 11 companies Google reached an agreement with.

Draw your own conclusions and take your own IPR risks.

Personally I'd rather the IPR devil I know vs. the IPR devil I don't know.

Google could fix this for most potential users (through indemnification, similar to what Oracle offers its Linux licensees) but has chosen not to. You can draw your own conclusion there, too.

Matthew Kaufman

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bo Burman
Sent: Thursday, October 24, 2013 6:27 AM
To: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

/Bo

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: den 24 oktober 2013 13:12
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

Just a reminder:

debate.

numbers are comparable.

Harald,

you've quoted.

--

---

From: David Singer <[email-masked]>
Date: Thu, 24 Oct 2013 09:09:07 -0700

> support to Constrained High Profile Level 1.3?

I think that merely means it's easier to speak of extending a level to support something, but actually, it would formally have to be expressed as a restriction on a higher level (which takes more explaining and words, which don't seem needed here).

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Bo Burman <[email-masked]>
Date: Thu, 24 Oct 2013 16:26:33 +0000

From: Harald Alvestrand [mailto:[email-masked]]
Sent: den 24 oktober 2013 16:10
To: Bo Burman; [email-masked]
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

We have published our tests, exactly so that they can be evaluated.
We want to do a good job of incorporating feedback - but we will keep on insisting that the tests should have some relationship to a realistic WebRTC scenario.

[BoB] One pass: agree. Using rate control: arguably yes, but as our recent posts with the rate control patch to x264 indicate, if you intend to compare codecs and apply similar rate control to all the tested codecs it is likely that you will get comparison results similar to what you would get with fixed-QP. Tests with and without rate control will likely not give the same results in absolute terms, but it is likely the relative performance of codecs either with or without rate control will yield similar results in a fair test.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 24 Oct 2013 09:55:42 -0700

On Thu, Oct 24, 2013 at 8:40 AM, Bo Burman <[email-masked]> wrote:

>   **
>
> *What “logically extended” intends to achieve is to specify a set of
> parameter values applied to the encoding process, starting from the set
> called “level 1.3” and increasing a few parameter values *
>

Is this meant to be level 1.2?  The draft says:

H.264 Constrained Baseline Profile Level 1.2 MUST be supported as
      Mandatory To Implement video codec.

I assume that this means shifting from 1.2 to 1.3 with the parameter set
for CHB?

> *beyond “level 1.3”. The word “extended” for this operation is fully in
> line with existing text in RFC 6184 specifying how to signal H.264 codec
> capability. “Logically extended” is not a term of art but was chosen due to
> a comment that an H.264 level cannot formally be “extended” in ISO/ITU-T
> terms even though the term is used in RFC 6184, but you will have to
> restrict a higher level instead. The result is however the same; a set of
> specified parameter values applied to the encoding process. *****
>
> * *
>
>
>
> ****
> *[BoB] Yes, and still do.*
>
>
>
> strictly speaking, relevant.****
>
> *[BoB] I did not change my mind on MTI; it is Constrained Baseline.*
>
> * *
>
> *I do believe the discussion on Constrained High is relevant; it is part
> of the overall argumentation for H.264 and relates to the important aspect
> of potential for improvement beyond MTI. *
>

I described this an optimization, and I think your comments actual support
that.  Our overall approach allows negotiating among multiple codes; the MTI
is not a restriction.  Having part of that negotiated set be related may
make
is simpler to support, but it is entirely possible to do it across codec
families
as well.

> *H.264 Profiles and Levels are essentially parameter restrictions on a
> single codec specification. If you have H.264 CBP as MTI but want access to
> even better performance, you don’t have to implement or license yet another
> codec but can still make use of H.264, only with another parameter setting
> (given that the specific implementation supports both CBP and CHP). Given
> that there are many other possible ways to set parameters to “H.264”,
> pointing to a specific “good” one beyond MTI seemed reasonable. This is
> arguably an optimization, but not only that.*
>
> **
>

I'm not sure I understand what makes it more than an optimization.

regards,

Ted Hardie

> **
> Ted Hardie****

---

From: Ted Hardie <[email-masked]>
Date: Thu, 24 Oct 2013 09:59:56 -0700

Hi Matthew,

On Thu, Oct 24, 2013 at 9:02 AM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

>  On the IPR issue, Google reached agreement with 11 patent holders. There
> are at least 31 companies in the MPEG-LA H.264 pool. There is considerable
> technical overlap between VP8 and H.264.****
>
> ** **
>
> My employer is one of those in the H.264 pool, and wasn’t one of the 11
> companies Google reached an agreement with.****
>
> ** **
>
> Draw your own conclusions and take your own IPR risks.****
>
> **
>

If you would like to make an IPR declaration according to the IETF
IPR process, the form is available here:

https://datatracker.ietf.org/ipr/new-specific/

If you would prefer to email one, [email-masked] is the correct email
address.
Statements of the form above to WG mailing lists do not appear to me qualify
as IPR statements in  the IETF IPR process, at least as I understand it.

regards,

Ted Hardie

> **
>
> Personally I’d rather the IPR devil I know vs. the IPR devil I don’t know.
> ****
>
> ** **
>
> Google could fix this for most potential users (through indemnification,
> similar to what Oracle offers its Linux licensees) but has chosen not to.
> You can draw your own conclusion there, too.****
>
> ** **
>
> Matthew Kaufman****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Bo Burman
> *Sent:* Thursday, October 24, 2013 6:27 AM
> *To:* Harald Alvestrand; [email-masked]
>
> *Subject:* Re: [rtcweb] VP8 vs H.264 - the core issue****
>
>  ** **
>
> 2) The "back-and forth of numbers" seems to refer to Ericsson's work where
> we tried to make a fair comparison to evaluate the extraordinary claims
> from Google that VP8 is 70 or 40 percent better than x264. We found serious
> issues with the way Google performed the test, maybe the most striking were
> the use of padding (+8% for x264) and excessive number of threads (+10% to
> +40% for x264) to add overhead to x264. That Google managed to remember the
> threading parameter only when it helped****
>
> VP8 (the speed test) is also quite remarkable.****
>
> ** **
>
> disclosure (https://datatracker.ietf.org/ipr/2035/) where the IPR holder
> seems unwilling to license (on any terms), and
> http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.htmland
> http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias.htmlshow that there are in fact ongoing litigations regarding VP8 - and this is
> only skimming the surface of what is available in public space.****
>
> ** **
>
> /Bo****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Harald Alvestrand
> *Sent:* den 24 oktober 2013 13:12
> *To:* [email-masked]
> *Subject:* Re: [rtcweb] VP8 vs H.264 - the core issue****
>
> ** **
>
> On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:****
>
> On 10/23/2013 02:51 PM, Harald Alvestrand wrote:****
>
>  Just a reminder:****
>
> The back-and-forth of numbers doesn't change the core question of this****
>
> debate.****
>
> Both codecs are capable of high quality video encoding, and performance****
>
> numbers are comparable.****
>
> ** **
>
> The real core question is the IPR issue.****
>
> ** **
>
> The tradition of the IETF says that allowing only business models that****
>
> can sustain royalty agreements and royalty payments is Bad for the Internet.****
>
> ** **
>
> The dominant video codec, H.264, is a royalty-required codec.****
>
> ** **
>
> Do we switch now, or do we give up and live with royalties forever?****
>
> ** **
>
>  ** **
>
> Harald,****
>
> ** **
>
> I would like to see some references to the tradition of the IETF that****
>
> you've quoted.****
>
> ** **
>
> For the record, I agree with the sentiment, but I'd like to be able to****
>
> back up the claim itself with references or explicit decisions that were****
>
> made in that regard.  I'm not trying to be a thorn in your side, just****
>
> looking for citations to back up the arguments, both on and off list.****
>
> ** **
>
> 8.  Evaluating Alternative Technologies in IETF Working Groups****
>
> ** **
>
>    In general, IETF working groups prefer technologies with no known IPR****
>
>    claims or, for technologies with claims against them, an offer of****
>
>    royalty-free licensing.  But IETF working groups have the discretion****
>
>    to adopt technology with a commitment of fair and non-discriminatory****
>
>    terms, or even with no licensing commitment, if they feel that this****
>
>    technology is superior enough to alternatives with fewer IPR claims****
>
>    or free licensing to outweigh the potential cost of the licenses.****
>
>
> -- ****
> Surveillance is pervasive. Go Dark.****
>
>

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 24 Oct 2013 15:34:36 -0400

On 10/24/2013 12:02 PM, Matthew Kaufman (SKYPE) wrote:
> are at least 31 companies in the MPEG-LA H.264 pool. There is
> considerable technical overlap between VP8 and H.264.
> 
> companies Google reached an agreement with.
> 
> similar to what Oracle offers its Linux licensees) but has chosen not
> to. You can draw your own conclusion there, too.
> 
> Matthew Kaufman

There are no conclusions to draw due to lack of sufficient evidence for
anything actionable.  IPR FUD has delayed the adoption of many free,
non-royalty-bearing formats for too long.  And, again, the IPR "devil we
know" is meaningless, because there are still IP litigation threats even
for H.264, MP3, and many other patented, royalty-bearing formats.

So, it contributes little to nothing to the discussion on IPR grounds if
a substantial declaration, as Ted has advised, is not taken, and such
claims should really be discounted in any serious consideration when
weighing options between formats.

-- 
Libre Video
http://librevideo.org

---

From: cowwoc <[email-masked]>
Date: Thu, 24 Oct 2013 16:47:20 -0400

> weighing options between formats.

     I would like to point out that we still have the option of 
mandating the use of an older codec whose IPR has expired (and let 
clients upgrade to VP8 or H264 as they fit).

     But if the community rejects this approach, then I agree that this 
should not hold back the use of VP8.

Gili

---

From: Silvia Pfeiffer <[email-masked]>
Date: Fri, 25 Oct 2013 09:01:36 +1100

Year I over-interpreted. But it does recommend listing all known IPR issues
and that's a lot.
Silvia.
 On 24 Oct 2013 22:05, "DRAGE, Keith (Keith)" <

---

From: Silvia Pfeiffer <[email-masked]>
Date: Fri, 25 Oct 2013 09:09:37 +1100

If VP8 is chosen as MTI, you'd need to come out as per IETF requirements.
So would others. That's a good thing. If there indeed is anything there.
Silvia.
 On 25 Oct 2013 03:11, "Matthew Kaufman (SKYPE)" <[email-masked]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 24 Oct 2013 23:06:54 +0000

Nothing in this decision, whether we make one or not, is holding back the development of any codec.

The debate is on whether and what to specify as a mandatory to implement codec. 

If that was to be the only codecs available, then there will never be any new codecs.

Keith

> [mailto:[email-masked]] On Behalf Of cowwoc
> Sent: 24 October 2013 21:47
> To: [email-masked]
> >> On the IPR issue, Google reached agreement with 11 patent holders. 
> >> There are at least 31 companies in the MPEG-LA H.264 pool. 
> There is 
> >> My employer is one of those in the H.264 pool, and wasn't 
> one of the 
> >> 11 companies Google reached an agreement with.
> >>
> >> Google could fix this for most potential users (through 
> >> indemnification, similar to what Oracle offers its Linux 
> licensees) 
> >> but has chosen not to. You can draw your own conclusion there, too.
> >>
> >> Matthew Kaufman
> > There are no conclusions to draw due to lack of sufficient evidence 
> > for anything actionable.  IPR FUD has delayed the adoption of many 
> > free, non-royalty-bearing formats for too long.  And, 
> again, the IPR 
> > "devil we know" is meaningless, because there are still IP 
> litigation 
> > threats even for H.264, MP3, and many other patented, 
> royalty-bearing formats.
> >
> > So, it contributes little to nothing to the discussion on 
> IPR grounds 
> > if a substantial declaration, as Ted has advised, is not taken, and 
> > such claims should really be discounted in any serious 
> consideration 
> > when weighing options between formats.
> 
>      I would like to point out that we still have the option 
> of mandating the use of an older codec whose IPR has expired 
> (and let clients upgrade to VP8 or H264 as they fit).
> 
>      But if the community rejects this approach, then I agree 
> that this should not hold back the use of VP8.
> 
> Gili

---

From: "cb.list6" <[email-masked]>
Date: Thu, 24 Oct 2013 16:13:40 -0700

On Oct 24, 2013 1:47 PM, "cowwoc" <[email-masked]> wrote:
>     I would like to point out that we still have the option of mandating
the use of an older codec whose IPR has expired (and let clients upgrade to
VP8 or H264 as they fit).
> Gili

There is no holding back vp8, it can always be negotiated.

My guidance is no mti.

I, for one, am tired of the gang-land ipr turf wars and posturing. This
argument is all about ipr, and ietf is explicitly setup to punt on all ipr
issue because they are hard.

Any layperson can see there is no concensus to be found. That's why we
designed for codec negotiating and negotiating away from failure is left
for implementation

CB

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 25 Oct 2013 04:27:39 +0200

Interesting discussion with very technical detail regarding specific tests
verses very general IPR allegations regarding the royal free issue, under
this same thread.

Does anyone know if Nokia has provided any technical relevant and
understandable detail regarding where they think VP8 is infringing or is
https://datatracker.ietf.org/ipr/2035/ 

just a list of some 67 maybe related patents (I count 35 cm * 2,5 lines/cm /
1,3 patents/line = 67 patents) poured into this declaration? 

I notice the “No information submitted”:

C. If an Internet-Draft or RFC includes multiple parts and it is not
reasonably apparent which part of such Internet-Draft or RFC is alleged to
be covered by the patent information disclosed in Section V(A) or V(B), it
is helpful if the discloser identifies here the sections of the
Internet-Draft or RFC that are alleged to be so covered: 

No information submitted

Is the IETF in a position to say something stronger than “it is helpful if
the discloser identifies here the sections of the Internet-Draft or RFC that
are alleged to be so covered” if such declaration is supposed to influence
the selection of codec?

An idea of which claim in which of the 67 listed patents Nokia believes is
being infringed by VP8 is relevant to be able to form an opinion. I added
the named Nokia contact to this email.

/Karl

Från: [email-masked] [mailto:[email-masked]] För Bo Burman
Skickat: den 24 oktober 2013 15:27
Till: Harald Alvestrand; [email-masked]
Ämne: Re: [rtcweb] VP8 vs H.264 - the core issue

1) We do agree that H.264 Constrained Baseline and VP8 are comparable in
terms of video quality. But do not forget that Constrained Baseline's twin
sister H.264 Constrained High outperforms VP8 by a huge margin. This is also
relevant.

2) The "back-and forth of numbers" seems to refer to Ericsson's work where
we tried to make a fair comparison to evaluate the extraordinary claims from
Google that VP8 is 70 or 40 percent better than x264. We found serious
issues with the way Google performed the test, maybe the most striking were
the use of padding (+8% for x264) and excessive number of threads (+10% to
+40% for x264) to add overhead to x264. That Google managed to remember the
threading parameter only when it helped

3) Regarding IPR, this is a difficult topic, but we're not at all convinced
that VP8 is royalty free. For example, there is an IETF IPR disclosure
(https://datatracker.ietf.org/ipr/2035/) where the IPR holder seems
unwilling to license (on any terms), and
http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.html
and
http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias.ht
ml show that there are in fact ongoing litigations regarding VP8 - and this
is only skimming the surface of what is available in public space.

/Bo

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Harald Alvestrand
Sent: den 24 oktober 2013 13:12
To: [email-masked]
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

Just a reminder:

 

 
Harald,

 

You may also enjoy reading the section of RFC 6569 (the guidelines that were
followed in the OPUS work) that deals with IPR:

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 25 Oct 2013 06:16:24 +0200

On 10/25/2013 01:13 AM, cb.list6 wrote:
> I, for one, am tired of the gang-land ipr turf wars and posturing. 
> This argument is all about ipr, and ietf is explicitly setup to punt 
> on all ipr issue because they are hard.
>
> designed for codec negotiating and negotiating away from failure is 
> left for implementation
>
Formalistically, the people who argue for abandoning an MTI, like the 
people who argue for adapting an antiquated codec, have not put in a 
draft by the chairs' deadline of October 6, so have not made a proposal.

But I'm not the one who argued for this to be put on the agenda for 2 hours.
The people who pushed for this to be on the agenda for 2 hours need to 
come forward and say why they believe this is a good use of our time. I 
haven't yet heard a VP8 proponent saying so.

So far, apart from learning a bit more about configuring x264, I haven't 
seen much new information.

---

From: cowwoc <[email-masked]>
Date: Fri, 25 Oct 2013 04:03:12 -0400

On 25/10/2013 12:16 AM, Harald Alvestrand wrote:
>> Any layperson can see there is no concensus to be found. That's why 
>> we designed for codec negotiating and negotiating away from failure 
>> is left for implementation
>>
> come forward and say why they believe this is a good use of our time. 
> I haven't yet heard a VP8 proponent saying so.
>
> So far, apart from learning a bit more about configuring x264, I 
> haven't seen much new information.

     I think the real elephant in the room is whether Apple and 
Microsoft (who are on the H264 bandwagon) will decide to implement VP8 
just because you mandate it or whether they will side-step WebRTC 
altogether. FireFox's market-share is decline so more and more this is 
becoming a story of Chrome vs IE (on desktop) + Safari (on mobile).

     The real question we should be asking is how to get Apple and 
Microsoft on board. If we could get everyone on board, the question of 
what codec should be used would melt away (hint: there is no objective 
answer to this question).

Gili

---

From: <[email-masked]>
Date: Fri, 25 Oct 2013 08:04:22 +0000

Hi,

Harald Alvestrand wrote:
>
> Formalistically, the people who argue for abandoning an MTI, like the people
> who argue for adapting an antiquated codec, have not put in a draft by the
> chairs' deadline of October 6, so have not made a proposal.
> 

I thought it has been mainly the VP8 proponents who have insisted to continue this discussion and have it on the agenda.

I am a H.264 proponent but it's clear to me there is no consensus, no substantially new information since March, and for that reason the IETF should not pick either H.264 or VP8 as *mandatory*. And consequently 2 hours is too much time for this.

It is useful to discuss pros and cons of H.264 and VP8 and compare them, since most likely every WebRTC endpoint will implement at least one of them, but I think we need to stop pushing for the decision of mandating one of them.

Of course, if we come back to this issue every November, we can eventually choose H.264 as mandatory, after all of its IPR has expired :-) 

Markus

---

From: <[email-masked]>
Date: Fri, 25 Oct 2013 08:11:56 +0000

Hi,

cowwoc wrote:
> 
>      I think the real elephant in the room is whether Apple and Microsoft (who
> are on the H264 bandwagon) will decide to implement VP8 just because you
> mandate it or whether they will side-step WebRTC altogether. FireFox's
> market-share is decline so more and more this is becoming a story of Chrome
> vs IE (on desktop) + Safari (on mobile).
> 

I think we can equally well ask whether Chrome and Firefox will support H.264 for WebRTC if IETF mandates that codec.

If the answer to both of these questions is "no", the value of the IETF decision is not that great. 

Markus

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 25 Oct 2013 10:43:52 +0200

Il giorno Fri, 25 Oct 2013 04:03:12 -0400
cowwoc <[email-masked]> ha scritto:

> >> This argument is all about ipr, and ietf is explicitly setup to
> >> punt on all ipr issue because they are hard.
> >>
> >> Any layperson can see there is no concensus to be found. That's
> >> why we designed for codec negotiating and negotiating away from
> >> failure is left for implementation
> >>
> > Formalistically, the people who argue for abandoning an MTI, like
> > the people who argue for adapting an antiquated codec, have not put
> > in a draft by the chairs' deadline of October 6, so have not made a
> > proposal.
> >
> > The people who pushed for this to be on the agenda for 2 hours need
> > to come forward and say why they believe this is a good use of our
> > time. I haven't yet heard a VP8 proponent saying so.
> >
> Microsoft (who are on the H264 bandwagon) will decide to implement
> VP8 just because you mandate it or whether they will side-step WebRTC 
> altogether. FireFox's market-share is decline so more and more this
> is becoming a story of Chrome vs IE (on desktop) + Safari (on mobile).
> 
> Microsoft on board. If we could get everyone on board, the question
> of what codec should be used would melt away (hint: there is no
> objective answer to this question).
> 
> Gili

The real question is not whether or not Apple and Microsoft will
implement VP8, but when they'll deign to start working on something
WebRTC at all. As most of the H.264 advocates in general, I'd dare to
say (at least from what I've seen so far).

Lorenzo

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 25 Oct 2013 08:50:47 +0000

Agree

We can either explicitly make a "no MTI" decision, or just let it become the default by the absence of agreement.

Keith 

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 25 October 2013 09:04
> To: [email-masked]; [email-masked]
> I thought it has been mainly the VP8 proponents who have 
> insisted to continue this discussion and have it on the agenda.
> 
> I am a H.264 proponent but it's clear to me there is no 
> consensus, no substantially new information since March, and 
> for that reason the IETF should not pick either H.264 or VP8 
> as *mandatory*. And consequently 2 hours is too much time for this.
> 
> It is useful to discuss pros and cons of H.264 and VP8 and 
> compare them, since most likely every WebRTC endpoint will 
> implement at least one of them, but I think we need to stop 
> pushing for the decision of mandating one of them.
> 
> Of course, if we come back to this issue every November, we 
> can eventually choose H.264 as mandatory, after all of its 
> IPR has expired :-) 
> 
> Markus

---

From: Leon Geyser <[email-masked]>
Date: Fri, 25 Oct 2013 11:05:13 +0200

It would be nice if video just works for the end user instead of them
having to install a different browser or buying a different device with a
different browser.

I personally think there needs to be a MTI video codec even if it is an old
codec such as H.261. Although the codec should not require a lot of
bandwidth to look decent which excludes something such as MJPEG.

---

From: <[email-masked]>
Date: Fri, 25 Oct 2013 08:59:41 +0000

I don't think this is true. A person must disclose all IPR he/she is reasonably and personally aware of related to his/her own contribution or contribution made by others (in certain conditions). But in neither case is the person required to know all potential IPR his/her employer has, nor is the employer required to do a search of their IPR portfolio for that purpose. In this particular case things are even more vague since neither VP8 or H.264 is an IETF-developed technology. IETF is just referencing those technologies in its own documents. For instance regarding H.264 everyone's interpretation is (or seems to be) that IETF declarations are not done especially since the IPR is already declared in ISO/MPEG/ITU. For VP8 Nokia indeed did a declaration, but we did not think we were _required_ to do so. And I have heard from a few other companies that their interpretation is the same.

So I don't think the IETF IPR disclosure & declaration process can be much relied upon in this case, especially related to what IPR do the various _companies_ _overall_ have. Otherwise we could also consider H.264 as unencumbered since there are no IETF IPR declarations about it at the moment...

Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Silvia Pfeiffer
Sent: 25 October, 2013 01:10
To: Matthew Kaufman
Cc: [email-masked]
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

If VP8 is chosen as MTI, you'd need to come out as per IETF requirements. So would others. That's a good thing. If there indeed is anything there.
Silvia.
On 25 Oct 2013 03:11, "Matthew Kaufman (SKYPE)" <[email-masked]<mailto:[email-masked]>> wrote:
On the IPR issue, Google reached agreement with 11 patent holders. There are at least 31 companies in the MPEG-LA H.264 pool. There is considerable technical overlap between VP8 and H.264.

Matthew Kaufman

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bo Burman
Sent: Thursday, October 24, 2013 6:27 AM
To: Harald Alvestrand; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

/Bo

Just a reminder:

debate.

numbers are comparable.

Harald,

you've quoted.

--

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 25 Oct 2013 11:12:49 +0000

If you want that, then you would need both VP8 and H.264 as MTI.

While VP8 might give you what you want in webrtc islands, it would not be able to communicate outside those islands, where the predominant codec is still H.248.

While a position of both codecs being MTI would be acceptable to me, I don't see the VP8 proponents going there.

Keith

________________________________
From: Leon Geyser [mailto:[email-masked]]
Sent: 25 October 2013 10:05
To: [email-masked]
Cc: [email-masked]; [email-masked]; DRAGE, Keith (Keith)
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

It would be nice if video just works for the end user instead of them having to install a different browser or buying a different device with a different browser.

I personally think there needs to be a MTI video codec even if it is an old codec such as H.261. Although the codec should not require a lot of bandwidth to look decent which excludes something such as MJPEG.

On 25 October 2013 10:50, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
Agree

Keith

> From: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Oct 2013 11:25:34 +0000

>While VP8 might give you what you want in webrtc islands, it would not be able to communicate outside those islands, where the predominant codec is still H.248.

If we choose the H.248 codec, we also need to choose an MTI encoding: text or binary ;)

Regards,

Christer

Keith

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Fri, 25 Oct 2013 11:25:35 +0000

First, my area of focus is system deployment for existing organizations, and my employer is clearly leaning H.264, however as an individual:

I am of the opinion that from a "browser user perspective" this is pretty easy because two of the issues I see seem not to have a significant winner based on all this list activity:
	The average browser user does not care, except that bandwidth is materially affected - and there seems both are close in performance.
		(Profiles and efficiency could be argued forever at this rate)
	IPR does seem to be in the air - and without being a lawyer, I see Nokia folks on this list declaring there is an issue here.
		(But lawyers can argue forever)

There seems to be a split.... however I believe the third factor here, while less technical in nature, will affect deployment and adoption.

I believe the ability to leverage existing applications/infrastructure with a relatively small amount of work is a third leg in this stool and tips the balance materially for those looking to light up applications.

Simply put, a user would ask why a new, less-interoperable standard is being introduced in absence of  functionality or bandwidth savings.

This has material cost savings and media flow implications for a large set of the people who are going to use this technology. Clearly this was an important factor based on the SDP slant of the content of the spec.
	
In my opinion we are not paying enough attention to an important line in the burman h.264 proposal: "In addition, using H.264 enables interoperability with many other services without video transcoding."

On Oct 25, 2013, at 5:05 AM, Leon Geyser <[email-masked]> wrote:

> On 25 October 2013 10:50, DRAGE, Keith (Keith) <[email-masked]> wrote:
> Agree
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 25 Oct 2013 11:28:02 +0000

Correction - meant H.264 in the message below.

Keith 

> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: 25 October 2013 12:13
> To: Leon Geyser; [email-masked]
> While VP8 might give you what you want in webrtc islands, it 
> would not be able to communicate outside those islands, where 
> the predominant codec is still H.248.
>  
> While a position of both codecs being MTI would be acceptable 
> to me, I don't see the VP8 proponents going there.
>  
> Keith
> 
> 
> 	It would be nice if video just works for the end user 
> instead of them having to install a different browser or 
> buying a different device with a different browser.
> 	
> 	
> 	I personally think there needs to be a MTI video codec 
> even if it is an old codec such as H.261. Although the codec 
> should not require a lot of bandwidth to look decent which 
> excludes something such as MJPEG.
> 	
> 
> 
> 		We can either explicitly make a "no MTI" 
> decision, or just let it become the default by the absence of 
> agreement.
> 		
> 		Keith
> 		
> 
> <mailto:[email-masked]> 
> 		> > Formalistically, the people who argue for 
> abandoning an
> 		> MTI, like the
> 		> > people who argue for adapting an antiquated 
> codec, have not
> 		> put in a
> 		> > draft by the chairs' deadline of October 6, 
> so have not
> 		> made a proposal.
> 		> >
> 		> > But I'm not the one who argued for this to 
> be put on the
> 		> agenda for 2 hours.
> 		> > The people who pushed for this to be on the 
> agenda for 2
> 		> hours need to
> 		> > come forward and say why they believe this 
> is a good use of
> 		> our time.

---

From: "cb.list6" <[email-masked]>
Date: Fri, 25 Oct 2013 09:35:59 -0700

On Thu, Oct 24, 2013 at 9:16 PM, Harald Alvestrand <[email-masked]> wrote:
>> designed for codec negotiating and negotiating away from failure is left for
>> implementation
>>

Yes. I should have done a better job of advocating no MTI in a timely manner.

I am happy to post an I-D when the tool comes back up, or i can email
it.  But, i respect the chairs need for a deadline and that i have
missed it.

I am happy to present the salient points in Vancouver if asked to.

That said, here they are in email:

1.  There are 2 camps H264 and VP8

2.  H264 and VP8 are both high quality and efficient video codecs,
there is no dispute

3.  H264 camp claims there is no IPR liability-free path.  Thus they
claim H264 has a more mature IPR model via MPEG than VP8.

4.  The IETF does not adjudicate on validity of any IPR claim, the
IETF only distributes information that is volunteered to the IETF.

5.  The 2 camps have irreconcilable legal and business assumptions,
thus the ideal of MTI cannot be achieved.

6.  Having both H264 and VP8 as MTI is not viable, because we know it
would cannot be true that both would be implemented.

7.  Voice-only WebRTC does have an MTI.  In the event that a common
video codec cannot be negotiated during video session setup, the
session SHOULD fall-back to voice-only session negotiation where there
is a MTI .

CB

> The people who pushed for this to be on the agenda for 2 hours need to come
> forward and say why they believe this is a good use of our time. I haven't
> yet heard a VP8 proponent saying so.
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 25 Oct 2013 12:50:18 -0700

On Fri, Oct 25, 2013 at 4:25 AM, Jeremy Laurenson (jlaurens) <
[email-masked]> wrote:

> First, my area of focus is system deployment for existing organizations,
> and my employer is clearly leaning H.264, however as an individual:
>
> I am of the opinion that from a "browser user perspective" this is pretty
> easy because two of the issues I see seem not to have a significant winner
> based on all this list activity:
> The average browser user does not care, except that bandwidth is
> materially affected - and there seems both are close in performance.
> IPR does seem to be in the air - and without being a lawyer, I see Nokia
> folks on this list declaring there is an issue here.

No, this is a fundamental issue. If H.264 is the MTI, to quote Harald, "we
give up and live with royalties forever". This will have a significant
impact on WebRTC innovation and adoption.

The fact that there are some who disagree with the IPR status of VP8 does
not invalidate this point.

>
> There seems to be a split.... however I believe the third factor here,
> while less technical in nature, will affect deployment and adoption.
>
> I believe the ability to leverage existing applications/infrastructure
> with a relatively small amount of work is a third leg in this stool and
> tips the balance materially for those looking to light up applications.
>
> Simply put, a user would ask why a new, less-interoperable standard is
> being introduced in absence of  functionality or bandwidth savings.
>
> This has material cost savings and media flow implications for a large set
> of the people who are going to use this technology. Clearly this was an
> important factor based on the SDP slant of the content of the spec.
>  In my opinion we are not paying enough attention to an important line in
> the burman h.264 proposal: "In addition, using H.264 enables
> interoperability with many other services without video transcoding."
>

Nobody is saying implementors can't support H.264. If interoperability with
such services is a high priority, implementors will ship H.264 regardless
of what we decide here.

> I personally think there needs to be a MTI video codec even if it is an
> old codec such as H.261. Although the codec should not require a lot of

---

From: cowwoc <[email-masked]>
Date: Fri, 25 Oct 2013 17:47:47 -0400

On 25/10/2013 3:50 PM, Justin Uberti wrote:
> No, this is a fundamental issue. If H.264 is the MTI, to quote Harald, 
> "we give up and live with royalties forever". This will have a 
> significant impact on WebRTC innovation and adoption.
>
> The fact that there are some who disagree with the IPR status of VP8 
> does not invalidate this point.

     What prevents us from retiring H264, VP8 or any other codec in the 
future? Surely we are allowed to retire codecs after 5-10 years? If not, 
listing any codec as MTI (including VP8) places us at a some level of risk.

> Nobody is saying implementors can't support H.264. If interoperability 
> with such services is a high priority, implementors will ship H.264 
> regardless of what we decide here.

     The same is true for VP8, so why mandate it as required? If VP8 is 
as good as everyone alleges (and I think it is) then surely vendors 
should be moving in this direction. But they are not. Forcing VP8 as MTI 
comes across as a political ploy to force their hand.

     From an end-user point of view, the only thing I really care about 
is getting WebRTC support from Microsoft and Apple. Because I view 
everything through that prism, my primary concern is how this decision 
affects them jumping on board.

Gili

---

From: Ted Hardie <[email-masked]>
Date: Fri, 25 Oct 2013 16:23:42 -0700

On Fri, Oct 25, 2013 at 2:47 PM, cowwoc <[email-masked]> wrote:

>
>     From an end-user point of view, the only thing I really care about is
> getting WebRTC support from Microsoft and Apple. Because I view everything
> through that prism, my primary concern is how this decision affects them
> jumping on board.
>

Do you mean "getting WebRTC support from Microsoft and Apple." or "adding
WebRTC support from Microsoft and  Apple to that available from Firefox and
Chrome?"

regards,

Ted Hardie

---

From: Justin Uberti <[email-masked]>
Date: Fri, 25 Oct 2013 16:32:02 -0700

On Fri, Oct 25, 2013 at 2:47 PM, cowwoc <[email-masked]> wrote:

>     The same is true for VP8, so why mandate it as required?
>

Because we want to guarantee video interoperability without forcing
everyone to pay licensing feeds.

> If VP8 is as good as everyone alleges (and I think it is) then surely
> vendors should be moving in this direction. But they are not. Forcing VP8
> as MTI comes across as a political ploy to force their hand.
>

Regarding VP8, pretty much every SoC vendor is now shipping HW VP8
acceleration, so I think there is clear movement in this direction.

> through that prism, my primary concern is how this decision affects them

I can't speak for Microsoft and Apple, but I don't think they are sitting
around waiting for us to make up our mind on this.

---

From: "cb.list6" <[email-masked]>
Date: Fri, 25 Oct 2013 16:37:41 -0700

>>> No, this is a fundamental issue. If H.264 is the MTI, to quote Harald,
"we give up and live with royalties forever". This will have a significant
impact on WebRTC innovation and adoption.

That's a fine goal. But there are camps in this wg that want license fees
paid.

So there will be no concensus.

Ack. Then the market may favor vp8.

Right.  So it sounds like you agree there is no need for mti since each
implementation will drive it's own strategy.

CB

---

From: Monty Montgomery <[email-masked]>
Date: Fri, 25 Oct 2013 20:12:02 -0400

> Because we want to guarantee video interoperability without forcing everyone
> to pay licensing feeds.

Remember, it's not about the money.  It's about the market control,
and it's about asking permission (or having to beg forgiveness).

Not saying you forgot; I'm addressing the gallery.

Cheers,
Monty

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Sat, 26 Oct 2013 00:57:47 +0000

On Oct 25, 2013, at 3:50 PM, Justin Uberti <[email-masked]> wrote:

> 
> 
> 
> On Fri, Oct 25, 2013 at 4:25 AM, Jeremy Laurenson (jlaurens) <[email-masked]> wrote:
> No, this is a fundamental issue. If H.264 is the MTI, to quote Harald, "we give up and live with royalties forever". This will have a significant impact on WebRTC innovation and adoption.

> 
> The fact that there are some who disagree with the IPR status of VP8 does not invalidate this point.

The fact that Nokia has informed the group they believe there are IPR issues and they will not license means that regardless of whether we are all proponents of "royalty free", VP8 is likely not "the answer". This would mean that VP8 has no bearing whatsoever on the point Harald made. Until someone here digs into the Nokia filings, I remain firmly unconvinced.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 26 Oct 2013 04:40:35 +0000

Hi, 

I just want to explain why chairs are not likely to allocate agenda time for this at IETF88. I have not discussed this my co-chairs so this is certainly not a chair decision but instead my guess of some items that would come up…

1) we clearly asked for any proposals that wanted agenda time to be in in the form of a draft by Oct 6. I think we would view this as another proposal. 

2) the WG has previous agreed they don't want interoperability failures. This would not get us there. (Yes, I do realize the WG might fail at that goal but the current plan is to try not to fail)

3) The agenda looks really full to me. ( The chairs will be thrilled if we turn out to be wrong on that and we can cover the stuff on the agenda and move on to other things )

But here's the really important thing - getting to consensus on an MTI would be better than no MTI. And we have never asked the question. Let me say that again - this WG has never had a consensus call on which codec should be the MTI one. We agreed to do that and if it fails to reach consensus, then, as the WG has discussed before, we can move on to discussing what to do next. 

I really don't want to start another long thread on why we are spending time on this topic at all but I did think your email deserved a response. 

Cullen

---

From: "Karl Stahl" <[email-masked]>
Date: Sat, 26 Oct 2013 17:04:10 +0200

Has a Video Codec Plug-in Slot been considered or discussed?
Wouldn't specifying such codec slots and making them mandatory for WebRTC
make (almost) everyone happy? 

For service providers having invested in H.264 gear (e.g. IMS/RCS) or PBX/UC
vendor's video-solutions, they could offer their users the royalty-bearing
codec as a plug-in (they are used to supplying these codecs in current
clients), when they wish to use the WebRTC browser as a soft client for
their services.

That is their need, and most of them certainly understand that a
royalty-bearing codec cannot be made mandatory in free web browsers (How
could it? IETF cannot ban free web browsers and will not pay the
royalties...). 

We (Ingate/Intertex SBCs) get requests for transcoding VP8<->H.264 in
network gateways. Others have already announced such. That would really be
ugly - a technically bad and resource consuming, quality degenerating
solution, that by definition also breaks the end-to-end privacy idea behind
WebRTC. Let's only have codecs in the endpoints - Make codec slots MTI! Few
really expect the H.264 can be MTI.

For the WebRTC browser itself, any mandating must be royalty free if it
should go into the web browser we know, mustn't it?

Having MTI codec slots will be great if we cannot reach consensus around VP8
(e.g. because of Nokia pouring some 67 patent numbers into an IPR
declaration, refusing to submit what their infringed innovation may be
https://datatracker.ietf.org/ipr/2035/). It is not hard to guess that Google
then will offer free VP8 plug-ins to any WebRTC browser when using their
search engine, especially Microsoft and Apple users'... Then we get the
video compatibility.

And the MPEG-group can be happy about a new efficient distribution channel
for their H.264 codecs, via service providers and PBX/UC vendors offering
such plug-ins to their users.

Maybe I should be sad, being deprived of the opportunity to build massive
H.264/VP8 transcoding gateways into the network...

/Karl

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För Cullen
Jennings (fluffy)
Skickat: den 26 oktober 2013 06:41
Till: cb.list6
Kopia: [email-masked]
Ämne: Re: [rtcweb] VP8 vs H.264 - the core issue

Hi, 

I just want to explain why chairs are not likely to allocate agenda time for
this at IETF88. I have not discussed this my co-chairs so this is certainly
not a chair decision but instead my guess of some items that would come up…

1) we clearly asked for any proposals that wanted agenda time to be in in
the form of a draft by Oct 6. I think we would view this as another
proposal. 

2) the WG has previous agreed they don't want interoperability failures.
This would not get us there. (Yes, I do realize the WG might fail at that
goal but the current plan is to try not to fail)

3) The agenda looks really full to me. ( The chairs will be thrilled if we
turn out to be wrong on that and we can cover the stuff on the agenda and
move on to other things )

But here's the really important thing - getting to consensus on an MTI would
be better than no MTI. And we have never asked the question. Let me say that
again - this WG has never had a consensus call on which codec should be the
MTI one. We agreed to do that and if it fails to reach consensus, then, as
the WG has discussed before, we can move on to discussing what to do next. 

I really don't want to start another long thread on why we are spending time
on this topic at all but I did think your email deserved a response. 

Cullen

---

From: tim panton <[email-masked]>
Date: Sat, 26 Oct 2013 16:11:22 +0100

> make (almost) everyone happy? 

A _very_ long time ago (in terms of the rtcweb efforts) I floated the idea of having codecs as javascript objects,
which would then be manageable and replaceable in javascript, and could be implemented with technologies like NaCL. However at that time it was viewed as overly complex and taken no further.

Tim.

---

From: Leon Geyser <[email-masked]>
Date: Sat, 26 Oct 2013 17:40:59 +0200

I don't think it is such a great idea, because it now places the plug-in
development away from the browser developers. The reason why I say that is
bad: Who says the plug-in maintainers will be willing to release a plugin
for each new browser that comes out on each platform? And how do we install
those plug-ins on mobile phones where we don't have access to the
application's isolated storage?
It probably could work somehow, but a lot of thinking would be required. It
will be easier just to mandate a MTI codec.

On 26 October 2013 17:11, tim panton <[email-masked]> wrote:

> which would then be manageable and replaceable in javascript, and could be
> implemented with technologies like NaCL. However at that time it was viewed
> as overly complex and taken no further.
>
> Tim.
>

---

From: cowwoc <[email-masked]>
Date: Sat, 26 Oct 2013 14:48:52 -0400

I think you are a lot more likely to see H264/VP8 proponents 
offering free plugins then you are getting everyone to accept the same 
codec as MTI.

     Then again, Google refused to carry H264 in Chrome (I doubt 
licensing fees had anything to do with it) so maybe I'm wrong.

Gili

On 26/10/2013 11:40 AM, Leon Geyser wrote:
> I don't think it is such a great idea, because it now places the 
> plug-in development away from the browser developers. The reason why I 
> say that is bad: Who says the plug-in maintainers will be willing to 
> release a plugin for each new browser that comes out on each platform? 
> And how do we install those plug-ins on mobile phones where we don't 
> have access to the application's isolated storage?
> It probably could work somehow, but a lot of thinking would be 
> required. It will be easier just to mandate a MTI codec.
>
>
> On 26 October 2013 17:11, tim panton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     On 26 Oct 2013, at 16:04, Karl Stahl <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     A _very_ long time ago (in terms of the rtcweb efforts) I floated
>     the idea of having codecs as javascript objects,
>     which would then be manageable and replaceable in javascript, and
>     could be implemented with technologies like NaCL. However at that
>     time it was viewed as overly complex and taken no further.
>
>     Tim.
>
>     [email-masked] <mailto:[email-masked]>

---

From: cowwoc <[email-masked]>
Date: Sat, 26 Oct 2013 15:19:41 -0400

On 25/10/2013 7:23 PM, Ted Hardie wrote:
> On Fri, Oct 25, 2013 at 2:47 PM, cowwoc <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>         From an end-user point of view, the only thing I really care
>     about is getting WebRTC support from Microsoft and Apple. Because
>     I view everything through that prism, my primary concern is how
>     this decision affects them jumping on board.
>
>
> Do you mean "getting WebRTC support from Microsoft and Apple." or 
> "adding WebRTC support from Microsoft and Apple to that available from 
> Firefox and Chrome?"
>
> regards,
>
> Ted Hardie

Hi Ted,

     I'm not sure whether I understood your question correctly. Is this 
what you meant?

 1. Getting Microsoft and Apple to implement and bundle WebRTC as part
    of IE and Safari, versus
 2. Having outsiders (e.g. Firefox or Chrome) offer free plugins for IE
    and Safari without Microsoft and Apple's support

     If that's what you meant, then I'm asking for #1. As we've seen 
before (e.g. Chrome refusing to carry H264) just because a plugin is 
available does not mean that a vendor will agree to bundle it as part of 
the browser. As Monty pointed out, this has more to do with market 
control than licensing fees.

     I think we will all suffer unless Microsoft and Apple genuinely 
want to jump on board the WebRTC train. I disagree with the assessment 
that they are sitting around waiting for us to make up our mind. 
Microsoft put out some feelers in the form of CU-RTC-Web and, regardless 
of the merits of that proposal, was clobbered from all directions. A 
more appropriate response would have been to sit down with their 
representatives and say "Listen. We value your feedback. We won't be 
able to integrate all of it in version 1.0 but here is a compromise that 
integrates part of what you said... Can we use this as a basis for an 
ongoing relationship?" Instead, the representative from Microsoft is 
sounding very defensive and I can't say I blame them.

     An open process has to feel genuine, not just in words, but also in 
actions.

Gili

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 27 Oct 2013 00:19:16 +0200

On 10/26/2013 09:19 PM, cowwoc wrote:
>> "adding WebRTC support from Microsoft and  Apple to that available
>> from Firefox and Chrome?"
>>
>> regards,
>>
>> Ted Hardie
>
> Hi Ted,
>
>  2. Having outsiders (e.g. Firefox or Chrome) offer free plugins for
>     IE and Safari without Microsoft and Apple's support
>
> available does not mean that a vendor will agree to bundle it as part
> of the browser. As Monty pointed out, this has more to do with market
> Microsoft put out some feelers in the form of CU-RTC-Web and,
> regardless of the merits of that proposal, was clobbered from all
> directions. A more appropriate response would have been to sit down
> with their representatives and say "Listen. We value your feedback. We
> won't be able to integrate all of it in version 1.0 but here is a
> compromise that integrates part of what you said... Can we use this as
> a basis for an ongoing relationship?" Instead, the representative from
> Microsoft is sounding very defensive and I can't say I blame them.
>

I actually think Martin Thomson and Travis Leithead have been giving
great input and been positive contributors. Not to belittle the
contributions of others, but those two especially have made many
positive contributions.

>     An open process has to feel genuine, not just in words, but also
> in actions.
>
>

I think we may have some differing perspectives.

---

From: cowwoc <[email-masked]>
Date: Sat, 26 Oct 2013 18:47:34 -0400

> I think we may have some differing perspectives.

I guess what I'm saying is... if all is well, then what's going on with 
Microsoft and Apple? What's their official position regarding MTI? Will 
it impact their intent to bundle WebRTC in their browsers? If we truly 
have an open process and representatives from Microsoft and Apple 
sitting on the WG then I would expect to get official answers to these 
questions.

I've seen multiple representatives from Microsoft, but not a single 
person from Apple. Is anyone representing them in an official capacity?

Gili

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 27 Oct 2013 18:26:44 +0000

On Oct 26, 2013, at 4:47 PM, cowwoc <[email-masked]> wrote:

>> I actually think Martin Thomson and Travis Leithead have been giving great input and been positive contributors. Not to belittle the contributions of others, but those two especially have made many positive contributions.
>> 
>>> 
>>>     An open process has to feel genuine, not just in words, but also in actions.
>>> 
>> 
> I guess what I'm saying is... if all is well, then what's going on with Microsoft and Apple? What's their official position regarding MTI? Will it impact their intent to bundle WebRTC in their browsers? If we truly have an open process and representatives from Microsoft and Apple sitting on the WG then I would expect to get official answers to these questions.
> 
> I've seen multiple representatives from Microsoft, but not a single person from Apple. Is anyone representing them in an official capacity?

Apple people have been involved (in fact are co-authors of some of the drafts on the VP8 vs H264 topic) and Microsoft clearly been very involved with the WG as well.  Kaufman has been clear his employer has a policy of not pre announcing products and I believe the same is true of Apple. This is often true of standards work in any WG so it limits how much people can exactly say about their employers until product is announced - that's pretty normal at IETF.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Oct 2013 14:09:28 -0700

On 26 October 2013 15:47, cowwoc <[email-masked]> wrote:
> what's going on with Microsoft and Apple?

I can't speak for Apple, or Microsoft.  However I am able to share
some information.

> What's their official position
> regarding MTI?

For Microsoft at least, their position on MTI remains that specifying
MTI is not preferable.  You can find plenty of elaboration on this
subject if you search around a little.  However, it is also
Microsoft's view that it is extremely important to respect the
consensus process.

> Will it impact their intent to bundle WebRTC in their
> browsers?

That would be pure speculation.  Microsoft has a policy of not
revealing any information about unreleased and unannounced products,
and it seems like Apple act similarly.  I think it unlikely that you
are going to get any information on this subject.  Asking repeatedly
is likely to annoy more than it is to get more answers.  I suggest
that you concentrate on the issues, and try to keep speculation to
yourself.

---

From: cowwoc <[email-masked]>
Date: Sun, 27 Oct 2013 23:21:23 -0400

> that you concentrate on the issues, and try to keep speculation to
Hi Martin,

     I understand. I'm happy to hear your official stance on MTI and 
Microsoft's commitment to the consensus process.

Thanks,
Gili

---

From: cowwoc <[email-masked]>
Date: Sun, 27 Oct 2013 23:21:24 -0400

On 27/10/2013 2:26 PM, Cullen Jennings (fluffy) wrote:
> Apple people have been involved (in fact are co-authors of some of the 
> drafts on the VP8 vs H264 topic) and Microsoft clearly been very 
> involved with the WG as well. Kaufman has been clear his employer has 
> a policy of not pre announcing products and I believe the same is true 
> of Apple. This is often true of standards work in any WG so it limits 
> how much people can exactly say about their employers until product is 
> announced - that's pretty normal at IETF. 

     Out of curiosity, who is representing Apple? I don't remember 
seeing the company name appearing on any of the documentation.

Gili

---

From: Victor Pascual Avila <[email-masked]>
Date: Mon, 28 Oct 2013 08:38:08 +0100

On Mon, Oct 28, 2013 at 4:21 AM, cowwoc <[email-masked]> wrote:
>> drafts on the VP8 vs H264 topic) and Microsoft clearly been very involved
>> with the WG as well. Kaufman has been clear his employer has a policy of not
>> pre announcing products and I believe the same is true of Apple. This is
>> often true of standards work in any WG so it limits how much people can
>> exactly say about their employers until product is announced - that's pretty
>> normal at IETF.
>
>
>     Out of curiosity, who is representing Apple? I don't remember seeing the
> company name appearing on any of the documentation.

http://tools.ietf.org/html/draft-burman-rtcweb-h264-proposal-03

-Victor

---

From: cowwoc <[email-masked]>
Date: Mon, 28 Oct 2013 04:55:55 -0400

> http://tools.ietf.org/html/draft-burman-rtcweb-h264-proposal-03

     Very interesting. Thank you for the head's up.

     I read your blog post (discussed off-list) and it had the opposite 
effect then what you'd expect. It made me reflect back on the days where 
I had to deal with the headache of H264 transcoding (cost and 
complexity) and it made me realize something:

     I would accept MTI any day of the week if it were necessary to 
avoid transcoding.
     I would accept VP8 (instead of H264) as MTI any day of the week to 
avoid licensing fees.

     I've been playing devil's advocate over the past couple of weeks 
because I wanted to hear everyone's arguments (indeed, it resulted in a 
lively debate) but as a webapp developer I err solidly on Google's side 
(in spite of the fact that their intentions are not pure). I fully 
appreciate why most vendors are falling behind H264, but as a webapp 
developer I have different interests (avoiding complex/expensive 
transcoding and licensing fees if possible). Further, I would argue that 
requiring transcoding would have a crippling effect on WebRTC (in many 
ways, it would be no better than the status-quo).

     When comparing H264 to VP8, the discussion has convinced me that 
VP8 is technically "good enough" and that neither H264 nor VP8 is 
completely safe from a legal point of view.

     For those reasons, I would vote for:

 1. No MTI if we can reasonably avoid transcoding for up-to-date clients
    (browsers, mobile devices). I don't mind vendors needing to
    transcode to support legacy devices (telephony).
 2. VP8 as MTI, otherwise.

Gili

---

From: David Singer <[email-masked]>
Date: Mon, 28 Oct 2013 10:19:49 +0100

> Apple people have been involved (in fact are co-authors of some of the drafts on the VP8 vs H264 topic) and Microsoft clearly been very involved with the WG as well.  Kaufman has been clear his emp…

We would be delighted for the community to establish a royalty free codec, in particular for web applications. To that goal, among other efforts, and together with several other companies, we proposed to MPEG last year H.264 Constrained Baseline as a basis for a new royalty free standard. This project, named by MPEG Web Video Coding, is now at a DIS (Draft International Standard) stage, and we are collecting IPR disclosures.
We are also co-authors on the H.264 proposal for MTI to WebRTC.

As others have noted, we are, alas, formally constrained not to discuss what we might or might not do in future (sorry).

David Singer

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 29 Oct 2013 16:36:54 +0900

Hello David,

> We are also co-authors on the H.264 proposal for MTI to WebRTC.

This seems to be somewhat similar to the work by Google a few IETFs ago. 
Is there any timeline for this to become an ISO standard? And what's 
more important, any kind of time expectation or other information about 
when and under what conditions this might become royalty free?

Also, once both V8 and H.264 Constrained Baseline are available without 
the need to pay, what about declaring both of them MTI? That would 
definitely make things interoperable, and keep both sides equally happy. 
Just a crazy idea, I guess.

Regards,   Martin.

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 30 Oct 2013 09:52:50 -0700

> Do we switch now, or do we give up and live with royalties forever?

This is a little dramatic. One can trivially prove that every technology 
required to implement H.264 will lose the protection of the patent 
system in a finite period of time. Much, much sooner than "forever".

Matthew Kaufman

---

From: Monty Montgomery <[email-masked]>
Date: Wed, 30 Oct 2013 13:07:17 -0400

> required to implement H.264 will lose the protection of the patent system in
> a finite period of time. Much, much sooner than "forever".

Had the Web been patented, those patents would just now be starting to
expire.  I was a slender, handsome undergraduate back then.  Sure
feels like forever.

Monty

---

From: Jack Moffitt <[email-masked]>
Date: Wed, 30 Oct 2013 11:07:45 -0600

> a finite period of time. Much, much sooner than "forever".

Selection of royalty-required codecs sets a precedent.

jack.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 30 Oct 2013 18:30:16 +0100

>system in a finite period of time. Much, much sooner than "forever".

The patent systems that are enforced on this planet can trivially be
modified and term extensions are not exactly unheard of. And it seems
pretty clear to me that if we as a society switched from royality co-
decs to free ones then we would be pretty unlikely to switch back to
royality codecs in the forseeable future; if we stick with them we're
likely to pay royalities for whatever non-free codec becomes popular
next, and that process may well continue indefinitely. In this sense,
you would rather have to show that we would make "the switch" later.
-- 
Björn Höhrmann · mailto:[email-masked] · 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 Kaufman <[email-masked]>
Date: Wed, 30 Oct 2013 10:40:40 -0700

> Selection of royalty-required codecs sets a precedent.

Prove that VP8 isn't such a thing, and we'd have a clear decision to make.

Matthew Kaufman

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Wed, 30 Oct 2013 18:27:06 +0000

+1

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Wed, 30 Oct 2013 22:35:54 -0400

On 10/30/2013 01:40 PM, Matthew Kaufman wrote:
>>> system in

1. Proving the absence of something is usually impossible when you would
have to exhaustively find all uses to rule out the possibility.

2. Proving the presence of something, on the other hand, would be an
exceptionally easy task.  Just find one.

Aside from Google, who's both purchased On2 and also entered into an
agreement with MPEG-LA to STOP their attempts at forming a patent pool
for VP8 (highly indicating there was very little money that could be
sought from VP8, maybe even saving face for them somewhat), it has never
been demonstrated that anyone has paid any licensing fees for VP8 since
Google released it as free software and also issue their patent grant,
for those using it in the VP8 implementation (a condition of their
grant, I believe).

So, just provide us the one (non-contrived, like Ericsson paying Apple
or something like that) case where someone was forced to pay a licensing
fee for VP8 as above, and it would give your suspicion credence.  Absent
that, then it's just FUD (Fear, Uncertainty, and Doubt), and don't
contribute anything useful to the discussion.

-- 
Libre Video
http://librevideo.org