When we have a multi-stream (i.e. audio and video) input and the demuxer
adds/removes pads for a new stream (common in a mpeg-ts stream when the
program stream mapping is updated), the algorithm for EOS handling was
previously wrong (it would only drop the EOS of the *last* pad but would
let the EOS on the other pads go through).
The logic has only been changed a tiny bit for EOS handling resulting in:
* If there is no next group, let the EOS go through
* If there is a next group, but not all pads are drained in the active
group, drop the EOS event
* If there is a next group and all pads are drained, then the ghostpads
will be removed and the EOS event will be dropped automatically.
For streams at low bitrates we need to set a limit in time because the limit
in bytes might not reached too late, sometimes more than 30 seconds.
This limit can only be set if upstream is seekable (see #584104)
Closes#647769
Parsers are the only element class that are not changing the data and
could lead to an infinite loop. Other element classes like demuxers,
e.g. id3demux, can be used multiple times in a row and sometimes are.
Previously we only checked against the raw caps but we should also
check against the return value of autoplug-continue. Additionally fix
a thread-safety issue with accessing the raw caps.
...instead of copying the array. Returning NULL will result
in the original factories array to be used and prevents a useless
array copy in most use cases.
Add notes about the behaviour if multiple signal handlers are connected.
For most autoplug-* signals only the first signal handler will ever
be invoked.
Also add to the autoplug-sort docs that the signal handler can return NULL
to specify that the order should change and other handlers get the chance
to sort the array.
Where it was previously located, we would get async-done for the first
unknown-type, even if other valid streams would appear afterwards.
decode_bin_expose() will take care of posting async-done when the group
is exposed.
But we still want to post it in case the typefinding returned an unknown
type, in which case we will post it after posting an error.
These two changes ensure we do as much as possible before posting async-done.
If an error happens, the PAUSED state will never be reached. If an
application re-uses decodebin2 (like totem) where one would normally
set to READY between each file, the cleanup that normally happens in
the PAUSED=>READY codepath will never be called, resulting in the
following file to re-use the previous demuxer/decoder/...
https://bugzilla.gnome.org/show_bug.cgi?id=622807
