Plugin does not work: bunch of gstreamer errors in console #8
Comments
|
It is also possible that the plugins can just not be found properly. Is this the complete GStreamer log? I think there should be more log messages before those. |
It is huge, do You want to attach it completely? The only error in the log is this mentioned above: I also guess Your plugin did not deploy some gstreamer plugins to the bundle as they were not installed in docker, so now I've installed them and rebuilding currently with such packages installed in build image: |
|
The plugin just copies whatever is available on the system. At the moment, it cannot detect which plugins are really needed. Therefore, installing all plugins is a good idea. PRs welcome that implement some detection. |
I see. So I installed all the plugins however have same error I got for See this line from the above: I see this file is not packaged to the bundle or packaged only ? x265 plugin loads and works fine according to the logs. |
|
Please try running |
Checking under Ubuntu 18.04 docker image:
|
|
Can you please rerun this on the x265 gstreamer plugin |
Ok, but why do you need 265:264: |
My bad. Would you mind to share your AppImage? In case it is open-source software, please provide a link to your repository and ideally to your build scripts. |
|
It is a fork of QGroundControl, not open for now sorry. But I can give You build scripts of course: replace these lines master/deploy/create_linux_appimage.sh#L86-L93 with To run execute: where:
|
|
I also tried to add these switches to However it did no helped: it deploys only 1 of it - Copying files manually to the bundle did not help as well ( Same error: Strange |
|
That second library in From the name, I would have assumed that the 10-bit library just implements some 10-bit codec, but is not necessarily required... |
Yes, I thought the same. However solved for now by upgrading gstreamer to the latest stable version - 1.18.5 which has only 1 library file there in
Guess the same.
I do not know, as You see GStreamer tried to load it in our app. |
|
Video works for us now on some machines after gstreamer upgrade, on some not - they have another error: I see that Could You fix gstreamer plugin to deploy them as well please? |
|
Latter is solved by putting Intel Media SDK libraries inside the bundle manually: So now video works everywhere! |
|
Another error on Ubuntu Touchpad: 1st try:To solve I'd also put above libraries manually like this: however got above error again. Seems GStreamer requires these paths to be preserved. Why 2nd try:To solve tried to copy libs to the AppDir manually before However above does not work as well, same error: Any ideas how to solve? Seems same problem as with x264 10-bit library error: it tries to load files from So I think there is a lot to polish in |
Feel free to contribute. I'm trying to help here. You have not yet provided an example project that I could test changes against. I do not have time to set up my own environment from the few information you provided so far and fiddle until I have an environment that is similar to yours so I can reproduce these issues. Also, now there are more cases added to this issue. Please open a new issue about your driver stuff. You're doing some very special stuff that has never been required before. This plugin is also relatively new and doesn't have sophisticated deployments for everything. It needs some love. I have some time next week that I want to dedicate to linuxdeploy and this plugin. How far has your project deviated from standard QGroundControl? I assume your build scripts can be shared or adapted at least to exclude problematic parts (otherwise helping would be difficult anyway), so we could create a fork of QGroundControl, you could integrate your scripts and I can then try to reproduce these issues myself.
Copying them into one directory is the default behavior of linuxdeploy. In the vast majority of all deployments, the libraries can live just fine in a singular directory. In fact, this is the case for the majority of all libraries on any distributions. Distros may add an architecture triplet component to the path, but in single-architecture AppImages, this is not needed, thus that path is exclued. Plugin systems etc. are not supported directly by linuxdeploy, i.e., "Exact paths", or rather hardcoded paths, are a bad misconception and an antipattern that used to dominate build systems and distributions as well. They effectively prevent relocation, a property needed for AppImages to work. See also https://docs.appimage.org/reference/best-practices.html#binaries-must-not-use-compiled-in-absolute-paths. The reason to use hardcoded paths is to reduce the need for path calculations within applications: you just expect resources to be at a specific path. In most modern frameworks (e.g., Qt), one can locate resources during runtime by resolving paths relative to known locations, typically relative to the main binary. This kind of relocatability is implemented by linuxdeploy to make sure the linker can find shared libraries during runtime using relative paths. We set the In case some plugins/drivers/whatever you need hardcode paths, they are not relocatable and deploying them in an AppImage will be a challenge. We might have to set environment variables etc. to help GStreamer etc. find them (in fact, we already use some environment variables for this). Note that environment variables induce new issues. But one step after another. For the record: deploying any kind of driver in AppImages is highly discouraged. Hardware-dependent libraries typically require said hardware to be in place. Obviously this is going to lead to new issues on other hardware which does not provide said requirements. You see, there is some complexity. Please open a new issue about your driver stuff. |
I did! Read above comments: #8 (comment) - QGroundControl + drone simulator is enough for testing. PX4 sim to run: https://docs.px4.io/master/en/simulation/gazebo.html#running-the-simulation
Regarding this functionality: transfer video from drone to QGroundControl - code is the same - was not changed, so You may use pure QGroundControl for this. However problems differ for our machines:
Was able to fix the latter as well - found the solution here: https://stackoverflow.com/a/29693295/630169.
Yes, we can do of course, that is easy, however like I said just need to replace few lines in master/deploy/create_linux_appimage.sh#L86-L93 file. ☝️
Thanks!
Of course, but |
|
Can you please fork QGroundControl, make the changes and post a link? |
Sure. Like I mentioned above we were able to fix all the issues, however I think You may use them of course to polish Latest GStreamer from PPA could be necessary there as well: https://askubuntu.com/q/1377561/130585 Original QGroundControl.AppImage does not have GStreamer libraries within and works on Ubuntu 20.04 just utilizing system GStreamer, and does not work on 18.04. Our AppImage works on both. To test simulator is necessary: https://github.com/PX4/PX4-Autopilot |
Still gstreamer errors in console:
In gstreamer log (
GST_DEBUG=*:DEBUG,decodebin:LOG) seeing this error:May be some plugin is still missed and need to add with
--library=switch?The text was updated successfully, but these errors were encountered: