PR #22931 opened by mcprat URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22931 Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22931.patch
Quick rant because this project needs to wake up a little: processing standard PCM tracks in large videos is completely broken without this. I don't understand why this was not already backported since it was available before 8.0.1, and it makes me question how stable the stable branches are, in other words, how many other critical fixes are overlooked on being backported. I spent weeks bisecting to figure out which one so I can help the project and have a working stable release instead of just using the master branch. Worth mentioning, the author of the regression has backported several commits of their own for the exact same file, but still overlooking this one. Does authorship decide whether fixes are important enough or noticeable? Maybe reading "old-style" threw all of you off into thinking this isn't important, meanwhile I have multiple videos from a new camcorder that I cannot transcode with audio intact. This is not a fix for an "old" type of PCM, its just normal PCM without a container, identified as: pcm_s16be (twos), 48000 Hz, 1 channel ~------------------------------------~ avformat/mov: Merge tts after building index for old-style uncompressed PCM This was a regression introduced in 292c1df7c159c8a1a7afe52613d164ff417e81ce. Since we don't know the length of the stts data until after building the index, since we're generating it, we need to merge any ctts data after, since otherwise tts_count is set to 0, and no packets will be output. We can't remove the merge entirely, because uncompressed PCM with a ctts atom is technically valid (e.g. a constant CTS offset). This fixes old-style uncompressed PCM demuxing. Fixes #11490. Signed-off-by: Derek Buitenhuis <[email protected]> (cherry picked from commit ae03b629db116a8a5b6b40ede912fbb8b1ca0175) >From 2c4c6bc5b14214840bd7a84acd48bc9858f1a903 Mon Sep 17 00:00:00 2001 From: Derek Buitenhuis <[email protected]> Date: Mon, 22 Sep 2025 20:00:54 +0100 Subject: [PATCH] avformat/mov: Merge tts after building index for old-style uncompressed PCM This was a regression introduced in 292c1df7c159c8a1a7afe52613d164ff417e81ce. Since we don't know the length of the stts data until after building the index, since we're generating it, we need to merge any ctts data after, since otherwise tts_count is set to 0, and no packets will be output. We can't remove the merge entirely, because uncompressed PCM with a ctts atom is technically valid (e.g. a constant CTS offset). This fixes old-style uncompressed PCM demuxing. Fixes #11490. Signed-off-by: Derek Buitenhuis <[email protected]> (cherry picked from commit ae03b629db116a8a5b6b40ede912fbb8b1ca0175) --- libavformat/mov.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 3fdf6d21f8..54eafa5e1c 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -4850,10 +4850,6 @@ static void mov_build_index(MOVContext *mov, AVStream *st) if (!sc->chunk_count || sc->tts_count) return; - ret = mov_merge_tts_data(mov, st, MOV_MERGE_CTTS); - if (ret < 0) - return; - // compute total chunk count for (i = 0; i < sc->stsc_count; i++) { unsigned count, chunk_count; @@ -4948,6 +4944,10 @@ static void mov_build_index(MOVContext *mov, AVStream *st) chunk_samples -= samples; } } + + ret = mov_merge_tts_data(mov, st, MOV_MERGE_CTTS); + if (ret < 0) + return; } if (!mov->ignore_editlist && mov->advanced_editlist) { -- 2.52.0 _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
