Every instance of calling bin_do_message_forward() first took the
object lock, so that bin_do_message_forward() could drop it and
then reclaim. Instead, only take the object lock afterward where
needed.
This prevents situations where a first branch would get seeked and
receive a buffer before all branches got seeked, and thus collected
would get called based on EOS from the previous segment.
As a consequence, during the process of seeking, don't decrease
the eospads number when a FLUSH_STOP is received.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724571
Add loop_type and repeat_count fields to GstTocEntry plus setters and getters.
This allows to represent edit-lists in a toc as well as loops in instruemnts (wav, xi).
API: gst_toc_entry_set_loop
API: gst_toc_entry_get_loop
From the test case:
/* This test creates a multiqueue with 2 streams. One receives
* a constant flow of buffers, the other only gets one buffer, and then
* new-segment events, and returns not-linked. The multiqueue should not fill.
*/
If one of the queues goes EOS and the other returns NOT_LINKED the stream
can be considerered EOS as a NOT_LINKED means that one of the branches has no
sink downstream that will block the EOS message posting.
https://bugzilla.gnome.org/show_bug.cgi?id=725917
Use the pad as object for logging to get more context. Use
gst_pad_store_sticky_event() instead of sending the event. This avoids a warning
as here the pad is not yet linked and we actually don't want to send anyway.
Use the last result as a default when pushing a item from a single queue,
otherwise the status gets reset to _OK when pushing events.
This causes problems when mistakenly activating a not-linked stream
that is being ignored upstream as it is not being used (adaptive
scenarios), it will make the multiqueue post a buffering message
on a pad that won't receive buffers
https://bugzilla.gnome.org/show_bug.cgi?id=725917
This ensures that the lock of the internal pad is held while referencing
it's peer (= the target pad), which ensures that the peer is not
going to be unlinked/destroyed in the meantime.
https://bugzilla.gnome.org/show_bug.cgi?id=725809
This was plain text that had all list items one after the other (including a
repeated number). Now it will atleast look good when processed with gtk-doc
1.20.
Tag allocated buffers with TAG_MEMORY. When they are released later,
only add them back to the pool if the tag is still there and the memory
has not been changed, otherwise throw the buffer away.
Add unit test to check various scenarios.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724481
