Subject: [rtcweb] MTI video codec, charter, RFC 3929

From: Stephan Wenger <[email-masked]>
Date: Fri, 8 Nov 2013 02:57:50 +0000

Hi all,

At the mike, I suggested that it is time to reconsider the currently standing WG's consensus to select at least one mandatory to implement video codec.  The chairs asked that such positions be stated on the list.  Here is my position, as usual as an individual (do I need to mention this?).

(1) Specifying one or more MTI video codecs is IMO desirable ONLY if the vast majority of the implementations, including both browser-based implementations and non-browser implementations would follow that requirement, and if the chosen MTI codec is technically suitable.  Both candidates under discussion are probably technically suitable, while old and reasonably patent-save stuff like H.261 probably is not.  However, today's statements and humms show, at least to me, rather convincingly that a decision for either of the two candidate codecs will be ignored by a significant part of the implementer community.  An SDO shouldn't mandate something of which it is clear that it is going to be widely ignored, for the same reason that no good manager issues orders that he knows will be ignored by the subordinate.

(2) Under the assumption that (1) is supported by rtcweb consensus, I think we need to take off the table the following options:

(2) a) Mandating one of the two candidate codecs, by RFC 3929.  Doing so will be painful, and will not lead to interoperability among most or all rtcweb devices/browsers, and is therefore a failure.  It will also damage the webrtc standard suite as a whole: who knows what else will be ignored when such a central part is being ignored...

(2) b) Mandating both candidate codecs.  Even more folks than under 2)a) would ignore the standard as written, because one would have to absorb cost and risk for both codecs, and not only for one.  Which is not good of the reasons stated above.  Oh, I would not rule out that there are a few bold guys who would faithfully implement both-Mozilla has announced that much-and those would be the interop stars.  Still, many more IMO would not, so I cannot help calling this a failure as well.

(3) Instead, the following options should be on the table:

(3) a) Mandating "at least one of VP8 / H.264" will slightly improve interoperability over saying nothing, and the standard will not be ignored by many.

(3) b) Mandating no video codec may well be the worst option for interoperability, but has the advantage of being future-proof.  How many folks implementing H.323 are unhappy with the requirement to implement H.261 QCIF and G.711???

(4) Structure of a decision making process

I would structure the decision making process as follows:

in a first step, see whether we can agree by consensus to overturn the previous consensus that we are to define at least one MTI video codec.  (For the procedure buffs: I looked at the charter and do not believe that it would need to be changed.  Nothing therein requires us to define an MTI video codec.  In fact, work item 6 could be interpreted as already achieved (through the audio codec selection), and even if we were not using such an interpretation, item 6 leaves us the option of "must or should".  That's a lot of wiggle room.  Wise choice at charter time.

If such a consensus could be reached, then I would seek consensus between options 3)a) and 3)b) above.

If such  consensus cannot be reached, it may indeed be time to invoke the RFC 3929 processes.

Contrary to what I said at the mike, after re-reading 3929, I do not care any more whether the question of invoking 3929 and the question of revoking previous WG consensus are decoupled and sequentially decided.  If the chairs want to deal with both issues in the same consensus call, that would be fine with me.  However, I would object if the previous WG consensus is not questioned at all.

Thanks for reading all the way down here.

Stephan

---

From: cowwoc <[email-masked]>
Date: Fri, 08 Nov 2013 01:02:10 -0500

On 07/11/2013 9:57 PM, Stephan Wenger wrote:
> (3) b) Mandating no video codec may well be the worst option for 
> interoperability, but has the advantage of being future-proof.  How 
> many folks implementing H.323 are unhappy with the requirement to 
> implement H.261 QCIF and G.711??? 
Hi Stephan,

Just a point of clarification: I hate dead wood as much as the next guy, 
so if you see me advocating H.261 as MTI please understand that I am 
also advocating removing it as MTI the second we have consensus on a 
credible replacement. I don't think anything in the spec should be 
written in stone. The list of MTI codecs *should* be updated every 5-10 
years.

Gili

---

From: Leon Geyser <[email-masked]>
Date: Fri, 8 Nov 2013 09:32:25 +0200

