On 12/29/2017 1:10 AM, Carl Eugen Hoyos wrote:
> New patch attached, only tested with fate.

> +    if (INT_MAX / sizeof(*sc->stts_data) <= entries)
>          return AVERROR(ENOMEM);

Should probably be something thing AVERROR(EINVAL), I think.

> +    sc->stts_count = FFMIN(1024 * 1024, entries);

As stated in the past many times, I am not a fan of hardcoding arbitrary
max hard limits. It's the OS's job to handle large allocation issues, not
the library, for what could be perfectly valid files.

However, if we insist on doing it, I believe 1024 * 1024 is too low. Very
long MP4/MOV files are not as uncommon as you think; I have many many 10-20hr
MP4s and even a 55 hour one, and this hardcoded (i.e. unchangeable by the user)
would/could break such files with no way to fix them from the user-side.

> +            sc->stts_count = FFMIN(sc->stts_count * 2, entries);

This one seems especially sketchy to me... it can't be that odd of a scenario
to double the count.

In general, I am not a fan of arbitrary limits.

- Derek
ffmpeg-devel mailing list

Reply via email to