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 F2DDC40B4B for ; Thu, 7 Apr 2022 07:44:22 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B230668B211; Thu, 7 Apr 2022 10:44:19 +0300 (EEST) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 63EF968A467 for ; Thu, 7 Apr 2022 10:44:13 +0300 (EEST) Received: by mail-yb1-f170.google.com with SMTP id d138so8092899ybc.13 for ; Thu, 07 Apr 2022 00:44:13 -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=OPsOfuTm3iuyJFvvkKwm48cXTXxhtTsHiaSPTA+Rggs=; b=R//8lvAR9y5482dlczVkUDeJ0oPFX6JVFuJVWhgQyYRVUNOKcn5x6+aFok6IsmRy2Q 770MF4j7qrffC0jQYsZX5GrxlNMtMg0aMX0CNirKv0SCvjkSgR+bWN5LxdLnuwOuxmm7 v4EZLabi2yU4ALPYJ2CSJGuer9r9Xkx2bt8OAX7lPzAsQRbAtnp1dsgXMaGD0APNQ0Oq 0X3Nx0ubjH6F/Jq8KJc4GTJ8AUgGG8c87FEG3xdh+lhXGW1UV43ntt4cqDGg4D+dvwIq HE625CNSaKPQx7qjjXb0kMKAEXsbwql41Of3guELsn2LSx0FDtGkqtcMm8ECj4C12GvV ZyUQ== 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=OPsOfuTm3iuyJFvvkKwm48cXTXxhtTsHiaSPTA+Rggs=; b=D3PmcerE7n7oudHrz7aMgBFluyU9CKOpL7PJBaCpoMl3Ik9CxNtw23M7FWoz3pSikR ea1OJyqk6zXYTI+p5Eqz95t69YXSweoVltkQuPu7F9P+FOfP7avnSZfbNavg9y0uEjJ8 O9XiYAdk4Q3pZAOoXe6YQEw6f8wDZ4X7ZMV5nKKdBKfu11/27D+xePAjmSywQePmfRi5 tkKj0zr0T39nlwPHP9z+nSv/X845chuTWufzkIe3MuN2WaYQjwue6Hb0PAph5Bv7L+Ch BgJ2OGVOaXMHg8irIKnOFaDlx3X1Vrc7xwv38SGwC5JMtlhXca79pKqFcGLyRudNXUin hTYA== X-Gm-Message-State: AOAM530r/phsC8ZCjsPqiGNYspaPhJieGsMH7P94elCwgDIVkLkcbvUa 4G9pYT/dBgTG5LnRMnOqw+ncpOxi4YIxp3kzBsetNL8E X-Google-Smtp-Source: ABdhPJz8LrbrS/u6sdap6HHGx4oQ5QaMZVEmgs8NFWCHtC6tJ9HL0bxPxy/X5yrvwJXZq9Ded3HJwt8gJUtgo80hNW8= X-Received: by 2002:a25:ab6a:0:b0:63d:9352:ec41 with SMTP id u97-20020a25ab6a000000b0063d9352ec41mr9355269ybi.250.1649317451755; Thu, 07 Apr 2022 00:44:11 -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: Thu, 7 Apr 2022 09:46:24 +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 Wed, Apr 6, 2022 at 1:49 PM Paul B Mahol wrote: > > > 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. > Alternatively, use current logic in ladspa filter, (also add option with same name). This would need less code, and probably better approach, as there is no extra latency introduced. Than mapping 1:1 between same number of samples per frame is not hold any more, but I think that is not much important any more. > > >> -- >> >> 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".