GNOME Bugzilla – Bug 319178
[API] finish filler events and support them in GstCollectPads
Last modified: 2005-11-21 13:05:39 UTC
Do we need them, do we not? If yes, how should they look like? etc. This is just a reminder bug to make sure it's not forgotten about before 0.10. In 0.8 we had this API: #define gst_event_new_filler() gst_event_new(GST_EVENT_FILLER) GstEvent* gst_event_new_filler_stamped (guint64 time, guint64 duration); guint64 gst_event_filler_get_duration (GstEvent *event); In 0.9 there's only this so far: GstEvent* gst_event_new_filler();
Fillers don't need a duration, I only found out after I realized that the start time of fillers is irrelevant; all that matters is their end time (time + duration), so we can make fillers empty events with a timestamp, where the timestamp is the new position after the filler: GstEvent * gst_event_new_filler (GstClockTime time); You could also access GST_EVENT_TIME(), I guess, although this API looks slightly cleaner. I don't think we will be able to handle stuff like DVD/matroska/ogg subtitles (in-stream) or DVD menus without filler events, but then again, feel free to prove me wrong by providing an alternative implementation.
Not to forget, GstCollectPads needs to support filler events as well. For me it seems the easiest way would be to add two fields to GstCollectData: gboolean is_eos; GstClockTime filler_end_time; Then _peek_buffer(), _pop_buffer() and friends would just return NULL when the pad has received an EOS event or when there has been a filler event and it's up to the collect pads user to check is_eos first. Or maybe change _peek_buffer() and _pop_buffer() into _peek_data() and return either a GstBuffer or a GstEvent (filler or eos)?
Ug. Very complicated. I would like to avoid adding filler events for 0.10.0. Instead we should make sure that they can be added later.
I propose removing filler events from the API, provided that they can be added in during the course of the 0.10.x stable series.
I propose delaying 0.10.0 until we have a clear idea about what we need to support subtitles and such properly. I don't see how we can do that without filler events or dummy-buffers with a filler flag.
I don't think delaying 0.10 is much of an option. Fortunately it doesn't need to be delayed -- if proper subtitle support requires filler events, then we figure out what exact API is needed and add that. We can always add API, but it's better not to be stuck with API that we don't know is adequate to the problem.
Filler events removed in CVS -- also see http://article.gmane.org/gmane.comp.video.gstreamer.devel/14235