[Bug 754438] oggdemux misbehaviour when seeking

[GStreamer (GNOME Bugzilla)]

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

--- Comment #21 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(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.


> > The bigger question is why it is still handling data at this point.
> 
> What point ? I'm tempted to say the following, but I'm guessing that I'm
> missing your point, so it's unlikely to be responsive, but here goes:
> 
> The request for a flushing seek is triggered by oggdemux from within the
> processing of data in the streaming thread. It happens when the data being
> processed is deemed to be too close to the end of the stream (itself being a
> hack, but whatever). At that point, it needs to cancel all the rest of the
> data it's got coming at it, until a flush stop signals that new data from
> there on is from the seeked to place (and thus picking a timestamp from
> there is known to be from the right place).

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

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