Re: [rtcweb] Transcoding

["Espen Berger (espeberg)" <[e-mail]>]

Comments inline. 

-----Original Message-----
From: John Leslie [mailto:[e-mail]] 
Sent: 15. januar 2014 15:11
To: Espen Berger (espeberg)
Cc: [e-mail]
Subject: Re: [rtcweb] Transcoding

Espen Berger (espeberg) <[e-mail]> wrote:
> 
> Comments on transcoding based on testing in lab and research. 

   :^)

> *  In side by side comparison, single encode/decode and
>    encode/transcode/decode we can see that the untranscoded video
>    stream can be 20-35% lower bitrate and give the same visual quality...

   This tradeoff will be acceptable in many cases, IMHO.

> * Lip-sync should be within 50 ms, this is the conclusion from a
>   Norwegian based ph.d student and also recommendation from EBU...

   The EBU document discusses HDTV programming (and indeed recommends audio no more than 5 msec early or 15 msec late). They claim to base this on failure of lip-sync becoming "perceptable to 50% of observers".

EBE>> The section I read was overall lip-sync at playout time should not exceed -40 to +60 ms offset. This is also in line with the PH.d work I have seen. 

   The 50 msec number seems plausible, but I have no basis to judge.

   Lip-sync can always be accomplished by delaying one or the other:
this gives us a trade-off (which I'd prefer to be under application control).
EBE>> Robust lip-sync should happen at the playout step, to handle various latency differences between audio and video related to transport, jitter buffer handling, decode or playout.  

> * Advanced media resilience techniques like LTRF, disposable frames
>   and more are hard to map between different video codecs, so
>   transcoding will likely reduce robustness for packet loss. 

   (discussed elsewhere)

> * Transcoding adds delay, between 60 - 200 ms  (depending on packet
>   loss and implementation).

   I have no basis to judge those numbers; but they seem high.
EBE>> I do not have a break down of what take time, but encoding of 1080p60 video takes a fair amount of time even on modern  CPU architecture. The longer delays are typically to handle receiver based packet loss and/or packet out-of-order, which is impacting your jitter buffer handling.  My point with transcoding overhead is packet re-ordering might have a higher impact in latency than the actual CPU time to do a decode+encode. 

>   This has an impact since camera to screen latency should be below
>   300 ms to get a smooth conversation between to participants in a
>   video call. Test on people shows that glass to glass latency
>   should be below 330 ms, to avoid latency to be noticed.  

   Do you have a source for that?

   My gut-feel is that folks will tolerate at least 200 msec glass-to- glass, but have problems when mouth-to-ear exceeds 150 msec. Alas I don't have a source for that... :^(

EBE>> Unfortunately,  I cannot find an online source for my statement. 

> All in all we should avoid transcoding for video conferencing use 
> cases to get to a good user experience.

   I quite agree it's worth "avoiding" -- but that's not at all the same as saying we should try to prevent it.

EBE>> Nothing is preventing us from doing transcoding here, it's more that transcoding has impact. 

--
John Leslie <[e-mail]>