FFmpeg 5.0
github.comIn 2003 or 2004 I had a job doing video installations with Linux systems in a variety of museums. That was the first time I learned about FFMpeg. Used it for everything, still one of the first things I install on any system, and whenever I need to do anything with video conversion or resizing or taking a slice out, I use FFMpeg. It is awesome.
Although, after all these years I still have to look up every single incantation except for the most basic things.
Wish it was easier to get Nvidia's encoder working with it. Too often it maxes out my CPU and the GPU is idle.
On most Linux package managers these days, FFmpeg is built with support for hardware encode, decode, and filtering out of the box.
Cutting releases of such a huge project with so many moving pieces, sub-projects, and dependencies, must be quite an effort!
This "5.0 release" thread in the official mailing list shows that they are trying to establish a "feature freeze" process in order to have a clear cut point where a release branch is made:
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-January/290665...
(yes that's the beginning of the thread... I guess the conversation drifted naturally from some previous patch discussion, until the point someone decided to change the email subject)
What are the highlights that made this a new major release? The changelog just mentions which codecs, muxers etc. got added and I'd appreciate if someone can explain what the important additions are
Blog post about the release: http://www.jbkempf.com/blog/post/2022/FFmpeg-5.0
See "Big API changes and deprecations" to know more about the major version bump.
I use ffmpeg to slice up and convert video.
I just looked at the new features for 5.0.
Does anyone have a more detailed description on what these are?
Why is ffmpeg still using Trac for bug reports? Switching to Gitlab would make it a lot more pleasant to deal with.
Most open source projects stick with the same system they started with. Don't fix what ain't broke.
Except it is broke. I'm not motivated to deal with Trac even if I want to submit a bug report.
So the above argument is not addressing the situation. Making bug reporting a better experience is in the interest of the project.
I find Debian bug reports a similarly annoying experience becasue it's so archaic. I.e. I deal with it, but I can totally understand if someone is turned off by the experience and simply avoids reporting bugs because of it.
Making code contribution a better experience is in the interests of the project, making it easier to report bugs is not such a clear win. Consumption-centric interactions are a modern concept originally popularized by the structure of the GitHub UI. Gamifying project popularity and making it easy for users to report bugs nobody is paying to have fixed has almost nothing to do with the actual task of developing software, although (cough) both are convenient if your primary use of open source is as a marketing tool.
I'm sure Marshall McLuhan would have a few things to say about GitHub if he were alive today.
Elitist approach to bug reporting is wrong, at least that's my opinion. Unless project maintainers indeed don't care about bug reports and just do whatever. But then it's more arrogance than actual benefit to the user.
I think more projects suffer from under reporting of bugs than from too many bugs reported.
And if no one is fixing bugs, then the above doesn't matter anyway.
You're being really ungenerous here, saying their bug tracking system is "broken", their use of it is "elitist", they "don't care about bug reports" and they're guilty of "arrogance". I don't think you can substantiate any of this just from the fact that they use Trac.
You (well, maybe not you, but one) can also imagine all kinds of counter-arguments (not that I know if any of these are true or not):
- Devs would rather spend their time on development
- No one is inspired to move the system over
- They have automations or conventions built on Trac
- Their super users (prolific users, testers, and engineers) are all used to Trac
- People use RSS feeds (Trac has lots of RSS feeds) to stay informed or build other tools, which would all have to be migrated and might have incompatible formats
I encourage you to be more open-minded about the way others choose to work. We shouldn't overemphasize homogeneity in work processes. I also encourage you to be more generous with the words you choose.
To clarify, I'm not saying it's arrogance in this particular case, but answering the above comment which claims there is no need for better bug reporting experience. That kind of attitude is arrogance I think.
All projects can have practical limitations and migrating the bug tracker is still work of course. But ignoring or even denying the fact that current experience is far from perfect is wrong.
Given the limited resource at the disposal of an open source project team, they need to pick their battles carefully to produce the most value with the least resources.
For a mature project such as FFmpeg, migrating to a new bug tracking system may produce some value to a small set of people who are reporting bugs, but for the vast majority of FFmpeg users, it produces no value.
So in this particular case it seems like they are willing to sacrifice the convenience of a small subset of users in the interest of the whole user community.
This applies to many mature and long running projects.
They can choose whatever priorities of course, but I'd disagree that it's not impacting anyone besides a small portion of the users. Discouraging bug reports reduces quality for everyone.
Those who report bugs might be a smaller portion, but projects need them I'd argue way more than those who use and never report anything to them.
I'd encourage browsing their Trac for context.. the handful of regular contributors definitely don't need any extra bug reporters
This kind of argument is exactly what I described above as an arrogant attitude. Not sure if developers actually use that in this case, but if some projects do - it's not a good thing at all.
don't know Trac, but can you import your history from it into Gitlab?
Haven't looked into it, but in the worst case making some custom tool would do it.
Ok maybe, but maybe the devs wouldn't feel that was that great a user of their time which might already be limited by other obligations.
But I guess someone else has already done it https://451.sh/post/tracboat/
So... what is so much different about it from 4.x?
Looks like a lot of new codecs and filters, but no breaking changes?
I'm not sure if ffmpeg follows semver at all. I thought their API was pretty stable after the big change from "next_video_frame" (or whatever it was called) to the send/receive packet/frame model.
Did you click the link?
Not the parent but the link is quite opaque. I'd really like it if someone more familiar with the project could explain what these changes mean, which ones are exciting and why and whether there were any interesting challenges that were overcome.
Something like that: http://www.jbkempf.com/blog/post/2022/FFmpeg-5.0
Indeed. At work, I find that doing a little bit of curation on the merged PRs makes for more much readable & relevant release notes.
I did, but none of those lines in the changelog mean anything to me, none look like important or major, because I'm not a specialist of this project, so from this link I don't know what makes the change from 4.x to 5.0, but I'd like to know, I use FFmpeg from time to time, and I'm genuinely curious
Could you explain what you did see in that link in a few simple words?
Do these lines mean new, modified or removed?