From: anders-mjoll via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
To: ffmpeg-devel@ffmpeg.org
Cc: anders-mjoll <code@ffmpeg.org>
Subject: [FFmpeg-devel] [PATCH] avformat/mov: fixed bug in mov_merge_tts_data (PR #21234)
Date: Thu, 18 Dec 2025 18:12:54 -0000
Message-ID: <176608157478.60.13191221660969304830@2cb04c0e5124> (raw)
PR #21234 opened by anders-mjoll
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21234
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21234.patch
After upgrading to FFmpeg 8.0 (from FFmpeg 5.1.2) we got some customers reporting that FFmpeg consumed all the memory of the machine and was eventually killed by the OS. I was able to track it down to the MOV demuxer not producing any audio packets and the filter graph just caching up all the video frames from the 70 GB MOV file. This in turn appears to be because the index is never built for the audio stream. The reason it doesn't get built is because it fails the following check in `mov_merge_tts_data`:
```
if (!sc->sample_count || sc->sample_count >= UINT_MAX / sizeof(*sc->tts_data))
return -1;
```
This happens because this MOV file contains PCM and in that case it appears that the `sc->sample_count` is equal to the actual number of PCM samples not the number of entries in the `stts` and `ctts` tables. This PR fixes this issue by first obtaining the actual number of entries required by the ctts and stts tables.
Unfortunately the file that triggers this problem is 70 GB and also contains sensitive customer data so I cannot provide a sample to reproduce the problem.
>From 0c2d59273ba09c73a97fee64e86aa190367228b8 Mon Sep 17 00:00:00 2001
From: Anders Rein <anders@onemimir.com>
Date: Thu, 18 Dec 2025 18:59:17 +0100
Subject: [PATCH] avformat/mov: fixed bug in mov_merge_tts_data
Calculate the actual required size for the tts_data array instead of
assuming sc->sample_count reflect the number of entries in the stts/ctts
tables. This assumption does not hold for certain MOV files with PCM
audio.
---
libavformat/mov.c | 32 +++++++++++++++++++++++++-------
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 009ddfec80..be86878486 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4637,25 +4637,43 @@ static int mov_merge_tts_data(MOVContext *mov, AVStream *st, int flags)
int ctts = sc->ctts_data && (flags & MOV_MERGE_CTTS);
int stts = sc->stts_data && (flags & MOV_MERGE_STTS);
int idx = 0;
+ unsigned int ctts_total_count = 0;
+ unsigned int stts_total_count = 0;
+ unsigned int tts_count = 0;
if (!sc->ctts_data && !sc->stts_data)
return 0;
+
+ if (sc->ctts_data) {
+ for (unsigned int i = 0; i < sc->ctts_count; i++) {
+ ctts_total_count += sc->ctts_data[i].count;
+ }
+ }
+
+ if (sc->stts_data) {
+ for (unsigned int i = 0; i < sc->stts_count; i++) {
+ stts_total_count += sc->stts_data[i].count;
+ }
+ }
+
+ tts_count = FFMAX(ctts_total_count, stts_total_count);
+
// Expand time to sample entries such that we have a 1-1 mapping with samples
- if (!sc->sample_count || sc->sample_count >= UINT_MAX / sizeof(*sc->tts_data))
+ if (!tts_count || tts_count >= UINT_MAX / sizeof(*sc->tts_data))
return -1;
if (ctts) {
sc->tts_data = av_fast_realloc(NULL, &sc->tts_allocated_size,
- sc->sample_count * sizeof(*sc->tts_data));
+ tts_count * sizeof(*sc->tts_data));
if (!sc->tts_data)
return -1;
memset(sc->tts_data, 0, sc->tts_allocated_size);
for (int i = 0; i < sc->ctts_count &&
- idx < sc->sample_count; i++)
+ idx < tts_count; i++)
for (int j = 0; j < sc->ctts_data[i].count &&
- idx < sc->sample_count; j++) {
+ idx < tts_count; j++) {
sc->tts_data[idx].offset = sc->ctts_data[i].offset;
sc->tts_data[idx++].count = 1;
}
@@ -4669,7 +4687,7 @@ static int mov_merge_tts_data(MOVContext *mov, AVStream *st, int flags)
idx = 0;
if (stts) {
MOVTimeToSample *tts_data = av_fast_realloc(sc->tts_data, &sc->tts_allocated_size,
- sc->sample_count * sizeof(*sc->tts_data));
+ tts_count * sizeof(*sc->tts_data));
if (!tts_data)
return -1;
@@ -4678,9 +4696,9 @@ static int mov_merge_tts_data(MOVContext *mov, AVStream *st, int flags)
sc->tts_data = tts_data;
for (int i = 0; i < sc->stts_count &&
- idx < sc->sample_count; i++)
+ idx < tts_count; i++)
for (int j = 0; j < sc->stts_data[i].count &&
- idx < sc->sample_count; j++) {
+ idx < tts_count; j++) {
sc->tts_data[idx].duration = sc->stts_data[i].duration;
sc->tts_data[idx++].count = 1;
}
--
2.49.1
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
reply other threads:[~2025-12-18 18:13 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=176608157478.60.13191221660969304830@2cb04c0e5124 \
--to=ffmpeg-devel@ffmpeg.org \
--cc=code@ffmpeg.org \
/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