How do I prevent FCP crash with divide-by-0 when playing clip?

Question

Level 1

0 points

How do I prevent FCP crash with divide-by-0 when playing clip?

One of my customers asked if I could modify a clip so that FinalCutPro 7.0.3 could play it without crashing. I've been testing FCP's sensitivity to a number of variables, and finally generated two clips which differ slightly, one of which will crashes FCP (5 times in 5 tries), the other of which doesn't (0 times in 5 tries). The procedure is ...

Start FCP.
Add the clip to the project.
Drag the clip from the project list to the timeline.

For the problem clip, FCP pops up a dialog when adding the clip to the project ("Media Performance Warning ... The following media files are not optimized for Final Cut Pro"). Then, when the clip is dragged to the timeline, there is a 1-2 second pause, and the gui disappears. After another short pause, another dialog appears ("Final Cut Pro quit unexpectedly"), showing a stack dump. See http://www.aratas.org/apple_developer/fcp_crash.txt for the text of both dialogs.

The clips:

http://www.aratas.org/apple_developer/out_xdcam_09_57_50_19.mov: consistently loads and plays correctly, except that there are 2 black frames at the beginning (I suspect those are due to ctts issues).
http://www.aratas.org/apple_developer/out_xdcam_09_57_50_20.mov: consistently crashes FCP.

Both of these clips are 4:2:0 25Hz 1080p XDCAM (fourcc "hdv7"). Both use a 12-frame closed-GOP structure with 2 B pictures per I/P picture. out_xdcam_09_57_50_19.mov contains 19 frames; out_xdcam_09_57_50_20.mov contains 20 frames, 19 of which are identical to out_xdcam_09_57_50_19.mov.

Both clips play in these players (no leading black frames in any) ...

mplayer SVN-r31628-4.1.2 (linux 2.6.18-308.1.1.el5 x86_64)
mplayer SVN-r30369-4.2.5 (windows 7 ultimate)
QuickTime Player 10.1 (501.8) (Apple OS X 10.7.3)

I've pretty much exhausted the possibilities I could think of for FCP crashing on the 20-frame file. Any suggestions would be highly appreciated ...

Final Cut Pro 7, Mac OS X (10.7.2), FCP 7.0.3

Posted on Jul 24, 2012 4:21 PM

Reply

Answer 1

Jim Cookman

Level 7

23,435 points

Jul 26, 2012 1:50 PM in response to MgFrobozz

Have you installed the Sony XDCAM plugins?

Reply

Answer 2

Jul 26, 2012 2:08 PM in response to MgFrobozz

And because I care more than uncle grump, here's where you can find the xdcam plugins (at least last time I looked).

https://discussions.apple.com/docs/DOC-2721

Reply

Answer 3

MgFrobozz Author

Level 1

0 points

Jul 26, 2012 4:05 PM in response to MgFrobozz

Thanks for the advice. I installed these packages from https://www.servicesplus.sel.sony.com/SoftwareFreeDownload.aspx ...

PDZKLT1A2/XDCAM_EX_Log_and_Transfer_Plugin_1_2_0.dmg

PDZKP1 XDCAM TRANSFER_v212/XDCAM_Transfer_2_12_0.dmg

... and hit restart (which rebooted the OS). I opened FCP again, and retested. No change; out_xdcam_09_57_50_19.mov still plays correctly, and out_xdcam_09_57_50_20.mov still crashes FCP with a divide-by-0.

Reply

Answer 4

Jul 26, 2012 6:22 PM in response to MgFrobozz

first, have you tried deleting your fcp preferences? www.digitalrebellion.com has a great utiltiy to do this.

And you might consider converting your material to prores. Although you can work with xdcam material natively in fcp, converting to prores has some advantages. Rendering and exporting will be faster with prores material.

Reply

Answer 5

Jul 27, 2012 8:08 AM in response to Michael Grenadier

