[FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.
Dale Curtis
dalecurtis at chromium.org
Mon Aug 7 22:31:01 EEST 2017
On Fri, Aug 4, 2017 at 4:40 PM, Rodger Combs <rodger.combs at gmail.com> wrote:
> + sc->ctts_data = av_fast_realloc(sc->ctts_data,
> &sc->ctts_allocated_size, request_size);
> ^ this line is incorrect; setting realloc's first arg to its return value
> leaks the existing allocation in the OOM case. Since you're doing your own
> calculation for the desired new size here, you may want to use av_reallocp
> (which frees the original allocation on failure).
>
Thanks, fixed; kept av_fast_realloc() for size setting simplicity, but
reused function-scope ctts_data as temporary.
>
> When reading a trun that requires this sort of realloc, is it common for
> there to be any existing entries in the range we're writing? Would it be
> safe to remove+replace them? Could we do a single realloc + single memmove,
> and then fill the newly-opened space, rather than repeating the memmove for
> each entry?
>
Yes it's common for their to be existing entries. To be clear this occurs
with standard files that are of sufficient length that a seek can occur
before all trun boxes are read. We could speculatively move all entries
based on the first insert and total entries count, but their are several
conditionals in av_add_index_entry() which may cause a bail out and such
failure would be unrecoverable (maybe painfully?) if we moved everything
ahead of time.
- dale
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctts_fix_v7.patch
Type: text/x-patch
Size: 23882 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170807/00da5f06/attachment.bin>
More information about the ffmpeg-devel
mailing list