From: Landry Breuil Subject: Re: Enable VA-API in graphics/ffmpeg To: ports@openbsd.org Date: Fri, 26 Jul 2024 18:15:16 +0200 Le Fri, Jul 26, 2024 at 02:55:17PM +0200, Landry Breuil a écrit : > Le Fri, Jul 26, 2024 at 02:35:28PM +0200, Theo Buehler a écrit : > > On Wed, Jul 24, 2024 at 03:15:55PM +0000, Lucas Gabriel Vuotto wrote: > > > On Wed, Jul 24, 2024 at 07:59:23AM GMT, Rafael Sadowski wrote: > > > > On Sun Jul 21, 2024 at 04:58:15PM GMT, Lucas Gabriel Vuotto wrote: > > > > > On Sat, Jul 20, 2024 at 11:32:29AM GMT, Rafael Sadowski wrote: > > > > > > OK to enable VA-API? It only depends on xenocara libva. Since libva > > > > > > builds on almost all arches, I see no reason to restrict it by CPU > > > > > > architectures any further. > > > > > > > > > > This worked well with mpv but is giving me issues in Firefox: > > > > > > > > I can confirm that it works well with mpv(1) but not in ff. In my last > > > > test I only tested WebGL and simple youtube stuff. > > > > > > > > I have not noticed taht playing youtube run on my CPU. That's because up > > > > to 1080p60 always runs smoothly. But 2160p60 is the end of the line > > > > here. > > > > > > > > What I cannot confirm, any disadvantages with enabling or disabling > > > > VAAPI. > > > > > > Did you try Twitch? It indeed stops working ,and I wouldn't consider it > > > as niche as viewing YouTube thru Invidious (OT: I believe it's becoming > > > less and less niche.) > > > > > > > > > > > > > - Invidious instances (YouTube alternative frontend) give me "No > > > > > compatible source was found for this media" > > > > > - Twitch gives a similar message > > > > > - Couldn't test in YouTube because it thinks I'm a bot > > > > > > > > WTF! > > > > > > It doesn't like my VPS provider. After connecting from my home, I saw > > > the same thing as you: it runs on the CPU. > > > > > > > > - Some meme pages show webms just fine > > > > > > > > I don't see it, I'll test it with a new profile. Can you give me a test > > > > example? > > > > > > https://9gag.com/gag/avynegn > > > https://9gag.com/gag/amoz10j > > > > > > Raw media links: > > > > > > https://img-9gag-fun.9cache.com/photo/amoz10j_460svvp9.webm (VP9) > > > https://img-9gag-fun.9cache.com/photo/avynegn_460svav1.mp4 (AV1) > > > > > > According to about:support, both VP9 and AV1 decoding are supported > > > (tried with the Tiger Lake, i7-1165G7, Intel iRIS Xe-LP). > > > > > > Downloading the video and playing it with MPV works wonders. Playing it > > > in Firefox makes the CPU usage raise. Enabling > > > media.ffmpeg.vaapi.enabled made no difference, even after a restart. > > > > > > Basically, it seems that having an VA-API enabled ffmpeg doesn't make > > > a difference in Firefox right now. > > > > > > > If it's only about enabling va-api in ffmpeg without breaking the sites > > and links above in firefox, I think a patch to firefox's unveil.utility > > adding '/usr/X11R6/lib r' would enough. > > > > > > 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) > > what can/should be tried instead is preloading those libs before calling > unveil/pledge, at the same place where it is done for ffmpeg libs cf > https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/ffvpx/FFVPXRuntimeLinker.cpp#44 > and > https://searchfox.org/mozilla-central/source/dom/media/ipc/RDDProcessImpl.cpp#31 > > with that, maybe no changes to unveil/pledge config is needed (or less) > trying various combination of pr_loadlibrary flags might be needed too, > so that it doesnt try to load again a lib that is already loaded, but > without the same flags, where in that case it bypasses the dlopen cache > and fails to load the lib because unveil. > > cf https://bugzilla.mozilla.org/show_bug.cgi?id=1856301 & > https://hg.mozilla.org/mozilla-central/rev/f6d59e68442d4e8fc895d59de77277f823c50fe2 > for the previous similar issue wrt dlopen cache. > > (sorry, wont be able to play much with that in the coming days) replying to myself, https://cgit.rhaalovely.net/mozilla-firefox/commit/?h=vaapi&id=d64d93197bd7122edaa85d4057f6000feeac86bb is a quickly wrapped up patch trying to: - preload libva/libva-drm/libgbm libs before sandboxing the rdd process - make sure all subsequent dlopens uses the same library name so that shoulnt require that much pledge/unveil changes. or less. *shrug* MOZ_GFX_DEBUG=1 /usr/local/lib/firefox/vaapitest -d /dev/dri/renderD128 is a first check. as tb said, MOZ_LOG="FFmpegVideo:5,Dmabuf:5" in the env helps a lot understanding what happens, add some OpenBSDSandbox:5 to that to have the order of pledge/unveil interactions. ktrace and LD_DEBUG=1 also help. the same was done last time media decoding broke, and it helped. I havent tested at runtime at all, but the firefox-129.0b8 package on my repo has it. Landry