The text is rather confusing. Why not directly mention that the money is fully donated?
It's great that the author likes supporting a charity/foundation, but as a customer, I would expect my money to be used to maintain and further develop the software I pay for. Having all the money directly getting donated, makes me slightly worry about longevity/maintenance of a product...
Author here. I need to clarify my messaging on the website: $3.50 gets donated with every purchase (even though after fees a $3.50 purchase results in about $3.00 going to my account). The people who choose to pay more (there are many!) cover the fees -- huge "thank you" to them.
I'm releasing version 2 in the next 2 months: anyone who ever bought the software (700+ people) will get the download link in their email.
Most of the core contributors had a fight with the project lead, so many of them left the project and forked into libav.
So the community and the projects both split, and both fought about being the real one. And at first, ffmpeg focused only on features, regardless of code quality, while libav focused on clean code, even if that meant compromising on features.
Obviously, people who aligned with the project lead, and people wondering why stuff suddenly didn’t work anymore, were fed up with libav. Even though it was a situation where libavs codebase was, compared to ffmpeg, much cleaner, similar to openssl vs libressl, but sacrificed a huge amount of functionality for that goal.
If you check this link[0] you can see most of your statement about FFmpeg merging everything and Libav being all about clean code is just completely false. Apparently lots of hardcoding and weird NIH on the Libav side, and a biased Ubuntu package maintainer to boot.
I have no bone in this fight, but this is an egregiously terrible and biased summary. I will pick some of the most ridiculous points here to rebut, but a better summary could be found in literally any of the search results for "ffmpeg libav".
> The project lead had a fight with all the other core contributors
There was longstanding animosity between the project lead and other developers, due to a variety of reasons, mainly his dictatorial leadership style.
> everyone but the lead left the project and forked into libav
A small set of contributors with technical control over certain infrastructure removed the lead's access.
> So the community and the projects both split, and both fought about being the real one.
This contradicts your previous claim that "everyone but the lead left the project".
> And at first, ffmpeg focused only on features, regardless of security, while libav focused on security and clean code, even if that meant compromising on features.
This is ridiculous. libav did remove a large amount of code that was working, some of which may have been insecure or not designed well, but a lot of which was actually necessary for people's workflows and not "dead code" as they claimed. Moreover, ffmpeg had a significantly better security profile than libav due to actually patching bugs rather than waiting to do it right (which ffmpeg developers will argue was basically "doing it differently than ffmpeg").
> Even though it was a situation where libavs codebase was, compared to ffmpeg, much cleaner, similar to openssl vs libressl.
It wasn't cleaner, just less. It became more and more "less" when ffmpeg gained new (well-designed) features, and libav refused to merge them just because they were not designed by libav.
All you’re saying is repeating what I stated — libav removed unclean code and focused on cleaning it up, even if that meant losing a lot of functionality.
At the same time, ffmpeg merged pretty much everything, even if that lead to worse code, or security issues.
Yes, libav was slower in patching, but the goals with which it started were good in nature.
> There was longstanding animosity between the project lead and other developers, due to a variety of reasons, mainly his dictatorial leadership style.
That’s nothing different from what I said, I just tried to phrase it more nicely.
> It wasn't cleaner, just less. It became more and more "less" when ffmpeg gained new (well-designed) features, and libav refused to merge them just because they were not designed by libav.
More isn’t better. FFmpeg is one of the buggiest and most broken collections of code on this planet. Clean code, maintainability, and so on are actually important.
Look at libressl — they ripped out 90% of the functionality of openssl, cleaned up the API surfaces, etc. And yes, right now they’re still slower to patch some kinds of bugs than openssl, but once they patch them, they actually stay fixed, while each openssl patch opens a dozen new bugs.
Complete outsider (literally learning about this fight via this post), but I have to admit you seem somwhat biased:
> At the same time, ffmpeg merged pretty much everything, even if that lead to worse code, or security issues.
Do you have proof of this claim, especially for "security issues"?
> That’s nothing different from what I said, I just tried to phrase it more nicely.
Your phrasing makes it sound like the project lead was the instigator.
> FFmpeg is one of the buggiest and most broken collections of code on this planet.
Again, do you have proof of this? I'll admit my experience with ffmpeg is minor, but it seemed like a fairly normal software project when I worked with it rather than a buggy mess.
I believe every major distro that jumped to libav has switched back. Some appearance of bias may be just a statement of fact. ffmpeg frequently merged changes from libav, but not vice versa. The newly commissioned (around the time of the fork) library libswresample for example was never brought over to libav, despite being far more ergonomic than libavresample.
> Your phrasing makes it sound like the project lead was the instigator.
Fixed that
> Again, do you have proof of this?
Most media code is already a huge bunch of a buggy mess, and more obscure codecs are usually the worst examples of this. Which is why gstreamer splits the codecs into groups based on how well they are maintained and how clean the code is.
If you read the CVE lists for ffmpeg, you’ll notice that a lot of them are in not so well maintained codecs or functionality (often in parts libav threw out, which annoyed the people who needed this), or in parts where ffmpeg reinvents the world.
It’s a common issue in many projects, and especially in the media world with obscure codecs which often only a handful of people — or only one person — even understand anymore it’s a major problem, and just like with OpenSSL/LibreSSL, it’s a good reason to rip this code out.
> Do you have proof of this claim, especially for "security issues"?
ffmpeg was known for overly strict code reviews before the fork, but afterwards Michael N. (the lead dev) merged every single libav commit back in without review and called it weird names like "Qatar" he thought were funny.
To be fair he was also schizophrenic and hallucinating. Good coder though.
> Your phrasing makes it sound like the project lead was the instigator.
He was quite difficult to work with, for instance you couldn't get him to delegate anything, and he wouldn't localize ffmpeg because it would take a few extra CPU cycles to look up strings in language tables.
I haven't been able to look at the project in a while but he's probably better.
Libav broke my scripts that had been working for years and had the audacity to claim ffmpeg was deprecated. I'm never glad when a FOSS project crashes and burns, but this is the exception that 'proves' the rule. Good riddance!
what security issues were prevented by libav's wholesale removal of working code? why did libav implement new ffmpeg features in gratuitously incompatible ways? why did libav print the hilariously defamatory "FFMPEG IS DEPRECATED" message?
> what security issues were prevented by libav's wholesale removal of working code?
ffmpeg has a lot of areas where the cold is old, barely maintained, and has many issues. Have you tried running ffmpeg through a static analysis tool? the resulting warning list will be so large, it wouldn’t fit on a floppy.
libav’s first action was removing such unclean code, which was a good thing, the project started with a good motivation, similar to libreSSL — they also ripped out 90% of working code to clean the codebase up.
> why did libav implement new ffmpeg features in gratuitously incompatible ways?
> why did libav print the hilariously defamatory "FFMPEG IS DEPRECATED" message?
Humans are humans, and tribalism is everywhere. After such a fight, usually the groups both declare the other side wrong, and do everything in their might to make their position more popular. That’s not saying it’s justified, and I won’t make a judgement on these actions, nor am I going to declare which side was good or bad, just that libav started with some good ideals, before this happened.
Man, if these reads like ad hominem, I wish you could read the whole story. The linked comment is admirably restrained to the point it prefers being confusing over explaining what happened (fwiw I have no dog in the fight, was privy to the goings-on because my project depended on ffmpeg)
IIRC parsers let it reconstruct metadata from files that aren't muxed, or inaccurately muxed. For instance, you'd need one to read raw .h264 files properly into .mp4.
Parsers typically are used to correctly demarcate packet boundaries in (coded) bitstreams e.g. H.264 bitstream is partitioned into NAL units and the parser assembles all relevant units for a single frame/slice so that the decoder gets everything it needs to decode that sample, nothing more, nothing less.
Well I should hope it does more by now because that's not enough information to mux an H.264 stream. You need to recover PTS/DTS offsets, keyframe types, SPS, etc.
Bwahaha, I still remember getting those 'codepacs' for Windows that'd install like 20 codecs at the same time, including one that was a thin wrapper around libav/ffmpeg. 99% sure half of those violated all kinds of EULAs and copyright issues.
Does this play nice with Python youtube-dl? [1] [2]. I want to run a python script on my computer that captures youtube audio of certain government meetings without first having to dl the entire video and convert it (while doing a bunch of other stuff before and after automatically, all without me touching anything).
Unless you need to convert the audio format, I don't think you need ffmpeg at all - youtube-dl can just download the audio stream and save it to a file. Just list the available formats from a video and choose an audio-only format.
Not sure what you mean, you're able to easily just use youtube-dl to download the audio only. Is the conversion suppose to change it into a certain filetype or something?
You neither need youtube-dl nor ffmpeg for that. JS userscript and wget is enough. Every YT page includes an array with links to all video/audio sources.
Even though they don’t charge for the library, they have a lot riding on the perception of the quality of their protocol. If they allow third party implementations and some of them suck, it might tarnish NDI’s image (and indirectly hurt them via the money they make on hardware).
Edit: I’m certainly not arguing that any particular implementation does suck, just saying that I can see why they might want to protect IP they don’t make money from directly.
Patents aren’t as much of an issue on software outside the US so it’s theoretically doable legally, it would just be like the situation with mp3 etc, Americans would have to snag the packages hosted from outside the US.
Is there anything in the new release that would allow an encoder to be "motion-aware"?
e.g. if the video is static, don't store any information. But if there is movement in the video, start storing frames etc
WHY? I find myself recording lots of videos of me talking through code in an IDE. The screen mostly static, with some occasional the screen scrolling. The regular tradeoff-space afforded by CRF doesn't seem to get me the size results I believe are possible.
If you're storing video only for offline viewing with minimal seeking, you can increase the iframe seperation, but if you're streaming this video, you'll need to pay the cost of including iframes to allow clients to seek or recover from dropped packets.
This guy is totally right. When there's no change on screen a huge percentage of bandwidth is from iframes, essentially start over points for fast forward and network corruption.
There's a tradeoff between skip/fast forward fidelity, streaming delay, and iframes. If you're not live streaming and don't care how easy it is to skip around the video increase the iframes inverval as much as you want and watch the bitrate melt away
If you're streaming, you don't need to implement full I-frames; instead you can do a kind of top-to-bottom rolling refresh. The video will be corrupt until the decoder catches up, but that's OK.
This is mostly used for TV broadcasts where you don't want the whole keyframe to get lost because of some brief interference. It's also good because it lowers peak bandwidth per second.
Most modern video codecs (vp9, av1, h264, h265, etc) handle motion-less or motion compression very well with diff between frames. The newer ones handle motion based frames better by shifting the next frame around to find the smallest diff. Ffmpeg just uses whatever codec configured.
I've been working through this over the last year plus in node, and ended up deciding with my team earlier this year to build a library that makes this easier to understand and work with.
It's early yet, and explicit I/O mapping is not quite there at the moment, but you're welcome to check it out. Feedback is welcome.
PCM-DVD has a specific way in how the channels are interleaved. For bit depths higher than 16, each sample is split so that the lowest byte is stored following the high bytes of all channels. There's also a 3-byte metadata which has to be prefixed to each packet. All of these steps could have been done via a bitstream filter but since the codec_id is different, this has to be done at the encoding stage.
My app pivotally depends on FFmpeg extracting screenshots of videos for users to browse through: https://github.com/whyboris/Video-Hub-App