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

["Cavigioli, Chris" <[e-mail]>]

Why are we debating this?  There are billions of Android devices shipped in recent years and billions of PCs shipped in recent years.  They can be programmed with apps, browsers and sw programs to support WebRTC.

From: rtcweb [mailto:[e-mail]] On Behalf Of cowwoc
Sent: Tuesday, January 14, 2014 11:35 AM
To: [e-mail]
Subject: Re: [rtcweb] There are no legacy WebRTC devices (Was: Comment on Straw Poll replies)

Hi,

Can we please make a concrete list of how many legacy devices with video encoding/decoding capability have shipped? How many of them could realistically interoperate with WebRTC? How many of them have a large enough market-share and video resolution to make them noteworthy?

Please, if your product(s) fall into this category please mention them now.

Thanks,
Gili

On 14/01/2014 9:59 AM, Cb B wrote:

On Jan 14, 2014 6:53 AM, "Cb B" <[e-mail]<mailto:[e-mail]>> wrote:
>
>
> On Jan 13, 2014 11:51 PM, "Christer Holmberg" <[e-mail]<mailto:[e-mail]>> wrote:
> >
> > 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
> >
> >
>
> You gave IMS as an example, but afaik IMS video calling is not widely deployed. Afaik, it is not deployed at scale in production at all.
>
> In fact, there may be a case that WebRTC voice and video is more widely deployed than any pure IMS 3gpp deployment.
>
> I lately noticed that Facebook now has voice and video calls without a plugin (i think..)
>
> So perhaps IMS video is not a good example of an install base since it does not exist.
>
> CB
>

I have not tested facebook video calling, so lets not discuss it.

I have also never tested IMS video calling. So lets not discuss that either unless you have a noteworthy example that is in production at scale and is worth discussing as an install base.

CB
> >
> >
> > > ________________________________________
> > > From: rtcweb [[e-mail]<mailto:[e-mail]>] on behalf of cowwoc
> > > [[e-mail]<mailto:[e-mail]>]
> > > Sent: Monday, 13 January 2014 7:48 PM
> > > To: DRAGE, Keith (Keith); [e-mail]<mailto:[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]<mailto:[e-mail]>] On Behalf Of cowwoc
> > > Sent: 10 January 2014 16:39
> > > To: [e-mail]<mailto:[e-mail]><mailto:[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]><mailto:[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]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/rtcweb