From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <ffmpeg-devel-bounces@ffmpeg.org>
Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100])
by master.gitmailbox.com (Postfix) with ESMTPS id F37DF4CC0F
for <ffmpegdev@gitmailbox.com>; Sat, 12 Apr 2025 01:07:39 +0000 (UTC)
Received: from [127.0.1.1] (localhost [127.0.0.1])
by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 090AA68C49F;
Sat, 12 Apr 2025 04:07:36 +0300 (EEST)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net
[217.70.183.194])
by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 46481687C94
for <ffmpeg-devel@ffmpeg.org>; Sat, 12 Apr 2025 04:07:29 +0300 (EEST)
Received: by mail.gandi.net (Postfix) with ESMTPSA id 665094318E
for <ffmpeg-devel@ffmpeg.org>; Sat, 12 Apr 2025 01:07:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc;
s=gm1; t=1744420048;
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=Kl6ukiB11GYWIUB17ror6Nd+bUtADnieuarJzb+Knr8=;
b=CDRadKEXjW+SVOMHKAiUhgrFRPY51Tqslw+8f8KKi/WAmagINELt3HWNxopvg0OMkGDStS
T1lhmD0RMOYnJthYYznzECsfHL2FFKehr+VUMnJhuaoHLFFExqEcWrjOH5w7T0MlqIYNEz
15MoXaTTch/qVoBEasMXqhjnOzbhgVW7ow2NyG8Vg5aQBTigQ0rEAJvR3nT0RKWKS4bBRL
eGX/6GBpsSMefskGWs+StE4DTeGbXR3Aks6S/J+MQ707fKHCkaKkdvCSzYq17AlXhj091H
+OBTiw6WrzA5kAiN2izsbWluEmrlZDAVGmmIde4u/mpGui9NZy3NiowXZUOEVw==
Date: Sat, 12 Apr 2025 03:07:27 +0200
From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Message-ID: <20250412010727.GI4991@pb2>
References: <20250404211451.91394-1-romain.beauxis@gmail.com>
<20250404211451.91394-2-romain.beauxis@gmail.com>
<20250410011153.GB4991@pb2>
<CABWZ6OQ3bbwOXM_ontxbrosFxB3uMHo3NNjTnzVbZWBzaFcqdw@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CABWZ6OQ3bbwOXM_ontxbrosFxB3uMHo3NNjTnzVbZWBzaFcqdw@mail.gmail.com>
X-GND-State: clean
X-GND-Score: -85
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvudeffeehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdduhedmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttddunecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpeevueefgeefudetuefggfeivdetteekgfdukedtjeeuffevheegleduleffudfgheenucffohhmrghinhepfhhfmhhpvghgrdhorhhgnecukfhppeeguddrieeirdeijedruddufeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeguddrieeirdeijedruddufedphhgvlhhopehlohgtrghlhhhoshhtpdhmrghilhhfrhhomhepmhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtpdhnsggprhgtphhtthhopedupdhrtghpthhtohepfhhfmhhpvghgqdguvghvvghlsehffhhmphgvghdrohhrgh
X-GND-Sasl: michael@niedermayer.cc
Subject: Re: [FFmpeg-devel] [PATCH v11 1/8] libavcodec/decode.c: intercept
`AV_PKT_DATA_METADATA_UPDATE` packet extra data,
attach them to the next decoded frame with the same PTS.
X-BeenThere: ffmpeg-devel@ffmpeg.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org>
List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>,
<mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe>
List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel>
List-Post: <mailto:ffmpeg-devel@ffmpeg.org>
List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help>
List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>,
<mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe>
Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Content-Type: multipart/mixed; boundary="===============3576891853714941896=="
Errors-To: ffmpeg-devel-bounces@ffmpeg.org
Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org>
Archived-At: <https://master.gitmailbox.com/ffmpegdev/20250412010727.GI4991@pb2/>
List-Archive: <https://master.gitmailbox.com/ffmpegdev/>
List-Post: <mailto:ffmpegdev@gitmailbox.com>
--===============3576891853714941896==
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="0jKRN1SIE8Km0AwT"
Content-Disposition: inline
--0jKRN1SIE8Km0AwT
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Apr 09, 2025 at 09:25:56PM -0500, Romain Beauxis wrote:
> Le mer. 9 avr. 2025 =E0 20:12, Michael Niedermayer
> <michael@niedermayer.cc> a =E9crit :
> >
> > On Fri, Apr 04, 2025 at 04:14:44PM -0500, Romain Beauxis wrote:
> > > ---
> > > libavcodec/decode.c | 130 ++++++++++++++++++++++++++++++++++++++++++=
++
> > > 1 file changed, 130 insertions(+)
> > >
> > > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > > index fca0c7ff58..39d054bdea 100644
> > > --- a/libavcodec/decode.c
> > > +++ b/libavcodec/decode.c
> > [...]
> > > @@ -702,6 +809,8 @@ int attribute_align_arg avcodec_send_packet(AVCod=
ecContext *avctx, const AVPacke
> > > {
> > > AVCodecInternal *avci =3D avctx->internal;
> > > DecodeContext *dc =3D decode_ctx(avci);
> > > + const uint8_t *side_metadata;
> > > + size_t size;
> > > int ret;
> > >
> > > if (!avcodec_is_open(avctx) || !av_codec_is_decoder(avctx->codec=
))
> > > @@ -719,6 +828,14 @@ int attribute_align_arg avcodec_send_packet(AVCo=
decContext *avctx, const AVPacke
> > > ret =3D av_packet_ref(avci->buffer_pkt, avpkt);
> > > if (ret < 0)
> > > return ret;
> > > +
> > > + side_metadata =3D av_packet_get_side_data(avpkt, AV_PKT_DATA=
_METADATA_UPDATE, &size);
> >
> >
> > > + if (avpkt->pts !=3D AV_NOPTS_VALUE && side_metadata) {
> > > + ret =3D insert_pending_metadata(&dc->pending_metadata, a=
vpkt->pts,
> > > + side_metadata, size);
> > > + if (ret < 0)
> > > + return ret;
> >
> > Is the tree needed and a FIFO not enough ?
>=20
> I believe so.
>=20
> There could be scenarios where the DTS are submitted out of order and
> we'd still want the metadata to be attached to the frame it was
> intended for.
>=20
> In fact, I did this change after you suggested such a scenario:
>=20
> >> Can you describe a scenario that you're thinking about?
>=20
> > The users feeds several packets into a multi threaded decoder
> > and then depending on the threads and luck sooner or later
> > one frame comes out.
> >
> > Passing some data in a way that disregards this, feels wrong
> > Hypothetically there also could be a 2nd AV_PKT_DATA_METADATA_UPDATE
> > going in before the frame corresponding to the first comes out
> > but i may be missing something
>=20
> Source: https://ffmpeg.org/pipermail/ffmpeg-devel/2025-March/340948.html
What i was thinkig of is the user passing in multiple
AV_PKT_DATA_METADATA_UPDATE in order
internally these could decode in parallel, but what goes
back to the user is in order again. Now there is frame reordering
but i assumed that metadata updates would not be at that level.
And this would rather be concatenated streams. But i dont know ...
Also if you want to keep the tree code, then error handling may need
to be improved.
Consider that a frame with metadata goes in but decoding has an error
and this frame never comes out.
iam not sure how you want to free metadata for damaged frames that are never
output without assumtations on the ordering
thx
[...]
--=20
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
--0jKRN1SIE8Km0AwT
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZ/m8ywAKCRBhHseHBAsP
q0puAJ4n73G7KUzzHvfkyIHbIp+Kx+kREQCeNsmc1LKkhdOXfniFMEe5dQYTu6s=
=h80d
-----END PGP SIGNATURE-----
--0jKRN1SIE8Km0AwT--
--===============3576891853714941896==
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".
--===============3576891853714941896==--