Re: [rtcweb] Comment on Straw Poll replies

In those terms, I do not believe that is what they were showing, at least according to the reports I have seen.

Further, apart from any processing power, the critical issue is the delay involved in any conversion, and I have no figures for that from this demonstration, and I suspect you do not either. Given that you must receive frames to do the conversion, my belief is that we will still be talking both decode and encode delay at the conversion point of the order of 60 - 70 ms, whatever mechanism is used. That is a significant take from the limits specified in ITU Recommendation G.114.

Regards

Keith

> -----Original Message-----
> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] 
> Sent: 14 January 2014 01:17
> To: DRAGE, Keith (Keith)
> Cc: cowwoc; rtcweb@ietf.org
> Subject: Re: [rtcweb] Comment on Straw Poll replies
> 
> For all those concerns, please remember that Zingaya 
> showcased a H.264 and VP8 real-time video conversion without 
> transcoding. That to me shows that we may all be 
> over-estimating the complexity involved in transcoding 
> between H.264 and VP8.
> 
> Cheers,
> Silvia.
> 
> 
> On Tue, Jan 14, 2014 at 1:47 AM, DRAGE, Keith (Keith) 
> <keith.drage@alcatel-lucent.com> 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:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
> > Sent: 10 January 2014 16:39
> > To: rtcweb@ietf.org
> > Subject: Re: [rtcweb] Comment on Straw Poll replies
> >
> > On 10/01/2014 9:54 AM, stephane.proust@orange.com 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
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> 