Sapiens
19th April 2013, 23:42
I'd like to ask for some clarification from the Doom9 forumgoers regarding how vbv-maxrate and vbv-bufsize behave, specifically in relation to live streaming on sites like Twitch.tv. If possible I'd also like to get a general idea of the path data takes from the time x264 receives it to when it shows up as playback on a viewer's screen. Here is what I'm working with so far in addition to the x264 settings page on MeWiki:
https://trac.handbrake.fr/wiki/VBVRateControl
http://forum.doom9.org/showthread.php?t=147460
https://www.xsplit.com/blog.php?post_id=305
The programs being used are primarily XSplit and OBS, if that makes a difference. I'll try to type out how this is currently working in my head; it will probably be exceedingly simplistic and mostly wrong. :cool:
I have been thinking of the x264 buffer as what viewers are watching. First x264 encodes video and fills the buffer at (up to) the rate defined by vbv-maxrate, then viewers preload the buffer and away we go. If the bitrate required to achieve the quality target/crf is less than the vbv-maxrate then the buffer is able to absorb bitrate spikes for brief amounts of time.
Example: vbv-maxrate 2000 Kbps and vbv-bufsize 4000 Kbps. Initially only 1500 Kbps is required to meet the quality target and the buffer is filled at 500 Kbps (I don't know how to properly describe this... 1500 Kbps is going out, leaving 500 Kbps to accumulate each second). At some point after the buffer is full, x264 decides it needs 4000 Kbps to meet the quality target for a particularly busy scene. 4000 Kbps exits the buffer during this scene, while at the same time 2000 Kbps enters the buffer, leaving it half filled. After 1.5 seconds the buffer is "empty" and the video bitrate becomes limited to 2000 Kbps.
According to this example it seems as though the person streaming won't need more than 2000 Kbps upstream, and viewers don't need more than 2000 Kbps downstream, even if the content itself exceeds these bitrates because of the buffer.
The alternate explanation presented to me seems to be kind of inverted, and takes into account more factors like the buffer of the video player, which I conflate with the x264 buffer pretty thoroughly. Here is a quick copy and paste:
So when x264 is deciding how much data it can allocate to a given frame it must look at how full the vbv-buffer is. If the buffer is nearly empty it will have nearly no limits in the size of that frame. (limits from the buffer there are still other limits from settings).
However if the frames you have been outputing are very large (larger than maxrate in size) and your buffer is nearly full (you may never overflow the buffer) then x264 will ensure you frames are small enough to fit within the buffer. (this will cause a reduction in quality if the frame is too complex)
This will affect your bandwith by only allowing you to stream at a rate > maxrate for a limited time (determined by the size of the buffer) before you will be forece to stream at or below maxrate.
You are still actually streaming at X kbps and your viewers will need to be able to download at X kbps (or have a large enough client buffer that they can get your data spike before they run out of buffer to watch)
The client buffer should be kept as full as possible. The x264 buffer should be kept as empty as possible to allow for large spikes if you need them.
But this seems to conflict with LoRd_MuldeR's explanation (http://forum.doom9.org/showthread.php?p=1292457#post1292457)? Or I'm just grossly misinterpreting it.
Okay this is already way too long for a first post, sorry for the wall of text. Did I just quote a perfect description? Have I gone terribly wrong somewhere else? Thanks in advance for any help! :thanks:
https://trac.handbrake.fr/wiki/VBVRateControl
http://forum.doom9.org/showthread.php?t=147460
https://www.xsplit.com/blog.php?post_id=305
The programs being used are primarily XSplit and OBS, if that makes a difference. I'll try to type out how this is currently working in my head; it will probably be exceedingly simplistic and mostly wrong. :cool:
I have been thinking of the x264 buffer as what viewers are watching. First x264 encodes video and fills the buffer at (up to) the rate defined by vbv-maxrate, then viewers preload the buffer and away we go. If the bitrate required to achieve the quality target/crf is less than the vbv-maxrate then the buffer is able to absorb bitrate spikes for brief amounts of time.
Example: vbv-maxrate 2000 Kbps and vbv-bufsize 4000 Kbps. Initially only 1500 Kbps is required to meet the quality target and the buffer is filled at 500 Kbps (I don't know how to properly describe this... 1500 Kbps is going out, leaving 500 Kbps to accumulate each second). At some point after the buffer is full, x264 decides it needs 4000 Kbps to meet the quality target for a particularly busy scene. 4000 Kbps exits the buffer during this scene, while at the same time 2000 Kbps enters the buffer, leaving it half filled. After 1.5 seconds the buffer is "empty" and the video bitrate becomes limited to 2000 Kbps.
According to this example it seems as though the person streaming won't need more than 2000 Kbps upstream, and viewers don't need more than 2000 Kbps downstream, even if the content itself exceeds these bitrates because of the buffer.
The alternate explanation presented to me seems to be kind of inverted, and takes into account more factors like the buffer of the video player, which I conflate with the x264 buffer pretty thoroughly. Here is a quick copy and paste:
So when x264 is deciding how much data it can allocate to a given frame it must look at how full the vbv-buffer is. If the buffer is nearly empty it will have nearly no limits in the size of that frame. (limits from the buffer there are still other limits from settings).
However if the frames you have been outputing are very large (larger than maxrate in size) and your buffer is nearly full (you may never overflow the buffer) then x264 will ensure you frames are small enough to fit within the buffer. (this will cause a reduction in quality if the frame is too complex)
This will affect your bandwith by only allowing you to stream at a rate > maxrate for a limited time (determined by the size of the buffer) before you will be forece to stream at or below maxrate.
You are still actually streaming at X kbps and your viewers will need to be able to download at X kbps (or have a large enough client buffer that they can get your data spike before they run out of buffer to watch)
The client buffer should be kept as full as possible. The x264 buffer should be kept as empty as possible to allow for large spikes if you need them.
But this seems to conflict with LoRd_MuldeR's explanation (http://forum.doom9.org/showthread.php?p=1292457#post1292457)? Or I'm just grossly misinterpreting it.
Okay this is already way too long for a first post, sorry for the wall of text. Did I just quote a perfect description? Have I gone terribly wrong somewhere else? Thanks in advance for any help! :thanks: