[rtcweb] FEC -- was Re: Plan for MTI video codec?

[Ca By <[e-mail]>]

On Sunday, October 19, 2014, Bernard Aboba <[e-mail]> wrote:

> 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
>
> Bernard,

Regarding packet loss in wireless networks and FEC,  can you be more
specific?

It would be best if this problem was clearly articulated. Afaik, various
flavors of 802.11 as well as UMTS and LTE all support L2 FEC. And, in the
case of UMTS and LTE , all packets are retransmitted until the end point
acknowledges the packet has been received.

That said, it would be imprudent to put those functions again into L4 or
L7.

CB

> 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 <
> [e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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
>> 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 <[e-mail]
>> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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 <
>>> [e-mail]
>>> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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 <
>>>> [e-mail]
>>>> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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.
>>>>>
>>>>> 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 <
>>>>> [e-mail]
>>>>> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> wrote:
>>>>>
>>>>>> 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 <
>>>>>> [e-mail]
>>>>>> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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 <
>>>>>>> [e-mail]
>>>>>>> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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 <
>>>>>>>>>> [e-mail]
>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','[e-mail]');>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>  On 16 October 2014 14:17, Matthew Kaufman <[e-mail]
>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> wrote:
>>>>>>>>>>> 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)
>>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> rtcweb mailing list
>>>>>>>>>> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> rtcweb mailing list
>>>>>>>>> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> rtcweb mailing list
>>>>>>>> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Alex. Gouaillard, PhD, PhD, MBA
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------------
>>>>>>> CTO - Temasys Communications, S'pore / Mountain View
>>>>>>> President - CoSMo Software, Cambridge, MA
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------------
>>>>>>> sg.linkedin.com/agouaillard
>>>>>>>
>>>>>>>    -
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> rtcweb mailing list
>>>>>>> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jonathan Rosenberg, Ph.D.
>>>>>> [e-mail]
>>>>>> <javascript:_e(%7B%7D,'cvml','[e-mail]');>
>>>>>> http://www.jdrosen.net
>>>>>>
>>>>>> _______________________________________________
>>>>>> rtcweb mailing list
>>>>>> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Alex. Gouaillard, PhD, PhD, MBA
>>>>
>>>> ------------------------------------------------------------------------------------
>>>> CTO - Temasys Communications, S'pore / Mountain View
>>>> President - CoSMo Software, Cambridge, MA
>>>>
>>>> ------------------------------------------------------------------------------------
>>>> sg.linkedin.com/agouaillard
>>>>
>>>>    -
>>>>
>>>>
>>>
>>>
>>> --
>>> Jonathan Rosenberg, Ph.D.
>>> [e-mail]
>>> <javascript:_e(%7B%7D,'cvml','[e-mail]');>
>>> http://www.jdrosen.net
>>>
>>
>>
>>
>> --
>> Alex. Gouaillard, PhD, PhD, MBA
>>
>> ------------------------------------------------------------------------------------
>> CTO - Temasys Communications, S'pore / Mountain View
>> President - CoSMo Software, Cambridge, MA
>>
>> ------------------------------------------------------------------------------------
>> sg.linkedin.com/agouaillard
>>
>>    -
>>
>>
>