home.social

#vaapi — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #vaapi, aggregated by home.social.

  1. I'll be watching this and hoping for a merge!

    VAAPI Encoder (2nd branch/attempt) by sgothel · Pull Request #7467 · HandBrake/HandBrake · GitHub

    github.com/HandBrake/HandBrake

    #handbrake #AMD #VAAPI

  2. #handbrake encoding with default #Mesa stack does not utilize GPU acceleration without proprietary amf-amdgpu-pro drivers, which are available in #AUR but look to have been abandoned after AMD stopped publishing separated AMF from their stack, building on top of open amdgpu drivers instead, and offer inferior performance in other contexts.

    #ffmpeg can with #VAAPI but hammering out scripts for the amount of media I'm archiving, that's less than ideal.

    Could spin up a VM with amf drivers, but setting up with SingleGPUPassthrough seems like overkill/pain in the ass.

    Any other tools utilizing VAAPI that could make things a little easier?

  3. @niccolove @niccolo_ve

    Comment on this video (which us not shown on my Fedi instance, yay federation!)

    tube.kockatoo.org/w/63cGWTvhzq

    I cannot believe that that GPU is not usable for video work. That is what GPUs are made for!

    Poorly, there are a few caveats:
    - there are always more DEcoders supported than ENcoders. I guess not being able to play a video (it would play but be less efficiently decoded on the CPU) is worse than being bound to #h265 instead of #av1 for recording.
    - thus it makes sense that GPUs generally work flawlessly for gaming, as that is just displaying videos (or rendering content, which is kinda different, no idea why video codecs are more difficult than rendering methods)
    - for every video format out there exists an encoder. If you use software rendering (on the CPU), you can use ANYTHING. Like encode to modern (and free!) AV1 using #svtav1 on any old CPU.
    - if you want to encode videos on a GPU, you need drivers, but also a different encoder. On #NVIDIA you use #NVENC (NVidia ENCoder), for example nvenc_x265 for h265/HEVC videos. On #IntelArc (and afaik AMD GPUs), you use the #QSV (quick sync video) library which builds on top of #VAAPI, which is open source. So you can encode to AV1 using qsv_av1 for example.

    What encoders are supported depends on the GPU a lot. Intel Arc seems to have supported the free, efficient and future-proof AV1 codec the earliest, but also the older free codecs VP9 and VP8 (also used in webm), like in a GPU I recently bought used. My older NVIDIA GPU only supports H265, which is proprietary and often less efficient than AV1 (not always, video codecs are black magic).

    As OBS can use your GPU for video capture (encoding), the issue is purely in software support.

    I only have experience with #ffmpeg for re-encoding videos, but that is also in many video editing tools. Try if you can get them somehow.

    For NVIDIA I needed the latest proprietary drivers (#NixOS makes this extremely easy, can recommend) and ffmpeg, nvenc worked out of the box.

    For intel Arc I used the regular drivers included in the kernel, but after adding the QSV runtime to my "hardware.graphics.extraPackages" I needed to recompile the entire kernel. Using a #longterm kernel (currently 6.18) makes this more viable... longterm XD.

    #MicrosoftSurface #KDENlive #Shotcut #VideoEditing

  4. @niccolove @niccolo_ve

    Comment on this video (which us not shown on my Fedi instance, yay federation!)

    tube.kockatoo.org/w/63cGWTvhzq

    I cannot believe that that GPU is not usable for video work. That is what GPUs are made for!

    Poorly, there are a few caveats:
    - there are always more DEcoders supported than ENcoders. I guess not being able to play a video (it would play but be less efficiently decoded on the CPU) is worse than being bound to #h265 instead of #av1 for recording.
    - thus it makes sense that GPUs generally work flawlessly for gaming, as that is just displaying videos (or rendering content, which is kinda different, no idea why video codecs are more difficult than rendering methods)
    - for every video format out there exists an encoder. If you use software rendering (on the CPU), you can use ANYTHING. Like encode to modern (and free!) AV1 using #svtav1 on any old CPU.
    - if you want to encode videos on a GPU, you need drivers, but also a different encoder. On #NVIDIA you use #NVENC (NVidia ENCoder), for example nvenc_x265 for h265/HEVC videos. On #IntelArc (and afaik AMD GPUs), you use the #QSV (quick sync video) library which builds on top of #VAAPI, which is open source. So you can encode to AV1 using qsv_av1 for example.

    What encoders are supported depends on the GPU a lot. Intel Arc seems to have supported the free, efficient and future-proof AV1 codec the earliest, but also the older free codecs VP9 and VP8 (also used in webm), like in a GPU I recently bought used. My older NVIDIA GPU only supports H265, which is proprietary and often less efficient than AV1 (not always, video codecs are black magic).

    As OBS can use your GPU for video capture (encoding), the issue is purely in software support.

    I only have experience with #ffmpeg for re-encoding videos, but that is also in many video editing tools. Try if you can get them somehow.

    For NVIDIA I needed the latest proprietary drivers (#NixOS makes this extremely easy, can recommend) and ffmpeg, nvenc worked out of the box.

    For intel Arc I used the regular drivers included in the kernel, but after adding the QSV runtime to my "hardware.graphics.extraPackages" I needed to recompile the entire kernel. Using a #longterm kernel (currently 6.18) makes this more viable... longterm XD.

    #MicrosoftSurface #KDENlive #Shotcut #VideoEditing

  5. @niccolove @niccolo_ve

    Comment on this video (which us not shown on my Fedi instance, yay federation!)

    tube.kockatoo.org/w/63cGWTvhzq

    I cannot believe that that GPU is not usable for video work. That is what GPUs are made for!

    Poorly, there are a few caveats:
    - there are always more DEcoders supported than ENcoders. I guess not being able to play a video (it would play but be less efficiently decoded on the CPU) is worse than being bound to #h265 instead of #av1 for recording.
    - thus it makes sense that GPUs generally work flawlessly for gaming, as that is just displaying videos (or rendering content, which is kinda different, no idea why video codecs are more difficult than rendering methods)
    - for every video format out there exists an encoder. If you use software rendering (on the CPU), you can use ANYTHING. Like encode to modern (and free!) AV1 using #svtav1 on any old CPU.
    - if you want to encode videos on a GPU, you need drivers, but also a different encoder. On #NVIDIA you use #NVENC (NVidia ENCoder), for example nvenc_x265 for h265/HEVC videos. On #IntelArc (and afaik AMD GPUs), you use the #QSV (quick sync video) library which builds on top of #VAAPI, which is open source. So you can encode to AV1 using qsv_av1 for example.

    What encoders are supported depends on the GPU a lot. Intel Arc seems to have supported the free, efficient and future-proof AV1 codec the earliest, but also the older free codecs VP9 and VP8 (also used in webm), like in a GPU I recently bought used. My older NVIDIA GPU only supports H265, which is proprietary and often less efficient than AV1 (not always, video codecs are black magic).

    As OBS can use your GPU for video capture (encoding), the issue is purely in software support.

    I only have experience with #ffmpeg for re-encoding videos, but that is also in many video editing tools. Try if you can get them somehow.

    For NVIDIA I needed the latest proprietary drivers (#NixOS makes this extremely easy, can recommend) and ffmpeg, nvenc worked out of the box.

    For intel Arc I used the regular drivers included in the kernel, but after adding the QSV runtime to my "hardware.graphics.extraPackages" I needed to recompile the entire kernel. Using a #longterm kernel (currently 6.18) makes this more viable... longterm XD.

    #MicrosoftSurface #KDENlive #Shotcut #VideoEditing

  6. @niccolove @niccolo_ve

    Comment on this video (which us not shown on my Fedi instance, yay federation!)

    tube.kockatoo.org/w/63cGWTvhzq

    I cannot believe that that GPU is not usable for video work. That is what GPUs are made for!

    Poorly, there are a few caveats:
    - there are always more DEcoders supported than ENcoders. I guess not being able to play a video (it would play but be less efficiently decoded on the CPU) is worse than being bound to #h265 instead of #av1 for recording.
    - thus it makes sense that GPUs generally work flawlessly for gaming, as that is just displaying videos (or rendering content, which is kinda different, no idea why video codecs are more difficult than rendering methods)
    - for every video format out there exists an encoder. If you use software rendering (on the CPU), you can use ANYTHING. Like encode to modern (and free!) AV1 using #svtav1 on any old CPU.
    - if you want to encode videos on a GPU, you need drivers, but also a different encoder. On #NVIDIA you use #NVENC (NVidia ENCoder), for example nvenc_x265 for h265/HEVC videos. On #IntelArc (and afaik AMD GPUs), you use the #QSV (quick sync video) library which builds on top of #VAAPI, which is open source. So you can encode to AV1 using qsv_av1 for example.

    What encoders are supported depends on the GPU a lot. Intel Arc seems to have supported the free, efficient and future-proof AV1 codec the earliest, but also the older free codecs VP9 and VP8 (also used in webm), like in a GPU I recently bought used. My older NVIDIA GPU only supports H265, which is proprietary and often less efficient than AV1 (not always, video codecs are black magic).

    As OBS can use your GPU for video capture (encoding), the issue is purely in software support.

    I only have experience with #ffmpeg for re-encoding videos, but that is also in many video editing tools. Try if you can get them somehow.

    For NVIDIA I needed the latest proprietary drivers (#NixOS makes this extremely easy, can recommend) and ffmpeg, nvenc worked out of the box.

    For intel Arc I used the regular drivers included in the kernel, but after adding the QSV runtime to my "hardware.graphics.extraPackages" I needed to recompile the entire kernel. Using a #longterm kernel (currently 6.18) makes this more viable... longterm XD.

    #MicrosoftSurface #KDENlive #Shotcut #VideoEditing

  7. I just spent like 5 hours trying to force #FFMPEG #VAAPI #OBS encoder to output something that isn't a hot blurry mess. It turns out there is a nice ffmpeg webpage, where they state that AMD/Mesa platform supports one parameter:
    -compression_level=xx

    And setting it to 29 activates a quality preset which isn't
    complete bullshit and then the #stream looks nice...

    https://trac.ffmpeg.org/wiki/Hardware/VAAPI

    I love
    #Linux, but cut me some slack sometimes xD I will start making guides for all of the bullshit I have been finding out about stuff over the years. The solutions people post on forums are sometimes so ridiculous xD

    At 1:40 AM, Nevy over and out... Finally...
    ​:skeletor:​

  8. Dans cette vidéo, je vous montre comment j’utilise mes alias personnalisés pour automatiser et accélérer le traitement vidéo sur mon matériel reconditionné 😉

    Retrouvez tous les alias et explications sur mon Wiki : wiki.blablalinux.be/fr/mp4-con

    #Debian #FFmpeg #VAAPI #Intel #GPU

  9. 🚀 Actualicé mi guía para instalar Kdenlive (DMO) en Debian/AntiX

    Le hice varias mejoras visuales para que ahora se vea mucho mejor en móviles 📱✨
    También agregué botones de copiar en los bloques de comandos para que todo sea más cómodo al seguir la guía.

    Si ya la leíste, te recomiendo revisarla de nuevo 👇😉

    🔗 👉 drcalambre.blogspot.com/2025/1

    #Kdenlive #MLT #MELT #Linux #Debian #AntiX #MX #VAAPI #DMO #EdiciónDeVideo #OpenSource #BlogTech #FOSS

  10. 🚀 Actualicé mi guía para instalar Kdenlive (DMO) en Debian/AntiX

    Le hice varias mejoras visuales para que ahora se vea mucho mejor en móviles 📱✨
    También agregué botones de copiar en los bloques de comandos para que todo sea más cómodo al seguir la guía.

    Si ya la leíste, te recomiendo revisarla de nuevo 👇😉

    🔗 👉 drcalambre.blogspot.com/2025/1

    #Kdenlive #MLT #MELT #Linux #Debian #AntiX #MX #VAAPI #DMO #EdiciónDeVideo #OpenSource #BlogTech #FOSS

  11. 🚀 Actualicé mi guía para instalar Kdenlive (DMO) en Debian/AntiX

    Le hice varias mejoras visuales para que ahora se vea mucho mejor en móviles 📱✨
    También agregué botones de copiar en los bloques de comandos para que todo sea más cómodo al seguir la guía.

    Si ya la leíste, te recomiendo revisarla de nuevo 👇😉

    🔗 👉 drcalambre.blogspot.com/2025/1

    #Kdenlive #MLT #MELT #Linux #Debian #AntiX #MX #VAAPI #DMO #EdiciónDeVideo #OpenSource #BlogTech #FOSS

  12. Interessant: eufy e210 Kamera über #frigate mit #zimaboard über #vaapi (Dekodierung) und #coral (Detektion) lokal energieschonend auswerten.

  13. Interessant: eufy e210 Kamera über #frigate mit #zimaboard über #vaapi (Dekodierung) und #coral (Detektion) lokal energieschonend auswerten.

  14. Interessant: eufy e210 Kamera über #frigate mit #zimaboard über #vaapi (Dekodierung) und #coral (Detektion) lokal energieschonend auswerten.

  15. Interessant: eufy e210 Kamera über #frigate mit #zimaboard über #vaapi (Dekodierung) und #coral (Detektion) lokal energieschonend auswerten.

  16. me: Oh, with my Framework Laptop I can now finally encode AV1 with hardware acceleration! Yay modern codecs!

    AMD: By the way there's a hardware bug and the resulting video's dimensions have to be a multiple of 64×16. We've added a partial workaround, but your 1080p videos will be 1082p nevertheless.

    gitlab.freedesktop.org/mesa/me

    🙄

    There's cropping metadata going to be added to AV1 at some point apparently, but don't hold your breath.

    github.com/AOMediaCodec/av1-sp

    #AMD #AV1 #FrameworkLaptop #VAAPI

  17. Done this with the #AMD 5600G's iGPU, now testing #Jellyfin hardware transcoding with my #Intel #ArcA380 GPU - one question though, is it normal for CPU usage to be rather high at least in the early parts of streaming (while transcoding), even with hardware transcoding?

    I'm just trying to figure out if it is actually hardware transcoding - I'm assuming it is, bcos on the admin dashboard I'm seeing that it's transcoding as AV1 and I'm sure my Ryzen 7 1700 would not be able to do/handle that, esp considering that I'm testing with 4 streams playing concurrently? but the CPU usage is rather high the first minute or two or more from when the stream starts, it does lower down afterwards - the video playback is perfectly fine, no stuttering or anything like that.

    My method of passthrough is the same as I did with the 5600G, that is a simple passthrough to the
    #LXC container, then to the #Docker container running Jellyfin. I don't think I noticed this high CPU usage when testing the 5600G, and the only minor configuration difference between the two was I'd used #VAAPI with the 5600G and disabled #AV1 encoding (since idt it supports it), while on the Arc A380 GPU I'm using Intel's #QSV and have enabled AV1 encoding.

    Am I correct to assume that hardware transcoding is indeed working? Cos again, I'm quite certain my Ryzen 7 1700 would definitely NOT be able to handle this lol esp since I only give the LXC container 2 cores.

  18. After upgrading to RX 6800, I managed to get VAAPI working by uninstalling `libva-nvidia-driver` package.

    Hardware acceleration seems to be working on Firefox latest.

    Did I tell you I have setup open-webui for Ollama? I installed with venv + pip because global level pip install is blocked in #Manjaro

    #linux #diary #vaapi #amdgpu

  19. Update: It's probably not a #VAAPI / #VDPAU issue. Went through the #HardwareAcceleration #Arch wiki entry and confirmed both to be working.

  20. PSA for the people running #Firefox (or derivative browsers) on Linux on older Intel hardware and using the iGPU (e.g. my i5-6600T).

    Enhancer for YouTube's ability to force H.264 so that we can get hardware video playback is broken - the checkbox does nothing. I've had to install enhanced-h264ify to get hardware decoding working again.

    I couldn't work out why my machine's CPU was going through the roof when watching a video.

    But at least that's all it was. It's still easier to set up a Firefox-based browser to use #VAAPI than any Chromium-based browser on this older hardware. I'd have to futz with settings every other release.

  21. VAAPI mejora significativamente la experiencia de reproducción de IPTV en Jellyfin al reducir la carga en la CPU, mejorar la calidad del video y ofrecer una reproducción más eficiente y fluida. 🎥✨

    🔧 **Intel** Desarrollada por Intel, VAAPI es ampliamente utilizada en sistemas Linux. Mejora la eficiencia del procesamiento de video al utilizar las capacidades de hardware de la GPU. 🌐

    🎉🖥️🔧 #antiX #AMD #Intel #HardwareTest #jellyfin #docker #GPU #vaapi #ATI #Radeon#old #IPTV

    en.wikipedia.org/wiki/Video_Ac

  22. **Capacidad de decodificar videos en los formatos MPEG2, VC1, y H264 en varios perfiles**, significa que puede reproducir videos utilizando la aceleración por hardware. Además, puede realizar **procesamiento de video acelerado por hardware** para mejorar la eficiencia en tareas como **escalado o filtrado de video**.

    🎉🚀 **AMD Radeon HD 5000/6000/7350/8350 [Discrete]** (dedicada) Series con **antiX** 🚀🎉

    🎉🖥️🔧 #antiX #AMD #HardwareTest #jellyfin #docker #GPU #vaapi #ATI #Radeon #retro #old #IPTV

  23. 🚀 **Un poco de historia:**

    🎮 La **AMD Radeon HD 5000 Series Cedar**, parte de la familia **Radeon HD 5000**, fue lanzada en **2010**. 🌟

    🖥️ **Cedar** se enfocó en los modelos de gama baja como las **Radeon HD 5450** y **HD 5550**, perfectas para sistemas de bajo consumo y bajo costo. ⚡

    💡 Ofrecían soporte para **DirectX 11** y reproducción de video en **alta definición**. 🎬✨

    #AMD #Radeon #Cedar #2010 #antiX #AMD #HardwareTest #jellyfin #docker #GPU #vaapi #ATI #Radeon #retro # old #IPTV

  24. I wrote an article on how to quickly (13x speedup) convert an video to using and to upload it to respecting its restrictions 🎬

    paulox.net/2023/05/03/quickly_

    Thanks to Michael Kennedy @mkennedy , Samuel Colvin @samuelcolvin and Sebastián Ramírez Montaño @tiangolo for the interview they did at 2023 🇺🇸

  25. #GStreamer 1.24 got released today and comes with explicit modifier support for DMABuf. Fittingly the MR to add support for that to the #PipeWire Gst plugin also just landed.

    This fixes some long standing issues where things could terribly break - one example being #vaapi encoding on Intel.

    So if you have an app that you'd like to support screen sharing on Wayland (and uses #GStreamer): the upcoming cycle will be a great time to start with that!

    gitlab.freedesktop.org/pipewir

  26. Sooo I spent all of yesterday troubleshooting a bug in my code interfacing with VA-API. Even called in @ryze for artillery support. And guess where the issue was?

    Intel's iHD driver doesn't implement x11 vaPutSurface correctly.

    *headdesk*

    #VAAPI #Intel #X11

  27. Haven't posted in a long time, but I am just so elated that I finally have #vaapi decoding running under #chromium and #wayland finally!!! And on #aarch64 as well. A note to anyone testing the new patches make sure you don't have #use-out-of-process-video-decoding enabled in chrome://flags There is a bug that is causing that and vaapi decoding to fail.

  28. Side note: Does anyone have tips for #videoacceleration with #sunshine on #amd? I have an RX 5700XT which I pass through to my gaming VM. The performance in game is as expected, but the encoding performance is frankly disappointing with #vaapi, both for h264 and h265, and amf requires Windows as of now, which I really don't want to bother with.

  29. Update regarding #wayland zero-copy video playback (using hardware planes): with a few small patches it works with #Chromium, both with #vaapi (Intel/AMD) and #v4l2 stateless.

    Here a short video using a #rk3399 - the #PINE64 #PinebookPro - playing a 4k 60fps video - only possible with hardware plane offloading. Playback is *almost* smooth already (~50fps), the goal is to catch up with #GStreamer where we get stable 60.

    I hope this will all get upstreamed in the coming months.

  30. nerd stuff.

    I have a Kaby Lake CPU computer I just upgraded from Xubuntu 20.04 to 22.04, as 20.04 has gone end of life
    .
    Almost everything works fine except VAAPI hardware video decoding - but vlc and mpv video players do play fine with hardware decoding fine.

    Parole, totem (gstreamer based) and browser don't work with hardware decoding.

    Not a deal breaker but annoying as this stuff should be all sorted out, and the previous version worked fine.

    I've tried a bunch of the suggested fixes of installing/uninstalling intel-media-va-driver-non-free and gstreamer1.0-vaapi
    setting LIBVA_DRIVER_NAME etc - no dice.

    looks like this bug or similar?

    bugs.launchpad.net/ubuntu/+sou

    #Ubuntu
    #Xubuntu
    #VAAPI
    #KabyLake

  31. If you were concerned about #Fedora losing some of the native graphics processing bits in mesa (#vaapi, #h264, #h265, #va1, etc.), #RPMFusion now has mesa-freeworld in testing to bring it back.

  32. nerd stuff.

    I have a Kaby Lake CPU computer I just upgraded from Xubuntu 20.04 to 22.04, as 20.04 has gone end of life
    .
    Almost everything works fine except VAAPI hardware video decoding - but vlc and mpv video players do play fine with hardware decoding fine.

    Parole, totem (gstreamer based) and browser don't work with hardware decoding.

    Not a deal breaker but annoying as this stuff should be all sorted out, and the previous version worked fine.

    I've tried a bunch of the suggested fixes of installing/uninstalling intel-media-va-driver-non-free and gstreamer1.0-vaapi
    setting LIBVA_DRIVER_NAME etc - no dice.

    looks like this bug or similar?

    bugs.launchpad.net/ubuntu/+sou

    #Ubuntu
    #Xubuntu
    #VAAPI
    #KabyLake

  33. nerd stuff.

    I have a Kaby Lake CPU computer I just upgraded from Xubuntu 20.04 to 22.04, as 20.04 has gone end of life
    .
    Almost everything works fine except VAAPI hardware video decoding - but vlc and mpv video players do play fine with hardware decoding fine.

    Parole, totem (gstreamer based) and browser don't work with hardware decoding.

    Not a deal breaker but annoying as this stuff should be all sorted out, and the previous version worked fine.

    I've tried a bunch of the suggested fixes of installing/uninstalling intel-media-va-driver-non-free and gstreamer1.0-vaapi
    setting LIBVA_DRIVER_NAME etc - no dice.

    looks like this bug or similar?

    bugs.launchpad.net/ubuntu/+sou

    #Ubuntu
    #Xubuntu
    #VAAPI
    #KabyLake

  34. nerd stuff.

    I have a Kaby Lake CPU computer I just upgraded from Xubuntu 20.04 to 22.04, as 20.04 has gone end of life
    .
    Almost everything works fine except VAAPI hardware video decoding - but vlc and mpv video players do play fine with hardware decoding fine.

    Parole, totem (gstreamer based) and browser don't work with hardware decoding.

    Not a deal breaker but annoying as this stuff should be all sorted out, and the previous version worked fine.

    I've tried a bunch of the suggested fixes of installing/uninstalling intel-media-va-driver-non-free and gstreamer1.0-vaapi
    setting LIBVA_DRIVER_NAME etc - no dice.

    looks like this bug or similar?

    bugs.launchpad.net/ubuntu/+sou

    #Ubuntu
    #Xubuntu
    #VAAPI
    #KabyLake