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 ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
