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 6E8834A8E1 for ; Tue, 23 Apr 2024 08:03:10 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2A33968D38C; Tue, 23 Apr 2024 11:03:08 +0300 (EEST) Received: from w4.tutanota.de (w4.tutanota.de [81.3.6.165]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9911C68C95A for ; Tue, 23 Apr 2024 11:02:59 +0300 (EEST) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w4.tutanota.de (Postfix) with ESMTP id E1AF91060159 for ; Tue, 23 Apr 2024 08:02:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1713859378; s=s1; d=lynne.ee; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=nKox0Gw3+aGnXhHSQKuKGhWHt4taznFGUAvzK6fNLKs=; b=fFn6OkoJwx5fkxW8josNidAivY0cb2s0qN/VhKHZtjMh1dZk6L9mT+hIDNVhSg98 VRByqRILGsrgllyypl5wtdLNMF3sCnxYb5eN02D0SA1S2wRemt3E+RVy+0IS8U3pquI hyVpJJEdU1fp+1tKaaNuOjA8z42zWPUETOzOAvR+PIoBk58+VEr1FGOgatX5yO/DTtM YlNQsh12v3/C6fYFNDslvB7xrwGrg/9ac79JAlGbXJK3+HA1PnBXC//g6KlsPd+8HNV VuBturT/1eK8ozRk4x5K9QNtLnDl3XD0gEkMceBHDFiu9f74BE8eJ1wLYdKk+17zT6D uzV3mFjXOQ== Date: Tue, 23 Apr 2024 10:02:58 +0200 (CEST) From: Lynne To: FFmpeg development discussions and patches Message-ID: In-Reply-To: References: <20240417135832.GJ6420@pb2> <20240423002051.GG6420@pb2> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Apr 23, 2024, 09:47 by ffmpeg-devel@pileofstuff.org: > On Tue, Apr 23, 2024 at 02:20:51AM +0200, Michael Niedermayer wrote: > >> On Thu, Apr 18, 2024 at 10:46:35AM +0200, Stefano Sabatini wrote: >> > On date Wednesday 2024-04-17 15:58:32 +0200, Michael Niedermayer wrote: >> > > Hi all >> > > >> > > The pace of inovation in FFmpeg has been slowing down. >> > > Most work is concentarted nowadays on code refactoring, and adding >> > > support for new codecs and formats. >> > > >> > > Should we >> > > * make a list of longer term goals >> > > * vote on them >> > > * and then together work towards implementing them >> > > ? >> > > >> > > (The idea here is to increase the success of larger efforts >> > > than adding codecs and refactoring code) >> > > It would then also not be possible for individuals to object >> > > to a previously agreed goal. >> > > And it would add ideas for which we can try to get funding/grants for >> > > >> > > (larger scale changes need consensus first that we as a whole want >> > > them before we would be able to ask for funding/grants for them) >> > > >> > > Some ideas and why they would help FFmpeg: >> > > >> > [...] >> > > * client side / in browser support >> > > (expand towards webapps, webpages using ffmpeg client side in the browser) >> > > bring in more users and developers, and it will be costly for us >> > > if we let others take this area as its important and significant >> > >> > There are already several projects on github, the most prominent one: >> > https://github.com/ffmpegwasm/ffmpeg.wasm/ >> > >> > In general it would be useful to provide libav* bindings to other >> > languages, for example: >> > https://github.com/PyAV-Org/PyAV >> > https://github.com/zmwangx/rust-ffmpeg >> > >> > Not sure these should be really moved to FFmpeg though. >> >> From a user PoV it would be nice if there was a official >> python, rust and wasm binding >> >> It also would draw in more developers and users to FFmpeg. >> test coverage might also improve >> >> I think the 2 questions are. >> 1. is there a binding for some language that wants to become the official >> FFmpeg binding for that language ? >> 2. does the FFmpeg community want that too ? >> >> thx >> > > I've thought about this a lot while trying to learn FFmpeg. > IMHO there are two big hurdles to good other-language bindings: > > First, FFmpeg's interface is full of C idioms that are unintuitive to > programmers from other languages. For example, Stefano Sabatini is > patiently explaining to me in anoher thread how contexts are a central > concept in FFmpeg's design. Even where I understood the code on a > mechanical level, I had drastically underestimated their importance > because I didn't have a mental model to understand them. Binding > FFmpeg functionality in another language is only half the problem - > the interface needs to be explained in terms they can understand, > or rewritten in terms they already know. > > Second, the interface is full of special cases that make translation > to other languages burdensome. For example, C errors are based on > returning a value and requiring the caller to check it explicitly; > whereas most other languages throw an error and allow the caller to > catch it or not. A translator needs to convert every one of those, > but FFmpeg functions don't have a standard mechanism to signal the > correct behaviour for a given function. Even the documentation isn't > reliably helpful, sometimes saying a variant of "returns an AVERROR", > sometimes "returns a negative number", and sometimes it just > returns an int and expects the reader to dig through the source. > That eats up a huge amount of programmer time, and has to be done for > every language that wants a binding. > > Solving those problems would make it far more practical for translators > to make bindings in other languages, and for new people to learn FFmpeg > even in C. For example, creating an `enum AVERROR` and rewriting > functions to return it would make the code easier to read and drastically > cut translator time. > We always return a negative number for error. _______________________________________________ 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".