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 1D689428CA for ; Tue, 5 Apr 2022 18:57:01 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AEED968B1A5; Tue, 5 Apr 2022 21:56:59 +0300 (EEST) Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id CFE4F68981E for ; Tue, 5 Apr 2022 21:56:53 +0300 (EEST) Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-2eba37104a2so2699287b3.0 for ; Tue, 05 Apr 2022 11:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oRCSxUr0J9Z7fo/m26ywHfrEL7DhIY54oyjqYLxWT5M=; b=OxfYjefVmm2UJX5DTGzXlKy2SUm3755nQBhvuUKEeENibzKBPUAp2Ge6vmTFnA65bx Ysf+gT+VyBk8rucOHwZxNTpvdtTI9OeM7UD8KzLoowMM6YIKbwToEzHEGXFlSp5Zvx3r DnOkS8Y0hxrvZZhbxIoy4KKdU1oDVXxMHTBjelYPGapXtKCnSltK1vT3VrZWXPHStrIs nLs5uQpkwHXEcFDkrAcAQ26d2jykT+ZY7ZzKI0V7Apc4FnhQ8BW3Ur8JNWEZD46qO2Wo WZIpIS6qLcOzHGBN4nnVbXK8+gutC6I5ZJDougAB3TwC21jRKqhPuXseuaStP7iG1iVG LuHQ== 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=oRCSxUr0J9Z7fo/m26ywHfrEL7DhIY54oyjqYLxWT5M=; b=R6x3P/lIyEURHtDr0eejY6lcovEjBFi12fQY8ZLYXHdnANiio3+ZhWCqPT4M23MdBF v4GWmVYu/bpLOY6h2fa/aNTPe09Xj58p2wHs7G1hGdyHNaoL2AQfmjhY0szcnsIfySn7 RvW2k5kqJe0eYgfry06Om0WKKQBMNuXwNZcJiHpN+ycwRO3/w4a2L8Bmmuy5RlcTynfq kF8rcmHrDMI4zMEh9+0n64nRgRbqstw/FWly2DGvJlN3mL9ZkglmZZHTAdOA1GIGR43J dcZcdlIgwzExeLUfhxyU28D96bFL2A3I49Zd61NJo8eSwNLATcZyOrwjGhSobvhSMRFa yEEw== X-Gm-Message-State: AOAM530Yg6VID0YptooB1vuqO/TqY7SD5pGR+j9MzI41K3uRVoqdtNfS 05otZsOfp69BiSwGYuCO+uxN1cy8y+TOUiQ7aZHkzddIaudMcA== X-Google-Smtp-Source: ABdhPJw2zGHOALINHIcTjeKBj/Yli+4ogKjfcfH9dh9vRoY1vd5yUo0dNgL0K7+bWX+OrryHHkzU7kaoUcrCAf5gKIw= X-Received: by 2002:a0d:ff42:0:b0:2eb:3711:f77f with SMTP id p63-20020a0dff42000000b002eb3711f77fmr3930984ywf.488.1649185012086; Tue, 05 Apr 2022 11:56:52 -0700 (PDT) MIME-Version: 1.0 References: <20220327060800.3732289-1-wangcao@google.com> <2ec3971d-f698-1369-1ace-eac613afc980@passwd.hu> In-Reply-To: From: Wang Cao Date: Tue, 5 Apr 2022 11:56:41 -0700 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 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 :) -- 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".