[FFmpeg-devel] [PATCH] avcodec/av1dec: Fix resolving zero divisor
Fixes: Out of array read Fixes: global-buffer-overflow-AV1 Found-by: "Leonelli, Matteo" Tested-by: "Wang, Fei W" Reviewed-by: "Wang, Fei W" Signed-off-by: Michael Niedermayer --- libavcodec/av1dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c index 6114cb78e65..4dcde234c6c 100644 --- a/libavcodec/av1dec.c +++ b/libavcodec/av1dec.c @@ -177,7 +177,7 @@ static uint8_t get_shear_params_valid(AV1DecContext *s, int idx) int16_t alpha, beta, gamma, delta, divf, divs; int64_t v, w; int32_t *param = &s->cur_frame.gm_params[idx][0]; -if (param[2] < 0) +if (param[2] <= 0) return 0; alpha = av_clip_int16(param[2] - (1 << AV1_WARPEDMODEL_PREC_BITS)); -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
On Tue, Mar 05, 2024 at 11:27:22AM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-03-05 03:50:01) > > The STF opertunity had a deadline. > > Also we can already start discussing what shall be done when the next grant > > opertunity comes. > > How about some actual transparency Theres a wiki: https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 that contains an application only 2 people filled out the application also Pierre collected the SoWs, only 2 people submitted any SoWs I do remember asking you to submit something and IIRC you said that you are waiting for the vote outcome. But you never submitted anything I also tried to contact everyone else, who at the time had something incomplete on the wiki and their name. This (and other people also not submitting any SoWs) caused us to fall below teh 150k€ minimum so i tried to fill the missing space with added work so we reach the minimum. at night on the 12th/morning 13th february i was CC-ed on the application submission to STF " a draft corresponding to the community-driven proposals found in [wiki]." Tara from STF then reworked this and asked us various additional information: (estimated effort (people hours) per milestone, and the fully loaded hourly rate (the price rate, so the cost divided by total number of hours).) "If you want to invoice after each sub milestone, then you need to break down the total cost per milestone into each sub milestone (and by extension also the estimated effort)." Others, I and niklas then helped fill the missing things in quickly before the deadline Someone along the line added more incomplete proposals to the wiki after the deadline But same as with others, no SoWs where submitted, and none of the details needed in the application where filled out. > instead of backroom deals, for a > change. iam sorry, but these accusations are not acceptable The application was and is on a public wiki the SoWs where collected by pierre and it was publically announced before. I tried to contact all people before the deadline who had incomplete submissions. I think for a change you should say thanks to tara, pierre, SPI, STF and others doing all the work. Instead of accusations. And you should submit a proposal with SoW and all needed information next time. Similarly others should too. The idea of this was never to have just 2 people submit SoWs > > The application has apparently been submitted, with no public > announcement that it even happened, much less what was in it. whats in it, should simlpy be what was on the wiki application plus the fixes and cleanups mentioned above thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/ffmpeg_mux_init: default to input timebase for streamcopy
On Tue, Jul 09, 2024 at 09:19:54AM +, Anton Khirnov wrote: > ffmpeg | branch: master | Anton Khirnov | Fri Jul 5 > 12:30:04 2024 +0200| [10185e2d4c1e9839bc58a1d6a63c861677b13fd0] | committer: > Anton Khirnov > > fftools/ffmpeg_mux_init: default to input timebase for streamcopy > > Stop trying to invent some "framerate-based" timebase when there is no > reason to think the stream is CFR at all. > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=10185e2d4c1e9839bc58a1d6a63c861677b13fd0 > --- This breaks: ./ffmpeg -f concat -i ~/tickets/3108/concatfile.txt -codec copy -bitexact /tmp/file3108-before-10185e2d4c1e9839bc58a1d6a63c861677b13fd0.avi (i assume the zip on the tracker contains all source files, if not i can provide the source files) -rw-r- 1 michael michael 3088008 Sep 13 18:01 /tmp/file3108-after-10185e2d4c1e9839bc58a1d6a63c861677b13fd0.avi -rw-r- 1 michael michael 2824008 Sep 13 18:01 /tmp/file3108-before-10185e2d4c1e9839bc58a1d6a63c861677b13fd0.avi the framerate is 600 fps after this: Input #0, avi, from '/tmp/file3108-after-10185e2d4c1e9839bc58a1d6a63c861677b13fd0.avi': Duration: 00:00:20.13, start: 0.00, bitrate: 1227 kb/s Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 480x270 [SAR 1:1 DAR 16:9], 978 kb/s, 600 fps, 25 tbr, 600 tbn Stream #0:1: Audio: aac (LC) ([255][0][0][0] / 0x00FF), 44100 Hz, stereo, fltp, 131 kb/s michael@zb:~/ffmpeg-git/ffmpeg$ ./ffprobe /tmp/file3108-before-10185e2d4c1e9839bc58a1d6a63c861677b13fd0.avi Input #0, avi, from '/tmp/file3108-before-10185e2d4c1e9839bc58a1d6a63c861677b13fd0.avi': Duration: 00:00:20.13, start: 0.00, bitrate: 1122 kb/s Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 480x270 [SAR 1:1 DAR 16:9], 978 kb/s, 50 fps, 25 tbr, 50 tbn [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2
Hi aybe On Sat, Jan 13, 2024 at 02:28:52AM +, aybe aybe wrote: > Here are the two STR files I have used when writing this patch: > https://github.com/aybe/FFmpeg-PSX-STR-tests ok, i can confirm the version patch fixes these, i will apply it > Fanatics would probably say that 30 FPS for NTSC is wrong (i.e. should be > 29.97)... > However, as the reversed-engineered docs in jpsxdec mentions, it is sort of > impossible to figure out which value to snap to from how frames spans across > CD-ROM sectors. > The sector count per video frame always seem to juggle between two values, > e.g. 6 sectors, then 7 sectors, rinse/repeat. i.e. it's never constant. > > Also, as one can see in the various code samples online on writing a PSX > program that plays MDEC videos, it is the responsibility of the coder to > present the frames on screen. > i.e. there is not definitive way on how to do so, and even if there was, you > can be sure some folks did not play by the rules back then. > The only way to figure out how a movie was intended to be played is to > reverse engineer a game to see what values they did cram in. > In short, the computed frame rate is 99% good, not 100%. But for mere > mortals, they are unlikely to notice it at all. Well, with the subset of samples i have, i dont feel confident that i could write and test timestamping/fps. The docuemnt you linked says "Data is read from the disc one sector at a time at either 75 sectors per second (single speed) or 150 sectors per second (double speed). The video and audio are spaced out over these sectors so they can be delivered at the appropriate times." what i would suggest to try is: avpriv_set_pts_info(st, 64, 1, 150); (or 75 for single speed) and then set AVPacket->pts to the sector number you never set fps, leave it to libavformat to figure it out. can you try that ? (i assume you have many samples to easily check) > > As for the movies in the samples repository, they are corrupt and FFmpeg > fails at them, obviously. > I figured these ones were by checking them in a hex-editor but also by > loading them in https://github.com/m35/jpsxdec which has great > logging. > Not sure why these samples were corrupt in first instance, maybe it was > intentional for testing? I can't tell. Thats very strange, anyone remembers where these samples are from originally ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes
Hi Should we use a Merge or Cherry picks for integrating Pauls work ? Following are 2 plans, as we execute either we may run into issues and of course adapt them as needed. (or even switch) Option M: This would be a merge of pauls last revission before files where switched to GPL and the command line tool to AGPL It would include all changes (except what is intentionally skiped) (This will look similar to how almpeg looks now) Fate tests would be added after the merge where sample media is publically available on our server. Reviews of Individual modules can be done after the merge where people want to do that. Option C: Individual Modules (Codecs, Filters, Demuxers) would be submitted as patch(sets) This would include only the picked changes. Changes noone picks and posts would be missing. Each would go through the review process (some likely with "apply after timeout"). And during that review fate tests would be added where public samples are on our server. M would likely integrate more changes, C less changes. C may be more work. We currently have a point on the wiki for STF 2025 that would fund each integrated module with 900€. That way, whoever adds fate tests, makes changes the community wants in a review, fixes bugs found by tests or review, could be funded. It is possible that teh community adjusts the exact STF task / work / ... before its deadline. I think many people have already thought about the merge vs cherry pick question. (it came up previously on the ML and in the GA) So maybe we can just vote on it now over the next 8 days. Or if people want more discussion first, we can do that too. We will see based on peoples replies. Maybe use the first day to think and sleep over it or a quick discussion and then vote in the next 7 days. If you want to vote, please simply reply with "M" or "C" (and of course any details, why you think thats the better option, if you want to add details) Otherwise reply with "D" for "more Discussion" and details about what you want to say/discuss. thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Some Animals are More Equal Than Others. - George Orwell's book Animal Farm signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] CI
Hi On Thu, Aug 21, 2025 at 06:03:12PM +0200, Kacper Michajlow via ffmpeg-devel wrote: [...] > Also on the topic of CI, I suspect we might add more jobs as needed. > Probably depends on priorities, to not overload existing runners > capacity. > > I was wondering about integrating CIFuzz. Which basically runs fuzzers > based on coverage data that are affected by the PR changes. And runs > fuzzing for N minutes. This would allow it to catch trivial issues, > quickly and without the need for turnaround until the issue is > reported in the oss-fuzz infra. It uses existing corpus to seed the > fuzzing, so it should be good at catching things that are not "hidden" > too deep. Though this brings challenges, because it likely would need > a separate pool of workers to not starve and build jobs. And not sure > how well it would work in practice. For example if change touches too > many fuzzers, it wouldn't manage to run them in the time limit of say > 20-30 minutes, which is probably the reasonable target. Though all > ffmpeg fuzers are specialized for codes, so codec specific code should > be fine to test. This is burning CI minutes, but if we have some to > spare, say from GH workers, it could help to weed out issues quickly. > Thoughts? immedeate fuzzing for pr, approved thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] CI
Hi On Thu, Aug 21, 2025 at 12:31:46AM +0200, Timo Rothenpieler via ffmpeg-devel wrote: > On 8/20/2025 9:25 PM, Michael Niedermayer via ffmpeg-devel wrote: > > Hi > > > > On Wed, Aug 20, 2025 at 05:56:27PM +0200, Timo Rothenpieler via > > ffmpeg-devel wrote: > > > On 8/20/2025 1:26 AM, Michael Niedermayer via ffmpeg-devel wrote: > > > > Hi > > > > > > > > It seems the forgejo CI takes about > > > > 13min to do fate on aarch64 and x86-64 and build on win64 > > > > > > > > Locally i run > > > > fate + install on x86-64 > > > > build on x86-32, mingw64, arm32, mips, ppc, x86-64 + shared libs > > > > testprogs alltools examples build on x86-64, x86-32 and arm32 > > > > in 2min 44sec > > > > > > > > can we improve the speed vs amount of tests ratio ? > > > > (its not a problem ATM, i did in fact not even notice as i never waited > > > > on it) > > > > > > > > Iam just seeing the difference in time and i think there is potential > > > > for > > > > optimization here > > > > > > > > I dont think my box here is really special, just a > > > > AMD Ryzen 9 3950X 16-Core + Samsung SSD 970 PRO > > > > > > Well, the test runners are 4 cores and 8GB of RAM. So that'll be the > > > primary > > > difference in speed. > > > I think they're performing pretty good for being just that. > > > > > > We could of course throw money at the problem and turn them into 16 core > > > machines. That would up the hosting cost of the runners from currently > > > 3*7.5€ a month to 3*30€ a month. Just for the runners. > > > > > > imo the current CI turnaround times are fine. 15-20 minutes per job is > > > fine, > > > as long as they can all run in parallel. > > > > Option 1: 15-20 min CI turnaround, 270 € per year > > Option 2: 4-5? min CI turnaround, 1080 € per year > > > > we have over 150k $ it seems > > > > Good use of capital can also lead to more donations > > > > I think the main question is, "would we benefit from the faster trunaround"? > > or not ? > > You have to keep in mind, 4 Core 8GB is also the swarm of runners we get for > free from Microsoft via GitHub. > > So the choice is actually "Be able to process 20+ jobs in parallel that take > 15-20 minutes each" vs. "Be able to process 3 or so at a time (roughly one > PR/push) in 5 minutes". > So realistically, unless we also pay for an actual swarm of runners > ourselves(which would cost 10k or more a year while being idle 95% of the > time) the total turnaround time including wait for a free runner is probably > still better with more of the smaller runners than less of the big ones. > > It'd also make it a lot more pressing to think about every single CI job we > add, vs. having a bit of leeway due to the over-abundance of runners. for 1-2k$ you can buy a box that runs fate once and build on 6 times in under 3minutes. if one is not enough buy 3, use the extra capcity for fuzzing or rent out to other projects I must be stupid, because to me this looks cheaper, its also one time expense these boxes can be used for 10 years also no need to be reliable expensive servers, if you have 3. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes
Hi Kieran On Thu, Aug 21, 2025 at 06:56:14AM -1000, Kieran Kunhya via ffmpeg-devel wrote: [...] > For the record, Paul had a note saying changes are under GPL. As I > understand you are ignoring legal advice saying this is a valid statement. > > Can you confirm the legal advice you were given and that you are ignoring > it? We have hired one of the leading copyright / IP law firms / lawyers And the shortest summary is that code with LGPL headers can be used under LGPL. The oppinion of the lawyer (which is much longer and more detailed) was provided to the General Assembly of FFmpeg. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] vf_colorspace: Add an option to clamp trc LUT output
On Tue, Aug 19, 2025 at 02:17:05PM +, Drew Dunne via ffmpeg-devel wrote:
[...]
> @@ -1000,6 +1005,11 @@ static const AVOption colorspace_options[] = {
> ENUM("vonkries", WP_ADAPT_VON_KRIES, "wpadapt"),
> ENUM("identity", WP_ADAPT_IDENTITY, "wpadapt"),
>
> +{ "clamptrc",
Trailing whitespace (i think there where more than this)
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF 2025 grant request (2025-09-01 target)
Hi Pierre On Wed, Aug 20, 2025 at 09:28:26AM -0700, Pierre-Anthony Lemieux via ffmpeg-devel wrote: > On Wed, Aug 20, 2025 at 9:24 AM Niklas Haas via ffmpeg-devel > wrote: > > > > On Tue, 12 Aug 2025 08:32:39 -0700 Pierre-Anthony Lemieux > > wrote: > > > Quick reminder that the deadline for submitting your proposal is > > > quickly approaching. > > > > > > Also note that the total amount of the proposed projects is below for > > > the minimum threshold for STF to consider the application. > > > > Despite my initial reservations, I decided to also apply with another > > continuation of the libswscale project. Just letting you know as a heads up > > that I will add my proposal to the wiki shortly. > > > > How much more is currently needed to meet the minimum threshold? > > @Michael Niedermayer How many of the 100 modules do you realistically > expect to complete? I think the main uncertainilities are 1. If teh community preferrs merges or cherry picks, If they want cherry picks its 100 patch(sets) passing review, adding tests where samples are on our server. If we do it as a merge, the work is still there but its different likely less work. Code would be merged in one go, then people could still review the individual modules afterwards, and I still would have the same effort to do to add tests and handle reviews. But maybe fewer people will post reviews with a merge than with cherry picks 2. when the work starts, because i intend to submit some patchset to test the whole process as soon as i am not busy with other work in ffmpeg So we might end up with fewer than 100 if we do some before STF starts 3. In all this I assume that the review process is fairly smooth and requests for major changes would be very rare because that would not work with the number of modules. And i assume that either we have testsamples or we dont and so the work adding tests is manageable. But the devil is in the details and tests can lead to detected bugs if the results are different between archs and so on. And then I would have to debug and fix that unknown number of bugs So really if everything is smooth i expect all 100 but if issues arise it can be less. I will know how badly i miscalcuated this only afterwards ;) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [Proposal] drawvg filter
Hi Ayose On Mon, Aug 18, 2025 at 07:22:56AM +0100, Ayose via ffmpeg-devel wrote: > This is a proposal to add a new filter to FFmpeg: drawvg, to draw > vector graphics on top of a video, using libcairo. > > This is my first contribution to FFmpeg, so I don't know if this is > the right channel to make the proposal. > > I was thinking on how to write it, and I thought that a FAQ-like > summary may be the easiest way to describe it. Apologies if this is > more confusing than helpful. > > > == What is drawvg == > > drawvg is a filter to render vector graphics on top of video frames. > > The render is done by executing a script written in its own language, > called VGS (Vector Graphics Script). The script consists of a series > of commands to describe 2D graphics, which are rasterized using the > libcairo library. > > VGS is not intended to be used as a general-purpose language. Since > its scope is limited, it prioritizes being concise and easy to use. > The syntax is heavily inspired by languages like [1]Magick Vector > Graphics, or [2]SVG's . > > [1] https://imagemagick.org/script/magick-vector-graphics.php > [2] > https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/path > > Some features of the syntax (like using whitespaces to separate > arguments) are also present in languages like TCL or shell scripts. > Many command names are taken from PostScript. > > Scripts can use FFmpeg expressions to describe graphics dynamically, > so they can compute coordinates based on frame dimensions, frame > metadata, generate random values, read pixel colors, etc. > > For example, to draw a blue circle in the middle of a frame: > > circle (w / 2) (h / 2) 100 > setcolor blue > fill > > Then: > > $ ffplay -i example.webm -vf 'drawvg=file=blue-circle.vgs' > > There is a [3]website with some examples on how to integrate drawvg > with other FFmpeg filters, and also a [4]playground to experiment with > the capabilities of the language. > > [3] https://ayosec.github.io/ffmpeg-drawvg/ > [4] https://ayosec.github.io/ffmpeg-drawvg/playground/ i like the filter, i think its useful and cool thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 8.0 Release
Hi On Wed, Aug 20, 2025 at 10:18:20AM +0900, Lynne via ffmpeg-devel wrote: > On 20/08/2025 06:13, Michael Niedermayer via ffmpeg-devel wrote: > > Hi all > > > > On Fri, Aug 01, 2025 at 06:16:18PM -0500, Romain Beauxis wrote: > > > Le mer. 23 juil. 2025 à 06:43, Michael Niedermayer > > > a écrit : > > > > > > > > Hi everyone > > > > > > > > I intend to create the release/8.0 branch in the next 1-2 weeks > > > > after that i intend to make teh 8.0 release in the following 1-2 weeks > > > > > > > > If theres something you want in it make sure its pushed before the > > > > branch > > > > is made. > > > > > > I would like to mention > > > https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20026 as well. > > > > I intend to make the release in the nest 24-48h > > so if nothing delays this, then thats as long as theres left to > > make any changes to 8.0 > > I'll write up a blog post as usual. > > It'll be quite long this time, as I'd like to mention in detail the work on > Vulkan accelerated decoding and encoding, so if possible, I'd like to get > the full 48 hours. ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] CI
Hi On Fri, Aug 22, 2025 at 05:22:54PM +0200, Timo Rothenpieler via ffmpeg-devel wrote: > On 22/08/2025 16:54, Michael Niedermayer via ffmpeg-devel wrote: > > Hi Timo > > > > On Fri, Aug 22, 2025 at 02:13:14PM +0200, Timo Rothenpieler via > > ffmpeg-devel wrote: > > [...] > > > But then again, GitHub/MS gives us 20 parallel runners for free, and we > > > can > > > freely pick if they're running on x86_64 or aarch64, Linux, Windows or > > > even > > > OSX. > > > As long as they do that, we only need to host a baseline of runners > > > ourselves, and can scale out into that whenever there's a peak in usage. > > > > if they give us 20, can we test mips & arm with qemu in a way that it > > does not block or delay merges. > > > > I mean so that a pr is considered ok and mergeable before tzhe slow qemu > > fate finishes but after the 2h or so it will display the result in the pr > We could only run those tests on master, not on PRs. > Nobody is impacted by them then, and we still notice breakage reasonably > fast. yes, agree > > For arm I'm not sure if we really need qemu? All it might take is a 32bit > arm chroot on aarch64? Not sure if it works like x86 though, where a 64bit > CPU can also run 32bit code. yeah i thought the same a few moments after sending that mail, though i have never tried i guess riscv would then be the next on the list to have at least a build test thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes
On Sat, Aug 23, 2025 at 10:09:14AM +0300, Rémi Denis-Courmont via ffmpeg-devel wrote: [...] > As a member of the CC and the GA, I agree with Niklaas that any license change > needs a GA vote. And obviously that preempts any discussion of how to merge > the code. There is no license change. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [Proposal] drawvg filter
Hi Ayose On Sat, Aug 23, 2025 at 09:22:47AM +0100, Ayose via ffmpeg-devel wrote: > On 2025-08-20 22:58:26 +0200, Michael Niedermayer wrote: > > > > On Mon, Aug 18, 2025 at 07:22:56AM +0100, Ayose via ffmpeg-devel wrote: > > > This is a proposal to add a new filter to FFmpeg: drawvg, to draw > > > vector graphics on top of a video, using libcairo. > > > > > > [...] > > > > > > i like the filter, i think its useful and cool > > > > Thanks! > > I see that [1]there are many pull-requests in the new code.ffmpeg.org, > but the [2]Submitting Patches section of the web only mentions the > mail-based method. Can I send the patch to the new forge? Or it is still > being tested? of course you can submit patches to the forge thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes
Hi On Thu, Aug 21, 2025 at 01:32:02PM +0200, Michael Niedermayer via ffmpeg-devel wrote: > Hi > > Should we use a Merge or Cherry picks for integrating Pauls work ? > > Following are 2 plans, as we execute either we may run into issues > and of course adapt them as needed. (or even switch) If neither Cherry picking nor Merging is choosen then I will remove my STF proposal about that work before 1. September (unless the deadline is extended). Without that funding, i cannot offer going through individual modules. That means someone else would need to volunteer doing this work to have the "Cherry pick" option in the future. (also consider code divergence with a future funding round) For the "Merge" option, similarly, the loss of STF funding would mean a loss of (funded) "per module" work. "Merge" will stay available from me but without per module work. (someone else would have to do per module work, or no per module work would be done) OTOH with the Integration of pauls code, i will spend more time on FFmpeg in the next 12 months, i would continue doing the fuzzing work as good as i can and i will try to get the 8.1 release done in the next 3 months if people want that. Without the integration of the code, I will likely loose alot of my motivation to contribute. I hope "D" (if its choosen) will stand for Discussion and not Decline or even eventual Death of FFmpeg. thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Legal Advice Was: [POLL][RFC] Merge vs Cherry pick for integration of changes
Hi Kieran On Sun, Aug 24, 2025 at 07:53:45AM +0100, Kieran Kunhya via ffmpeg-devel wrote: > On Sat, 23 Aug 2025, 21:33 Michael Niedermayer via ffmpeg-devel, < > ffmpeg-devel@ffmpeg.org> wrote: > > > Hi > > > > Here is the legal advice that i was given. > > The GA has the full text and that is much more detailed. > > Iam posting the relevant parts so the whole community can see it. > > > > "a claim that there is GPLv2 code in a file of > > FFmpeg origin that has the LGPLv2.1 license would be a breach of the > > FFmpeg's > > LGPLv2.1 license. While section 3 of the LGPLv2.1 would have allowed him > > to > > take the original FFmpeg files and change the license for them to GPLv2, > > he > > didn't follow the necessary steps to effectively change the license. So > > the > > original code he is building from is still under LGPLv2.1. Since code > > contributions to a copyleft work have to be under the /same /license as > > the > > code you are contributing to (Section 2(c), "You must cause the whole of > > the > > work to be licensed at no charge to all third parties under the terms of > > this > > License"), Paul's contributions to LGPLv2.1 files are under the LGPLv2.1 > > license because he didn't exercise the option to change them to GPLv2 > > first. A > > claim otherwise would be admitting he is in breach of the FFmpeg license." > > > > "You can safely assume that any new file he created with a license > > identifier in the file of LGPLv.2.1 is under the LGPLv2.1 license." > > > > "Paul's response to your use of his code may be to relicense his code under > > the AGPL,* but he cannot change the license retroactively - you would > > have to > > accommodate the AGPL license for any later changes you adopt, but not for > > any > > code you are using from before a license change." > > > > thx > > > > [...] > > > > Can you confirm the FFlabs lawyer said something different? I cannot confirm this. I dont remember ever seeing the reply or the question. My communication with the FFlabs lawyer was through a intermediary developer, who was very busy and the mails where also terse IIRC i also had to ask multiple times to get any awnser > And so you went > to another one until you got the answer you wanted? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF 2025 grant request (2025-09-01 target)
Hi Kieran On Sat, Aug 23, 2025 at 11:39:37PM -0700, Kieran Kunhya via ffmpeg-devel wrote: > > > > The author for most of the changes of the new modules is Paul. > > I certainly have alot of respect from Paul, he is a brilliant > > developer and i feel a bit offended by what nonsense Kieran said. > > > > Paul left the project because of your attempt to ram in SDR without > community support. > > This is documented on the ML. You have mobbed one developer after the other out of the project. when the vote against carl didnt succeed you shut down a project server The main person who was against SDR was you. Everyone i remember pointed to you about SDR objections. Then thilo was attacked by derek claiming he stole money. And you simply posted thilos street address in public. You took donations that belong to FFmpeg. (this is physical hardware) Hw donations should be owned by SPI. And of course you objected to SPI too IIRC You helped setup a booth at NAB where a corporate entity impersionated FFmpeg. This is documented with pictures, including the FFmpeg name and logo. end of 2024/2025 there was a slandering compaign against me and as this escalated anton left. Anton was a really important developer. And had you and your friends just stoped, there would have been no escalation and anton would be still here In many threads about decissions you post false, misleading or inflamatory statements and we could continue and continue this thread and also look up all the references ... Please stop, simply stop. Not only, is what you do, not going to work (obviously) because frankly i dont care anymore, say what you want about me. But its very harmfull to FFmpeg and the team. No matter if its your statements directly or the reactions they provocate, these statements are a main cause of people leaving. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes
Hi On Thu, Aug 21, 2025 at 01:32:02PM +0200, Michael Niedermayer via ffmpeg-devel wrote: > Hi > > Should we use a Merge or Cherry picks for integrating Pauls work ? > > Following are 2 plans, as we execute either we may run into issues > and of course adapt them as needed. (or even switch) > > Option M: > This would be a merge of pauls last revission before files where > switched to GPL and the command line tool to AGPL > > It would include all changes (except what is intentionally skiped) > (This will look similar to how almpeg looks now) > > Fate tests would be added after the merge where sample media is > publically available on our server. > Reviews of Individual modules can be done after the merge where > people want to do that. > > Option C: > Individual Modules (Codecs, Filters, Demuxers) would be submitted > as patch(sets) > > This would include only the picked changes. Changes noone picks and > posts would be missing. > > Each would go through the review process (some likely with "apply > after timeout"). And during that review fate tests would be added > where public samples are on our server. > > M would likely integrate more changes, C less changes. C may be more work. "M", (probably) less work than "C" and iam lazy. But 100% happy to change my vote to "C", if thats what the majority preferrs thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The difference between a dictatorship and a democracy is that every 4 years the population together is allowed to provide 1 bit of input to the government. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Legal Advice Was: [POLL][RFC] Merge vs Cherry pick for integration of changes
Hi Kieran On Sun, Aug 24, 2025 at 12:11:20PM +0100, Kieran Kunhya via ffmpeg-devel wrote: > On Sun, 24 Aug 2025, 11:56 Michael Niedermayer via ffmpeg-devel, < > ffmpeg-devel@ffmpeg.org> wrote: > > > Hi Kieran > > > > On Sun, Aug 24, 2025 at 07:53:45AM +0100, Kieran Kunhya via ffmpeg-devel > > wrote: > > > On Sat, 23 Aug 2025, 21:33 Michael Niedermayer via ffmpeg-devel, < > > > ffmpeg-devel@ffmpeg.org> wrote: > > > > > > > Hi > > > > > > > > Here is the legal advice that i was given. > > > > The GA has the full text and that is much more detailed. > > > > Iam posting the relevant parts so the whole community can see it. > > > > > > > > "a claim that there is GPLv2 code in a file of > > > > FFmpeg origin that has the LGPLv2.1 license would be a breach of the > > > > FFmpeg's > > > > LGPLv2.1 license. While section 3 of the LGPLv2.1 would have allowed > > him > > > > to > > > > take the original FFmpeg files and change the license for them to > > GPLv2, > > > > he > > > > didn't follow the necessary steps to effectively change the license. > > So > > > > the > > > > original code he is building from is still under LGPLv2.1. Since code > > > > contributions to a copyleft work have to be under the /same /license > > as > > > > the > > > > code you are contributing to (Section 2(c), "You must cause the whole > > of > > > > the > > > > work to be licensed at no charge to all third parties under the terms > > of > > > > this > > > > License"), Paul's contributions to LGPLv2.1 files are under the > > LGPLv2.1 > > > > license because he didn't exercise the option to change them to GPLv2 > > > > first. A > > > > claim otherwise would be admitting he is in breach of the FFmpeg > > license." > > > > > > > > "You can safely assume that any new file he created with a license > > > > identifier in the file of LGPLv.2.1 is under the LGPLv2.1 license." > > > > > > > > "Paul's response to your use of his code may be to relicense his code > > under > > > > the AGPL,* but he cannot change the license retroactively - you would > > > > have to > > > > accommodate the AGPL license for any later changes you adopt, but not > > for > > > > any > > > > code you are using from before a license change." > > > > > > > > thx > > > > > > > > [...] > > > > > > > > > > Can you confirm the FFlabs lawyer said something different? > > > > I cannot confirm this. I dont remember ever seeing the reply or the > > question. > > > > My communication with the FFlabs lawyer was through a intermediary > > developer, > > who was very busy and the mails where also terse > > > > IIRC i also had to ask multiple times to get any awnser > > > > Translation: The FFlabs lawyer didn't agree with my agenda and so I went > and found one that did. > > It's funny how you are reluctant to post that lawyers opinion [because it > didn't agree with you] when you happily leak private discussions (e.g from > the CC) on this list all the time. > > To use Anton's words "tin-pot dictator" behaviour in action. Date: Sun, 08 Jun 2025 14:40:25 +0200 From: Jean-Baptiste Kempf To: Michael Niedermayer Subject: Re: License question Hello, Lawyer says that, most likely,the COPYING file that comes after (newer) than the headers of the file prevails. So all his changes are GPLv2. :( BEst, On Sat, 7 Jun 2025, at 15:31, Michael Niedermayer wrote: > Hi jb > > any news ? > have you had time to ask the lawyer ? > > Its bad for FFmpeg to lack features that our competitors have. > (and thus also bad for FFlabs) > > librempeg has 36 decoders that FFmpeg does not have, id like to > get these into FFmpeg and even after the lawyer reply it will > still need likely a vote between cherry picking vs merging > > thx > > On Mon, Jun 02, 2025 at 10:34:27PM +0200, Michael Niedermayer wrote: >> Hi jb >> >> On Mon, Jun 02, 2025 at 09:50:53PM +0200, Jean-Baptiste Kempf wrote: >> > Hello, >> > >> > "All Librempeg modifications, and any new files >> > not available in FFmpeg, are licensed under GPL v2, unless stated >> > otherwise." >> > >&g
Re: [FFmpeg-devel] STF 2025 grant request (2025-09-01 target)
Hi Pierre On Wed, Aug 20, 2025 at 06:38:06PM -0700, Pierre-Anthony Lemieux via ffmpeg-devel wrote: [...] > I recommend that the proposed SOWs be more specific, i.e. list those forks. > > [ed.: I would definitely avoid forks from folks that have not shown > interest in working with ffmpeg, or at least list those forks as super > low priority.] The fork will probably be mainly almpeg, iam maintaining it, i want to work with ffmpeg and i want to merge the code from it back into ffmpeg. The author for most of the changes of the new modules is Paul. I certainly have alot of respect from Paul, he is a brilliant developer and i feel a bit offended by what nonsense Kieran said. That said, Paul is certainly a competitor to FFmpeg thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Legal Advice Was: [POLL][RFC] Merge vs Cherry pick for integration of changes
Hi Here is the legal advice that i was given. The GA has the full text and that is much more detailed. Iam posting the relevant parts so the whole community can see it. "a claim that there is GPLv2 code in a file of FFmpeg origin that has the LGPLv2.1 license would be a breach of the FFmpeg's LGPLv2.1 license. While section 3 of the LGPLv2.1 would have allowed him to take the original FFmpeg files and change the license for them to GPLv2, he didn't follow the necessary steps to effectively change the license. So the original code he is building from is still under LGPLv2.1. Since code contributions to a copyleft work have to be under the /same /license as the code you are contributing to (Section 2(c), "You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License"), Paul's contributions to LGPLv2.1 files are under the LGPLv2.1 license because he didn't exercise the option to change them to GPLv2 first. A claim otherwise would be admitting he is in breach of the FFmpeg license." "You can safely assume that any new file he created with a license identifier in the file of LGPLv.2.1 is under the LGPLv2.1 license." "Paul's response to your use of his code may be to relicense his code under the AGPL,* but he cannot change the license retroactively - you would have to accommodate the AGPL license for any later changes you adopt, but not for any code you are using from before a license change." thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] AAC AVERROR_BUG
Hi Lynne, ffmpeg-devel
the following (testcase public, not cattegorized as a security issue)
https://issues.oss-fuzz.com/issues/416134551
hits
if (!ics->num_swb || !ics->swb_offset) {
ret_fail = AVERROR_BUG;
goto fail;
}
Assertion ret != (-(int)(('B') | (('U') << 8) | (('G') << 16) |
((unsigned)('!') << 24))) failed at tools/target_dec_fuzzer.c:556
MemorySanitizer:DEADLYSIGNAL
==399==ERROR: MemorySanitizer: ABRT on unknown address 0x0539018f (pc
0x7d47828ed00b bp 0x7ffc5e5cb040 sp 0x7ffc5e5cac70 T399)
#0 0x7d47828ed00b in raise
/build/glibc-LcI20x/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:51:1
#1 0x7d47828cc858 in abort
/build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:79:7
#2 0x586ab3406fdc in LLVMFuzzerTestOneInput
ffmpeg/tools/target_dec_fuzzer.c:0
#3 0x586ab32f7fe0 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
#4 0x586ab32e3255 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*,
unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
#5 0x586ab32e8cef in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned
char const*, unsigned long))
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
#6 0x586ab3313f92 in main
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#7 0x7d47828ce082 in __libc_start_main
/build/glibc-LcI20x/glibc-2.31/csu/libc-start.c:308:16
#8 0x586ab32db43d in _start
thx
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Any man who breaks a law that conscience tells him is unjust and willingly
accepts the penalty by staying in jail in order to arouse the conscience of
the community on the injustice of the law is at that moment expressing the
very highest respect for law. - Martin Luther King Jr
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Revert "avformat/mpegts: update stream info when PMT ES stream_type changes"
HI Kacper On Wed, Aug 13, 2025 at 02:42:13AM +0200, Kacper Michajlow wrote: > On Sat, 14 Jun 2025 at 22:47, Michael Niedermayer > wrote: > > > > On Fri, Jun 13, 2025 at 04:06:31PM -0600, Pavel Koshevoy wrote: > > > On Fri, Jun 13, 2025 at 2:46 PM Michael Niedermayer > > > > > > wrote: > > > > > > > On Mon, Jun 09, 2025 at 02:25:51PM +0200, Michael Niedermayer wrote: > > > > > This fixes mixing up contexts, use of uninitialized data and crashes. > > > > > More specifically: > > > > > > > > > > ==1001752== Conditional jump or move depends on uninitialised value(s) > > > > > ==1001752==at 0xA9ED82: avpriv_h264_has_num_reorder_frames > > > > (h264dec.c:64) > > > > > ==1001752==by 0x668C7E: has_decode_delay_been_guessed > > > > > (demux.c:757) > > > > > ==1001752==by 0x66AB13: compute_pkt_fields (demux.c:1137) > > > > > ==1001752==by 0x66B2E9: parse_packet (demux.c:1265) > > > > > ==1001752==by 0x66BD84: read_frame_internal (demux.c:1449) > > > > > ==1001752==by 0x67085B: avformat_find_stream_info (demux.c:2692) > > > > > ==1001752==by 0x25157C: ifile_open (ffmpeg_demux.c:1814) > > > > > ==1001752==by 0x272B15: open_files (ffmpeg_opt.c:1366) > > > > > ==1001752==by 0x272D85: ffmpeg_parse_options (ffmpeg_opt.c:1415) > > > > > ==1001752==by 0x2925C9: main (ffmpeg.c:991) > > > > > ==1001752== Uninitialised value was created by a heap allocation > > > > > ==1001752==at 0x483E0F0: memalign (in > > > > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > > > > > ==1001752==by 0x483E212: posix_memalign (in > > > > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > > > > > ==1001752==by 0x14882CE: av_malloc (mem.c:107) > > > > > ==1001752==by 0x1463785: av_buffer_alloc (buffer.c:82) > > > > > ==1001752==by 0x146423F: pool_alloc_buffer (buffer.c:369) > > > > > ==1001752==by 0x14643C4: av_buffer_pool_get (buffer.c:407) > > > > > ==1001752==by 0x752C4B: buffer_pool_get (mpegts.c:1142) > > > > > ==1001752==by 0x7538F2: mpegts_push_data (mpegts.c:1407) > > > > > ==1001752==by 0x758893: handle_packet (mpegts.c:2909) > > > > > ==1001752==by 0x758E90: handle_packets (mpegts.c:3048) > > > > > ==1001752==by 0x759B1D: mpegts_read_packet (mpegts.c:3290) > > > > > ==1001752==by 0x6687A3: ff_read_packet (demux.c:649) > > > > > ==1001752==by 0x66B594: read_frame_internal (demux.c:1346) > > > > > ==1001752==by 0x67085B: avformat_find_stream_info (demux.c:2692) > > > > > ==1001752==by 0x25157C: ifile_open (ffmpeg_demux.c:1814) > > > > > ==1001752==by 0x272B15: open_files (ffmpeg_opt.c:1366) > > > > > ==1001752==by 0x272D85: ffmpeg_parse_options (ffmpeg_opt.c:1415) > > > > > ==1001752==by 0x2925C9: main (ffmpeg.c:991) > > > > > > > > > > Found-by: Alexander A. Shvedov > > > > > CC: Pavel Koshevoy > > > > > This reverts commit 0021484d05f9b0f032fa319399de6e24eea0c04f. > > > > > --- > > > > > libavformat/mpegts.c| 4 +--- > > > > > tests/ref/fate/ts-demux | 4 ++-- > > > > > 2 files changed, 3 insertions(+), 5 deletions(-) > > > > > > > > does anyone object to this ? > > > > > > > > Pavel, are you ok with this being reverted or do you want to submit a > > > > patch that puts this behind some runtime flag ? > > > > > > > > > > yeah, you can revert it ... Once I have the runtime flag implemented I can > > > resubmit it all together. > > > > ok will revert > > Is this still a plan? I was a bit undecided on this, i may have overestimated the problems this would cause. And nothing major broke, and noone else spoke up ... So I kind of conditionally droped this patch until someone else said something or something broke ... > I also see a memory leak after this change. > OSS-Fuzz testcase 5851268507828224. > > Additionally, it looks weird to skip `mpegts_set_stream_info()` on > this pes, but a few lines below still use it in > `av_program_add_stream_index()`. To me it looks like the change is not > fully complete, so I would propose to revert until fixed. feel free to revert it or fix it. But please make sure it gets into release/8.0 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Advanced Error Codes
Hi Nicolas On Tue, Aug 12, 2025 at 04:43:29PM +0200, Nicolas George wrote: > Michael Niedermayer (HE12025-08-03): > > well, you may have deep call stacks > > > > user_app->libavfilter->libavformat->libavcodec->decoder->jpeg_decoder->... > > > > and the user of the user_app needs to know what file had what failure > > so the error details must pass through all this. > > > > Some of the API calls failing here can be final calls that are > > expected to leave nothing allocated on a failure return. > > > > also other subsequent and prior errors may have occured in some contexts > > I thiink we want to be able to distingish what caused teh current error from > > the previous or next > > Before we dig deeper into the technical details, we need to clarify what > exactly you need to do. yes, also to clarify this from my side. This error code work originates from interrest of multiple companies in wanting improvments in the error codes. This interrest is far from clear, and there where intermediaries between me and the companies who want this. So it involves some guesswork but one thing that was mentioned was the error code return from ffmpeg command line tool being not enough, and xerror also being not enough as it always aborts. > > The subject of the thread evokes error messages. Error messages are > meant for users, to give them the information they need to fix their > issue: did they make a typo in the file name? did they forget to enable > wifi? do they need to free some space on their hard drive? is there no > solution because the file is too damaged? This is about error codes, and i do not think anything that goes only to the terminal will help. It is not about a user or developer looking at the ffmpeg output. Because there is no user, these are automated uses of ffmpeg. Iam sure the number of FFmpeg instances they run is way too large for a human to look through the output. I believe they simple want richer error codes that provide more details of why a instance failed like not just "error" and maybe not just "OOM" but maybe OOM in the mov demuxer reading file.mov at file position 5:12 id guess, they could then cluster these into similar issues, and pass each cluster to a developer to investigate and fix without that lets say you have a million failures, what do you do ? you pick a random one and investgate and you cant do anything else until you figured that one out because if you pick 5 you might pick the same bug 5 times. I think what they want is simply more details / vissibility into failures [...] > > What I want to improve is error messages, to make it easier for > applications to separate them from the noise of logs and display them in > nice dialog boxes. We might get a few features helping debug at the same > time, but it is not the main objective, and chasing two hares is a > recipe for catching zero. I think theres some similarity between what you are thinking of and what the goals here are, but unless the companies themselfs speak up here in public and clarify what exactly they want. Its guesswork for me That said of course iam not just interrested in this because some company wants it. But that was what brought the idea up of improved error codes thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] lavc/vp9dec: use cbs_vp9 to parse the frame header
Hi The commit below affects: ~/tickets/5114/test_case.ivf not sure its a "bug" as the file is not really having any content but wanted to repost this as i saw this change commit c0bf1382a757a4dd45b0c5f8ab70578e7126beca (HEAD) Author: Lynne AuthorDate: Thu Mar 27 04:54:54 2025 + Commit: Lynne CommitDate: Fri Aug 8 18:29:39 2025 +0900 lavc/vp9dec: use cbs_vp9 to parse the frame header -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 5.1.7 and 6.1.3
Hi On Wed, Aug 13, 2025 at 01:45:04PM +0200, Michael Niedermayer wrote: > Hi all > > I intend to make 6.1.3 and 5.1.7 today or tomorrow > we have had many security fixes so its high time to make releases of them > > the unfixed USAC bug should not affect it as USAC was added in 7.1 > > So if you want something backported do it quick or ping me on IRC > and tell me to wait both 6.1.3 and 5.1.7 releases have been made [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 8.0 Release
Hi On Fri, Aug 01, 2025 at 03:17:48PM -0700, Jacob Lifshay wrote: > On July 23, 2025 4:43:43 AM PDT, Michael Niedermayer > wrote: > > Hi everyone > > > > I intend to create the release/8.0 branch in the next 1-2 weeks > > after that i intend to make teh 8.0 release in the following 1-2 weeks > > > > If theres something you want in it make sure its pushed before the branch > > is made. > > I'm expecting https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20024 to be merged > soon since all the review comments were resolved on Wednesday. Can you (or > someone else) please merge that before creating the release/8.0 branch? Of > course that's all assuming there aren't any more review issues that need to > be resolved. pr/20024 is in release/8.0 If you want, please send a patch to add yourself to .forgejo/CODEOWNERS and MAINTAINERS thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 8.0 Release
Hi all On Fri, Aug 01, 2025 at 06:16:18PM -0500, Romain Beauxis wrote: > Le mer. 23 juil. 2025 à 06:43, Michael Niedermayer > a écrit : > > > > Hi everyone > > > > I intend to create the release/8.0 branch in the next 1-2 weeks > > after that i intend to make teh 8.0 release in the following 1-2 weeks > > > > If theres something you want in it make sure its pushed before the branch > > is made. > > I would like to mention > https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20026 as well. I intend to make the release in the nest 24-48h so if nothing delays this, then thats as long as theres left to make any changes to 8.0 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] FFmpeg 8.0 Name
Hi all what name should we give 8.0 ? I already asked but it seems only a single reply suggested a name. Just want to make sure everyone heared the call thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 8.0 Release
Hi Andrew On Fri, Jul 25, 2025 at 06:34:53PM +0300, Andrew Randrianasulu wrote: > ср, 23 июл. 2025 г., 14:43 Michael Niedermayer : > > > Hi everyone > > > > Hi. > > I still wish you put some time in making more accurate web changelog, with > detailed (with git commit links) API changes, and new/closed bugs and > regressions since last release (a bit like wine project does this part for > example). You are welcome to write a better changelog and submit a patch the website git is here: https://git.ffmpeg.org/ffmpeg-web You are also welcom to do that for every future release if this is something you want to do. > > -rc tarball is also much hoped for by me, at least. you can just grab git master or git release/X.Y before the release thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] fate runners/clients
Hi We seem not to have basic x86-32 / 64 linux clients covering the releases iam running clients for many obscure archs like sh4 and alpha should i add x86-32 and 64 linux See for example: https://fatebeta.ffmpeg.org/v5.1 theres my ming32 x86-32/64 but no linux that said, the hidden reason for this mail ... do other people maybe want to have their fate clients test the releases too ? (it could help prevent issues/regressions like: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20270) thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes
Hi all On Sun, Aug 24, 2025 at 12:59:29PM +0200, Michael Niedermayer via ffmpeg-devel wrote: [...] > > Option M: > > This would be a merge of pauls last revission before files where > > switched to GPL and the command line tool to AGPL [...] > > Option C: > > Individual Modules (Codecs, Filters, Demuxers) would be submitted > > as patch(sets) > > > > This would include only the picked changes. Changes noone picks and > > posts would be missing. > > > > Each would go through the review process (some likely with "apply > > after timeout"). And during that review fate tests would be added > > where public samples are on our server. > > > > M would likely integrate more changes, C less changes. C may be more work. > > "M", (probably) less work than "C" and iam lazy. But 100% happy to change my > vote to > "C", if thats what the majority preferrs Id like to change my choice from "M" to "C" after hearníng the oppinions of several developers. It seems most people prefer integrating the modules under GPLv3+ and that is easier with cherry picks than a true merge Of course as before iam perfectly happy with "M" thx [..] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] web: Add funding.json
See: https://fundingjson.org/
See: https://floss.fund/
Based on: https://www.python.org/funding.json and the example from
fundingjson.org
It is put in the web repository so its all on the plain ffmpeg.org domain
otherwise extra files are needed
---
htdocs/funding.json | 131
1 file changed, 131 insertions(+)
create mode 100644 htdocs/funding.json
diff --git a/htdocs/funding.json b/htdocs/funding.json
new file mode 100644
index 000..d0b6ee8
--- /dev/null
+++ b/htdocs/funding.json
@@ -0,0 +1,131 @@
+{
+"version": "v1.0.0",
+
+"entity": {
+"type": "group",
+"role": "owner",
+"name": "FFmpeg",
+"email": "ffmpeg-devel@ffmpeg.org",
+"description": "FFmpeg is the leading multimedia framework, able to
decode, encode, transcode, mux, demux, stream, filter and play pretty much
anything that humans and machines have created. It supports the most obscure
ancient formats up to the cutting edge. No matter if they were designed by some
standards committee, the community or a corporation. It is also highly
portable: FFmpeg compiles, runs, and passes our testing infrastructure FATE
across Linux, Mac OS X, Microsoft Windows, the BSDs, Solaris, etc. under a wide
variety of build environments, machine architectures, and configurations.",
+"webpageUrl": {
+"url": "https://ffmpeg.org/";
+}
+},
+
+"projects": [{
+"guid": "ffmpeg",
+"name": "FFmpeg",
+"description": "FFmpeg is the leading multimedia framework, able to
decode, encode, transcode, mux, demux, stream, filter and play pretty much
anything that humans and machines have created. It supports the most obscure
ancient formats up to the cutting edge. No matter if they were designed by some
standards committee, the community or a corporation. It is also highly
portable: FFmpeg compiles, runs, and passes our testing infrastructure FATE
across Linux, Mac OS X, Microsoft Windows, the BSDs, Solaris, etc. under a wide
variety of build environments, machine architectures, and configurations.",
+"webpageUrl": {
+"url": "https://ffmpeg.org/";
+},
+"repositoryUrl": {
+"url": "https://ffmpeg.org/download";
+},
+"licenses": ["spdx:LGPL-2.1-or-later", "spdx:GPL-2.0-or-later"],
+"tags": ["audio", "graphics"]
+}],
+
+"funding": {
+"channels": [{
+"guid": "ffmpeg-spi",
+"type": "other",
+"address": "https://ffmpeg.org/donations.html";,
+"description": "Paypal, CreditCard, Check, Money Order"
+},{
+"guid": "ffmpeg-spi-bank",
+"type": "bank",
+"address": "Please email us for payment details.",
+"description": "Bank transfer"
+},{
+"guid": "ffmpeg-crypto",
+"type": "other",
+"address": "0x2f3900e7064eE63D30d749971265858612AA7139",
+"description": "USDC on etherium/arbitrum/base/optimism/polygon,
small amounts only, until we fully understand tax and accounting of this"
+}
+],
+
+"plans": [{
+"guid": "ffmpeg-individual",
+"status": "active",
+"name": "FFmpeg individual",
+"description": "Pay as much or as little as you want",
+"amount": 0,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi", "ffmpeg-crypto"]
+},{
+"guid": "visionary",
+"status": "active",
+"name": "Visionary Sponsor",
+"amount": 155000,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi-bank"]
+},{
+"guid": "sustainability",
+"status": "active",
+"name": "Sustainability Sponsor",
+"amount": 95000,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi-bank"]
+},{
+"guid": "maintaining",
+"status": "active",
+"name": "Maintaining Sponsor",
+"amount": 63000,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi-bank"]
+},{
+"guid": "contributing",
+"status": "active",
+"name": "Contributing Sponsor",
+"amount": 33000,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi-bank"]
+},{
+"guid": "supporting",
+"status": "active",
+"name": "Supporting Sponsor",
+"amount": 16500,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi-bank"]
+},{
+"guid": "partner",
+"status": "active",
+"name": "Partner Spo
[FFmpeg-devel] CI
Hi It seems the forgejo CI takes about 13min to do fate on aarch64 and x86-64 and build on win64 Locally i run fate + install on x86-64 build on x86-32, mingw64, arm32, mips, ppc, x86-64 + shared libs testprogs alltools examples build on x86-64, x86-32 and arm32 in 2min 44sec can we improve the speed vs amount of tests ratio ? (its not a problem ATM, i did in fact not even notice as i never waited on it) Iam just seeing the difference in time and i think there is potential for optimization here I dont think my box here is really special, just a AMD Ryzen 9 3950X 16-Core + Samsung SSD 970 PRO thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] CI
Hi On Wed, Aug 20, 2025 at 05:56:27PM +0200, Timo Rothenpieler via ffmpeg-devel wrote: > On 8/20/2025 1:26 AM, Michael Niedermayer via ffmpeg-devel wrote: > > Hi > > > > It seems the forgejo CI takes about > > 13min to do fate on aarch64 and x86-64 and build on win64 > > > > Locally i run > > fate + install on x86-64 > > build on x86-32, mingw64, arm32, mips, ppc, x86-64 + shared libs > > testprogs alltools examples build on x86-64, x86-32 and arm32 > > in 2min 44sec > > > > can we improve the speed vs amount of tests ratio ? > > (its not a problem ATM, i did in fact not even notice as i never waited on > > it) > > > > Iam just seeing the difference in time and i think there is potential for > > optimization here > > > > I dont think my box here is really special, just a > > AMD Ryzen 9 3950X 16-Core + Samsung SSD 970 PRO > > Well, the test runners are 4 cores and 8GB of RAM. So that'll be the primary > difference in speed. > I think they're performing pretty good for being just that. > > We could of course throw money at the problem and turn them into 16 core > machines. That would up the hosting cost of the runners from currently > 3*7.5€ a month to 3*30€ a month. Just for the runners. > > imo the current CI turnaround times are fine. 15-20 minutes per job is fine, > as long as they can all run in parallel. Option 1: 15-20 min CI turnaround, 270 € per year Option 2: 4-5? min CI turnaround, 1080 € per year we have over 150k $ it seems Good use of capital can also lead to more donations I think the main question is, "would we benefit from the faster trunaround"? or not ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes
Hi Niklas On Fri, Aug 22, 2025 at 02:29:56PM +0200, Niklas Haas via ffmpeg-devel wrote: > On Thu, 21 Aug 2025 13:32:02 +0200 Michael Niedermayer via ffmpeg-devel > wrote: > > Hi > > > > Should we use a Merge or Cherry picks for integrating Pauls work ? > > > > Following are 2 plans, as we execute either we may run into issues > > and of course adapt them as needed. (or even switch) > > > > Option M: > > This would be a merge of pauls last revission before files where > > switched to GPL and the command line tool to AGPL > > > > It would include all changes (except what is intentionally skiped) > > (This will look similar to how almpeg looks now) > > > > Fate tests would be added after the merge where sample media is > > publically available on our server. > > Reviews of Individual modules can be done after the merge where > > people want to do that. > > > > Option C: > > Individual Modules (Codecs, Filters, Demuxers) would be submitted > > as patch(sets) > > > > This would include only the picked changes. Changes noone picks and > > posts would be missing. > > > > Each would go through the review process (some likely with "apply > > after timeout"). And during that review fate tests would be added > > where public samples are on our server. > > > > M would likely integrate more changes, C less changes. C may be more work. > > > > We currently have a point on the wiki for STF 2025 that would fund each > > integrated module with 900€. > > That way, whoever adds fate tests, makes changes the community wants in > > a review, fixes bugs found by tests or review, could be funded. > > D > > Since you tagged the GA on this, I am going to go ahead and request that > a formal GA vote, which I assume will be conducted before any action, must > have the option to vote that we respect Paul's request (and arguably, his > legal right) to not merge his work into FFmpeg. This here is a simple (and transparent) vote Using the mailing list allows people also to discuss and explain their reasonings (like you did here) I do think there is value in hearing the reasonings of people and not just seeing a number of how many are in favor vs against. [...] > > It is possible that teh community adjusts the exact STF task / work / ... > > before its deadline. > > I think that SPI/STF projects should also be voted on by the GA before being > approved for inclusion in the contract proposal. That was always possible, people can and could always discuss and object to proposals. What we submit to STF should be proposals that have a broad consensus not 51% behind them > > We already have the infrastructure for this in place, and I am sure that the > majority of the GA members would rather spend 5 minutes of their time > reviewing each project proposal rather than having it handled in an ad-hoc > manner. The infrastructure will tell you what the majority voted for. Not why Nor will it lead to a consensus if theres none before but open discussion can lead to consensus thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes
Hi Niklas On Fri, Aug 22, 2025 at 02:29:56PM +0200, Niklas Haas via ffmpeg-devel wrote: > On Thu, 21 Aug 2025 13:32:02 +0200 Michael Niedermayer via ffmpeg-devel > wrote: > > Hi > > > > Should we use a Merge or Cherry picks for integrating Pauls work ? > > > > Following are 2 plans, as we execute either we may run into issues > > and of course adapt them as needed. (or even switch) > > > > Option M: > > This would be a merge of pauls last revission before files where > > switched to GPL and the command line tool to AGPL > > > > It would include all changes (except what is intentionally skiped) > > (This will look similar to how almpeg looks now) > > > > Fate tests would be added after the merge where sample media is > > publically available on our server. > > Reviews of Individual modules can be done after the merge where > > people want to do that. > > > > Option C: > > Individual Modules (Codecs, Filters, Demuxers) would be submitted > > as patch(sets) > > > > This would include only the picked changes. Changes noone picks and > > posts would be missing. > > > > Each would go through the review process (some likely with "apply > > after timeout"). And during that review fate tests would be added > > where public samples are on our server. > > > > M would likely integrate more changes, C less changes. C may be more work. > > > > We currently have a point on the wiki for STF 2025 that would fund each > > integrated module with 900€. > > That way, whoever adds fate tests, makes changes the community wants in > > a review, fixes bugs found by tests or review, could be funded. > > D > > Since you tagged the GA on this, I am going to go ahead and request that > a formal GA vote, which I assume will be conducted before any action, must > have the option to vote that we respect Paul's request (and arguably, his > legal right) to not merge his work into FFmpeg. > > Even if you personally think the risk of Paul litigating FFmpeg in response > is neglible, and are willing to shoulder the potential costs of a legal battle > on your own shoulders, I do not think it sets a good precedent and will be > potentially damaging to the FFmpeg project's public image. So, lets just make a thought-experiment 1. Mr X forks FFmpeg. 2. Mr X merges Pauls (LGPL) code 3. Mr X adds everything he finds cool or inovative 4. Mr X maintains his fork and stops maintaining anything in FFmpeg 5. Mr X daily merges ffmpeg improvments (and maybe pauls if his code is GPL) 6. Mr X nicely tell FFmpeg that he objects to FFmpeg merging his code ;) ;) ; will ffmpeg comply to this request ? What if I join these forks, you know each of the forks will take ffmpeg code and each others work. (within the bounds of each ones licenses) FFmpeg will not integrate any improvments back ? Thats how you suggest FFmpeg should be run ? how could that work ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] CI
On Fri, Aug 22, 2025 at 02:13:14PM +0200, Timo Rothenpieler via ffmpeg-devel wrote: > On 22/08/2025 07:00, Kieran Kunhya via ffmpeg-devel wrote: > > On Thu, 21 Aug 2025, 11:33 Michael Niedermayer via ffmpeg-devel, < > > ffmpeg-devel@ffmpeg.org> wrote: > > > > > Hi > > > > > > On Thu, Aug 21, 2025 at 12:31:46AM +0200, Timo Rothenpieler via > > > ffmpeg-devel wrote: > > > > On 8/20/2025 9:25 PM, Michael Niedermayer via ffmpeg-devel wrote: > > > > > Hi > > > > > > > > > > On Wed, Aug 20, 2025 at 05:56:27PM +0200, Timo Rothenpieler via > > > ffmpeg-devel wrote: > > > > > > On 8/20/2025 1:26 AM, Michael Niedermayer via ffmpeg-devel wrote: > > > > > > > Hi > > > > > > > > > > > > > > It seems the forgejo CI takes about > > > > > > > 13min to do fate on aarch64 and x86-64 and build on win64 > > > > > > > > > > > > > > Locally i run > > > > > > >fate + install on x86-64 > > > > > > >build on x86-32, mingw64, arm32, mips, ppc, x86-64 + shared > > > libs > > > > > > >testprogs alltools examples build on x86-64, x86-32 and > > > > > > > arm32 > > > > > > >in 2min 44sec > > > > > > > > > > > > > > can we improve the speed vs amount of tests ratio ? > > > > > > > (its not a problem ATM, i did in fact not even notice as i never > > > waited on it) > > > > > > > > > > > > > > Iam just seeing the difference in time and i think there is > > > potential for > > > > > > > optimization here > > > > > > > > > > > > > > I dont think my box here is really special, just a > > > > > > > AMD Ryzen 9 3950X 16-Core + Samsung SSD 970 PRO > > > > > > > > > > > > Well, the test runners are 4 cores and 8GB of RAM. So that'll be the > > > primary > > > > > > difference in speed. > > > > > > I think they're performing pretty good for being just that. > > > > > > > > > > > > We could of course throw money at the problem and turn them into 16 > > > core > > > > > > machines. That would up the hosting cost of the runners from > > > currently > > > > > > 3*7.5€ a month to 3*30€ a month. Just for the runners. > > > > > > > > > > > > imo the current CI turnaround times are fine. 15-20 minutes per job > > > is fine, > > > > > > as long as they can all run in parallel. > > > > > > > > > > Option 1: 15-20 min CI turnaround, 270 € per year > > > > > Option 2: 4-5? min CI turnaround, 1080 € per year > > > > > > > > > > we have over 150k $ it seems > > > > > > > > > > Good use of capital can also lead to more donations > > > > > > > > > > I think the main question is, "would we benefit from the faster > > > trunaround"? > > > > > or not ? > > > > > > > > You have to keep in mind, 4 Core 8GB is also the swarm of runners we get > > > for > > > > free from Microsoft via GitHub. > > > > > > > > So the choice is actually "Be able to process 20+ jobs in parallel that > > > take > > > > 15-20 minutes each" vs. "Be able to process 3 or so at a time (roughly > > > one > > > > PR/push) in 5 minutes". > > > > So realistically, unless we also pay for an actual swarm of runners > > > > ourselves(which would cost 10k or more a year while being idle 95% of > > > > the > > > > time) the total turnaround time including wait for a free runner is > > > probably > > > > still better with more of the smaller runners than less of the big ones. > > > > > > > > It'd also make it a lot more pressing to think about every single CI job > > > we > > > > add, vs. having a bit of leeway due to the over-abundance of runners. > > > > > > for 1-2k$ you can buy a box that runs fate once and build on 6 times in > > > under 3minutes. > > > > > > if one is not enough buy 3, use the extra capcity for fuzzing or rent out > > > to other projec
Re: [FFmpeg-devel] CI
Hi Timo On Fri, Aug 22, 2025 at 02:13:14PM +0200, Timo Rothenpieler via ffmpeg-devel wrote: [...] > But then again, GitHub/MS gives us 20 parallel runners for free, and we can > freely pick if they're running on x86_64 or aarch64, Linux, Windows or even > OSX. > As long as they do that, we only need to host a baseline of runners > ourselves, and can scale out into that whenever there's a peak in usage. if they give us 20, can we test mips & arm with qemu in a way that it does not block or delay merges. I mean so that a pr is considered ok and mergeable before tzhe slow qemu fate finishes but after the 2h or so it will display the result in the pr thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Re: Community booth address Was: STF 2025 grant request (2025-09-01 target)
Hi Remi On Sun, Aug 24, 2025 at 04:46:09PM +0300, Rémi Denis-Courmont via ffmpeg-devel wrote: > Le sunnuntai 24. elokuuta 2025, 13.47.49 Itä-Euroopan kesäaika Michael > Niedermayer via ffmpeg-devel a écrit : [...] > > And you simply posted thilos street address in public. > > Kieran quoted an unidentified address from public pages of the tradeshow's > website, and asked whose it is. If Thilo has a problem with the privacy > policy > of the tradeshow, that's not something to blame Kieran for. > > Ultimately, it was not Kieran who outed Thilo as the addressee. (IIRC, it was > none other than Thilo himself.) Lets look at the ML 1. 2023-11-01 Thilo announcing the NAB 2024 booth https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316474.html Subject: [FFmpeg-devel] FFmpeg at NAB 2024 After this EVERYONE knew Thilo was setting up a booth on NAB2024 for FFmpeg ---> Both Kieran and Derek wrote replies in the announcement above. <--- 2. 2024-01-31 Kieran posting the street address publically as reply to Cosmin. After cosmin pointed out that this is likely thilos booth " There is currently a booth registered under the FFmpeg name: https://nab24.mapyourshow.com/8_0/exhview/?hallID=W&selectedBooth=W4232 Currently it has the following address associated to FFmpeg: [SNIP] Who does this address belong to? " thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: STF 2025 grant request (2025-09-01 target)
Hi Derek On Sun, Aug 24, 2025 at 03:33:32PM +0100, Derek Buitenhuis via ffmpeg-devel wrote: > On 8/24/2025 2:46 PM, Rémi Denis-Courmont via ffmpeg-devel wrote: > > Le sunnuntai 24. elokuuta 2025, 13.47.49 Itä-Euroopan kesäaika Michael > > Niedermayer via ffmpeg-devel a écrit : > >> Then thilo was attacked by derek claiming he stole money. > > > > Derek claimed that Thilo had some sort of alcohol-related issue. This was I do not think the public mailing list is the appropriate place for discussing someones personal health without their consent. And the alcohol part may be wrong. But i do NOT know what the health issues where. I never pushed him to tell me, because i felt this is none of my buisness. > > totally unacceptable behaviour, since he failed to provide any proof of his > > statement, nor of the alleged negative impact to FFmpeg. Nevertheless, this > > is > > not quite as bad as accusing someone of theft/embezzelment, which would > > constitute outright slander. > > I, at no point, claimed money was stolen. Here: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-November/336263.html You wrote this: "I also do not believe STF and SPI are being used appropriately, and I believe Thilo is recieving money through this, possible via Michael, (and also only appears when the next thing he needs is relevant)." This is as close as you can get to a claim of stolen money without using the word "stolen" [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH v4 0/3] avcodec/aac_ac3_parser: fix HE-AAC probing
On Tue, Aug 12, 2025 at 12:35:15PM +0200, Nicolas Gaullier wrote:
> v4 (Michael): first patch splitted: now 3 patches, code is unchanged.
> v3 (James): complete overhaul of the commit message of the first
> patch, code is unchanged. Second patch is fully unchanged ("should be ok").
> v2 (Baptiste): keep setting the profile in the parser even if it is not
> always reliable, just allow it to be overriden by the decoder.
>
> Nicolas Gaullier (3):
> avcodec/aac_ac3_parser: remove unused USAC/ADTS code
> avcodec/aac_ac3_parser: simplify
> avcodec/aac_ac3_parser: do not override the profile set by the decoder
>
> libavcodec/aac_ac3_parser.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
will apply patchset, this looks like it has been through enough
rounds of review
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
z(9) = an object that transcends all computable functions describable
in finite terms. - ChatGPT in 2024
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH] web: Add funding.json
Hi Derek On Fri, Aug 29, 2025 at 01:48:07PM +0100, Derek Buitenhuis via ffmpeg-devel wrote: > On 8/29/2025 2:08 AM, Kieran Kunhya via ffmpeg-devel wrote: > We'll see if this is pushed without consent like funding.json > was to the main git repo, which has yet to be removed. Implying that a funding.json was pushed without consent is unacceptable The patch was on the mailing list, Do 19 Jun 2025 21:12:23 CEST Michael Niedermayer [FFmpeg-devel] [PATCH] Add FUNDING.json The General Assembly was informed about the potential donation from the etherum foundation, that needed this FUNDING.json file Mo 09 Jun 2025 21:30:27 CEST Michael Niedermayer Donation from the etherium foundation Mi 18 Jun 2025 23:23:31 CEST Michael Niedermayer Re: Donation from the etherium foundation Normally this would call for a private one on one discussion but as you make these statments in public, it requires a public response. What you do here is damaging to the FFmpeg project. Including a potential loss of sponsors. And also very damaging to the Team. This comes after, you yourself already stated that you would limit yourself to code and reviews: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-November/336263.html "The only mails you'll see from me in the future are code or reviews. I am sure certain community members will appreciate that." And id like to emphasize, even IF something wrong happened with funding.json thats a matter to be discussed and resolved privatly. First with the involved parties, and if that fails with the GA. None of that happened Posting such claims in public is damaging to the project and team. And is completely unacceptable thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH] web: Add funding.json
Hi Remi
On Fri, Aug 29, 2025 at 08:35:54PM +0300, Rémi Denis-Courmont via ffmpeg-devel
wrote:
[...]
> >+},{
> >+"guid": "ffmpeg-crypto",
> >+"type": "other",
> >+"address": "0x2f3900e7064eE63D30d749971265858612AA7139",
> >+"description": "USDC on
> >etherium/arbitrum/base/optimism/polygon, small amounts only, until we fully
> >understand tax and accounting of this"
> >+}
>
> Does SPI controls this crypto-wallet? If not, then either:
> - the entity controlling the wallet is somehow not taxable and is
> appropriating community funding,
> - the entity controlling the wallet is taxable and, on top of the above, it
> is legally questionable, no matter how small the amount(s).
>
> In other words, unless the answer is "yes", the only possible response is
> "hard nack".
Ive sent a V2 of this patch without this wallet, but to awnser your questions
This is FFmpegs gnosis safe wallet, i have originally set it up
The wallet is controlled by the General Assembly of FFmpeg and SPI
And the General Assembly can change the person(s) who control the wallet
For example the GA could simply choose any people it wants
these people then could make a transaction. for example it could be setup as a
2 of 3
multisig, so that 2 of 3 people have to agree on a transaction.
(of course once the GA does that, only these people can make future changes)
Currently the wallet is intended to only serve as a intermediate to move money
from crypto USDC to USD on SPIs/FFmpeg. This is not a taxable operation here
according to the tax adviser i have asked. But i still would like to limit
the use of this wallet until we are sure everything works in practice.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] [PATCH v2] web: Add funding.json
See: https://fundingjson.org/
See: https://floss.fund/
Based on: https://www.python.org/funding.json and the example from
fundingjson.org
It is put in the web repository so its all on the plain ffmpeg.org domain
otherwise extra files are needed
---
htdocs/funding.json | 126
1 file changed, 126 insertions(+)
create mode 100644 htdocs/funding.json
diff --git a/htdocs/funding.json b/htdocs/funding.json
new file mode 100644
index 000..42664c7
--- /dev/null
+++ b/htdocs/funding.json
@@ -0,0 +1,126 @@
+{
+"version": "v1.0.0",
+
+"entity": {
+"type": "group",
+"role": "owner",
+"name": "FFmpeg",
+"email": "ffmpeg-devel@ffmpeg.org",
+"description": "FFmpeg is the leading multimedia framework, able to
decode, encode, transcode, mux, demux, stream, filter and play pretty much
anything that humans and machines have created. It supports the most obscure
ancient formats up to the cutting edge. No matter if they were designed by some
standards committee, the community or a corporation. It is also highly
portable: FFmpeg compiles, runs, and passes our testing infrastructure FATE
across Linux, Mac OS X, Microsoft Windows, the BSDs, Solaris, etc. under a wide
variety of build environments, machine architectures, and configurations.",
+"webpageUrl": {
+"url": "https://ffmpeg.org/";
+}
+},
+
+"projects": [{
+"guid": "ffmpeg",
+"name": "FFmpeg",
+"description": "FFmpeg is the leading multimedia framework, able to
decode, encode, transcode, mux, demux, stream, filter and play pretty much
anything that humans and machines have created. It supports the most obscure
ancient formats up to the cutting edge. No matter if they were designed by some
standards committee, the community or a corporation. It is also highly
portable: FFmpeg compiles, runs, and passes our testing infrastructure FATE
across Linux, Mac OS X, Microsoft Windows, the BSDs, Solaris, etc. under a wide
variety of build environments, machine architectures, and configurations.",
+"webpageUrl": {
+"url": "https://ffmpeg.org/";
+},
+"repositoryUrl": {
+"url": "https://ffmpeg.org/download";
+},
+"licenses": ["spdx:LGPL-2.1-or-later", "spdx:GPL-2.0-or-later"],
+"tags": ["audio", "graphics"]
+}],
+
+"funding": {
+"channels": [{
+"guid": "ffmpeg-spi",
+"type": "other",
+"address": "https://ffmpeg.org/donations.html";,
+"description": "Paypal, CreditCard, Check, Money Order"
+},{
+"guid": "ffmpeg-spi-bank",
+"type": "bank",
+"address": "Please email us for payment details.",
+"description": "Bank transfer"
+}
+],
+
+"plans": [{
+"guid": "ffmpeg-individual",
+"status": "active",
+"name": "FFmpeg individual",
+"description": "Pay as much or as little as you want",
+"amount": 0,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi"]
+},{
+"guid": "visionary",
+"status": "active",
+"name": "Visionary Sponsor",
+"amount": 155000,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi-bank"]
+},{
+"guid": "sustainability",
+"status": "active",
+"name": "Sustainability Sponsor",
+"amount": 95000,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi-bank"]
+},{
+"guid": "maintaining",
+"status": "active",
+"name": "Maintaining Sponsor",
+"amount": 63000,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi-bank"]
+},{
+"guid": "contributing",
+"status": "active",
+"name": "Contributing Sponsor",
+"amount": 33000,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi-bank"]
+},{
+"guid": "supporting",
+"status": "active",
+"name": "Supporting Sponsor",
+"amount": 16500,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi-bank"]
+},{
+"guid": "partner",
+"status": "active",
+"name": "Partner Sponsor",
+"amount": 11000,
+"currency": "USD",
+"frequency": "yearly",
+"channels": ["ffmpeg-spi-bank"]
+},{
+"guid": "participating",
+"status": "active",
+"name": "Participating Sponsor",
+"amount": 4000,
+
[FFmpeg-devel] Re: [PATCH] web: Add funding.json
Hi Remi On Sun, Aug 31, 2025 at 11:53:01AM +0300, Rémi Denis-Courmont via ffmpeg-devel wrote: [...] > > And the General Assembly can change the person(s) who control the wallet > > For example the GA could simply choose any people it wants > > these people then could make a transaction. for example it could be setup as > > a 2 of 3 multisig, so that 2 of 3 people have to agree on a transaction. > > > > (of course once the GA does that, only these people can make future changes) > > > > Currently the wallet is intended to only serve as a intermediate to move > > money from crypto USDC to USD on SPIs/FFmpeg. This is not a taxable > > operation here according to the tax adviser i have asked. > > Currency conversion is not taxable in some jurisdictions (including mine, > AFAIK), but then why does it say that this should be limited to small sums? > Simply, either there is a tax problem and we should not allow it at all, or > there is no tax problem at all. Simple awnser: because iam not 100% sure Long awnser: I had asked a tax expert about forwarding USDC from the etherium foundation grant to SPI stripe, But he was quite busy that moment, so the advice that its "ok" doesnt give me 100% confidence. Id like an actual transaction with a "small" sum to happen (and this requires SPI to accept USDC by some means first). And then have that tax expert look at that specific case and confirm. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH 0/2] libavfilter/vf_minterpolate: Minor speedup
On Fri, Aug 29, 2025 at 08:19:39PM +, Zsolt Vadász via ffmpeg-devel wrote: > > This patch series makes vf_minterpolate approximately 5% faster, > according to my tests, which I performed on a Ryzen 7 PRO 4750U, > compiling with GCC 15.2.1, using -O2. > > Zsolt Vadasz (2): > libavfilter/vf_minterpolate: Hoist hot loop in `set_frame_data` > libavfilter/vf_minterpolate: Use local variable in array access > > libavfilter/vf_minterpolate.c | 21 - > 1 file changed, 12 insertions(+), 9 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH] avformat/wavdec: support loop_start and loop_end from 'smpl' chunk
On Sat, Aug 30, 2025 at 04:27:25PM -0700, Spencer Alves via ffmpeg-devel wrote:
> The 'smpl' chunk is used for sampling music synthesizers, and includes
> things like the pitch of the sample and how to loop it. This exposes the
> loop points as "loop_start" and "loop_end" metadata, that the brstm, mca,
> and scd demuxers already support.
>
> Tested with file output from "Polyphone" soundfont editor.
>
> Signed-off-by: Spencer Alves
> ---
> libavformat/wavdec.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
> index c65e0a2723..fb3749d64d 100644
> --- a/libavformat/wavdec.c
> +++ b/libavformat/wavdec.c
> @@ -595,6 +595,28 @@ static int wav_read_header(AVFormatContext *s)
> }
> }
> break;
> +case MKTAG('s', 'm', 'p', 'l'):
> +if (size >= 36 && got_fmt && st->codecpar->sample_rate > 0) {
> +unsigned sample_loop_count;
> +avio_skip(pb, 28);
> +sample_loop_count = avio_rl32(pb);
> +avio_skip(pb, 4);
> +for (unsigned i = 0; i < sample_loop_count; i++) {
> +avio_skip(pb, 8);
> +if (av_dict_set_int(&s->metadata, "loop_start",
> +av_rescale(avio_rl32(pb), AV_TIME_BASE,
> + st->codecpar->sample_rate),
> +AV_DICT_MULTIKEY) < 0)
> +return AVERROR(ENOMEM);
> +avio_skip(pb, 8);
> +if (av_dict_set_int(&s->metadata, "loop_end",
> +av_rescale(avio_rl32(pb), AV_TIME_BASE,
> + st->codecpar->sample_rate),
> +AV_DICT_MULTIKEY) < 0)
> +return AVERROR(ENOMEM);
> +}
> +}
> +break;
> }
> /* seek to next tag unless we know that we'll run into EOF */
> --
error: corrupt patch at line 38
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH] fftools/ffmpeg: fix gracefully shutdown
Hi Patrick
On Fri, Aug 29, 2025 at 02:58:16AM +0800, Patrick Wang via ffmpeg-devel wrote:
> d119ae2fd82a494d9430ff4d4fc262961a68c598 removed the loop-breaking condition
> received_sigterm.
> Thus, signals no longer gracefully shutdown ffmpeg.
>
> Fixes: #10834
>
> Signed-off-by: Patrick Wang
> ---
> fftools/ffmpeg.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index de607cac9..cd3894341 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -806,8 +806,6 @@ static int check_keyboard_interaction(int64_t cur_time)
> {
> int i, key;
> static int64_t last_time;
> -if (received_nb_signals)
> -return AVERROR_EXIT;
> /* read_key() returns 0 on EOF */
> if (cur_time - last_time >= 10) {
> key = read_key();
> @@ -891,6 +889,9 @@ static int transcode(Scheduler *sch)
> while (!sch_wait(sch, stats_period, &transcode_ts)) {
> int64_t cur_time= av_gettime_relative();
>
> + if (received_nb_signals)
> + break;
will apply without the tabs
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH v3 2/2] avcodec/libaom: Add test for HDR10+ metadata support
On Wed, Aug 27, 2025 at 01:06:42PM +0200, Maryla Ustarroz via ffmpeg-devel wrote: > On Mon, Aug 11, 2025 at 2:01 PM Maryla Ustarroz wrote: > > > > On Mon, Aug 11, 2025 at 1:57 PM Maryla Ustarroz-Calonge > > wrote: > > > > > > Signed-off-by: Maryla Ustarroz-Calonge > > > --- > > > tests/Makefile | 1 + > > > tests/fate/av1.mak | 7 + > > > tests/ref/fate/libaom-hdr10-plus | 44 > > > 3 files changed, 52 insertions(+) > > > create mode 100644 tests/fate/av1.mak > > > create mode 100644 tests/ref/fate/libaom-hdr10-plus > > > > > > diff --git a/tests/Makefile b/tests/Makefile > > > index 3f4dbaabfd..3eef290e41 100644 > > > --- a/tests/Makefile > > > +++ b/tests/Makefile > > > @@ -162,6 +162,7 @@ include $(SRC_PATH)/tests/fate/apng.mak > > > include $(SRC_PATH)/tests/fate/apv.mak > > > include $(SRC_PATH)/tests/fate/atrac.mak > > > include $(SRC_PATH)/tests/fate/audio.mak > > > +include $(SRC_PATH)/tests/fate/av1.mak > > > include $(SRC_PATH)/tests/fate/bmp.mak > > > include $(SRC_PATH)/tests/fate/build.mak > > > include $(SRC_PATH)/tests/fate/caf.mak > > > diff --git a/tests/fate/av1.mak b/tests/fate/av1.mak > > > new file mode 100644 > > > index 00..81072be5b8 > > > --- /dev/null > > > +++ b/tests/fate/av1.mak > > > @@ -0,0 +1,7 @@ > > > +# Tests that reading and writing with codec libaom-av1 preserves HDR10+ > > > metadata. > > > +FATE_AV1_FFMPEG_FFPROBE-$(call ENCDEC, LIBAOM_AV1 VP9, IVF MATROSKA) += > > > fate-libaom-hdr10-plus > > > +fate-libaom-hdr10-plus: CMD = enc_external > > > $(TARGET_SAMPLES)/mkv/hdr10_plus_vp9_sample.webm ivf "-map 0 -c:v > > > libaom-av1 -cpu-used 8" "-show_frames -show_entries frame=side_data_list > > > -codec:v libaom-av1" > > > + > > > +FATE_SAMPLES_FFMPEG_FFPROBE += $(FATE_AV1_FFMPEG_FFPROBE-yes) > > > + > > > +fate-av1: $(FATE_AV1_FFMPEG_FFPROBE-yes) > > > diff --git a/tests/ref/fate/libaom-hdr10-plus > > > b/tests/ref/fate/libaom-hdr10-plus > > > new file mode 100644 > > > index 00..c03dda7e7f > > > --- /dev/null > > > +++ b/tests/ref/fate/libaom-hdr10-plus > > > @@ -0,0 +1,44 @@ > > > +[FRAME] > > > +[SIDE_DATA] > > > +side_data_type=HDR Dynamic Metadata SMPTE2094-40 (HDR10+) > > > +application version=1 > > > +num_windows=1 > > > +targeted_system_display_maximum_luminance=400/1 > > > +maxscl=3340/10 > > > +maxscl=2870/10 > > > +maxscl=2720/10 > > > +average_maxrgb=510/10 > > > +num_distribution_maxrgb_percentiles=9 > > > +distribution_maxrgb_percentage=1 > > > +distribution_maxrgb_percentile=30/10 > > > +distribution_maxrgb_percentage=5 > > > +distribution_maxrgb_percentile=2940/10 > > > +distribution_maxrgb_percentage=10 > > > +distribution_maxrgb_percentile=255/10 > > > +distribution_maxrgb_percentage=25 > > > +distribution_maxrgb_percentile=70/10 > > > +distribution_maxrgb_percentage=50 > > > +distribution_maxrgb_percentile=1340/10 > > > +distribution_maxrgb_percentage=75 > > > +distribution_maxrgb_percentile=1600/10 > > > +distribution_maxrgb_percentage=90 > > > +distribution_maxrgb_percentile=1850/10 > > > +distribution_maxrgb_percentage=95 > > > +distribution_maxrgb_percentile=1950/10 > > > +distribution_maxrgb_percentage=99 > > > +distribution_maxrgb_percentile=2940/10 > > > +fraction_bright_pixels=1/1000 > > > +knee_point_x=0/4095 > > > +knee_point_y=0/4095 > > > +num_bezier_curve_anchors=9 > > > +bezier_curve_anchors=102/1023 > > > +bezier_curve_anchors=205/1023 > > > +bezier_curve_anchors=307/1023 > > > +bezier_curve_anchors=410/1023 > > > +bezier_curve_anchors=512/1023 > > > +bezier_curve_anchors=614/1023 > > > +bezier_curve_anchors=717/1023 > > > +bezier_curve_anchors=819/1023 > > > +bezier_curve_anchors=922/1023 > > > +[/SIDE_DATA] > > > +[/FRAME] > > > \ No newline at end of file > > > -- > > > 2.50.1.703.g449372360f-goog > > > > Note that this is a simplified version of v2 now that ffprobe supports > > the -codec:v flag. > > This allows testing reading and writing of HDR10+ metadata in a single > > test, and > > removes the need for a new test file. > > Friendly ping. will apply patchset thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH v3 2/2] avcodec/libaom: Add test for HDR10+ metadata support
On Tue, Sep 02, 2025 at 10:39:12AM -0300, James Almer via ffmpeg-devel wrote: > On 9/2/2025 10:30 AM, Michael Niedermayer via ffmpeg-devel wrote: > > On Wed, Aug 27, 2025 at 01:06:42PM +0200, Maryla Ustarroz via ffmpeg-devel > > wrote: > > > On Mon, Aug 11, 2025 at 2:01 PM Maryla Ustarroz wrote: > > > > > > > > On Mon, Aug 11, 2025 at 1:57 PM Maryla Ustarroz-Calonge > > > > wrote: > > > > > > > > > > Signed-off-by: Maryla Ustarroz-Calonge > > > > > --- > > > > > tests/Makefile | 1 + > > > > > tests/fate/av1.mak | 7 + > > > > > tests/ref/fate/libaom-hdr10-plus | 44 > > > > > > > > > > 3 files changed, 52 insertions(+) > > > > > create mode 100644 tests/fate/av1.mak > > > > > create mode 100644 tests/ref/fate/libaom-hdr10-plus > > > > > > > > > > diff --git a/tests/Makefile b/tests/Makefile > > > > > index 3f4dbaabfd..3eef290e41 100644 > > > > > --- a/tests/Makefile > > > > > +++ b/tests/Makefile > > > > > @@ -162,6 +162,7 @@ include $(SRC_PATH)/tests/fate/apng.mak > > > > > include $(SRC_PATH)/tests/fate/apv.mak > > > > > include $(SRC_PATH)/tests/fate/atrac.mak > > > > > include $(SRC_PATH)/tests/fate/audio.mak > > > > > +include $(SRC_PATH)/tests/fate/av1.mak > > > > > include $(SRC_PATH)/tests/fate/bmp.mak > > > > > include $(SRC_PATH)/tests/fate/build.mak > > > > > include $(SRC_PATH)/tests/fate/caf.mak > > > > > diff --git a/tests/fate/av1.mak b/tests/fate/av1.mak > > > > > new file mode 100644 > > > > > index 00..81072be5b8 > > > > > --- /dev/null > > > > > +++ b/tests/fate/av1.mak > > > > > @@ -0,0 +1,7 @@ > > > > > +# Tests that reading and writing with codec libaom-av1 preserves > > > > > HDR10+ metadata. > > > > > +FATE_AV1_FFMPEG_FFPROBE-$(call ENCDEC, LIBAOM_AV1 VP9, IVF MATROSKA) > > > > > += fate-libaom-hdr10-plus > > > > > +fate-libaom-hdr10-plus: CMD = enc_external > > > > > $(TARGET_SAMPLES)/mkv/hdr10_plus_vp9_sample.webm ivf "-map 0 -c:v > > > > > libaom-av1 -cpu-used 8" "-show_frames -show_entries > > > > > frame=side_data_list -codec:v libaom-av1" > > > > > + > > > > > +FATE_SAMPLES_FFMPEG_FFPROBE += $(FATE_AV1_FFMPEG_FFPROBE-yes) > > > > > + > > > > > +fate-av1: $(FATE_AV1_FFMPEG_FFPROBE-yes) > > > > > diff --git a/tests/ref/fate/libaom-hdr10-plus > > > > > b/tests/ref/fate/libaom-hdr10-plus > > > > > new file mode 100644 > > > > > index 00..c03dda7e7f > > > > > --- /dev/null > > > > > +++ b/tests/ref/fate/libaom-hdr10-plus > > > > > @@ -0,0 +1,44 @@ > > > > > +[FRAME] > > > > > +[SIDE_DATA] > > > > > +side_data_type=HDR Dynamic Metadata SMPTE2094-40 (HDR10+) > > > > > +application version=1 > > > > > +num_windows=1 > > > > > +targeted_system_display_maximum_luminance=400/1 > > > > > +maxscl=3340/10 > > > > > +maxscl=2870/10 > > > > > +maxscl=2720/10 > > > > > +average_maxrgb=510/10 > > > > > +num_distribution_maxrgb_percentiles=9 > > > > > +distribution_maxrgb_percentage=1 > > > > > +distribution_maxrgb_percentile=30/10 > > > > > +distribution_maxrgb_percentage=5 > > > > > +distribution_maxrgb_percentile=2940/10 > > > > > +distribution_maxrgb_percentage=10 > > > > > +distribution_maxrgb_percentile=255/10 > > > > > +distribution_maxrgb_percentage=25 > > > > > +distribution_maxrgb_percentile=70/10 > > > > > +distribution_maxrgb_percentage=50 > > > > > +distribution_maxrgb_percentile=1340/10 > > > > > +distribution_maxrgb_percentage=75 > > > > > +distribution_maxrgb_percentile=1600/10 > > > > > +distribution_maxrgb_percentage=90 > > > > > +distribution_maxrgb_percentile=1850/10 > > > > > +distribution_maxrgb_percentage=95 > > > > > +distribution_maxrgb_percentile=1950/10 > > > > > +distribution_ma
[FFmpeg-devel] Re: [PATCH v2] web: Add funding.json
Hi Derek On Wed, Sep 03, 2025 at 02:19:28PM +0100, Derek Buitenhuis via ffmpeg-devel wrote: > On 9/3/2025 2:06 PM, Michael Niedermayer via ffmpeg-devel wrote: > > Applied after discussion in the General Assembly. > > There where no objections. > > There were multiple objections on this list. There was one objection against the support for crypto donations by you. And the option for crypto donations was removed in v2 of this patch. Against v2 of this patch there was one objection by your manager (or co worker) Vittorio. There where not multiple objections. https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.org/message/DYTV6QXM2KUW7QHTPLMGDQF6WXLR2YJV/ Vittorio wants FFmpeg to not seek any Sponsors and describes FFmpeg as hostile. How would you describe your and Vittorios behavior towards FFmpeg ? Towards, Thilo, towards me, in the past towards Carl, Paul and others ? And where do you think FFmpeg will be in 10 years if the suggestions from you and Vittorio are implemented (that is not seeking sponsors, not integrating improvments from forks) ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH v2] web: Add funding.json
Hi Derek On Wed, Sep 03, 2025 at 02:19:28PM +0100, Derek Buitenhuis via ffmpeg-devel wrote: > On 9/3/2025 2:06 PM, Michael Niedermayer via ffmpeg-devel wrote: > > Applied after discussion in the General Assembly. > > There where no objections. [...] > Moving it to a private list because it better suits your goal is, to use > a word you like to use: unacceptable. The General Assembly is the group that can override an objection or decide in case of a dispute that doesnt fall under the TC. funding is not a techincal matter so its not for the TC. A formal vote was not opened because not a single member asked for one or supported the objection from vittorio. But i encourage you and vittorio to publically discuss your objections: "I don't think any funding scheme should be authorized." from here: https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.org/message/DYTV6QXM2KUW7QHTPLMGDQF6WXLR2YJV/ I belive close to 100% of FFmpeg supporters, support some funding scheme for FFmpeg. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH v2] web: Add funding.json
On Fri, Aug 29, 2025 at 05:21:00PM +0200, Michael Niedermayer via ffmpeg-devel wrote: > See: https://fundingjson.org/ > See: https://floss.fund/ > > Based on: https://www.python.org/funding.json and the example from > fundingjson.org > > It is put in the web repository so its all on the plain ffmpeg.org domain > otherwise extra files are needed > --- > htdocs/funding.json | 126 > 1 file changed, 126 insertions(+) > create mode 100644 htdocs/funding.json Applied after discussion in the General Assembly. There where no objections. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Some people wanted to paint the bikeshed green, some blue and some pink. People argued and fought, when they finally agreed, only rust was left. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH v2] web: Add funding.json
Hi everyone On Fri, Aug 29, 2025 at 05:21:00PM +0200, Michael Niedermayer via ffmpeg-devel wrote: > See: https://fundingjson.org/ > See: https://floss.fund/ > > Based on: https://www.python.org/funding.json and the example from > fundingjson.org > > It is put in the web repository so its all on the plain ffmpeg.org domain > otherwise extra files are needed > --- > htdocs/funding.json | 126 > 1 file changed, 126 insertions(+) > create mode 100644 htdocs/funding.json Submitted to: https://dir.floss.fund/ "The manifest has been submitted." "Submitting a funding manifest here makes it publicly discoverable on the directory. It also creates an application for a FLOSS/Fund grant. See FAQs." https://dir.floss.fund/view/@ffmpeg.org If you want something changed, just send a patch to change funding.json thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [PATCH] avcodec/decode: fix enum conversion warnings in side_data_map.
On Thu, Sep 04, 2025 at 07:43:36PM +0800, 岑湛权 via ffmpeg-devel wrote:
> From: zhanquan cen
>
> Fix two -Wenum-conversion warnings:
> - Implicit conversion from AVPacketSideDataType to AVFrameSideDataType
> - Implicit conversion from AVFrameSideDataType to AVPacketSideDataType
>
> The packet side data type should be cast explicitly when used in
> packet_side_data_get(), as the function expects AVPacketSideDataType.
>
> CC: ffmpeg-devel@ffmpeg.org
>
> Signed-off-by: zhanquan cen
> ---
> libavcodec/decode.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index f395948d60..f6ed1b4600 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1469,12 +1469,12 @@ static int side_data_map(AVFrame *dst,
>
> {
> for (int i = 0; map[i].packet < AV_PKT_DATA_NB; i++) {
> -const enum AVPacketSideDataType type_pkt = map[i].packet;
> +const enum AVPacketSideDataType type_pkt = (enum
> AVFrameSideDataType)map[i].packet;
^^^
This is not the same type, how does this fix a missmatch ?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] Re: [RFC] Sponsors & Funding
Hi Remi On Tue, Sep 09, 2025 at 02:49:39PM +0300, Rémi Denis-Courmont via ffmpeg-devel wrote: > Hi, > > Le 9 septembre 2025 11:19:26 GMT+03:00, Michael Niedermayer via ffmpeg-devel > a écrit : > >Hi Everyone > > > >The subject of funding and sponsors came up a few times recently. > > > >I think FFmpeg needs a clear guideline on this matter. To avoid > >confusion, to avoid disagreements and to ensure community members > >can point potential sponsors in an aggreed direction without hesitation. > > We already went through that before. There are two ways that companies might > credibly sponsor an OSS project on a big enough scale to actually hire > developers: > > 1) Developers are hired or contracted independently. This is already > happening. > > 2) A legal entity with clear oversight rules that sponsors can trust and > influence collects funding from sponsors and decides whom to pay for what. We have that: "Software in the Public Interest (SPI) is a non-profit corporation registered in the state of New York founded to act as a fiscal sponsor for organizations that develop open source software and hardware. Our mission is to help substantial and significant open source projects by handling their non-technical administrative tasks so that they aren't required to operate their own legal entity." thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
[FFmpeg-devel] SDR debate again Was: Re: [RFC] Sponsors & Funding
Hi Kieran On Tue, Sep 09, 2025 at 10:02:22AM +0100, Kieran Kunhya via ffmpeg-devel wrote: > On Tue, 9 Sept 2025, 09:19 Michael Niedermayer via ffmpeg-devel, < [...] > My suggestion would be: > > - The FFmpeg project should actively seek sponsors and funding. > > - The money would be used for FFmpeg (Maintenance, Development, Infra, > > Testing, Travel, Research, ...) > > - A fair selection process shall be used by the FFmpeg Community to > > select what the money is used for, which maximizes FFmpegs future. > > - The money would also be used to hire / employ FFmpeg Developers > > fulltime or whatever the preferrance of each Developer is. > > - Work / employment shall be preferrentially be given to FFmpeg > > Developers / FFmpeg community members. > > > > What work though? > Who decides this? The FFmpeg Community, and the General Assembly. I think thats the only option we have. > Would sponsors really want their funds > going on SDR or game codecs. Lets discuss this in this little subthread, because why not Had my SDR patch been applied, what would have been different ? 1. a few kilobytes of optional source code that affects noone because its disabled by default 2. I would have had 3 months more time to work on FFmpeg, which i spend arguing over SDR and subsequently spending also less time on FFmpeg 3. Maybe Paul or Anton would still be in FFmpeg 4. I would not have to go over the whole SDR code again and maintain it as a plugin (which will take more time away from FFmpeg) So what did it achieve to block SDR in main ffmpeg git ? please tell me And why would a company have the same preferrance ? IMO any good manager will want their employee to be happy and efficiently working. Not pissing them off, so in fact i expect support in favor of SDR by many companies. Not because they care about SDR, but because they care about me working on the FFmpeg code and SDR has no cost to them. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
