VBR Rate Control Methods Ignored - Windows 32.1.2

M

Mudkips

New Member
I'm on Windows 10 22H2 and lately I've noticed my VBR settings are being ignored when streaming.
When simply recording, it works fine.

It doesn't seem to matter if I use the AMD AMF hardware encoder or software. It doesn't seem to matter which VBR rate control method I use.
When streaming, even if I choose to ignore the streaming platform's settings, my stream is set to CBR. It used to properly work with VBR rate control methods (I've used VBR_LAT, VBR, and HQVBR or QVBR previously). Trying various other settings seems to have no effect - pre-analysis on/off, keyframe interval 0 (auto), 1, or 2, bitrate, etc.

Even when streaming a black screen, it uses up whatever I set - 12000 Kbps, 15000 Kbps, etc.
When recording and telling the recording options to not use the same settings as the stream encoder, I don't have this problem. The recording properly drops down very low on static scenes, under 1000 Kbps. When I have the recording encoder settings set to match the stream encoder settings the issue returns, even if I'm not streaming.

Any ideas? I know some people cling to the idea that you should stream in CBR, but I find it to be a huge waste of bandwidth. The encoder should be allowed to save bits when it makes sense, and I've never had any issues with that in the past.

Here's a log excerpt of a basic recording working and respecting the HQVBR rate control method, but a stream to YouTube being initialized as CBR despite my settings saying to use HQVBR. It seems from the log that OBS or FFMPEG tries to switch to HQVBR as specified in my stream settings, but fails to because the stream is already initialized.

This also happens with software x.264, so I don't think it's an AMF issue, but I haven't thoroughly re-tested x.264 streaming and captured logs to prove it here.

Thanks

Code: 
01:21:39.550: [texture-amf-h265: 'advanced_video_recording'] Original base default settings were used according to resolution and framerate.
01:21:39.554: [texture-amf-h265: 'advanced_video_recording'] settings:
01:21:39.554:     rate_control: HQVBR
01:21:39.554:     bitrate:      12000
01:21:39.554:     cqp:          20
01:21:39.554:     keyint:       120
01:21:39.554:     preset:       quality
01:21:39.554:     profile:      main
01:21:39.554:     level:        5
01:21:39.554:     width:        2560
01:21:39.554:     height:       1440
01:21:39.554:     pre-analysis: true
01:21:39.554:     params:       (none)
01:21:39.559: ---------------------------------
01:21:39.559: [FFmpeg aac encoder: 'Track1'] bitrate: 160, channels: 2, channel_layout: stereo, track: 1
01:21:39.559:
01:21:39.567: ==== Recording Start ===============================================
01:21:39.567: [mp4 output: 'adv_file_output'] Writing Hybrid MP4/MOV file 'C:/Users/...../Desktop/2026-07-18 01-21-39.mp4'...
01:21:51.453: [mp4 muxer: 'adv_file_output'] Flushing final fragment...
01:21:51.454: [mp4 muxer: 'adv_file_output'] Number of fragments: 6
01:21:51.454: [mp4 muxer: 'adv_file_output'] Full moov size: 6 KiB
01:21:51.454: [mp4 muxer: 'adv_file_output'] Final mdat size: 1058 KiB
01:21:51.454: Output 'adv_file_output': stopping
01:21:51.454: Output 'adv_file_output': Total frames output: 698
01:21:51.454: Output 'adv_file_output': Total drawn frames: 713
01:21:51.454: [mp4 output: 'adv_file_output'] Waiting for file writer to finish...
01:21:51.454: [mp4 output: 'adv_file_output'] File output complete. Finalization took 1 ms.
01:21:51.458: ==== Recording Stop ================================================
01:22:05.113: Uploading thumbnail file "C:/Users/...../Desktop/Generic.jpg"...
01:22:09.508: User is ignoring service bitrate limits.
01:22:09.508: Service Recommendations:
01:22:09.508:     video bitrate: 51000
01:22:09.508:     audio bitrate: 160
01:22:09.549: [texture-amf-h265: 'advanced_video_stream'] Original base default settings were used according to resolution and framerate.
01:22:09.553: [texture-amf-h265: 'advanced_video_stream'] settings:
01:22:09.553:     rate_control: CBR
01:22:09.553:     bitrate:      12000
01:22:09.553:     cqp:          20
01:22:09.553:     keyint:       120
01:22:09.553:     preset:       quality
01:22:09.553:     profile:      main
01:22:09.553:     level:        5
01:22:09.553:     width:        2560
01:22:09.553:     height:       1440
01:22:09.553:     pre-analysis: true
01:22:09.553:     params:       (none)
01:22:09.558: ---------------------------------
01:22:09.558: [FFmpeg aac encoder: 'adv_stream_audio'] bitrate: 160, channels: 2, channel_layout: stereo, track: 1
01:22:09.558:
01:22:09.558: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmps://a.rtmps.youtube.com:443/live2...
01:22:09.561: [rtmp stream: 'adv_stream'] Interface: Intel(R) I211 Gigabit Network Connection #2 (ethernet, 1000↓/1000↑ mbps)
01:22:09.561: [rtmp stream: 'adv_stream'] Interface has non-zero error counters (80/0 errors, 160/0 discards)
01:22:09.561: encoder 'advanced_video_stream': Cannot apply a new video_t object after the encoder has been initialized
01:22:09.561: encoder 'advanced_video_stream': Cannot set the scaled resolution after the encoder has been initialized
01:22:09.561: encoder 'advanced_video_stream': Cannot enable GPU scaling after the encoder has been initialized
01:22:09.600: [texture-amf-h265: 'advanced_video_recording'] Original base default settings were used according to resolution and framerate.
01:22:09.604: [texture-amf-h265: 'advanced_video_recording'] settings:
01:22:09.604:     rate_control: HQVBR
01:22:09.604:     bitrate:      12000
01:22:09.604:     cqp:          20
01:22:09.604:     keyint:       120
01:22:09.604:     preset:       quality
01:22:09.604:     profile:      main
01:22:09.604:     level:        5
01:22:09.604:     width:        2560
01:22:09.604:     height:       1440
01:22:09.604:     pre-analysis: true
01:22:09.604:     params:       (none)
01:22:09.608: ---------------------------------
01:22:09.608: [FFmpeg aac encoder: 'Track1'] bitrate: 160, channels: 2, channel_layout: stereo, track: 1
01:22:09.608:
01:22:09.615: ==== Replay Buffer Start ===========================================
01:22:09.869: [rtmp stream: 'adv_stream'] Connection to rtmps://a.rtmps.youtube.com:443/live2 (2607:f8b0:4007:803::200c) successful
01:22:09.870: [rtmp stream: 'adv_stream'] Socket send buffer is 65536 bytes
01:22:09.874: ==== Streaming Start ===============================================
01:22:28.360: Output 'Replay Buffer': stopping
01:22:28.360: Output 'Replay Buffer': Total frames output: 1110
01:22:28.360: Output 'Replay Buffer': Total drawn frames: 1125
01:22:28.361: ==== Replay Buffer Stop ============================================
01:22:28.380: [rtmp stream: 'adv_stream'] User stopped the stream
01:22:28.380: [rtmp stream: 'adv_stream'] Socket send buffer is 262144 bytes
01:22:28.380: Output 'adv_stream': stopping
01:22:28.380: Output 'adv_stream': Total frames output: 1096
01:22:28.380: Output 'adv_stream': Total drawn frames: 1129
01:22:28.384: ==== Streaming Stop ================================================
 
