From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id A30D843E1B for ; Wed, 14 Sep 2022 20:26:53 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6EF3768BB4C; Wed, 14 Sep 2022 23:26:50 +0300 (EEST) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0131568B96F for ; Wed, 14 Sep 2022 23:26:44 +0300 (EEST) Received: by mail-ed1-f43.google.com with SMTP id x94so6688512ede.11 for ; Wed, 14 Sep 2022 13:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date; bh=wFS/1YDF8vIVony/cwT9ShMm2dw0IhpuHgl8mDR7zns=; b=mEYazxGc9Up8lhIIKtGDGA1eu14HcgVzA6zh7GIM1a4hnZ3JrMGWea81MUxHrCHnn2 BNNXzbwFIIhNiVMkVF+EO41mpazy1Om51WuAKEEcsDcPLIt3aVGZGLu1p74IumcliTvi 2yxhIemy+rhrk2A9s6z9BSVtGA5Xzm12uLtaU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=wFS/1YDF8vIVony/cwT9ShMm2dw0IhpuHgl8mDR7zns=; b=I3YZTYCZdXzBtNXPDBUC9lgpZIeoBnOrjcMtL/N0nlTpM98okLBn+S+qnj1lhzDC9L gu/jgoZim2H3OD0EexMt+zhuBkBsbSEQd9HMwEjlLjI59ubPe3h9Oujp/VN50m+THEag BJLdOxPfxzJ1iHSiYuRSQM+pqSUqv3PsJ76ZAXT5QGo/XL1r8GsPrQCKXvJ7nVz+R9L2 chnyalx3FV4IrIxuGY+1j4NFu5K/mVP/rxCAYPyloquo+pPFDKNLDYuLhDP9lMOODBP5 6Bnz7ca4zFQXXVpJKtKfu1jcTDtqujMzEYZihCgF+jixOg/tTe7Xrf+ps9IPWV5yKxq7 GsRw== X-Gm-Message-State: ACgBeo0poVGGXexU/Mto/yR9swRH2NvKzC1n0yA8X+KKy7wOM9yatuUu LGqRXVorsGrHNiPZxmXrmkRut9z/vAf7egrJWOmdhLqGL4gTIA== X-Google-Smtp-Source: AA6agR7WeYw2Hr3pNpvHx8b3fD/Bi7TTkJuJ9FkjMges6AKF6CQ6h9gxnp/lDo9q3+mHe8H/rJu77uvDtT/9zTWhR5Y= X-Received: by 2002:aa7:de9a:0:b0:44d:8191:44c5 with SMTP id j26-20020aa7de9a000000b0044d819144c5mr31735248edv.232.1663187204270; Wed, 14 Sep 2022 13:26:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Li-Heng Chen Date: Wed, 14 Sep 2022 13:26:33 -0700 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] libavfilter/f_select: switch to activate and properly handle EOF pts X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Wed, Sep 14, 2022 at 11:15 AM Nicolas George wrote: > > 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. > Please allow me to explain again with your example. That's say we have an input with 20 frames (0-19), and we want to keep prime number frames with select filter, -vf select='eq(n\,2)+eq(n\,3)+...+eq(n\,13)+eq(n\,17)' In the activation function, select->eof_pts is updated to n at n=4, 6, 8, 12, 14, 18 However, select->eof_pts is passed into ff_outlink_set_status only at n=20, since ff_inlink_acknowledge_status returns 1. > 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. > My point is to indicate EOF PTS to last-selected-frame (n=17) instead of last-input frame (n=19). The reason why I added one to select->eof_pts is because the existing EOF PTS is the pts value after the last frame (20). > > 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. > In the existing behavior, the EOF PTS is always the pts after the last input frame. For example, if the input to ffmpeg has 20 frames, the EOF PTS passed to the next filter is the pts of the "21th" frame, no matter the 20th frame is dropped or not. > > 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. > Regardless of my logic, this behavior looks weird to me. In my opinion, -vf select='eq(n\,24),fps=25/1' should produce the same result as just having -vf select='eq(n\,24)'. However, select='eq(n\,24),fps=25/1' generates 22 identical frames while select='eq(n\,24)' only outputs one frame... Thanks, Li-Heng > Regards, > > -- > Nicolas George > _______________________________________________ > 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". _______________________________________________ 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".