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 2A7B0421C9 for ; Fri, 17 Dec 2021 00:04:30 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0243468AA81; Fri, 17 Dec 2021 02:04:28 +0200 (EET) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A7A2968A5E7 for ; Fri, 17 Dec 2021 02:04:21 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id 18157E6589 for ; Fri, 17 Dec 2021 01:04:21 +0100 (CET) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n2k-k4LsQJY for ; Fri, 17 Dec 2021 01:04:19 +0100 (CET) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id 17AC9E6588 for ; Fri, 17 Dec 2021 01:04:19 +0100 (CET) Date: Fri, 17 Dec 2021 01:04:19 +0100 (CET) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <20211216132151.8216-1-jamrial@gmail.com> Message-ID: <92861361-f316-78a5-3c72-1e279d2a9f8c@passwd.hu> References: <20211216132151.8216-1-jamrial@gmail.com> MIME-Version: 1.0 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-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 Thu, 16 Dec 2021, James Almer wrote: > 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. Can you push the full branch somewhere? > > The proposals so far to extend the API to support either custom > labels for channels are, or some form of extra user information. > > - 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. 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. 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 weight and would like to stick to flat structs. > - Opaque id/s or pointer/s that the API will not touch beyond > passing them around (So unlike the above, the helpers would not > benefit from this). This can be combined with any of the above, > too, and i did as much in this version. > - Leave API as it was in v1. Maybe it is not said enough times, but thanks to everybody who worked on this. It certainly was huge work, and I know that it is a thankless effort to get such a big change merged. Any change based on my suggestions is appreciated, even if some of my ideas get rejected in the end. Thanks, Marton _______________________________________________ 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".