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 2DD284294B for ; Wed, 6 Apr 2022 11:47:12 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 29CC768B261; Wed, 6 Apr 2022 14:47:10 +0300 (EEST) Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2AD4068A5B3 for ; Wed, 6 Apr 2022 14:47:02 +0300 (EEST) Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-2eb57fd3f56so22894117b3.8 for ; Wed, 06 Apr 2022 04:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=3/a2REnuCcvTsqnleQzgJaWwJKeRnZP1rJ0LSwosjbw=; b=My1bSkxhKQ3/3eWOYOrG9lPwh9u863inT49p4mZWluM23pQzKDpGOFUnAOYJoQR9cX 2Rsrsp3hCXWaBnnNlekjKM/Fu7k+YR846YtKpQjfsN7IKL75+YmyLN30PWddebCymgxt QXut0PEIa+MHPuJRG72d7rmKDAwoFckpVngwHtja8b2yTyVKNt2h2apDlJcxwh3dSmPt vuQ53T3BZC/WK0/bQlbUEM8QzFFC7z+JlcIMalBlRvK8CLZqrbe1M4DN32g7t77w8gtW aWSXk8rmp11mRPZvKXkUh3lMVJNGOGsY/QWPXSIc+k8+fv78kfKqAM3p41CTV5w8ar2t Wz7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=3/a2REnuCcvTsqnleQzgJaWwJKeRnZP1rJ0LSwosjbw=; b=igPoyCoUNCIq/+DlnFRFYBezX4TQ4Gb5AH0yadxMa0ieZnLsIWhe6MTzn2wpFICcQk YMTTUNPWnPT+eDUJRtfwJh6i4AJBxj0UfCidYIEatpdDcdYL9CSUDICNYmbqTxgRX6RT kZJm8aTZje6vjR4QuMo1IgWOLlqbbNWjeBntn8W1H7eMafheD7AHcsdhiXjsl1jY8qgc LsEQlqYg9L2bNz1rKTmKmPyhYUFJBrUcdy2/C7i1qMgJzynyixuEE62eEb2OGAzAl5cx PU2JyRwfmN8G5cU9ugByUSsTdqM68wTv0pCwTaWvyygY2PMOwTogekaFpcJknBfAm3fh koRQ== X-Gm-Message-State: AOAM530iEvQITslh2e8lHfaSxJaGJw4SjvTxKwX0zxrMesceczuGFBBy cdSUtBYveCbH7HpFPVsafRgblsFhwrOGTCUKHZShvgYD X-Google-Smtp-Source: ABdhPJxSha45P5qATUIp7RKgMm8lAbdIRD4QkbW62Q6k+M7akx4koiKUTYfG/6ETPZnwwWOeXFHTv4eBBhRrCFw0B/8= X-Received: by 2002:a81:4f55:0:b0:2eb:7da1:f4ae with SMTP id d82-20020a814f55000000b002eb7da1f4aemr6515062ywb.221.1649245621326; Wed, 06 Apr 2022 04:47:01 -0700 (PDT) MIME-Version: 1.0 References: <20220327060800.3732289-1-wangcao@google.com> <2ec3971d-f698-1369-1ace-eac613afc980@passwd.hu> In-Reply-To: From: Paul B Mahol Date: Wed, 6 Apr 2022 13:49:14 +0200 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH] avfilter/alimiter: Add "flush_buffer" option to flush the remaining valid data to the output 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 Tue, Apr 5, 2022 at 8:57 PM Wang Cao wrote: > On Mon, Apr 4, 2022 at 3:28 PM Marton Balint wrote: > > > > > > > On Mon, 4 Apr 2022, Paul B Mahol wrote: > > > > > On Sun, Mar 27, 2022 at 11:41 PM Marton Balint wrote: > > > > > >> > > >> > > >> On Sat, 26 Mar 2022, Wang Cao wrote: > > >> > > >>> The change in the commit will add some samples to the end of the > audio > > >>> stream. The intention is to add a "zero_delay" option eventually to > not > > >>> have the delay in the begining the output from alimiter due to > > >>> lookahead. > > >> > > >> I was very much suprised to see that the alimiter filter actually > delays > > >> the audio - as in extra samples are inserted in the beginning and some > > >> samples are cut in the end. This trashes A-V sync, so it is a bug > IMHO. > > >> > > >> So unless somebody has some valid usecase for the legacy way of > > operation > > >> I'd just simply change it to be "zero delay" without any additional > user > > >> option, in a single patch. > > >> > > > > > > > > > This is done by this patch in very complicated way and also it really > > > should be optional. > > > > But why does it make sense to keep the current (IMHO buggy) operational > > mode which adds silence in the beginning and trims the end? I understand > > that the original implementation worked like this, but libavfilter has > > packet timestamps and N:M filtering so there is absolutely no reason to > > use an 1:1 implementation and live with its limitations. > > > Hello Paul and Marton, thank you so much for taking time to review my > patch. > I totally understand that my patch may seem a little bit complicated but I > can > show with a FATE test that if we set the alimiter to behave as a > passthrough filter, > the output frames will be the same from "framecrc" with my patch. The > existing > behavior will not work for all gapless audio processing. > > The complete patch to fix this issue is at > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220330210314.2055201-1-wangcao@google.com/ > > Regarding Paul's concern, I personally don't have any preference whether to > put > the patch as an extra option or not. With respect to the implementation, > the patch > is the best I can think of by preserving as much information as possible > from input > frames. I also understand it may break concept that "filter_frame" outputs > one frame > at a time. For alimiter with my patch, depending on the size of the > lookahead buffer, > it may take a few frames before one output frame can be generated. This is > inevitable > to compensate for the delay of the lookahead buffer. > > Thanks again for reviewing my patch and I'm looking forward to hearing from > you :) > Better than (because its no more 1 frame X nb_samples in, 1 frame X nb_samples out) to replace .filter_frame/.request_frame with .activate logic. And make this output delay compensation filtering optional. In this process make sure that output PTS frame timestamps are unchanged from input one, by keeping reference of needed frames in filter queue. Look how speechnorm/dynaudnorm does it. > -- > > Wang Cao | Software Engineer | wangcao@google.com | 650-203-7807 > <(650)%20203-7807> > _______________________________________________ > 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".