[FFmpeg-devel] Bug in libavformat/mov.c?

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Wed, Jul 09, 2008 at 01:24:45PM +0100, M?ns Rullg?rd wrote:
>> 
>> Ivan Zezyulya wrote:
>> >
>> > The problem is that I have a .mov file, VERY large file (101GB), and it
>> > has more than UINT_MAX / sizeof(int) entries in one of its sample size
>> > tables. After reaching the above lines with check of "entries" variable,
>> > ffmpeg recursively quits reading .mov file and reports "error reading
>> > header" (in mov_read_header function in libavormat/mov.c:1743) and then
>> > quits. The file itself is correct, the QuickTime player can successfully
>> > play it.
>> 
>> The proper way to handle such files is, IMHO, to load the sample sizes
>> in smaller chunks as needed, based on the current playback position.
>> Loading them all would require an insane amount of memory.  This could
>> be done either by seeking and reading, or (if virtual address space
>> allows), by mmap()ing that section of the file, and let the OS take
>> care of the caching.
>
> theres an additional complication with that, mov allows these headers to
> be zlib compressed IIRC, that would likely complicate random access
> considerably ...

Yes, random access in zlib compressed data is impossible.  For linear
playback, one could of course uncompress a reasonably-sized chunk at a
time, and discard the used data.  Does anyone know how Quicktime
player handles such files?

-- 
M?ns Rullg?rd
mans at mansr.com