How does webrtc select the encoding bitrate

[acid weak]

Through printing the target bitrate in send_side_bandwidth_estimation.cc(CapToThreshold), I found that there are many values in one second. Since there are so many values, how can I figure out which value is truely used by the encoder?

Is the encoder periodically select one value when there is a frame or there is other more complex logic?

I am eager to figure out this thing, waiting for your guidance!

[Alexandre GOUAILLARD]

First, you have to separate bandwidth estimation, from bandwidth usage policy, and actual bandwidth usage.

Let's say you are using a simple encoder (non simulcast, non-svc),

let's say you are using only one track per stream, per peerconnection,

First you need to evaluate how much bandwidth you have. It's the role of the Bandwidth Estimation algorithms, usually based on the RTCP reports. In the code right now you have sender-side BWE, receiver-side BWE, Google-CC, and BBR. By default you should be using Google-CC. It gives you a "Bandwidth budget". This is what you are looking at right now.

This pipe into a bitrate_allocator_observer, which is going to .. well .. observe the values given by the BWE at certain times, and provide that value to the internal::VideoSendStream. This class is a high level class to aggregate all the other needed classes: bitrate allocator, transport, FEC, .... It also proxies message from each module, for example, it can ask the video source to reduce spatial resolution or drop frames, as part of the adaptation. RTP headers take some bandwidth, but this value is constant, while FEC take some bandwidth dynamically. There is a FEC_Controller attached which is going to provide in real time the bandwidth used by FEC message to be subtracted from the Bandwidth budget to have the actual usable bandwidth for the RTP packet. RTP headers are then taken into account, and the bandwidth for the payload (the codec output) is computed and given to the encoder.

Everything related to encoder is pushed down to VideoSendStreamImpl then to VideoStreamEncoder. This last class use the provided VideoEncoderFactory to create a VideoEncoder of the proper type (say VP8), and pass the bitrate constraints to it.

It's slightly oversimplified, but it should help you go directly to the right classes.

Hope this helps.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/081202aa-4f9f-439b-a1ea-a2c9211c47d6%40googlegroups.com.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

President - CoSMo Software Consulting, Singapore

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[acid weak]

Thank you very much for your simple but clear description. This helps me figure out the flow of the codes. By adding some "printf" in the SetEncoderParameters() of modules/video_coding/video_sender.cc I found that the encoder is updated around 30-40ms as shown in the following picture.This is the result by using the peerconnenction_client provided by the default compile, Is this the right frequency in the real condition?

 
在 2019年12月3日星期二 UTC+8下午5:20:38，Alexandre GOUAILLARD写道：

First, you have to separate bandwidth estimation, from bandwidth usage policy, and actual bandwidth usage.

Let's say you are using a simple encoder (non simulcast, non-svc),

let's say you are using only one track per stream, per peerconnection,

First you need to evaluate how much bandwidth you have. It's the role of the Bandwidth Estimation algorithms, usually based on the RTCP reports. In the code right now you have sender-side BWE, receiver-side BWE, Google-CC, and BBR. By default you should be using Google-CC. It gives you a "Bandwidth budget". This is what you are looking at right now.

This pipe into a bitrate_allocator_observer, which is going to .. well .. observe the values given by the BWE at certain times, and provide that value to the internal::VideoSendStream. This class is a high level class to aggregate all the other needed classes: bitrate allocator, transport, FEC, .... It also proxies message from each module, for example, it can ask the video source to reduce spatial resolution or drop frames, as part of the adaptation. RTP headers take some bandwidth, but this value is constant, while FEC take some bandwidth dynamically. There is a FEC_Controller attached which is going to provide in real time the bandwidth used by FEC message to be subtracted from the Bandwidth budget to have the actual usable bandwidth for the RTP packet. RTP headers are then taken into account, and the bandwidth for the payload (the codec output) is computed and given to the encoder.

Everything related to encoder is pushed down to VideoSendStreamImpl then to VideoStreamEncoder. This last class use the provided VideoEncoderFactory to create a VideoEncoder of the proper type (say VP8), and pass the bitrate constraints to it.

It's slightly oversimplified, but it should help you go directly to the right classes.

Hope this helps.

On Tue, Dec 3, 2019 at 8:42 AM acid weak <weakac...@gmail.com> wrote:

Through printing the target bitrate in send_side_bandwidth_estimation.cc(CapToThreshold), I found that there are many values in one second. Since there are so many values, how can I figure out which value is truely used by the encoder?

Is the encoder periodically select one value when there is a frame or there is other more complex logic?

I am eager to figure out this thing, waiting for your guidance!

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/081202aa-4f9f-439b-a1ea-a2c9211c47d6%40googlegroups.com.

--