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 5A7654954C for ; Thu, 14 Mar 2024 00:00:48 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C187168D022; Thu, 14 Mar 2024 02:00:45 +0200 (EET) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 25E7368C7F8 for ; Thu, 14 Mar 2024 02:00:39 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 6C193E0002 for ; Thu, 14 Mar 2024 00:00:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1710374438; 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=mlJBfdOfRhiSrxIjKiM3kblu42FhriPfOCHUDacu8bs=; b=TJ18DLMeH9ZrNjvjkGzRZ86OshF7Kbrzu4/F1GQFwowumnYb1hOFuefcXO06trmraBG4m4 lr1wC6s14l6sLTKMMjQw8+rFfhk4u9Dk7DR2Nh92/nX6Pj+dWSnuc+99b60pM3ihl9nXhw BGLLZfDNRqVh+1rvLMUjGW+gtDhXLaQOcS+vEQmSSeAQTKZCP2su6j3atADqKhs4nRktEd g3srp6Gn8r9OhE0tgfhZ2LswLvRWSaLjkBKlhDFcG/rOLdDxAfonzo4u56TDwqaHeVLXLv vS2CXZIZMNKqGIIsD8i6mtdYxKiiu0KRZWb7tGWGYoMm3wnkD/f3+w/wAavF9Q== Date: Thu, 14 Mar 2024 01:00:37 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240314000037.GA6420@pb2> References: <20240313122425.92457-1-ffmpeg@haasn.xyz> <20240313122425.92457-2-ffmpeg@haasn.xyz> <20240313234126.GZ6420@pb2> <35250a40-88fb-4337-b237-81e6c50a25f0@gmail.com> MIME-Version: 1.0 In-Reply-To: <35250a40-88fb-4337-b237-81e6c50a25f0@gmail.com> 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="===============6768539688687572337==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6768539688687572337== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CtvlPTJ5HiQixxmu" Content-Disposition: inline --CtvlPTJ5HiQixxmu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 13, 2024 at 08:43:58PM -0300, James Almer wrote: > On 3/13/2024 8:41 PM, Michael Niedermayer wrote: > > 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 reque= st > > > frames from their various inputs. As such, there is absolutely no > > > synchronization for ref streams with dynamically changing resoluti= ons > > > (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 inp= ut > > > 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 option= s) > > > - framesync only supports a single output, so we can (indeed must) dr= op > > > the redundant ref output stream > > >=20 > > > Update documentation, changelog and tests to correspond to the new us= age > > > 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(-) > >=20 > > this causes > > ./ffplay --help > > to segfault >=20 > Unrelated to this crash, but why does that command line output every sing= le > option from every single filter? It's several thousand printed lines. > Shouldn't that be the output of --longhelp or similar, and leave --help to > print some basic non filter specific options? I think the help handling should be consistent between the tools, iam not s= ure why it is not currently thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable --CtvlPTJ5HiQixxmu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZfI+JQAKCRBhHseHBAsP q3MOAJ9d8Wg7dyovCxeHY09fr34t5KiGGgCfbH0Ri1EpVajWE9xTP0tzVwX85i8= =e6W+ -----END PGP SIGNATURE----- --CtvlPTJ5HiQixxmu-- --===============6768539688687572337== 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". --===============6768539688687572337==--