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 698574CE7C for ; Mon, 11 Aug 2025 12:22:40 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 76DEE68BA45; Mon, 11 Aug 2025 15:22:36 +0300 (EEST) Received: from vidala.pars.ee (vidala.pars.ee [116.203.72.101]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 9F635687D2C for ; Mon, 11 Aug 2025 15:22:29 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; s=202405r; d=lynne.ee; c=relaxed/relaxed; h=Subject:From:To:Date:Message-ID; t=1754914949; bh=cKBHCGn9XNKwTLor1qWA+ET cvjGndv1slTuQXw/jDBM=; b=dTMHrw9b3ytU0REAotnvPxnlWAvlpqCAEQOvqdNxFAdvaUV9/+ v1E1hiUznuho0T0Y55zcw6kwjSrX2o883t/Jc1DMgcOz10jm+aMQoX0Tt+1tpyHcu3wEXzLOWHz 0mcV8sB1ijODA6Cso+vz2xuWajXmKlNlIFdSmpbxpIwbYl3/x79lcqPNJmiXC0cgncMtS8dEgXz jhTlobRAmiDUbhj/rbqNmbc6Pqj4dDVmpBOQh5pCNvBzjcqAC72ZNAdhxAGdfNrH36VO09Oi7WZ d4kAkhkL+S/AEsk/QfwRTL/wed/RRZt0Scg3BK+a5nU353o6JrBUPlVG62lpgJnsBZA==; DKIM-Signature: v=1; a=ed25519-sha256; s=202405e; d=lynne.ee; c=relaxed/relaxed; h=Subject:From:To:Date:Message-ID; t=1754914949; bh=cKBHCGn9XNKwTLor1qWA+ET cvjGndv1slTuQXw/jDBM=; b=15vMyQKK/OpskGkUipYvug9/Y3NokziudcoKw13kljljlOVw+P j9edPLbxiGsW0WN2bvNAni2JoLS2ozHc9DCg==; Message-ID: <6e208946-690c-4cbb-9539-bd85df02430c@lynne.ee> Date: Mon, 11 Aug 2025 21:22:26 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: ffmpeg-devel@ffmpeg.org From: Lynne Subject: [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: Recently, the issue of plugins was raised. Michael pushed a patch to enable out of tree branches to be freely added to FFmpeg. I did not very much like the option of having officially-endorsed source plugins, as to me, it moved all the burden of maintenance to FFmpeg maintainers. The commit was reverted, with the tentative agreement to open a discussion on the nature of plugins we would like to have. 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. 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. 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. Option 5 - we have an official source plugins interface for repositories affiliated with the FFmpeg project. This means that rather than just using it for libpostproc, we could use the plugins interface to split up the project into individual repositories for each library. 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. _______________________________________________ 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".