Commit graph

6 commits

Author SHA1 Message Date
Thibault Saunier
0c75ea0858 videorate: Update QoS events taking into account our rate
Otherwise there is a mismatch between the QoS values and what upstream
would expect, leading to too much buffer dropping in video decoders in
case rate < 1.0 or not enough buffer dropping in case rate > 1.0

Adding validate tests with and without decoders.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/679>
2020-06-01 07:07:31 +00:00
Thibault Saunier
6499e2afa5 videorate: Fix changing rate property during playback
We need to take into account the base_ts to compute next_ts and it needs
to be updated on rate change.

This introduces `pending_rate` so that change rate is properly handled
in the streaming thread in a safe way.

Added tests

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/679>
2020-06-01 07:07:31 +00:00
Thibault Saunier
d846a1ac1c tests:validate: Run all test using a simple fakesink
`fakevideosink` is in -bad and thus not available here.

Update the expectation files as video metas are not negotiated anymore.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/677>
2020-05-29 19:21:43 +00:00
Thibault Saunier
97fe599c0f videorate: Fix buffer selection logic in reverse playback
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>
2020-05-26 15:35:00 -04:00
Thibault Saunier
dc47232d0d videorate: Do not push an extra buffer on EOS when we are done pushing already
There is no reason that when we have already pushed all the buffers in
a segment we push a new one on EOS

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/668>
2020-05-26 15:35:00 -04:00
Thibault Saunier
b46718b1a0 audiotestsrc: Fix the way we compute EOS in reverse playback
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>
2020-05-25 08:19:02 +00:00