Footage going corrupt after imported into after effects

[Marco Cardenas]

I’m on a Mac Pro 2x 3.2 GHz Quad Core Intel Xeon Machine with 10 gigs of ram and Aja Kona Card. We work on Final Cut Studio 2 version 6.0.6 and After Effects CS4. We are putting a cut together of just talking heads on a greenscreen and exporting each shot individually to key out in after effects and add graphics, supers, titles etc. Then we are exporting the shots out of After Effects back to final cut. The issue is once those files are in aftereffects usually like 6 out of 20 will just go offline and wont play even in quicktime. I really can’t figure this one out. I hope thats enough info sorry for not being so detailed. My condolences lol.

[Marco Cardenas]

Yeah its the same machine. We have 3 different machines and they all have the same specs. The clips are fine in the edit and even in after effects. Its when you render them out or maybe reopen the program, like i said its very random. If it was a log and transfer issue the original footage would be messed up. Its something with the export to after effects I feel like. But we can’t figure it out. Everything still works it just sucks when you have to waste an extra hour to re render shots that went offline. I can’t stress how random this problem is cause shots that dont work one time will re render out of final cut back to ae and then be fine. Its very very strange.

[Mike Zimbard]

Marco-

Unfortunately I cannot offer a definitive solution, but we have been experiencing this as well and like you say it is quite maddening to constantly be re-exporting files. I have some thoughts as to why this might be happening, but can’t consistently re-create the issue so it’s very difficult to pinpoint.

Our workflow is slightly different than yours. We’re using FCS 2, AE CS 4, Kona 3 card and our 3 rooms are configured in an XSAN 2.1 (4 promise raids). Our footage is coming in from RED either 2K or 4K, but everything is transcoded into ProRES HQ 2048X1152 before our Final Cut edit. For greenscreen shots we then export self-contained footage to composite in After Effects. A portion of times during that process if a shot has been keyed and then AE is re-opened, an error will be reported saying the clip is offline and it will no longer be able to play in Quicktime. VERY frustrating. Also, similar shots seem to pose a constant issue (meaning this problem keeps happening to the same clips, whereas others are fine).

One fix has seemed to be exporting the problem clips from FCP onto a local drive (not on the SAN), opening up those files in QT Pro, then saving self-contained back to the local drive, and finally copying that file to SAN. Definitely an annoying process. Luckily we only work in short form spots so none of these clips are too long, but if you have clips of any length I would think this would really start adding a lot of time to your workflow.

A couple of things have changed in our workflow in the past few months and that’s when this problem arose. We formerly used to capture from HDCAM tape and work 1920×1080 ProRes HQ in FCS 2 and AE CS3. Around the time we switched to AE CS4 is also when we started receiving RED footage consistently so there are two new variables in play. Now in CS4 our new frame size from pro RES is 2048×1152. My thought is that maybe that frame size could be causing some kind of quicktime corruption. Marco – what frame size are you working in?? Is it “non-standard?” Also, CS4 is the other variable, but as Dave was saying I usually find AE to rarely be a culprit with these kinds of issues. But it’s so bizarre, I can’t rule anything out.

Furthermore, it shouldn’t be XSAN related because we’ve been on 2.1 since last June with no issues. However, after installing CS4 and working with these larger frame sizes, this problem has appeared to crop up more when one artist is working in Final Cut and another artist is receiving exported shots for AE compositing. Permissions issues?? All of our permissions from the XSAN are read/write for the 3 stations and our engineers have verified this.

So this problem us scratching our heads as much as you. If anyone can offer some thoughts it would be hugely appreciated. Thanks!

– Mike

[Benjamin Byleen]

The problem described above seems very similar to something that I have encountered as well, but I have not been able to determine the exact cause of the problem or a solution.

Quicktime files (various codecs) that have been successfully imported into AE CS4 from the SAN, later on randomly go “corrupt” saying that the moov file is unsupported. When these files are launched in quicktime an error reports “bad public movie atom” and will not open.

Is there any chance that the AE Preference “write XMP data”, when enabled, causes this problem? I have not seen any posts that would suggest that, just grasping at straws here.

Any updates Mike? or OP?

—————-
2.94 MacPro Nehalem
12 GB Ram
XSan 2.1.1
Adobe CS4 Master Collection
FCP 6.06
Decklink HD Extreme

[Steven Jones]

