In some cases the wait for more data was happening without updating
the buffering state, meaning the API user would not be able to notice
it should pause the pipeline and update UI to indicate that is the
case, the video would likely stutter instead.
https://bugzilla.gnome.org/show_bug.cgi?id=707648
The seqnum of the segment after a seek should be the same of
the seek event. Downstream elements might rely on seqnums to
identify events related to a seek.
This is particularly important when a demuxer maps a TIME seek
into a BYTES seek for upstream and it needs to identify the
corresponding segment event and map it back into TIME to push
downstream, possibly using the values from the original seek
event.
https://bugzilla.gnome.org/show_bug.cgi?id=707530
If a pad is removed while a collectpads element (say adder) is in a chain
function waiting to be collected, there is a possibility that an unref happens
on a NULL pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=707536
If the multiqueue has automatically grown chances are good that
we will cause the pipeline to starve if the maximum level is reduced
below that automatically grown size.
https://bugzilla.gnome.org/show_bug.cgi?id=707156
This avoids triggering plenty of extra code/methods/overhead downstream when
we can just quickly check whenever we want to set caps whether they are
identical or not
https://bugzilla.gnome.org/show_bug.cgi?id=706600
This makes gst_parse_bin_from_description() return an element instead of
a bin if there's only one element. Also changed gstparse.c to use this,
so gst-launch won't create superfluous bins.
https://bugzilla.gnome.org/show_bug.cgi?id=703405
When a buffering query is handled it uses the get_buffering_percent()
function to get some statitics. Unfortunately this function also
calculates whether the queue should be buffering and adapts the
global queue2 state in case of state transitions from/to buffering
(including whether a buffering message was posted on the bus!).
This means that there is a race which can cause buffering messages
to never posted if the global state changes happen as a result of aa
query instead of resulting from bytes flowing in/out.
Spotted by Sjoerd Simons.
Change to only query state in get_buffering_percent() and update
state only in update_buffering().
https://bugzilla.gnome.org/show_bug.cgi?id=705332
Use custom code to implement flush-stop, we can't reuse the set_flushing code
because we can't touch the live_playing flag and we need to signal the
streaming thread.
In some specific cases (like transmuxing) we want to force the element
to actually parse all incoming data even if the element deems it is not
necessary.
This property simply ignores requests from the element to enable passthrough
mode which results in processing always being enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=705621
Adds a variant of the _push function that doesn't check the queue limits
before adding the new item. It is useful when pushing an element to the
queue shouldn't lock the thread.
One particular scenario is when the queue is used to serialize buffers
and events that are going to be pushed from another thread. The
dataqueue should have a limit on the amount of buffers to be stored to
avoid large memory consumption, but events can be considered to have
negligible impact on memory compared to buffers. So it is useful to be
used to push items into the queue that contain events, even though the
queue is already full, it shouldn't matter inserting an item that has
no significative size.
This scenario happens on adaptive elements (dashdemux / mssdemux) as
there is a single download thread fetching buffers and putting into the
dataqueues for the streams. This same download thread can als generate
events in some situations as caps changes, eos or a internal control
events. There can be a deadlock at preroll if the first buffer fetched
is large enough to fill the dataqueue and the download thread and the
next iteration of the download thread decides to push an event to this
same dataqueue before fetching buffers to other streams, if this push
locks, the pipeline will be stuck in preroll as no more buffers will be
downloaded.
There is a somewhat common practice in dash streams to have a single
very large buffer for audio and one for video, so this will always
happen as the download thread will have to push an EOS right after
fetching the first buffer for any stream.
API: gst_data_queue_push_force
https://bugzilla.gnome.org/show_bug.cgi?id=705694
