From 996ab61a6a3422c84f8924ebb72ffda833545777 Mon Sep 17 00:00:00 2001 From: wm4 Date: Thu, 8 May 2014 00:49:21 +0200 Subject: 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. --- DOCS/man/en/input.rst | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'DOCS/man/en') 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 -- cgit v1.2.3