сб, 14 дек. 2019 г. в 17:27, Brad DeMorrow <b...@demorrow.net>: > > Thank you both again for the explanation. That makes sense now. > I've updated the libva Makefile to simply use 0.0 as the SHARED_LIBS versions > and I've removed the post-install hook that adds additional symlinks for no > good reason. > > I added patches to remove the explicit shared library versions from the > dlopen calls in the > intel-vaapi-driver port and it now works as expected without the symlinks. I > looked through > the other ports for hard-coded dlopen calls as well, but found no more. > > libva-utils had an extra binary being installed called test_va_api as a > result of building the test suite. > I added a post-install hook to remove this binary before it's packaged. I > hope that's the correct approach. > > Please find the updated tarballs attached with all of the changes we've > discussed thus far. > > Thank you again for helping me test this and get it all straightened out.
And here is a somewhat working gstreamer-vaapi port (intended to be unarchived in multimedia/gstreamer1 directory). Decoding works, encoding MPEG2 works, encoding H.264 doesn't (still investigating). Since the latter is what I really want, I won't push the port in current state, but anyone willing it in - be my guest. :) And if there are any GStreamer gurus which could tell the reason encoding fails, here are the logs (for MPEG2 and H.264 encoding, both in full and trimmed for diffability versions) and test video I'm using: https://ohvost.ru/dnl/gstreamer-vaapi-encoding-logs.tgz https://ohvost.ru/dnl/test.yuv.xz -- WBR, Vadim Zhukov
gstreamer-vaapi_port.tar.gz
Description: application/gzip