+1
H.261 will anyway only be used in a small percentage of cases. Most will
implement VP8 or/and H.264 in addition to the MTI.

On 8 November 2013 08:02, cowwoc <[email-masked]> wrote:

> interoperability, but has the advantage of being future-proof.  How many
> folks implementing H.323 are unhappy with the requirement to implement
> H.261 QCIF and G.711???
>
> Hi Stephan,
>
> so if you see me advocating H.261 as MTI please understand that I am also
> advocating removing it as MTI the second we have consensus on a credible
> replacement. I don't think anything in the spec should be written in stone.
> The list of MTI codecs *should* be updated every 5-10 years.
>
> Gili
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 08 Nov 2013 14:55:54 -0800

On 11/7/13 18:57, Stephan Wenger wrote:
> ...a decision for either of the two candidate codecs will be ignored 
> by a significant part of the implementer community.

I'm not sure that's true any longer. Indulge me in a bit of armchair 
game theory application.

Let's start by looking at ground zero: the browsers. Considering the 
public statements that have been made, I think it's fairly safe to 
assume that the following can be taken as given:

 1. Chrome will support at least VP8.
 2. Firefox will support both VP8 and H.264.
 3. Internet Explorer is almost certain to support H.264.
 4. Safari (including Mobile Safari) is almost certain to support H.264.

If the codecs are *only* those called out above, then you'll end up with 
an interesting situation in which IE, Safari, and Firefox can all 
mutually interoperate; Chrome and Firefox can interoperate with each 
other; and Chrome cannot interoperate with anything else.

I'm not going to put plans in Google's mouth, but envision yourself in 
the same set of circumstances: you own a fully-paid H.264 license, 
already ship an H.264 codec as part of your browser, and are getting a 
huge black eye for not interoperating with significant major browsers. 
What do you do?

Okay. Now, shift your imagined role: you're a non-browser implementor, 
and discover the facts on the ground to be those described above. You 
can deploy VP8 and work with two of the four major browsers, or you can 
deploy H.264 and work with all four. Yeah, you might not be in love with 
the structural issues involved in integrating the Cisco library [1]  -- 
and I'm certainly not -- but you're not actually precluded from using 
H.264. What do *you* do?

Which is a kind of long way to get to the fact that I think we're in a 
situation where H.264 is a de facto MTI codec anyway [2].

Now, imagine you're working in an SDO with this particular set of 
writing on the wall. You have a solid decision to choose one MTI video 
codec. You can choose one that's going to be functionally MTI regardless 
of what you say, or you can choose one that is quite probably going to 
be ignored by some non-trivial set of implementors.

So. What do *we* do?

/a

____
[1] There's been quite a bit of handwringing around the impact this has 
on iOS developers, as they cannot download modules at runtime. Bear in 
mind that these are curated applications, with a single, 
well-accounted-for distribution point. These are not libre software by a 
long shot, and they don't need to worry about the implications of third 
parties compiling their own versions. So, these implementors statically 
link in the OpenH264 library, and are exempted for the first 100,000 
instances they ship each year. Beyond that point, they're not "small 
fish" any more. Back when I was one of the owners of the company I 
worked at, "complications arising from selling more than 100,000 copies 
a year" is the kind of thing that I would place on a list titled 
"problems I wish I had."

[2] And to be clear, this is *not* the result I would have preferred. 
But I recognize that this isn't about my personal preferences. I find 
myself in the odd position of actually arguing for the position contrary 
to what I think is ideal, simply because I think it is the only 
practical path to success.

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 8 Nov 2013 15:20:08 -0800

You are responding to a little speculation with a lot of speculation, which
doesn't seem very valuable.  What should *I* do?  Respond with more
speculation, of course.

