GNOME Bugzilla – Bug 732207
bad/gst-libs: Cleanup libraries before 1.4 release
Last modified: 2014-07-11 07:42:00 UTC
Several micro-libraries have been added. We should make sure: * We only expose headers/pkgconfig for libraries that *really* need to be available outside of gst-plugins-bad * We don't have naming conflicts * base Name is conflicting with core's base directory Does this need to be public API outside of -bad ? => If so, rename to badbase ? * basecamerabinsrc Does this need to be public API outside of -bad ? * interfaces photography app-facing API Change name ? * uridownloader => Not needed outside -bad ? * video Name is conflicting with -base's video directory => Is this needed outside of gst-plugins-bad ? => Rename to badvideo ? * wayland Only two methods, apparently needed by apps Should go into video-overlay * codecparsers: KEEP People have been developping 3rd party apps and plugins (gst-vaapi) using it * gl: KEEP Needs to be public * insertbin: KEEP Needs to be public * mpegts: KEEP Needed by apps for proper dvb/mpeg-ts interaction
> * basecamerabinsrc > Does this need to be public API outside of -bad ? > * interfaces > photography app-facing API > Change name ? > * uridownloader > => Not needed outside -bad ? Let's just not touch the existing stuff at this point please? The photography interface should move to -base at some point, probably merged into gstvideo or some new image/photo/camera type lib. basecamerabinsrc may have to be public, I think the reason for its existance is that you can have SoC/API-specific source classes that expose all the special features in hardware, right? Uridownloader will probably go away in the next cycle when the adaptive plugins are merged? > * video > Name is conflicting with -base's video directory > => Is this needed outside of gst-plugins-bad ? > => Rename to badvideo ? No need to install .pc files and headers for now, right? Hopefully it can go away in the next cycle again then. > * wayland > Only two methods, apparently needed by apps > Should go into video-overlay Are we confident that we will find the right API quickly enough to move it straight to videooverlay? This lib shouldn't have been snuck in like that in the first place btw.
So to summarize, we keep everything as-is except for: * video : don't dist .pc/header files * base : don't dist it ? it's required by glmixerpad
Or maybe just leave everything as is for now? It's not like the situation is worse than 1.2...
(In reply to comment #0) > * basecamerabinsrc > Does this need to be public API outside of -bad ? I think yes. There is GstBaseCameraSrc which is supposed to be a base class for 3pad camera sources. Even if the class is not used to implement camera sources, there is still gstbasecamerasrc.h which contains the names of the needed pads. One can argue that it's an overkill to have a header just to define names of pads ;-)
What a mess. Even worse that it's all entangled now, esp. libgstgl. So how about we move GstGLMixer into ext/gl/ instead of having it as public API in gst-libs/gst/gl/ ? Then gstglmixerpad.h is no longer public API and we don't have to make the 'bad video' and 'bad base' headers.pc files public, right? And regarding libgstwayland, see bug #726193, I think we should not expose this publicly yet in this cycle.
(In reply to comment #0) > * wayland > Only two methods, apparently needed by apps > Should go into video-overlay This is not just two methods. There are two methods that should go into GstVideoOverlay or otherwise be killed, but there are also some other methods. See bug 726193 comment 14
(In reply to comment #5) > So how about we move GstGLMixer into ext/gl/ instead of having it as public API > in gst-libs/gst/gl/ ? Then gstglmixerpad.h is no longer public API and we don't > have to make the 'bad video' and 'bad base' headers.pc files public, right? Or we could just revert all the libgstgl depending on 'bad base' and 'bad video' commits to avoid the problem and sort it out in the next cycle :). I'm a little confused as to how that got in without a bugzilla review.
Matthew: any preference? (installing these other headers is of course an option but I think we should avoid it).
Reverting everything seems a bit radical, would be the lazy way IMHO :) This port of glmixer introduced no behavioural regression, fixed *a lot* of potential deadlocks and made the code much smaller! As for the "no bugzilla review", Matthew I thought I understood you had given your go to this? I didn't look into the problem, but afaiu it's just the same situation as 1.2, no reason to go and revert our nice things :)
So what's going to happen now is: 1) wayland, video and base libs won't install there headers 2) glvideomixer is moved to the plugin so it does not depend on installed headers of the above For 1.6 we hopefully can solve this mess a bit better :)
commit 92d00d0233109fb701af180a8dcc7e61ab460516 Author: Sebastian Dröge <sebastian@centricular.com> Date: Fri Jul 11 09:41:05 2014 +0200 gl: Move GstGLMixer to the plugin for now It depends on GstAggregator and we don't want to install headers for that yet. https://bugzilla.gnome.org/show_bug.cgi?id=732207 commit f701aa29b9831310b9a7da2d0de1ec37d0cce2fa Author: Sebastian Dröge <sebastian@centricular.com> Date: Fri Jul 11 09:33:57 2014 +0200 libs: Don't install headers and pc files for libgstwayland/badvideo/badbase These will disappear after 1.4.0 and it would be rather annoying if people started depending on them. https://bugzilla.gnome.org/show_bug.cgi?id=732207