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

["Jason A. Donenfeld via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>]

Hi Daniel,

On Tue, Dec 30, 2025 at 5:50 AM Daniel Verkamp <daniel@drv.nu> 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.
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.*

- `-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.*

- `-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_.

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