Subject: [rtcweb] The MTI Codec Questions (what to ask and how to ask them)

From: Sean Turner <[email-masked]>
Date: Mon, 3 Nov 2014 18:32:37 -0500

All,

One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be  MTI.  The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91.  To make the best use of the WG’s face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs).  We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked.

Without further ado, these are the proposed questions:

Question #0 (hum)

Do you want to discuss this issue at this meeting?

Question #1 (stand up)

Please stand (or signal in the jabber chat) if you will be part of that consensus process for this question. If you're here to read email or watch the show, we want to know that your sitting throughout this isn't expressing opinions for the consensus process.

    To many this might seem like a silly question,
    but the chairs believe the problem is well enough
    understood by those actively involved WG
    participants so we would like to confirm this
    understanding.  The chairs will also use to the
    determine the informed pool of WG participants.  

Question #2 (hum)

Do you believe we need an MTI codec to avoid negotiation failures?

    Previous attempts at determining the MTI did not
    yield a result but did confirm that there is a desire
    for an MTI to avoid negotiation failures.   Recently,
    some on the mailing list have expressed an interest
    in postponing this discussion until after IETF 91.  The
    purpose of this question is to reconfirm the original
    consensus.

Question #3 (open mic)

Are there any codecs that were not included in the previous consensus calls that warrant consideration?  If yes, which one and why.

    The assumption is that the viable codecs are a) VP8,
    b) H.264, or c) VP8 and H.264.  This is based on the
    extensive poll results from the last consensus calls.
    But time has passed so we need to entertain the ever
    so slight possibility that another codec has miraculously
    appeared.  Remember, we want to ensure we’re going
    to get maximum interoperability.

Question #4 (open mic)

Are there any new or unaddressed technical issues that will not allow us to narrow the field to VP8 and H.264?

    We do not want to revisit previous discussions; we only
    want new or unaddressed technical issues and will throttle
    the discussion accordingly.  We’ll rely on WG participants
    and our former RAI AD (Mr. Sparks) for help in this area.

    We believe the technical discussion will fall into two
    buckets:
      - New or unresolved technical points.
      - Licensing.  WRT licensing, the IETF tries not discuss
        whether IPR is valid, but an IPR issue that can be used
        as input to the decision making process is if enough
        people say they can’t/won’t implement because of the IPR.

Question #5 (hum)

With respect to the MTI codec:
    - Who can live with a requirement that WebRTC User Agents
      MUST support  both VP8 and H.264 and WebRTC devices
      MUST support  either VP8 or H.264?
    - Who can live with a requirement that all endpoints MUST support VP8?
    - Who can live with a requirement that all endpoints MUST support H.264?

Thanks for your time,
t/c/s

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Nov 2014 16:08:26 -0800

The questions below do not make it clear whether we are revisiting the MTI video codec issue or whether in addition the audio codec issue (on which we reached consensus) is also being reconsidered. Please clarify.

> On Nov 3, 2014, at 3:32 PM, Sean Turner <[email-masked]> wrote:
> 
> All,
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 4 Nov 2014 00:27:08 +0000

> The questions below do not make it clear whether we are revisiting the MTI video codec issue or whether in addition the audio codec issue (on which we reached consensus) is also being reconsidered.…

Bernard, I think I can safely say the chairs were only thinking about the video codec when this was written and that should have been clear on that. 

That said, there was consensus on 711 and opus being MTI but I think we would need to check carefully the status of if there was consensus that no other audio codecs would be be MTI. But this email was really meant to be about the video codecs.

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 03 Nov 2014 16:31:18 -0800

The below has been discussed to death on the list *and* nearly identical 
questions were presented at a previous meeting.

I'm going to ask what I asked when I first saw this on the agenda: What 
has substantively changed since then?

As far as I can tell, nothing.

Matthew Kaufman

ps. Doing this with hums at a meeting just encourages filling the room 
with people who aren't participating in the process but whose employers 
have asked them to stuff the room to increase the hum volume. Those 
people will all stand up for question #1, then leave immediately after 
the hums are completed. Just like last time.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 03 Nov 2014 17:02:17 -0800

Hm.

I don’t think there’s much value in revisiting the “one codec”
alternatives. We tried that, and know that we found no consensus.
Nobody’s changed their minds.

It would be very sad if we give up on interoperability for WebRTC
devices. Accepting “either” means that there will be 2 groups of them,
and they need a gateway to talk to each other, even when they can all
talk to all compatible browsers. Having an MTI would be better - but one
purpose of the “device” category is to allow fully compliant devices
that don’t need the kind of corporate backing a browser needs - which
means that licensed codecs are an issue. We’ve had that discussion before.

Of course, WebRTC-compatible devices (as currently defined) can do
whatever they want.

But still, it seems that there’s a chance that discussing this again is
worth it. We might find an agreement this time.

Harald

-- 
Surveillance is pervasive. Go Dark.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 3 Nov 2014 20:13:21 -0500

Matthew,

You wrote:
"I'm going to ask what I asked when I first saw this on the agenda: What
has substantively changed since then?

As far as I can tell, nothing.:

Actually several things have substantively changed since then. The list
includes but is not limited to:

* Cisco shipped its H264 open source and binary module
* Firefox is using the Cisco binary module and as such Firefox now supports
both H264 and VP8
* IOS8 has shipped with API support for H264 (you may recall that lack of a
solution for H264 on IOS was an objection many had regarding the Cisco h264
binary module solution; this is now addressed)
* there has been progress in the ongoing legal proceedings around VP8
* there are new IPR statements regarding VP8 in ongoing standards processes

I think this is far beyond "nothing". And given the importance of this
topic to progress on adoption of webRTC, it warrants discussion at the mic.

-Jonathan R.

On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand <[email-masked]>
wrote:

> alternatives. We tried that, and know that we found no consensus. Nobody’s
> changed their minds.
>
> It would be very sad if we give up on interoperability for WebRTC devices.
> Accepting “either” means that there will be 2 groups of them, and they need
> a gateway to talk to each other, even when they can all talk to all
> compatible browsers. Having an MTI would be better - but one purpose of the
> “device” category is to allow fully compliant devices that don’t need the
> kind of corporate backing a browser needs - which means that licensed
> codecs are an issue. We’ve had that discussion before.
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --

-- 
Jonathan Rosenberg, Ph.D.
[email-masked]
http://www.jdrosen.net

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 03 Nov 2014 19:15:24 -0800

A "substantive change" would be *any* of the parties who participate in 
these discussions having a different position than before.

Yes, Cisco, who already supported H.264 and had announced an intention 
to ship an open source and binary module, shipped H.264.

And Firefox, reluctant supporter of H.264 when available but preferring 
VP8 and some future even more free codec that isn't yet shipped, is 
reluctantly supporting H.264 when available.

And iOS 8 has H.264, but of course Apple already had access to that 
H.264 if they were to put WEBRTC into their browser...

Etc.

Where's the "Google has decided to pull their support for VP8 and fully 
back H.264 for real-time communications on the web" announcement? Or the 
"Microsoft open-sources Internet Explorer, adds native VP8 to Windows" 
announcement? Or the "MPEG-LA drops all fees for H.264 encoding and 
decoding" announcement? Or really *anything* that substantially changes 
things from where we were six months ago?

I don't get the desire to spend time on this topic... and I especially 
don't understand the call to pack as many people into a room as possible 
to conduct a hum, when the outcome will need to be discussed and 
confirmed on the list anyway.

Matthew Kaufman

