GNOME Bugzilla – Bug 634687
RFC: operation hints for GstElement
Last modified: 2018-11-03 12:14:18 UTC
Bug #564749 mostly blocks on the GstTagReaderIface. An alternative would be to have a set of hint-flags on GstElement. Those flags can be set on the pipeline, individual bins and even elements. Bins could propagate the hints to new children and hint-changes to existing children. The purpose of the hints is to specify the intended use case a bit more to give elements a chances for optimization. Right now gstreamer elements prepare to support everything. Some use cases 1) quickly play something from start to end - no need for metadata - no seeking/no playback rate changes - no mucking with the pipeline at all until eos 2) quick metadata reading - no prerolling - no seektable building 3) no caps changes (video in fullscreen) - quicker pad_alloc or even no need to check for caps changes in basetransform No proposal for a set of hints yet :/
An alternative to use-case flags would be a means of telling that the app is not interested in certain message and not going to send certain events and queries. At least that could cover 1) & 2)
One more item for the initial comment category 1) is avoid building the GstIndex (like it is done in QtDemux now).
> avoid building the GstIndex (like it is done in QtDemux now) This is usually achieved by not setting one in the first place.
Created attachment 185691 [details] [review] element: implement hint flags Straightforward approach to implementing suggested hint flags. Obviously one can up with all sorts of if'ing examples/applications of demuxers skipping some index or metadata parsing steps depending on configured hint flags, but not that much point until API to do so is agreed upon and stabilizes.
Review of attachment 185691 [details] [review]: Looks good. Few small comments below. I wonder if we want to make this an element property (then we can test this on gst-launch). The we could also use the property-flags to document that e.g. it cannot be changed in state >=PAUSED (imho a sensible restriction). ::: gst/gstelement.c @@ +550,3 @@ + * @hints: the hints to set. + * + * Sets the hints of an element. See gst_element_get_base_time(). copy'n'paste mistake here in the reference. @@ +566,3 @@ + GST_OBJECT_UNLOCK (element); + + GST_DEBUG_OBJECT (element, "set hints=%08x, old %08x", hints, old); This will yield a compiler warning about unused var 'old' when logging is off. ::: gst/gstelement.h @@ +61,3 @@ + * it to optimize for that purpose and possibly discard unneccesary actions + * and steps. + */ Maybe mention, that by default elements will prepare for all features to be used.
Created attachment 185791 [details] [review] element: implement hint flags Next version with some adjustments as suggested. Maybe the hint type flag registering belongs elsewhere, but for now it is "tucked in there".
Comment on attachment 185791 [details] [review] element: implement hint flags Looks good to me, what shall we do about this? Apart from that you can let the GType of the flags get generated by glib-mkenums somehow
Comment on attachment 185791 [details] [review] element: implement hint flags This should be implemented with GstContext, and perhaps it should just be part of a bigger GstPipelineContext or GstBinContext or whatnot.
IMHO GstPipelineContext/GstBinContext would not be a good name. A GstContext implies some shared state. But indeed we could implement a GstUsageHintContext.
Whatever the name, it would be shared state that's propagated through the pipeline hierarchy. The point of the suggestion was to have a more general context struct which can be used for this but also other things.
-- 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/gstreamer/issues/17.