In reverse playback we were not taking into account the current buffer
samples to check if we had reached EOS which was leading to a buffer
with PTS = CLOCK_TIME_NONE containing too many frames followed by a
useless buffer with pts=0 duration=0, and a g_critical issue in
gst_object_sync_values.
Also add a validate based test case.
Without that patch this is how the expectation fails:
``` diff
--- log-asink-sink-expected 2020-05-22 23:22:42.654384579 -0400
+++ log-asink-sink-actual 2020-05-22 23:29:35.671586380 -0400
@@ -27,5 +27,6 @@
buffer: pts=0:00:00.058820861, due=0:00:00.023219955, flags=discont
buffer: pts=0:00:00.035600907, due=0:00:00.023219954, flags=discont
buffer: pts=0:00:00.012380952, due=0:00:00.023219955, flags=discont
-buffer: pts=0:00:00.000000000, due=0:00:00.012380952, flags=discont
+buffer: due=0:00:00.012380953, flags=discont
+buffer: pts=0:00:00.000000000, flags=discont
event eos: (no structure)
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/667>
(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.
Make sure ticks start with an accumulator value of 0 by incrementing it
after filling in samples instead of before and by resetting the accumulator
every time a tick begins. This prevents it from being discontinuous at the
beginning of the tick.
https://bugzilla.gnome.org/show_bug.cgi?id=774050
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
Before it was done the other way around and that can trigger the assert that
already is in place. This also makes more sense; when seeking to time x, we want
then sample that is <= that pos.
