Commit graph

198 commits

Author SHA1 Message Date
Sebastian Dröge
3edf390b4c videorate/videoscale/audioresample: Ensure that the caps returned from fixate_caps() are actually fixated
If there is some other field than the ones we care about left and not
fixated yet then basetransform will just error out. So instead just pass
the result through gst_caps_fixate() in the very end.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/799>
2020-08-26 09:10:29 +00:00
Olivier Crête
cb6edaf6f8 videorate: Error out on streams with no way to guess framerate
This is better than going into an infinite loop.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/761>
2020-07-20 22:05:57 +00:00
Olivier Crête
90ff086a43 videorate: Assert on invalid result from internal code
Letting this through instead results in an infinite loop where
the exact same buffer gets pushed out ad infinitum.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/761>
2020-07-20 22:05:57 +00:00
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
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
6e82eb28f3 videorate: Factor out a method for themax-duplication-time property
Sensibly simplifying gst_video_rate_transform_ip

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/668>
2020-05-26 15:35:00 -04:00
Thibault Saunier
39c321835b videorate: Use CLOCK_TIME_IS_VALID instead of checking CLOCK_TIME_NONE
Making it more consistency with the rest of the code.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/668>
2020-05-26 15:35:00 -04:00
Thibault Saunier
086f3c05b9 videorate: Factor out a method to reset mode
Working on simplifying gst_video_rate_transform_ip

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
fc2810bada videorate: Fix buffer timestamp underflow in reverse playback
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>
2020-05-06 16:50:01 +00:00
Seungha Yang
bb8515671e videorate: Signalling reconfigure to upstream whenever updating downstream caps
Previously configured bufferpool can be expired/inactivate by the
updated caps. Therefore new reconfigure event should be signalled in order to
do allocation query dancing between upstream and downstream again.

Fixes: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/730
2020-03-23 18:50:10 +09:00
Niels De Graef
761bb9b9ff videorate: Use G_DECLARE_FINAL_TYPE 2020-03-16 15:47:58 +00:00
Sebastian Dröge
c363747251 videorate: Fix max-duplication-time handling
Previously this would've only set discont=TRUE and then for all future
buffers simply returned immediately.

Instead we also need to
  a) drain previous input until its buffer time
  b) update next_ts and base_ts accordingly for the gap
  c) actually store the new buffer after the gap so it can be used in
     the future and so the old buffer before the gap is gone

Also update the unit test accordingly so that it actually tests for this
behaviour. Previously it only tested that after the gap we got no output
at all.
2019-11-04 19:01:10 +00:00
Tim-Philipp Müller
289d8e53e2 Remove autotools build system 2019-10-13 14:15:43 +01:00
Thibault Saunier
909baa2360 Pass the code through codespell 2019-08-30 13:05:36 +00:00
Thibault Saunier
27ba8d24ec doc: Port to hotdoc 2019-05-13 11:34:08 -04:00
Vivia Nikolaidou
8ecc3b9730 videorate: Add max-duplication-time property
This will only duplicate buffers if the gap between two consecutive
buffers is up to fill-until nsec. If it's larger, it will only output
the new buffer and mark it as discont.
2019-02-21 15:50:55 +00:00
Xavier Claessens
201e7c7803 Meson: Generate pc file for all plugins in base
https://bugzilla.gnome.org/show_bug.cgi?id=794568
2018-04-25 11:05:56 +01:00
Sebastian Dröge
bec7f4ad5e videorate: In reverse playback mode, don't output the first buffer with ts=segment.stop
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
2018-03-29 20:48:27 +03:00
Mathieu Duponchelle
875af55937 videorate: flush remaining buffers on SEGMENT_DONE
Just as we do on EOS.

https://bugzilla.gnome.org/show_bug.cgi?id=784666
2017-07-21 14:22:07 -04:00
Guillaume Desmottes
36b7e5890f videorate: stop copying buffers in drop-only mode
gst_video_rate_flush_prev() ensures that the pushed buffer is writable
by calling gst_buffer_make_writable() on videorate->prevbuf.

In drop-only mode we always push buffers directly when they are received
from GstBaseTransform (gst_video_rate_transform_ip()) and do not keep them
around. GstBaseTransform already ensures that those buffers are
writable so there is no need to do it twice.

This change saves us from copying buffers in drop-only mode as we no longer
calls gst_buffer_make_writable() with a buffer having a refcount of 2
(one ref owned by GstBaseTransform and one in videorate->prevbuf).

https://bugzilla.gnome.org/show_bug.cgi?id=780767
2017-05-20 16:35:53 +02:00
Guillaume Desmottes
2c2d2a444c videorate: factor out gst_video_rate_push_buffer()
No semantic change, just factor out this function from
gst_video_rate_flush_prev().

I'm about to use it to change the 'drop-only' code path.

