[FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.
Carl Eugen Hoyos
ceffmpeg at gmail.com
Fri Nov 24 01:54:25 EET 2017
2017-11-23 19:45 GMT+01:00 John Stebbins <stebbins at jetheaddev.com>:
> On 11/22/2017 05:26 PM, Carl Eugen Hoyos wrote:
>> 2017-11-23 1:30 GMT+01:00 John Stebbins <stebbins at jetheaddev.com>:
>>> On 11/22/2017 02:36 PM, Carl Eugen Hoyos wrote:
>>>> 2017-08-24 0:39 GMT+02:00 Dale Curtis <dalecurtis at 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
>>>> 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.
Could you do that?
Thank you, Carl Eugen
More information about the ffmpeg-devel