[FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Carl Eugen Hoyos]

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
>>>> 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