On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote:
> Matthew,
>
> You wrote:
> "I'm going to ask what I asked when I first saw this on the agenda: 
> What has substantively changed since then?
>
> Actually several things have substantively changed since then. The 
> list includes but is not limited to:
>
> * Firefox is using the Cisco binary module and as such Firefox now 
> supports both H264 and VP8
> * IOS8 has shipped with API support for H264 (you may recall that lack 
> of a solution for H264 on IOS was an objection many had regarding the 
> Cisco h264 binary module solution; this is now addressed)
> On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hm.
>
>     I don't think there's much value in revisiting the "one codec"
>     Nobody's changed their minds.
>
>     devices. Accepting "either" means that there will be 2 groups of
>     them, and they need a gateway to talk to each other, even when
>     they can all talk to all compatible browsers. Having an MTI would
>     be better - but one purpose of the "device" category is to allow
>     fully compliant devices that don't need the kind of corporate
>     backing a browser needs - which means that licensed codecs are an
>     issue. We've had that discussion before.
>
>     But still, it seems that there's a chance that discussing this
>     again is worth it. We might find an agreement this time.
>
>     Harald
>
>
>
>
>>     One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be  MTI.  The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91.  To make the best use of the WG's face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs).  We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked.
>>
>>          appeared.  Remember, we want to ensure we're going
>>          the discussion accordingly.  We'll rely on WG participants
>>              people say they can't/won't implement because of the IPR.
>>
>>     Question #5 (hum)
>>
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> http://www.jdrosen.net
>
>

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Tue, 4 Nov 2014 13:44:12 +0800

Apple had 264, but there was no API to make 264 HW acceleration available
to developers. It was mentioned as one of the reason why cisco open264 felt
short of addressing some concerns voiced in the MTI pool. the iOS 8's 264
API changed this.

In any case, I support the chair decision to try to revisit the question.

On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman <[email-masked]> wrote:

> Yes, Cisco, who already supported H.264 and had announced an intention to
> ship an open source and binary module, shipped H.264.
>
> And iOS 8 has H.264, but of course Apple already had access to that H.264
> if they were to put WEBRTC into their browser...
>
> Etc.
>
> don't understand the call to pack as many people into a room as possible to
> conduct a hum, when the outcome will need to be discussed and confirmed on
> the list anyway.
>
> Matthew Kaufman
>
>
> * IOS8 has shipped with API support for H264 (you may recall that lack of
> a solution for H264 on IOS was an objection many had regarding the Cisco
> h264 binary module solution; this is now addressed)
>> devices. Accepting “either” means that there will be 2 groups of them, and
>> they need a gateway to talk to each other, even when they can all talk to
>> all compatible browsers. Having an MTI would be better - but one purpose of
>> the “device” category is to allow fully compliant devices that don’t need
>> the kind of corporate backing a browser needs - which means that licensed

-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -

---

From: Justin Uberti <[email-masked]>
Date: Mon, 3 Nov 2014 22:36:22 -0800

> have asked them to stuff the room to increase the hum volume. Those people
> will all stand up for question #1, then leave immediately after the hums
> are completed. Just like last time.

I am shocked -- shocked -- at these allegations of room stuffing in our
beloved IETF.  Surely the blue
<http://www.ietf.org/proceedings/88/bluesheets/bluesheets-88-rtcweb-01.pdf>
sheets
<http://www.ietf.org/proceedings/88/bluesheets/bluesheets-88-rtcweb-02.pdf>
from IETF 88 (the last time we discussed codecs, on day 2) will put to rest
these claims.

Wait...

CompanyDay2 RTCWEB AttendeesDay1 RTCWEB AttendeesDeltacisco251510mozilla1212
0ericsson1055huawei1082google990alu642oracle550
(stats shown for all company affiliations reported by 5 or more people)

---

From: Emil Ivov <[email-masked]>
Date: Tue, 4 Nov 2014 11:24:11 +0100

Looking at the list of IETF attendees for that session [0] we see that
total meeting participation for the delta companies was:

Cisco: 118
Ericsson: 36

So, clearly someone was very sloppy when organizing the rtcweb MTI voting
flood. A participation of 21% and 28% respectively is indeed quite
embarassing.

Reopening the question in Hawaii would allow raising the awareness among
the non-voters and having the proper numbers attend this time.

*That* could constitute one important change since last time and, if so, it
would totally justify having the debate again.

[0] https://www.ietf.org/registration/ietf88/attendance.py

--sent from my mobile
On 04 Nov 2014 7:36 AM, "Justin Uberti" <[email-masked]> wrote:

> CompanyDay2 RTCWEB AttendeesDay1 RTCWEB AttendeesDeltacisco251510mozilla12
> 120ericsson1055huawei1082google990alu642oracle550

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Tue, 04 Nov 2014 14:08:44 +0100

If there are groups of people willing to discuss the evolution of the
surrounding environment around video codecs, that's their time, can be
done anywhere at their wish.

Related to the substance of webrtc MTI, there is nothing new out there
relevant to the video codecs constraints. No change from MPEG-LA on
H.264 costs and restrictions for use freely by everyone (including the
open source space), as expected when having to implement an open
standard from IETF. No final decisions on patent claims to VP8.

Let's hope soon there will be news about:
- MPEG-LA makes H.264 completely free
- VP8 pattent claims get to a final decision in court, so either they
are dismissed there or they can be dealt differently
- a new completely free video codec shows up

I expect IETF is going to stand against monopolistic trends and
particular business interests, being the standardization body for open
protocols in an open internet. It is no excuse to release/propose IETF
standards that force someone either to pay to or be tracked by specific
group of interests.

Let's not forget that not so many years ago there were completely
different communication means -- under monopoly, with high costs and
very rigid -- without open standards with no barriers for anyone, the
level of innovation we benefited in the past years wouldn't have happened.

Daniel

On 04/11/14 06:44, Alexandre GOUAILLARD wrote:
> Apple had 264, but there was no API to make 264 HW acceleration
> available to developers. It was mentioned as one of the reason why
> cisco open264 felt short of addressing some concerns voiced in the MTI
> pool. the iOS 8's 264 API changed this.
>
> On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     A "substantive change" would be *any* of the parties who
>     participate in these discussions having a different position than
>     before.
>
>     Yes, Cisco, who already supported H.264 and had announced an
>     intention to ship an open source and binary module, shipped H.264.
>
>     And Firefox, reluctant supporter of H.264 when available but
>     preferring VP8 and some future even more free codec that isn't yet
>     shipped, is reluctantly supporting H.264 when available.
>
>     And iOS 8 has H.264, but of course Apple already had access to
>     that H.264 if they were to put WEBRTC into their browser...
>
>     Etc.
>
>     Where's the "Google has decided to pull their support for VP8 and
>     fully back H.264 for real-time communications on the web"
>     announcement? Or the "Microsoft open-sources Internet Explorer,
>     adds native VP8 to Windows" announcement? Or the "MPEG-LA drops
>     all fees for H.264 encoding and decoding" announcement? Or really
>     *anything* that substantially changes things from where we were
>     six months ago?
>
>     I don't get the desire to spend time on this topic... and I
>     especially don't understand the call to pack as many people into a
>     room as possible to conduct a hum, when the outcome will need to
>     be discussed and confirmed on the list anyway.
>
>     Matthew Kaufman
>
>
>>     "I'm going to ask what I asked when I first saw this on the
>>     agenda: What has substantively changed since then?
>>
>>     Actually several things have substantively changed since then.
>>     The list includes but is not limited to:
>>
>>     * Firefox is using the Cisco binary module and as such Firefox
>>     now supports both H264 and VP8
>>     * IOS8 has shipped with API support for H264 (you may recall that
>>     lack of a solution for H264 on IOS was an objection many had
>>     regarding the Cisco h264 binary module solution; this is now
>>     addressed)
>>     I think this is far beyond "nothing". And given the importance of
>>     this topic to progress on adoption of webRTC, it warrants
>>     discussion at the mic.
>>
>>     -Jonathan R.
>>
>>
>>         I don’t think there’s much value in revisiting the “one
>>         codec” alternatives. We tried that, and know that we found no
>>         consensus. Nobody’s changed their minds.
>>
>>         It would be very sad if we give up on interoperability for
>>         WebRTC devices. Accepting “either” means that there will be 2
>>         groups of them, and they need a gateway to talk to each
>>         other, even when they can all talk to all compatible
>>         browsers. Having an MTI would be better - but one purpose of
>>         the “device” category is to allow fully compliant devices
>>         that don’t need the kind of corporate backing a browser needs
>>         - which means that licensed codecs are an issue. We’ve had
>>         that discussion before.
>>
>>         Of course, WebRTC-compatible devices (as currently defined)
>>         can do whatever they want.
>>
>>         But still, it seems that there’s a chance that discussing
>>         this again is worth it. We might find an agreement this time.
>>
>>         Harald
>>
>>
>>
>>
> sg.linkedin.com/agouaillard <http://sg.linkedin.com/agouaillard>
>
>  *
>
>
>
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 4 Nov 2014 14:03:34 +0000

