Re: [FFmpeg-devel] [RFC PATCH] vf_fps: Requantize pts of CFR videos

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 2491 bytes --]

On Wed, Dec 22, 2021 at 11:20:26AM -0500, Calvin Walton wrote:
> This is mostly to avoid oddities in small framerate adjustments when you
> have input videos from containers such as matroska, where the pts values
> are quantized with a large enough error to cause issues.
> 
> An example, when converting from 24/1.001 fps to 24 fps with round=down
> from an mkv source (inlink time base is 1/1000, outlink is 1001/24000):
> 
>   In PTS | Out PTS  | Rounded Out PTS
>   69292  | 1663.008 | 1663
>   69333  | 1663.992 | 1663
>   69375  | 1665.000 | 1665
> 
> In this example, the fps filter would drop the frame with pts 69292,
> then duplicate the frame with pts 69333, an undesirable result.
> 
> By first requantizing the input pts to the inlink frame rate, the result
> looks much nicer:
> 
>   In PTS | Req. PTS | Out PTS
>   69292	 | 1661     | 1662
>   69333  | 1662     | 1663
>   69375  | 1663     | 1664
> 
> (Note that the same rounding mode is used for both conversions,
> resulting in the final out pts being a bit lower in this case. With the
> normal nearest mode, it would be closer.)
> 
> I've verified that in conversions of longer mkv files to "close"
> framerates that previously had issues due to quantization, this
> significantly reduces the number of incorrectly dropped or duplicated
> frames.
> 
> The potential downside of this change is that if an input file is
> probed as CFR but is actually VFR, then the results will be poor
> (you'll get unnecessarily dropped frames or added judder). A new
> option, "requantize", is added to allow disabling this behaviour in
> those cases.
> 
> Signed-off-by: Calvin Walton <calvin.walton@kepstin.ca>
> 
> ---
>  libavfilter/vf_fps.c | 48 +++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 41 insertions(+), 7 deletions(-)

breaks a 60fps 1/60000 timebase input downconverted with -vf fps=30:-0.01
the expected result is identical to -vf fps=30 but

-i 60fps.mov -bitexact -vf fps=30:-0.01  -t 2 -v 99 fps.flv
the expected output is that either all odd or all even frames are returned but
its a mix after this patch
I cannot share the input file but this should reproduce with any 60fps
input i hope. If not say so and ill try to find some other file that shows this

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".