Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FFmpeg 7.0 "Dijkstra" released 2024-04-05 (Read 2120 times) previous topic - next topic - Topic derived from ffmpeg 6.1 released 2...
0 Members and 1 Guest are viewing this topic.

FFmpeg 7.0 "Dijkstra" released 2024-04-05

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.)

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #1
One of the major changes in this release is the inclusion of multithreading in the command line tool.

Quote
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.
Music: sounds arranged such that they construct feelings.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #2
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.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #3
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...
Hybrid Multimedia Production Suite will be a platform-indipendent open source suite for advanced audio/video contents production.
Official git: https://www.forart.it/HyMPS/

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #4
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.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #5
Yes, they even reintroduce old bugs all over again.

Use librempeg instead.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #6
Use librempeg instead.

It also uses ffmpeg. Older version, though. Is there something not written on their github that I'm missing?
Error 404; signature server not available.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #7
Changelog file will be updated soon. Its not source of truth. The commits are.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #8
This seems like OpenSSL vs LibreSSL. In the end, OpenSSL won.
ffmpeg is too widespread at this point to be replaced by a fork.
Allegari nihil et allegatum non probare, paria sunt.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #9
That is just your opinion/perspective/statement/thought.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #10
@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.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #11
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) - including honouring valid bits per sample; keeps alignment and length when encapsulating in container; and not to forget, can read every file it creates.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #12
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.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #13
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, and some of them are even compiled automatically, without requiring constant attention from the maintainer. For example, that's what I'm using now.

Code: [Select]
$ 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
  
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #14
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".

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #15
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.

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #16
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"?

 

Re: FFmpeg 7.0 "Dijkstra" released 2024-04-05

Reply #17
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.