[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 #34 from Florin Apostol <florin.apostol at oregan.net> ---
(In reply to Vincent Penquerc'h from comment #32)
> The penultimate (ec001f4e8511e57fdae7ed6eddf1f651fbf9ab78, call it 1/2) is
> the main patch for this bug, and is the one that is already posted here. The
> top patch (87db55f5092e9d0d03d6c0eb644bfd92ce061c11, call it 2/2) applies on
> top of 1/2, and is separate because it merges the manifest and object locks,
> as I mentioned, and I did not want to merge those two patches before you had
> had a look at whether you agreed with the apprach. I want to know this
> before working more on this, because I want to know whether to work on top
> of just 1/2, or on top of 1/2 + 2/2. If you agree with the idea (maybe not
> the details, I don't really care, as this can be changed later) of 2/2 then
> I will merge them.

Now I get it.
Yes, I agree with merging manifest lock and demux object lock and now I see
that you removed the demux object lock completely and use only one lock
(manifest lock) for locking the demux object. Which is good and a step into the
right direction.
Traditionally gstreamer accesses to an object are protected by taking that
object lock, so I propose to not confuse other readers and use the same
approach in adaptivedemux: use the demux object lock. So I propose you start
from patch 2/2 and do a find and replace and change GST_MANIFEST_LOCK (demux)
with GST_OBJECT_LOCK (demux). In this way we will have only one lock for the
demux (its object lock) and the manifest lock will be unused and can be
removed. Next we can start discussing the observations I had in comments 28 and
29.

In terms of organizing patches, I don't care how many they are. I always apply
the whole set on master and review the resulting code. So feel free to organize
your changes how you want. But I suggest that each patch contains a set of
changes that can be applied on master without breaking the product.

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