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
GST_CHECKS can be simply "test*" to run run all tests (including those that are
marked broken). Update the sparse comments a bit to tell how this works.
Make a method to get the seeking threshold. If data is further away from
this threshold we want to perform a seek upstream.
When the current downloaded range can merge with the next range,
actually include the data of the next range into the current range
instead of discarding it. Also decide if we seek to the write position
of the merged range or continue reading.
Don't set the size to -1 in automatic_eos mode (which also updates the
duration to -1). We only want automatic_eos mode influence the maxsize
calculations without any side effects.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724564
Using info from gst-plugins-base/docs/design .
Encoded streams might make use of the raw properties, so list them all under foo/* .
For foo/raw, only note which of these properties are mandatory.
I didn't take a closer look at the raw formats yet. Those might still be out-of-date.
https://bugzilla.gnome.org/show_bug.cgi?id=724187
