Subject: [rmcat] SCReAM status and way forward

From: "Ralf Globisch" <[email-masked]>
Date: Tue, 31 May 2016 21:13:28 +0200

Ingemar, for what it's worth, I forked the SCReAM code on github and integrated it into an RTP library.
I ran some preliminary tests streaming video over my home ADSL line, but often found that the algorithm
struggled to stream at higher rates than the minimum (in my case I used 50kbps as the minimum). 
If I understand correctly, the algorithm is designed for use over mobile networks and not ADSL though. 
If you're interested, perhaps we could investigate the behaviour of the algorithm on other network types, etc.
It could be that some fine-tuning, etc is needed to make it work in such cases. Of course it could also be,
that I was not using your code as intended...

R.

> Q3:
> Running code for SCReAM has been published quite a while ago, both as a
> standalone implementation and as a part of OpenWebRTC, I have however not
> seen any reaction or questions or other signs that indicate that this is of
> interest to this group. Has anybody looked at this code, experimented with
> it, or integrated it in one form or the other ?. Does anybody plan to do
> anything with the code ?

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

Please consider the environment before printing this email.

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 1 Jun 2016 06:58:38 +0000

Hi Ralf

And thanks for the effort, worth a lot. 

I assume that you have used the C++ code
(https://github.com/EricssonResearch/scream) in your implementation?

50kbps is a very low bitrate for video, there are a few things that can
cause extra trouble. 

+ RTCP overhead. At bitrates this low it is sufficient with feedback
intervals around 200ms, furthermore reduced size RTCP (RFC5506) is highly
recommended, this will give you an RTCP overhead of ~3-5kbps, so a
recommendation is that you have a look at how much bandwidth RTCP consumes.
Is reduced size RTCP implemented in your RTP library ?, it is implemented in
the GStreamer libraries if you wish to have a look at how it is done.

+ RTP overhead. The function getTargetBitrate has a comment in the header
file

    /*

    * Get the target bitrate for stream with SSRC

    * NOTE!, Because SCReAM operates on RTP packets, the target bitrate will

    *  also include the RTP overhead. This means that a subsequent call to
set the 

    *  media coder target bitrate must subtract an estimate of the RTP +
framing 

    *  overhead. This is not critical for Video bitrates but can be
important 

    *  when SCReAM is used to congestion control e.g low bitrate audio
streams

    */

   This means that, if the size argument in the addTransmitted function
includes also the size of the RTP header (+ possible extensions) then the
computed bitrate is the bitrate with the RTP overhead included. This means
that you need to subtract the bitrate given by the RTP overhead when you
compute the video coder bitrate. The function to compute the video coder
bitrate is thus.

videoBitrate = getTargetBitrate(..)+rtpOverheadBitrate.

  A somewhat better alternative, used in the OpenWebRTC implementation is to
use the RTP payload size as input to the addTransmitted(..) function.

+ Video coder output. My grim experience is that the video coder does not
always output the desired target bitrate, variations around the target
bitrate is natural but in some cases I have seen that the output bitrate is
consistently 10-20% above the target bitrate, for that reason it could be
good to compute and log the video coder output bitrate. In some cases the
video coders are in a non-rate adaptive mode or have the internal rate
control tuned too slow, this is a tuning matter. I have fiddled a bit with
OpenH264 and VP8, which video codec do you use ?

I have only tried out these low bitrates with the experimental code, the
code is adapted for audio streaming so it should not be any problems to
congestion control video  over 50kbps bottlenecks. 

With the OpenWebRTC implementation I managed to push down the bottleneck
bitrate down to 200kbps. The problem there is that I did not have full
control over the RTP stack and that RTCP tended to consume too much
bandwidth.

That said, there are probably some yet to discover issues, it is not too
unlikely that you have found an issue in  SCReAM but one probably need to
rule out the  possible issues above before. 

Is your fork available somewhere ?, could be interesting to try it out as
you have integrated it into an RTP library.

Regards

Ingemar

"Ralf Globisch" <[email-masked]> Tue, 31 May 2016 19:14 UTC
<https://mailarchive.ietf.org/arch/search/?email_list=rmcat> Show header

Ingemar, for what it's worth, I forked the SCReAM code on github and
integrated it into an RTP library.
I ran some preliminary tests streaming video over my home ADSL line, but
often found that the algorithm
struggled to stream at higher rates than the minimum (in my case I used
50kbps as the minimum). 
If I understand correctly, the algorithm is designed for use over mobile
networks and not ADSL though. 
If you're interested, perhaps we could investigate the behaviour of the
algorithm on other network types, etc.
It could be that some fine-tuning, etc is needed to make it work in such
cases. Of course it could also be,
that I was not using your code as intended...