After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760707 - appsrc/sink: Add functions for catching/injecting events
appsrc/sink: Add functions for catching/injecting events
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-01-16 10:03 UTC by Sebastian Dröge (slomo)
Modified: 2018-11-03 11:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2016-01-16 10:03:04 UTC
This is mostly useful for custom events. Any reasons not to do that? Should we prevent using it for standard events that are handled internally (e.g. to prevent setting different caps on the caps property than in the caps event)?
Comment 1 Tim-Philipp Müller 2016-01-18 11:39:19 UTC
Sure, why not.

For appsrc, you can already do that with gst_element_send_event(appsrc,event), so it's just a convenience function, right? We could special-case the CAPS and EOS events and call our equivalent API then to make sure it's handled right.

For appsink it's a bit more tricky, I guess we'd keep events and buffers serialized and if someone pulls out a buffer, even though an event is next, then the event just gets dropped (for backwards compat)?
Comment 2 Olivier Crête 2016-01-18 19:19:07 UTC
How would a custom function to inject events be different from gst_element_send_event() ?
Comment 3 Tim-Philipp Müller 2016-01-18 19:35:12 UTC
It wouldn't, it's just more discoverable.
Comment 4 Sebastian Dröge (slomo) 2016-01-19 07:53:20 UTC
Also does send_event() on appsrc put serialized events into the queue and only send them when it's time? IIRC basesrc will send them right before the next buffer or something like that.

But for that we'll just have to override GstElement::send_event() in appsrc anyway. So yes, no behaviour difference to gst_element_send_event() but more discoverable.


And appsink would work like Tim mentioned. And there would be some pull_event() or maybe pull_object() (?) or something to check the type of the next thing to pull? And a new callback/signal to notify about that.
Comment 5 Sebastian Dröge (slomo) 2016-07-08 07:18:51 UTC
*** Bug 768510 has been marked as a duplicate of this bug. ***
Comment 6 GStreamer system administrator 2018-11-03 11:44:03 UTC
-- 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-base/issues/247.