By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
This new property controls the synchronisation offset between the text and video
streams. Positive values make the text ahead of the video and negative values
make the text go behind the video.
https://bugzilla.gnome.org/show_bug.cgi?id=797134
It is forwarding messages to the playbin bus, thus forwarding messages
that contain a floating reference to the application. This generally
makes bindings unhappy, we must not leak floating references to them.
We take a ref before removing which was never freeded.
The element is still alive anyway because the group has its own ref as
well.
Fix a leak with the 'test_suburi_error_wrongproto' test.
https://bugzilla.gnome.org/show_bug.cgi?id=766515
Elements usually require that all fields on their caps are present
on the fixed caps they receive. Using intersection won't verify it,
resort to using is_subset() checks.
https://bugzilla.gnome.org/show_bug.cgi?id=760477
Unconditionally adding the template caps when proxying the caps query will play
havoc with decoders that attempt to choose an output format based on some caps
features. Creating a sink that does not include those caps features and a
decoder/parser/etc that preferentially chooses some specific caps feature when
available, will always return the decoder/parser/etc template caps and choose a
feature that downstream will be unable to support.
Fix by limiting the addition of the template caps to when the result is actually
empty.
https://bugzilla.gnome.org/show_bug.cgi?id=758212
Send event directly to playsink instead of letting GstBin iterate
over all sink elements. The latter might send the event multiple times
in case the SEEK causes a reconfiguration of the pipeline, as can easily
happen with adaptive streaming demuxers.
What would then happen is that the iterator would be reset, we send the
event again, and on the second time it will fail in the majority of cases
because the pipeline is still being reconfigured
Casting to gpointer from gulong generates the following warning with
64bit Windows target MinGW:
gstplaybin2.c: In function 'pad_added_cb':
gstplaybin2.c:3476:7: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
(gpointer) group_id_probe_handler);
^
cc1: all warnings being treated as errors
We should cast to guintptr from gulong before we cast to gpointer.
https://bugzilla.gnome.org/show_bug.cgi?id=754755
If suburidecodebin is failed to negotiate (e.g file does not exist)
then free internal suburi variable so that 'current-suburi' property
returns correct status.
https://bugzilla.gnome.org/show_bug.cgi?id=751118
6a2f017bfa changed it to check the subtitle
factory caps if there is a text-sink but we fail to get its sinkpad. What
actually should be done here is to use the factory caps if there is no
text-sink at all.
https://bugzilla.gnome.org/show_bug.cgi?id=750785
There is the GstVideoMultiviewMode enum and the
GstVideoMultiviewFramePacking, which is a subset of the
multiview modes, with the same values as the corresponding
types from the full enum. Do some casts and use the right
times to avoid implicitly using/passing GstVideoMultiviewFramePacking
when a GstVideoMultiviewMode is needed.
Add GstVideoMultiviewFramePacking enum, and the
video-multiview-mode and video-multiview-flags
properties on playbin.
Use a pad probe to replace the multiview information in
video caps sent out from uridecodebin.
This is a part implementation only - for full
correctness, it should also modify caps in caps events,
accept-caps and allocation queries.
https://bugzilla.gnome.org/show_bug.cgi?id=611157
If a new pad is added after playbin has been put to READY/NULL it
should ignore new pads as it is shutting down.
This can happen when the pipeline fails to preroll (is still in READY)
and the user gives up on waiting or an error that doesn't reach
the demuxer occurs (on some event handling) and it will continue to
work and exposing pads while playbin has been put to NULL.
Without this check an input-selector is created and set to PAUSED
state, preventing playbin from properly shutting down in case it
has data blocked inside it.
Create a function to do the pad cleanup of the GstSourceCombine struct
and use it to not forget to also cleanup the sink pad and fix a memory
leak.
https://bugzilla.gnome.org/show_bug.cgi?id=741198
When switching URI from about-to-finish, playbin starts decoding the new
URI and the queue2 inside uridecodebin starts emitting buffering messages
immediately. However, the queue(s) inside playsink still have buffers to
play and the pipeline doesn't need to pause for buffering, so we should
not send those buffering messages up to the application, otherwise there
is an audible glitch caused by pausing the pipeline for a very short time.
https://bugzilla.gnome.org/show_bug.cgi?id=727255
