From: Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: Michael Niedermayer <michael@niedermayer.cc>
Subject: [FFmpeg-devel] Re: [PATCH] avformat/wavenc: use RF64 when needed
Date: Sun, 21 Dec 2025 04:08:04 +0100
Message-ID: <aUdklCi05339tlw0@neo> (raw)
In-Reply-To: <20251220212839.2451047-1-Jason@zx2c4.com>
[-- Attachment #1.1: Type: text/plain, Size: 3848 bytes --]
Hi Jason
On Sat, Dec 20, 2025 at 10:28:39PM +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.
> ---
> libavformat/wavenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
> index a515f4e2a2..835a2157bc 100644
> --- a/libavformat/wavenc.c
> +++ b/libavformat/wavenc.c
> @@ -487,7 +487,7 @@ static const AVOption options[] = {
> { "off", "Do not write peak chunk.", 0, AV_OPT_TYPE_CONST, { .i64 = PEAK_OFF }, 0, 0, ENC, .unit = "peak" },
> { "on", "Append peak chunk after wav data.", 0, AV_OPT_TYPE_CONST, { .i64 = PEAK_ON }, 0, 0, ENC, .unit = "peak" },
> { "only", "Write only peak chunk, omit wav data.", 0, AV_OPT_TYPE_CONST, { .i64 = PEAK_ONLY }, 0, 0, ENC, .unit = "peak" },
> - { "rf64", "Use RF64 header rather than RIFF for large files.", OFFSET(rf64), AV_OPT_TYPE_INT, { .i64 = RF64_NEVER },-1, 1, ENC, .unit = "rf64" },
> + { "rf64", "Use RF64 header rather than RIFF for large files.", OFFSET(rf64), AV_OPT_TYPE_INT, { .i64 = RF64_AUTO },-1, 1, ENC, .unit = "rf64" },
> { "auto", "Write RF64 header if file grows large enough.", 0, AV_OPT_TYPE_CONST, { .i64 = RF64_AUTO }, 0, 0, ENC, .unit = "rf64" },
> { "always", "Always write RF64 header regardless of file size.", 0, AV_OPT_TYPE_CONST, { .i64 = RF64_ALWAYS }, 0, 0, ENC, .unit = "rf64" },
> { "never", "Never write RF64 header regardless of file size.", 0, AV_OPT_TYPE_CONST, { .i64 = RF64_NEVER }, 0, 0, ENC, .unit = "rf64" },
breaks fate:
--- - 2025-12-21 04:04:18.901071242 +0100
+++ tests/data/fate/filter-channelmap-one-str 2025-12-21 04:04:18.898363748 +0100
@@ -1 +1 @@
-e18791f65ce5861e130b2c3e472ab90a
+8f8a664b694f18e1e9ae1b9ccfa6f30c
Test filter-channelmap-one-str failed. Look at tests/data/fate/filter-channelmap-one-str.err for details.
make: *** [tests/Makefile:323: fate-filter-channelmap-one-str] Error 1
if this change is intended, then update the fate tests and explain in the commit message
why they change
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once" - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
[-- 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
prev parent reply other threads:[~2025-12-21 3:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-20 21:28 [FFmpeg-devel] " Jason A. Donenfeld via ffmpeg-devel
2025-12-21 3:08 ` Michael Niedermayer via ffmpeg-devel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aUdklCi05339tlw0@neo \
--to=ffmpeg-devel@ffmpeg.org \
--cc=michael@niedermayer.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git