I will speculate that there is a group of developers that would ignore an
H.264 MTI:  FOSS projects.  They will ignore it because they can't
implement it.  To them, MT(IMPLEMENT) becomes MT(IGNORE_THE_SPEC).  I
speculate this includes FOSS browsers, include the Firefox source code and
(with no extra knowledge from my employer; it's just speculation) Chromium
and FOSS forks of both Firefox and Chromium.  I further speculate this will
include FOSS non-browser RTCWEB endpoints, such as FOSS RTC mobile apps.

So there's my speculation in response to your speculation in response to
Stephan's speculation, probably without value, but perhaps worth reminding
everyone that some people (FOSS projects) will have to ignore the spec if
H.264 is the MTI, because they have no choice (at least in countries where
software patents are enforced).  Of course, you may then speculate in
return that no one cares about FOSS projects and browsers, which I
speculate would be an ironic coming from someone representing a FOSS
project.

On Fri, Nov 8, 2013 at 2:55 PM, Adam Roach <[email-masked]> wrote:

> ...a decision for either of the two candidate codecs will be ignored by a
> significant part of the implementer community.
>
>
> I'm not sure that's true any longer. Indulge me in a bit of armchair game
> theory application.
>
> public statements that have been made, I think it's fairly safe to assume
> that the following can be taken as given:
>
>
> an interesting situation in which IE, Safari, and Firefox can all mutually
> interoperate; Chrome and Firefox can interoperate with each other; and
> Chrome cannot interoperate with anything else.
>
> I'm not going to put plans in Google's mouth, but envision yourself in the
> same set of circumstances: you own a fully-paid H.264 license, already ship
> an H.264 codec as part of your browser, and are getting a huge black eye
> for not interoperating with significant major browsers. What do you do?
>
> Okay. Now, shift your imagined role: you're a non-browser implementor, and
> discover the facts on the ground to be those described above. You can
> deploy VP8 and work with two of the four major browsers, or you can deploy
> H.264 and work with all four. Yeah, you might not be in love with the
> structural issues involved in integrating the Cisco library [1]  -- and I'm
> certainly not -- but you're not actually precluded from using H.264. What
> do *you* do?
>
> Now, imagine you're working in an SDO with this particular set of writing
> on the wall. You have a solid decision to choose one MTI video codec. You
> can choose one that's going to be functionally MTI regardless of what you
> say, or you can choose one that is quite probably going to be ignored by
> some non-trivial set of implementors.
>
> So. What do *we* do?
>
> /a
>
> ____
> [1] There's been quite a bit of handwringing around the impact this has on
> iOS developers, as they cannot download modules at runtime. Bear in mind
> that these are curated applications, with a single, well-accounted-for
> distribution point. These are not libre software by a long shot, and they
> don't need to worry about the implications of third parties compiling their
> own versions. So, these implementors statically link in the OpenH264
> library, and are exempted for the first 100,000 instances they ship each
> year. Beyond that point, they're not "small fish" any more. Back when I was
> one of the owners of the company I worked at, "complications arising from
> selling more than 100,000 copies a year" is the kind of thing that I would
> place on a list titled "problems I wish I had."
>
> [2] And to be clear, this is *not* the result I would have preferred. But
> I recognize that this isn't about my personal preferences. I find myself in
> the odd position of actually arguing for the position contrary to what I
> think is ideal, simply because I think it is the only practical path to
> success.
>

---

From: cowwoc <[email-masked]>
Date: Fri, 08 Nov 2013 18:42:44 -0500

Allow me to throw some more water on Adam's analysis :)

 1. Chrome = 46% of the market. IE + Safari = 23% of the market. Source:
    http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
     1. It doesn't matter how many browsers you own. What matters is
        market-share. In fact, the more browsers you have to support,
        the more difficult it is to deploy and test the app.
     2. Now... Why would I break my back for 23% of the market *and* pay
        royalties when I can get 46% of the market for very little
        effort (ease of deploying/testing) and pay no royalties?
 2. If what you say is true, it is in Google's best interest to get
    Firefox to drop H.264 and then drop H.264 itself in order to even
    the odds. Now, guess where the vast majority of Firefox's funding
    comes from?

     I don't think these kinds of politics should come into play, but 
clearly the situation is a lot more nuanced than previously mentioned.

Gili

On 08/11/2013 6:20 PM, Peter Thatcher wrote:
> You are responding to a little speculation with a lot of speculation, 
> which doesn't seem very valuable.  What should *I* do?  Respond with 
> more speculation, of course.
>
> I will speculate that there is a group of developers that would ignore 
> an H.264 MTI:  FOSS projects.  They will ignore it because they can't 
> speculate this includes FOSS browsers, include the Firefox source code 
> and (with no extra knowledge from my employer; it's just speculation) 
> Chromium and FOSS forks of both Firefox and Chromium.  I further 
> speculate this will include FOSS non-browser RTCWEB endpoints, such as 
> FOSS RTC mobile apps.
>
> So there's my speculation in response to your speculation in response 
> to Stephan's speculation, probably without value, but perhaps worth 
> reminding everyone that some people (FOSS projects) will have to 
> ignore the spec if H.264 is the MTI, because they have no choice (at 
> least in countries where software patents are enforced).  Of course, 
> you may then speculate in return that no one cares about FOSS projects 
> and browsers, which I speculate would be an ironic coming from someone 
> representing a FOSS project.
>
>
>
>
>
>
>
> On Fri, Nov 8, 2013 at 2:55 PM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     ...a decision for either of the two candidate codecs will be
>>     ignored by a significant part of the implementer community.
>
>     I'm not sure that's true any longer. Indulge me in a bit of
>     armchair game theory application.
>
>     Let's start by looking at ground zero: the browsers. Considering
>     the public statements that have been made, I think it's fairly
>     safe to assume that the following can be taken as given:
>
>     If the codecs are *only* those called out above, then you'll end
>     up with an interesting situation in which IE, Safari, and Firefox
>     can all mutually interoperate; Chrome and Firefox can interoperate
>     with each other; and Chrome cannot interoperate with anything else.
>
>     I'm not going to put plans in Google's mouth, but envision
>     yourself in the same set of circumstances: you own a fully-paid
>     H.264 license, already ship an H.264 codec as part of your
>     browser, and are getting a huge black eye for not interoperating
>     with significant major browsers. What do you do?
>
>     Okay. Now, shift your imagined role: you're a non-browser
>     implementor, and discover the facts on the ground to be those
>     described above. You can deploy VP8 and work with two of the four
>     major browsers, or you can deploy H.264 and work with all four.
>     Yeah, you might not be in love with the structural issues involved
>     in integrating the Cisco library [1]  -- and I'm certainly not --
>     but you're not actually precluded from using H.264. What do *you* do?
>
>     Which is a kind of long way to get to the fact that I think we're
>     in a situation where H.264 is a de facto MTI codec anyway [2].
>
>     writing on the wall. You have a solid decision to choose one MTI
>     video codec. You can choose one that's going to be functionally
>     MTI regardless of what you say, or you can choose one that is
>     quite probably going to be ignored by some non-trivial set of
>     implementors.
>
>     So. What do *we* do?
>
>     /a
>
>     ____
>     [1] There's been quite a bit of handwringing around the impact
>     this has on iOS developers, as they cannot download modules at
>     runtime. Bear in mind that these are curated applications, with a
>     single, well-accounted-for distribution point. These are not libre
>     software by a long shot, and they don't need to worry about the
>     implications of third parties compiling their own versions. So,
>     these implementors statically link in the OpenH264 library, and
>     are exempted for the first 100,000 instances they ship each year.
>     Beyond that point, they're not "small fish" any more. Back when I
>     was one of the owners of the company I worked at, "complications
>     arising from selling more than 100,000 copies a year" is the kind
>     of thing that I would place on a list titled "problems I wish I had."
>
>     [2] And to be clear, this is *not* the result I would have
>     preferred. But I recognize that this isn't about my personal
>     preferences. I find myself in the odd position of actually arguing
>     for the position contrary to what I think is ideal, simply because
>     I think it is the only practical path to success.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Fri, 08 Nov 2013 15:48:36 -0800

On 11/8/13 15:20, Peter Thatcher wrote:
> [S]ome people (FOSS projects) will have to ignore the spec if H.264 is 
> the MTI, because they have no choice... 

You appear to have somehow missed Cisco's announcement last week.

> Of course, you may then speculate in return that no one cares about 
> FOSS projects and browsers, which I speculate would be an ironic 
> coming from someone representing a FOSS project.

I think your assertion is trivially disproved by the fact that we, as a 
FOSS project, are going to support H.264 for WebRTC.

/a

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 8 Nov 2013 16:16:57 -0800

> You appear to have somehow missed Cisco's announcement last week.
Of course, you may then speculate in return that no one cares about FOSS
>> projects and browsers, which I speculate would be an ironic coming from
>> someone representing a FOSS project.
>>
>
I'll let other FOSS projects speak for themselves (and Debian and Fedora
already have, I believe), but I speculate many of them will disagree with
you.​
​
​

As a long-time FOSS developer myself (in small things; I claim no big
achievements), I personally don't see how the Cisco announcement changes
anything for a FOSS project, Firefox included.  Firefox still can't ship a
plugin-less browser with H.264, and neither can any FOSS project (at least
in nations where software patents are enforced).  But again, I'll let them
speak for themselves rather than claiming that one FOSS proves some
position for all of them.

And for that matter, this is all re-treading all the same arguments.  I
only keep commenting because it seems that FOSS projects (outside of
Firefox) seem poorly represented in this discussion, so I thought someone
should speak up for them a bit at times when they seem to be ignored.  I
hope this will be sufficient.

​​

​​

---

From: cowwoc <[email-masked]>
Date: Fri, 08 Nov 2013 19:24:27 -0500

On 08/11/2013 7:16 PM, Peter Thatcher wrote:
> And for that matter, this is all re-treading all the same arguments. 
>  I only keep commenting because it seems that FOSS projects (outside 
> of Firefox) seem poorly represented in this discussion, so I thought 
> someone should speak up for them a bit at times when they seem to be 
> ignored.  I hope this will be sufficient.

This is a good point and I think this is equally true for non-browser 
applications, most of which do not have a plugin architecture.

Gili

---

From: Justin Uberti <[email-masked]>
Date: Fri, 8 Nov 2013 16:48:01 -0800

> for not interoperating with significant major browsers. What do you do?

I'm scratching my head over how the introduction of a new WebRTC
implementation that intentionally doesn't work with Chrome would reflect
poorly on *Google*, especially with the "little guy versus big guy"
narrative that is developing around this issue.

---

From: Ron <[email-masked]>
Date: Sat, 9 Nov 2013 16:29:35 +1030

> 4. Safari (including Mobile Safari) is almost certain to support H.264.

Except the chairs already noted at the meeting that these browser
vendors had all indicated they would support whatever MTI decision
the working group made.

So game theory still says the optimal solution is the one that
doesn't automatically lock out other players though restrictive
licencing.

And the only non-browser, mobile-vendor, implementation that I'm
presently aware of, was, last I looked, still steadfastly pretending
that Opus didn't exist, for whatever that is worth to the game.

For myself personally, I'm likewise kind of torn, since I don't
think either option is perfectly ideal, but since an option that
can't freely be used by anyone is obviously unacceptable for a
standard that hopes to become ubiquitous, that really only leaves
assessing if the other choice does really have some similar issue
that it also would need to resolve before we could choose it.

If both options were equal in that respect, then to me a coin-flip
would be as good a way as any to end the impasse - but I can't see 
how H.264 can possibly dig itself out of the hole it was designed
into in this respect, so the remaining question is what, if anything
would make VP8 still unacceptable.

And that hasn't really been answered except with unsubstantiated
Fears, of unseen threats, that also apply equally or moreso to H.264.

Nobody has answered how Cisco intends to mitigate risk from the Nokia
portfolio that remains outside the MPEG LA pool, which they aren't
licencing for users of their blob.  Pretending that doesn't exist
doesn't make it go away, and nobody doubts it _does_ read on H.264.

And that's before we look at the amusing situation of them declaring
their H.264 IPR against VP8 here, but _not_ against H.264 ...

  Ron

---

From: Mohammed Raad <[email-masked]>
Date: Sat, 9 Nov 2013 19:02:35 +1100

Hi,

One point that does concern me, is that there seems to be a general
acceptance that VP8 does meet the requirements to be selected as MTI, yet
it is still not acceptable to many in your WG. Added to this the various
attempts to dress up H.264 into something that looks as workable as VP8.

I note here that there is now an attempt to present "market realities" in
such a way as to imply H.264 is a defacto MTI. Of course, the game theory
example given does not include any actual deployment numbers and so doesn't
lead to a sound conclusion.

Nonetheless, I do not think that an SDO should be simply guided by market
deployments, decisions should be based on how to best meet the requirements
of a particular project. I'm not saying market information should be
ignored, I am saying that whether or not a particular solution meets a
project's requirements should be the driver behind adoption.

In this case, two camps have developed around two technologies and both
camps have taken steps to make their preferred solution better aligned with
the project's requirements. In such a case it would be ideal if the
technical merit could be used as the deciding factor, but chasing a
decision on that basis is by definition impractical given that two groups
of technologists have already formed - meaning there is enough ambiguity in
the technical information to allow each group to justify its position.

In such situations, one looks for compromise.

In answering the question "what do we do":

I have suggested one possible way to compromise, a couple of people seemed
supportive, others were not.

BR,
Mohammed

---

From: cowwoc <[email-masked]>
Date: Sat, 09 Nov 2013 03:09:30 -0500

Someone should put together a spreadsheet listing everyone who gave 
their feedback, their preference and an explanation (regardless of 
whether we agree with it). At this point I've lost track of who said what.

Gili

On 09/11/2013 3:02 AM, Mohammed Raad wrote:
> acceptance that VP8 does meet the requirements to be selected as MTI, 
> yet it is still not acceptable to many in your WG. Added to this the 
> various attempts to dress up H.264 into something that looks as 
> workable as VP8.
>
> I note here that there is now an attempt to present "market realities" 
> in such a way as to imply H.264 is a defacto MTI. Of course, the game 
> theory example given does not include any actual deployment numbers 
> and so doesn't lead to a sound conclusion.
>
> Nonetheless, I do not think that an SDO should be simply guided by 
> market deployments, decisions should be based on how to best meet the 
> requirements of a particular project. I'm not saying market 
> information should be ignored, I am saying that whether or not a 
> particular solution meets a project's requirements should be the 
> driver behind adoption.
>
> In this case, two camps have developed around two technologies and 
> both camps have taken steps to make their preferred solution better 
> aligned with the project's requirements. In such a case it would be 
> ideal if the technical merit could be used as the deciding factor, but 
> chasing a decision on that basis is by definition impractical given 
> that two groups of technologists have already formed - meaning there 
> is enough ambiguity in the technical information to allow each group 
> to justify its position.
>
> I have suggested one possible way to compromise, a couple of people 
> seemed supportive, others were not.
>
> BR,
> Mohammed
>
> On Nov 9, 2013 9:56 AM, "Adam Roach" <[email-masked]

---

From: Adam Roach <[email-masked]>
Date: Sat, 09 Nov 2013 00:35:47 -0800

On 11/8/13 21:59, Ron wrote:
> [T]he chairs already noted at the meeting that these browser

I agree with you that one of the chairs indicated that he had personally 
received off-the-record, back-channel indications to this effect. The 
problem is that this assertion conflicts with off-the-record, 
back-channel indications that I have myself received.

Perhaps someone from each of Google, Microsoft, and Apple could stand up 
and confirm the chair's claim. I'll note that Mozilla is already on the 
record in this regard.

/a

---

From: Lorenzo Miniero <[email-masked]>
Date: Sat, 9 Nov 2013 17:27:56 +0100

Il giorno Fri, 08 Nov 2013 14:55:54 -0800
Adam Roach <[email-masked]> ha scritto:

> If the codecs are *only* those called out above, then you'll end up
> with an interesting situation in which IE, Safari, and Firefox can
> all mutually interoperate; Chrome and Firefox can interoperate with
> each other; and Chrome cannot interoperate with anything else.
> 
> I'm not going to put plans in Google's mouth, but envision yourself
> in the same set of circumstances: you own a fully-paid H.264 license, 
> already ship an H.264 codec as part of your browser, and are getting
> a huge black eye for not interoperating with significant major
> browsers. What do you do?
> 
> major browsers, or you can deploy H.264 and work with all four. Yeah,
> you might not be in love with the structural issues involved in
> integrating the Cisco library [1]  -- and I'm certainly not -- but
> you're not actually precluded from using H.264. What do *you* do?
> 

I *would* use a different library, if I could. Which I can't, because
we're talking of a patented library and I'm all at disadvantage here. I
stated several times why the current Cisco plugin, while a nice and
generious offer (funny thing they changed the original "Christmas
release" slide, BTW ;-) ), is not an acceptable option for me. What some
see as an opportunity, I see as a leash, that could (or could not) be
use at any time to either slow me down or stop me entirely. I'd rather
have a free web, please.

> Which is a kind of long way to get to the fact that I think we're in
> a situation where H.264 is a de facto MTI codec anyway [2].
> 

A weird statement, considering I've yet to see an H.264 WebRTC
implementation at all.

> video codec. You can choose one that's going to be functionally MTI
> regardless of what you say, or you can choose one that is quite
> probably going to be ignored by some non-trivial set of implementors.
> 
> So. What do *we* do?
> 
> /a
> 

The above mentioned non-trivial set of implementors is currently
ignoring the whole spec anyway. Why should I care?

> ____
> [1] There's been quite a bit of handwringing around the impact this
> has on iOS developers, as they cannot download modules at runtime.
> Bear in mind that these are curated applications, with a single, 
> well-accounted-for distribution point. These are not libre software
> by a long shot, and they don't need to worry about the implications
> of third parties compiling their own versions. So, these implementors
> statically link in the OpenH264 library, and are exempted for the
> first 100,000 instances they ship each year. Beyond that point,
> they're not "small fish" any more. Back when I was one of the owners
> of the company I worked at, "complications arising from selling more
> than 100,000 copies a year" is the kind of thing that I would place
> on a list titled "problems I wish I had."
> 

I really can't accept the 100k thing. First of all, it's not at all
clear how they're computed in the first place. Are you consuming one
when you install an app? when you open an encoder/decoder instance? a
mix of the two? what about servers? am I breaking the law every time I
play a video I took with my phone using mplayer, or transcoding it
with streamer/ffmpeg, if I don't tell MPEG LA? as I told EKR on the
chat, I've tried looking several times for information about licensing
in that sense, and have always miserably failed. I may be incredibly
dumb, but apparently I'm in good company, as I've often read posts,
blogs and more by people who tried to do the same to no avail. This
excellent post on librevideo, for instance, is three years old now and
yet so up-to-date:

http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/

I do remember something I read on a post here thats truck me at the
time. I can't remember who wrote that, and so I may be corrected, but
it said something like "just tracking down all the licenses being
consumed, even when you're under the 100k, is almost a full-time job".
For a small (actually tiny) company like mine, devoting a full
resource just for that, especially when you could use it to much
more benefit (like working on actual WebRTC stuff), is inevitably out of
the question. And the fact that other companies can instead just ignore
that and pay the cap as if it were a rounding error to their coffee
budget doesn't make me more symphatethic to the cause.

> myself in the odd position of actually arguing for the position
> contrary to what I think is ideal, simply because I think it is the
> only practical path to success.

I understand your points, and appreciate the fact you'd rather take a
different way, even if you're doing a really good job at fostering the
other. :-)

Lorenzo

---

From: Lorenzo Miniero <[email-masked]>
Date: Sat, 9 Nov 2013 17:36:38 +0100

Il giorno Fri, 08 Nov 2013 15:48:36 -0800
Adam Roach <[email-masked]> ha scritto:

> > [S]ome people (FOSS projects) will have to ignore the spec if H.264
> > is the MTI, because they have no choice... 
> 

What announcement? :-)

