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 025FF49531 for ; Wed, 13 Mar 2024 23:41:37 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B355468CF92; Thu, 14 Mar 2024 01:41:34 +0200 (EET) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5B16F68C93A for ; Thu, 14 Mar 2024 01:41:28 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 7C9C0FF802 for ; Wed, 13 Mar 2024 23:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1710373287; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=m/r/T01ohuHi9mb9x0SXucmyCU84AF8d0iBCqXhnws0=; b=laXZBFzmcG8AwAC0nERWyg0IummPWpjoS6bwa2qdfZ1fOiNHjhW8NGajjk2vQXf8ouKYZ6 7OLSXwq3JphqeSPzJFL7CcbgYHNCk3H38DgEuLlTeE3D4+F1+JGdSISYMjALLv5jnQB73R Pt4SAkMeu0CCHBuN/hfoFyX/3GUiMu4SIq6eYTywOdvg4+iI1kbCZ9uT6NOhRv9oDo4SBC Gyyn8ca127F8BGv9cwFWCv8iiXOmyi0rkemEfaOvOEkLT93lp5w6KbzDYfEiPWYd714D+w kWKYDzQN6ll011hmh38mmpNTFuTEfy1qLooRNcfyhrY6AVF4/+HQ4FsoXPkJtg== Date: Thu, 14 Mar 2024 00:41:26 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240313234126.GZ6420@pb2> References: <20240313122425.92457-1-ffmpeg@haasn.xyz> <20240313122425.92457-2-ffmpeg@haasn.xyz> MIME-Version: 1.0 In-Reply-To: <20240313122425.92457-2-ffmpeg@haasn.xyz> X-GND-Sasl: michael@niedermayer.cc 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-Type: multipart/mixed; boundary="===============5951012621304298589==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============5951012621304298589== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J3oP+kAhDWsiZejI" Content-Disposition: inline --J3oP+kAhDWsiZejI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 13, 2024 at 01:24:25PM +0100, Niklas Haas wrote: > From: Niklas Haas >=20 > This filter's existing design has a number of issues: >=20 > - 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-*). >=20 > - 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. >=20 > - The default filter activation function is fundamentally incapable of > handling filters with multiple inputs cleanly, because doing so > requires both knowledge of how these inputs should be internally > ordered, but also how to handle EOF conditions on either input (or > downstream). Both of these are best left to the filter specific > options. (See #10795 for the consequences of using the default > activate with multiple inputs). >=20 > Switching this filter to framesync fixes all three points: >=20 > - ff_framesync_activate() correctly handles multiple inputs and EOF > conditions (and is configurable with the framesync-specific options) > - framesync only supports a single output, so we can (indeed must) drop > the redundant ref output stream >=20 > Update documentation, changelog and tests to correspond to the new usage > pattern. >=20 > Fixes: https://trac.ffmpeg.org/ticket/10795 > --- > Changelog | 2 + > doc/filters.texi | 10 +- > libavfilter/vf_scale.c | 130 ++++++++++++----------- > tests/filtergraphs/scale2ref_keep_aspect | 3 +- > 4 files changed, 76 insertions(+), 69 deletions(-) this causes =2E/ffplay --help to segfault [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire --J3oP+kAhDWsiZejI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZfI5oAAKCRBhHseHBAsP q4QVAJ9JU7E3Su9/S6jzPiVqU8BVlfA9CQCfQRxPf6Ilm/hWeW+IIZ8Dn/HyIdw= =Zt08 -----END PGP SIGNATURE----- --J3oP+kAhDWsiZejI-- --===============5951012621304298589== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============5951012621304298589==--