[gst-devel] handling seeking in audio decoder plugin

[Sameer Naik]

got it. thanks for the info.

Regards
~Sameer

On Fri, Dec 4, 2009 at 4:21 AM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:
> On Mon, 2009-11-30 at 22:32 +0530, Sameer Naik wrote:
>
>> According to events design doc, the plugin is supposed to discard any
>> input data it receives after the GST_EVENT_FLUSH_START event. This
>> call is not serialized. Which means the chain function would have to
>> be sprinkled with the is_flushing check, which is not very desirable.
>
> That's not how it works. The flush-start would be pushed out of band
> from a thread other than the streaming threads (and your sink event
> handler would/should pass it downstream). Pads will set themselves
> automatically to flushing when they receive flush-start. In your chain
> function you will then receive a wrong-state flow return when you do
> gst_pad_push() or gst_pad_alloc_buffer(), at which point you'd stop or
> skip the processing/decoding and bail out by returning wrong-state
> upstream. You won't receive data after the flush-start automatically,
> you just have to make sure you bail out quickly if needed.
>
> Cheers
>  -Tim
>
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>