Description: HW video decode support for Intel integrated graphics
rpmlint is clean on the package
This package was previously rejected by Fe-Legal mainly because the code of the libva intel backend was "unreadable".
This package only bundles the backend as the wrapper is already accepted in Fedora, but I wonder if there is a need to revisit the Legal Review.
/usr/lib64/dri/i965_drv_video.so is in previous versions of Libva, but not in the current version: libva-1.0.14-1.fc16.x86_64
I found a workaround. Download the above file from the link and use rpm2cpio (must be installed) to extract it's contents. Copy the extracted file ~/i965_drv_video.so to /usr/lib64/dri/i965_drv_video.so
You can also do the same with 32-bit systems by downloading libva-1.0.13-6.fc16.i686.rpm from the link below and following the same instructions with rpm2cpio.
The libva package is in Fedora but without the i965_drv_video.so.
So an additional package can be found as libva-freeworld on RPM Fusion.
This last is meant to be obsoleted by this package if the Fe-Legal review can be re-evaluated.
With current version (1.0.15 in F-17), libva upstream doesn't even provide anymore the intel backend within libva. Instead, a new source archive that contain only the intel backend is provided.
Summary: HW video decode support for Intel integrated graphics
Update package with few clean-ups as there is only a dlopened shared object (so no ldconfig).
Just to be clear here, this package is just the same mess that we said was not okay before, just in a separate package?
(In reply to comment #6)
> Just to be clear here, this package is just the same mess that we said was not
> okay before, just in a separate package?
Actually I've double checked and the comment from benjamin still stands in few files from the previous review:
Quoting Benjamin: https://bugzilla.redhat.com/show_bug.cgi?id=518546#c39
Showing a diff between 1.0.12 and current
I expected it should be possible to regenerate the code (using the intel-gen4asm) from the ASM files that wasn't always available in the previous versions.
Actually, I'm 'only' failing to regenerate shaders/h264/mc/avc_mc.g4b src/shaders/h264/mc/null.g4b and src/shaders/h264/mc/null.g4b.gen5 at least, so I will investigate.
That been said, I may have missed another side of the problem raised by ajax:
In this case, it will mean the code may touch codec internals that can be covered. And given that this logic is not implemented in hardware, this will put a perpetual end to any libva intel backend in Fedora.
So please close the review if you think it doesn't worth to re-evaluate.
(In reply to comment #7)
> That been said, I may have missed another side of the problem raised by ajax:
> In this case, it will mean the code may touch codec internals that can be
> covered. And given that this logic is not implemented in hardware, this will
> put a perpetual end to any libva intel backend in Fedora.
> So please close the review if you think it doesn't worth to re-evaluate.
From a quick look at the libva-intel driver, it's still clearly doing motion compensation and in-loop-deblocking and a bunch of other actual video codec work in the shaders, not in the hardware. So I don't think this can land in Fedora, sorry.