gstreamer-full: new recipe

[fnadeau]

Specify library name and version: gstreamer-full/1.24.2

gstreamer and its pluggins are maintained at a different pace.
gstreamer- 1.22.6
gst-plugings-base 1.19.2
gst-plugings-good 1.19.1
gst-plugings-ugly 1.19.1
gst-plugings-bad 1.19.1
gst-libav 1.19.1

From a maintainability point of view, any update from gstreamer upstream requires 6 PR for conan to catch-up. This does not include PR for missing items such as gst-rtsp-server. Since 1.24 it is now possible to do a full build static. This would make the version bump way easier. It should be possible to have a full build dynamic, this could be added later.

There is still a bit of work and testing todo. I would like to gather interest and comment on the package.

---

• I've read the contributing guidelines.
• I've used a recent Conan client version close to the currently deployed.
  • 2.3.0, it's close, just ahead. It actually needs 2.3.0 since it uses subprojects in meson.
• I've tried at least one configuration locally with the conan-center hook activated.
  • Hook don't works with conan 2

[valgur]

This won't work, unfortunately. The user-provided values for options are not available in config_options() or even configure(). You will have to del self.info.options.xyz' the options that have no effect in package_id()` instead.

[fnadeau]

I'm not sure I follow. Doc seems to do it in configure(), see second snippet where they remove fPIC.

I have no issue with moving it to package_id(), just want to understand a bit better. Thanks

[valgur]

@danimtb Maybe you or someone else from the team can clarify whether the configure() step can be used like that or not, given that you were wrestling with similar issues in the Arrow recipe. Does the standard if self.options.shared: del self.options.fPIC even work as intended?

[fnadeau]

I'm re-reading the doc and I think it should be in configure() and not in config_option() (that was a mistake as you pointed out, only settings is populated), and not in package_id(). I'll wait for confirmation on this. Thanks

[valgur]

Looks promising at a first glance. Thank you very much!

All of the sub-packages, except for gst-libav to some degree, are very likely to be used simultaneously, so packaging them as a single unit makes sense to me.

As for the difficulty of bumping 6 different packages one-by-one. That is currently quite painful indeed, but Conan devs have mentioned that support for modifying of multiple packages in a single PR will likely be added some time soon. @RubenRBS do you know if and when that feature might land on CCI?

[conan-center-bot]

Conan v1 pipeline ❌

Failure in build 5 (e6ee8462b7ea265eee96c1c890e152aaada88125):

• gstreamer-full/1.24.3:
  Error running command conan export recipes/gstreamer-full/all/conanfile.py gstreamer-full/1.24.3@:

  WARN: *** Conan 1 is legacy and on a deprecation path ***
  WARN: *** Please upgrade to Conan 2 ***
  ERROR: Error loading conanfile at '/home/conan/workspace/prod-v1_cci_PR-23694/recipes/gstreamer-full/all/conanfile.py': Current Conan version (1.64.0) does not satisfy the defined one (>=2.3.0).
  

---

^{Note: To save resources, CI tries to finish as soon as an error is found. For this reason you might find that not all the references have been launched or not all the configurations for a given reference. Also, take into account that we cannot guarantee the order of execution as it depends on CI workload and workers availability.}

---

Conan v2 pipeline ❌

Note: Conan v2 builds are now mandatory. Please read our discussion about it.

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 @conan-io/barbarians on the PR and we will help you.

See details:

Failure in build 5 (e6ee8462b7ea265eee96c1c890e152aaada88125):

• gstreamer-full/1.24.3:
  Error running command conan export --name gstreamer-full --version 1.24.3 recipes/gstreamer-full/all/conanfile.py:

  ======== Exporting recipe to the cache ========
  ERROR: Error loading conanfile at '/home/conan/workspace/prod-v2_cci_PR-23694/recipes/gstreamer-full/all/conanfile.py': Current Conan version (2.2.2) does not satisfy the defined one (>=2.3.0).
  

---

^{Note: To save resources, CI tries to finish as soon as an error is found. For this reason you might find that not all the references have been launched or not all the configurations for a given reference. Also, take into account that we cannot guarantee the order of execution as it depends on CI workload and workers availability.}

[uboot]

I think this PR is very promising, I am highly interested. @fnadeau is there any update? Is there anything I can do to support the PR? I would be happy to contribute. So far I was able to rebase the PR branch onto the current master branch and build the package on Windows/msvc17.

[fnadeau]

Sorry I was on medical leave for a while and when I came back, this wasn't a priority anymore. I might get around to it later, I'll just close the PR to avoid bombarding conan-center-index with staled PR.

[uboot]

Hi Frédéric @fnadeau, sorry to hear that. I hope you are doing well now. Would you mind if I try to re-open the PR from the rebased version of your branch? I really would like to upstream Conan recipes for current versions of GStreamer. Your PR seems to be closest to that target. If gstreamer-full can not be merged I would consider porting the respective portions of it to the individiual, existing recipes (gst-plugins-* etc).

[uboot]

@fnadeau, sorry for pinging you again. Do you have any comments on my above question?

[valgur]

@uboot I have a fully working and up-to-date recipe for GStreamer and all of its available plugins available at https://github.com/valgur/conan-center-index. I'll open a PR at some point, but it probably won't get merged any time soon, since the recipes are rather complex at 3500 LoC combined.

[fnadeau]

@uboot : Hi, I started working again on my branch. It's not complete and requires cleanup. If you can look it up and give feedback, that would be appreciated.
@valgur : Could you check my branch, maybe we could combine efforts to have this finalized faster.

Note that i'm working on gstreamer-full and not on individual gstreamer package.

So far it works on my machine, Linux. Windows is untested. I would like to revisit the way egl, wayland, x11 option are used since it's differ a lots from gstreamer approach. Currently, there are >150 plugins that compiles in base/good/bad/ugly/libav/rtsp-server but a whole lot are still disabled.

https://github.com/fnadeau/conan-center-index/tree/feature/gstreamer-full

[valgur]

I considered the combined gstreamer-full approach, but I find keeping them separate to be more reasonable:

1. the good/bad/ugly recipes alone are pretty massive already when all plugins are correctly supported: https://github.com/valgur/conan-center-index/blob/dev/recipes/gst-plugins-bad/all/conanfile.py
2. the good/bad/ugly corresponds to difference license terms, with bad and ugly containing GPL in addition to LGPL, so keeping them separate helps in that regard as well.
3. having a single recipe does not provide a maintainability benefit since C3I gained support for changes to multiple recipes in a single PR.

I have tested my recipe version on Linux, Windows and macOS. Nearly all plugins that can be built with Conan deps work correctly on each of the three platforms.

[fnadeau]

One PR for multiple recipes, that is absolute good news. GPL plugins should be handled via a with_gpl flag or something similar, meson uses -Dgpl=enabled.
gstreamer-full allow for static build with auto-plugin registration, which is very convenient.
Since conan 2.0, I notice that we can use python file from other directories, python_requires I think. Do you think that it could be leverage so that receipie for individual gstream exist along side a gstreamer-full, all reusing some shared python files that describes the various plugins?

[uboot]

@fnadeau these are great news. I will rebase my commits onto your branch. I mainly build for Windows so this might complement your work on Linux. For now I built gstreamer-full as shared libraries (I added a shared option) but I plan to test the static "full" build asap.

[valgur]

I opened a PR for the updated gst-* recipes:

• GStreamer: update all recipes, add support for all available plugins, add gst-orc recipe #26330

These recipes are basically feature-complete. I highly doubt there's anything to be added from the gstreamer-full one here.

[uboot]

@valgur I think #26330 looks very promising, thanks a lot. I will have a look at it.

A few thoughts on single recipe (aka gstreamer-full) vs. multiple recipes: GStreamer (including its plugins) has been maintained in a mono-repo for some years now. That would actually justify a single recipe. The Qt recipe follows the same approach. On the other hand this is, admittedly, a matter of taste.

The gstreamer-full recipe potentially allows to do a static build of GStreamer. This can only work with the single recipe approach.

[valgur]

Hmm, ok, the monolithic build into a single shared library file is an interesting feature. Static library builds work just fine with the individual recipes as well, though, if that's what you mean.

An additional gstreamer-full recipe that simply links the sub-packages into a monolithic library would be quite simple to add, and might be an option.

As for Qt, having it as individual component recipes would be very welcome too to keep the scope of each one clearer and to not have to download and unzip gigabytes of sources, but it would result in a lot of redundant logic in the build setup and packaging steps. That was not the case for GStreamer, since the build config and packaging are actually very straightforward.