-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Experiment] FFmpeg backend for Qt6 QtMultimedia and support for VAAPI drivers #23089
[Experiment] FFmpeg backend for Qt6 QtMultimedia and support for VAAPI drivers #23089
Conversation
…d on component name changes. Also adds 'with_cuvid' option.
… is super slow for such a large file, even compared to mirrors oceans away)
…end for qtmultimedia. Attempts to re-enable 'with_pulseaudio` because it is required for the ffmpeg plugin. Attempts to override Qt cmake find files to find conan ffmpeg+libva+pulseaudio.
🤖 Beep Boop! This pull request is making changes to 'recipes/ffmpeg//'. 👋 @MartinDelille you might be interested. 😉 |
🤖 Beep Boop! This pull request is making changes to 'recipes/qt//'. 👋 @ericLemanissier @jwillikers @MartinDelille @paulharris you might be interested. 😉 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…nctioning) media player example
This comment has been minimized.
This comment has been minimized.
self.cpp_info.set_property("cmake_target_name", "intel-media-driver") | ||
self.cpp_info.set_property("pkg_config_name", "intel-media-driver") | ||
|
||
self.cpp_info.components["intel-media-driver"].libs = collect_libs(self) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should avoid using collect_libs
if possible. Since this is a runtime-loadable plugin, I'm not sure that you even need to provide a library in this way.
You'll want to make the VA-API libraries accessible at runtime:
self.runenv_info.prepend_path("LIBVA_DRIVERS_PATH", os.path.join(self.package_folder, "lib", "dri"))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point on the libs bit, this seems like it can be removed altogether since libva always runtime loads it and nothing ever depends at link time on it.
Regarding the VAAPI env variables, I thought about this when I originally wrote this recipe, but ultimately ended up setting those variables in my consuming application. We give users the option to set both the path to look for VAAPI drivers and select which one they'd prefer to use, as we found support widely varied across hardware targets and OS versions.
Still might make sense to set it here anyway and the user can just override it if they need. By adding it, there is at least a chance for things to work out of the box.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think it might be worth setting here and letting consumer's figure out whether or not to include it as a dependency as appropriate for the specific system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thought just now, how would you expect to handle the case where there are two VAAPI driver packages that both do this?
As an example, in our app we pull in both intel-media-driver
and nvidia-vaapi-driver
and the correct one can be used by the application based on the hardware it is running on. There can only be one LIBVA_DRIVERS_PATH
, so it seems like the value couldn't be the individual package folder itself in that case?
We handle this in our consumer conanfile.py
by merging dri/<driver-name>.so
for each package into a single thirdparty/dri/
during our consumer's generate()
step, then LIBVA_DRIVERS_PATH
can be set to that one directory and find any conan-installed VAAPI drivers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seriously? That seems like a ridiculous limitation. Do you know if there's a good reason for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I found this: /~https://github.com/canonical/snapcraft/pull/3591/files which seems to indicate someone at least tried to append a path to that variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha! It should work with multiple paths: intel/libva#639 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/~https://github.com/intel/libva/blob/907b2b5405ca1091b4360bf35060e143bd704b62/va/va.c#L393
Great thanks, just validated it myself in the source. Good find!
…ires ffmpeg and puts vaapi drivers in the correct directory
Conan v1 pipeline ❌Changes not allowed in build 4:
One or more of the folder/files added are not allowed into the repository. Conan v2 pipeline ❌
The v2 pipeline failed. Please, review the errors and note this is required for pull requests to be merged. In case this recipe is still not ported to Conan 2.x, please, ping See details:Changes not allowed in build 4:
One or more of the folder/files added are not allowed into the repository. |
As of my last push, I now believe I have everything working together. Qt's MediaPlayer loads a remote MP4 containing h264, loads the FFMpeg plugin, and FFmpeg reports that it has found our conan-provided
The "cuda" HWAccel decoder (h264_cuvid in ffmpeg) also works:
I also fixed some issues with qtimageformat while I was at it, and brought in my fixes to the whole libsndio->pulseaudio chain, and tested that audio decoding/playback through ffmpeg was also working correctly. Now that everything works as a proof of concept, if there is any advice/feedback on any element of the approach at a high level, I'd be glad to hear and iterate on it here for a bit longer. From there, I can split things out into individual PRs per recipe and close this PR. |
Closing this PR to avoid new CI actions, as it has multiple recipes. Please, feel free to open new PRs splitting it. Thank you! |
Attempts to add support for building Qt6.4+'s FFMpeg backend for QtMultimedia.
This PR contains several changes to try and work towards functional ffmpeg-based hardware decoding (and other multimedia functions) within Qt6, which shifted focus from their gstreamer-based backend to ffmpeg in Qt6.4, so as to target all platforms with one library.
This is not meant to ever be merged, but to serve as grounds for discussion to figure out the right way to achieve these goals.
The impetus behind these changes come from difficulties we have had when trying to use conan-packaged ffmpeg within our Qt application. We were originally using Qt's official release binaries, but once Qt shifted to ffmpeg and added support for ffmpeg's hardware decoders, we discovered that we had a dependency conflict between the ffmpeg version Qt built and statically linked against (used by their MediaPlayer QML element, among others) and our conan-supplied shared version of ffmpeg+libva. (context, if desired: https://bugreports.qt.io/browse/QTBUG-122757)
We are now trying to shift to using the conan Qt recipe, but there is currently only support for the gstreamer qtmultimedia backend. Upon trying to follow the same process within the recipe as the gstreamer plugin, I ran into some hurdles:
with_pulseaudio
was forbidden by the recipe due to some outstanding bug/build limitationI've included a non-trivial Qt application, which I am trying to use to test the various aspects of the Qt recipe that I ultimately depend on. It isn't complete yet, because I'm stuck on the Qt6 package build with the current conan option set.
My current blocker is a long list of linking errors to pulseaudio symbols:
So my next step is to figure out what is wrong with the attempted inclusion of pulseaudio into the recipe, most likely relating to the cmake find file.
Any advice/feedback on this effort is much appreciated.
Some random notes:
nvidia-vaapi-driver
recipe or thelibva
recipe which preventednvidia-vaapi-driver
's meson configure process from finding libdrm. I had a custom libva recipe of my own (from before there was one in conan center) which worked, so I replaced the libva recipe content with my own, just to get things working. This required a change in ffmpeg as well, to make sure it found the correct target components.cuvid
decoding support in the ffmpeg recipe, such that it builds, but I haven't been able to test it yet.