OBS Merges FFmpeg VA-API AV1 Support

[phoronix]

Phoronix: OBS Merges FFmpeg VA-API AV1 Support

The cross-platform OBS software that is popular with game streamers and others live-recording their desktops has finally landed support for AV1 video encoding using Linux's Video Acceleration API (VA-API) interface...

https://www.phoronix.com/news/OBS-Lands-AV1-VA-API

[Quackdoc]

it's a shame how OBS development is being handled now, OBS devs arent even willing to merge a generic pipewire video back end. instead forcing everything through the craptastic xdg portals stuff. if anyone knows a good alternative I would like to be told, even if its only a simple compositor for ffmpeg/gstreamer

[shmerl]

ffmpeg itself only landed AV1 VAAPI encoding relatively recently (September 2023), so having this PR opened from May didn't really matter until it was merged in ffmpeg itself.

But yeah, it didn't have to sit there much longer since September at least.

[shmerl]

it's a shame how OBS development is being handled now, OBS devs arent even willing to merge a generic pipewire video back end. instead forcing everything through the craptastic xdg portals stuff. if anyone knows a good alternative I would like to be told, even if its only a simple compositor for ffmpeg/gstreamer

Does Pipewire alone handle security? I thought whole idea of portals was for requesting access for screen sharing and such, but in the end it's still using Pipewire underneath. So why is that a problem?

I.e. portals don't really add any overheard, they only handle permissions checking/granting.

[Quackdoc]

Does Pipewire alone handle security? I thought whole idea of portals was for requesting access for screen sharing and such, but in the end it's still using Pipewire underneath.

pipewire itself does have basic access control, but even without that I don't see why it should be wholly excluded from OBS. Pipewire can be used in a lot of places, and instead of implementing a portals provider for every single type of capture. If you need that level of security, flatpak can provide that. and if for some reason it is an issue, just put it behind a conditional compile flag

[shmerl]

pipewire itself does have basic access control, but even without that I don't see why it should be wholly excluded from OBS. Pipewire can be used in a lot of places, and instead of implementing a portals provider for every single type of capture. If you need that level of security, flatpak can provide that. and if for some reason it is an issue, just put it behind a conditional compile flag

I mean, I think OBS does use Pipewire for actual video needs. Portals don't handle video, they are simply an interface for permissions handling as far as I understand.

[Quackdoc]

I mean, I think OBS does use Pipewire for actual video needs. Portals don't handle video, they are simply an interface for permissions handling as far as I understand.

correct, but they refuse to support pipewire itself. you can use the pipewire stream ID to capture a stream perfectly fine. for instance to capture gstreamer output you can use the below cmdline perfectly fine to capture the node id

gst-launch-1.0 pipewiresrc "path=$(pw-dump | jq '.[] | select(.info.props["node.name"] == "gamescope") | .id')" <Exclamation mark> videoconvert ! xvimagesink

<Sorry for the weird ! thing, phoronix breaks if I put an actual exclamation mark here>

you could also use this cmdline to query the availible devices, this will show any pipewire video source, gamescope, cameras etc.

pw-dump | jq '.[] | select(.info.props["media.class"] == "Video/Source") | .info.props."node.name" + " | " + .info.props."node.description" + " | " + (.id|tostring)

Pipewire offers everything needed for a comprehensive intercommunication between apps perfectly fine without needing portals. Instead OBS limits itself to the portals usage, Limiting compositor support (as compositors need to use a xdg portals that exports the video capture, which many wayland compositors don't do currently, or do so in a very limited manor), but also flexibility. I can easily make my application export a pipewire stream using gstreamer (I actually did this using Spice for virtual machines in the past.) However OBS can't consume these streams since it, really stupidly IMO, limits itself to portals and are out right unwilling to support a "just pipewire" pipeline

[shmerl]

I mean I don't really worry about how permissions are handled as along as you have access to full Pipewire functionality if you need anything. Or do you mean that using portals limits what from Pipewire can be used somehow? I.e. can you attach your stream to a portal for access if OBS relies to it? I'm not really familiar with how portals are used.

Some compositors not handling portals doesn't sound like an OBS problem to me. Compositors in general can be all over the place. Even Pipewire itself isn't really a mandatory feature of a Wayland set up.

But I agree in general, compositors better figure out something commonly expected, like they did with libinput for example.

[Quackdoc]

Or do you mean that using portals limits what from Pipewire can be used somehow? I.e. can you attach your stream to a portal for access if OBS relies to it? I'm not really familiar with how portals are used.

this is exactly the issue, not only does this mean you need to add a portals provider into the mix, but you also are limited in what the portals offer, one portal is for "screen capture" one port is for "camera" etc so on and so forth, and if there is no portal availible for you, you are SOL. but even if there was a portal for every usecase, requiring portals to begin with is stupid since now every single app that wants to work with OBS needs to implement this portal provider, and every compositor needs to have that specific provider too

Some compositors not handling portals doesn't sound like an OBS problem to me. Compositors in general can be all over the place. Even Pipewire itself isn't really a mandatory feature of a Wayland set up.

sure it's not an OBS problem. Same way as applications not supporting wayland "not a wayland problem", or some hardware devices not supporting linux "A linux problem" except this time, People have offered to do the work for OBS, and OBS devs outright said no

[shmerl]

sure it's not an OBS problem. Same way as applications not supporting wayland "not a wayland problem", or some hardware devices not supporting linux "A linux problem" except this time, People have offered to do the work for OBS, and OBS devs outright said no

That I don't get. If there are more access options, why not add them especially if someone does the work for them.