What looks like it will be a massive release for Linux users, OBS Studio has begun the release procedure for OBS Studio 27.0 with it having a first Release Candidate out now and it's huge.
Something we reported on back in January is finally coming officially to the Linux version: service integration and browser dock support. This means you can actually add in things like Twitch chat and whatever other windows you want attached right into the OBS Studio application so everything can fit nicely together. It is incredibly useful!
The other huge one for Linux is Wayland support. This comes with a new PipeWire capture source when using Wayland. The developers note specifically that for Ubuntu users you're going to need Ubuntu 20.10 onwards, due to the need of PipeWire 0.3+.
Game pictured - the excellent DRAG.
Here's some of the other highlights to come with it:
- Added Undo/Redo
- Added a missing files warning when loading scene collections
- Also allows for bulk-update when folders have been moved (such as between computers)
- Third party plugins will need to add support for this capability manually
- Added source transitions, which allow you to set a transition for a source when showing or hiding it
- Added a Track Matte mode to stinger transitions, which supports a scene mask to display parts of the previous & current scene at the same time
- Added support for sRGB color formats, applying color operations in linear space
Some Linux-specific bug fixes also made it in this release including fixing VST paths on Linux and also a crash that would happen on Linux when audio backends are disabled was solved too. A number of bug fixes that affected all platforms were also solved with this update.
Full changelog here.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: PangaeaLooks like a really solid program, and I'm glad there is native Linux support (now) :)I'm pretty sure it has supported Linux natively for years. The new thing is Wayland support.
0 Likes
DamonLinuxPL Apr 4, 2021
Quoting: LeopardQuoting: DamonLinuxPLYou can always disable pipewire by pass -DENABLE_PIPEWIRE=OFF flag to CMAKE. This should fix compilation on previous Ubuntu releases.
Anyway looks like to me that recording witch VAAPI on Radeon 580 8GB in X11 is broken... at least on my hardware (both in vaapi+x264 and vaapi+hevc). Just not sure if this related to new OBS 27.0.0 RC1 release or new libva 2.11.0... or maybe somethings else. Anyone see somethings similar?
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9995
Maybe try with this mr or Mesa master.
Just applied this patch and vaapi works fine. Thanks.
1 Likes, Who?
Quoting: Purple Library GuyI've been gradually seeing more mentions of Pipewire, seems like it's kind of becoming another "next thing that will finally make Linux sound great" (although I understand it can do more than sound). What do people figure the prospects are this time around?
Pretty good, I'd say! I've been running Pipewire for the past month or so (I use Arch BTW ;) ) and haven't had any issues (apart from needing to check that conf files were updated on package upgrades). I like that it's a nice, compatible and modular system that maintains compatibility with existing solutions (Alsa, Pulse, Jack) and - best part - lets you still use the Jack server as a backend, if you want.
Surprisingly, it also seems less temperamental than PulseAudio and seems to not leave clients hanging if you restart its daemon (unlike PulseAudio).
1 Likes, Who?
Quoting: DamonLinuxPLYou can always disable pipewire by pass -DENABLE_PIPEWIRE=OFF flag to CMAKE. This should fix compilation on previous Ubuntu releases.
Anyway looks like to me that recording witch VAAPI on Radeon 580 8GB in X11 is broken... at least on my hardware (both in vaapi+x264 and vaapi+hevc). Just not sure if this related to new OBS 27.0.0 RC1 release or new libva 2.11.0... or maybe somethings else. Anyone see somethings similar?
I run a video stream system on PopOS running in an unraid VM with a RX480 4GB and I had Vaapi working for all of a couple of months. It stopped working just prior to 27.0 becoming available, so about 4 months ago. So I would guess there's an underlying issue with a library like libva. Exactly what your describing. Renders 1 frame every 30 or so seconds but has flawless audio. Is really weird. Back on software rendering and it's "ok".
0 Likes
DamonLinuxPL Jun 20, 2021
Quoting: AzarelQuoting: DamonLinuxPLYou can always disable pipewire by pass -DENABLE_PIPEWIRE=OFF flag to CMAKE. This should fix compilation on previous Ubuntu releases.
Anyway looks like to me that recording witch VAAPI on Radeon 580 8GB in X11 is broken... at least on my hardware (both in vaapi+x264 and vaapi+hevc). Just not sure if this related to new OBS 27.0.0 RC1 release or new libva 2.11.0... or maybe somethings else. Anyone see somethings similar?
I run a video stream system on PopOS running in an unraid VM with a RX480 4GB and I had Vaapi working for all of a couple of months. It stopped working just prior to 27.0 becoming available, so about 4 months ago. So I would guess there's an underlying issue with a library like libva. Exactly what your describing. Renders 1 frame every 30 or so seconds but has flawless audio. Is really weird. Back on software rendering and it's "ok".
Update Mesa to latest version. It is fixed now. Or if you can;t update it right now, just recompile mesa with this patch https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9995
1 Likes, Who?
I'm having some troubles with VAAPI-encoding too. Basically, it seems slower than it should be capable of. The highest settings I can run without overwhelming the encoder is 720p, profile=high, level=4.0, bitrate=25000kbps. In Windows the same graphics card will do 4k 60fps no problem.
I suspect that the encoder has a speed setting that isn't exposed in OBS, and it's set to high quality by default. I remember (long time ago) running a transcoding application in Windows which utilized AMD's VCE and it had three speed settings. The differences in frame-rate between each setting was pretty huge. The quality setting at 1080p would result in something like 40-ish fps, medium was maybe ~120fps, while the fastest setting would be between 150-200fps IIRC. That makes the quality setting pretty useless for realtime encoding in an application like OBS. I wish this setting was exposed in OBS too because as it is right now, the VAAPI-option isn't very useful.
Edit: Not sure if relevant, but the following yields ~72-77fps on a 1080p video.
Edit2: I found a promising parameter in the VAAPI-section of the ffmpeg documentation, '-compression_level', but it doesn't seem to be implemented or working on my hardware.
Last edited by Brisse on 20 June 2021 at 12:20 pm UTC
I suspect that the encoder has a speed setting that isn't exposed in OBS, and it's set to high quality by default. I remember (long time ago) running a transcoding application in Windows which utilized AMD's VCE and it had three speed settings. The differences in frame-rate between each setting was pretty huge. The quality setting at 1080p would result in something like 40-ish fps, medium was maybe ~120fps, while the fastest setting would be between 150-200fps IIRC. That makes the quality setting pretty useless for realtime encoding in an application like OBS. I wish this setting was exposed in OBS too because as it is right now, the VAAPI-option isn't very useful.
Edit: Not sure if relevant, but the following yields ~72-77fps on a 1080p video.
ffmpeg -y -vaapi_device /dev/dri/renderD128 -i file_in.mkv -vf 'format=nv12,hwupload' -c:v h264_vaapi -b:v 25000k file_out.mp4Edit2: I found a promising parameter in the VAAPI-section of the ffmpeg documentation, '-compression_level', but it doesn't seem to be implemented or working on my hardware.
[h264_vaapi @ 0x55cefcc345c0] Quality attribute is not supported: will use default quality level.Last edited by Brisse on 20 June 2021 at 12:20 pm UTC
0 Likes
Patreon
PayPal
See more from me