Jokes apart, we both know that the allegedly BSD license of the will-be
library means nothing. The fact itself you cannot use a version you
compile yourself will make it unusable. As Peter already pointed out,
developers from Debian and Fedora (incidentally two of the most
widespread distributions, Fedora being my default OS for a long time)
have already clarified how they won't be able to take advantage of it.

> I think your assertion is trivially disproved by the fact that we, as
> a FOSS project, are going to support H.264 for WebRTC.
> 

Which won't happen on my Fedora, where the shipped Firefox version
won't have the plugin installed. Or with any other multimedia
application on my Fedora at all, for that matter, for the very same
reason. Lucky thing opus and libvpx are available out of the box,
instead.

Lorenzo

---

From: Peter Thatcher <[email-masked]>
Date: Sat, 9 Nov 2013 11:36:43 -0800

While I appreciate the effort to gather additional information, I am
beginning to notice a trend that some of the big players here are
forgetting about the smaller players.  In particular, there aren't just 4
browsers in the world, and acting like there are only 4 browsers in the
world does not look good from a "big players vs. small players"
perspective.  For example, can we really tell the world that our WG has
concluded "lots of smaller players can't ship codec X, but we're going to
mandate it anyway because the 4 big players are willing to ship it" (which
they haven't, but assuming they did)?

