This is made possible by filtering errors. This is required to let
harware accelerated element query the video context. The video context
is used to determine if the HW is capable, and thus if the element is
supported or not.
Fixes bug #662330.
With unfixed caps we can't reliably decide if the final caps
are going to be "raw" (e.g. supported by a sink) or not.
We will get here again later when the caps are fixed.
If subdrained isn't initialized to FALSE then a chain might think
that its group is drained when in fact it's not and this can cause
a switch too early or even cause a deadlock.
g_value_get_object() does not give us our own ref.
Fixes "Trying to dispose object "flacparse", but it still has a parent "registry0".
You need to let the parent manage the object instead of unreffing the object directly."
and similar warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=658416
This is done by adding a capsfilter after every parser/converter that contains
all possible caps supported by downstream elements. A capsfilter is necessary
here because the decoder is only selected after the parser selected a format
and the parser can't know what downstream would support otherwise.
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
Use the pad caps when they are available to continue the autoplugging. If the
pad caps are set, they are fixed and then we can directly continue autoplugging.
Use an accumulator for the autoplug-sort signal so that we can stop the emission
when a signal handler produced a valid result. This avoids the object handler
to overwrite the results from user signals.
Fixes#621161
If a file contains raw streams (not requiring a decoder) that we do
not want (expose-all-streams == FALSE), we would previously consider
those of unknown-type (missing a decoder) ... whereas in fact it was just
because they don't need decoders.
This only applies if expose-all-streams is FALSE.
