GStreamer encoder not applying saved bitrate while streaming

[pmartiner]

Hi!

I'm facing an issue with the plugin while streaming. It looks like the encoder is not respecting my bitrate (similar issue as #67). And not only that: the output of my stream looks like is being downgraded to the default bitrate (2500kbps) and to a 720p resolution, even though I have a 6000kbps bitrate at 1080p in my settings. This, however, does not happen when I record the video. I'm using the latest version (v0.3.4) from the AUR. I've also tried the prebuilt plugin, but the problem is still there

Here are some screenshots of the issue:

Is this a bug? May I help with some logs? Thanks!

[fzwoch]

An OBS log always helps. Not sure what should be the differnce between recording and streamign though.

Oddly enough you screenshot says it is streaming at 11mbps. Maybe your streaming provider transcodes the video to low quality?

[pmartiner]

Sure thing! Here are my logs. I tried to stream and record with the Gstreamer encoder as well as streaming with AMF in case that comparing them may be useful for the debugging process.

Yeah, I would think that if OBS is streaming at 11mbps the output quality would be waaay better. Maybe that's just a Twitch thing.

Weirdly enough, unless I set the type on the Recording tab to "Custom Output (FFmpeg)" and the Video Bitrate manually to 6000kbps, the output looks the same as when streaming. Maybe it has to do with that?

[pgwipeout]

Twitch generally enforces a max cap of 6m, you can push it a bit higher, but not by much. They do support auto transcode for non partners on a space available basis. Use twitch inspector to view statistics of your incoming video.

Since "source" isn't an option here I'd venture it's because you're too high above their limits.

[pmartiner]

@pgwipeout yeah, I imagine that's the reason it's playing it at 720p. However, even if I set the bitrate to 6mbps on the Gstreamer encoder settings in the Streaming tab, the config is not being respected :/

[pgwipeout]

What does twitch inspector say?

[pmartiner]

it looks like the bitrate's okay, but there's a config/compatibility issue:

[pgwipeout]

Are you running adaptive bitrate? I recommend you look into twitch's recommended streaming settings.

[pmartiner]

@pgwipeout nope, CBR. these are my current settings:

EDIT: I usually use AMF to stream and, with 6000kbps CBR, everything works as expected. I decided to give the gstreamer plugin a try since the recordings performed better IMO, but I've not managed to get it working when streaming :/

EDIT 2: I forgot to mention that I stream on Linux (if that helps)

[pgwipeout]

The bitrate spike is a problem if it happens regularly, also it's concerning the video and audio encoder aren't being passed through correctly. That's probably a string that this plugin should be setting (just a guess here).

[pmartiner]

@pgwipeout I guess that the encoders weren't passed to the inspector because I was running a test stream. Here's a screenshot of a "live" stream:

[fzwoch]

Here is my config and result.

[pmartiner]

hmmm, weird. it looks like we have the same settings @fzwoch. maybe it has to do with the distro I'm running (Arch Linux)? 'cause I've tried both the flatpak version and tytan's version of OBS and the issue is still there.

EDIT: @fzwoch does your stream's output look good? as in no artifacts (well, at least not as much as the screenshot I posted)?

[pgwipeout]

Most likely it's your actual hardware encoder here. Some are more stable than others.

With those settings you should be seeing "source" as an option on your live stream. If you're seeing artifacting on the "source" stream that's either your hardware or the driver.

[pmartiner]

@pgwipeout yup, those artifacts appear when the "source" option is selected. I find it weird that the encoder's kinda unstable given that the inspector does not complaint about the stabilty. I'm not ruling it out, since I have a low-end RDNA(1) GPU (5500XT), but I just find it weird.

(I tried running OBS with the RADV drivers as well as with the AMDGPU PRO ones and the output's the same. I also suspect that it may have to do with the FFmpeg version I'm running)

[fzwoch]

My stream looks good for me. I personally use an RX 570 so I doubt it should be an issue with the 5500 XT. I tried with the Ryzen G series in the past too with no problems. At some point I had it running on a 5700 too.

FFMPEG should not be involved here, at least for the encoding.

[pgwipeout]

Funnily enough, the older radeons are some of the ones that are unstable. It's gotten better with rdna2 but we still have reports of weird behavior on some of them.

[pmartiner]

@fzwoch true. I tried with the "regular" FFmpeg and nothing changed :/

@pgwipeout yeah, it may be, especially if no one else has faced this issue

[fzwoch]

FFMPEG VAAPI is the same issue?

Then maybe it is your mesa driver version that's causing it.

[pgwipeout]

All of the encoder "work" is done by the GPU silicon. There's some minor post processing that can be handled by the CPU, but anything major is expensive(thus you'd notice if you were doing it).

If you want to verify it's a hardware problem, pop the card in a windows machines and verify with those drivers.

[pmartiner]

@fzwoch @pgwipeout yup, the same thing happens with FFMPEG VAAPI. Does that confirm that's a Mesa driver issue? I'm currently running v22.1.4

[pgwipeout]

Using the encoder directly through the va-api interface won't touch mesa as it's directly calling the kernel encoder api. Mesa only comes into play when video is displayed. If the stream looks broken on another device, then it isn't a display issue. You should validate your hardware isn't one of the bugged ones.

[pmartiner]

@pgwipeout it looks like the hardware's not the issue. it looks great on windows:

[pgwipeout]

x264 is a cpu encoder. You need an external plugin for amf to work on OBS for windows.

[pmartiner]

@pgwipeout I usually stream with AMF on windows as well and the output looks great. Here are some screenshots:

[fzwoch]

At the end I do not understand why the recording turns out good, while the stream does not. Unless you have different encoders or encoding settings for them.

[pgwipeout]

I suspect this is a data rate / data starvation problem. Recording can buffer until an entire frame or group of frames is ready and run them through the encoder, where streaming will run as fast as the pipeline will allow. IIRC the AMD encoder needs this in order to perform well. They stated the AMF plugin for Linux worked well, while pumping through the VA-API directly does not. I suspect the AMF plugin is doing something behind the scenes to mitigate this weakness. I don't spend a lot of time messing with gstreamer pipelines, but is there a way to ask it to buffer a frame or two? Another possibility is we are building the pipeline without B Frames. See this article for info: https://www.tomshardware.com/news/amd-amf-encoder-quality-boost

[pmartiner]

I the recording report was an issue on my part :s, my bad!!! I didn't realize that I was indeed using a different encoder. After changing the settings the Gstreamer Encoder, the output looked the same as when streaming. (The bad quality video does happen with FFMPEG VAAPI and the Gstreamer Encoder when streaming and recording)

[fzwoch]

Ok, I guess I will close it then. Looks like the issue seems to be in the VAAPI layer or driver, but not in this plugin.

[pmartiner]

Thank you for the help and for your time!