https://bugzilla.gnome.org/show_bug.cgi?id=780767
2017-05-20 16:35:53 +02:00
Nicolas Dufresne
8e6c6266d7 Remove plugin specific static build option
Static and dynamic plugins now have the same interface. The standard
--enable-static/--enable-shared toggle are sufficient.
2017-05-16 13:42:07 -04:00
Sebastian Dröge
0be4504b10 Revert "videorate: In reverse playback mode, don't output the first buffer with ts=segment.stop"
This reverts commit e6736e9925.

This one is for after 1.12.0 and shouldn't have been merged yet.
2017-05-02 14:32:02 +03:00
Sebastian Dröge
e6736e9925 videorate: In reverse playback mode, don't output the first buffer with ts=segment.stop
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
2017-05-02 14:05:39 +03:00
Thibault Saunier
099ac9faf2 docs: Convert gtkdoc comments to markdown
Modernizing the documentation, making it simpler to read an
modify and allowing us to possibly switch to hotdoc in the
future.
2017-03-10 18:19:17 -03:00
Tim-Philipp Müller
f9d110f596 videorate: fix LATENCY query
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
2017-01-24 01:04:53 +00:00
Tim-Philipp Müller
d6c0e9072b videorate: fix duration and position query handling
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
2017-01-24 01:04:39 +00:00
Joris Valette
658ee6f0db videorate: Add fixed rate property
https://bugzilla.gnome.org/show_bug.cgi?id=699077
2016-11-04 14:01:54 -03:00
Nirbheek Chauhan
5c4f4ac1bd Add support for Meson as alternative/parallel build system
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.html
http://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.
2016-08-20 11:09:51 +01:00
Sebastian Dröge
2ebbd1c9fa videorate: Implement basic support for reverse playback
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
2016-08-19 15:57:01 +03:00
Sebastian Dröge
6788003912 videorate: Don't fill up the segment with duplicate buffers if drop_only==TRUE 2016-04-03 11:40:50 +03:00
Sebastian Dröge
eda44c640e videorate: Remove dead code
We never get into this code path at all if drop_only==TRUE.
2016-04-03 11:38:28 +03:00
Frédéric Bertolus
2626c02149 videorate: avoid useless buffer copy in drop-only mode
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
2016-04-03 11:37:52 +03:00
Vineeth TM
44b70ca3a1 base: use new gst_element_class_add_static_pad_template()
https://bugzilla.gnome.org/show_bug.cgi?id=763075
2016-03-24 14:25:41 +02:00
Tim-Philipp Müller
ddfe7a2808 win32: remove outdated build cruft
This hasn't been touched for generations, doesn't work,
and is just causing confusion. We also don't want to
maintain these files manually.
2016-02-20 10:05:17 +00:00
Thiago Santos
5ef0a09794 videorate: replace accept-caps with a caps query
accept-caps is only a shallow check, it needs to know
whether downstream as a whole accepts the framerate
2016-01-08 15:05:38 -03:00
Vincent Penquerc'h
033ce9b20d videorate: remove dead code
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
2015-12-16 11:00:22 +00:00
Vineeth T M
a1d84edd16 videorate: remove unnecessary break statement
Trivial patch to remove unncessary break statement used after
goto statement.

https://bugzilla.gnome.org/show_bug.cgi?id=754054
2015-10-02 17:27:13 +03:00
Thiago Santos
909f494a5a videorate: fixate the pixel-aspect-ratio
If the pixel-aspect-ratio is not fixed, try to get it as close
to 1/1 as possible

https://bugzilla.gnome.org/show_bug.cgi?id=748635
2015-08-13 14:11:37 -03:00
Joan Pau Beltran
5070d6367e videorate: add support for bayer formats
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
2015-08-10 17:21:03 -04:00
George Kiagiadakis
c84f911cee videorate: update the caps framerate only in the GST_PAD_SINK transform_caps direction
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
2015-05-29 15:03:05 +02:00
Tim-Philipp Müller
ec5c93f169 docs: update element example pipelines
- gst-launch -> gst-launch-1.0
- use autoaudiosink and audiovideosink more often
- review pipeline examples and descriptions
2015-05-10 11:38:19 +01:00
Tim-Philipp Müller
c680e324bc Remove obsolete Android build cruft
This is not needed any longer.
2015-04-26 18:42:34 +01:00
Tim-Philipp Müller
d4f9ea8499 app, videorate: fix CFLAGS and LIBADD order
Make sure local headers are included before installed -base.
2015-04-11 00:03:29 +01:00
Tim-Philipp Müller
609d021f96 videorate: downgrade left-over ERROR debug message 2015-04-04 00:49:23 +01:00
Tim-Philipp Müller
413fc30235 videorate: fix a couple of memory leaks
tests: videorate: fix leak in unit test
2015-04-04 00:49:21 +01:00
Thibault Saunier
ae86dec9ca videorate: Detect framerate if not forced to variable downstream
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
2015-04-02 17:13:24 -04:00
Thibault Saunier
1cda538e00 videorate: Do not loop forever pushing first buffer when variable framerate
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
2015-04-02 17:13:24 -04:00