On Tue, Dec 30, 2025 at 3:17 AM Jason A. Donenfeld <[email protected]> wrote: > > Hi Daniel, > > On Tue, Dec 30, 2025 at 5:50 AM Daniel Verkamp <[email protected]> wrote: > > I am not opposed to changing the default, but I recall there were some > > reports of problems[1] when ffmpeg began to stray from the "classic" > > WAV file layout. > > > > The `-rf64 auto` option adds an extra junk chunk near the beginning of > > the file, before the "fmt " chunk, to reserve space for the extended > > header if needed. > > This is not what `-rf64 auto` does, and I think your reply might be > skipping an important step. Namely, `-rf64 auto` only goes into riff64 > mode when there's no way to construct a valid wav32 to hold the data.
Right, the RIFF to RF64 conversion and creation of the ds64 chunk only happen as needed in `-rf64 auto` mode. However, it still changes the file layout even when the RF64 conversion doesn't trigger (see below). I did actually intend to make `-rf64 auto` the default when the RF64 support was originally added, but it got merged with `-rf64 never` as default instead (https://ffmpeg.org/pipermail/ffmpeg-devel/2013-February/138901.html) and I never got around to changing it. I think it's probably reasonable to change it now, but I wanted to add some minor clarifications below about the potential compatibility issue I was discussing. > So, here are the effects of the different settings: > > - `-rf64 no`: makes a valid wav file, unless it's too long, and then > it produces a corrupt file that can't be played anywhere. *This > corruption-producing behavior is the current bad default.* It is actually readable in some software (including ffmpeg itself when using `-ignore_length 1`, although this is not the default), so the data is not truly lost, but I agree it is generally better to do the right thing by default, assuming it doesn't cause other problems. > - `-rf64 yes`: always makes a riff64 file, which these days generally > has universal support, but ys, at some point long long ago, there were > some old players that didn't know about it. *This is _not_ the option > I'm proposing we make default.* Right, and I don't think it would ever make sense to make this the default for the WAV muxer, since it would not produce actual WAV files matching the Microsoft spec anymore at that point. This option only really exists to make testing RF64 support easier (without needing a gigantic test file). > - `-rf64 auto`: make a valid wav file if it can do so, but then, if it > can't, rather than producing a corrupt output file, make a riff64 > file, so that it'll still be playable in 99% of the places. *This is > what I'm proposing we turn on by default." > > So, as you can see, `-rf64 auto` is strictly better than the status > quo, offering no drawback. It produces a riff64 file only in the case > when ffmpeg would _otherwise generate a corrupt unplayable file_. The compatibility issue I mentioned is not related to the RIFF versus RF64 format change (which only triggers for large files, as you mentioned); it's that adding the extra reserved space for the potentially-needed RF64 header extension, which always happens in `-rf64 auto` mode even if the file ends up being a normal WAV and not RF64, causes the headers prior to the audio data to not be the exact 44-byte size expected by (buggy) software. In addition to the ffmpeg mailing list thread I mentioned before, there's another mention of this in https://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html - "Some programs (naively) assume that for PCM data, the preamble in the file header is exactly 44 bytes long" - so presumably this shortcut has been independently reinvented more than once. That said, I think it's fair to say that switching to `-rf64 auto` by default won't cause further compatibility problems due to breaking the 44-byte header assumption, because current ffmpeg already doesn't generate such files (although it did at some point in the distant past). WAV files generated by the ffmpeg CLI now have a "ISFT" chunk containing the libavformat version, so the header won't be the magic 44-byte size regardless of whether the extra reserved-for-ds64 padding is added. In other words, any supposed compatibility improvements we'd get by trying to stick with the expected "classic" layout were already lost when the encoder metadata was added; I should have peeked in a hex editor rather than relying on my recollection. :) So in summary, I think switching to `-rf64 auto` by default is fine. It just needs a FATE reference update as Michael mentioned; `make fate-rsync` to get the samples and then `make fate GEN=1` should take care of most of the necessary updates. Thanks, -- Daniel _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
