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 31A7B40BCF for ; Thu, 7 Apr 2022 21:56:32 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7437368B21F; Fri, 8 Apr 2022 00:56:30 +0300 (EEST) Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E23CB68B0C3 for ; Fri, 8 Apr 2022 00:56:23 +0300 (EEST) Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-2eb57fd3f56so76833117b3.8 for ; Thu, 07 Apr 2022 14:56:23 -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=S0dpPElPo96BXplX6Qu9Y5LB/mHxEpos7yD8hI5OWe0=; b=N4tCf458wEHegAbw2s/kKaKz9L250iOnDpALb7C6b7z8ZiOolb+DfnCGr+6ANcvNSR ThKyjds123IotbZm4/aUCnl4HRHljkeiVNZrW6wMhYo7hwcu09v5aUzSJSubMws3FUPn B/lrh/8SM9ediD6iPLzMyVybdMPpsa1G3EqPEJtTamWo1uhouQJCs8rWeN3T8I/jcvJW b4cOYTI/FaCHaUU9NmtT9MwFjSuJRs4VEywHZn2Y2r6yOhDhrJksxa0+tX8sZ9kCR7pk pab8aVoNAjUsMs6LKQfer+HgZnjfdu1cBjfZSH5Y7GVvV3nFWI9/s8uxGRlkZItFNE/t f+WA== 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=S0dpPElPo96BXplX6Qu9Y5LB/mHxEpos7yD8hI5OWe0=; b=bUm9SEt3wviynkMttoXScGQTgjE0rvVfpaj++8XWh6hh7q6vdur73E0AatpSS3+zzo HMam+mA9hcMEjdLM+w9CCShrVbCAOjrg8LNukA2JstNNRFFDsn+L+Zf9d6AuUup7H4ZW sxfL73/f884Z3ATXZ1Kr7ErMu5KIRPYAu9Jb/SUTrjuolBjW4h2bUTHytuqb/q35rkC0 XwKku4QJaTe8KN0F2nsa619/4p7+RKsAEgoFJQQ9ayzIrvEX0yqRB6KCJsxs3ppSnWUQ pvw65c1gj1bzPZ+b1Yq2N/nd7rfjJDvZJjB3p00r7+gJ0iIEd1gCdiMxeMfEvub9i0qg hr4g== X-Gm-Message-State: AOAM532NNoQ6uEhkhVmpyizOoq8yu9c0LcjdTFUPLZFbFGSQyi16OQYg 0EJERdDdGdN4SJIshWxCxXDXLBoMV668YEIIARZBGUJEGxswyw== X-Google-Smtp-Source: ABdhPJxzOoyQjGBDCii0ufmIfO/VGPTc9zKnzeYtauFg73DYCEB5TDV4vJWlMBCrLcm+zwBertuxSdZWvmNHyfOGBTA= X-Received: by 2002:a81:3489:0:b0:2eb:8b8e:c02c with SMTP id b131-20020a813489000000b002eb8b8ec02cmr13432337ywa.213.1649368582062; Thu, 07 Apr 2022 14:56:22 -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: Thu, 7 Apr 2022 14:56:11 -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 Thu, Apr 7, 2022 at 12:44 AM Paul B Mahol wrote: > On Wed, Apr 6, 2022 at 1:49 PM Paul B Mahol wrote: > > > > > > > On Tue, Apr 5, 2022 at 8:57 PM Wang Cao < > wangcao-at-google.com@ffmpeg.org> > > 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. > Thank you for replying to me with your valuable feedback! I have checked af_ladspa and the "request_frame" function in af_ladspa looks similar to what I'm doing. The difference comes from the fact that I need an internal frame buffer to keep track of output frames. Essentially I add a frame to the internal buffer when an input frame comes in. The frames in this buffer will be the future output frames. We start writing these output frame data buffers only when the internal lookahead buffer has been filled. When there is no more input frames, we flushing all the remaining data in the internal frame buffers and lookahead buffers. Can you advise on my approach here? Thank you! I can put my current implementation of "filter_frame" and "request_frame" into the "activate" approach as you suggested with speechnorm/dynaudnorm. -- Wang Cao | Software Engineer | wangcao@google.com | 650-203-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".