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

[cowwoc <[e-mail]>]

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
>