Subject: [rmcat] SCReAM, discussion topics

From: Ingemar Johansson S <[email-masked]>
Date: Sat, 7 Nov 2015 20:35:36 +0000

Hi

Listened in on the recording from the RMCAT session of Friday. Two topics took some extra time during the SCReAM presentation.

1)      RTP and Network queue delay

2)      Video coder rate change delay

Possibly it all became clear during the presentation, if not here an attempt to explain it a bit further

RTP and Network queue delay: Yes, it is true that the resulting video frame delay is some kind of convolution of the network and RTP queue delay. I would not however use the data available from the SCReAM logs in order to get a measure of the total video frame delay. For instance the RTP queue delay is actually an estimated RTP queue delay that is based on the size of the RTP queue divided by the estimated throughput, moreover the delay is logged only every 200ms.  To get a true video frame delay, it is instead better to compare the wall clock time on the receiver side with the RTP timestamp.
Xiaoqing (?) mentioned that if the RTP queue delay becomes too large then one may as well discard (some of) the RTP packets that are queued up on the sender side. That is true and have been mentioned in the draft a long while, the OpenWebRTC implementation discards all packets in the RTP queue when the estimated RTP queuing delay exceeds 1 second. The RTP stack will then arrange with a FIR to restore the video context.

Video coder rate change delay: The problem with a slow video coder rate control loop is that one can easily end up in the situation where a controller is considerably faster than the system under control (see scary example what can happen https://www.youtube.com/watch?v=k6yVU_yYtEc). At least in theory it should be possible to derive a tolerable rate increase, given the knowledge about the sluggishness in the video coder rate control loop, and avoid getting into or too close to instability. Need to admit though that my control theory skills are a bit rusty, furthermore systems may be too non-linear for simple analysis.
In any case, as graphs on page 9 show, it helps to reduce the RAMP_UP_SPEED in SCReAM if the video coder control loop is slow. A faster video rate control loop of course makes it possible to increase the RAMP_UP_SPEED, for instance I recall that openh264  has a faster rate control loop than VP8 so it could be a configuration issue (if possible to configure)
My opinion here is that this is not only a SCReAM problem, the underlying problem with the control of slow systems is a general problem, and I would say one should expect to see these issues with other algorithms as as well.

/Ingemar

=================================
Ingemar Johansson  M.Sc.
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com

"Telegraph sang a song
 about the world outside"
    dIRE<http://www.brainyquote.com/quotes/authors/a/abraham_lincoln.html> sTRAITS
=================================