command: add property that estimates current video FPS

This is done after filters, so things like framerate-doubling
deinterlacing is accounted for.

Unfortunately, framedropping can cause inaccuracies (especially after
precise seeks), and we can't really know when that happens. Even though
we know that the decoder might drop a frame if we request it to do so,
we don't know when the dropped frame will start or stop affecting the
video filter chain. Video filters can have frames buffered, and we
can't tell at which point the dropped frame would have been output.
It's not even possible to mark a discontinuity after seek, because
again we don't know if the filter chain still has the discontinuity
within its buffers.

So we have to live with the fact that the output of this property can
be completely broken after seek, unless --no-hr-seek-framedrop is used.

1 files changed, 8 insertions, 0 deletions

diff --git a/DOCS/man/en/input.rst b/DOCS/man/en/input.rst
index 568d7e737e..3843a0b1b8 100644
--- a/DOCS/man/en/input.rst
+++ b/DOCS/man/en/input.rst
@@ -978,6 +978,14 @@ Property list
     Container FPS. This can easily contain bogus values. For videos that use
     modern container formats or video codecs, this will often be incorrect.
 
+``estimated-vf-fps``
+    Estimated/measured FPS of the video filter chain output. (If no filters
+    are used, this corresponds to decoder output.) This uses the average of
+    the 10 past frame durations to calculate the FPS. It will be inaccurate
+    if framedropping is involved (such as when framedrop is explicitly
+    enabled, or after precise seeking). Files with imprecise timestamps (such
+    as Matroska) might lead to unstable results.
+
 ``window-scale`` (RW)
     Window size multiplier. Setting this will resize the video window to the
     values contained in ``dwidth`` and ``dheight`` multiplied with the value