Subject: Re: [rtcweb] Plan for MTI video codec?

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 15 Oct 2014 16:20:56 +0200

I surely missed a recent thread on it but, any plan to discuss MTI
Video Codec in HI?

I read in Jonathan's post it's part of the agenda?
http://blogs.cisco.com/collaboration/ciscos-openh264-now-part-of-firefox/

Cheers,
-Victor

On Wed, Sep 11, 2013 at 7:51 PM, Victor Pascual Avila
<[email-masked]> wrote:
> Thanks for the feedback Ted!
>
> On Wed, Sep 11, 2013 at 7:48 PM, Ted Hardie <[email-masked]> wrote:
>> Hi Victor,
>>
>> The chairs have been discussion the structure of the upcoming meeting, and
>> you should expect something from us soon.
>>
>> thanks,
>>
>> Ted
>>
>>
>> On Tue, Sep 10, 2013 at 6:47 AM, Victor Pascual Avila
>> <[email-masked]> wrote:
>>>
>>> Dear WG Chairs,
>>>
>>> What's the plan for the MTI video codec discussion? Are we planning to
>>> discuss this during our next meeting? Is there a reason to delay this
>>> decision?
>>>
>>> My apologies if this has already been discussed but could not find it
>>> in the archives.
>>>
>>> Thanks,
>>> -Victor
>>> _______________________________________________
>>> rtcweb mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
>
>
> --
> Victor Pascual Ávila

-- 
Victor Pascual Ávila

---

From: Ted Hardie <[email-masked]>
Date: Wed, 15 Oct 2014 10:10:05 -0700

Hi Victor,

As you may remember, we tabled discussion of video codecs back in January,
and said that the topic could be re-opened 6 weeks prior to IETF 91.  We do
anticipate discussing it at this meeting, likely in the Thursday slot
(since there is a related BoF earlier that day).

regards,

Ted Hardie

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 Oct 2014 11:39:31 -0700

Are we actually going to spend time discussing draft-ietf-rtcweb-video
(which will provide the details on what is necessary for video
implementations of any codec), or will yet another MTI discussion take up
all the energy (and perhaps time)?

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 16 Oct 2014 14:17:18 -0700

On 10/15/2014 10:10 AM, Ted Hardie wrote:
> Hi Victor,
>
> As you may remember, we tabled discussion of video codecs back in 
> January, and said that the topic could be re-opened 6 weeks prior to 
> IETF 91.  We do anticipate discussing it at this meeting, likely in 
> the Thursday slot (since there is a related BoF earlier that day).
>

And that's because something substantive has changed, or simply because 
wasting the WG time on this again is more entertaining than actually 
finishing a specification that can be independently implemented by all 
browser vendors? (A specification that we are nowhere near having, as 
far as I can tell)

Matthew Kaufman

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Oct 2014 14:28:09 -0700

On 16 October 2014 14:17, Matthew Kaufman <[email-masked]> wrote:
> browser vendors? (A specification that we are nowhere near having, as far as
> I can tell)

Personally, I've found the reprieve from this fight refreshing.  And
it would appear that we've made some real progress as a result.  I'd
suggest that if we don't have new information, we continue to spend
our time productively.  If we can't find topics to occupy our meeting
agenda time, then maybe we can free an agenda slot.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 16 Oct 2014 15:35:45 -0600

On 10/16/14, 3:28 PM, Martin Thomson wrote:
> our time productively.

+1

As I said here on January 28th:

"IMHO the state of video codec development needs to evolve before the WG 
can make a decision regarding an MTI video codec."

As far as I can see, it is still too early to take up the MTI video 
codec issue again, and I urge the WG to continue working on tractable 
problems.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Oct 2014 15:02:30 -0700

One thing we could do instead of wasting time on MTI is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actually interoperate regardless of the codec.

> On Oct 16, 2014, at 2:28 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Thu, 16 Oct 2014 22:40:50 +0000

I completely agree.  MTI is wasting time, given we know the industry is split between H.xxx and VPxxx ... and given we know that H.264/VP8 will become H.265/VP9 rapidly ... we need to ensure WebRTC works with various codecs and guide the industry towards VP8, H.264, VP9, H.265 (not some other variant).  There will be some vendors who support both formats and some who don't.
-chris 

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Thursday, October 16, 2014 3:03 PM
To: Martin Thomson
Cc: [email-masked]
Subject: Re: [rtcweb] Plan for MTI video codec?

>> And that's because something substantive has changed, or simply 
>> because wasting the WG time on this again is more entertaining than 
>> actually finishing a specification that can be independently 
>> implemented by all browser vendors? (A specification that we are 
>> nowhere near having, as far as I can tell)
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 16 Oct 2014 22:50:44 +0000

+ 1

> From: rtcweb [mailto:[email-masked]] On Behalf Of Cavigioli, Chris
> Sent: Thursday, October 16, 2014 5:41 PM
> To: Bernard Aboba; Martin Thomson
> Cc: [email-masked]
> I completely agree.  MTI is wasting time, given we know the industry is
> split between H.xxx and VPxxx ... and given we know that H.264/VP8 will
> become H.265/VP9 rapidly ... we need to ensure WebRTC works with various
> codecs and guide the industry towards VP8, H.264, VP9, H.265 (not some other
> variant).  There will be some vendors who support both formats and some who
> don't.
> -chris
> 
> One thing we could do instead of wasting time on MTI is to actually make
> progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could
> actually interoperate regardless of the codec.
> 
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 16 Oct 2014 18:54:08 -0400

+1 as well. There is nothing of consequence that changed since this
discussion happened last time, so there is no possibility for the decision.

_____________
Roman Shpount

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 17 Oct 2014 11:30:58 +0000

What I am seeing is a better awareness of APIs for accessing embedded codec hardware in the client, and independently of any MTI codec discussion, I think the codec document should address the existing of these, and how they might be used. At least it should not ignore the issue entirely.

But I do agree that I do not really want an MTI codec discussion (unless we find a late night bar to do it in).

Keith

________________________________
From: rtcweb [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 16 October 2014 23:54
To: Makaraju, Maridi Raju (Raju)
Cc: [email-masked]
Subject: Re: [rtcweb] Plan for MTI video codec?

+1 as well. There is nothing of consequence that changed since this discussion happened last time, so there is no possibility for the decision.

_____________
Roman Shpount

On Thu, Oct 16, 2014 at 6:50 PM, Makaraju, Maridi Raju (Raju) <[email-masked]<mailto:[email-masked]>> wrote:
+ 1

> From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Cavigioli, Chris
> Cc: [email-masked]<mailto:[email-masked]>
> From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bernard Aboba
> Cc: [email-masked]<mailto:[email-masked]>
> > On Oct 16, 2014, at 2:28 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>>
> wrote:
> >
> >> On 16 October 2014 14:17, Matthew Kaufman <[email-masked]<mailto:[email-masked]>> wrote:
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 17 Oct 2014 15:22:03 +0200

> One thing we could do instead of wasting time on MTI is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actually interoperate regardless of the codec.

The big argument for an MTI is actually the one stated in -overview: It 
guards against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it 
to everything else, and run well for *some* level of "well" - and I 
would prefer that ecosystem to be one where it's possible to field the 
box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. 
And I don't see much movement on the specifics of the proposals either.

We'll have to interoperate well with the codecs we field. So using some 
time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 
isn't finished either. There's one sentence that needs to be removed.)

I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd 
prefer to re-discuss based on the knowledge that some significant 
players have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have 
said "I have changed my mind".

Harald

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Sun, 19 Oct 2014 05:08:03 +0800

+1 to not having MTI codec discussion unless some progress has been made on
VP8 at MPEG. Any news on that? I'm sharing harald's  feeling that there was
no change on the members position.

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <[email-masked]>
wrote:

> I would like to have an ecosystem where one can field a box, connect it to
> everything else, and run well for *some* level of "well" - and I would
> prefer that ecosystem to be one where it's possible to field the box
> without making prior arrangements with anyone about licenses.
>
> This argument hasn't changed one whit since last time we discussed it. And
> I don't see much movement on the specifics of the proposals either.
>
> time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't
> finished either. There's one sentence that needs to be removed.)
>
> prefer to re-discuss based on the knowledge that some significant players
> have actually changed their minds.
>
>>>> far as

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

   -

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 18 Oct 2014 23:25:03 +0200

Changing the subject line, since this is information that more people
may be interested in having called out clearly:

On 10/18/2014 11:08 PM, Alexandre GOUAILLARD wrote:
> +1 to not having MTI codec discussion unless some progress has been
> made on VP8 at MPEG. Any news on that?

The VCB spec (VP8 in ISO) is in DIS ballot, and the ballot closes in
January.
ISO processes are complex, and I don't always understand them, but if
the ballot results are positive, the standard should be approved.

So far, we have not seen any official feedback, but all the unofficial
feedback I've seen has been more or less editorial in nature.

There are no technical changes that would cause any issues in
compatibility between VP8 and VCB.

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Sun, 19 Oct 2014 09:34:13 +0800

Thanks harald for the update.

I'm tempted to say that this is the only event I can think off, based on
the results of the previous pool, that would motivate some from changing
their mind. Hence putting the MTI discussion back on the table before any
progress on VP8 in IOS is, IMHO, useless.

Alex.

   -

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 19 Oct 2014 11:14:42 -0400

I'm in favor of taking another run at this.

The working group has repeatedly said that an MTI codec is something we
need to produce. And its one of the issues holding up wider adoption of the
technology (not the only one for sure).

And things have changed since the last meeting, a year ago now (November in
Vancouver). Cisco's open264 plugin shipped and now just recently is
integrated into Firefox. iOS8 shipped with APIs for H264. There are other
things worth noting. Will this change the minds of everyone? Surely not.
Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth
finding out.

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <[email-masked]

> +1 to not having MTI codec discussion unless some progress has been made
> on VP8 at MPEG. Any news on that? I'm sharing harald's  feeling that there
> was no change on the members position.
>
>> to everything else, and run well for *some* level of "well" - and I would

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

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 19 Oct 2014 08:43:30 -0700