Final Cut Pro utilizes the QuickTime API but it would appear that Apple rewrote certain aspects (perhaps before they existed in QuickTime) so it does not obey the specifications exactly. I've seen certain situatins where FCP expects a certain amount of 0x0 bytes after an ImageDescription extension otherwise it will crash, which forces you to break the QuickTime spec, although luckily the file is still readable by other applications.

So it should not be assumed that a file that other QT apps read just fine will not have problems in FCP. The only thing I know for sure is that it will never be fixed so transcoding may be your best bet.

Reply

Answer 6

MgFrobozz Author

Level 1

0 points

Jul 27, 2012 9:02 AM in response to Michael Grenadier

Hi, Michael ...

Thanks for the hint. I shut down FCP, deleted the preferences, restarted FCP, and re-ran the test. Unfortunately, got the same results.

I noticed that I omitted a dialog in the original submission: it said "Attention - This clip does not match this sequence's setting or any of your sequence presets ... Change sequence settings to match the clip settings?". I had reflexly hit "yes". I tried "no", and it loaded and played without the divide-by-0 and crash. If I accept the change, it crashes. Without the crash, I was able to run Tools/AnalyzeMovie for both the working clip (http://www.aratas.org/apple_developer/out_xdcam_09_57_50_19.mov) and the problem clip (http://www.aratas.org/apple_developer/out_xdcam_09_57_50_20.mov), and it reports them both as Mpeg-2 viddeo at 24.092 Mbps. It also reports an XDCAM export for FCP as Mpeg-2 video (rather than XDCAM).

Although our tools can easily convert this to ProRes, that's not a workable solution for my customer. His workflow specifies XDCAM, and the downstream broadcast server (from another vendor) doesn't play ProRes. My customer processes a lot of clips, so if they transcode to ProRes, and then then later transcode back to XDCAM, it'll take significantly longer to process all their clips, and they'll pick up extra quantization noise in the transcodes.

Reply

Answer 7

MgFrobozz Author

Level 1

0 points

Jul 27, 2012 9:32 AM in response to Jon Chappell

Hi, Jon ...

Yep, I'm aware that Apple doesn't adhere very stringently to their specification. I'm using "QuickTime File Format Specification ... Data Management: File Management 2011-07-13", the latest I could find. I wasn't able to find an errata for it, so I'm gradually building my own. I'd found that FCP doesn't write the tcmi atom as specfied (FCP inserts an extra uint32 in the middle), and thought that might be the problem, but matching that format didn't help.

Thanks for the note. I'm aware of Apple's requirement for the termination code (the extra 0s) at the end of the stsd: that was revealed as a requirement in email from an Apple engineer, so I also write that.The stsd has been at the heart of almost every instance I've encountered in which a clip will play with every player except FCP and QuickTimePlayer. Some other players, after they read the codec fourcc from the stsd, will ignore the rest, much of which duplicates information from the video sequence header, and simply read the video sequence header instead. But since the working clip and the problem clip both have exactly the same stsd (I've done a hex dump of each, followed by a diff), I'm reasonably sure that's not the problem.

As I mentioned in my response to Michael, requiring my customer to transcode to another form is not an option. Somehow I need to discover what's causing FCP to commit seppuku.

Reply

Answer 8

Jul 27, 2012 12:03 PM in response to MgFrobozz

After importing your two files into FCP, in the Browser the second file that crashes is showing a Media Start and Media End value of 00:00:00:00, no Vid Rate, and a Data Rate of "nan TB/sec". Compare that to the good file's Media End of 00:00:00:18, Vid Rate of 25 fps, and Data Rate of 0/sec. The second file is pretty obviously corrupted in some way.

No idea how to fix that, but there you go.

Reply

Answer 9

MgFrobozz Author

Level 1

0 points

Jul 27, 2012 6:12 PM in response to Brad Bechtel

Hi, Brad ...

Thanks for giving those two clips a try. In my Browser, I see the values below. I guess the next question would be, how does FCP determine "Data Rate"? Quicktime defines a max data rate atom ("rmdr"), but neither of these files uses it, since the files don't contain alternate data rates. Also, rmdr uses a 32-bit int, which can't express any number that is nan ("Not A Number").

