you're confused about the first part. the send buffer is not tied with the video encoder buffer size it is currently tied with the bitrate value (the max send buffer is static based on that value in bytes and the bitrate is of course always variable even with cbr) for the simplicity of the matter + another 128 kbps 16384 bytes of the audio for a total of 400384 that is sent in memory piece's from 1024 bytes up to a multiple of it to the next layer then the windows tcp layer. story short you don't want that big of a buffer (for a what it's supposed to be around 3mbps semi constant speed usage) on a small latency tcp connection because its beats the purpose of using tcp, you can only use it if latency is there as a factor.. and don't confuse this with the old send buffer value from the older code. obs now uses window's AFD as an additional layer that helps tons with the frame drop code.Bensam123 said:max bitrate: 3000
buffer size: 3000
I'm unsure, but it seems as though you're trying to confuse me by changing kilobits to bytes as a traditional buffers size is in kilobits per second... 3000 or 4000 isn't too high for a bit rate of 3000. I use a buffer of 5000 with a bit rate of 3100. A large buffer isn't actually bad and will generally allow you to stream a more consistent stream, since bit rate is variable (unless you have CBR selected).
Most stream providers don't allow you to use large buffers though. Good blog on it here:
https://www.xsplit.com/blog.php?post_id=305
All a larger buffer would do is increase the amount of time it takes for content to get to a provider like twitch. People can't tell the difference as they have no way of knowing how long it takes for your stream to get to twitch beyond how long it takes for you to respond to chat.
"Really bad" isn't a very descriptive way of saying why it's bad.
if he had let's say a 70mbps upload that buffer would be perfect at latency of 50ms assuming that nothing is restricted