On Sat Jan 11, 2025 at 08:41:32PM +0100, Jan Stary wrote:
> Should graphics/ffmpeg include an explicit --enable-vaapi ?
> The current Makefile seems to rely on autodetection, is that intended?
>
> Jan
>
Yes, auto-detection is provided, and since we ship libva with xenocara,
it will be fo
Should graphics/ffmpeg include an explicit --enable-vaapi ?
The current Makefile seems to rely on autodetection, is that intended?
Jan
To be sure: is vaapi supposed to also help with encoding ?
$ pkg_info intel-vaapi-driver
The current video driver backend provides a bridge to the GEN GPUs
through the packaging of buffers and commands to be sent to the i915
driver for exercising both hardware and shader functionality for
> First, I was able to solve my problem with acceleration in Firefox
> using this about:config option
>
> media.ffmpeg.vaapi.enabled = true
>
> Once I enabled it, in about:support I saw h264 hardware decoding
> support (but not h265 and my card is capable).
Setting media.ffmpeg.vaapi.enabled = t
> Can AMD users play https://www.youtube.com/watch?v=LXb3EKWsInQ in
> 2160p60 on FF without blowing the CPU?
On this AMD machine (dmesg and vainfo below),
firefox-129.0 plays this video eating about 14% of CPU.
PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
23106 hans
On Mon, Jul 29, 2024 at 01:52:51PM GMT, Jan Stary wrote:
> On Jul 21 18:00:28, lu...@sexy.is wrote:
> > On Sun, Jul 21, 2024 at 01:09:24PM GMT, José Maldonado wrote:
> > > This is rare. In my case, using mpv+yt-dlp for YouTube videos work
> > > fine (using 4.4.4p3 and 4.4.4p5).
> >
> > This isn't
On Jul 21 14:15:49, josemal...@gmail.com wrote:
> El dom, 21 jul 2024 a la(s) 2:00 p.m., Lucas Gabriel Vuotto
> (lu...@sexy.is) escribió:
> >
> > I don't believe you're doing hardware decoding here. This is how it
> > looks in my machine:
> >
> > (+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
> >
On Jul 28 20:19:48, raf...@sizeofvoid.org wrote:
> On Sun Jul 28, 2024 at 06:52:04PM GMT, Jan Stary wrote:
> > On Jul 28 18:37:55, raf...@sizeofvoid.org wrote:
> > > On Sun Jul 28, 2024 at 06:35:37PM GMT, Jan Stary wrote:
> > > > Before I get down the rabbit hole,
> > > > is there any way to tell w
El dom, 28 jul 2024 a la(s) 4:59 a.m., Landry Breuil
(lan...@openbsd.org) escribió:
>
> Le Sun, Jul 28, 2024 at 09:43:55AM +0200, Landry Breuil a écrit :
>
> with the latest version of the patchset, i have something that doesnt
> crash, but fails to properly initialize vaapi:
>
> [(null) 51070: Mai
On Sun Jul 28, 2024 at 06:52:04PM GMT, Jan Stary wrote:
> On Jul 28 18:37:55, raf...@sizeofvoid.org wrote:
> > On Sun Jul 28, 2024 at 06:35:37PM GMT, Jan Stary wrote:
> > > Before I get down the rabbit hole,
> > > is there any way to tell which codecs
> > > my inteldrm is able to decode/accelerate
On Jul 28 18:37:55, raf...@sizeofvoid.org wrote:
> On Sun Jul 28, 2024 at 06:35:37PM GMT, Jan Stary wrote:
> > Before I get down the rabbit hole,
> > is there any way to tell which codecs
> > my inteldrm is able to decode/accelerate
> > and how much it is worth it?
cd /usr/ports/sysutils/libva-uti
On Sun Jul 28, 2024 at 06:35:37PM GMT, Jan Stary wrote:
> Before I get down the rabbit hole,
> is there any way to tell which codecs
> my inteldrm is able to decode/accelerate
> and how much it is worth it?
cd /usr/ports/sysutils/libva-utils && make install && vainfo
>
> Anything else to look at
Before I get down the rabbit hole,
is there any way to tell which codecs
my inteldrm is able to decode/accelerate
and how much it is worth it?
Anything else to look at besides this?
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 2000" rev 0x09
Jan
OpenBSD 7.5-current (GENERIC.MP)
Landry Breuil wrote:
> 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.
That is correct. What's being proposed is ve
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
> > (lan...@openbsd.org) escribió:
> > >
> > > > There are numerous issues that will need to be fixed befor
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
> (lan...@openbsd.org) escribió:
> On the other hand, there is one additional positive point in creating
> the libgbm and libdrm symlinks (or patch hardcode name for this lib
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
> (lan...@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
El vie, 26 jul 2024 a la(s) 8:56 a.m., Landry Breuil
(lan...@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 dlo
That's quite a step backwards for pledge usage. The firefox privsep
story just keeps getting worse.
El mié, 24 jul 2024 a la(s) 4:41 p.m., Rafael Sadowski
(raf...@sizeofvoid.org) escribió:
>
> 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
>
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.
>
Here is some research from me:
# Case 1, segmentation fault in int
El mié, 24 jul 2024 a la(s) 2:01 a.m., Rafael Sadowski
(raf...@sizeofvoid.org) escribió:
>
> 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 libv
On Tue Jul 23, 2024 at 06:02:20PM GMT, José Maldonado wrote:
>
> Hi!
>
> The last sync (23 july, 21:57 pm UTC) for my port tree have
> ffmpeg-4.4.4p5 without VAAPI active (--disable-vaapi CONFIGURE_ARGS)
> but ports xine-libs and others point this version with this support.
>
Thanks for feedbac
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 fu
El lun, 22 jul 2024 a la(s) 3:36 a.m., Brad Smith (b...@comstyle.com) escribió:
>
> On 2024-07-20 5:32 a.m., 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 furthe
On 2024-07-20 5:32 a.m., 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.
diff --git a/graphics/ffmpeg/Makefile b/graphics/ffmpeg/Makefile
index 8b1663a55ab..83
> El dom, 21 jul 2024 a la(s) 2:00 p.m., Lucas Gabriel Vuotto
> (lu...@sexy.is) escribió:
> >
> > I don't believe you're doing hardware decoding here. This is how it
> > looks in my machine:
> >
> > (+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
> > (+) Audio --aid=1 --alang=eng (*) (aac 2ch 441
El dom, 21 jul 2024 a la(s) 2:00 p.m., Lucas Gabriel Vuotto
(lu...@sexy.is) escribió:
>
> I don't believe you're doing hardware decoding here. This is how it
> looks in my machine:
>
> (+) Video --vid=1 (*) (vp9 3840x2160 59.940fps)
> (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
> Sub
On Sun, Jul 21, 2024 at 01:09:24PM GMT, José Maldonado wrote:
> This is rare. In my case, using mpv+yt-dlp for YouTube videos work
> fine (using 4.4.4p3 and 4.4.4p5).
This isn't firefox tho, which is were I do experience issues. My
ffmpeg+mpv works fine, even mpv+yt-dlp with your YouTube video.
ff
El dom, 21 jul 2024 a la(s) 1:00 p.m., Lucas Gabriel Vuotto
(lu...@sexy.is) escribió:
>
> 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
> >
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:
- In
El sáb, 20 jul 2024 a la(s) 5:34 a.m., Rafael Sadowski
(raf...@sizeofvoid.org) escribió:
>
> 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.
>
> diff --git a/graphics/ffmpeg/Makefil
32 matches
Mail list logo