Your statements about what the IETF should expect are somewhat different from the statements in RFC 3979. I quote:

   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.

You are perfectly entitled to have your own personal view of what you desire, but please do not equate your desires with IETF policy in this area.

I'd also note you are making your own assumptions about the IPR encumbrance of various solutions, and those assumptions may not match those of other participants. IETF itself does not evaluate IPR encumbrance.

regards

Keith Drage

________________________________
From: rtcweb [mailto:[email-masked]] On Behalf Of Daniel-Constantin Mierla
Sent: 04 November 2014 13:09
To: Alexandre GOUAILLARD; Matthew Kaufman
Cc: [email-masked]
Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them)

If there are groups of people willing to discuss the evolution of the surrounding environment around video codecs, that's their time, can be done anywhere at their wish.

Related to the substance of webrtc MTI, there is nothing new out there relevant to the video codecs constraints. No change from MPEG-LA on H.264 costs and restrictions for use freely by everyone (including the open source space), as expected when having to implement an open standard from IETF. No final decisions on patent claims to VP8.

Let's hope soon there will be news about:
- MPEG-LA makes H.264 completely free
- VP8 pattent claims get to a final decision in court, so either they are dismissed there or they can be dealt differently
- a new completely free video codec shows up

I expect IETF is going to stand against monopolistic trends and particular business interests, being the standardization body for open protocols in an open internet. It is no excuse to release/propose IETF standards that force someone either to pay to or be tracked by specific group of interests.

Let's not forget that not so many years ago there were completely different communication means -- under monopoly, with high costs and very rigid -- without open standards with no barriers for anyone, the level of innovation we benefited in the past years wouldn't have happened.

Daniel

On 04/11/14 06:44, Alexandre GOUAILLARD wrote:
Apple had 264, but there was no API to make 264 HW acceleration available to developers. It was mentioned as one of the reason why cisco open264 felt short of addressing some concerns voiced in the MTI pool. the iOS 8's 264 API changed this.

On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman <[email-masked]<mailto:[email-masked]>> wrote:
A "substantive change" would be *any* of the parties who participate in these discussions having a different position than before.

Yes, Cisco, who already supported H.264 and had announced an intention to ship an open source and binary module, shipped H.264.

And Firefox, reluctant supporter of H.264 when available but preferring VP8 and some future even more free codec that isn't yet shipped, is reluctantly supporting H.264 when available.

And iOS 8 has H.264, but of course Apple already had access to that H.264 if they were to put WEBRTC into their browser...

Etc.

Where's the "Google has decided to pull their support for VP8 and fully back H.264 for real-time communications on the web" announcement? Or the "Microsoft open-sources Internet Explorer, adds native VP8 to Windows" announcement? Or the "MPEG-LA drops all fees for H.264 encoding and decoding" announcement? Or really *anything* that substantially changes things from where we were six months ago?

I don't get the desire to spend time on this topic... and I especially don't understand the call to pack as many people into a room as possible to conduct a hum, when the outcome will need to be discussed and confirmed on the list anyway.

Matthew Kaufman

You wrote:
"I'm going to ask what I asked when I first saw this on the agenda: What has substantively changed since then?

Actually several things have substantively changed since then. The list includes but is not limited to:

* Cisco shipped its H264 open source and binary module
* Firefox is using the Cisco binary module and as such Firefox now supports both H264 and VP8
* IOS8 has shipped with API support for H264 (you may recall that lack of a solution for H264 on IOS was an objection many had regarding the Cisco h264 binary module solution; this is now addressed)
* there has been progress in the ongoing legal proceedings around VP8
* there are new IPR statements regarding VP8 in ongoing standards processes

I think this is far beyond "nothing". And given the importance of this topic to progress on adoption of webRTC, it warrants discussion at the mic.

-Jonathan R.

On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
Hm.

I don't think there's much value in revisiting the "one codec" alternatives. We tried that, and know that we found no consensus. Nobody's changed their minds.

It would be very sad if we give up on interoperability for WebRTC devices. Accepting "either" means that there will be 2 groups of them, and they need a gateway to talk to each other, even when they can all talk to all compatible browsers. Having an MTI would be better - but one purpose of the "device" category is to allow fully compliant devices that don't need the kind of corporate backing a browser needs - which means that licensed codecs are an issue. We've had that discussion before.

Of course, WebRTC-compatible devices (as currently defined) can do whatever they want.

But still, it seems that there's a chance that discussing this again is worth it. We might find an agreement this time.

Harald

All,

Question #0 (hum)

Question #1 (stand up)

Question #2 (hum)

Question #3 (open mic)

Question #4 (open mic)

Question #5 (hum)

Thanks for your time,
t/c/s
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

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

--
Jonathan Rosenberg, Ph.D.
[email-masked]<mailto:[email-masked]>
http://www.jdrosen.net

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

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

sg.linkedin.com/agouaillard<http://sg.linkedin.com/agouaillard>

  *

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

---

From: Sean Turner <[email-masked]>
Date: Tue, 4 Nov 2014 09:45:28 -0500

> That said, there was consensus on 711 and opus being MTI but I think we would need to check carefully the status of if there was consensus that no other audio codecs would be be MTI. But this email…

Definitely just about the video codecs.

spt

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Tue, 04 Nov 2014 15:55:18 +0100

I don't find anything contrary to the RFC paragraph you refer to. No
technology (video codec in this case) is superior enough to the other
for taking that in consideration (there were results from tests over
tests and re-tests done by various entities), nothing changed, so this
is not an excuse/reason to be considered. I did use 'I' not 'IETF' for
my opinions, there is no 'equate' but 'expect'. Also, no IPR
assumptions, just stated that nothing relevant changed related to them,
given the conclusions from the past discussions.

I did read most of the RFCs out there and worked for the past almost 15
years with the specs from IETF, therefore to be clear, my 'expect' comes
from how IETF worked so far and I hope the future activity still tries
to follow the 'preferred' guidelines rather than the 'exceptions'.

Those being said, unless you can point case by case the specific parts
in my initial opinions, I don't really get what you targeted with your
answer.

Daniel