May I remind you that Firefox, the very browser you represent, until very
recently, was on the "small player" side of the fence in the codec debate
and only until very recently (apparently) switched sides?  Perhaps you
could still engender in yourself some lingering empathy for those other
small players that cannot necessarily comply with the mandate of certain
codecs that you are so willingly eager to press upon them.

You may abandon their cause, you may disregard their complaints, and you
may disparage their positions, but at least do not cease to acknowledge
their existence and forget that you were once one them.  There are more
browsers than 4!

On Sat, Nov 9, 2013 at 12:35 AM, Adam Roach <[email-masked]> wrote:

> problem is that this assertion conflicts with off-the-record, back-channel
> indications that I have myself received.
>

---

From: cowwoc <[email-masked]>
Date: Sat, 09 Nov 2013 15:08:31 -0500

... and many more non-browser native applications.

Gili

On 09/11/2013 2:36 PM, Peter Thatcher wrote:
> forgetting about the smaller players.  In particular, there aren't 
> just 4 browsers in the world, and acting like there are only 4 
> browsers in the world does not look good from a "big players vs. small 
> players" perspective.  For example, can we really tell the world that 
> our WG has concluded "lots of smaller players can't ship codec X, but 
> we're going to mandate it anyway because the 4 big players are willing 
> to ship it" (which they haven't, but assuming they did)?
>
> May I remind you that Firefox, the very browser you represent, until 
> very recently, was on the "small player" side of the fence in the 
> codec debate and only until very recently (apparently) switched sides? 
>  Perhaps you could still engender in yourself some lingering empathy 
> for those other small players that cannot necessarily comply with the 
> mandate of certain codecs that you are so willingly eager to press 
> upon them.
>
> You may abandon their cause, you may disregard their complaints, and 
> you may disparage their positions, but at least do not cease to 
> acknowledge their existence and forget that you were once one them. 
>  There are more browsers than 4!
>
>
>
>
> On Sat, Nov 9, 2013 at 12:35 AM, Adam Roach <[email-masked] 
>     I agree with you that one of the chairs indicated that he had
>     personally received off-the-record, back-channel indications to
>     this effect. The problem is that this assertion conflicts with
>     off-the-record, back-channel indications that I have myself received.
>
>     Perhaps someone from each of Google, Microsoft, and Apple could
>     stand up and confirm the chair's claim. I'll note that Mozilla is
>     already on the record in this regard.
>
>     /a

---

From: Ron <[email-masked]>
Date: Sun, 10 Nov 2013 17:07:10 +1030

> their existence and forget that you were once one them.  There are more

Just on this note, if we're strolling down memory lane ...

if there's to be pleas of "Won't somebody think of the industry giants!",
which seemed to be a core motif of the H.264 presentation, it might be
good to pause for a moment and remember the garage startup roots of the
aforesaid giants currently in the spotlight.

While it may be true that some of those giants kickstarted their enterprise
the hard way, with stolen or otherwise questionably acquired IP [1], I don't
think that's a rite of passage the IETF should encourage for the budding
future giants in this application space.

If the market is as big and important as people say it is, then we're quite
likely defining the incubator environment for one or more of them here [2].
Let's not kill our next generation of chickens before they hatch and grow
to take their place in the pecking order on their own merit [3].

If the giants don't think they can compete on a level playing field, then
there are tacit admissions there too, which surely aren't to the advantage
of potential users of this technology.

  Ron

[1] so sayeth wikipedia.

[2] which may of course be a compelling reason for some existing giants
    to be very keen to lock them out as much as possible.

[3] some of them might even contribute to the economy by paying taxes,
    until they grow big enough to hire enough accountants to fix that :)