VBR is not a Rate Control that I use so I can't offer much help with it. But, you do have some network issues that should be addressed.

01:22:09.561: [rtmp stream: 'adv_stream'] Interface has non-zero error counters (80/0 errors, 160/0 discards)

Head over to the support page for your mobo & download/install the latest Network Driver. It should eliminate those errors & maybe you can get back to streaming without issue.
 
Streaming will always use CBR, even with VBR rate control methods padding will be inserted to ensure the stream is a static bitrate.
 
Thanks for the replies. The logged interface errors are irrelevant, and I have no issue with my actual network connection.

R1CH said:
Streaming will always use CBR, even with VBR rate control methods padding will be inserted to ensure the stream is a static bitrate.
Click to expand...
I've almost certain I've used VBR (VBR_LAT and HQVBR specifically for AMF) in OBS for streaming with it working as expected. When I'd throw up a static screen I'd see the streaming bitrate drop as expected. The same goes for when I open up a menu in a game or it goes to a mostly static loading screen.

I don't have any direct logs or captures of the statistics UI to prove it, and I see you're a developer of OBS, so I guess I'm just wrong / insane. If it's coming from rtmp-common.c [obs_data_set_string(settings, "rate_control", "CBR");] then that's been in place for a decade and I'm just wrong or Mandela Effecting myself.

Regardless, is there any way to disable the forced CBR / padding functionality or limit it to some range? For example, VBR targeting 16000 kbps with padding only up to 8000 kbps to prevent the ingest side from seeing large drops? VBR would save me a lot of bandwidth and usage against my data cap.

I know the common recommendation is to use CBR, but as far as I can tell that's fairly old advice and was a bandaid to prevent issues on some streaming platforms where VBR dips added latency on their end (with their encoders waiting to fill a buffer or the traffic being deprioritized). I don't know how true that is today. Maybe it is still a very bad idea on most platforms.

Thanks again.
 
Mudkips said:
Thanks for the replies. The logged interface errors are irrelevant, and I have no issue with my actual network connection.
Click to expand...

You only streamed for something like 20 seconds & yes there were no dropped frames in that instance but keep an eye on it. Every PC that is throwing that error is suspect. Anyway, the error is caused by bad EEE settings, your NIC trying to save power when it should be operating in performance mode.
 
You only streamed for something like 20 seconds
Click to expand...
That was just a test to see if it was forcing CBR or not.

And after further testing, with my streaming encoder set to the AMD AV1 hardware encoder set to HQCBR, and the recording encoder set to AMD AV1 HQVBR, the stream that gets sent to Youtube is, in fact, VBR. The log starts the same, saying it's starting in CBR mode, then it has a section saying HQVBR mode is being activated.

On a static, dark screen the bitrate encoded (and uploaded) does in fact drop way, way down to a few hundred Kbps. On a static, bright screen it doesn't drop as low, but still drops well under my target of 12000 Kbps for both HQCBR & HQVBR that I have for streaming and recording, respectively.

@R1CH Is this possibly because of an interaction with the replay buffer? I'm wondering if the replay buffer is forcing it to switch to using the settings defined in my recording encoder even if OBS would normally want to use CBR for the streaming encoder (regardless of my preferences set in the UI).
 
OK, thanks for the reply. I prefer VBR anyway (and haven't seen any issues with it on YouTube, so I'll stick with how I have it set up now.
 
You must log in or register to reply here.
Back
Top