On 04/11/14 15:03, DRAGE, Keith (Keith) wrote:
> Your statements about what the IETF should expect are somewhat
> different from the statements in RFC 3979. I quote:
>  
>     ------------------------------------------------------------------------
>     *From:* rtcweb [mailto:[email-masked]] *On Behalf Of
>     *Daniel-Constantin Mierla
>     *Sent:* 04 November 2014 13:09
>     *To:* Alexandre GOUAILLARD; Matthew Kaufman
>     *Cc:* [email-masked]
>     *Subject:* Re: [rtcweb] The MTI Codec Questions (what to ask and
>     how to ask them)
>
>     If there are groups of people willing to discuss the evolution of
>     the surrounding environment around video codecs, that's their
>     time, can be done anywhere at their wish.
>
>     Related to the substance of webrtc MTI, there is nothing new out
>     there relevant to the video codecs constraints. No change from
>     MPEG-LA on H.264 costs and restrictions for use freely by everyone
>     (including the open source space), as expected when having to
>     implement an open standard from IETF. No final decisions on patent
>     claims to VP8.
>
>     - VP8 pattent claims get to a final decision in court, so either
>     they are dismissed there or they can be dealt differently
>     particular business interests, being the standardization body for
>     open protocols in an open internet. It is no excuse to
>     release/propose IETF standards that force someone either to pay to
>     or be tracked by specific group of interests.
>
>     different communication means -- under monopoly, with high costs
>     and very rigid -- without open standards with no barriers for
>     anyone, the level of innovation we benefited in the past years
>     wouldn't have happened.
>
>     Daniel
>
>
>>     available to developers. It was mentioned as one of the reason
>>     why cisco open264 felt short of addressing some concerns voiced
>>     in the MTI pool. the iOS 8's 264 API changed this.
>>
>>     On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         participate in these discussions having a different position
>>         than before.
>>
>>         preferring VP8 and some future even more free codec that
>>         isn't yet shipped, is reluctantly supporting H.264 when
>>         available.
>>
>>         And iOS 8 has H.264, but of course Apple already had access
>>         to that H.264 if they were to put WEBRTC into their browser...
>>
>>         Etc.
>>
>>         Where's the "Google has decided to pull their support for VP8
>>         and fully back H.264 for real-time communications on the web"
>>         announcement? Or the "Microsoft open-sources Internet
>>         Explorer, adds native VP8 to Windows" announcement? Or the
>>         "MPEG-LA drops all fees for H.264 encoding and decoding"
>>         announcement? Or really *anything* that substantially changes
>>         especially don't understand the call to pack as many people
>>         into a room as possible to conduct a hum, when the outcome
>>         will need to be discussed and confirmed on the list anyway.
>>
>>         Matthew Kaufman
>>
>>
>>>         Actually several things have substantively changed since
>>>         then. The list includes but is not limited to:
>>>
>>>         * IOS8 has shipped with API support for H264 (you may recall
>>>         that lack of a solution for H264 on IOS was an objection
>>>         many had regarding the Cisco h264 binary module solution;
>>>         this is now addressed)
>>>         I think this is far beyond "nothing". And given the
>>>         importance of this topic to progress on adoption of webRTC,
>>>         it warrants discussion at the mic.
>>>
>>>         -Jonathan R.
>>>
>>>
>>>             codec” alternatives. We tried that, and know that we
>>>             found no consensus. Nobody’s changed their minds.
>>>
>>>             It would be very sad if we give up on interoperability
>>>             for WebRTC devices. Accepting “either” means that there
>>>             will be 2 groups of them, and they need a gateway to
>>>             talk to each other, even when they can all talk to all
>>>             compatible browsers. Having an MTI would be better - but
>>>             one purpose of the “device” category is to allow fully
>>>             compliant devices that don’t need the kind of corporate
>>>             backing a browser needs - which means that licensed
>>>             But still, it seems that there’s a chance that
>>>             discussing this again is worth it. We might find an
>>>             agreement this time.
>>>
>>>             Harald
>>>
>>>
>>>
>>>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 4 Nov 2014 10:17:03 -0500

Matthew,

You wrote:
"A "substantive change" would be *any* of the parties who participate in
these discussions having a different position than before."

Let us not forget that this working group is a large set of people, many of
whom are not amongst the frequent posters and/or highly opinionated folks
on this and other threads. While the changes over the last year are
unlikely to sway the opinions of those who are entrenched, they may make
enough difference to folks in the middle. Enough, at least, for us to
achieve rough consensus, since that is the best we can hope for.

Given the importance of this issue to making webRTC viable in the market,
and given the relatively low cost of running a brief discussion (updates
only!) and hum at IETF, I see only a possibility of great progress and
almost no negative costs to trying.

-Jonathan R.

On Tue, Nov 4, 2014 at 9:55 AM, Daniel-Constantin Mierla <[email-masked]>
wrote:

> technology (video codec in this case) is superior enough to the other for
> taking that in consideration (there were results from tests over tests and
> re-tests done by various entities), nothing changed, so this is not an
> excuse/reason to be considered. I did use 'I' not 'IETF' for my opinions,
> there is no 'equate' but 'expect'. Also, no IPR assumptions, just stated
> that nothing relevant changed related to them, given the conclusions from
> the past discussions.
>
> from how IETF worked so far and I hope the future activity still tries to
> follow the 'preferred' guidelines rather than the 'exceptions'.
>
> Those being said, unless you can point case by case the specific parts in
> my initial opinions, I don't really get what you targeted with your answer.
>
> Daniel
>
>
> Your statements about what the IETF should expect are somewhat different
> from the statements in RFC 3979. I quote:
>
>
>  ------------------------------
> *From:* rtcweb [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Daniel-Constantin Mierla
> *Subject:* Re: [rtcweb] The MTI Codec Questions (what to ask and how to
> ask them)
>
> surrounding environment around video codecs, that's their time, can be done
> anywhere at their wish.
>
> relevant to the video codecs constraints. No change from MPEG-LA on H.264
> costs and restrictions for use freely by everyone (including the open
> source space), as expected when having to implement an open standard from
> IETF. No final decisions on patent claims to VP8.
>
> - VP8 pattent claims get to a final decision in court, so either they are
> dismissed there or they can be dealt differently
> I expect IETF is going to stand against monopolistic trends and particular
> business interests, being the standardization body for open protocols in an
> open internet. It is no excuse to release/propose IETF standards that force
> someone either to pay to or be tracked by specific group of interests.
>
> different communication means -- under monopoly, with high costs and very
> rigid -- without open standards with no barriers for anyone, the level of
> innovation we benefited in the past years wouldn't have happened.
>
> Daniel
>
>
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>

---

From: cowwoc <[email-masked]>
Date: Tue, 04 Nov 2014 10:24:04 -0500

On 04/11/2014 10:17 AM, Jonathan Rosenberg wrote:
> Matthew,
>
> You wrote:
> "A "substantive change" would be *any* of the parties who participate 
> in these discussions having a different position than before."
>
> Let us not forget that this working group is a large set of people, 
> many of whom are not amongst the frequent posters and/or highly 
> opinionated folks on this and other threads. While the changes over 
> the last year are unlikely to sway the opinions of those who are 
> entrenched, they may make enough difference to folks in the middle. 
> Enough, at least, for us to achieve rough consensus, since that is the 
> best we can hope for.
>
> Given the importance of this issue to making webRTC viable in the 
> market, and given the relatively low cost of running a brief 
> discussion (updates only!) and hum at IETF, I see only a possibility 
> of great progress and almost no negative costs to trying.
>
> -Jonathan R.
>

I think Matthew is referring to "/Insanity/: doing the same thing over 
and over again and expecting different results."-Albert/Einstein/

:)

