On Fri, Jan 2, 2026 at 4:12 PM Michael Niedermayer via ffmpeg-devel <[email protected]> wrote: > > 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
Hi Jason, For the FATE error Michael mentioned, it looks like this test has a hard-coded REF = hash in a Makefile (tests/fate/fifo-muxer.mak) rather than an external ref file that can be automatically updated. It should be okay to update this REF to the expected hash if the file generated by the test command looks okay. (I didn't get a chance to look at this myself yet.) While doing some testing locally, I found one small design change I would like to make before switching to `-rf64 auto` by default. Currently, the auto mode places the JUNK chunk that is used to reserve space for ds64 at the beginning of the file, displacing the fmt chunk from its usual place; among other things, this breaks `file`, which no longer prints the format information: rf64-never.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz vs. rf64-auto.wav: RIFF (little-endian) data, WAVE audio Since `file` is a widely used tool, this seems worth fixing before committing to `-rf64 auto` by default. (Other tools have probably made the same assumption about fmt being first too.) Luckily, this is actually pretty easy to resolve by just shuffling the order of the chunks around and rewriting the fmt chunk if necessary; I sent a pull request for this: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21556 (I did some testing with smaller and larger than 4GB files, but more testing and extra eyes on the patch would be welcome). This layout modification will unfortunately change all of the ref hashes again when rf64 is auto, so the fate refs will need one more respin if this gets applied. Thanks, -- Daniel _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
