[FFmpeg-devel] Re: [PATCH v2] avformat/wavenc: use RF64 when needed

[Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2584 bytes --]

Hi Jason

On Wed, Dec 31, 2025 at 02:08:12PM +0100, Jason A. Donenfeld via ffmpeg-devel wrote:
> Currently if you encode a large wav, ffmpeg will hint after the fact
> that the resultant file is corrupted, because traditional wav cannot
> handle lengths greater than 32-bits. This isn't very useful; nobody
> benefits from getting garbage files.
> 
> You can manually work around this by adding `-rf64 always`, which most
> players have support for. Most people don't remember to do this until
> after the fact when their file is corrupted, or they don't figure it out
> at all and wind up using the w64 container instead.
> 
> And so that's what `-rf64 auto` is for. It uses the larger format when
> needed, and if not, uses the traditional wav that is probably more
> compatible. The result of using `-rf64 auto` is that you can add it to
> every command line -- and should add it to every command line -- to get
> either a normal small file, or a non-corrupt large file.
> 
> This is a very sensible default to have on, rather than just producing
> corrupt files and having users scrambling for solutions, and then having
> to do a potentially expensive reencode after. With `-rf64 auto` on by
> default, the user always gets a readable good file. And for users who
> sometimes want corrupt files, there still exists `-rf64 never` that can
> be enabled.
> 
> The fate changes needed to be regenerated, though, because this does
> change the size of the normal non 64-bit RIFF header, because the `-rf64
> auto` code path still makes room for it, even if it doesn't wind up
> being used. Though some old buggy players relied on having fixed 44-byte
> RIFF headers, those old buggy players actually haven't worked with
> ffmpeg's wav files for a long time anyway, even in `-rf64 no` mode,
> because ffmpeg adds the ISFT filed for the libavformat version. So this
> patch shouldn't make any difference in terms of current compatibility.

still breaks some fate tests:

make  fate-fifo-muxer-wav
TEST    fifo-muxer-wav
--- -	2026-01-03 01:08:49.377174061 +0100
+++ tests/data/fate/fifo-muxer-wav	2026-01-03 01:08:49.371683543 +0100
@@ -1 +1 @@
-4dda5dcc7ecdc2218b0739a152ada802
+c9a1921dfda2531b52b48f268936e0d7
Test fifo-muxer-wav failed. Look at tests/data/fate/fifo-muxer-wav.err for details.
make: *** [tests/Makefile:323: fate-fifo-muxer-wav] Error 1

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org