I'd like to understand whether there has been any progress on friendlier 
licensing terms for H264 or a royalty-free profile. The H264 crowd made 
a lot of noise about these possibilities but nothing seems to have come 
out of them.

If you want the community to adopt H264 over VP8, then you need to make 
some serious progress on these two points.

Gili

---

From: Mary Barnes <[email-masked]>
Date: Tue, 4 Nov 2014 09:45:57 -0600

Comments below on the questions [MB].

Mary.

On Mon, Nov 3, 2014 at 5:32 PM, Sean Turner <[email-masked]> wrote:

> All,
>
> One of the remaining major technical decisions for the RTCweb WG is which
> codec(s) should be  MTI.  The issue has been on hold for over 6 months and
> the original plan to was the re-attempt determining consensus at the IETF
> 91.  To make the best use of the WG’s face-to-face time at IETF 91, we want
> to give the WG ample time to digest/discuss the questions the chairs intend
> to ask the WG concerning the MTI codec (or codecs).  We want to know before
> the meeting whether to ask the questions and then what questions to ask -
> in other words we want to inform the WG of the questions before the WG
> session so as to not waste time debating what questions should be asked.
>
[MB] I'll answer this now - NO. [/MB]

>
> Question #1 (stand up)
>
> Please stand (or signal in the jabber chat) if you will be part of that
> consensus process for this question. If you're here to read email or watch
> the show, we want to know that your sitting throughout this isn't
> expressing opinions for the consensus process.
>
[MB] I'm assuming that even if one hums NO for the question above that one
can still stand at this point?   [/MB]

> Are there any codecs that were not included in the previous consensus
> calls that warrant consideration?  If yes, which one and why.
>

[MB] So, are you going to let people hum more than once?  If so, I cannot
see how the outcome will be any different than the last time we had this
discussion.  I didn't hum twice last time because it made no sense to me.
I would hum for all of those and my guess is that many others are in the
same boat.   I was going to suggest you separate the questions under number
5, but I don't think that will change the outcome either.
[/MB]

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Nov 2014 16:55:13 +0000

Hi Sean,

>    - Who can live with a requirement that all endpoints MUST support H.264?

As far as I know, we are still discussing the terminology, and meaning of "WebRTC User Agent", "WebRTC device", etc, so I don't think it is a good idea to use that in a hum at this point.

Or, if you want to use it, please provide a definition, to be used in the hum, of the terminology.

Regards,

Christer

---

From: tim panton <[email-masked]>
Date: Tue, 4 Nov 2014 17:01:48 +0000

> Or, if you want to use it, please provide a definition, to be used in the hum, of the terminology.

I think it may be possible to dodge the device definition problem by saying:

All implementations of the rtcweb specification must implement at least one of  VP8 or H.264, 
implementations that also implement the w3c’s webRTC javascript  API must implement  both VP8 and H264

- The latter requirement would also need to be blessed by the w3c of course.

T.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 5 Nov 2014 11:22:21 +0000

On 04/11/14 07:36, Justin Uberti wrote:
>     ps. Doing this with hums at a meeting just encourages filling the
>     room with people who aren't participating in the process but whose
>     employers have asked them to stuff the room to increase the hum
>     volume. Those people will all stand up for question #1, then leave
>     immediately after the hums are completed. Just like last time.
>
> from IETF 88 (the last time we discussed codecs, on day 2) will put to
> rest these claims.
>
> Wait...
>
> Company 	Day2 RTCWEB Attendees 	Day1 RTCWEB Attendees 	Delta
> cisco 	25 	15 	10
> mozilla 	12 	12 	0
> ericsson 	10 	5 	5

When I read the blue sheets I get 9 and 6 respectively. One of the three 
delta persons was Bo Burman who presented 
http://www.ietf.org/proceedings/88/slides/slides-88-rtcweb-8.pdf.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Nov 2014 16:47:23 +0100

> implementations that also implement the w3c’s webRTC javascript  API must implement  both VP8 and H264

+1

This is obviously the only way-to-go and the only reasonable and
feasible decision.

BTW and given that this is a W3C business, I would replace:
  "implementations that also implement the w3c’s webRTC javascript  API"
with:
  "browsers"

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: cowwoc <[email-masked]>
Date: Wed, 05 Nov 2014 11:58:33 -0500

>    "implementations that also implement the w3c’s webRTC javascript  API"

Why should we treat non-browsers any differently?

Gili

---

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 5 Nov 2014 18:16:00 +0100

> implementations that also implement the w3c’s webRTC javascript  API must implement  both VP8 and H264

I'd be OK with that

-Victor

-- 
Victor Pascual Ávila

---

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Nov 2014 09:27:49 -0800

On Wed, Nov 5, 2014 at 3:22 AM, Stefan Håkansson LK <
[email-masked]> wrote:

> > <
> http://www.ietf.org/proceedings/88/bluesheets/bluesheets-88-rtcweb-01.pdf>
> > sheets
> > <
> http://www.ietf.org/proceedings/88/bluesheets/bluesheets-88-rtcweb-02.pdf>

Yes, this was a counting error on my part, apologies for that.

---

From: Neil Stratford <[email-masked]>
Date: Wed, 5 Nov 2014 17:29:31 +0000

> implement  both VP8 and H264

That gets my support.

Neil

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Wed, 05 Nov 2014 18:46:41 +0100

>> implementations that also implement the w3c’s webRTC javascript  API must implement  both VP8 and H264
I don't see any reason to split on JavaScript API implementations and
the rest.

Moreover, looking back, the web browsers (and the web ecosystem itself)
got to this level mainly due to open source implementations, via
khtml/webkit and gecko/firefox (then servers and other tools), which at
some point were small and not benefiting of any substantial resources.
If any of "must implement" requirements adds limits (financial or not)
to the usage in any kind of major open source licensing models, it is
going to block a lot of innovation and disruption in the field.

Better the freedom to negotiate anything and fail to find some common
grounds in a session than building a walled garden for 'the chosen ones'
-- hopefully the aim is not to build a new pstn-like ecosystem.

Daniel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Nov 2014 19:30:12 +0100

> Why should we treat non-browsers any differently?

Because the W3C can just standardize stuff for browsers, and not for
mobile/desktop native apps.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Nov 2014 19:38:35 +0100

> -- hopefully the aim is not to build a new pstn-like ecosystem.

Very good point.

Chrome exists thanks to an open source project. It wouldn't be fair
that now Chrome gets something that other users of the same source
project are not allowed to use due to the licensing business model of
the "Industry" (Industry = those that do not really contribute to
*Web*RTC, but just expect WebRTC satisfies some requirements for their
legacy business).

Of course, if VP8 or H264 or both become a MTI codec for WebRTC
browsers, then any future effort to introduce a new open and 100%
rollalty-free video codec will be unfeasible.

Said that, then what? no MTI codec at all?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: tim panton <[email-masked]>
Date: Wed, 5 Nov 2014 19:05:28 +0000

> Why should we treat non-browsers any differently?

My logic for this is that non-browsers are typically statically programmed, to do a single task well,
so don’t have the same over-riding need for interop with everything else.

A browser has no pre-defined use case and so has to be as flexible as possible to accommodate anything.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 05 Nov 2014 11:07:45 -0800

> rollalty-free video codec will be unfeasible.

There's no barrier to introducing non-MTI codecs. They just won't have
universal support (like any new feature).

VP9 is the obvious candidate for trying that one out.

---

