Seungmin Kim

Sounds good. But they do still need to be mapped adequately (for instance `/etc` vs `/usr/share` ~~or `/usr/lib`/`/usr/lib64` vs `/usr/lib/x86_64-linux-gnu`~~).

Thanks for the information. Please have patience.

Because I need to see how things work after merging, I am merging now and continuing on in `main`.

@belotv This is evidently related to: https://discussion.fedoraproject.org/t/proprietary-video-codecs-are-no-longer-hardware-accelerated-by-default-on-amd-gpus-since-fedora-37/73723 https://baronhk.wordpress.com/2022/10/05/the-facts-about-video-codec-acceleration-on-fedora-37/ https://news.itsfoss.com/fedora-drops-vaapi-codec/ https://discussion.fedoraproject.org/t/why-is-fedora-38-missing-the-essential-gpu-driver-component-to-have-hw-acceleration-enabled-by-default/87945/3 But why it doesn't work even in AMDGPU Pro drivers is unknown.

`va` is the way forward for AMD GPUs in Linux.

> `va` is the way forward for AMD GPUs in Linux. Ah, I meant `vah264enc`, `vaav1enc`, and all other GStreamer plugins in the family. `vaapih264enc` is set to be deprecated.

@totaam Since VA-API and NVIDIA both provide hardware JPEG encoders, it might be worth looking at. Since JPEG streams can be sent pixel-by-pixel compared to video which isn't, it might...

@totaam Do you have VA-API accelerated jpeg encode in your non-GStreamer backend?

It could be possible to use libva to do it outside of GStreamer just like how you do it with `nvjpeg`.

I am interested in the components for RTP packet processing (without the encoder/decoder for now) for more supported codecs. What are we supposed to do? The major codecs relevant across...