(Initially discussed in
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/305)
The ticks waveform can be useful for audio synchronization diagnostics
and other cases where the time offset between waveforms is important.
However, in its current form, it is too limited, and has problems with
discontinuities, which result in severe artifacts when this waveform
is output by a DAC.
This patch fixes some discontinuities and considerably expand the ticks
waveform's flexibility. They also introduce the notion of a "marker tick";
every Nth tick can have a different amplitude (usually one that is larger
than the others). This is useful for combining frequent oscilloscope
triggering with large time offset detection. For example, without marker
ticks, the tick intervals must not be too small, otherwise the maximum time
offset that can be unambiguously detected is quite small (for example, if
the interval is 50ms, then no time offset larger than 25ms can be
unambiguously recognized). If the tick intervals are too far apart, then
no sudden changes can be clearly observed, since the oscilloscope is not
updated quickly enough. But with marker ticks, this is not an issue: If
there's for example a tick every 100 ms, then the oscilloscope can be
triggered every 100 ms. And, if every 20th tick is a marker tick, then
time offsets of up to 1 second can be discovered, even though the time
between ticks is 100 ms.
The patch also applies some minor cleanup to the audiotestsrc documentation.
Both versions are basically the same, but version 2.0 also allows
60000/1001 as framerate and allows to specify the field and line number
for each payload.
Put the major version into the caps so that elements can limit via caps
negotiation which versions they can support.
audioconvert's passthrough status can no longer be determined
strictly from input / output caps equality, as a mix-matrix can
now be specified.
We now call gst_base_transform_set_passthrough dynamically, based
on the return from the new gst_audio_converter_is_passthrough()
API, which takes the mix matrix into account.
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
This removes the crossfade-ratio property and replaces it with an
operator property. Currently this implements the following operators:
- SOURCE: Copy over the source and don't look at the destination
- OVER: Default blending of the source over the destination
- ADD: Like OVER but simply adding the alpha instead
See the example for how to implement crossfading with this.
https://bugzilla.gnome.org/show_bug.cgi?id=797169
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
255 will easily become 0 in the blending function as they expect
the maximum value to be 255.
Can be reproduce with
gst-launch-1.0 videotestsrc pattern=ball ! c.sink_0 \
videotestsrc pattern=snow ! c.sink_1 \
compositor name=c \
sink_0::zorder=0 sink_1::zorder=1 sink_0::crossfade-ratio=0.5 \
background=black ! \
videoconvert ! xvimagesink
crossfade-ratio +/- 0.001 makes it work correctly and the same happens
at e.g. 0.25, 0.75, N*0.0625
https://bugzilla.gnome.org/show_bug.cgi?id=796846
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.