From: tim panton <[email-masked]>
Date: Wed, 5 Nov 2014 19:09:31 +0000

> -- hopefully the aim is not to build a new pstn-like ecosystem.

I accept that argument, to an extent. However I think the costs of producing an all new browser
are now so high that the H264 license won’t be the blocker. I have no evidence for this opinion.
The combination of the Cisco h264 plugin ugliness and the exposure of h264 hardware on iOS also
mitigate the problem. It is however still a problem, but on balance having no webRTC MTI for video is 
worse IMHO.

---

From: tim panton <[email-masked]>
Date: Wed, 5 Nov 2014 19:12:55 +0000

On 5 Nov 2014, at 15:47, Iñaki Baz Castillo <[email-masked]> wrote:

>  “browsers"

Yes, that is the intention, but I think it is easier to get agreement on this clear, if clumsy, definition.
If you want to come up with a good  definition of a browser, feel free :-)
Me, I’m dodging that bullet!

T.

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Wed, 05 Nov 2014 20:44:11 +0100

> are now so high that the H264 license won’t be the blocker. I have no evidence for this opinion.

I don't want to rule out the possibility of having a completely new
implementation.

Anyhow, by the nature of open source, if someone doesn't like the path a
project goes, then the project can forked. Even the big players that
could eventually afford plenty of resources do that: webkit was started
by apple as fork of khtml, (afaik) blink from chrome is forked from webkit.

We already have small players around (khtml is still there, popular
within kde) or tailored versions (debian ships own browser built out of
mozilla code -
http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project).

> mitigate the problem. It is however still a problem, but on balance having no webRTC MTI for video is 

Any kind of restricting the freedom to implement open protocols/specs is
worse than no MTI for video, IMO.

Daniel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Nov 2014 20:55:12 +0100

> If you want to come up with a good  definition of a browser, feel free :-)

Please enlighten me... do we also have problems to define what a browser is?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Wed, 05 Nov 2014 20:56:51 +0100

> Said that, then what? no MTI codec at all?
Yes, better no MTI for video than a MTI allowing only some 'particular'
players.

If the "Industry" wants to make MTI a codec they control, then they have
to make it completely free to everyone. Most of the web ecosystem
(browsers, servers, languages, etc ...) was made free by others and they
don't have to pay to benefit of it, then, whatever is not free, it is
not enforced to anyone in order to be 'on web'.

Daniel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Nov 2014 21:15:53 +0100

> not enforced to anyone in order to be 'on web'.

100% agreed. Just be careful when you say "free" as Cisco may argument
that their binary is "free".

I will keep a modified version of your perfect statement:

"If the 'Industry' wants to make MTI a codec they control, then they
have to make it completely free and open to everyone."

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 5 Nov 2014 21:20:45 +0100

> have to make it completely free and open to everyone."

BTW note that if such a codec becomes free and open, then the
"Industry" would not control it anymore. So expect a big "NO" from the
"Industry" on this topic.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Wed, 05 Nov 2014 21:27:31 +0100

> have to make it completely free and open to everyone."
OK, I see - some time any nuance can be employed :-) .

Indeed, I meant 'free' as in complete freedom (no barrier to use any
kind of implementation - own one, an open one or paid one - definitely,
not restricted to use a particular implementation claimed to be free at
a moment).

Daniel

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 6 Nov 2014 09:00:48 +1100

> Please enlighten me... do we also have problems to define what a browser
is?

In the W3C the word UA (user agent) is often used in place of browser
because "browser" means different things to different people.

Cheers,
Silvia.

---

From: tim panton <[email-masked]>
Date: Wed, 5 Nov 2014 22:39:36 +0000

> I don't want to rule out the possibility of having a completely new

I’m not ruling it out, I just claim that any full fresh implementation of all the w3c specs
would be an order of magnitude more expensive to produce than the maximum cost of the H264 license.
I admit that I have no evidence to back that view.

> http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project).

Agreed, the worst aspect of any adoption of H264 is that it makes it significantly more difficult to
produce a custom ’secure’ build of firefox that has been independently reviewed for special use-cases
(press, humanitarian workers etc). I suspect those users might be prepared to forego the ‘w3c webRTC compliant’
logo in exchange for increased security.

Khtml is interesting - it isn’t a browser, it is a component (I think) - ideally it would come under the ‘either’ codec
rule - but since it implements a javascript API it falls into the ‘wrong’ category. Konquorer is the browser app I think?

> worse than no MTI for video, IMO.

I am very keen to avoid a restriction at the protocol (IETF) level, but feel it is marginally acceptable at the
API (w3c) layer for those who choose to implement the full spec.

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 6 Nov 2014 00:00:13 +0100

2014-11-05 23:39 GMT+01:00 tim panton <[email-masked]>:
> Khtml is interesting - it isn’t a browser, it is a component (I think) -

KHTML is a HTML/CSS/JS rendered, right.

> ideally it would come under the ‘either’ codec
> rule - but since it implements a javascript API it falls into the ‘wrong’
> category. Konquorer is the browser app I think?

Right, Konqueror is a web browser. But there are lot of KDE apps
(which are not web browsers) than include a KHTML view to get and
render web pages (for example KTorrent and many others).

Said that, I'm not sure whether WebRTC should be implemented in KHTML
or in Konqueror.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Rob Pickering <[email-masked]>
Date: Thu, 06 Nov 2014 01:36:44 +0000

> Me, I’m dodging that bullet!
+1 to the proposal and sane to dodge the bullet

Perhaps that should read "implementations that also *expose* the w3c's 
javascript API" otherwise there is an interesting case where a compiled 
mobile app isn't a "browser", but the same app using one of the JS app 
frameworks internally is. Externally they have essentially the same 
characteristics.

--
     Rob.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 5 Nov 2014 22:03:13 -0500

> frameworks internally is. Externally they have essentially the same

Does this mean that node.js, must support H.264 if it implements W3C
javascript API? I doubt anybody will call it a browser.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Nov 2014 21:14:27 -0800

On Wed, Nov 5, 2014 at 2:39 PM, tim panton <[email-masked]> wrote:

> (press, humanitarian workers etc).
>

Why is this true? We currently build OpenH264 and then send the binary to
Cisco but keep a hash for comparison. Why is it more difficult to review
this?

-Ekr

I suspect those users might be prepared to forego the ‘w3c webRTC compliant’

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 6 Nov 2014 07:08:34 +0000

> project are not allowed to use due to the licensing business model of

(To my understanding Chrome already contains a lot that is not part of 
Chromium - e.g. H.264, Flash, and pdf support. Not meant as an argument 
in any direction, just FYI.)

---

From: tim panton <[email-masked]>
Date: Thu, 6 Nov 2014 07:27:33 +0000

On 6 Nov 2014, at 05:14, Eric Rescorla <[email-masked]> wrote:

> Cisco but keep a hash for comparison. Why is it more difficult to review this?
> 
> -Ekr

I can’t speak for people who actually do that build, but I imagine that they would also need to review
the plug-in mechanism, decide if downloading the plugin on first use represents a threat in itself, decide
how to protect the hash they use to do the comparison and factor in any mechanisms for upgrades of the 
plugin (and therefor changes in the hash).
All of which would represent a significant effort beyond the pure code review. I imagine most will simply remove the
module from the build to save themselves the work.

Tim.

---

From: tim panton <[email-masked]>
Date: Thu, 6 Nov 2014 07:34:25 +0000

On 6 Nov 2014, at 03:03, Roman Shpount <[email-masked]> wrote:

> Perhaps that should read "implementations that also *expose* the w3c's javascript API" otherwise there is an interesting case where a compiled mobile app isn't a "browser", but the same app using one of the JS app frameworks internally is. Externally they have essentially the same characteristics.
> 
> Does this mean that node.js, must support H.264 if it implements W3C javascript API? I doubt anybody will call it a browser.

My formulation was "implementations that also implement the w3c’s webRTC javascript  API must implement  both VP8 and H264"

I’d be surprised if node implemented all of w3c’s webRTC api - for example the <video> tag and how it relates to <canvas> 
or the relationship with webAudio contexts. If it does then it would need to implement both codecs in my view.

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 6 Nov 2014 18:13:47 +0100

> Cisco but keep a hash for comparison. Why is it more difficult to review

If somebody expects that teams like Debian will accept such a hack he
is really wrong. I know the Industry does not care about that, but
software packagers (specially Open Source software packagers) will not
trust this hack from Cisco regardless it has been "adopted" by
Mozilla. When I talk to veteran Firefox users (not involved in WebRTC
at all) about the "binary topic" they just cry.

Said that, I'm pretty sure nobody will comment on the previous proposal:

Is so hard to understand that if the W3C mandates a MTI codec then
such a codec MUST be free and open to everyone (without royalties)?
This is the W3C, not the 3GPP/GSMA. There is no room for binary stuff
or royalties here.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ron <[email-masked]>
Date: Fri, 7 Nov 2014 04:59:37 +1030

> Cisco but keep a hash for comparison. Why is it more difficult to review

Is Cisco offering to ship such binaries for anyone who wants to build
them, or is this a special privilege they offered to you to win your
support for their scheme?

  Ron

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 6 Nov 2014 19:11:21 +0000

We are also working with Red Hat on a potential Gstreamer plugin.
We would be happy to work with Debian or anyone else on other wrappers
for projects that want to download some wrapper format beyond the raw
library.

It would be ideal to have a single binary (per platform) that works for
all applications, without many different wrappers. That was the goal of
the raw library, but apparently this is not sufficient for most projects.
Until we reach an acceptable common wrapper (with verifiable builds),
we¹re happy to have folks contribute their desired wrapper for hosting.
Mozilla contributed the Firefox Gecko Media Plugin (GMP) wrapper. They
were first to contribute, so they were hosted first, not due to any
special privilege.

Mo

On 11/6/14, 1:29 PM, Ron <[email-masked]> wrote:
On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote:
> > produce a custom ¹secure¹ build of firefox that has been independently
> > reviewed for special use-cases

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 6 Nov 2014 21:05:41 +0100

So the world WebRTC ecosystem will depend on Cisco. This is something
unnaceptable and I hope the W3C won't make MTI a video codec under those
circumstances.

---

From: cowwoc <[email-masked]>
Date: Thu, 06 Nov 2014 15:07:55 -0500

First a question and then a rant :)

Question: What are you proposing to replace with a GStreamer plugin?
Rant: 2 years ago I tried to get Gstreamer working on iOS. Let's just 
say it felt like taking a drill to the head. The codebase depended on 
many Linux-specific dependencies (which did not exist on BSD) and some 
of them were very poorly maintained (committers who were unreachable or 
dead .. no joke .. for years). Once I got past that point, it used to 
break randomly in mysterious ways (i.e. the API's error handling sucks, 
once you report a bug it sits unfixed for months)

I know that GStreamer is very popular and that GStreamer SDK has since 
been published for iOS and OSX, but I still don't trust that codebase. I 
wouldn't want to have to maintain a project on top of it.

Gili

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 6 Nov 2014 21:10:37 +0100

What we need is a free, standardized and open video codec, rather than a
universal "binary wrapper".
On 6 Nov 2014 21:08, "cowwoc" <[email-masked]> wrote:

> Rant: 2 years ago I tried to get Gstreamer working on iOS. Let's just say
> it felt like taking a drill to the head. The codebase depended on many
> Linux-specific dependencies (which did not exist on BSD) and some of them
> were very poorly maintained (committers who were unreachable or dead .. no
> joke .. for years). Once I got past that point, it used to break randomly
> in mysterious ways (i.e. the API's error handling sucks, once you report a
> bug it sits unfixed for months)
>

---

From: Ron <[email-masked]>
Date: Fri, 7 Nov 2014 07:30:38 +1030

> were first to contribute, so they were hosted first, not due to any

For Debian, this gets complicated really quickly on lots of fronts,
not the least being the basic principle of not entering into licence
agreements that don't apply equally to everybody.  If someone with a
copy of Debian doesn't have the same rights to use/distribute/modify
it as Debian itself does, then it doesn't meet even the most basic
test of "is it Free/Open".

While the IETF does give working groups some freedom to make exceptions
where exceptional circumstances might justify it, I do think that the
aspirational requirements for freedom to implement proposed standards
are fairly closely aligned to what Debian requires more strictly.

I agree that reproducible builds would go some way toward making a
"single binary" more viable - but that also is a Hard Problem, and
while people are working on it, I don't see it being universally
solved before H.264 has gone the same way as H.261 has.  It does
also still leave the problem of people needing custom and/or urgent
fixes, whether for security reasons or simply because of some show
stopper bug that might be specific to some narrow use case.

What happens when fixing that bug for your app causes somebody else's
app to break because of some other assumption they made in their code?
Who gets to decide whose app gets to stay broken?

I definitely appreciate the good will that Cisco has put into trying
to find viable answers for other groups that would allow its preferred
choice to actually be a viable one, but at the end of the day it is a
hack around the H.264 licencing, and I don't think we're really even
close to having charted the full extent of the thin ice that it is
currently floating on.  The cap announced for H.265 definitely appears
to have responded to this challenge already ...

So the question for me at this stage still really is:

 What exceptional circumstances exist to justify this group deciding
 to go out on such a thin and completely untested limb, to mandate a
 technology that is so obviously, and undisputedly, encumbered?

Especially when we have an alternative choice available to us which is
its technical equal, and for which the equivalent encumberance is, at
best, still the untested assertion of a few far-from-unbiased parties.

I'm not ruling out that there may be *some* solution which makes H.264
viable without needing to resort to Clever Hacks, but so far we seem
to be still well short of that.  At the same time, VP8 is currently
under consideration to become an international standard. And there are
other codecs under development which may change the facts on the ground
too before the work of this group is completed.

I do think we want an MTI video codec, but it's less clear we need to
rush this decision while things that may be quite pertinent to it are
still evolving in new and potentially game changing ways.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Nov 2014 13:08:21 -0800

On Thu, Nov 6, 2014 at 10:29 AM, Ron <[email-masked]> wrote:

> them

I think Mo has answered this.

, or is this a special privilege they offered to you to win your
> support for their scheme?

It certainly wasn't this. When we agreed to do this, the intent was to do
reproducible builds, but then as we got closer to ship engineering
realities intervened and it became clear that it was easier for Mozilla
to do the builds in the interim, but that decision was only made
recently and we would prefer to have reproducible builds, as Mo
says..

-Ekr

---

From: Silvia Pfeiffer <[email-masked]>
Date: Fri, 7 Nov 2014 08:46:18 +1100

+1
That's the best summary of our current state wrt MTI that I've heard.

Best Regards,
Silvia.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 06 Nov 2014 22:52:08 +0100

On of my biggest concerns with VP8 is the lack of alternatives, as 
libvpx has been quite unstable for a while (too many seg-faults if input 
was corrupted), but at least I had the ability to compile and use my own 
version. With Cisco binary, not only I don't have any free-alternative, 
but I can't even compile and use my own version! No way.

