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
The original 0/1 framerate must still be allowed to be configured
on the upstream side of videorate, otherwise future caps renegotiation
is going to fail.
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
Fix up videorate test for latest videotestsrc changes: just check for
the important bits in the negotiated caps, not for exact equality with
our filter caps. Also don't leak the videorate element in the test.
Original commit message from CVS:
* tests/check/elements/videorate.c: (GST_START_TEST):
Set buffer timestamp to a valid value in order to test the buffer
really does stay in videorate.
Original commit message from CVS:
Patch by: Dan Williams <dcbw redhat com>
* gst/videorate/gstvideorate.c: (gst_video_rate_chain):
Don't leak incoming buffer if gst_pad_push() returns a
non-OK flow. Fixes#432755.
* tests/check/elements/videorate.c: (GST_START_TEST),
(videorate_suite):
Unit test for the above by Yours Truly.
Original commit message from CVS:
* gst/videorate/gstvideorate.c: (gst_video_rate_setcaps),
(gst_video_rate_chain):
Add some debug.
* tests/check/elements/videorate.c: (GST_START_TEST),
(videorate_suite):
Added check for videorate changing caps handling. Closes#421834.
Original commit message from CVS:
2007-03-29 Andy Wingo <wingo@pobox.com>
* gst/videorate/gstvideorate.c (gst_video_rate_flush_prev): Make
perfect offsets also, not just timestamps.
* tests/check/elements/videorate.c (test_more): Test that given
any incoming offsets, that videorate produces perfect offsets.
Original commit message from CVS:
* tests/check/elements/audioconvert.c: (set_channel_positions),
(get_float_mc_caps), (get_int_mc_caps):
* tests/check/elements/audioresample.c:
* tests/check/elements/audiotestsrc.c: (GST_START_TEST):
* tests/check/elements/videorate.c:
* tests/check/elements/videotestsrc.c: (GST_START_TEST):
* tests/check/elements/volume.c:
* tests/check/elements/vorbisdec.c:
* tests/check/pipelines/vorbisenc.c: (GST_START_TEST):
Don't busy-wait in tests; this was causing test timeouts very
frequently when running under valgrind.
Original commit message from CVS:
* gst/videorate/gstvideorate.c: (gst_video_rate_reset),
(gst_video_rate_swap_prev), (gst_video_rate_chain):
fix up docs
fix a leak when no caps negotiated
fix counting of input frames
* tests/check/elements/.cvsignore:
* tests/check/elements/videorate.c: (assert_videorate_stats),
(GST_START_TEST), (videorate_suite):
add tests for these
Original commit message from CVS:
Patch by: Edward Hervey <edward@fluendo.com>
* gst/videorate/gstvideorate.c: (gst_video_rate_chain):
* tests/check/Makefile.am:
* tests/check/elements/videorate.c: (assert_videorate_stats),
(setup_videorate), (cleanup_videorate), (GST_START_TEST),
(videorate_suite), (main):
Fix an infinite loop if frames are passed in with wrongly ordered
timestamps. Fixes#339013.
