A major release, ffmpeg 7.0, has been out since Friday: https://ffmpeg.org/
Changelog: https://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=Changelog;hb=n7.0
Audio-specific: QOA decoder.
Not unikely there are some details to existing encoders/decoders too.
(And I haven't paid enough attention to know that -map_channel has been deprecated, until now that it is removed.)
One of the major changes in this release is the inclusion of multithreading in the command line tool (https://ffmpeg.org/#cli_threading).
Thanks to a major refactoring of the ffmpeg command-line tool, all the major components of the transcoding pipeline (demuxers, decoders, filters, encodes, muxers) now run in parallel. This should improve throughput and CPU utilization, decrease latency, and open the way to other exciting new features.
Note that you should not expect significant performance improvements in cases where almost all computational time is spent in a single component (typically video encoding).
This is probably pretty useful for audio, especially when working with symmetric codecs: decoding and encoding can now run in parallel if I understand this correctly.
Its is fake news by former LibAV devs and similar ... that completely overtoke current "FFmpeg" project by force, also the performance just got worse with that "refactoring", specially with audio formats with small numbers of encoded/stored (raw or compressed) samples per single packet.
Audio-specific: QOA decoder.
I'm pretty glad that the HA community - like, I imagine, the Doom9 one for video side - is given due consideration by FFMPEG...
BTW, any new version of ffmpeg can have unpredictable bugs, because there actually are no release versions, no release candidates, no betas, no alfas. ffmpeg team is in constant process of fixing old bugs, adding new features and adding new bugs.
Yes, they even reintroduce old bugs all over again.
Use librempeg instead.
Use librempeg instead.
It also uses ffmpeg. Older version, though. Is there something not written on their github that I'm missing?
Changelog file will be updated soon. Its not source of truth. The commits are.
This seems like OpenSSL vs LibreSSL. In the end, OpenSSL won.
ffmpeg is too widespread at this point to be replaced by a fork.
That is just your opinion/perspective/statement/thought.
@mycroft I sent a PR your way. Please close it with a disparaging comment 8). Potential contributors should see that PRs are being looked at. Maybe they will start coming with contributions that should actually be merged.
Also, some IRC presence would help. At least register the channels if you're really in it for the long haul.
ffmpeg has had a schism back in the day, and to those who don't know how that turned out: https://en.wikipedia.org/wiki/Libav
If someone makes a tool that does work different by default where ffmpeg does something stupid, then that could get a userbase in the right community. For example I can imagine that a small pack of lossless enthusiasts could want something that by default maintains losslessness when converting between lossless formats.
By that, I mean that conversion between lossless formats (including uncompressed) keeps bit depth (cf. e.g. this thread) (https://hydrogenaud.io/index.php/topic,125759.0.html) - including honouring valid bits per sample; keeps alignment and length when encapsulating in container; and not to forget, can read every file it creates.
What if conversion cant be done if format have no support with certain bitdepths. It is low level tool. Feel free to write wrapper that is smarter and actually does what you want.
About FDK pull request - its not proper way and beside you can already disable native aac decoders. PS: maybe LibAV devs will finally write AAC USAC support into native decoder, but do not hold your breath.
Yes, they even reintroduce old bugs all over again.
Use librempeg instead.
Does Librempeg exist as a binary for Windows 7 x64? I am not a developer to build it properly myself. Whereas various FFMPEG binaries, including version 7, exist in abundance (https://www.animmouse.com/p/ffmpeg-binaries/), and some of them are even compiled automatically, without requiring constant attention from the maintainer. For example, that's what I'm using now.
$ ffmpeg.exe
ffmpeg version N-114795-g0e4dfa470-2024-04-10-nonfree Copyright (c) 2000-2024 the FFmpeg developers
built with gcc 14.0.1 (GCC) 20240127 (Fedora MinGW 14.0.1-1.fc40)
configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-config=pkg-config --cross-prefix=x86_64-w64-mingw32ucrt- --arch=x86_64 --target-os=mingw32 --enable-gpl --enable-version3 --disable-debug --disable-doc --enable-nonfree --extra-version=2024-04-10-nonfree --disable-w32threads --enable-pthreads --enable-iconv --enable-libxml2 --enable-zlib --enable-libfreetype --enable-libfribidi --enable-gmp --enable-libharfbuzz --enable-libfontconfig --enable-libvorbis --enable-opencl --enable-libvmaf --enable-amf --enable-avisynth --enable-chromaprint --enable-libdav1d --enable-libdavs2 --enable-decklink --enable-libdvdread --enable-libdvdnav --enable-ffnvcodec --enable-cuda-llvm --enable-libgme --enable-libkvazaar --enable-libaribcaption --enable-libass --enable-libbluray --enable-libfdk-aac --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librist --enable-libtheora --enable-vaapi --enable-libvpx --enable-libwebp --enable-libzmq --enable-libvpl --enable-openal --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-libssh --enable-libsrt --enable-librav1e --enable-librubberband --enable-schannel --enable-sdl2 --enable-libsoxr --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d --enable-libvidstab --enable-vulkan --enable-libshaderc --enable-libplacebo --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libzimg --enable-libzvbi --extra-cflags='-fpermissive -DLIBTWOLAME_STATIC' --extra-cxxflags= --extra-ldflags= --extra-libs=
libavutil 59. 13.100 / 59. 13.100
libavcodec 61. 5.101 / 61. 5.101
libavformat 61. 3.100 / 61. 3.100
libavdevice 61. 2.100 / 61. 2.100
libavfilter 10. 2.101 / 10. 2.101
libswscale 8. 2.100 / 8. 2.100
libswresample 5. 2.100 / 5. 2.100
libpostproc 58. 2.100 / 58. 2.100
About FDK pull request - its not proper way and beside you can already disable native aac decoders. PS: maybe LibAV devs will finally write AAC USAC support into native decoder, but do not hold your breath.
That's the comment I expected to see in GitHub closing/NACKing the PR (maybe with some telling off for doing that in
avformat_find_stream_info()). That's what potential contributors via Github would expect from a maintainer, especially considering that you mention in the README that GH PRs is the workflow contributors should follow.
There are more builds out there with native AAC alone, some with both native and FDK, and almost none with FDK and without native. The error/warning message users get is also very much useless.
Me, you, and many here obviously know what the problem is, and know how to somehow fix it. But if you need librempeg to be a good choice, the preferable choice even, for many users, then a different mindset and approach is probably needed.
And on the API level, a generic solution would probably require better support for trying multiple decoders supporting the same codec id. This should become even more relevant now that there is talk of external
"modules" and
"plugin system".
What if conversion cant be done if format have no support with certain bitdepths.
Err out!
Instead of clipping the signal and pretending everything is OK - that is like when Excel pretended it could do ANOVA and happily delivered negative variances.
If I try to fit PCM into FLAC or WavPack, then all common sense says I want it to be lossless unless I specifically tell it to alter the signal.
Its is fake news by former LibAV devs and similar ... that completely overtoke current "FFmpeg" project by force, also the performance just got worse with that "refactoring", specially with audio formats with small numbers of encoded/stored (raw or compressed) samples per single packet.
Is that really true... LibAV devs taking over FFMpeg development? LibAV website lies abandoned for years now.. how did they manage that esp given their complaint that the guy who runs the whole thing is rather "opinionated"?
More ex-LibAV devs (but not all LibAV devs did this, this is the difference) infiltrated FFmpeg project not long ago, taking under control the CC and TC committee. Just take a look core FFmpeg developers now and core LibAV developers then.
Now that they took control they will force LibAV flawed policies into FFmpeg including also bugs and broken/misdesigned features and APIs.
7.0.1 out. Changelog (https://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=Changelog;hb=n7.0.1) indicates it is mostly fixes.
Mostly "fixes".
Could someone please explain what is wrong with new versions of ffmpeg? Should we use 6.1 or 7.0 or 7.0.1 or older versions? I heard that there were/are some personal issues but do those affect the product in any way?
I heard that there were/are some personal issues but do those affect the product in any way?
YES.
they always do.
if you want more info just wait for mycroft's reply.
Could someone please explain what is wrong with new versions of ffmpeg? Should we use 6.1 or 7.0 or 7.0.1 or older versions? I heard that there were/are some personal issues but do those affect the product in any way?
It goes more into corporate network bubble with making personal networking between current devs and their business and various corporations.
Its mostly now low-effort, by state sponsored maintenance work over auto-detected issues in source code - of questionable outcomes and benefit.
Still extreme low effort is taken on fixing user reported regressions and bug fix/feature requests reports. And new features are limited or buggy in some usecases.
There is some cool and nice stuff, like cleanups and refactoring but net results is still negative.
"state sponsored"... surely you do mean dictatorship governments where one voice matters over all, right?
May 13th news from ffmpeg.org:
The FFmpeg community is excited to announce that Germany's Sovereign Tech Fund (https://www.sovereigntechfund.de/tech/ffmpeg) has become its first governmental sponsor. Their support will help sustain the maintainance of the FFmpeg project, a critical open-source software multimedia component essential to bringing audio and video to billions around the world everyday.
Not quite Putin.
[...]
Its mostly now low-effort, by state sponsored maintenance work over auto-detected issues in source code - of questionable outcomes and benefit.
[...]
There is some cool and nice stuff, like cleanups and refactoring but net results is still negative.
And yet, of the 1775 patches that went into ffmpeg (https://github.com/FFmpeg/FFmpeg/graphs/contributors?from=2023-12-30&to=2024-05-29&type=c), you used 1376 in librempeg (https://github.com/librempeg/librempeg/graphs/contributors?from=2023-12-30&to=2024-05-29&type=c), if my counts are correct. That doesn't seem like "mostly fixes of questionable outcomes and benefits" nor "some cool and nice stuff but net result negative" to me.
Its mostly now low-effort, by state sponsored maintenance work over auto-detected issues in source code - of questionable outcomes and benefit.
…
net results is still negative.
That's an extraordinary claim needing specific examples.
Are you trying to say that it's better to leave the auto-detected issues unsolved? Even those potentially exploitable? Which is what fuzzing/static analysis tools are mostly trying to find.
[...]
Its mostly now low-effort, by state sponsored maintenance work over auto-detected issues in source code - of questionable outcomes and benefit.
[...]
There is some cool and nice stuff, like cleanups and refactoring but net results is still negative.
And yet, of the 1775 patches that went into ffmpeg (https://github.com/FFmpeg/FFmpeg/graphs/contributors?from=2023-12-30&to=2024-05-29&type=c), you used 1376 in librempeg (https://github.com/librempeg/librempeg/graphs/contributors?from=2023-12-30&to=2024-05-29&type=c), if my counts are correct. That doesn't seem like "mostly fixes of questionable outcomes and benefits" nor "some cool and nice stuff but net result negative" to me.
Such reasoning is flawed. There is no correlation between number of new commits since some fixed period and quality of project itself.
Extreme reductions lead to lies.
Its mostly now low-effort, by state sponsored maintenance work over auto-detected issues in source code - of questionable outcomes and benefit.
…
net results is still negative.
That's an extraordinary claim needing specific examples.
Are you trying to say that it's better to leave the auto-detected issues unsolved? Even those potentially exploitable? Which is what fuzzing/static analysis tools are mostly trying to find.
Trying and actually fixing are different sets.
Net results is negative because today trends only goes down for the project.
Once upon in time FFmpeg had Gold Era in development, that time is long gone and forgotten.
(https://files.ekmcdn.com/soccertackle/images/goal-post-transporter-wheels-small-for-lightweight-80mm-goals-9152-p.jpg?v=da226c13-3e40-466b-a583-129bb931c18a)
Extra wheels available.
There is no correlation between number of new commits since some fixed period and quality of project itself.
Extreme reductions lead to lies.
Yes, but that is not what I was saying. I wasn't implying any relationship between number of commits and quality of projects.
I was just noting that looking at the commits went into ffmpeg, about 75% of those were also applied to librempeg. So, apparently, 75% of the commits that went into ffmpeg were 'good' as they went into librempeg as well.
Dunno from where you got such "statistics" but I pushed almost all commits from FFmpeg, minus commits that touch code that got removed from Librempeg.