Re: [rtcweb] There are no legacy WebRTC devices (Was: Comment on Straw Poll replies)

[cowwoc <[e-mail]>]

I had a similar experience, which is why I don't expect iOS support 
anytime soon.

Gili

On 14/01/2014 1:05 PM, Steve McFarlin wrote:
> iOS has the VideoToolbox API for H.264 hardware coding, but this is a private framework. User mode applications are not allowed to create an IO channel without a Jailbreak. The framework is public in OS-X. I filed a bug report with Apple as the framework is in the public folder in the iOS SDK, but there are no headers. An engineer got back to me and said that ‘is by design’.
>
> On Jan 14, 2014, at 6:30 AM, cowwoc <[e-mail]> wrote:
>
>> Thanks for this post. It *does* help.
>>
>> My original argument revolved around #2. The only platform where I can see the possibility of WebRTC being baked into the operating system is iOS. All other operating systems are open enough that they would expose public APIs for doing this in user space. Now, in the case of iOS: do any of the devices support hardware *encoding* of H.264? If so, which iPhone/iPad versions?
>>
>> Thanks,
>> Gili
>>
>> On 14/01/2014 4:49 AM, [e-mail] wrote:
>>> Hi,
>>>
>>> There are several aspects how WebRTC compatibility or interoperability with "legacy" or non-WebRTC devices/services is relevant. I try to summarize them below since I think they have been mixed in this conversation:
>>>
>>> 1.) WebRTC interoperability with non-WebRTC endpoints or services through a gateway
>>>
>>> In this scenario we have WebRTC and WebRTC compliant devices on one side of the gateway, and for instance SIP/IMS/H.323/proprietary video conferencing equipment on the other. The gateway may need to do various translations related to e.g. ICE, DTLS-SRTP, SDP and so on, but if both sides use the same video codec, the heaviest part, i.e. the video transcoding, can be avoided.
>>>
>>> I think this is the scenario that for instance Keith and Christer have brought up in this thread, and that some people thought essential in their video codec straw poll answers. H.264 is widely used in those current non-WebRTC systems. And they are not all "legacy", but their use and deployment may grow in parallel to WebRTC.
>>>
>>> 2.) WebRTC implemented on a "legacy" or "existing" device with HW codec support
>>>
>>> This is the scenario where open API's and access to HW codecs matters. For instance most mobile devices have H.264 on HW, far fewer have VP8. It is clear that currently on many platforms there is no way for third party apps to use these codecs, so right now it does not help much. However, if and when WebRTC and real-time video become more relevant, it is possible for the platform vendors to make those codecs accessible. In that case it does matter what the HW can support.
>>>
>>> 3.) WebRTC implemented on a device that supports also other video related services and standards
>>>
>>> In this scenario WebRTC is implemented on a device (existing or future) that also supports other video services or use cases, such as 3GPP IMS video services or Wi-Fi Alliane Miracast (for streaming video over Wi-Fi to a TV screen, for instance). In this case these are all distinct apps/services that do not interoperate with each other. It is however useful the HW, OS and device vendor if all of them use the same video codec. That reduces cost (development, maintenance, possibly licensing). The abovementioned IMS and WFA standards mandate H.264, so it needs to be on devices for those services regardless of WebRTC.
>>>
>>>
>>> So, these are all different cases, and not all are equally relevant to all players. But they all show that what is called "legacy" interoperability/compatibility does matter, when it comes to video codecs. How much it matters compared to other factors (codec quality, cost etc.) is up to each individual or organization to valuate.
>>>
>>> Regards,
>>> 	Markus
>>>
>>>
>>>> -----Original Message-----
>>>> From: rtcweb [mailto:[e-mail]] On Behalf Of ext Christer
>>>> Holmberg
>>>> Sent: 14 January, 2014 09:51
>>>> To: cowwoc; DRAGE, Keith (Keith); [e-mail]
>>>> Subject: Re: [rtcweb] There are no legacy WebRTC devices (Was: Comment
>>>> on Straw Poll replies)
>>>>
>>>> Hi,
>>>>
>>>>> It doesn't matter that your legacy device can play YouTube (i.e. decode
>>>>> H.264 in a web browser). My point is that unless a legacy device can do
>>>> everything I mentioned in the top bullet points then it's not relevant to the
>>>> MTI discussion.
>>>>
>>>> I don't agree.
>>>>
>>>>>> Regarding the third bullet, it is true that gateway functionality will often
>>>> be needed to handle WebRTC specific features (continous consent etc). But,
>>>> such gateway wouldn't have to do video transcoding.
>>>>> I don't understand. I don't think that VP8 (or any other codec) as MTI
>>>> implies that you would have to transcode in the gateway.
>>>>> If we're going to talk about gateways, it's important for you to explain what
>>>> kind of devices are on either end. Please clarify.
>>>>
>>>> I think Keith gave IMS based networks/devices as an example, so I'll echo
>>>> him.
>>>>
>>>> But, of course the networks/devices on the other side could also be non-IMS
>>>> SIP networks.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>
>>>>> ________________________________________
>>>>> From: rtcweb [[e-mail]] on behalf of cowwoc
>>>>> [[e-mail]]
>>>>> Sent: Monday, 13 January 2014 7:48 PM
>>>>> To: DRAGE, Keith (Keith); [e-mail]
>>>>> Subject: [rtcweb] There are no legacy WebRTC devices (Was: Comment on
>>>>> Straw Poll replies)
>>>>>
>>>>> Keith,
>>>>>
>>>>> Even if we mandate H.264 and SDP as MTI, how in the world do you expect
>>>> RTCWEB to be interoperable with existing video equipment? I just don't get
>>>> this argument.
>>>>> As far as I can tell, the market share of devices that:
>>>>>
>>>>>     *   Encode/decode H.264 in hardware *and* expose public APIs for doing
>>>> so,
>>>>>     *   Understand SDP,
>>>>>     *   Are WebRTC compliant
>>>>>
>>>>> is exactly zero. There is no way that legacy devices will magically begin
>>>> supporting WebRTC. This will require *new* products to get released.
>>>>> Gili
>>>>>
>>>>> On 13/01/2014 9:47 AM, DRAGE, Keith (Keith) wrote:
>>>>> Legacy interoperability is important to some of us.
>>>>>
>>>>> It is not about preserving our existing equipment.
>>>>>
>>>>> It is about the fact the communication involves two or more parties, and
>>>> we want to enable video communication between RTCWEB user and the rest
>>>> of the entities in the world that are capable of video, without having to resort
>>>> to transcoding video on all calls. Yes transcoding is possible, but it has a cost
>>>> that someone will have to pay for, and it introduces delay, which can be
>>>> catered for, but removes the possibility of someone else in the call path
>>>> using that delay portion.
>>>>> Currently there are a considerable number more of those users using
>>>> legacy systems than there are using RTCWEB.
>>>>> Keith
>>>>>
>>>>> ________________________________
>>>>> From: rtcweb [mailto:[e-mail]] On Behalf Of cowwoc
>>>>> Sent: 10 January 2014 16:39
>>>>> To: [e-mail]<mailto:[e-mail]>
>>>>> Subject: Re: [rtcweb] Comment on Straw Poll replies
>>>>>
>>>>> On 10/01/2014 9:54 AM,
>>>> [e-mail]<mailto:[e-mail]>
>>>> wrote:
>>>>> Can I ask why you even bother with WebRTC, if you want to restrict
>>>> WebRTC to interoperability with old systems only and therefore to old
>>>> features only?
>>>>> I'd like to suggest that such replies should be disregarded because they
>>>> look backwards and not forwards.
>>>>> I don't think that disregarding replies is a constructive way forward.
>>>>>
>>>>> However if you want to go that way, and if you want to get rid of old
>>>> technologies, let's start by disregarding replies from those who could live
>>>> with a WebRTC technology that would specify H.261 as only  MTI codec.
>>>>> Given your concerns about "old" systems and "od" features, I'm a little bit
>>>> surprised that your are part of them.
>>>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg10798.html
>>>>> (note that there is G.711 for audio but NOT as ONLY MTI codec)
>>>>>
>>>>>
>>>>> This is a fallacy. No one is arguing that you should be stuck with using *just*
>>>> H.261. What we are saying is that: if H.264 or VP8 are available on both end-
>>>> points, great. If not, you can either:
>>>>>     *   Use H.261, or
>>>>>     *   Transcode, or
>>>>>     *   Drop Video
>>>>>
>>>>> By eliminating H.261 as MTI, you lose the first option and are forced to
>>>> either transcode or drop video. The cost to supporting H.261 is as simple as
>>>> compiling https://github.com/Vproject/p64 and popping it on your device.
>>>> You don't need hardware support because it's so computationally cheap.
>>>>> And finally, we're not objecting to the use of H.264, per se, but rather to
>>>> the fact that the majority of people who vote for it and against everything
>>>> else use "legacy interoperability" as argument.
>>>>> WebRTC is a *new* technology. If all we wanted to do was to support
>>>> *existing* devices then we would use *existing* technologies. For that
>>>> reason, I don't think maintaining backwards compatibility is important when
>>>> breaking it has a noticeable benefit (and in this case, I believe it does).
>>>>> Alternatively, please convince MPEG-LA to make H.264 available royalty-
>>>> free.
>>>>> Gili
>>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb