Especially when changing the sample rate our timestamp tracking will be
completely off, but even otherwise we would usually lose the last few
samples if we don't drain here as the resampler gets reset if anything
but the sample rate changes.
This is usually not a problem as the first buffer after a caps event
usually has the discont flag set, but can cause problems if
- the caps event is followed by a segment event, which then causes
draining according to the new sample rate
- the caps were changed because of rengotiation due to a reconfigure
event and there is not discontinuity from upstream
In both cases we would output buffers with completely wrong timestamps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/670>
Stop comparing all timestamps from buffers that are before the segment
with the segment.stop and compare with the actual end times.
Comparing to segment.stop for all the buffers that where before
the segment.stop was incorrect and leading to consuming wrong buffers
and not respecting segment.stop, this is now properly tested.
Expectations for `reverse.10_to_1fps.validatetest` have been fixed to
take that into account and comparing the checksums of the sinkpad and
srcpad expectations makes pretty clear how wrong that was.
(we can see in the expectations that videotestsrc outputs an extra
buffer with pts == segment.stop and this one is now properly dropped
by videorate as bec7f4ad5e aimed at
doing)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/668>
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>
The gir generator wrongly assume that the vfunc
GstGLFilterClass.filter() and the method gst_gl_filter_filter_texture()
are related. As a result it complains about not matching argument names.
Workaround this by naming both of their arguments input and output.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/664>
This is needed for cross-compiling without a build machine compiler
available. The option was added in 0.54, but we only need this in
Cerbero and it doesn't affect older versions so it should be ok.
Will only cause a spurious warning.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/660>
And fix reverse playback buffer duration computation as in reverse
playback, buffer duration is prev_buffer.pts - buffer.pts not pts -
next_pts (buffers are displayed from buffer.pts + buffer.duration for
a duration of buffers.duration).
This is now tested with the `validate.test.clock_sync.videorate.*`
tests in the default integration testsuite where we check the exact
data flow and the synchronization on the clock behaviour with a
TestClock.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/646>
In reverse playback, buffers have to be displayed at buffer.stop running
time, meaning:
buffer.pts + buffer.duration = prev_buffer.pts
=>
buffer.duration = prev_buffer.pts - buffer.pts
We were setting buffer.duration = next_buffer.pts - buffer.pts which
is not correct.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/646>
If core is built as a subproject (e.g. as in gst-build), make sure to use
the gst-plugin-scanner from the built subproject. Without this, gstreamer
might accidentally use the gst-plugin-scanner from the install prefix if
that exists, which in turn might drag in gst library versions we didn't
mean to drag in. Those gst library versions might then be older than
what our current build needs, and might cause our newly-built plugins
to get blacklisted in the test registry because they rely on a symbol
that the wrongly-pulled in gst lib doesn't have.
This should fix running of unit tests in gst-build when invoking
meson test or ninja test from outside the devenv for the case where
there is an older or different-version gst-plugin-scanner installed
in the install prefix.
In case no gst-plugin-scanner is installed in the install prefix, this
will fix "GStreamer-WARNING: External plugin loader failed. This most
likely means that the plugin loader helper binary was not found or
could not be run. You might need to set the GST_PLUGIN_SCANNER
environment variable if your setup is unusual." warnings when running
the unit tests.
In the case where we find GStreamer core via pkg-config we use
a newly-added pkg-config var "pluginscannerdir" to get the right
directory. This has the benefit of working transparently for both
installed and uninstalled pkg-config files/setups.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/582>
-base plugins will always be found in the build directory, and
core plugins will be found either also via the build directory
(if both core and -base are a subproject) or by getting the
pluginsdir via pkg-config if core is installed.
The GST_PLUGIN_LOADING_WHITELIST env var will make sure we only
pick up plugins from core/base and base plugins only from the
builddir.
There is no reason to look for -base plugins in the install dir.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/582>
the old manner does not consider the profile idc. The profile idc should
play an more important role in recognizing the profile than the other
information. And there is no need to mix profiles of different extensions
together to find the closest profile when the bits stream is not standard,
different extensions support different features and should not be mixed.
The correct way should be recognize the extension category by profile idc
firstly, and then find the closest profile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/645>
GstH265FormatRangeExtensionProfile declares the common bits used
for not only format range extensions profiles, but also for several
different h265 extension profiles, such as high throughput, screen
content coding extensions, etc. And So the old name is not proper.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/645>