I have had this exact same issue multiple times over the last few days on two different machines. This is HDCAM footage by the way. After Effects seems to corrupt these quicktime files and then they are completely unreadable. Seriously frustrating. Please let me know if you see some kind of fix for this.

[Steven Jones]

I have had the EXACT same problem. On 2 different machines and using 2 different XSANs. Footage randomly gets corrupted, or after effects crashes then when I relaunch the footage is corrupt and is no longer viewable. I getthe same error message about the MooV file being unsupported. I am wondering if it might have something to do with the XSAN? Whatever the case, it is extremely irritating and potentially bad if I corrupt some footage that can’t be redigitized. Let me know if you find any solutions.

[Benjamin Byleen]

For those out there having this problem, would you be willing to try a test?

I am leaning towards the “write XMP data” preference in After Effects CS4 (in Media & Disk Cache settings) as the problem. Now I’m not saying that it’s Adobe’s problem(!), but just that somehow when the XMP data is written back to the file there could a faulty writing of that data (perhaps related obscurely with the XSan filesystem).

A few things have led me to this conclusion. First, this preference does alter the quicktime file. Modified dates on the file are changed and of course, as the preference implies, metadata is written to the QT file. Second, the modified date on the file only changes after the first interaction with the file (as far as I can tell), which would lend credence to all of us that had a working file for awhile which then went randomly bad. Third, using HexEdit and studying the code that makes up each QT, I have noticed that this preference adds additional code to the QT file other than the XMP metadata.

Also, as far as I can tell, when the preference is disabled, the file is never modified during interactions in AE.

SUMMARY:
If you want to try a test and/or are not using the XMP metadata feature anyway, please disable the preference and report back if any corruptions occur or not. I have not encountered any corruptions since disabling it, but a larger test group would bolster these test results.

[Mark Hatch]

Ben,

Whatever came of this? We’ve had similar problems for a couple of years and we run FCP/CS4/XSAN2.X. I just had this issue come up from After Effects CS4 and now the Quicktime File is corrupt, as mentioned above. Funny thing is that this file was just a small quicktime, h264 file, 640×360 and I was just using it for reference. It worked fine for about 30 minutes, then all of the sudden it died. I like your test idea, but I may have some information that will be helpful for it. We’ve had this problem without ever importing footage into After Effects. We own two RED cameras and shoot lots of footage with them. We used to use RedCine to process the footage to ProRes. We’d then edit for a few days in final cut pro and randomly, some of the footage would start going corrupt. This happened a lot and was very frustrating. We found that if we processed the footage to a local drive and edited from there, that the footage never went corrupt. So, my only guess is that the problem lies with XSan. That may not be true, but it certainly checks out. But it may be the combination of XSan with certain applications. We started using the RED Rocket several months ago and I don’t think we’ve had that issue since then. But as I mentioned, I just had a similar issue with After Effects CS4, XSAN 2.(something) and a lowly quicktime, h264 file. Also, we don’t seem to recall ever having had this issue with XSan 1.

Anyone have any new findings on this?

Mark Hatch
Cosmic Pictures

[Benjamin Byleen]

Hi Mark:

Well I’m glad to know that it’s probably not After Effects. I could never show that it was, only that the mentioned AE preference does modify the file’s code structure.

So you have QTs (RED) on the SAN that later on randomly go “corrupt” so that when the files are launched in quicktime an error reports “bad public movie atom” and will not open?

I’m pretty sure that a recent XSan update spoke of this error and that it was fixed. This would lend credence to your local harddrive test.

“Resolves an issue that could cause QuickTime media to report “invalid public movie atom found” on playback”

https://support.apple.com/kb/ht3927

I haven’t seen the problem again, and I hope this fixes it for you, though I’m guessing you are on a recent version. And btw if you need some of the corrupt movies back I might have found a way to resurrect them.

Sorry I didn’t post the link earlier.

Ben

[Mark Hatch]

The actual raw RED files don’t become corrupt. We used to process those RED files, using REDCine, to ProRes Quicktime files. We would process them directly to the SAN. Those files are the ones that would randomly become corrupt after a day or two. Corrupt, meaning that we get the “bad public movie atom” error and are unable to edit with them. We are now on XSan 2.1.1. We don’t seem to have that problem anymore, but we also don’t use REDCine. We now use RED Rocket and RocketCineX.

I just had this one issue yesterday. So it appears that mostly, we’re much better off now.

Mark Hatch
Cosmic Pictures