clip	Duration	Media End	Vid Rate	Data Rate	Compressor	Tracks
out_xdcam_09_57_50_19.mov	00:00:00:19	00:00:00:18	25 fps	0/sec	HDV 1080p25	1V
out_xdcam_09_57_50_20.mov	00:00:00:20	00:00:00:19	25 fps	nan TB/sec	HDV 1080p25	1V

Reply

Answer 10

Meg The Dog

Level 6

13,561 points

Jul 27, 2012 6:21 PM in response to MgFrobozz

If you don't mind, what are the value of/interest in clips that are only 19 frames and 20 frames long?

Just curious.

MtD

Reply

Answer 11

Jul 27, 2012 11:28 PM in response to MgFrobozz

I would have assumed FCP gets the bitrate by calculating the size of the entire video data in the file and then dividing it by the frame rate, although that doesn't seem to tally with the results above. I think it's coming out as NaN because it's doing error checking to prevent the divide by zero. Later on in the code it evidently doesn't check for it and crashes.

MgFrobozz wrote:

I wasn't able to find an errata for it, so I'm gradually building my own.

Would you be willing to share this document? I'd be very interested to see it.

Reply

Answer 12

MgFrobozz Author

Level 1

0 points

Jul 28, 2012 3:50 PM in response to Meg The Dog

Hi, Meg ...

The clip from my customer is 38GB, which is a bit too large to experiment with ;-)

My usual approach to these problems is to simplify the clip, reducing the length and eliminating any variables which don't contribute (in this case, the audio tracks were not a problem). I found that a video-only clip that is anywhere between 1 frame and 19 frames is fine, and adding one more frame to the 19-frame clip (keeping everything else in the clip identical) causes FCP to crash.

Reply

Answer 13

MgFrobozz Author

Level 1

0 points

Jul 28, 2012 4:25 PM in response to Jon Chappell

Hi, Jon ...

That tie between NAN (caused by a check for div-by-0) and the subsequent fault (caused by not checking for div-by-zero) is excellent insight. Presumably some part of FCP thinks the frame rate is 0Hz. For the 20-frame clip, my Browser doesn't show a "Vid rate" of 0Hz, but Brad's did (see earlier message). I'm guessing that what the Browser calls "Vid rate" is what the QT spec calls "Time scale", contained in the mvhd (movie header) and mdhd (the track's media header). Those two values are the same (25) for the 19- and 20-frame files, but maybe there's something else in the 20-frame file that causes FCP to over-write them with 0s within its internal structs.

My customer did comment that if FCP stayed alive long enough to write out the clip as it was closed, that it had corrupted the clip (the clip played with a transmission server from another vendor before the FCP session, but not afterward). They sent me a copy; it had a trak atom for the video trak, but no atoms within the trak video atom. So possible FCP over-wrote the entire video struct, including time_scale.

Regarding releasing the errata, I'll need to check first with my company, but I wouldn't think it would be a problem.

Reply

Answer 14

Jul 28, 2012 4:54 PM in response to MgFrobozz

The data rate isn't calculated from just the timescale. Sample duration plays a part and there may be additional factors too.

Now that I think about it, I'd definitely recommend checking the stts and elst atoms for problems. I've seen strange problems caused by edits or samples not having the same duration.

Reply

Answer 15

MgFrobozz Author

Level 1

0 points

Jul 29, 2012 12:28 AM in response to Jon Chappell

For the 19-frame clip, the elst duration is 19 ticks, stts is 19.

For the 20-frame clip, the elst duration is 20 ticks, stts is 20.

I'm still poring through the atom dump, looking for anything that could contribute. A diff of the dump of the 19-frame and 20-frame files shows the duration differences (19 vs 20), one extra stsz entry in the 20-frame file, and one extra co64 entry in the 20-frame file (both expected). Other than that, there are differences in the atom sizes and offsets due to the extra frame in mdat, and the extra entries in stsz and co64, all expected.

Wish I had the relevant source code for fcp ...

Reply