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>
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.
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 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.
The outgoing buffer timestamp is calculated by scaling an output buffer
count by the src pad frame rate caps. If these caps change, we need to
reset the count and work from a new base timestamp. The new output
buffer timestamp is then the count scaled by the new caps values added
onto the base timestamp.
Add a property that makes videorate skip to the first buffer it
receives instead of padding the stream from segment start to the
first real buffer.
Fixes bug #567928.
Handle buffers with -1 timestamps better by keeping track of the en time of the
previous buffer and assuming the -1 timestamp buffer goes right after the
previous one.
when we have two buffers that are equally good, output the oldest buffer once to
minimize latency.
don't try to calculate latency when the input framerate is unknown.
When videorate duplicates a buffer with a DISCONT flag, it copies the discont on
the first pushed buffer but fails to clear it for subsequent buffers. This
causes theoraenc!oggmux and possibly other elements to consider this a discont
stream.
Fix videorate to produce discont as the first buffer and after a flushing seek.
Fixes#580271.
Original commit message from CVS:
Patch by: Mark Nauwelaerts <manauw at skynet be>
* gst/videorate/gstvideorate.c: (gst_video_rate_reset),
(gst_video_rate_flush_prev), (gst_video_rate_event),
(gst_video_rate_chain):
* gst/videorate/gstvideorate.h:
React (more) to NEWSEGMENT
Small adjustment in timestamp calculation to prevent mismatches
Fixes#435633.
Original commit message from CVS:
* gst/audiorate/gstaudiorate.c: (gst_audio_rate_chain):
Set caps on outgoing buffers.
* gst/videorate/gstvideorate.c: (gst_video_rate_flush_prev),
(gst_video_rate_event), (gst_video_rate_chain):
* gst/videorate/gstvideorate.h:
Fix videorate some more. Fixes#357977
Original commit message from CVS:
* docs/libs/gst-plugins-base-libs-docs.sgml:
* docs/libs/gst-plugins-base-libs-sections.txt:
* docs/libs/gst-plugins-base-libs.types:
* docs/plugins/Makefile.am:
* docs/plugins/gst-plugins-base-plugins-docs.sgml:
* docs/plugins/gst-plugins-base-plugins-sections.txt:
Added some more docs to libs and plugins.
* gst-libs/gst/audio/gstringbuffer.c:
(gst_ring_buffer_prepare_read), (gst_ring_buffer_clear):
* gst-libs/gst/audio/gstringbuffer.h:
Document ringbuffer some more.
* gst/videorate/gstvideorate.c: (gst_video_rate_class_init),
(gst_video_rate_setcaps), (gst_video_rate_reset),
(gst_video_rate_init), (gst_video_rate_flush_prev),
(gst_video_rate_swap_prev), (gst_video_rate_event),
(gst_video_rate_chain), (gst_video_rate_change_state):
* gst/videorate/gstvideorate.h:
Fix videorate to use segments.
Make it work with 0/1 framerates (closes#331903)
Handle EOS correctly.
Added docs.
