Hi,
Is it okay to mix versions for various GStreamer components in the ecosystem?
For example, I do have GStreamer at version 1.22.12 installed, including gst-libav. Will everything work properly when I just update gst-libav to version 1.24.3 and leave everything else at 1.22.12?
The project claims that the 1.x series is API and ABI stable, but I’m not sure if it covers situations like I described above.
Thank you.
This is not guaranteed by the API/ABI stability. What we do guarantee with our stable API/ABI is, that running an older (1.22) dependent module (e.g. gst-libav) against a newer version (1.24) of a dependency (libgstreamer, libgstvideo, etc).
What you are asking for is forward compatibility which is not possible or feasible to support as we would not be able to add any kind of new API anywhere.
Now, in this case specific case, it may work but just know that in general, this is not guaranteed to work in every situation.
Thanks for explanation.
This leads to another question: how can I find (as somebody without deep GStreamer internals knowledge) what is the dependency tree of GStreamer components? In other words: What is the proper order of upgrading the whole GStreamer suite from 1.22 to 1.24 (or in general from 1.x to 1.(x+n)) when I want to upgrade one component at a time and keep everything stable and working? Should I upgrade gstreamer first and then all other components like gst-plugins-base, gst-libav, gst-rtsp-server, etc.? In what order?
I’m asking as a package maintainer of an rolling release operating system.
Thank you.
You can have a look at cerbero’s GStreamer packages for what we consider to be dependencies between different GStreamer modules: recipes · main · GStreamer / cerbero · GitLab. Of course, this only works if the module has publicly consumable libraries which e.g. -good, -ugly, -libav do not.
e.g. recipes/gst-plugins-good-1.0.recipe · main · GStreamer / cerbero · GitLab says that gst-plugins-good depends on core and -base.