"And its one of the issues holding up wider adoption of the technology"

[BA] Specifying an MTI encoder/decoder is not sufficient for
interoperability.  It is also necessary to specify the transport in enough
detail to allow independent implementations that interoperate well enough
to be usable in a wide variety of scenarios, including wireless networks
where loss is commonly experienced.

We made the mistake of having an MTI discussion previously with not enough
details on that subject, particularly with respect to H.264.
draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.

So if we are to have the discussion again, it should occur in the context
of detailed specifications and interoperability reports.

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <[email-masked]>
wrote:

> And things have changed since the last meeting, a year ago now (November
> in Vancouver). Cisco's open264 plugin shipped and now just recently is
> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <
> [email-masked]> wrote:
>
>>>> One thing we could do instead of wasting time on MTI is to actually
>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could
>>>>>> because

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Mon, 20 Oct 2014 00:13:23 +0800

@jonathan,

while you are right and availability of 264 implementation or hardware
acceleration has improved, it has never been reported as a problem in the
previous pool by anyone. The 264 royalties, and the VP8 IP risks were,
AFAIR, the main reasons used by individuals to justify their positions.
Today, nothing has changed with respect to those two items (even though
providing open264 royalties and absorbing the license cost for some
platforms might have been a set in the right direction). This is why I
think the conditions are not met for a consensus to be reached.

Alex.

On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba <[email-masked]>
wrote:

>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <[email-masked]
>>> > wrote:
>>>

   -

---

From: Watson Ladd <[email-masked]>
Date: Sun, 19 Oct 2014 09:15:17 -0700

On Sun, Oct 19, 2014 at 9:13 AM, Alexandre GOUAILLARD
<[email-masked]> wrote:
> platforms might have been a set in the right direction). This is why I think
> the conditions are not met for a consensus to be reached.

But now VP8 is going through ISO, and the people claiming patents on
VP8 have had time to sue, and haven't. That's evidence that some
concerns are overblown.

>> detail to allow independent implementations that interoperate well enough to
>> be usable in a wide variety of scenarios, including wireless networks where
>> loss is commonly experienced.
>>
>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD
>>> <[email-masked]> wrote:
>>>>
>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand
>>>> <[email-masked]> wrote:
>>>>>
>>>>> prefer that ecosystem to be one where it's possible to field the box without
>>>>> making prior arrangements with anyone about licenses.
>>>>>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Sun, 19 Oct 2014 17:59:58 +0000

I am hearing a lot of folks outside this group losing faith and beginning to talk about writing off WebRTC for lack of consensus (including analysts).

I am therefore in favor of a very finite amount of "new-news" discussion and another attempt at consensus. We either do or don't have it.

On Oct 19, 2014, at 11:15 AM, Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>> wrote:

The working group has repeatedly said that an MTI codec is something we need to produce. And its one of the issues holding up wider adoption of the technology (not the only one for sure).

And things have changed since the last meeting, a year ago now (November in Vancouver). Cisco's open264 plugin shipped and now just recently is integrated into Firefox. iOS8 shipped with APIs for H264. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth finding out.

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <[email-masked]<mailto:[email-masked]>> wrote:
+1 to not having MTI codec discussion unless some progress has been made on VP8 at MPEG. Any news on that? I'm sharing harald's  feeling that there was no change on the members position.

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
On 10/17/2014 12:02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actually interoperate regardless of the codec.

The big argument for an MTI is actually the one stated in -overview: It guards against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to everything else, and run well for *some* level of "well" - and I would prefer that ecosystem to be one where it's possible to field the box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. And I don't see much movement on the specifics of the proposals either.

We'll have to interoperate well with the codecs we field. So using some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't finished either. There's one sentence that needs to be removed.)

I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer to re-discuss based on the knowledge that some significant players have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have said "I have changed my mind".

Harald

On Oct 16, 2014, at 2:28 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

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

  *

[email-masked]<mailto:[email-masked]>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 19 Oct 2014 14:13:23 -0400

@Alexandre - you say "Today, nothing has changed with respect to those two
items (even though providing open264 royalties and absorbing the license
cost for some platforms might have been a set in the right direction). ".
But, as you say, the availability of Firefox with H264 is a change
(previously it was not yet available); the fact that Cisco has in fact
fronted the cost is a change (at the last meeting some were skeptical this
would happen, but it has). The other big news was IOS8, which now enables
apps to access H264 and Apple pays the cost. Last time, the lack of a
solution on IOS was a big deal. That is also now, no longer an issue. As
such I think there are material changes.

On Sun, Oct 19, 2014 at 12:13 PM, Alexandre GOUAILLARD <
[email-masked]> wrote:

>> We made the mistake of having an MTI discussion previously with not
>> enough details on that subject, particularly with respect to H.264.
>>>> made on VP8 at MPEG. Any news on that? I'm sharing harald's  feeling that
>>>> there was no change on the members position.
>>>>
>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <
>>>> [email-masked]> wrote:
>>>>
>>>>> The big argument for an MTI is actually the one stated in -overview:
>>>>> It guards against interoperability failure.
>>>>>
>>>>> I would like to have an ecosystem where one can field a box, connect
>>>>> it to everything else, and run well for *some* level of "well" - and I
>>>>> would prefer that ecosystem to be one where it's possible to field the box
>>>>> We'll have to interoperate well with the codecs we field. So using
>>>>> some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Mon, 20 Oct 2014 02:46:41 +0800

@watson

I would prefer the ISO process to see through before deciding. That's why I
keep bothering harald for news at every meeting ;-) If for any reason it
does not happen, we're back where we were when we did the last pool.
Nobody has sued .... yet, does not mean there is no IP risk. Actually,
there were at least 3 counts of nokia suing, but the three cases were
negotiated and the result is not available to the public. (here
<http://www.fosspatents.com/2013/05/nokia-files-third-patent-infringement.html>
)

@jonathan

Point taken, I hadn't thought about the implications of H264 hardware
acceleration. If indeed it leverages the need to get a license, that makes
the situation better. Would that be enough ...? We could map all the cases
and see what is left to be dealt with. In any case, deciding about 264
without looking at 265 seems shortsighted, and I am not aware of any
binary, or hardware acceleration support available for 265 yet (even though
iPhone 6 claims to supports 265 acc in its specs, I'm not aware of API that
would allow native app to leverage this capacity).

Correct me if I'm wrong or if I'm missing anything (anyone):

-- desktop browsers --
- firefox, let's assume the 264 binary is used. It also supports VP8.
- chrome on desktop supports vp8 but not 264 (as far as webrtc is
concerned, the media element supports 264 playback).
- what about IE / Safari ? I don't think apple will make a statement, but I
remember reading that microsoft would support 264 (at least for media
element playback) if it is available on the system. Bernard / shijun, any
comment about which codec would be used for ORTC/webRTC?

-- mobile browsers --
- no firefox on iOS. What about the android version, what does it support?
- chrome supports only VP8, and can't support webRTC on iOS anyway (even
though justin is working on a audio-only, API-injection-in-webkit solution).
- opera?

-- mobile native --
- iOS 8+ has system API for hw acc 264
- android has system API for both hw acc 264 and VP8 (is it true?)
- the webrtc.org stack does not support 264 even though kaiduan die from
blackberry provided a patch for this
- the ericson's openwebrtc stack supports 264 in multiple ways (does it
support hw acc?) but lack support for Windows and data channel.

-- Others --
- lots of MCUs / SFUs / Gateways would need 264 in more cases than just the
interoperability between webrtc and SIP, and I'm not sure the cisco
binaries can be used there.

On Mon, Oct 20, 2014 at 2:13 AM, Jonathan Rosenberg <[email-masked]>
wrote:

> @Alexandre - you say "Today, nothing has changed with respect to those
> two items (even though providing open264 royalties and absorbing the
> license cost for some platforms might have been a set in the right
> direction). ". But, as you say, the availability of Firefox with H264 is a
> change (previously it was not yet available); the fact that Cisco has in
> fact fronted the cost is a change (at the last meeting some were skeptical
> this would happen, but it has). The other big news was IOS8, which now
> enables apps to access H264 and Apple pays the cost. Last time, the lack of
> a solution on IOS was a big deal. That is also now, no longer an issue. As
>>> So if we are to have the discussion again, it should occur in the
>>> context of detailed specifications and interoperability reports.
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <[email-masked]
>>> > wrote:
>>>
>>>> And things have changed since the last meeting, a year ago now
>>>> (November in Vancouver). Cisco's open264 plugin shipped and now just
>>>> recently is integrated into Firefox. iOS8 shipped with APIs for H264. There
>>>> are other things worth noting. Will this change the minds of everyone?
>>>> Surely not. Will it sway enough for us to achieve rough consensus? Maybe.
>>>> IMHO - worth finding out.
>>>>
>>>>>> This argument hasn't changed one whit since last time we discussed
>>>>>> it. And I don't see much movement on the specifics of the proposals either.
>>>>>>

   -

---

From: Emil Ivov <[email-masked]>
Date: Sun, 19 Oct 2014 21:39:44 +0200

Given how:

a) a big number of people have indicated their concern that codec 
discussions would steal time away from other important topics that need 
to be progressed and how

b) a second group of people seem to consider it important to have a 
discussion on developments around deployment, adoption and 
standardization of VP8 and H.264

then wouldn't it be reasonable to try and allocate an extra slot for an 
ad hoc meeting on the MTI Video Codec topic?

Emil

-- 
https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 19 Oct 2014 13:30:34 -0700

Alex said:

"I don't think apple will make a statement, but I remember reading that
microsoft would support 264 (at least for media element playback) if it is
available on the system.  Bernard / shijun, any comment about which codec
would be used for ORTC/WebRTC?"

[BA] Microsoft, Apple, Cisco, Blackberry, Ericsson and others have
previously co-authored an H.264 MTI proposal:
https://tools.ietf.org/html/draft-burman-rtcweb-h264-proposal

