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
I think you should give up on this.
I think by talking about "sandbox" in an abstract for what is going on,
it fails to describe the what is going on. "sandbox" is an extremely
unspecific words and everyone brings in their weird understanding.
- the program (firefox) has extremely poor "privsep"
Le Wed, Aug 14, 2024 at 10:57:46AM +0200, Jan Stary a écrit :
> > 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 USER
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
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..83887bbabe0 100644
--- a/graphics/ffmpeg/Makefile
++
35 matches
Mail list logo
