Currently Being ModeratedJul 26, 2012 1:50 PM (in response to MgFrobozz)
Have you installed the Sony XDCAM plugins?
Currently Being ModeratedJul 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).
Currently Being ModeratedJul 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 ...
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.
Currently Being ModeratedJul 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.
Currently Being ModeratedJul 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.
Currently Being ModeratedJul 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.
Currently Being ModeratedJul 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.
Currently Being ModeratedJul 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.
Currently Being ModeratedJul 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
Currently Being ModeratedJul 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?
Currently Being ModeratedJul 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.
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.
Currently Being ModeratedJul 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.
Currently Being ModeratedJul 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.
Currently Being ModeratedJul 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.