[FFmpeg-devel] [PATCH] libavfilter/f_select: switch to activate and properly handle EOF pts

[Nicolas George]

Li-Heng Chen (12022-09-14):
> Thanks for the comment, Nicolas! I've attached a new patch file which
> should address the comments. I also want to mention that this patch is
> similar to another one Paul had done for setpts filter:
> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=2a546fb7d5722c306dd42c715137e5e493b0d5be

It is similar in its form, but the logic is very different: Paul's
commit has the function evaluated for the final timestamps.

> The attached patch should have the commit message wrapped, and I
> have also added a comment in the code to explain the logic:
> /* Two conditions that current pts could be the EOF pts:
> * - If the current frame N is not selected while the previous
> * frame (N-1) is selected, frame N-1 could be the last frame,
> * hence we update select->eof_pts.
> * - Last input frame: we have EOF status, and the current (last)
> * frame is selected */

Thanks for explaining. Unfortunately, it confirms my analysis that your
logic is slightly flawed.

Consider a select filter that keeps only the frames with a PTS that is a
prime number. The frame with PTS 13 used to extend in the timeline of
the stream from 13 inclusive to 14 exclusive. Now it extends from 13
inclusive to 17 exclusive; the timestamp 14 was completely skipped.

There is no reason that a EOF arriving a little after that would change
that and make the filter re-consider 14: the frame 14 was skipped, its
PTS should not be considered.

> This patch does not change the frame timestamps. Instead, we added
> another variable select->eof_pts to track possible EOF pts. It sets the
> EOF pts as the pts *after* the last selected frame (e.g. if the last frame
> selected by the filter is frame 20, EOF pts is set as the pts of frame 21)

Which means it sets the EOF PTS at the timestamp of a frame that was
dropped. This is not logical.

> I have also tested the trim filter, which does not present this bug. However,
> if you do -vf select='eq(n\,24)',fps=25/1 on the above example, this selected
> frame will also be duplicated 21 times, which is also not an expected behavior
> for the select filter.

I consider it the correct behavior.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220914/cefaa9c1/attachment.sig>