2017-11-23 19:45 GMT+01:00 John Stebbins <stebb...@jetheaddev.com>: > On 11/22/2017 05:26 PM, Carl Eugen Hoyos wrote: >> 2017-11-23 1:30 GMT+01:00 John Stebbins <stebb...@jetheaddev.com>: >>> 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. >> This is about invalid files allocating >1GB. > > Ah, ok. The practical limit would be the number of samples > (sc->sample_count). > But you can't be certain this is set before the ctts box is parsed (the value > is > determined when parsing stsz box). You can be certain it is set before > mov_build_index is called. So perhaps revert this part and then add code to > mov_build_index to expand the ctts_data entries there. This would solve the > invalid mp4 alloc issues while still preserving the fix for trampling of ctts.
@Dale: Could you do that? Thank you, Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
