This allows us to easily get ahold of all pads on a stream-topology message, including
pre-decoder ones, while "pad" only gives us access to the raw pads (as used by discoverer).
Set up targets on READY->PAUSED state change to passthrough by
default. This prevents the targets from being unset on the
first run, while the 'raw' variable would mean that some
target is set.
The identity element should be handled by the GstBin's cleanup,
removing it on the remove_elements function might remove it
too soon, as this function can be called directly from playsink
The playsink was nastily poking a boolean in the structure.
Make those booleans properties, so we are told when they change,
and rebuild the conversion bin when they do.
Some cleanup to go with it too.
https://bugzilla.gnome.org/show_bug.cgi?id=661262
ie, audio/x-raw- for audio, video/x-raw- for video.
Add a trailing - to be more specific. I doubt there's anything
like audio/x-rawhide or something, but you never know.
https://bugzilla.gnome.org/show_bug.cgi?id=661262
The code was doing counterintuitive rewiring of pads when the
bin did not contain any elements. We now add an identity element
in that case, which makes it simpler, and should fix the AC3
passthrough mode when using pulseaudio (but I don't see the bug
here so can't test).
https://bugzilla.gnome.org/show_bug.cgi?id=661262
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.
If the pad block never happens because there is no data flow at all, the
callback is never fired and the reference is never released. This causes a
reference cycle between the pad and element, so valgrind is not very vocal
about it (memory is still reachable).
The bins' getcaps was bypassing the inner elements, and thus
failing to account for the caps transformations they allow,
which caused YUV video pipelines to fail with ximagesink, which
does not support YUV, even though the convenience bin includes
a colorspace converter for just this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=660816
The new code was checking for a prefix, and would find video/
first. Check in two passes, first checking for a perfect match,
and falling back to a prefix check if nothing was found.
https://bugzilla.gnome.org/show_bug.cgi?id=657261
The fact that a decoder is not compatible with the fixed sink
is currently happenning in the case where we have hardware accelerated
video decoders on the system (especially vaapi elements that are actually plugged),
and the user is providing a sink that doesn't support the surface.
A simple example that shows how it used to crash on a system where gstreamer-vaapi
is installed:
gst-launch playbin2 video-sink=xvimagesink uri=/codec/supported/by/vaapi
What we are now doing in this case, is avoid using the accelerated
decoder and plug a "normal" decoder instead (if avalaible).
This commit doesn't handle the case where we have hardware accelerated
demuxing.
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.
This reverts commit b0b4e286c8.
We agreed that the previous (pre-.35) behaviour is broken and a bug and the
current behaviour is correct, deterministic and allows the application to
handle stuff properly while the old behaviour can't be handled properly by
applications and just worked in some applications by luck.
The solution to the problem that was solved by relying on the old, broken
behaviour would be, to make decodebin2/playbin2 more aware of decoders and
improve the autoplugging of decoders by considering the caps supported by the
sink instead of just using something with the highest rank.
See bug #656923.
Fixes regression since 0.10.33 where sinks that can cope with non raw
caps or custom caps are not autoplugged if there's a sink configured
with the properties video-sink and audio-sink which cannot handle
the stream. This change checks for compatibility on the configured one
and use it if success. Otherwhise it tries with the found factories.
This reverts commit a22faad18a. Instead
of disabling subtitles completelly when video stream have custom caps,
just let the sutbtileoverlay cope with them as now it's able to.
Implement handling of non raw video streams by avoiding colorspace
elements and autoplugging a compatible renderer if available. Fallback
to passthrough if no compatible renderer is found.
