After preroll the multiqueue limits are still set to the preroll
limits if use-buffering is set to TRUE. In that case we only want
time limits on the multiqueue if upstream is seekable.
Such streams were detected as seekable, as the query on the typefind
element was testing the m3u8 file listing the actual streams, and
not going through the demuxer(s).
We now check for seekability for each multiqueue following a demuxer,
so the query will flow through the elements which might prevent seeking.
https://bugzilla.gnome.org/show_bug.cgi?id=647769
API: GstVideoRate:force-fps
Changing the framerate during playback is not possible
with a capsfilter downstream if upstream is not using
gst_pad_alloc_buffer(). In that case there's no way in
0.10 to signal to videorate that the preferred framerate
has changed.
This new property will force the output framerate to
a specific value and can be changed during playback.
The ghostpad acceptcaps functions are not valid in this case because
we don't only accept the caps accepted by the target but could also
insert converters. Fixes bug #663892.
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
Re-enable parsers in encodebin to allow more passthrough scenarios
to work. Specially the ones that require changing 'stream formats'.
i.e. h264 in mkv to mpegts.
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.
The condition is if the muxer doesn't have tag setter *and* isn't
a formatter itself. Any of those two conditions makes the muxer
good enough to not need a formatter.
gstsubtitleoverlay.c: In function 'gst_subtitle_overlay_video_sink_event':
gstsubtitleoverlay.c:1736:22: error: 'target' may be used uninitialized in this function
There's no code whatsoever that uses these macros. If anyone
ever feels the need to resurrect them, we should add them to
gstutils.h in core or libgstaudio or so.
In various use-case you want to dynamically change the framerate (e.g.
live streams where the available network bandwidth changes). Doing this
via capsfilters in the pipeline tends to be very cumbersome and racy,
using this property instead makes it very painless.
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.
Only log in debug log for now, since the check is a bit
half-hearted, its purpose is mostly to make sure people
use gst_filename_to_uri() or g_filename_to_uri().
https://bugzilla.gnome.org/show_bug.cgi?id=654673
Note that there is already a AMF detection for a different
magic, I'm not sure if that's a different format with the
same initials or not. AMF is used for a few different formats
(including video), so...
This fixes playbin2 playing Asylum modules.
https://bugzilla.gnome.org/show_bug.cgi?id=658514
This patch prevents timestamp like "1 1:00:00", which would have been seen
as hour 101 by our parser, and allow single digit hour, minute and seconds
as it's already supported by the parser, and also by other implementation
like in mplayer. This fixes bug 657872.
https://bugzilla.gnome.org/show_bug.cgi?id=657872
