[FFmpeg-devel] Bug in libavformat/mov.c?
Wed Jul 9 19:27:29 CEST 2008
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?
mans at mansr.com
More information about the ffmpeg-devel