[FFmpeg-user] ProRes (LT) Quicktimes: Good for Windows. Not so good for Mac.
joddo at jerfu.com
Fri Mar 23 17:02:34 CET 2012
> 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.
Got it. Thanks for explaining.
> 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.
For what it's worth, I encoded a ProRes QT using ffmbc and had the
same issue (FCP not accepting the QT as ProRes (LT)). From your
text above, I wasn't sure if you were pointing out that ffmbc could make
"legal" ProRes (LT)'s or if you were merely saying that ffmbc deals with
B-frame'd H.264's properly. (I should note that I didn't have an audio track
if that is an issue.)
More information about the ffmpeg-user