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 80EC049500 for ; Wed, 13 Mar 2024 13:21:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id ACD7F68CEE6; Wed, 13 Mar 2024 15:21:47 +0200 (EET) Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2CDFB68C458 for ; Wed, 13 Mar 2024 15:21:41 +0200 (EET) Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4Tvrkp6jmBz9tWl for ; Wed, 13 Mar 2024 14:21:38 +0100 (CET) Message-ID: <3b4409fb-03a1-42f9-aafb-a7c386c0b2df@gyani.pro> Date: Wed, 13 Mar 2024 18:51:36 +0530 MIME-Version: 1.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20240313122425.92457-1-ffmpeg@haasn.xyz> <20240313122425.92457-2-ffmpeg@haasn.xyz> From: Gyan Doshi In-Reply-To: <20240313122425.92457-2-ffmpeg@haasn.xyz> X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_scale2ref: switch to FFFrameSync 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 2024-03-13 05:54 pm, Niklas Haas wrote: > From: Niklas Haas > > This filter's existing design has a number of issues: > > - There is no guarantee whatsoever about the order in which frames are > pushed onto the main and ref link, due to this being entirely > dependent on the order in which downstream filters decide to request > frames from their various inputs. As such, there is absolutely no > synchronization for ref streams with dynamically changing resolutions > (see e.g. fate/h264/reinit-*). The only raison d'etre for scale2ref was to have some way to access another stream's parameters. Dynamic streams weren't really the focus. > - For some (likely historical) reason, this filter outputs its ref > stream as a second ref output, which is in principle completely > unnecessary (complex filter graph users can just duplicate the input > pin), but in practice only required to allow this filter to > "eventually" see changes to the ref stream (see first point). In > particular, this means that if the user uses the "wrong" pin, this > filter may break completely. This change is fine but you should note in the manual docs that this change has occurred (and when) as existing scripts will fail due to the surplus output pad. Regards, Gyan _______________________________________________ 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".