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

["Michael Adeyeye, PhD" <[e-mail]>]

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