Use the intended sequence for re-using elements:
* EOS
* STREAM_START if element is to be re-used
This avoids having elements (such as queue/multiqueue/queue2) not
properly resetting themselves.
When delaying EOS propagation (because we want to wait until all
streams of a group are done for example), we re-trigger them by
first sending the cached STREAM_START and then EOS (which will
cause elements to re-set themselves if needed and accept new
buffers/events).
https://bugzilla.gnome.org/show_bug.cgi?id=785951
Only adjusting the base_ts might lead to a negative ts and as such integer
overflow into a huge timestamp which then propagates into the granulepos
and so on. Instead, resync to incoming buffer timestamp using both base_ts
and sample count rather than only base_ts.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=785948
It is forwarding messages to the playbin bus, thus forwarding messages
that contain a floating reference to the application. This generally
makes bindings unhappy, we must not leak floating references to them.
channels=1 is always mono, having it 'unpositioned' does not make
sense.
This fixes pipeline such as:
gst-validate-1.0 audiotestsrc ! audio/x-raw,channels=2,rate=44100,layout=interleaved ! audioconvert ! audioresample ! audio/x-raw, rate=44100, channels=1 ! avenc_mp2 ! fakesink
https://bugzilla.gnome.org/show_bug.cgi?id=785407
The g-i stuff for this helper lib was never usable from bindings
anyway and there are problems with the latest gobject-introspection,
so we might just as well remove the g-i integration entirely for
this lib.
Do not remove other parsebin's input streams. It will cause unexpected
removal of any input streams in multi-parsebin use case.
Basically, the purpose of blocking buffers is similar to checking
no-more-pads of chain/group. That is, it gives hint to know the timing
to remove old (EOSed) streams of the parsebin and to add/reuse slots
for new input streams. But, that doesn't mean that we need to remove
other parsebin's EOSed stream. Each parsebin has most likely its
own streaming thread and therefore EOSed time can be much different.
(i.e., much early EOS of subtitle only parsebin)
https://bugzilla.gnome.org/show_bug.cgi?id=785120
Fields related to stream handling (input_streams,
output_streams, slots, guint slot_id) where used totally unprotected
until know.
This lead to several races, especially playing back RTSP streams.
To protect those fields, the OBJECT_LOCK can not be used as we sometimes
need to be able to post message on the bus while holding it.
decodebin3 already has a lock to manage stream selection, and in the end
it makes sense to protect all the stream management fields with the same
lock which is why we reuse the SELECTION_LOCK here.
https://bugzilla.gnome.org/show_bug.cgi?id=784012
When dealing with streams/contents which have large duration, it is
more user-friendly to show more details in the high values (hours or days)
than in the microseconds.
This patch will use the following formatting schemes:
* Below 1hour : MM:SS.SSS
* Below 24hours : HHhMMmSSs
* Above : DDdHHhMMm
decodebin3 checks input streams and pushes EOS if all input streams
are EOSed. If not, fake EOS is pushed to the corresponding slot.
When adaptivedemux is used with multi-track configuration,
adaptivedemux never ever push EOS to non-selected track
because streaming thread for the slot stops with not-linked flow return.
So, decodebin3 should generate EOS itself to finish playback.
https://bugzilla.gnome.org/show_bug.cgi?id=777735
linked input of slot can be old input, so urisourcebin should check
eos state to figure out whether it's new one or not.
If not, urisourcebin never ever forwards EOS to downstream at the end
of presentation, because the old input is still there without removal
https://bugzilla.gnome.org/show_bug.cgi?id=777735
group-id in stream-start event might be updated in
parse_chain_output_probe (). This cause duplicated stream-start
twice with identical stream-id and seq-num, but only group-id is
different. Although there is no change, stream-start event will
be followed by the first buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=771088
In GStreamer 1.12 and older, the GstBaseSrc live lock used to be held while
create() virtual function was called. As appsrc pushes serialized event in
that virtual function, we ended up with some deadlock while setting the
state to NULL. This test simulates this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=783301
This makes it possible for GstDiscoverer to work with sources that
have multiple source pads and hence will trigger the creation of multiple
decodebin instances such as rtspsrc.
Based on the work of Vineeth TM <vineeth.tm@samsung.com>
https://bugzilla.gnome.org/show_bug.cgi?id=754178
... as expected later on when end time is used to determine end running time.
Otherwise the latter is determined as NONE and the resulting text buffer is
then used indefinitely.
