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 6D6044ADBA for ; Tue, 23 Jul 2024 00:25:05 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E2F3E68D544; Tue, 23 Jul 2024 03:25:02 +0300 (EEST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 667D668D217 for ; Tue, 23 Jul 2024 03:24:56 +0300 (EEST) X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.11.12] ([95.33.106.134]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M2wGi-1sSkTz0etQ-00HEh0 for ; Tue, 23 Jul 2024 02:24:55 +0200 Message-ID: Date: Tue, 23 Jul 2024 02:24:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <8c6c11a6-bc55-41a0-9f98-262c60f63ec8@gmx.net> <593d1c9b-a040-40e9-93f9-d6966eeb080b@gmx.net> <172130193771.21847.12496308464135252572@lain.khirnov.net> <172163146231.21847.3900874929001201865@lain.khirnov.net> Content-Language: de-DE In-Reply-To: <172163146231.21847.3900874929001201865@lain.khirnov.net> X-Provags-ID: V03:K1:ad0YDYt2Pu6+YMRlHVbqmUVYtCo/GMzQkDkWjnrQNMDjwxMTiSy NPgDoy+8g2O0sfQDDVHnIJy8vnZQ2HnELp0y9wJX3CYU0FyLtXkG7BT7z7vN4ruA7kR5bkB jrjZ36WtQjjdSI2FnoUYYp5uMfFUlbtJsIrya0I5esW8SuT3J2RzWlEZqBf8s3mqXlogCSs Cz6RfzHzKtIZNe+bLEd3g== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:ES32noZuB4g=;8fbZkTQ/4TfjyPN7akxKM96jSPo nKY23aCUMSPlXW/igUqklT2Ui+i21GsoAzXeffKZ2s8GfEmV21ua7obRkEmwwfyFKVxxxsZje QyAT0bko4wKavuYH2jxkl3fVQNPMoIpvsEdE90Osd1+PhLyqLLwWNJQChWGWUR8PPkwd17cBH VA7xQmEmBVTqonz7om9L+oALuSHJr8DurDj/lWgDFpJjYB8UO86VCG8vxW11ohPiNIRGJVWj1 5CbWXuLdR2XEuIXGtKy5KEoFooQHfT9mEPW4piLlKAOPDN3MSGMVWtfyMcRwdJoG9uDvPZU9O yJzzsi4Dq0Swj0W8n+qywdqQvVs8Z76JucWXRJRrPyShHmLu2iZ52cu6tLxZgdzG8fZnPiBM9 pXBcwCuYeK8CKLNSCd9KMC6tZRnNzjP4p54sEi+MHSttXH7kYao3U71c3L6hl6Gsc3i92G6LO ouh6tuKk9vLxaSWZYWz2yrf6goWbcRseywOAmyitYJtT8xTy1zySURZEjTzaYVDdxjmzB5fMY Y5g564VVNt6P3pxLmCtuT4Ruki/D6/BC1ocRgiPOvierRFdQHiGCstd4Q4VsuO/cYcVDXWKTl C4TI/lgHL7sC6Sj5Ne7JZ8Pd58yDVVYwP1NKWk72wnraXmOKxLtba/yEFzlPRaqKec+TB5WGC CF+arVkzgViESCVLldGOaFNT7vP7+4V+zNhXL2qGX5s0SCC+VHNL4j0SgUKy+ulBsE2PIYElf RIxuOr2f6Pz79KFziS2za6oFdxBthXm0mv3orRPzT1JWZsjjxbBlJDnFy8bsxsoJQbPEABTQy JAARFbx5tvvs2QxPQRX8JZAg== Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/vapoursynth: Update to API version 4, load library at runtime 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: , From: Stefan Oltmanns via ffmpeg-devel Reply-To: FFmpeg development discussions and patches Cc: Stefan Oltmanns 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: Am 22.07.24 um 08:57 schrieb Anton Khirnov: > Quoting Stefan Oltmanns (2024-07-18 14:12:42) >> Hello Anton, >> >> can you eloborate on that? What is unacceptable with my patch that is >> perfectly fine in the AviSynth input module? It's the very same concept. > > It's not perfectly fine in avisynth, I dislike it there as well. There > are also recent patches that remove the atexit handler. The atexit will be removed in the next revision of the patch. > >> Loading the library at runtime makes it so much more useful, because you >> can distribute ffmpeg binaries without forcing the user to install >> VapourSynth (which requires the user to install Python). > > Runtime loading hides dependencies from standard tools and makes program > behaviour harder to analyze. Not to mention you're adding a bunch of > global state, which is evil. All global states will be removed in the next revision of the patch. It's the intention of my patch to reduce ("hide") the VapourSynth dependency, so unless you want to actually open a VapourSynth script there is no dependency to it. If you try to open a VapourScript script without having VapourSynth installed, you'll get an error message. VapourSynth itself has unclear dependencies, it will load plug-ins on runtime and as it uses Python you can in fact load other Python libaries, for example AI stuff like PyTorch for fancy upscaling, that will then load CUDA/ROCM. > >> VapourSynth is not just a library like x264 that you can link in >> statically if you like, VapourSynth is a frame server (like AviSynth) >> with it's own dependencies. >> If you worry about platforms that do not support loading libraries at >> runtime: VapourSynth is based on plugins that are loaded on runtime, so >> it won't work on those platforms anyway. > > I am worried about special "demuxers" than are not really demuxers and > don't work like other demuxers, hence massively increasing library > maintenance load. > I somewhat agree here, when I first saw a AviSynth demuxer in the list of supported formats it looked weird, because it's not a format that you demux. But what's the solution? Create a new library like "avframeserver" for 2 (?) different tools? How do they increase the maintinace load? There are a lot of external libraries that get used by ffmpeg, what's the difference here? As these formats do not contain any advanced video codec, but raw video, shouldn't it be rather easy to maintain, because no weird complications with some decoder? Best regards Stefan _______________________________________________ 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".