Opened 13 months ago

Last modified 13 months ago

#10253 new defect

Bug in yadif/bwdif filter - wrong handling for pts wrap

Reported by: Christian Zillner Owned by:
Priority: important Component: avfilter
Version: 4.4.3 Keywords: yadif bwdif pts wrap
Cc: Christian Zillner Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

I faced this problem when I tried to deinterlace video frames on the pts max border.

The frame before the pts wrap was still ok, but the first frame after the wrap has a pts issue. The video frame I got had a pts value in the mid of the pts range - I expected a value in the near of zero. After that issue (that single frame) all following pts values/frames were okay again.

I used ffmpeg version 4.4.3 but I think the problem still exists in the current version.

Attachments (1)

yadif_common.c (7.3 KB ) - added by Christian Zillner 13 months ago.
suggested fix for that issue

Download all attachments as: .zip

Change History (5)

comment:1 by Cigaes, 13 months ago

The file you attached is identical to the file in the repository. As a general rule, do not send modified files, send diffs, and send them to the devel mailing-list.

But timestamps discontinuities should be fixed before filter graphs, it is not the task of each individual filters to reinvent how ti fix timestamps.

by Christian Zillner, 13 months ago

Attachment: yadif_common.c added

suggested fix for that issue

comment:2 by Christian Zillner, 13 months ago

I'm sorry. I replaced the file with the right one.

comment:3 by Cigaes, 13 months ago

Indeed. (It contains tabs.) But as I said, fixing the timestamps should not be done in each individual filters, and especially not with something specific to MPEG timestamps. Normally, these MPEG timestamps resets should be handled before entering the filter graph. If it does not happen, the bug is elsewhere.

in reply to:  3 comment:4 by Balling, 13 months ago

Replying to Cigaes:

Indeed. (It contains tabs.) But as I said, fixing the timestamps should not be done in each individual filters, and especially not with something specific to MPEG timestamps. Normally, these MPEG timestamps resets should be handled before entering the filter graph. If it does not happen, the bug is elsewhere.

Before even trying to fix rollover, which is very buggy indeed right before it happens (#7449), the problem with seeking in MPEG-TS should be fixed. See: #9412, one of the patches is there.

Last edited 13 months ago by Balling (previous) (diff)
Note: See TracTickets for help on using tickets.