FFmpeg 4.2
ffmpeg.org
ffmpeg.org
My app pivotally depends on FFmpeg extracting screenshots of videos for users to browse through: https://github.com/whyboris/Video-Hub-App
Appears to donate 100% straight to Charity by the looks of it.
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...
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.
I keep a log of all the donations: https://videohubapp.com/blog.html -- you can click to see the charity website log as well: https://www.againstmalaria.com/VideoHubApp
Happy to answer any questions :)
[0] https://stackoverflow.com/questions/9477115/what-are-the-dif...
If it’s clear and I’m just missing it, sorry i have a temp of 102.3 so I’m a little hazy.
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)
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.
EDIT: Rephrasing for accuracy
> 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.
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.
> 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.
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.
https://alioth-lists.debian.net/pipermail/pkg-multimedia-mai...
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.
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.
Nice to see progress in the AV1 front!
Not sure how that would apply to GIF.
The parser is inserted after demux and before decode.
Yes, xPS are also located and decoded. My comment wasn't meant to be an enumeration. Specific tasks depend on the complexity of the bitstream syntax.
BVLC.
by the time you got there you were way past that point.
[1] https://stackoverflow.com/questions/27473526/download-only-a...
[2] https://stackoverflow.com/questions/39665160/youtube-dl-pyth...
[1] https://github.com/ytdl-org/youtube-dl/blob/c3bcd206eb031de3...
`youtube-dl -F <URL>` will display the available formats.
Would love to see an open source NDI, but I know newtek will never allow it.
Newtek should really bite the bullet and just open source, and make their money on the 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.
Offtopic: GStreamer and rust are a powerful combination.
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.
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
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.
I'm building some software on using it is kind of cumbersome
https://github.com/lovell/sharp
Benchmark
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.