From: Landry Breuil <landry@openbsd.org>
Subject: Re: Enable VA-API in graphics/ffmpeg
To: ports@openbsd.org
Date: Fri, 26 Jul 2024 14:55:17 +0200

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)

Landry