Stuttering in recording at 1440p@60, stuttering is removed if force memory copy is used.

[Sjatar]

Had great success using this plugin to record with a old AMD580 card! However there seems to be frame stuttering at 60 fps, this is not the case if you force memory copy though, so it leads me to believe that it's not my card not being up for the task.

The frame stuttering is not a issue with or without force memory copy if recording at 30 fps. I have included very short video clips showing the effect in 4 video files Force@30, NoForce@30, Force@60 and NoForce@60. Only NoForce@60 shows the stuttering. The recording is done using gstreamers testsrc pattern 18, this has been very handy in troubleshooting recordings! Examples.zip

I would use mem copy if I could, but noticed that it causes a memory leak. While a little tech savy I did try and look at the code but it's beyond me. It might be that the buffer that is filled is not cleared? Or perhaps this is the intended use of force memory copy?

As stated by others the encoding done by this plugin is very impressive and I'm not able to record at 1440p@60fps with my 580 in any other way I have tested.

(Second time posting on github, hope I'm doing this right)

[fzwoch]

Hey, I guess the memory leak is kinda huge?

What OS/platform and GStreamer version are you using? That options is really there because I was never sure about the life time of the underlying buffer. So with copy is probably safer. However I believe it should not leak.

[Sjatar]

I'm using Nobara which is gloriouseggrolls distro https://nobaraproject.org/ . I have also asked on their discord if anybody else can reproduce this issue ^^

Gstreamer spits out Core lib ver: 1.20.3

There is some unknowns I have not been able to check, Nobara comes with OBS V28 which is still in beta. But as I think this might be gstreamer related it might not matter.

Edit: and yes the memory leak will eventually fill the 16GB I have on this system. Also using Gnome version of the Nobara distro.

[fzwoch]

Tbh, it may just be that the GPU is not fast enough for real time. I can't check it myself as my VAAPI on my system is broken atm. But it could be, that currently all buffers are queued causing the memory usage to increase. One could tinker with the max-buffers property of the appsrc so see if it behaved differently. (in that case it will probably missing frames if it really is a performance thing)

That may explain why you have the skipped frame behavior when memory copy is disabled.

[Sjatar]

I will see how close to 1440p 60 fps I can get without the leak. I was very suprised the 580 was able to keep up.

When ending the recording OBS does state lost frames which is around 0.4% but this still results in a very watchable video.

[fzwoch]

OBS will not notice the lost frames as they are queued and not lost. If stop stoppes immedateily you may lose content in the end. Hoever I cannot remember if it waits until all frames are encoded.

[Sjatar]

I ran this gstreamer pipe to test the performance of the vaapi encoder:

gst-launch-1.0 filesrc location=testsnow.raw ! videoparse format=nv12 width=2560 height=1440 ! videoconvert ! vaapih264enc bitrate=22000 rate-control=cbr keyframe-period=120 ! h264parse ! mp4mux ! fakesink

the testsnow.raw file is premade with this pipe:

gst-launch-1.0 videotestsrc pattern=snow num-buffers=1000 ! video/x-raw, format=nv12, width=2560, height=1440 ! filesink location=testsnow.raw

The execution took 15.904 seconds which is a speed of 62.8fps in realtime, and 61.9 fps (16.157 sec) if it's outputted to a filesink. So it's really on the edge of processing it I guess?

First time running gstreamer to benchmark encoding, if there is faults in the pipes I would happily test again!

[Sjatar]

I will be closing this issue as I do think you are correct in saying that 580 is not capable of 1440p60fps. But even being close is amazing. Given 1080p60fps is a struggle with other implementations of vaapi and 580.

[T-Hitoshi]

Pardon me for commenting on an already year-old closed issue, however I want to request another look into this as I was having issues that might be linked to this: high memory consumption while attempting to stream on 1440p, a timelapse. Context is provided in the description, but do notify if you need other details from me.

First of all I am very thankful for making OBS work with VAAPI via the GStreamer plugin, as I discovered it while looking for a solution on having hardware-based encoding after I recently made a switch from an NVIDIA 750 Ti to an AMD RX 580 2048SP with 8GBs of VRAM (as to why I decided on this card, I was looking for a 2nd-hand immediate replacement and found this, but that's a story upon itself).

I mentioned in the video that it affects "streaming/recording", but as far as my own testing sessions went I've only been able to notify the memory leak happening during streaming.

I should also note that for streaming and recording on 1080p 60fps both hardware and encoder works excellently in my opinion, however what I was really trying to accomplish with 1440p 60fps streaming using the plugin and my current hardware was trying to circumvent Youtube transcoding 1080p streams and recordings badly as I've observed instances of it on several streams and uploads I have made.

[fzwoch]

You should move to https://github.com/fzwoch/obs-vaapi if you are interested in the encoders.

It may very well be that the GPU cannot handle 1440p60 in real time. It may be due to hardware limitation or driver implementation. The plugin cannot do much in these cases.

Note that force copy in this plugin will just allow storing of raw image data until the GPU is ready to consume them. If the encoder is too slow the memory will increase indefinitely until your system crashes.

[Sjatar]

Yes sadly to recap my findings, 580 is on the cusp of doing 1440p@60. But cannot get there sadly. Because of this Force copy works for a bit as the number of frames it stores is quite small.

It might be possible to run a non standard fps or resolution to give the card a bit more headroom but still be close to 1440p@60. It's not ideal though.

[fzwoch]

The newer plugin should expose a lot more knobs for encoder control. It may depend on the driver/hardware to what extend it helps in these cases.

[T-Hitoshi]

So I take it the obs-vaapi plugin is the newer one and I should use it in favor of obs-gstreamer, however I have not had much luck in using the former for streaming even at 1080p 60fps, as the encoder tends to overload no matter what I do, while obs-gstreamer did not give me that problem.

Honestly 1080p streaming on Youtube is far from ideal thanks to YouTube drastically lowering the quality of such streams, in order to avoid that I've gotten the suggestion to upscale my streams to 1440p and was hoping to be able to stream it.

But anyway thank you for answering my query, I will look into obs-vaapi plugin.

I'm also using the flatpak version of OBS and the plugins if that helps.

[fzwoch]

The obs-vaapi offers two different type of encoders; older, legacy vaapi versions and newer va ones. For both, h264 and h265. Each hardware/driver may work better or worse than the other - not sure if there is a rule of thumb.

I know that I had no issues at 1080p60 with a 570 before I replaced it with a 6600 (which runs fine as well).

[T-Hitoshi]

On my end I seem to only see the legacy vaapi versions, is obs-gstreamer conflicting with it?

Either way thank you again for the answers, I'll look into the settings I have when I can.

[fzwoch]

No, there are no conflicts. You need the va set of plugins from GStreamer. No idea if they are available on Flatpak.

[T-Hitoshi]

Thank you.

It seems I do need to look into the obs-vaapi list of issues as I do have problems trying to use them on my end, so I'll be forwarding my issue there then.