Even though that proposal expires next week, we still believe it is
possible for an H.264 encoder/decoder to serve as a foundation for
interoperability
between independent implementations.   However, choosing an MTI codec and
specifying aspects of the codec is not enough.  On wireless networks
(bursty) packet loss is common, so it is important to specify transport
aspects and robustness measures.  This would include an MTI FEC scheme and
bandwidth estimation techniques, as well as use of codec-specific feedback
messages.

In terms of what needs to be done, there is work needed on the rtp-usage
document (such as addressing the MTI FEC scheme),  draft-ietf-rtcweb-video,
etc.  Focussing on another MTI debate at this time could make it difficult
to make major progress before IETF 92.

If instead of tackling the hard problems, we spend our precious time on yet
another MTI debate, this will not satisfy customers who have burned
before.  From past experience, they know that if interoperability issues
are not addressed *early on*, patching things up after the fact can be
difficult and time consuming.  Yet that is *exactly* where we are headed.

On Sun, Oct 19, 2014 at 11:46 AM, Alexandre GOUAILLARD <
[email-masked]> wrote:

> @watson
>
> I would prefer the ISO process to see through before deciding. That's why
> I keep bothering harald for news at every meeting ;-) If for any reason it
> - what about IE / Safari ? I don't think apple will make a statement, but
> I remember reading that microsoft would support 264 (at least for media
> - lots of MCUs / SFUs / Gateways would need 264 in more cases than just
> the interoperability between webrtc and SIP, and I'm not sure the cisco
>>> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba <[email-masked]
>>> > wrote:
>>>
>>>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <
>>>> [email-masked]> wrote:
>>>>
>>>>> The working group has repeatedly said that an MTI codec is something
>>>>> we need to produce. And its one of the issues holding up wider adoption of
>>>>> the technology (not the only one for sure).
>>>>>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 19 Oct 2014 22:38:00 +0200

On 10/19/2014 05:43 PM, Bernard Aboba wrote:
> interoperability.  It is also necessary to specify the transport in
> enough detail to allow independent implementations that interoperate
> well enough to be usable in a wide variety of scenarios, including
> wireless networks where loss is commonly experienced. 

Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome,
and usage of various mechanisms for congestion control and repair of
packet loss being applied in live services.

So it can't be all bad.....

> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     The working group has repeatedly said that an MTI codec is
>     something we need to produce. And its one of the issues holding up
>     wider adoption of the technology (not the only one for sure).
>
>     (November in Vancouver). Cisco's open264 plugin shipped and now
>     just recently is integrated into Firefox. iOS8 shipped with APIs
>     for H264. There are other things worth noting. Will this change
>     the minds of everyone? Surely not. Will it sway enough for us to
>     achieve rough consensus? Maybe. IMHO - worth finding out.
>
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         +1 to not having MTI codec discussion unless some progress has
>         been made on VP8 at MPEG. Any news on that? I'm sharing
>         harald's  feeling that there was no change on the members
>         position. 
>
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 One thing we could do instead of wasting time on MTI
>                 is to actually make progress on Sections 4.2 - 4.4 of
>                 draft-IETF-RTCWEB-video, so we could actually
>                 interoperate regardless of the codec.
>
>
>             The big argument for an MTI is actually the one stated in
>             -overview: It guards against interoperability failure.
>
>             I would like to have an ecosystem where one can field a
>             box, connect it to everything else, and run well for
>             *some* level of "well" - and I would prefer that ecosystem
>             to be one where it's possible to field the box without
>             This argument hasn't changed one whit since last time we
>             discussed it. And I don't see much movement on the
>             specifics of the proposals either.
>
>             We'll have to interoperate well with the codecs we field.
>             So using some time to discuss draft-ietf-rtcweb-video
>             seems to make sense. (And 4.1 isn't finished either.
>             There's one sentence that needs to be removed.)
>
>             I wouldn't say I'd be happy to not discuss this in
>             Honolulu. But I'd prefer to re-discuss based on the
>             knowledge that some significant players have actually
>             changed their minds.
>
>             At the moment, I don't see signs that any of the poll
>             respondents have said "I have changed my mind".
>
>             Harald
>
>
>
>
>
>
>                     On Oct 16, 2014, at 2:28 PM, Martin Thomson
>                     <[email-masked]
>                     <mailto:[email-masked]>> wrote:
>
>                         On 16 October 2014 14:17, Matthew Kaufman
>                         <[email-masked]
>                         <mailto:[email-masked]>> wrote:
>                     [email-masked] <mailto:[email-masked]>
>                 [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>         sg.linkedin.com/agouaillard <http://sg.linkedin.com/agouaillard>
>
>          *
>
>
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     http://www.jdrosen.net
>
>     [email-masked] <mailto:[email-masked]>

-- 
Surveillance is pervasive. Go Dark.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 19 Oct 2014 14:29:05 -0700

Harald said:

"Bernard,

We have demonstrated interoperability on VP8 between Firefox and Chrome,
and usage of various mechanisms for congestion control and repair of packet
loss being applied in live services.

So it can't be all bad....."

[BA]  I agree that the lack of interoperability is largely "codec
independent":   that is, implementations based on different mechanisms for
congestion control, repair, etc. will exhibit interoperability problems,
regardless of the codec chosen.   The real test for RTCWEB will be to move
beyond "interoperability of implementations sharing source code"  to
"interoperability of independent implementations, based on open standards".

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand <[email-masked]>
wrote:

> and usage of various mechanisms for congestion control and repair of packet
> loss being applied in live services.
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 20 Oct 2014 01:10:01 +0000

Hi,

On 10/19/14, 9:15 AM, "Watson Ladd" <[email-masked]> wrote:

>>think
>But now VP8 is going through ISO,

... and is is DIS ballot.  Few projects in ISO get stopped at that stage.
To me, it¹s pretty clear that VP8 will have an ISO/IEC blessing within a
year or two.  Without substantial technical changes.  Given the very
limited participation in the relevant subgroup in MPEG, it¹s unclear to me
what good that will do, though.

>and the people claiming patents on
>VP8 have had time to sue, and haven't.

That¹s factually incorrect.  To the best of my knowledge, what would be
factually correct is this: in two cases, companies have been sued over
patents allegedly reading on VP8 in the context of the wider ³smartphone
wars² lawsuits, and the defendants have won non-infringement rulings in
the first instance (though, last I looked, appeals were pending in both
cases).  At least one other case was settled on undisclosed terms.  Some
of these cases were widely reported in the press, others are a little bit
harder to find without access to legal search tools.

>That's evidence that some
>concerns are overblown.

And that depends on your viewpoint.

Stephan

>>>enough
>>>enough
>>>context
>>><[email-masked]>
>>>>we
>>>>(November
>>>>>made
>>>>>>would
>>>>>>it.
>>>>>>some
>>>>>>>> <[email-masked]> wrote:
>>>>>>>>
>>>>>>>>> finishing a specification that can be independently implemented
>>>>>>>>>by
>>>>>>>>> all
>>>>>>>>> browser vendors? (A specification that we are nowhere near
>>>>>>>>>having,
>>>>>>>>> as far as
>>>>>>>>> I can tell)
>>>>>>>>

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Mon, 20 Oct 2014 01:20:04 +0000

Harald said:
“We made the mistake of having an MTI discussion previously with not enough details on that subject…”

We didn’t have quantitative data earlier for a data-driven decision.  Future Web – LTE interop is important.  A group of us in GSMA have been looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video/messaging), specifically looking at user experience impact of latency introduced by added in-network transcoding.  GSMA has approved the whitepaper and it is being prepared for public distribution.

WebRTC – LTE transcoding is now MANDATORY because of “WebRTC Audio Codec and Processing Requirements”. http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio codecs in WebRTC and in LTE are dissimilar.  Thus, REGARDLESS of the video codecs, there is already a significant degradation imposed on Web – LTE links if only MTI codecs are used.  The only systems to avoid this are those which implement OPTIONAL audio codecs to be transcoder-free with LTE.  The same can apply for video codecs.

The GSMA whitepaper refers to:

1.     Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by 3GPP SA4 in August 2014.  To paraphrase, performance objectives for maximum VoLTE device delays in error and jitter free conditions and AMR speech codec operation, the sum of the UE delays in sending and receiving directions (TS + TR) should be ≤ 150ms. If this performance objective cannot be met, the sum of the UE delays in sending and receiving directions (TS + TR) shall in any case be ≤ 190ms.

2.     OPUS – AMR transcoding adds an additional 211.5 ms implementation-agnostic (TS + TR) delay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

3.     To put these numbers in perspective, it is in general desirable to minimize UE delays to ensure low enough end-to-end delays and hence a good conversational experience.  Increasing delay causes people to double-talk making conversations increasingly frustrating.  Guidance to stay below 400 ms maximum one-way delay is found in ITU-T Recommendation G.114 and the computational E-model is in ITU-T Recommendation G.107.

This is a complex topic with many network factors in play.  LTE operators in 3GPP seek UE delays (TS + TR) around 150 ms.  Adding OPUS – AMR transcoding in the network imposes an additional 211.5 ms on top of that, just for audio.  Optionally using AMR in WebRTC, those 211.5 ms can be eliminated, delivering a superior end-user experience.

CONCLUSION:  regardless of MTI codec choices in WebRTC, to provide a good WebRTC – LTE interop experience, emerging WebRTC systems must accommodate MTI codecs already deployed in the LTE domain and in mobile operating systems, namely AMR/AMR-WB and H.264.

POSITION:  To be clear, several Intel SoCs launched at MWC this year for smartphones and tablets support both VP8 and H.264 hardware encode and decode – so Intel is codec-neutral in this MTI debate.  Additionally, Intel has high-performance solutions for transcoding.  However, we wish to inform the industry, with quantitative data, about impact to end-user experience of mandating such transcoding so IETF can make a data-driven decision on video codecs as well as reflect on the impact of already having mandated transcoding on the audio side.

Chris Cavigioli
Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Communications Group (MCG)
+1 (415) 254-4545 mobile
+1 (408) 653-8348 desk
+1 (408) 884-2400 fax
This e-mail may contain confidential and privileged material for the sole use of the intended recipient(s).  Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

From: rtcweb [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Sunday, October 19, 2014 2:29 PM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] Plan for MTI video codec?

Harald said:

"Bernard,

We have demonstrated interoperability on VP8 between Firefox and Chrome, and usage of various mechanisms for congestion control and repair of packet loss being applied in live services.
So it can't be all bad....."

[BA]  I agree that the lack of interoperability is largely "codec independent":   that is, implementations based on different mechanisms for congestion control, repair, etc. will exhibit interoperability problems, regardless of the codec chosen.   The real test for RTCWEB will be to move beyond "interoperability of implementations sharing source code"  to "interoperability of independent implementations, based on open standards".

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
On 10/19/2014 05:43 PM, Bernard Aboba wrote:
"And its one of the issues holding up wider adoption of the technology"

[BA] Specifying an MTI encoder/decoder is not sufficient for interoperability.  It is also necessary to specify the transport in enough detail to allow independent implementations that interoperate well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienced.

Bernard,

We have demonstrated interoperability on VP8 between Firefox and Chrome, and usage of various mechanisms for congestion control and repair of packet loss being applied in live services.

We made the mistake of having an MTI discussion previously with not enough details on that subject, particularly with respect to H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.

So if we are to have the discussion again, it should occur in the context of detailed specifications and interoperability reports.

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>> wrote:
I'm in favor of taking another run at this.

Harald

·

rtcweb mailing list

--

---

From: Ron <[email-masked]>
Date: Mon, 20 Oct 2014 12:48:45 +1030

On Mon, Oct 20, 2014 at 01:20:04AM +0000, Cavigioli, Chris wrote:
> This is a complex topic with many network factors in play.  LTE
> operators in 3GPP seek UE delays (TS + TR) around 150 ms.  Adding OPUS
> – AMR transcoding in the network imposes an additional 211.5 ms on top
> of that, just for audio.  Optionally using AMR in WebRTC, those 211.5
> ms can be eliminated, delivering a superior end-user experience.

That seems like LTE's problem, not ours.

If you start with a codec like Opus where the maximum native frame
size is 60ms and manage to engineer a solution that blows that out
to near 400ms, we'd certainly have to applaud your, uh, innovation.

> CONCLUSION:  regardless of MTI codec choices in WebRTC, to provide a
> good WebRTC – LTE interop experience, emerging WebRTC systems must
> accommodate MTI codecs already deployed in the LTE domain and in
> mobile operating systems, namely AMR/AMR-WB and H.264.

You conclude that since LTE sucks, WebRTC ought to suck too?  That
seems like a strange direction to move in.  150ms is already ample
delay on its own to create a horrible user experience.  The aim of
WebRTC was to create a standard solution that doesn't suck.  If
LTE thinks it won't be able to compete with that, but considers
interoperating with it to be important, maybe it's time LTE thought
more about deploying a codec that's actually up to the job than
about protecting the royalty revenues of its voting group ...

If 150ms is your idea of a "superior end-user experience", then
maybe people who want a satisfactory user experience will simply
avoid using LTE at all, and then this won't be a problem for them,
or us, at all.

  Just sayin'

---

From: Ca By <[email-masked]>
Date: Sun, 19 Oct 2014 21:24:32 -0700

On Sunday, October 19, 2014, Cavigioli, Chris <[email-masked]>
wrote:

> We didn’t have quantitative data earlier for a data-driven decision.
> Future Web – LTE interop is important.  A group of us in GSMA have been
> looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based
> voice/video/messaging), specifically looking at user experience impact of
> latency introduced by added in-network transcoding.  GSMA has approved the
> whitepaper and it is being prepared for public distribution.
>
>
>
> WebRTC – LTE transcoding is now MANDATORY because of “WebRTC Audio Codec
> and Processing Requirements”.
> http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio
> codecs in WebRTC and in LTE are dissimilar.  Thus, REGARDLESS of the video
> codecs, there is already a significant degradation imposed on Web – LTE
> links if only MTI codecs are used.  The only systems to avoid this are
> those which implement OPTIONAL audio codecs to be transcoder-free with
> LTE.  The same can apply for video codecs.
>
>
>
> 1.     Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by
> 3GPP SA4 in August 2014.  To paraphrase, performance objectives for maximum
> VoLTE device delays in error and jitter free conditions and AMR speech
> codec operation, the sum of the UE delays in sending and receiving
> directions (TS + TR) should be ≤ 150ms. If this performance objective
> cannot be met, the sum of the UE delays in sending and receiving directions
> (TS + TR) shall in any case be ≤ 190ms.
>
> 2.     OPUS – AMR transcoding adds an additional 211.5 ms
> implementation-agnostic (TS + TR) delay, including 40 ms for jitter
> buffer and 40 ms for discontinuous reception (DRX).
>
> 3.     To put these numbers in perspective, it is in general desirable to
> minimize UE delays to ensure low enough end-to-end delays and hence a good
> conversational experience.  Increasing delay causes people to double-talk
> making conversations increasingly frustrating.  Guidance to stay below 400
> ms maximum one-way delay is found in ITU-T Recommendation G.114 and the
> computational E-model is in ITU-T Recommendation G.107.
>
>
>
> This is a complex topic with many network factors in play.  LTE operators
> in 3GPP seek UE delays (TS + TR) around 150 ms.  Adding OPUS – AMR
> transcoding in the network imposes an additional 211.5 ms on top of that,
> just for audio.  Optionally using AMR in WebRTC, those 211.5 ms can be
> eliminated, delivering a superior end-user experience.
>
>
>
> CONCLUSION:  regardless of MTI codec choices in WebRTC, to provide a good
> WebRTC – LTE interop experience, emerging WebRTC systems must accommodate
> MTI codecs already deployed in the LTE domain and in mobile operating
> systems, namely AMR/AMR-WB and H.264.
>
>
>
> POSITION:  To be clear, several Intel SoCs launched at MWC this year for
> smartphones and tablets support both VP8 and H.264 hardware encode and
> decode – so Intel is codec-neutral in this MTI debate.  Additionally, Intel
> has high-performance solutions for transcoding.  However, we wish to inform
> the industry, with quantitative data, about impact to end-user experience
> of mandating such transcoding so IETF can make a data-driven decision on
> video codecs as well as reflect on the impact of already having mandated
> transcoding on the audio side.
>
>
>
>
Chris,

My expectation is that something acceptable will be negotiated. And, these
LTE smartphones can and do support a variety of codecs, as you noted.

AMR and h264 are tied to walled garden mobile telco IMS mumbo jumbo, which
has little to do with webrtc, and webrtc has a lot to do with an open
internet. My guess is the IMS will change to interop with webrtc in an
effort to stay relevant.

CB

> This e-mail may contain confidential and privileged material for the sole
> use of the intended recipient(s).  Any review or distribution by others is
> strictly prohibited. If you are not the intended recipient, please contact
> the sender and delete all copies.
>
>
>
> *From:* rtcweb [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Bernard
> Aboba
> *Sent:* Sunday, October 19, 2014 2:29 PM
> *To:* Harald Alvestrand
> *Cc:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Subject:* Re: [rtcweb] Plan for MTI video codec?
>
>
>
> Harald said:
>
>
>
> "Bernard,
>
>
> On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>  On Oct 16, 2014, at 2:28 PM, Martin Thomson <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> On 16 October 2014 14:17, Matthew Kaufman <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> http://www.jdrosen.net
>
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Justin Uberti <[email-masked]>
Date: Sun, 19 Oct 2014 22:52:14 -0700

Looks like someone wants to have not just one, but two MTI codec
discussions...

On Sun, Oct 19, 2014 at 6:20 PM, Cavigioli, Chris <[email-masked]

> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Bernard
> Aboba
> *Cc:* [email-masked]

---

From: Victor Pascual <[email-masked]>
Date: Mon, 20 Oct 2014 08:00:21 +0200

And that's what the 3GPP is doing for release 12: http://webrtchacks.com/ims-approach-webrtc/

> On Oct 20, 2014, at 6:24 AM, Ca By <[email-masked]> wrote:
> 
> My guess is the IMS will change to interop with webrtc in an effort to stay relevant.

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Mon, 20 Oct 2014 07:09:17 +0000

No, not 2 discussions … but 2 MTI codecs.
Given:

-       Industry is polarized c. 40% VP8 vs. c. 40% H.264

-       Unlikely this will change

-       Every single mobile device (100%) of the billions out there running a mobile OS (iOS, Android, Windows, BB OS, etc) will already support H.264, AMR-xx since those are MTI for 3GPP and for the OS
Then:

-       Why not support both:  VP8, Opus = web; H.264, AMR/AMR-WB = LTE

-       Every single mobile device and OS already deals with H.264+AMR licensing for many years.

-       Being royalty free, incrementally adding VP8 and Opus shouldn’t be a major additional impact
-chris

From: Justin Uberti [mailto:[email-masked]]
Sent: Sunday, October 19, 2014 10:52 PM
To: Cavigioli, Chris
Cc: Harald Alvestrand; Bernard Aboba; [email-masked]
Subject: Re: [rtcweb] Plan for MTI video codec?

Looks like someone wants to have not just one, but two MTI codec discussions...

On Sun, Oct 19, 2014 at 6:20 PM, Cavigioli, Chris <[email-masked]<mailto:[email-masked]>> wrote:
Harald said:
“We made the mistake of having an MTI discussion previously with not enough details on that subject…”

Chris Cavigioli
Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Communications Group (MCG)
+1 (415) 254-4545<tel:%2B1%20%28415%29%20254-4545> mobile
+1 (408) 653-8348<tel:%2B1%20%28408%29%20653-8348> desk
+1 (408) 884-2400<tel:%2B1%20%28408%29%20884-2400> fax
This e-mail may contain confidential and privileged material for the sole use of the intended recipient(s).  Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

Harald said:

"Bernard,

Bernard,

Harald

•

rtcweb mailing list

--

---

From: Barry Dingle <[email-masked]>
Date: Mon, 20 Oct 2014 19:52:38 +1100

Chris,

So you are saying that we should NOT have 'unqualified' MTI Audio and Video
codecs.

Rather, we should have 2 (or more) Network Scenarios and have Audio+Video
MTI's for Each Network Scenario.

Browsers that wish to support multiple Network Scenarios will support the
MTI's for those Scenarios. Special Browsers - or a sub-set of a Browser -
MAY support only specific Network Scenarios and their MTIs.

This seems to make a lot of sense.

Cheers,
Barry Dingle
Fixed - +61(0)3-9725-3937    Mob - +61(0)41-911-7578
Fellow of University of Melbourne, Australia

On Mon, Oct 20, 2014 at 6:09 PM, Cavigioli, Chris <[email-masked]

> -       Every single mobile device (100%) of the billions out there
> running a mobile OS (iOS, Android, Windows, BB OS, etc) will already
> support H.264, AMR-xx since those are MTI for 3GPP and for the OS
>
> Then:
>
> *From:* Justin Uberti [mailto:[email-masked]]
> *Sent:* Sunday, October 19, 2014 10:52 PM
> *To:* Cavigioli, Chris
> *Cc:* Harald Alvestrand; Bernard Aboba; [email-masked]
>
> On Sun, Oct 19, 2014 at 6:20 PM, Cavigioli, Chris <
> [email-masked]> wrote:
>
> Harald said:
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 20 Oct 2014 10:05:48 +0000

Given that codecs appear in the end device and the 3GPP activity is to provide a gateway, either the gateway provides transcoding or the two end devices use SDP to agree on a mutually acceptable codec. 

Our view is that in many of these cases, it is perfectly possible for a webRTC device and the 3GPP device to decide to use H.264 as the codec and will do so, in order to avoid transcoding. 

That will occur whatever is specified as an MTI video codec.

Keith

> From: rtcweb [mailto:[email-masked]] On Behalf Of 
> Victor Pascual
> Sent: 20 October 2014 07:00
> To: Ca By
> Cc: [email-masked]
> And that's what the 3GPP is doing for release 12: 
> http://webrtchacks.com/ims-approach-webrtc/
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Oct 2014 05:02:46 -0700

> MTI's for Each Network Scenario.

Why should your network attachment conditions determine who you can talk to?

---

From: Andrew Allen <[email-masked]>
Date: Mon, 20 Oct 2014 13:52:10 +0000

Chris

What is the scenario that dictates the need for direct transcoding between OPUS and AMR?

All RTCweb clients MUST support OPUS so for Web browsers on mobile LTE devices OPUS can be negotiated with non mobile RTCweb devices end to end.

My expectation is that for mobile devices the RTCweb client will also have access to the embedded AMR codec so mobile RTCweb devices can interoperate using AMR with non-RTCweb enabled mobile IMS devices that support AMR.

For interoperation between non mobile RTCweb devices and mobile non RTCweb IMS devices the non mobile RTCweb device can use G.711 to the transcoder for transcoding to AMR on the other side. While not ideal this will be no worse than non mobile RTCweb devices interoperating with circuit switched only mobile devices which will be forced to interoperate via the PSTN.

As RTCweb becomes universal on mobile devices I expect that support for OPUS will become native and mobile IMS devices will also be able to use OPUS even when operating without the use of the browser (i.e. in non RTCweb mode) for better interoperation with non-mobile RTCweb devices.

The lifetime of most mobile devices is 2 years or less so this is likely to be mainly a short term transition issue only.

Andrew

From: Cavigioli, Chris [mailto:[email-masked]]
Sent: Sunday, October 19, 2014 09:20 PM Eastern Standard Time
To: Harald Alvestrand <[email-masked]>; Bernard Aboba <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Plan for MTI video codec?

Harald said:

Chris Cavigioli

Harald said:

"Bernard,

Bernard,

Harald

rtcweb mailing list

--

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 20 Oct 2014 14:34:58 +0000

The scenario where you might want to transcode the audio codec is where you have wideband audio in both the OPUS and the AMR, and you believe by transcoding you can achieve a wideband quality, rather than falling back to G.711. And for interworking between 3GPP devices that are not using webRTC, the audio will still be AMR or AMR-WB or EVC, not OPUS.

But audio transcoding is not particularly a concern for me. It is trying where possible to avoid video transcoding.

Keith

________________________________
From: rtcweb [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 20 October 2014 14:52
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [rtcweb] Plan for MTI video codec?

Chris

Andrew

Harald said:
"We made the mistake of having an MTI discussion previously with not enough details on that subject..."

We didn't have quantitative data earlier for a data-driven decision.  Future Web - LTE interop is important.  A group of us in GSMA have been looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video/messaging), specifically looking at user experience impact of latency introduced by added in-network transcoding.  GSMA has approved the whitepaper and it is being prepared for public distribution.

WebRTC - LTE transcoding is now MANDATORY because of "WebRTC Audio Codec and Processing Requirements". http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio codecs in WebRTC and in LTE are dissimilar.  Thus, REGARDLESS of the video codecs, there is already a significant degradation imposed on Web - LTE links if only MTI codecs are used.  The only systems to avoid this are those which implement OPTIONAL audio codecs to be transcoder-free with LTE.  The same can apply for video codecs.

2.     OPUS - AMR transcoding adds an additional 211.5 ms implementation-agnostic (TS + TR) delay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

This is a complex topic with many network factors in play.  LTE operators in 3GPP seek UE delays (TS + TR) around 150 ms.  Adding OPUS - AMR transcoding in the network imposes an additional 211.5 ms on top of that, just for audio.  Optionally using AMR in WebRTC, those 211.5 ms can be eliminated, delivering a superior end-user experience.

CONCLUSION:  regardless of MTI codec choices in WebRTC, to provide a good WebRTC - LTE interop experience, emerging WebRTC systems must accommodate MTI codecs already deployed in the LTE domain and in mobile operating systems, namely AMR/AMR-WB and H.264.

POSITION:  To be clear, several Intel SoCs launched at MWC this year for smartphones and tablets support both VP8 and H.264 hardware encode and decode - so Intel is codec-neutral in this MTI debate.  Additionally, Intel has high-performance solutions for transcoding.  However, we wish to inform the industry, with quantitative data, about impact to end-user experience of mandating such transcoding so IETF can make a data-driven decision on video codecs as well as reflect on the impact of already having mandated transcoding on the audio side.

Chris Cavigioli

Harald said:

"Bernard,

Bernard,

Harald

rtcweb mailing list

--

---

From: Justin Uberti <[email-masked]>
Date: Mon, 20 Oct 2014 15:29:15 -0700

>From the subject "Plan for MTI video codec", I thought this discussion was
about video codecs, not AMR interop.

An astute observer might take note of the fact that our inability to close
the door on H.264 is providing an opportunity to other royalty-bearing
codecs that want to join the party.

On Mon, Oct 20, 2014 at 7:34 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

>  The scenario where you might want to transcode the audio codec is where
> you have wideband audio in both the OPUS and the AMR, and you believe by
> transcoding you can achieve a wideband quality, rather than falling back to
> G.711. And for interworking between 3GPP devices that are not using webRTC,
> the audio will still be AMR or AMR-WB or EVC, not OPUS.
>
> But audio transcoding is not particularly a concern for me. It is trying
> where possible to avoid video transcoding.
>
> Keith
>
>  ------------------------------
> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Andrew
> Allen
> *Sent:* 20 October 2014 14:52
> *To:* [email-masked]; [email-masked];
> [email-masked]
>
> *Cc:* [email-masked]
> All RTCweb clients MUST support OPUS so for Web browsers on mobile LTE
> devices OPUS can be negotiated with non mobile RTCweb devices end to end.
>
> My expectation is that for mobile devices the RTCweb client will also have
> access to the embedded AMR codec so mobile RTCweb devices can interoperate
> using AMR with non-RTCweb enabled mobile IMS devices that support AMR.
>
> For interoperation between non mobile RTCweb devices and mobile non RTCweb
> IMS devices the non mobile RTCweb device can use G.711 to the transcoder
> for transcoding to AMR on the other side. While not ideal this will be no
> worse than non mobile RTCweb devices interoperating with circuit switched
> only mobile devices which will be forced to interoperate via the PSTN.
>
> As RTCweb becomes universal on mobile devices I expect that support for
> OPUS will become native and mobile IMS devices will also be able to use
> OPUS even when operating without the use of the browser (i.e. in non RTCweb
> mode) for better interoperation with non-mobile RTCweb devices.
>
> The lifetime of most mobile devices is 2 years or less so this is likely
> to be mainly a short term transition issue only.
>
> Andrew
>
>  *From*: Cavigioli, Chris [mailto:[email-masked]]
> *Sent*: Sunday, October 19, 2014 09:20 PM Eastern Standard Time
> *To*: Harald Alvestrand <[email-masked]>; Bernard Aboba <
> [email-masked]>
> *Cc*: [email-masked] <[email-masked]>
> *Subject*: Re: [rtcweb] Plan for MTI video codec?
>
>
> Harald said:
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 Oct 2014 18:46:27 -0400

Unless H.264 became royalty free or royalty free profile for H.264 is
developed (and I am talking about ability to include any implementation of
this H.264 profile into any project without paying royalties, not linking
to something the end user must  download), H.264 would not be acceptable to
me as an MTI. All the other news updates regarding H.264 are irrelevant. I
would assume most open source developer or smaller software developers
would share my opinion.

Settled law suits regarding VP8 also do not provide a significant change
regarding video MTI.

There is nothing here to discuss except that we all want video MTI, but we
cannot agree on one. Why waste time on this?

_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Oct 2014 00:50:59 +0200

2014-10-21 0:46 GMT+02:00 Roman Shpount <[email-masked]>:
> this H.264 profile into any project without paying royalties, not linking to
> something the end user must  download), H.264 would not be acceptable to me
> as an MTI. All the other news updates regarding H.264 are irrelevant. I
> would assume most open source developer or smaller software developers would
> share my opinion.

+1

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

---

From: Barry Dingle <[email-masked]>
Date: Tue, 21 Oct 2014 10:26:52 +1100

Martin,

Sorry for the confusion. I was trying to use 'network scenario' as a
general term to encompass different end-to-end call situations that involve
my WebRTC network and the destination network e.g. mobile, PSTN, VoIP,
existing Video Services etc. (Opposite call directions also apply of
course.)

I am suggesting that there should be MTI's for several major end-to-end
network scenarios as that is something that the IETF can specify. HOW the
small range of MTI's are Implemented is up to Browsers and the Browsers can
be categorised according to their support of the different network
scenarios.

The Browsers are the key to what codecs are supported. Trying to force
people by Specification to implement something they do not want to support
(for whatever reason) is what is causing us this video codec MTI debate to
be unsolvable.

The IETF Specifications should describe what protocols etc are needed for
interoperability. A separate document can describe which options (in this
case codecs) to use in different end-to-end network scenarios. That is, the
'case-specific' MTIs.

Barry Dingle

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Oct 2014 17:40:33 -0700

On Oct 20, 2014, at 3:29 PM, Justin Uberti <[email-masked]> wrote:
> 
> An astute observer might take note of the fact that our inability to close the door on H.264 is providing an opportunity to other royalty-bearing codecs that want to join the party.

[BA] IETF WG Chairs have the ability to avoid revisiting previously settled issues (e.g. Audio codecs) or unsettled ones (e.g. Video codecs).  

BTW, I've had difficulty verifying the assertion that "AMR codecs are accessible via the hardware without additional fees". There may be an SDK available, but my understanding is that this requires a licensing fee above and beyond the fee required to license AMR codecs in Voice over LTE. In other words, not only is the codec royalty bearing, but access to it for a purpose other than VoLTE requires additional licensing fees.  If this is wrong, please point me to the web page for the appropriate license-free SDKs.

---

From: Victor Pascual <[email-masked]>
Date: Tue, 21 Oct 2014 06:37:45 +0200

Sounds like only consensus so far is we agree to disagree

> On Oct 21, 2014, at 12:46 AM, Roman Shpount <[email-masked]> wrote:
> 
> Unless H.264 became royalty free or royalty free profile for H.264 is developed (and I am talking about ability to include any implementation of this H.264 profile into any project without paying royalties, not linking to something the end user must  download), H.264 would not be acceptable to me as an MTI. All the other news updates regarding H.264 are irrelevant. I would assume most open source developer or smaller software developers would share my opinion.
> 
> Settled law suits regarding VP8 also do not provide a significant change regarding video MTI.
> 
> There is nothing here to discuss except that we all want video MTI, but we cannot agree on one. Why waste time on this?
> 
> _____________
> Roman Shpount
> 
>> On Sun, Oct 19, 2014 at 2:13 PM, Jonathan Rosenberg <[email-masked]> wrote:
>> @Alexandre - you say "Today, nothing has changed with respect to those two items (even though providing open264 royalties and absorbing the license cost for some platforms might have been a set in the right direction). ". But, as you say, the availability of Firefox with H264 is a change (previously it was not yet available); the fact that Cisco has in fact fronted the cost is a change (at the last meeting some were skeptical this would happen, but it has). The other big news was IOS8, which now enables apps to access H264 and Apple pays the cost. Last time, the lack of a solution on IOS was a big deal. That is also now, no longer an issue. As such I think there are material changes.
>> 
>> 
>>> On Sun, Oct 19, 2014 at 12:13 PM, Alexandre GOUAILLARD <[email-masked]> wrote:
>>> @jonathan,
>>> 
>>> while you are right and availability of 264 implementation or hardware acceleration has improved, it has never been reported as a problem in the previous pool by anyone. The 264 royalties, and the VP8 IP risks were, AFAIR, the main reasons used by individuals to justify their positions. Today, nothing has changed with respect to those two items (even though providing open264 royalties and absorbing the license cost for some platforms might have been a set in the right direction). This is why I think the conditions are not met for a consensus to be reached.
>>> 
>>> Alex.
>>> 
>>> 
>>>> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba <[email-masked]> wrote:
>>>>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <[email-masked]> wrote:
>>>>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <[email-masked]> wrote:
>>>>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <[email-masked]> wrote:

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Oct 2014 07:55:08 +0200

On 10/21/2014 12:29 AM, Justin Uberti wrote:
> From the subject "Plan for MTI video codec", I thought this discussion
> was about video codecs, not AMR interop.

All discussions branch, but I strongly recommend changing the subject
line when changing the subject.

The discussion is supposed to be managed by the WG chairs; since they
have not spoken up on this thread at all, I must assume that they do not
wish to constrain the discussion at this time.

>
> An astute observer might take note of the fact that our inability to
> close the door on H.264 is providing an opportunity to other
> royalty-bearing codecs that want to join the party.
>
> On Mon, Oct 20, 2014 at 7:34 AM, DRAGE, Keith (Keith)
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     The scenario where you might want to transcode the audio codec is
>     where you have wideband audio in both the OPUS and the AMR, and
>     you believe by transcoding you can achieve a wideband quality,
>     rather than falling back to G.711. And for interworking between
>     3GPP devices that are not using webRTC, the audio will still be
>     AMR or AMR-WB or EVC, not OPUS.
>      
>     But audio transcoding is not particularly a concern for me. It is
>     trying where possible to avoid video transcoding.
>      
>     Keith
>
>         ------------------------------------------------------------------------
>         <mailto:[email-masked]>] *On Behalf Of *Andrew Allen
>         *To:* [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>
>
>         *Cc:* [email-masked] <mailto:[email-masked]>
>         All RTCweb clients MUST support OPUS so for Web browsers on
>         mobile LTE devices OPUS can be negotiated with non mobile
>         RTCweb devices end to end.
>
>         My expectation is that for mobile devices the RTCweb client
>         will also have access to the embedded AMR codec so mobile
>         RTCweb devices can interoperate using AMR with non-RTCweb
>         enabled mobile IMS devices that support AMR.
>
>         For interoperation between non mobile RTCweb devices and
>         mobile non RTCweb IMS devices the non mobile RTCweb device can
>         use G.711 to the transcoder for transcoding to AMR on the
>         other side. While not ideal this will be no worse than non
>         mobile RTCweb devices interoperating with circuit switched
>         As RTCweb becomes universal on mobile devices I expect that
>         support for OPUS will become native and mobile IMS devices
>         will also be able to use OPUS even when operating without the
>         use of the browser (i.e. in non RTCweb mode) for better
>         interoperation with non-mobile RTCweb devices.
>
>         The lifetime of most mobile devices is 2 years or less so this
>         is likely to be mainly a short term transition issue only.
>
>         Andrew
>          
>         *From*: Cavigioli, Chris [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *To*: Harald Alvestrand <[email-masked]
>         <mailto:[email-masked]>>; Bernard Aboba
>         <[email-masked] <mailto:[email-masked]>>
>         *Cc*: [email-masked] <mailto:[email-masked]>
>         <[email-masked] <mailto:[email-masked]>>
>         “We made the mistake of having an MTI discussion previously
>         with not enough details on that subject…”
>
>          
>
>         We didn’t have quantitative data earlier for a data-driven
>         decision.  Future Web – LTE interop is important.  A group of
>         us in GSMA have been looking at WebRTC interop with LTE (where
>         3GPP / GSMA defined IMS-based voice/video/messaging),
>         specifically looking at user experience impact of latency
>         introduced by added in-network transcoding.  GSMA has approved
>         the whitepaper and it is being prepared for public distribution. 
>
>          
>
>         WebRTC – LTE transcoding is now MANDATORY because of “WebRTC
>         Audio Codec and Processing Requirements”.
>         http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where
>         MTI audio codecs in WebRTC and in LTE are dissimilar.  Thus,
>         REGARDLESS of the video codecs, there is already a significant
>         degradation imposed on Web – LTE links if only MTI codecs are
>         used.  The only systems to avoid this are those which
>         implement OPTIONAL audio codecs to be transcoder-free with
>         1.     Quantitative voice-over-LTE (VoLTE) delay limits were
>         agreed-to by 3GPP SA4 in August 2014.  To paraphrase,
>         performance objectives for maximum VoLTE device delays in
>         error and jitter free conditions and AMR speech codec
>         operation, the sum of the UE delays in sending and receiving
>         directions (T_S + T_R ) should be ≤ 150ms. If this performance
>         objective cannot be met, the sum of the UE delays in sending
>         and receiving directions (T_S + T_R ) shall in any case be ≤
>         190ms.
>
>         implementation-agnostic (T_S + T_R ) delay, including 40 ms
>         for jitter buffer and 40 ms for discontinuous reception (DRX).
>
>         3.     To put these numbers in perspective, it is in general
>         desirable to minimize UE delays to ensure low enough
>         end-to-end delays and hence a good conversational experience. 
>         Increasing delay causes people to double-talk making
>         conversations increasingly frustrating.  Guidance to stay
>         below 400 ms maximum one-way delay is found in ITU-T
>         Recommendation G.114 and the computational E-model is in ITU-T
>         Recommendation G.107.
>
>          
>
>         This is a complex topic with many network factors in play. 
>         LTE operators in 3GPP seek UE delays (T_S + T_R ) around 150
>         ms.  Adding OPUS – AMR transcoding in the network imposes an
>         additional 211.5 ms on top of that, just for audio. 
>         Optionally using AMR in WebRTC, those 211.5 ms can be
>         CONCLUSION:  regardless of MTI codec choices in WebRTC, to
>         provide a good WebRTC – LTE interop experience, emerging
>         WebRTC systems must accommodate MTI codecs already deployed in
>         the LTE domain and in mobile operating systems, namely
>         AMR/AMR-WB and H.264.
>
>          
>
>         POSITION:  To be clear, several Intel SoCs launched at MWC
>         this year for smartphones and tablets support both VP8 and
>         H.264 hardware encode and decode – so Intel is codec-neutral
>         in this MTI debate.  Additionally, Intel has high-performance
>         solutions for transcoding.  However, we wish to inform the
>         industry, with quantitative data, about impact to end-user
>         experience of mandating such transcoding so IETF can make a
>         data-driven decision on video codecs as well as reflect on the
>         impact of already having mandated transcoding on the audio side.
>
>          
>
>         Chris Cavigioli
>
>         Intel Corp, System Architecture and Planning,
>         Video/Multimedia, Mobile and Communications Group (MCG)
>
>         +1 (415) 254-4545 <tel:%2B1%20%28415%29%20254-4545> mobile
>
>         +1 (408) 653-8348 <tel:%2B1%20%28408%29%20653-8348> desk
>
>         +1 (408) 884-2400 <tel:%2B1%20%28408%29%20884-2400> fax
>
>         This e-mail may contain confidential and privileged material
>         for the sole use of the intended recipient(s).  Any review or
>         distribution by others is strictly prohibited. If you are not
>         the intended recipient, please contact the sender and delete
>         all copies.
>
>          
>
>         *From:*rtcweb [mailto:[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *Bernard Aboba
>         *Cc:* [email-masked] <mailto:[email-masked]>
>         We have demonstrated interoperability on VP8 between Firefox
>         and Chrome, and usage of various mechanisms for congestion
>         control and repair of packet loss being applied in live services.
>
>         [BA]  I agree that the lack of interoperability is largely
>         "codec independent":   that is, implementations based on
>         different mechanisms for congestion control, repair, etc. will
>         exhibit interoperability problems, regardless of the codec
>         chosen.   The real test for RTCWEB will be to move beyond
>         "interoperability of implementations sharing source code"  to
>         On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand
>             [BA] Specifying an MTI encoder/decoder is not sufficient
>             for interoperability.  It is also necessary to specify the
>             transport in enough detail to allow independent
>             implementations that interoperate well enough to be usable
>             in a wide variety of scenarios, including wireless
>             networks where loss is commonly experienced. 
>
>
>         Bernard,
>
>         We have demonstrated interoperability on VP8 between Firefox
>         and Chrome, and usage of various mechanisms for congestion
>         control and repair of packet loss being applied in live services.
>
>         We made the mistake of having an MTI discussion previously
>         with not enough details on that subject, particularly with
>         respect to H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4
>         remain sketchy at best.  
>
>          
>
>         So if we are to have the discussion again, it should occur in
>         the context of detailed specifications and interoperability
>         reports.
>
>          
>
>          
>
>          
>
>          
>
>          
>
>         something we need to produce. And its one of the issues
>         holding up wider adoption of the technology (not the only one
>         for sure).
>
>          
>
>         (November in Vancouver). Cisco's open264 plugin shipped and
>         now just recently is integrated into Firefox. iOS8 shipped
>         with APIs for H264. There are other things worth noting. Will
>         this change the minds of everyone? Surely not. Will it sway
>         enough for us to achieve rough consensus? Maybe. IMHO - worth
>         finding out.
>
>          
>
>         One thing we could do instead of wasting time on MTI is to
>         actually make progress on Sections 4.2 - 4.4 of
>         draft-IETF-RTCWEB-video, so we could actually interoperate
>         regardless of the codec.
>
>
>         I would like to have an ecosystem where one can field a box,
>         connect it to everything else, and run well for *some* level
>         of "well" - and I would prefer that ecosystem to be one where
>         it's possible to field the box without making prior
>         arrangements with anyone about licenses.
>
>         discussed it. And I don't see much movement on the specifics
>         of the proposals either.
>
>         We'll have to interoperate well with the codecs we field. So
>         using some time to discuss draft-ietf-rtcweb-video seems to
>         make sense. (And 4.1 isn't finished either. There's one
>         sentence that needs to be removed.)
>
>         I wouldn't say I'd be happy to not discuss this in Honolulu.
>         But I'd prefer to re-discuss based on the knowledge that some
>         significant players have actually changed their minds.
>
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>         having, as far as

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 21 Oct 2014 09:25:54 +0200

>> would assume most open source developer or smaller software developers would

+pi

/O

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 21 Oct 2014 09:08:40 +0000

With respect to audio codecs I was replying to a question from the previous message in the thread. But...

The MTI discussion does not close the door on any codec, as any codec can be supported, just not mandatory to implement.

Your argument to eliminate H.264 only applies if you can either eliminate interworking with the rest of the world or you can persuade all those legacy devices to remove H.264 and use something else, which in my view is totally impractical.

MTI might persuade usage of that codec, but it will only do that if the MTI codec actually supports end to end communication of the required video capabilities. Neither VP8 or H.264 fit all those requirements.

Keith

________________________________
From: Justin Uberti [mailto:[email-masked]]
Sent: 20 October 2014 23:29
To: DRAGE, Keith (Keith)
Cc: Andrew Allen; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [rtcweb] Plan for MTI video codec?

>From the subject "Plan for MTI video codec", I thought this discussion was about video codecs, not AMR interop.

On Mon, Oct 20, 2014 at 7:34 AM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
The scenario where you might want to transcode the audio codec is where you have wideband audio in both the OPUS and the AMR, and you believe by transcoding you can achieve a wideband quality, rather than falling back to G.711. And for interworking between 3GPP devices that are not using webRTC, the audio will still be AMR or AMR-WB or EVC, not OPUS.

Keith

________________________________
From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrew Allen
Sent: 20 October 2014 14:52
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Chris

Andrew

From: Cavigioli, Chris [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, October 19, 2014 09:20 PM Eastern Standard Time
To: Harald Alvestrand <[email-masked]<mailto:[email-masked]>>; Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Plan for MTI video codec?

Harald said:

Chris Cavigioli

Harald said:

"Bernard,

Bernard,

Harald

rtcweb mailing list

--

---

From: Ted Hardie <[email-masked]>
Date: Tue, 21 Oct 2014 07:45:32 -0700

I would appreciate folks moving off the question of whether the video codec
discussion should be part of the agenda could change the topic.

thanks,

Ted

On Tue, Oct 21, 2014 at 2:08 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> The MTI discussion does not close the door on any codec, as any codec can
> be supported, just not mandatory to implement.
>
> Your argument to eliminate H.264 only applies if you can either eliminate
> interworking with the rest of the world or you can persuade all those
> legacy devices to remove H.264 and use something else, which in my view is
> totally impractical.
>
> MTI might persuade usage of that codec, but it will only do that if the
> MTI codec actually supports end to end communication of the required video
> capabilities. Neither VP8 or H.264 fit all those requirements.
>
> Keith
>
> *Sent:* 20 October 2014 23:29
> *To:* DRAGE, Keith (Keith)
> *Cc:* Andrew Allen; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
>
>> My expectation is that for mobile devices the RTCweb client will also
>> have access to the embedded AMR codec so mobile RTCweb devices can
>> interoperate using AMR with non-RTCweb enabled mobile IMS devices that
>> support AMR.
>>
>> For interoperation between non mobile RTCweb devices and mobile non
>> RTCweb IMS devices the non mobile RTCweb device can use G.711 to the
>> transcoder for transcoding to AMR on the other side. While not ideal this
>> will be no worse than non mobile RTCweb devices interoperating with circuit
>> switched only mobile devices which will be forced to interoperate via the
>> PSTN.
>>
>> 1.     Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to
>> by 3GPP SA4 in August 2014.  To paraphrase, performance objectives for
>> maximum VoLTE device delays in error and jitter free conditions and AMR
>> speech codec operation, the sum of the UE delays in sending and receiving
>> 3.     To put these numbers in perspective, it is in general desirable
>> to minimize UE delays to ensure low enough end-to-end delays and hence a
>> good conversational experience.  Increasing delay causes people to
>> double-talk making conversations increasingly frustrating.  Guidance to
>> stay below 400 ms maximum one-way delay is found in ITU-T Recommendation
>> G.114 and the computational E-model is in ITU-T Recommendation G.107.
>>
>>
>>

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 22 Oct 2014 19:45:40 +0000

Hi,
I have to make one correction in the light of information that has
surfaced at the MPEG meeting currently ongoing in Strasbourg.  (I’m not at
that meeting this time, but a colleague is and she briefed me.)
Nokia has made MPEG and ISO/IEC officially aware that they are not willing
to license essential patents under RAND terms.  For those with MPEG
document access, please see M34917.  The official declaration is dated
9/19/2014, and is not yet available from the respective databases, as ISO
is apparently changing its recordation infrastructure.
My understanding of the joint ITU/ISO/IEC patent policy is that no
standard can be issued that has a type 3 declaration against it.  To the
best of my knowledge, ISO has no established procedure how to deal with
type 3 (non-RAND) declarations and still keep the standard project going.
Unlike, for example, W3C and its Patent Advisory Groups.
The declaration does not list specific patents. To the best of my
knowledge, such info is not required (only desired) for ISO and IEC
standardization work--one of the few differences in patent policy
guidelines between ITU and ISO/IEC.
Therefore, I have to row back on my previous statement of likeliness of
having an ISO number for VP8 anytime soon.  At this point, I just don’t
know whether, if ever, that will happen.
Regards,
Stephan

On 10/19/14, 6:10 PM, "Stephan Wenger" <[email-masked]> wrote:

>>>>>>>>actually
>>>>>>>connect it
>>>>>>---------------------------------------------------------------------
>>>>>>-
>>>>>>--------------
>>>>>>---------------------------------------------------------------------
>>>>>>-
>>>>>>--------------
>>>-----------
>>>-----------

---

From: Mohammed Raad <[email-masked]>
Date: Thu, 23 Oct 2014 09:41:23 +0200

Hi Stephan,

The relevant section in the ISO/IEC directives
<http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-1%7Bed11.0%7Den.pdf>
is:

2.14.3 Should it be revealed after publication of a document that licences
under patent
rights, which appear to cover items included in the document, cannot be
obtained under
reasonable and non-discriminatory terms and conditions, the document shall
be referred back
to the relevant committee for further consideration.

It should be clear to participants in this discussion that not listing any
patents in a type 3 declaration makes it difficult to claim that it has
been "revealed after publication of a document that licences under patent
rights, which appear to cover items included in the document,  cannot be
obtained".

So, yes, ISO does have a way of dealing with such situations. MPEG,
specifically, has dealt with such a situation during the development of the
CDVS standard, which is a recent standard. The path chosen in that instance
was to work around the known unlicensable patent.

If one was to accept the idea that a type-3 declaration (i.e. there will be
no licensing) without being told as to what patent the claim refers to
should stop the progress of a standard, then it would be impossible to
develop any standard.

Regards,
Mohammed

-- 
Mohammed Raad, PhD.
Partner
RAADTECH CONSULTING
P.O. Box 113
Warrawong
NSW 2502 Australia
Phone: +61 414451478
Email: [email-masked]

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Thu, 23 Oct 2014 10:15:56 +0000

The GSMA white paper has been published.  Download a copy here:  http://www.gsma.com/newsroom/webrtc-codecs-draft-v1-3/

Note: Transcoding can be avoided by negotiating optional codecs and finding a matching pair.  The GSMA white paper doesn’t focus on that case, but instead specifically highlights the scenario where a pure WebRTC endpoint is communicating with a pure 3GPP LTE VoLTE/ViLTE IMS endpoint, assuming each endpoint ONLY has access to the MTI codecs in its respective domain.  In that case, the network is responsible to transcode between (Opus or G.711, <WebRTC MTI video codec TBD>) and (AMR or AMR-WB, H.264).

From: rtcweb [mailto:[email-masked]] On Behalf Of Cavigioli, Chris
Sent: Sunday, October 19, 2014 6:20 PM
To: Harald Alvestrand; Bernard Aboba
Cc: [email-masked]
Subject: Re: [rtcweb] Plan for MTI video codec?

Harald said:

Chris Cavigioli

Harald said:

"Bernard,

Bernard,

Harald

rtcweb mailing list

--

---

From: Leon Geyser <[email-masked]>
Date: Thu, 23 Oct 2014 16:57:35 +0200

In section '6 Use Cases' it seems like there isn't any transcoding required
between AMR-WB <-> EVS
Can an AMR-WB decoder decode an EVS stream?

On 23 October 2014 12:15, Cavigioli, Chris <[email-masked]>
wrote:

>  The GSMA white paper has been published.  Download a copy here:
> http://www.gsma.com/newsroom/webrtc-codecs-draft-v1-3/
>
>
>
> Note: Transcoding can be avoided by negotiating optional codecs and
> finding a matching pair.  The GSMA white paper doesn’t focus on that case,
> but instead specifically highlights the scenario where a pure WebRTC
> endpoint is communicating with a pure 3GPP LTE VoLTE/ViLTE IMS endpoint,
> assuming each endpoint ONLY has access to the MTI codecs in its respective
> domain.  In that case, the network is responsible to transcode between
> (Opus or G.711, <WebRTC MTI video codec TBD>) and (AMR or AMR-WB, H.264).
>
>
>
> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Cavigioli,
> Chris
> *Sent:* Sunday, October 19, 2014 6:20 PM
> *To:* Harald Alvestrand; Bernard Aboba
>
> *Cc:* [email-masked]
> *From:* rtcweb [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Bernard Aboba

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 23 Oct 2014 17:50:50 +0200

> http://www.gsma.com/newsroom/webrtc-codecs-draft-v1-3/

Great. And now... can we go on with WebRTC and ignore anything 3GPP/GSMA says?

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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 23 Oct 2014 08:56:19 -0700

On Thu, Oct 23, 2014 at 3:15 AM, Cavigioli, Chris <[email-masked]

> http://www.gsma.com/newsroom/webrtc-codecs-draft-v1-3/

​Note that this document claims to be confidential.  It's not clear to me
to whom, but IETF working groups are ​not limited in membership, so sharing
it with a working group is similar to making a public statement of its
availability.  Are you sure that this is the intent of the GSMA?

> domain.

​While WebRTC has re-affirmed multiple times that a mandatory-to-implement
codec is an important strategy for avoiding interoperability failure, the
negotiation of mutually acceptable codecs is far more fundamental.  You
don't get a lot of list traffic on it because it is a given.

For clients which expect to interoperate with telephony systems, the
inclusion of other codecs that assist with that interoperation would be a
far more natural strategy than relying on transcoding.  There's been
discussion of which those might be already, and we can have more.

But please realize that there is a broad variety of client use cases here
and that not all of them are in the realm of telephony.  For those, the
handheld device is not really an "IMS endpoint", it is a mobile
platform--and the choice of what to include there is not limited to the
mandatory to implement IMS codecs in any way of which I am aware.

​regards,

Ted Hardie
/wearing no hat at the moment.​

> In that case, the network is responsible to transcode between (Opus or
> G.711, <WebRTC MTI video codec TBD>) and (AMR or AMR-WB, H.264).
>
>
>

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 23 Oct 2014 17:10:41 +0000

Another correction: the MPEG doc number below is wrong (typo).  The
correct number is M34971.
Stephan

On 10/22/14, 12:45 PM, "Stephan Wenger" <[email-masked]> wrote:

>>>>>>> on VP8 at MPEG. Any news on that? I'm sharing harald's  feeling
>>>>>>>that
>>>>>>>there
>>>>>>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video,
>>>>>>>>>so
>>>>>>>>>we could

---

From: Randell Jesup <[email-masked]>
Date: Fri, 24 Oct 2014 01:11:08 -0400

On 10/20/2014 3:09 AM, Cavigioli, Chris wrote:
>
> No, not 2 discussions ... but 2 MTI codecs.
>
> Given:
>
> -Industry is polarized c. 40% VP8 vs. c. 40% H.264
>
> -Unlikely this will change
>
> -Every single mobile device (100%) of the billions out there running a 
> mobile OS (iOS, Android, Windows, BB OS, etc) will already support 
> H.264, AMR-xx since those are MTI for 3GPP and for the OS
>
> Then:
>
> -Why not support both:  VP8, Opus = web; H.264, AMR/AMR-WB = LTE
>
> -Every single mobile device and OS already deals with H.264+AMR 
> licensing for many years.
>
> -Being royalty free, incrementally adding VP8 and Opus shouldn't be a 
> major additional impact
>

I should note that many H.264 HW implementations (or the software 
driving them) in mobile devices are NOT usable for WebRTC (or for video 
communication in general).  The bugs I've seen..... <shudder>.  You can 
certify specific sets of hardware or base chipset code, but until they 
actually get tested *well* in interactive, error-recovery, variable 
bandwidth use you have no clue if they'll work.  (And without such 
testing, generally the answer would be 'no').  Can you say "IDR to 
change bitrate"?  Learn.... OMX has *many* options, most of which are 
not supported on a given implementation, which makes generic use 
'interesting' when you go past the well-traveled (and still rocky) 
decode path.

So if Mozilla distributes Firefox to Android devices, what are we to 
do?  We can't simply assume the encoder/decoder will work for WebRTC at 
this point.  Even getting streaming video decode to leverage HW decoders 
was a massive pain with whitelists, blacklists, evil device-specific 
hacks, etc.  It has gotten better over time - but not great.

I'll note that for WebRTC we currently support OpenH264 on desktop, and 
HW H.264 on specific FxOS devices/chipsets/versions (the default for 
FxOS WebRTC OMX H.264 support is false).  As of today we support only 
VP8 on Android.

And I'll echo Bernard's comments about AMR and licensing/open APIs.

<gripe> When did people forget how to edit out irrelevant repetition of 
old messages?  Ah, yes, when everyone started top-replying.... </gripe>  
Makes searching archives much less fun.  :-/

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

---

From: Adam Roach <[email-masked]>
Date: Fri, 24 Oct 2014 18:32:38 -0500

> is apparently changing its recordation infrastructure.

Thanks for the update.

That's actually even more interesting than it first appears to be. The 
official rationale previously offered by Nokia was that the refusal to 
license patents [0] for VP8 was that VP8 had not been through an 
appropriate standards process [1]. The fact that Nokia is now using 
those same patents to *block* VP8-based work from going through an 
appropriate standards process pretty clearly exposes that claim as 
false. This isn't aimed at ensuring "open and collaborative efforts for 
standardization": this is aimed at suppressing technology.

To be clear, my position remains that either VP8 or H.264 would be a 
suitable MTI, and (although not my preference) I would accept a 
situation in which both are required. Which is to say that I don't 
really have much at stake in the MTI conversation (as long as we do 
eventually do something to guarantee interop). But it does seem that 
Nokia isn't being forthcoming about its motives here, and I find that 
pretty distasteful. I would have preferred silence over lies.

> know whether, if ever, that will happen.

I find the ISO policy as stated to be curious -- if it doesn't require 
citing patents, and categorically refuses to issue specs with type 3 
declarations, I could effectively reduce the ISO output to zero by 
mechanically claiming a type 3 declaration on every specification under 
development.

/a

____
[0] For absolute clarity, I make no assertion one way or another about 
the applicability of such patents to VP8.

[1] As quoted in uncountably many publications: "Nokia believes that 
open and collaborative efforts for standardization are in the best 
interests of consumers, innovators and the industry as a whole. We are 
now witnessing one company attempting to force the adoption of its 
proprietary technology, which offers no advantages over existing, widely 
deployed standards such as H.264 and infringes Nokia's intellectual 
property. As a result, we have taken the unusual step of declaring to 
the Internet Engineering Task Force that we are not prepared to license 
any Nokia patents which may be needed to implement its RFC6386 
specification for VP8, or for derivative codecs."

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Sat, 25 Oct 2014 01:53:44 +0000

EVS supports AMR-WB functionality:
http://www.etsi.org/deliver/etsi_ts/126400_126499/126446/12.00.00_60/ts_126446v120000p.pdf

From: Leon Geyser [mailto:[email-masked]]
Sent: Thursday, October 23, 2014 7:58 AM
To: Cavigioli, Chris
Cc: Harald Alvestrand; Bernard Aboba; [email-masked]
Subject: Re: [rtcweb] Plan for MTI video codec?

In section '6 Use Cases' it seems like there isn't any transcoding required between AMR-WB <-> EVS
Can an AMR-WB decoder decode an EVS stream?

On 23 October 2014 12:15, Cavigioli, Chris <[email-masked]<mailto:[email-masked]>> wrote:
The GSMA white paper has been published.  Download a copy here:  http://www.gsma.com/newsroom/webrtc-codecs-draft-v1-3/

Harald said:

Chris Cavigioli

Harald said:

"Bernard,

Bernard,

Harald

rtcweb mailing list

--