Use the bitrate advertised by queue2 to determine the limits to
set across possibly multiple queue2/downloadbuffer elements. e.g.
with two queue2's and a max-bytes based on the ratio of the
bitrate/cumulative_bitrate multiplied by the buffer_size set on urisourcebin.
This allows finer grained control over the buffer used by all the queue
elements inside urisourcebin. Instead of a maximum of
n_streams*buffer_size being used, only buffer_size will be used however
we will fallback to n_streams*buffer_size if one of the queue2's does
not have bitrate information.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/60
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
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
When the playsink contains a text chain this property controls the
synchronisation of the subtitles and video by controlling the underlying
subtitleoverlay::subtitle-ts-offset property.
https://bugzilla.gnome.org/show_bug.cgi?id=797134
The queue between the audiotee and the audio chain wasn't properly added to the
bin, leading to streamsynchronizer locks on EOS. Reconfiguration of the
visualization chain wasn't working as expected either. It is now possible to
dynamically enable/disable the audio visualization support.
https://bugzilla.gnome.org/show_bug.cgi?id=796553
The fomula, 'offset = time / rate', is correct only if
the rate is never changed. When the rate is changed,
the offset should be re-calculated based on the previous
offset.
https://bugzilla.gnome.org/show_bug.cgi?id=791269
adder needs more than just trivial work to support planar buffers properly
because it currently reads sub-buffers from GstCollectPads in order for all
of them to have matching sizes. In planar mode, this means it would truncate
some channels and mix them up in strange ways. It only works if all input
buffers in all sink pads have matching sizes.
With the way caps negotiation work in encoders, the only way to ensure
that no downstream renegotiation is done in the encoder is to also lock
upstream caps. Anyway with the current behavior upstream of encoders
*require* to handle any file format so locking upstream format should
be safe.
https://bugzilla.gnome.org/show_bug.cgi?id=795464
Otherwise decodebin won't get notified about STREAM_COLLECTION comming
from the sources and thus will never get informored about it. Without
being informed about the stream collection decodebin won't be able to
select any streams. It ends up not creating any output for the streams
defined from outside parserbin.
https://bugzilla.gnome.org/show_bug.cgi?id=795364
