From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 39CCE4CF02 for ; Tue, 12 Aug 2025 06:38:45 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id DD0DD68C154; Tue, 12 Aug 2025 09:38:40 +0300 (EEST) Received: from vidala.pars.ee (vidala.pars.ee [116.203.72.101]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id EFA81687BEA for ; Tue, 12 Aug 2025 09:38:33 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; s=202405r; d=lynne.ee; c=relaxed/relaxed; h=From:To:Subject:Date:Message-ID; t=1754980713; bh=efW5fhRls6oaVfKtcwJQv3y nYlLw+BD7tMscJMF09cY=; b=cJrygLdcFOHjhxokE8674jXQGeCadG2aYC60hfslvuh//Plm5b nhfY0oD2KZgpbjcWkvhLE7vOqBqGxk9T9w6YPoC4JtZNAVX3F+1vdY54nEv+IxV/b4ENWnt+Dyg drSGR+Yd0mR7qAdZJdeiB2BUiPyI0JpTBmgY9EBqi03d17Sfu8e3+6cIB3R8tEhG+OEug8lHl/d 41qeubw7ii+f5/b63DGPuFXmRKcnpG1/FwR8om0Hb1S/MA5ge5wWd+qF5ziba1QSexqDZGH8ehR abYo0hp0xGlDBNR71tuYrTc06nVxPMyjSk6T7hY4hCuEXZHOS/EYDrV2/Ms4qQsnH+A==; DKIM-Signature: v=1; a=ed25519-sha256; s=202405e; d=lynne.ee; c=relaxed/relaxed; h=From:To:Subject:Date:Message-ID; t=1754980713; bh=efW5fhRls6oaVfKtcwJQv3y nYlLw+BD7tMscJMF09cY=; b=EAnjjuFBB3iRTtFvzvRpTKZkYdwLeEkcubppIuPZC05vqBnWXe AX1Vke+07wLAfU7q0Mvs5i0CsbhojL4uBhDA==; Message-ID: <00ad392c-084e-4ab9-a314-48412d56c348@lynne.ee> Date: Tue, 12 Aug 2025 15:38:31 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <6e208946-690c-4cbb-9539-bd85df02430c@lynne.ee> <20250811131052.GZ29660@pb2> Content-Language: en-US From: Lynne In-Reply-To: <20250811131052.GZ29660@pb2> Subject: Re: [FFmpeg-devel] Plugins architecture 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 11/08/2025 22:10, Michael Niedermayer wrote: > Hi Lynne > > On Mon, Aug 11, 2025 at 09:22:26PM +0900, Lynne wrote: > [...] >> To me, at least, I can imagine five options: >> >> Option 1 - we have an official binary plugin interface, free for >> everyone to use with no limitation. > > That requires someone to create that "binary plugin interface", > that person seems not existing, so i dont think its an "option" Its a better option in that its a one-time affair, and also there's no endorsement of such plugins by us. Also, we had such an infrastructure in the past with users being able to give their own AVCodec structures to lavc, without us having guarantees that we wouldn't break this. It wouldn't take much to revert that and implement support for this, along with freezing AVCodec longer-term than major bumps. >> Option 2 - we have an official source plugin interface, free for >> everyone to use with no limitations. This means that all >> plugins are source-code based. External plugins would result >> in a build with a different license - if one of the plugins >> used was non-free, then the resulting build would be non >> free. >> Basically, the status quo now, only we would avoid breaking >> interfaces like AVCodec. >> The list of source plugins would not be maintained by us, but >> could be a text file that users could share between. > > >> Option 3 - we have an official source plugin interface, free for >> everyone to use, with license limitations. All source plugins >> The list of source plugins would be maintained by us, and >> policing of the list for violations (including using >> dlopen() to workaround licensing) would be left to us. >> The list of such plugins would be maintained by us. > > Id like to point out that testing for dlopen() is a matter of > "git grep dlopen" after the "git merge" of teh plugins > Similarly we can require any specific license or contract text in a > plugin and can verify that automatically. (similar to fate-source) > Thus turning a non compliant plugin into a contract violation That's a rather eccentric and ineffective solution to a problem that shouldn't exist in the first place. > > Iam not sure we want or need any of that, just saying that if we want > then its a automated thing It would have fallen up to maintainers to check for this, which is one of my main objections to this option. >> Option 4 - we have an official source plugins interface for repositories >> maintained by FFmpeg developers. This means that for >> developers interested in developing features outside of the >> scope of the project, there would exist an interface which >> would allow developers to conveniently maintain and >> distribute their work as an optional extension for the >> project. > > These options do not seem exclusive > we can make a list of GPL/LGPL plugins maintained by ffmpeg developers > > and a seperate list of GPL/LGPL plugins maintained by other developers I included this option for your sake, as you were interested in SDR. This option would allow you to work on and distribute your SDR code. >> As a maintainer, I would like to avoid option 3 to the extent that I am more >> comfortable with fully liberalizing all plugins via option 1. >> >> I would like to hear other options or suggestions that developers may have, >> and ultimately, if there's a consensus on the amount of options that that >> the project would benefit from having a plugins interface, a vote on the >> type of interface(s) we would maintain. > > IIUC your intend is to avoid closed source / non free plugins. > I do think, what you push for here, will open the door primarly for > closed source / non free plugins. > So it seems to do the exact opposite of what you try to achieve. If you feel that way about allowing plugins, I would be happy to have a free-for-all binary plugins interface if the rest of the developer community agrees. There is also some value from such an interface for ourselves, as it would allow us to test the actual guts of libav* libraries rather than having to use a real decoder and testing the decoder at the same time. But personally, I am of the opinion that our project is well-developed enough to not need plugins. Rather than having codecs and filters live in separate repositories, we have room for more. > Because if we dont have a reasonable complete list of plugins in > our repository, it will be outside and will contain all the non free, > corporate and closed source ones I am happy with this as well, as it would not constitute an endorsement from us. _______________________________________________ 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".