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 E696A4A8CB for ; Thu, 18 Apr 2024 21:13:54 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C7F9068D2C4; Fri, 19 Apr 2024 00:13:51 +0300 (EEST) Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 012C168D02E for ; Fri, 19 Apr 2024 00:13:44 +0300 (EEST) Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1e51398cc4eso12094505ad.2 for ; Thu, 18 Apr 2024 14:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713474822; x=1714079622; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=NQShemR+JRTMoJmU0rI3ycIvDT4dTZFZtgEzWxF6I/c=; b=K8ZHmXKxXU/dNeoVMEJ4DBrSkMwEtaCdiPtMFscH2jNLBWs5dkchEBDyQyVEjgx+lv qOrmGz/97gW3rqEI3qipBIqESpkYoW8AXvdgNMn3ZJFM5iWMIHBakgeL4HZPdnzUn2oT MpS5IjAJjGXS9WSQnX+t4TGllUCpAeFoxSXc99WPqEc6FYXZkRMKR5Rq3QJnykDuMSGD 6hWLlOyfylf/5PjL67GaybdL8BwktElDlzRbZyVQxhhJ+utGo/4Gp5zSY3MFKV3+eVRD Xj7fn6u85p3SbFox4owcj/TknTBgE159vUy5ucGTB+xAbpFdgOT2miLCFs3U5j0kKrOx m3yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713474822; x=1714079622; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NQShemR+JRTMoJmU0rI3ycIvDT4dTZFZtgEzWxF6I/c=; b=IFp9DsTsTAHPqVyqEipkSwta8/Z5VCiGqXNsASvtlJHp8iSA9FGk/9rxhpvSnmm4lC 4vPUhFOAymDqRRK7xgHow1g7eSZDRv8hZ+jZzUz6IOxx/ZUe41VboIEG00V/EMgES8Gf W52MaW9bkf5i0xifHLn01jYplVs7mGgcz3b8snVEeBOp4FyXl4fkav+K+XEuqIQe1me4 JqElH8g+nA+ulVdiNdJJJ4GsZcVOiFu2H5Wa1tfPhlHW6tvcQKyy0MCKLI/bI4ip5B8x 8lXauZnVXAhrtCgmtz5Cfmo9pYlKOm09RCWG1Lj+jOrYehaXlI5k/gdnY1RnCt144nc1 d/PA== X-Gm-Message-State: AOJu0YwZvJTTj5msaTdd6Z8rN7WvrOw8N/zQbzuEsgaceFIMfV+4cB0A fpT+gpV8QIgL0T7tF7T8NcyQbqn51MAtl3C3qMW7pI8aeOne2++8E4t0IA== X-Google-Smtp-Source: AGHT+IEV6UNmj5X24Qbvn4ED77bPc/DdmqK3j5dCqvpD9BqUa3SxCzketVloUC1PSceuQhPjj4iXPg== X-Received: by 2002:a17:902:dac8:b0:1e4:19e3:56cb with SMTP id q8-20020a170902dac800b001e419e356cbmr477050plx.12.1713474821766; Thu, 18 Apr 2024 14:13:41 -0700 (PDT) Received: from [192.168.0.10] ([190.194.167.233]) by smtp.gmail.com with ESMTPSA id y15-20020a170902d64f00b001e510b3e807sm1967610plh.263.2024.04.18.14.13.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Apr 2024 14:13:41 -0700 (PDT) Message-ID: <5f454591-fe4c-4fc1-98b0-d3d21b207b12@gmail.com> Date: Thu, 18 Apr 2024 18:13:40 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20240417135832.GJ6420@pb2> <20240418160207.GB45500@haasn.xyz> <20240418205351.GS6420@pb2> Content-Language: en-US From: James Almer In-Reply-To: <20240418205351.GS6420@pb2> 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-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 4/18/2024 5:53 PM, Michael Niedermayer wrote: > On Thu, Apr 18, 2024 at 04:02:07PM +0200, Niklas Haas wrote: >> On Wed, 17 Apr 2024 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: >>> >>> * Switch to a plugin architecture >>> (Increase the number of developers willing to contribute and reduce >>> friction as the team and community grows) >> >> This would almost surely hurt productivity > > i dont agree, ill elaborae below > > >> as it will require exposing, >> versioning, documenting and maintaining a vast number of internal APIs > > yes to some extend that is needed. It can be more or less depending > on how things are implemented > > >> which we are currently at the liberty of modifying freely. > > we are modifying these APIs for decades. That modification of APIs > their documentation and all code using them costs time. The AVCodec hooks being internal allowed us to add autoinserted bsfs and to painlessly rewrite the decouple I/O callbacks to work as a pure pull based interface. Were said internals public, that wouldn't have been possible. > > More so we have issues with patch-management. And i claim this is > not the mailing list but a lack of time and in some cases a lack of > interrest in many areas. > > A plugin system moves this patch-management to people who actually > care, that is the authors of the codecs and (de)muxers. > > Our productivity as is, is not good, many patches are ignored. A lot of patches fall through the cracks rather than being ignored. There are people that send patchsets unthreaded (Because of misconfigured git send-email i suppose), and it makes browsing your mailbox hard. > The people caring about these patches are their Authors and yet they > are powerless as they must sometimes wait many months for reviews > Besides that, developers are leaving for various reasons and they > are forced to setup full forks not being able to maintain their > code in any other way. > IMO A plugin system would improve productivity as everyone could work > on their own terms. You say the ML is not the problem, but it sort of is. An MR based development would greatly improve this problem. > No week or month long delays and weekly pinging patches > No risk about patches being rejected or ignored > No need to read every other discussion on the ML. One can just > simply work on their own plugin looking just at the API documentation I don't personally have a strong opinion one way or another on this subject at this moment, but any such approach would need to be carefully thought and designed, to prevent all the potential problems people have expressed so far. > ... > > > >> >>> * ffchat >>> (expand into realtime chat / zoom) this would >>> bring in more users and developers, and we basically have almost >>> all parts for it already but some people where against it >> >> This seems like a user application on top of FFmpeg, not something that >> should be part of FFmpeg core. Can you explain what modifications in >> FFmpeg would be necessary for something like this? > > ffmpeg, ffplay, ffprobe are also user applications. > > >> >>> * 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 >> >> I don't understand this point - don't all major browsers already vendor >> FFmpeg for decoding? > > FFmpeg does more than decoding. > > >> >>> * AI / neural network filters and codecs >>> The future seems to be AI based. Future Filters and Codecs will use >>> neural networks. FFmpeg can be at the forefront, developing these >> >> We already have TensorFlow support, no? (vf_sr etc.) What more is >> needed? > > more of that AND more convenience > > lets pick a comparission > to run fate > you write "make fate" > if you want to do it with the samples its > make fate-rsync ; make fate > > if you want to use vf_sr, its reading the docs, looking at some scripts reading their docs > and i presume selecting a training set ? creating a model ? .... By no means we could ever ship a custom AI model for the sake of a "git fetch, compile, and run" scenario. This was already a problem when tensorflow was first committed. So this can't be avoided. > > how many people do that ? Every external dependency has its documented requirements... > > thx > > [...] > > > _______________________________________________ > 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". _______________________________________________ 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".