[FFmpeg-devel] [PATCH] avfilter/setpts: also preserve duration when not stripping fps (PR #20304)

[FFmpeg-devel] [PATCH] avfilter/setpts: also preserve duration when not stripping fps (PR #20304)

[Niklas Haas via ffmpeg-devel]

PR #20304 opened by Niklas Haas (haasn)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20304
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20304.patch

It makes sense to treat the presence of a frame duration and the presence
of frame rate metadata identically - because both convey effectively the same
amount of information.

In f121d95 and fa110c3 respectively, this information was stripped by default,
originally to work-around bugs when changing the PTS information of a stream
being fed to some encoders. (See https://trac.ffmpeg.org/ticket/10886)

Later, commit 959b799c restored the ability to preserve the frame rate
medatata via the `strip_fps` option, but this option did not extend to also
include the frame duration.

This commit resolves the scenario by making `frame_rate` and `duration`
handled in a consistent manner, so that the frame rate information is
generally preserved unless explicitly stripped by the user.

While it does regress the exact invocation presented in the trac ticket unless
using `strip_fps=yes`, I consider this an acceptable trade-off, especially in
light of the fact that the `fps` filter also exists and is arguably the better
tool for the task at hand.


From 8e0de5d811b1828d588844a88cea35440cce0008 Mon Sep 17 00:00:00 2001
From: Niklas Haas <git@haasn.dev>
Date: Thu, 21 Aug 2025 14:46:52 +0200
Subject: [PATCH] avfilter/setpts: also preserve duration when not stripping
 fps

It makes sense to treat the presence of a frame duration and the presence
of frame rate metadata identically - because both convey effectively the same
amount of information.

In f121d95 and fa110c3 respectively, this information was stripped by default,
originally to work-around bugs when changing the PTS information of a stream
being fed to some encoders. (See https://trac.ffmpeg.org/ticket/10886)

Later, commit 959b799c restored the ability to preserve the frame rate
medatata via the `strip_fps` option, but this option did not extend to also
include the frame duration.

This commit resolves the scenario by making `frame_rate` and `duration`
handled in a consistent manner, so that the frame rate information is
generally preserved unless explicitly stripped by the user.

While it does regress the exact invocation presented in the trac ticket unless
using `strip_fps=yes`, I consider this an acceptable trade-off, especially in
light of the fact that the `fps` filter also exists and is arguably the better
tool for the task at hand.
---
 doc/filters.texi     | 6 +++---
 libavfilter/setpts.c | 3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 2818bd28b0..e84d7d5554 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -31911,9 +31911,9 @@ This filter accepts the following options:
 The expression which is evaluated for each frame to construct its timestamp.
 
 @item strip_fps (@emph{video only})
-Boolean option which determines if the original framerate metadata is unset.
-If set to true, be advised that a sane frame rate should be explicitly
-specified if output is sent to a constant frame rate muxer.
+Boolean option which determines if the original framerate and frame duration
+metadata is unset. If set to true, be advised that a sane frame rate should be
+explicitly specified if output is sent to a constant frame rate muxer.
 Default is @code{false}.
 
 @end table
diff --git a/libavfilter/setpts.c b/libavfilter/setpts.c
index 0565533ed2..b49a0cb64f 100644
--- a/libavfilter/setpts.c
+++ b/libavfilter/setpts.c
@@ -199,7 +199,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
 
     d = eval_pts(setpts, inlink, frame, frame->pts);
     frame->pts = D2TS(d);
-    frame->duration = 0;
+    if (setpts->strip_fps)
+        frame->duration = 0;
 
     av_log(inlink->dst, AV_LOG_TRACE,
             "N:%"PRId64" PTS:%s T:%f",
-- 
2.49.1

_______________________________________________
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".