On 11/22/2017 02:36 PM, Carl Eugen Hoyos wrote: > 2017-08-24 0:39 GMT+02:00 Dale Curtis <dalecur...@chromium.org>: > >> - sc->ctts_data[ctts_count].count = count; >> - sc->ctts_data[ctts_count].duration = duration; >> - ctts_count++; >> + /* Expand entries such that we have a 1-1 mapping with samples. */ >> + for (j = 0; j < count; j++) >> + add_ctts_entry(&sc->ctts_data, &ctts_count, >> &sc->ctts_allocated_size, 1, duration); > count is a 32bit value read from the file, so this hunk makes > the demuxer allocate huge amount of memories for some > files. > > Is there an upper limit for count? > >
In practice, if a valid mp4 blows up due to this ctts allocation, it's also going to blow up when AVIndexEntries is allocated for the samples. An invalid mp4 can do anything of course. -- John GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01 83F0 49F1 D7B2 60D4 D0F7
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel