[Bug 754438] oggdemux misbehaviour when seeking

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=754438

--- Comment #22 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> ---
(In reply to Sebastian Dröge (slomo) from comment #21)
> (In reply to Vincent Penquerc'h from comment #20)
> > Can a flush stop *really* come through while you're busy in the streaming
> > thread ? I see it for a flush start, but a flush stop ?
> 
> That's exactly my point. Why would your code be inside the streaming thread
> at all? The streaming thread is supposed to be shut down before the
> flush-stop is sent. And after it starts again there should only be the new
> data.

While would the code be inside the streaming at all ? It is in the streaming
thread when executing code like
gst_ogg_demux_seek_back_after_push_duration_check_unlock, which sets up the
flushing seek.
After it starts again, there will be new data, yes. And just before that, the
flush stop event will have arrived, and so the discard_till_flush flag will
have been reset, as I want/expect.

> You mean oggdemux seeks (i.e. does a stream event) from its own streaming
> thread? That's not allowed

Well, not directly. It creates a seek event in the streaming thread, and saves
it in the object. It will be sent by.... I forget... looks like a separate
thread that's spawned for that at pad activation.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.