There was a case where we could end up having more buffers on the sinkpads
than what was expected, depending on timings. This ensure that we have a fixed
number of buffers produced by the testsrc, and we play until EOS.
Replace theora encoder/decoder chain with fakevideodec for testing
QoS handling in videorate rate property tests. This simplifies the
test pipeline and removes dependency on theora codecs.
Also adjust test expectations to match RGBA format output from
fakevideodec instead of I420 from theoradec, and limit buffer
counts to make tests more deterministic.
This also fixes the rate we set for 2.0 test as we were actually testing
0.5 there.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9013>
Refactor the videorate element to properly separate upstream and downstream
time domains when the `rate` property is set.
The previous implementation had issues with time domain conversions when
changing rates, especially during seeks after which we were basically confusing
input and output timestamps.
This also fixes rate changes as we are now tracking the wanted input timestamps
and not confusing them with the output, so this way we do not drop buffers when
the rate is changed while playing, meaning that the related tests have been
fixed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9013>
The 'new-pref' property sets the preference to use the new (next)
instead of the old (previous) buffer. The default is set to 0.5 to get
a similar behaviour as before the change.
Value 0.0 makes sure that only frames are shown where it's known that
the frame content is visible at that time, always show the old frame
until the new frame timestamp is reached.
Then, if the next buffer replaces the previous buffer the new buffer
is pushed as often as possible until PTS is reached. Before the new
buffer was only pushed once the new next buffer arrived.
Use GstClockTimeDiff because it's known that the current buffer time
is inside the time interval of previous buffer and next buffer the
calculation can be done with building absolute values. Special macros
are not needed here.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8579>
The scenario is what we try in the tests:
- we have a segment with .stop set
- some frame(s) flow
- we get a CAPS event
- we get an EOS (before getting buffers after the CAPS event)
in that case, without that patch, the segment is not properly closed
which is not correct. In this patch we keep track of previous caps until
a new buffer arrives, this way in that situation we set previous caps
again, and close the segment with the previous buffer.
Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1352
in this specific case
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3059>
This allows users to let videorate fully fill the segments when received
EOS or on new segment, removing an arbitrary limit of 25 duplicates which
might not be what the user wants (for example on low FPS stream in GES,
that sometimes leaded to broken behavior)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3000>
Fixes warnings like:
Received a structure string that contains '="0.5"'. Reading as a gdouble value, rather than a string value. This is undesired behaviour, and with GStreamer 1.22 onward, this will be interpreted as a string value instead because it is wrapped in '"' quotes. If you want to guarantee this value is read as a string, before this change, use '=(string)"0.5"' instead. If you want to read in a gdouble value, leave its value unquoted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2621>
