[gst-devel] review for event handling patch

[Mark Nauwelaerts]

Stefan Kost wrote:
> hi,
> 
> seek_event = gst_event_new_seek(1.0, GST_FORMAT_TIME,
>        GST_SEEK_FLAG_FLUSH,
>        GST_SEEK_TYPE_SET, 0,
>        GST_SEEK_TYPE_SET, (GstClockTime)song_length);
>
> Attached is a patch with my current changes. The pipeline is something
> like a bunch of audiotestsrc elements hitting a bin containg an
> oggmuxer, encoder and a filesink.
> Alternatively the bin can contain an audiosink.
> 
> When doing encoding both seek and tag events fails, when doing playback
> the tag-event fails.
> I need the seek to get an EOS (also for encoding). The tags are only
> needed when encoding.
> 
> Am I challanging gst too much? Any feedback is very welcome.

Well, I suppose depends a bit on what is meant by "fails" ;-), but I can share
some experience with similar transcoding/encoding while re-writing avimux to
0.10 (almost there) (suffice it to say that any feedback on the comments below
is also welcome):

1. I believe (from code) that oggmux "eats" SEEK events, so they don't make it
downstream (to whatever element that can do the seeking).

2. Performing a FLUSHing seek in a pipeline that has a GstCollectPads can cause
blocking, if it has more than one sink pad ? (just filed something in bugzilla).

3. If the FLUSH_START makes it to the filesink, this one can really flush some
buffers (and return GST_FLOW_WRONG_STATE); the muxer (or its writer) can be
quite "surprised" if something then does not make it to file :-(
[A non-flushing SEEK works quite nicely, though, with avimux :-)]

4. As an alternative to the event patch (not commenting on the patch itself and
not knowing the context); is it perhaps possible to insert a "cooperating
element" into the pipeline that will take care of the application's "dirty work"
of sending a tag event from where wanted (= somewhere upstream) ?

Mark.