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 C9CA7422F0 for ; Fri, 17 Dec 2021 11:24:28 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0B8CB6803C7; Fri, 17 Dec 2021 13:24:26 +0200 (EET) Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 84EFB680046 for ; Fri, 17 Dec 2021 13:24:19 +0200 (EET) Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 470DE200002 for ; Fri, 17 Dec 2021 11:24:17 +0000 (UTC) Date: Fri, 17 Dec 2021 12:24:17 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20211217112417.GG2829255@pb2> References: <20211216132151.8216-1-jamrial@gmail.com> <92861361-f316-78a5-3c72-1e279d2a9f8c@passwd.hu> MIME-Version: 1.0 In-Reply-To: <92861361-f316-78a5-3c72-1e279d2a9f8c@passwd.hu> Subject: Re: [FFmpeg-devel] [PATCH 000/279 v2] New channel layout API 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="===============4470865070174208809==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4470865070174208809== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1E8AXipGA1cDb+SH" Content-Disposition: inline --1E8AXipGA1cDb+SH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 17, 2021 at 01:04:19AM +0100, Marton Balint wrote: >=20 >=20 > On Thu, 16 Dec 2021, James Almer wrote: >=20 > > Resending the first two patches only, since this is meant to > > show the implementation of one of the several suggestions made > > in the previous set that need to be discussed and hopefully > > resolved in a call. >=20 > Can you push the full branch somewhere? >=20 > >=20 > > The proposals so far to extend the API to support either custom > > labels for channels are, or some form of extra user information. > >=20 > > - Fixed array of bytes to hold a label. Simple solution, but > > the labels will have a hard limit that can only be extended > > with a major bump. This is what i implemented in this version. > > - "char *name" per channel that the user may allocate and the > > API will manage, duplicate and free. Simple solution, and the > > name can be arbitrarily long, but inefficient (av_strdup() per > > channel with a custom label on layout copy). > > - "const char *name" per channel for compile time constants, or > > that the user may allocate and free. Very efficient, but for > > non compile time strings ensuring they outlive the layout can > > be tricky. > > - Refcounted AVChannelCustom with a dictionary. This can't be > > done with AVBufferRef, so it would require some other form > > of reference counting. And a dictionary may add quite a bit of > > complexity to the API, as you can set anything on them. >=20 > Until we have proper refcounting API we can make the AVBufferRef in > AVChannelLayout a void *, and only allow channel_layout functions to > dereference it as an AVBufferRef. This would mean adding some extra helper > functions to channel layout, but overall it is not unsolvable. >=20 > The real question is that if you want to use refcounting and add helpers = to > query / replace per-channel metadata, or you find the idea too heavy weig= ht > and would like to stick to flat structs. what is the advantage of refcounting for channel metadata ? is it about the used memory, about the reduced need to copy ? what kind of metadata and what size do you expect ? bytes, kilobytes, megabytes, gigabytes per channel ? what is the overhead for dynamic allocation and ref counting? that is at which point does it even make sense ? thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives.= =20 -- Abba Eban --1E8AXipGA1cDb+SH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYbxzXQAKCRBhHseHBAsP q1FRAJ41KqHllcpHx1tNSmwIa28YUniXhgCfXWGtQkHSH5euKVptFkuxb5NKykk= =BP7l -----END PGP SIGNATURE----- --1E8AXipGA1cDb+SH-- --===============4470865070174208809== 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". --===============4470865070174208809==--