Instead go backwards before segment.stop based on the framerate or the
next buffers end timestamp. Otherwise the first buffer will usually be
dropped because outside the segment.
https://bugzilla.gnome.org/show_bug.cgi?id=781899
The latency query originally had a fallthrough to the default
label at the end as fallback, but that got messed up when the
DURATION and POSITION queries were added, so it then fell through
to the duration query handler instead. Restore original behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=699077
Duration query would return TRUE and duration=-1. This
worked in the unit test because the unit test implementation
was a bit broken.
Both queries need to access rate with a lock.
Fix broken duration query test as well. It relied on broken
behaviour by the videorate query handler, and also it was
implemented as a downstream query rather than an upstream
query. And we must return HANDLED from the probe so that the
query we intercept actually returns TRUE.
https://bugzilla.gnome.org/show_bug.cgi?id=699077
This is enough for making it work in GES, but it's unclear if all the various
property combinations are working correctly. It's an improvement over what was
there before in any case, which was to just drop all buffers if rate < 0.0.
https://bugzilla.gnome.org/show_bug.cgi?id=769624
Make writable the buffer before pushing it lead to a buffer copy. It's
because a reference is keep for the previous buffer.
The previous buffer reference is only need to duplicate the buffer. In
drop-only mode, the previous buffer is release just after pushing the
buffer so a copy is done but it's useless.
https://bugzilla.gnome.org/show_bug.cgi?id=764319
Since the loops increasing count from 0 are always run at least
once (if count < 1), count will always be at least one when
compared to the drop/dup conditions.
Coverity 1139674
Since the videorate element just duplicates or drops frames
to achieve the desired framerate, it can accept video/x-bayer media
(in any format), which are not present in the current caps.
Just add "video/x-bayer(ANY);" to the caps of the static pad template
(fixing line style to pass the indent commit hook).
https://bugzilla.gnome.org/show_bug.cgi?id=753483
When a stream has a variable framerate, videorate calculates it and
forces it on the output caps. However, the code in _transform_caps()
currently also does that if the transform is going in the opposite
direction (GST_PAD_SRC), so during a renegotiation it tries to force
upstream to use the calculated framerate and it fails.
https://bugzilla.gnome.org/show_bug.cgi?id=750032
In case upstream does not provide videorate with framerate information,
it will detect the current framerate from the buffer it received,
but if downstream forces the use of variable framerate (most probably
through the use of a caps filter with framerate = 0 / 1), videorate will
respect that.
And add some unit tests
https://bugzilla.gnome.org/show_bug.cgi?id=734424
In the case the framerate is variable (represented by framerate=0/1),
we currently end up loop pushing the first buffer and then recompute
diff1 and diff2 without updating the videorate->next_ts at all
leading to infinitely looping pushing that first buffer.
In the case of variable framerate, we should just compute the next_ts
as previous_pts + previous_duration.
https://bugzilla.gnome.org/show_bug.cgi?id=734424
VideRate keeps 1 buffer in order to duplicate base on closest buffer
relative to targeted time. This extra buffer need to be request
otherwise the pipeline may stall when fixed size buffer pool is used.
https://bugzilla.gnome.org/show_bug.cgi?id=738302
There's no reason why we would have to wait for the next buffer to decide
whether to output the current one or not. We just have to check if the
current one is earlier than our expected next time, which is the previous
frame timestamp plus the expected frame duration.
https://bugzilla.gnome.org/show_bug.cgi?id=740018
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
API: GstVideoRate:force-fps
Changing the framerate during playback is not possible
with a capsfilter downstream if upstream is not using
gst_pad_alloc_buffer(). In that case there's no way in
0.10 to signal to videorate that the preferred framerate
has changed.
This new property will force the output framerate to
a specific value and can be changed during playback.
In various use-case you want to dynamically change the framerate (e.g.
live streams where the available network bandwidth changes). Doing this
via capsfilters in the pipeline tends to be very cumbersome and racy,
using this property instead makes it very painless.
