[FFmpeg-user] ProRes (LT) Quicktimes: Good for Windows. Not so good for Mac.

[Thomas Worth]

>> Also it should be noted that the media performance warning does not
>> occur when QuickTime files are written with a co64 atom. So, Final Cut
>> apparently likes FFmpeg MOV files written with 64 bit offsets.
>
> Could you explain the "co64 atom" thing a bit? I don't know what co64 atom
> is. Is it possible for FFMPEG to write ProRes QTs with a co64 atom or
> is that related to some other codec?

The co64 atom is only used when the file is over 4GB. The reason is
because an unsigned 32 bit value (e.g. uint32_t, which is 4 bytes)
simply isn't big enough to hold a number over 4294967295. Sometimes
the file is so big that the position of data relative to the beginning
of the file goes past 4294967295, so without a 64 bit value (i.e.
int64_t, which is 8 bytes), the file reader hits the 4GB limit and
doesn't have any more numbers to seek over 4GB. This is a common
limitation in computing in general and affects everything, most
notably the FAT32 filesystem.


>> Someone might take a gander at movenc.c and see if interleaving is
>> done differently with 64 bit MOV offsets vs. 32 bit ones.
>
> Does this 32/64-bit offsets related to the OS or can a 64-bit MOV offset
> be written from a 32-bit OS? Don't know if it matters but we're using the
> 64-bit FFMPEG.

The way the program is compiled doesn't have anything to do with it. A
32 bit ffmpeg binary can still read/write 64 bit QuickTime files. If
it couldn't, then the file size would be limited to 4GB.


>>>  Yes, this is because FCP expects audio chunks to be approximately
>>>  48000 samples.
>>>
>
> Could you get around this issue by supplying a null stream for the audio
> and setting -ar 48000? I can't test the /dev/zero because I'm on Windows
> and I don't know if there is a /dev/zero equivalent (I tried null w/o luck).

This doesn't work. The problem is with movenc.c, and possibly other
source files.

It should also be pointed out that MOV/MP4 elst atoms aren't written
properly in many cases, at least not in a way that Apple's software
expects them. For example, sometimes the start value in elst will be
wrong if performing stream copies with B-frame'd H.264. The fix is to
go into a hex editor and change the start value to 1 or 1001,
depending on the PTS duration. ffmbc isn't affected by this since
Baptiste has taken the time to ensure the MOV/MP4 writer works in a
way that Apple software expects. IMHO, someone should follow ffmbc's
good example and fix the MOV muxer in ffmpeg, at least to the point
where it addresses these issues. It'd be a pretty hard sell to
convince me that writing MOVs/MP4s that are incompatible with software
from the same company that invented the format in the first place is
acceptable. Not to bash the effort that's been put into this, of
course. avformat is a fabulous piece of software, it just could be a
LITTLE better... :-)

Baptiste, what would it take to fix these issues in ffmpeg? Would the
changes be limited to movenc or would changes elsewhere need to be
made as well?

I would gladly fix this myself and submit patches, but unfortunately I
don't know avformat well enough to not utterly break it to oblivion!