From: Landry Breuil Subject: Re: Enable VA-API in graphics/ffmpeg To: José Maldonado Cc: ports@openbsd.org Date: Sun, 28 Jul 2024 10:59:09 +0200 Le Sun, Jul 28, 2024 at 09:43:55AM +0200, Landry Breuil a écrit : > Le Fri, Jul 26, 2024 at 08:49:49PM -0400, José Maldonado a écrit : > > El vie, 26 jul 2024 a la(s) 8:56 a.m., Landry Breuil > > (landry@openbsd.org) escribió: > > > > > > > There are numerous issues that will need to be fixed before va-api in > > > > firefox will actually work. Some of them are pledge/unveil related, > > > > others are firefox hardcoding specific library versions for dlopen > > > > without fallback. > > > > > > thanks tb for looking into that :) > > > > > > > With the symlinks below and various additions to pledge and unveil, > > > > I get sound to play in what looks like hardware decoded video. > > > > Unfortunately, the player remains dark... > > > > > > the symlinks shouldnt be needed in all cases, because in the code i can > > > find that wraps ffmpeg and tries to load the libva libs > > > (https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegLibWrapper.cpp#366) > > > and the libgbm libs > > > (https://searchfox.org/mozilla-central/source/third_party/gbm/libgbm/mozgbm.cpp#31), > > > (and maybe others ? havent seen libxaw in the source code) > > > it uses nspr's PR_LoadLibraryWithFlags() which is patched to drop what's > > > after the .so (cf > > > https://github.com/openbsd/ports/blob/master/devel/nspr/patches/patch-nspr_pr_src_linking_prlink_c#L32) > > > > > > > In my case, I am trying Firefox 128 from packages, and ffmpeg with > > VAAPI patches and obtain VAAPI hwaccel with this changes > > thanks, that's a start, because it makes us understand what files are > opened by which process. > > But you do realize this adds lots of capacities to those process types > that arent needed right now, thus shouldnt be added. > > The right process is to figure out _what_ codepaths open those > libs/paths, and try to move those initializations *before* sandboxing, > so that adding those capacities isnt needed. Preloading libs before > sandboxing is a trick that has been done before (cf > https://phabricator.services.mozilla.com/D193353 / > https://bugzilla.mozilla.org/show_bug.cgi?id=1856301) now we need to add > a bit more libs, make sure subsequent dlopens finds the preloaded lib, > and do the same for the drm device fd. Right now wpath is needed because > it tries to open /dev/dri/renderD128 read-write after sandboxing, doing > that before sandboxing is the way to go. > > > On the other hand, there is one additional positive point in creating > > the libgbm and libdrm symlinks (or patch hardcode name for this libs > > in Firefox): enabling general DMAbuf support for Firefox which is > > broken due to the library versioning not matching. > > creating the symlinks is a big no :) fixing hardcoded versions is easy, > and upstreaming that is generally welcome. > > > If I'm not mistaken this leaves us with two things: > > > > 1.- Apply the patches you mentioned to pre-load libva and VAAPI > > support without many changes in unveil/pledge, but I don't think this > > enables full DRM and DMAbuf support for Firefox. > > that's a work in progress. we'll see if we get somewhere. If you want to > help, try the patches in my branch (eg > https://cgit.rhaalovely.net/mozilla-firefox/log/patches?h=vaapi) > and if they dont work, start from that and move the code around... > https://searchfox.org is a great tool to find codepaths/callers/etc. with the latest version of the patchset, i have something that doesnt crash, but fails to properly initialize vaapi: [(null) 51070: Main Thread]: D/Dmabuf DMABufDevice::Configure() [(null) 51070: Main Thread]: D/Dmabuf Loading DMABuf system library libgbm.so ... [(null) 51070: Main Thread]: D/Dmabuf Using DRM device /dev/dri/renderD128 [(null) 51070: Main Thread]: D/Dmabuf DMABuf is enabled drmfd preopened, fd=12 [(null) 51070: Main Thread]: D/OpenBSDSandbox /tmp: unveil(/tmp, rwc) [(null) 51070: Main Thread]: D/OpenBSDSandbox /etc/firefox/pledge.rdd: pledge(stdio rpath tmppath recvfd sendfd unix) [RDD 51070: MediaSupervisor #1]: D/FFmpegVideo FFMPEG: FFmpegVideoDecoder::FFmpegVideoDecoder MIME video/avc Codec ID 27 [RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: Initialising VA-API FFmpeg decoder [RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: codec h264 : H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: Can't get DRM VA-API display. [RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: Failed to create VA-API device context the gfxvars object isnt initialized yet, so it requires MOZ_DRM_DEVICE=/dev/dri/renderD128 in the env to find the right device. Landry