gstsubtitleoverlay.c: In function 'gst_subtitle_overlay_video_sink_event':
gstsubtitleoverlay.c:1736:22: error: 'target' may be used uninitialized in this function
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
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.
This reverts commit 105814e2c7.
The general consensus seems to be that we should revert this for
now. If such behaviour is desired, we should probably enable it
via a flag. And maybe use the scaletempo plugin instead.
Make enums for the chroma siting for easier use in the videoinfo.
Make enums for the color range, color matrix, transfer function and the
color primaries. Add these values to the video info structure in a Colorimetry
structure. These values define the exact colors and are needed to perform
correct colorspace conversion. Use a couple of predefined colorimetry specs
because in practice only a few combinations are in use.
Add view_id to the video frames to identify the view this frame represents in
multiview video.
Remove old gst_video_parse_caps_framerate, use the videoinfo for this.
Port elements to new colorimetry info.
Remove deprecated colorspace property from videotestsrc.
Rework the audio caps similar to the video caps. Remove
width/depth/endianness/signed fields and replace with a simple string
format and media type audio/x-raw.
Create a GstAudioInfo and some helper methods to parse caps.
Remove duplicate code from the ringbuffer and replace with audio info.
Use AudioInfo in the base audio filter class.
Port elements to new API.
Instead of just assuming all pads are created at the same time,
remember which ones are actually new (via ->pending_blocked_pads).
This allows the following use-case to properly work:
* Upstream starts with audio-only
* Only that pad gets data, blocks and a real audio sink is created
* Upstream laters adds a video stream
* A new pad is requested, blocks and reconfiguration kicks in in
order to add a new real video sink
