PR #24749 opened by yiijima URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/24749 Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/24749.patch
Keep the previous input PTS in `int64_t`, matching `AVFrame.pts`. The existing `int` storage narrows timestamps outside the range of a 32-bit signed integer, corrupting the second field's extrapolated timestamp when `deinterlace_vaapi` flushes at EOF. With a 1/90000 input time base, this affects sufficiently long recordings (approximately 6 hours and 38 minutes). On the tested system, the final timestamp jumps by `2^32 / 180000` seconds, greatly inflating the output duration. The change only widens the private timestamp field; the EOF calculation and normal field interpolation remain unchanged. Reproduce with a VAAPI device and a generated 0.3-second input: ```sh ffmpeg -hide_banner -vaapi_device /dev/dri/renderD128 \ -f lavfi -i 'testsrc2=size=320x240:rate=30000/1001:duration=0.3' \ -vf 'setfield=tff,settb=expr=1/90000,setpts=PTS+25000/TB,format=nv12,hwupload,deinterlace_vaapi=mode=bob:rate=field,hwdownload,format=nv12,showinfo' \ -fps_mode passthrough -f null - ``` The last two `showinfo` timestamps are: | | Penultimate field | Final field | |---|---:|---:| | Before | 25000.266933 | 48861.213039 | | After | 25000.266933 | 25000.283617 | Validation against master `84779ade2679449c70dfd3fb77f7779340356ff0`: - Built the unmodified and patched source with VAAPI enabled on Linux. - Verified all 18 field timestamps on an Intel VAAPI device, using offsets of 0, 23860, 25000, 50000 and -25000 seconds. The patched version matches the expected timestamps in all five cases; short-input controls are unchanged. - `make fate` passed all 281 available tests in the minimal VAAPI build configuration, without an external FATE sample corpus. - Ran `tools/patcheck`, checked whitespace, and manually reviewed the one-line diff. The hardware reproducer is provided above rather than added as an unconditional FATE test because it requires a VAAPI device. >From c06456fc98b2b8095b74c7d479857698c358ceee Mon Sep 17 00:00:00 2001 From: yusuke iijima <[email protected]> Date: Mon, 28 Sep 2026 16:34:13 +0900 Subject: [PATCH] avfilter/deinterlace_vaapi: keep previous PTS in 64 bits prev_pts stores an AVFrame timestamp but is declared as int. When the input PTS exceeds the range of int, the narrowing conversion changes the value used to extrapolate the second field timestamp at EOF. With a 1/90000 input time base and 32-bit int, this can happen after about 6 hours and 38 minutes. On the tested platform, the final output timestamp jumps forward by 2^32 ticks in the 1/180000 output time base, or about 23861 seconds. This can greatly inflate the output duration. Store prev_pts as int64_t to preserve the input timestamp. The EOF calculation and the normal field interpolation remain unchanged. Signed-off-by: yusuke iijima <[email protected]> --- libavfilter/vf_deinterlace_vaapi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/vf_deinterlace_vaapi.c b/libavfilter/vf_deinterlace_vaapi.c index 4bb109336a..7e35fbd24d 100644 --- a/libavfilter/vf_deinterlace_vaapi.c +++ b/libavfilter/vf_deinterlace_vaapi.c @@ -47,7 +47,7 @@ typedef struct DeintVAAPIContext { int extra_delay_for_timestamps; int eof; - int prev_pts; + int64_t prev_pts; } DeintVAAPIContext; static const char *deint_vaapi_mode_name(int mode) -- 2.52.0 _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
