[Bug 755169] dashdemux: can we have multiple seek events at the same time?

[GStreamer (GNOME Bugzilla)]

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

--- Comment #7 from Florin Apostol <florin.apostol at oregan.net> ---
(In reply to Vincent Penquerc'h from comment #6)
> I agree that it seems wrong to lock gst_adaptive_demux_can_seek and not lock
> the next gst_adaptive_demux_is_live and other manifest using code, given how
> the former is implemented. I'm less sure about the other object access (ie,
> the segment use you mentioned above). Some uses of the segment are already
> protected by the manifest lock, but there are others which do not seem to be
> (eg, gst_adaptive_demux_stream_push_buffer), and I'd expect the object lock
> to be used for such, though the code doesn't seem to use it in that way, it
> seems only used for cancelled, last_ret, and streams, though not always. So
> I guess I'll try to use the manifest lock for this and test...

I would use the manifest lock to create critical sections for a set of steps
that try to reconfigure the demux object and must be performed together. For
example configuration of streams when a manifest update is received or a period
end is detected, or the reconfiguration of demux object when a seek is
requested, or a flush event is handled

What is not clear to me is when the GST_OBJECT_LOCK (demux) should be used. It
seems to guard the demux->cancelled member, but not all accesses to it are done
with the GST_OBJECT_LOCK taken, so probably this is another bug.

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