[gst-devel] review for event handling patch
manauw at skynet.be
Tue Jan 24 15:02:03 CET 2006
Stefan Kost wrote:
> seek_event = gst_event_new_seek(1.0, GST_FORMAT_TIME,
> 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) ?
More information about the gstreamer-devel