GNOME Bugzilla – Bug 685877
Added DirectFB surface source plugin which generates a live video stream from the selected surface
Last modified: 2018-11-03 14:47:54 UTC
Created attachment 226169 [details] [review] DirectFB surface source plugin patch The source plugin is based on the DirectFB graphics system and allows users to record images from a DirectFB surface (in the same way as done by xvimagesrc plugin). The plugin gets compiled if a DirectFB installation gets autodetected through configure (pkg-config). Attached a clean patch against gst-plugins-good GIT master.
Any reason you didn't add it to the existing directfb plugin in gst-plugins-bad ? :)
No there is no special reason behind this... I just thought it belongs to the good plugins like the ximage source plugin does. Thus it was placed aside. Is there any reason this should not be included there? ;)
First a disclaimer: My company (YouView[1]) sponsored this work so we could use it in our open-source set-top-box testing system stb-tester[2]. I've not yet tried building it, so this is puely based upon reading the patch. Doing a diff between ximagesrc and dfbsurfacesrc shows that the latter is based on the former. Notably: - There doesn't seem to be any functional difference between the elements in *_unlock. - *_create seems to only really differ in that one calls gst_ximage_src_ximage_get and the other gst_dfbsurface_src_data_get - Many of the same properties are listed in *_set_property and *_get_property - *_get_caps and *_set_caps do roughly the same thing but get the information on the size/format of the captures from different places - *_fixate is almost identical, but it seems that yours might have been slightly improved WRT pixel-aspect-ratio. This might also be useful for ximage. It might be worth trying to reduce this level of duplication. This could be done by moving the common code into a helper library which could be called from both ximagesrc and dfbsurfacesrc. Alternatively, and perhaps one more fitting with how it's been done in other parts of Gstreamer would be to create a base class that calls down to derived classes for type-specfic behaviour. In this case I think we would need to have these "virtual functions": - start - stop - get_caps - grab_frame I don't know which of these approaches would be preferred by the core gstreamer devs. Perhaps Tim could comment? In addition: the function gst_dfbsurface_src_format seems to be intended to serve the same purpose as gst_dfbvideosink_get_caps_from_format in gst-plugins-bad. It might make sense to only have one of these, although I'm aware that the dfb plugins in -bad have not yet been ported to 1.0 so perhaps this would be unfeasable. [1]:http://youview.com/ [2]:http://stb-tester.com/
William, sorry, I am waiting for some comments from the gstreamer core devs first, but there do not seem to be any. For my personal opinion it seems too much what you want... Too much as in too much work/structural rework involved (which in fact kind of provokes all other plugins to follow because there are alot of code duplications across the plugins everywhere since these plugins have the same base and purpose I guess). Also I do not like the idea to share code between bad and good or other plugin trees. Please correct me if I am wrong. Any opinions or suggestion from other developers are hightly appreciated. Thanks!
Comment on attachment 226169 [details] [review] DirectFB surface source plugin patch First of all this should be added to gst-plugins-bad (that's where new code gets first), and merged with the existing directfb plugin. There's probably some code that can be shared there. Independent of this bug here it would also be great if the directfb sink could get some love ;)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/76.