[jitsi-dev] Questions about the bitrate in remb


#1

From the code in AimdRateControl, after the initial 5 seconds

(kInitializationTimeMs), it is using the incomingBitrate (collected in the
past second) as the bitrate in the first REMB packet to the sender. We are
using H264 and doing screenshare without camera video, and found if the
screenshare content is static in the first 5 seconds, the collected
incoming bitrate is very small (<10kbps), which causes low bitrate in the
remb packet and result in the send side bwe drop to 30k, and slowly ramping
up. With VP8, it seems much more data were sent during the static period so
the bitrate won't drop that low.

Eventually, we have to set a minimum bitrate threshold in this initial
situation to avoid sender bwe drop. I know the code is from chrome webrtc,
but what do you guys think about it? Is it reasonable to use the incoming
bitrate for the initial bitrate in the remb packets?

        // Set the initial bit rate value to what we're receiving the first
half
        // second.
        if (!bitrateIsInitialized)
        {
            if (timeFirstIncomingEstimate < 0L)
            {
                if (input.incomingBitRate > 0L)
                    timeFirstIncomingEstimate = nowMs;
            }
            else if (nowMs - timeFirstIncomingEstimate >
kInitializationTimeMs
                    && input.incomingBitRate > 0L)
            {
                currentBitrateBps = input.incomingBitRate; // we have to
make some threshold value here to avoid a very small initial
currentBitrateBps value
                bitrateIsInitialized = true;
            }
        }


#2

Hey Ethan,
Not sure there's something here to be taken upstream...I think the real
solution is probably to get some form of probing enabled (which would have
other benefits here as well) so that even when the video stream bitrate is
low, the REMB values would be more accurate. This fix seems like it would
just be a workaround so I don't know if it makes sense to take upstream.

You might also look into using 'x-google-min-bitrate' in the sdp, maybe
that could help address this too?

···

On Fri, Jan 13, 2017 at 7:04 PM, Ethan Lin <ethan@highfive.com> wrote:

From the code in AimdRateControl, after the initial 5 seconds
(kInitializationTimeMs), it is using the incomingBitrate (collected in the
past second) as the bitrate in the first REMB packet to the sender. We are
using H264 and doing screenshare without camera video, and found if the
screenshare content is static in the first 5 seconds, the collected
incoming bitrate is very small (<10kbps), which causes low bitrate in the
remb packet and result in the send side bwe drop to 30k, and slowly ramping
up. With VP8, it seems much more data were sent during the static period so
the bitrate won't drop that low.

Eventually, we have to set a minimum bitrate threshold in this initial
situation to avoid sender bwe drop. I know the code is from chrome webrtc,
but what do you guys think about it? Is it reasonable to use the incoming
bitrate for the initial bitrate in the remb packets?

        // Set the initial bit rate value to what we're receiving the
first half
        // second.
        if (!bitrateIsInitialized)
        {
            if (timeFirstIncomingEstimate < 0L)
            {
                if (input.incomingBitRate > 0L)
                    timeFirstIncomingEstimate = nowMs;
            }
            else if (nowMs - timeFirstIncomingEstimate >
kInitializationTimeMs
                    && input.incomingBitRate > 0L)
            {
                currentBitrateBps = input.incomingBitRate; // we have to
make some threshold value here to avoid a very small initial
currentBitrateBps value
                bitrateIsInitialized = true;
            }
        }

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev