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 just dropped libwavpack encoder (Read 3956 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FFmpeg just dropped libwavpack encoder

FFmpeg authors have removed the libwavpack encoder, in favor of their internal Wavpack encoder.

Quote
[libwavpack encoder] supports less sample formats than the native encoder, is less efficient
than the native encoder and is also slower and pretty much remains untested.
libwavpack also isn't being fuzzed, which given that we plug the parameters
without any sanitizing them looks concerning.
https://github.com/FFmpeg/FFmpeg/commit/45070eec4c089b06947f07e25cdb1bc8b2102553#diff-32f299c378ca0b8c50690f95fc0e5b4e

I have not verified their claims, but I am skeptical given their past track record of promoting their internal encoders even when they are clearly inferior.
Does anybody know :
- If their encoder give the same bit exact output than libwavpack ?
- Is it also faster for single thread performance ? I remember for decoding, it was faster by aggressively multi threading
Opus 96 kb/s (Android) / Vorbis -q5 (PC) / WavPack -hhx6m (Archive)

Re: FFmpeg just dropped libwavpack encoder

Reply #1
When I first saw this mentioned on their mailing list I did some investigation because what they were saying really didn't make sense. Like how could it be faster and more flexible than the reference encoder, especially when it doesn't have the ASM optimizations? And unlike some of their encoders (and the WavPack decoder) it is not a rewrite; it's basically a copy of the libwavpack encoder with reformatting and a little refactoring.

A quick test showed that their native encoder is slower than libwavpack as used by the WavPack command-line encoder, and it doesn't do any multithreading or anything to run faster. That was as expected.

However, when I looked closer at their libwavpack interface code, I understand what they're talking about. It only uses the libwavpack encoder at 32-bit integer audio, regardless of the source format! That causes libwavpack to go through all kinds of hoops scanning the audio, which will slow it down significantly. And worse, the resulting WavPack audio files will be reported as 32-bit (I didn't verify that but it didn't seem like anything else could happen from the code I saw). And it didn't look like the multichannel configuration was done correctly either. Obviously I now agree with them that's there's no reason to use that configuration.

I considered offering to help them to improve that code so that libwavpack would be a viable alternative, but life is too short to spend time trying to submit patches to FFmpeg unless absolutely necessary, and their encoder works fine (since it's basically a copy of my code). It won't generate bit-identical output for several reasons, but the most obvious is that it doesn't have any of the WavPack 5.0 additions, like block checksums. But the decoded audio will be identical.

Re: FFmpeg just dropped libwavpack encoder

Reply #2
That's unfortunate, as FFmpeg is ubiquitous and having a suboptimal encoder going around misrepresents this brilliant CODEC.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

Re: FFmpeg just dropped libwavpack encoder

Reply #3
FFmpeg wavpack Encoder is not suboptimal in any way.
The wrapper encoder was suboptimal in any sense.

 

Re: FFmpeg just dropped libwavpack encoder

Reply #4
Wasn't it mostly down to the libwavpack frontend in FFmpeg being limited to always encoding 32 bit samples?