BR
Sergio

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 6 Nov 2014 22:55:30 +0100

+1

I just hope that those promoting H264 have something to say about this
instead of ignoring this great and realistic rationale.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 06 Nov 2014 22:56:00 +0100

+1, agree on all statements expecially:

"It does also still leave the problem of people needing custom and/or urgent
fixes, whether for security reasons or simply because of some show
stopper bug that might be specific to some narrow use case."

Been there too many times to not worry about it.

BR
Sergio

On 06/11/2014 22:46, Silvia Pfeiffer wrote:
> On 7 Nov 2014 08:01, "Ron" <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > On 11/6/14, 1:29 PM, Ron <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > > On Wed, Nov 5, 2014 at 2:39 PM, tim panton
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > > >
>     > > > Agreed, the worst aspect of any adoption of H264 is that it
>     makes it
>     > > > significantly more difficult to

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 06 Nov 2014 22:56:14 +0100

+1, agree on all statements, especially:

BR
Sergio

---

From: Ron <[email-masked]>
Date: Fri, 7 Nov 2014 08:29:11 +1030

> recently and we would prefer to have reproducible builds, as Mo

Right, that was sort of the point I elaborated on in my reply to Mo,
there's a very real gulf between how we might like to imagine things
could work, and what's actually going to happen or be possible in the
real world that we actually have to work within.

It's perfectly fine for Mozilla and Cisco to take shortcuts that they
agree serves them both well to make things happen in a timely way.

Where that leaves everyone else is the question I was asking here.
This isn't a shortcut that would seem to scale well to other users,
or one that seems likely to cease to be "necessary" any time soon.

(I believe I already noted the difficulty of doing this when it was
first proposed, so I'm definitely not surprised at it remaining just
a promise at this stage)

I've seen enough engineering realities to be pretty sure that any
untested and novel scheme isn't going to end exactly how the people
who pitched it said it would.  Mozilla's experience with this will
definitely be an interesting datapoint, but it's not clear how well
that will extrapolate to the more general case or the users that
Tim indicated concern for yet.

  Ron

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 7 Nov 2014 09:56:45 +0000

> wouldn't want to have to maintain a project on top of it.

Perhaps http://www.openwebrtc.io/ (which supports both codecs talked 
about) is of interest to you.
Regarding gstreamer and openh264: 
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/openh264 
is available.
And for iOS specifically there is also http://www.openwebrtc.io/bowser.

(I know, I should not have sent this on the list. I could not help 
myself, sorry. Please do not respond to the list - if you're interested 
head over to the gstreamer or openwebrtc channels.)

---

From: Bo Burman <[email-masked]>
Date: Fri, 7 Nov 2014 15:31:35 +0000

I think, as was also said by others, we are moving in circles without very much progress. What seems to be the most pressing issue, the licensing landscape, has changed somewhat since last time we tried to decide on video MTI, but there are still major objections to that landscape and it is also still changing. While I do think we need an MTI video codec, I believe we would make better use of our time postponing the decision a bit longer, at least until VCB is fully settled in MPEG.

/Bo

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Ron
> Sent: den 6 november 2014 22:59
> To: [email-masked]
> > > > > makes it significantly more difficult to produce a custom
> > > > > ’secure’ build of firefox that has been independently reviewed
> > > > > for special use-cases (press, humanitarian workers etc).
> > > >
> > > > Why is this true? We currently build OpenH264 and then send the
> > > > binary to Cisco but keep a hash for comparison. Why is it more
> > > > difficult to review this?
> > >
> > > Is Cisco offering to ship such binaries for anyone who wants to
> > > build them
> >
> > It certainly wasn't this. When we agreed to do this, the intent was to
> > do reproducible builds, but then as we got closer to ship engineering
> > realities intervened and it became clear that it was easier for
> > Mozilla to do the builds in the interim, but that decision was only
> > made recently and we would prefer to have reproducible builds, as Mo
> > says..
> 
> Right, that was sort of the point I elaborated on in my reply to Mo, there's a very real gulf between how we might like to
> imagine things could work, and what's actually going to happen or be possible in the real world that we actually have to
> work within.
> 
> It's perfectly fine for Mozilla and Cisco to take shortcuts that they agree serves them both well to make things happen in
> a timely way.
> 
> This isn't a shortcut that would seem to scale well to other users, or one that seems likely to cease to be "necessary" any
> time soon.
> 
> (I believe I already noted the difficulty of doing this when it was first proposed, so I'm definitely not surprised at it
> remaining just a promise at this stage)
> 
> I've seen enough engineering realities to be pretty sure that any untested and novel scheme isn't going to end exactly
> how the people who pitched it said it would.  Mozilla's experience with this will definitely be an interesting datapoint, but
> it's not clear how well that will extrapolate to the more general case or the users that Tim indicated concern for yet.
> 
>   Ron
> 
>

---

From: cowwoc <[email-masked]>
Date: Fri, 07 Nov 2014 11:06:21 -0500

Or design based on the de-facto situation (no MTI) until the situation 
changes to the point where we can revisit this issue.

Hopefully things will improve. But if they don't... we shouldn't wait 
forever.

Gili

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 7 Nov 2014 17:09:12 +0100

If "things will improve" means a non royalty-polluted codec then I agree.
Until that no MTI codec, because WebRTC is for the web, not for the
Industry.
On 7 Nov 2014 17:07, "cowwoc" <[email-masked]> wrote:

>> I think, as was also said by others, we are moving in circles without
>> very much progress. What seems to be the most pressing issue, the licensing
>> landscape, has changed somewhat since last time we tried to decide on video
>> MTI, but there are still major objections to that landscape and it is also
>> still changing. While I do think we need an MTI video codec, I believe we
>> would make better use of our time postponing the decision a bit longer, at
>> least until VCB is fully settled in MPEG.
>>
>> /Bo
>>
>>>>>> On Wed, Nov 5, 2014 at 2:39 PM, tim panton <[email-masked]>
>>>>>>
>>>>> wrote:
>>>>>
>>> there's a very real gulf between how we might like to
>>> imagine things could work, and what's actually going to happen or be
>>> possible in the real world that we actually have to
>>> work within.
>>>
>>> This isn't a shortcut that would seem to scale well to other users, or
>>> one that seems likely to cease to be "necessary" any
>>> time soon.
>>>
>>> first proposed, so I'm definitely not surprised at it
>>> untested and novel scheme isn't going to end exactly
>>> how the people who pitched it said it would.  Mozilla's experience with
>>> this will definitely be an interesting datapoint, but
>>> it's not clear how well that will extrapolate to the more general case
>>> or the users that Tim indicated concern for yet.
>>>
>>>    Ron
>>>
>>>

---

From: Randell Jesup <[email-masked]>
Date: Tue, 11 Nov 2014 21:11:07 -0500

On 11/5/2014 5:39 PM, tim panton wrote:
> (press, humanitarian workers etc). I suspect those users might be 
> prepared to forego the ‘w3c webRTC compliant’

I'll note that we're running openH264 inside a pretty strong sandbox for 
security reasons, so really one should be vetting the sandbox and 
assuming the code inside is compromised. The sandbox exposes a lot less 
than an NPAPI plugin exposes, for example. Perhaps this helps for your case.

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Sean Turner <[email-masked]>
Date: Wed, 12 Nov 2014 08:59:55 -1000

All,

Based on the responses receive so far to our "The MTI Codec Questions” mail, we are planning to discuss Adam Roach’s proposal instead of the questions that we proposed.  At the end of the discussion, we will seek consensus on it.

spt