Re: [rtcweb] Transcoding

[cowwoc <[e-mail]>]

That hasn't been my experience. I am no codec expert but the transcoding 
quality I've seen was as good as the original (to the naked eye).

My main objection to transcoding is the computational cost of doing so. 
In my experience, it isn't viable to do transcoding in software on 
mobile devices (at almost any resolution) and on desktops you will run 
into problems at 720p or higher. Even if it's doable for a simple P2P 
situation, consider that for an N:N chat, the computational cost goes 
through the roof. In short, transcoding severely limits scalability and 
increases the financial cost of any solution.

Gili

On 12/01/2014 4:12 PM, cb.list6 wrote:
>
>
> On Jan 12, 2014 12:56 PM, "John Leslie" <[e-mail] 
> <mailto:[e-mail]>> wrote:
> >
> > Karl Stahl <[e-mail] <mailto:[e-mail]>> 
> wrote:
> > >
> > > [1] Transcoding VP8 ?> H.264 is very CPU intensive. Chrome with 
> VP8 on old
> > > laptops with 1 core 1.5 Ghz x86 is not even usable. Core i5 CPU is 
> fine.
> > >
> > > Even the master of transcoding, ACME Packet/Oracle said at the 
> last WebRTC
> > > conference that they will not support transcoding, leaving that to 
> others
> > > real heavy DSP cabinets.
> >
> >    (I will write an analysis _after_ the straw poll closes; but it looks
> > like that analysis will state we should consider transcoding as an
> > alternative to one-or-more MTI codecs.)
> >
> >    Transcoding _seems_ to be almost universally rejected; but this is
> > the first clear description of _why_ it's rejected.
> >
> >    Clearly, some hardware that we'd like to see participating in webRTC
> > isn't capable of transcoding at line speed. Thus, I fully agree that we
> > should reject transcoding as a requirement for _all_ webRTC devices.
> >
> >    But other hardware will surely be capable of transcoding at line 
> speed.
> > It might be painful, but we _could_ specify a "negotiate transcoding"
> > function which decided that one end does all the transcoding -- or that
> > a middleman does all the transcoding.
> >
> >    (Of course, part of the pain is the transcoding delay -- but IMHO
> > folks are pretty tolerant of lip-sync mismatch of several hundred
> > milliseconds: it's the mismatch of one second or more which is
> > unbearable.)
> >
> >    It appears _very_ likely that several browsers will support both
> > H.264 and VP8 natively; and others will be able to specify a low-
> > latecy middleman. Thus, we can hope for the normal case to be no
> > obvious transcoding delay...
> >
> >    You may flame at will...
> >
>
> I am not a codec expert.
>
> But, it is worth noting that transcoding, to the best of my knowledge, 
> substantially reduces quality. Any compression creates an 
> approximation. Transcoding is an approximation of an approximation, 
> which leads to bad quality.  So it is expensive, complex, and poor 
> quality.
>
> CB
> > --
> > John Leslie <[e-mail] <mailto:[e-mail]>>
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb