Re: [rtcweb] rtcweb Digest, Vol 35, Issue 86

[cowwoc <[e-mail]>]

Michael,

The results are already out. See 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11084.html

Gili

On 14/01/2014 3:03 PM, Michael Adeyeye, PhD wrote:
> Hi Everyone,
> Is there ever going to be a full report on the outcome of the poll? Or 
> would the outcome only be available during the next IETF meeting in 
> London?
> Some of us would have loved to participate in the poll but we're not 
> included in it. Notwithstanding, we have seen some of the WG members 
> share similar views with us w.r.t. the de-facto codec(s) for WebRTC.
> We are looking forward to the report.
> Regards.
> Michael
>
> > On 14 January 2014 at 20:32 [e-mail] wrote:
> >
> >
>
> > On 14 January 2014 at 19:00 Steve McFarlin <[e-mail]> wrote:
> >
> >
> > It looks like Blackberry has API's for H.264 encoding/decoding [1], 
> and windows phone also looks like it may have API's (I don't have 
> enough time to really look) [2].
> >
> >
> > [1] 
> http://developer.blackberry.com/native/reference/core/com.qnx.doc.camera.lib_ref/topic/manual/camera_h264avc.h_enums_overview.html 
>
> >
> > [2] 
> http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.phone.media.capture.h264encoderprofile(v=vs.105).aspx 
>
> >
> >
> > On Jan 14, 2014, at 6:15 AM, cowwoc <[e-mail]> wrote:
> >
> >
> > > I stand corrected: 
> http://developer.android.com/guide/appendix/media-formats.html
> > >
> > > Both H.264 and VP8 encoder/decoders are supported. Thanks for 
> catching that.
> > >
> > > I'm still curious if anyone has seen a public API for hardware 
> encoding/decoding of video outside of Android...
> > >
> > > Gili
> > >
> > > On 13/01/2014 11:04 PM, Eric Rescorla wrote:
> > >
> > > > > On Mon, Jan 13, 2014 at 6:13 PM, cowwoc 
> <[e-mail]> wrote:
> > > >
> > > > > > > To date, Android is the only operating system that I've 
> come across which
> > > > > exposes a public API for hardware video encoding/decoding, but 
> it only
> > > > > supports hardware encoding for VP8.
> > > > >
> > > > > > > Can you please provide a reference for this claim? That 
> does not match
> > > > my understanding.
> > > >
> > > > -Ekr
> > > >
> > > > > _______________________________________________
> > > rtcweb mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> > >
>
> > On 14 January 2014 at 19:05 Steve McFarlin <[e-mail]> 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
> >
> >
>
> > On 14 January 2014 at 20:31 cowwoc <[e-mail]> wrote:
> >
> >
> > 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
> >
> >
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb