L&T Problems with Red Footage

[Jeremy Garchow]

Looks like some sort of codec conflict to me. By the looks of your dock, it seems like perhaps you have a few different Red software installed? If so, perhaps you’ve installed a few versions on top of each other?

Just curious…

[Jonathan Hensley]

Possible. But I don’t know if that would explain why it worked for the first 75% of the footage but not the last half.

[Jeremy Garchow]

Something went corrupt/kablooey. I’d try to uninstall/delete all the old versions of everything and see what happens. Also try deleting any and all renders files, along with your waveform and thumbnail caches, as well as constant frames. Make sure that FCP is quit when doing this.

Jeremy

[Jonathan Hensley]

Hey guys. Thanks for the advice.

A few weeks into this now, and I’m still running into the same problems on THREE different computers (all with the same specs). Software has been updated correctly on all three, and I trashed the waveforms and thumbnails on all three.

Sometimes I get a green screen like before, and sometimes Final Cut Pro quits unexpectedly and blames the RedCode QT Plugin.

Any ideas? I’m desparate.

[Jeremy Garchow]

What version of Fcp and what version of the red l&t plugin?

Perhaps you should think about a redcinex to make prores proxies > edit in fcp > XML to clipfinder conform back to Fcp > send to color workflow. It’s much simpler than it sounds and works very well.

Jeremy

[Jonathan Hensley]

UPDATE:

Sorry to double post in this thread, but after getting frustrated with Final Cut Pro, I decided to run the clips through RedCine-X. It actually worked fine for a minute, but when I looked through the clips, I noticed THE SAME PROBLEM! (though the clips were black this time instead of green).

Video Below.

https://www.youtube.com/watch?v=PHPLpvr-xxA

This leads me to believe that there has to be something wrong with the way the Red folder are set up, though not the clips, because the Quicktime files work fine and play well.

[Jeremy Garchow]

[Jonathan Hensley] “his leads me to believe that there has to be something wrong with the way the Red folder are set up”

Yeah, the DIT screwing around with the file structure is kind of a scary thought.

Perhaps the footage has dropped frames and it is screwing up the workflow. I haven’t seen it myself but have heard it can cause some major issues.

[Joshua Caldwell]

Jonathan,

Out of curiosity, which camera did you shoot on? We’re currently running into the same problem. We’ve tried converting to different formats on two different machines through FCP, REDCine, everything and its the same issue.

So far, it’s only happening to footage shot on the A Camera on day one. The interesting thing about that, is that on that day, A Camera was a Red One and B Camera was a RED MX. Thus far, we’ve had no trouble with the MX based footage (after day one, we switched A Camera to an MX).

It doesn’t make sense why RED ONE footage wouldn’t work but we believe we’ve isolated it to this camera. However, some clips work fine from that camera do work.

We shot on cards the entire day and it doesn’t seem to be a card only issue, though we haven’t confirmed that. Regardless, the proxies play fine and the pre-convert file plays fine in L&T. It’s some weird glitch in the conversion process.

Regardless, even though all your clips are turning green, that doesn’t mean that all of them are “corrupted.” What happens is that the corrupted clip effects the rest of the import. Try L&T on the clips following the clip that didn’t work. We’ve managed to trim it down to only a few problem clips. (This way you’re not screwed out of all of them.)

Meanwhile, has anyone else had experience with this. Seems like a recent phenomenon.

Thanks,
Josh

[Joshua Caldwell]

Here’s a potential cause/solution to the problem:

As some of you know, there have a been a number of threads/projects on here suffering from footage turning into solid green images during import (whether through FCP’s L&T, REDCINE-X and even Clipfinder). Like others, we were experiencing the same issue on our project, inexplicably, and have managed to isolate the problem and come up with a potential (albeit laborious) workaround for those still looking for a solution (considering there are none out there yet).

We’ve managed to isolate the problem to a select number of clips and it appears that the cause is a dropped frame, actually, several corrupted, dropped frames, that appear as solid green images in the middle of the clip. We were shooting on several SD cards and it appears there wasn’t any one card that was the culprit. However, after speaking with our DIT, we learned that on any card that had a “corrupted” frame, when copying to the hard drives, he would encounter a “Source Verify After Copy Error.” Having never seen this before (and us being in the middle of the desert with no internet access), and having verified that the information/footage was there in RED ALERT, he made a note of it, labeled the folder and moved on.

(I should note that while he should have possibly recopied, we were so under the gun and so behind on copying that, having checked to make sure all the footage did get copied and played fine in REDALERT, there was no way for him to know.)

When he came in this evening and started going through it, he discovered that all of the problem files with the green frames were from the same file that gave him the “Source Verify After Copy Error.” We were able to isolate those files based off those file labels and those notes and all of the other non-issue files appear to be importing through L&T correctly. However, I’ll have an update tomorrow on whether this is entirely true. So far so good.

So, that seems to be the problem, though we still don’t know what caused the weird dropped frames.

Now, for the workaround on the damaged clips:

First and foremost, as suggested above, not ALL of your clips are corrupted. What happens when converting through L&T is that once the program hits the bad frame (the green one) it doesn’t know what to do and converts everything after that frame, whether in the same clip or all the clips following it, to green.

Regarding the clips with the green frames, what we’ve done is brought the corrupted clip into Clipfinder and set in and out points before and after the corrupted section, effectively creating two separate clips, with the section within it missing and then exported it as normal.

Sometimes this doesn’t matter because the corrupted file is in the beginning, before the marker. Sometimes, however, they’re in the middle and we have to manually go in and re-sync the audio.

The reason you can’t just say “oh, well, we cut out 10 frames, so just drop the second clip in 10 frames later,” is that, at least for us, scrubbing over the corrupted section causes Clipfinder to crash. Our AE is going to be finessing those corrupted clips and we’ll let you know what his work flow is.

The fortunate thing is that we’re only losing a few frames of footage in certain clips. Fortunately, we were shooting with two cameras and have multiple takes of each scene. The bad news is that we don’t know what caused the dropped frames, since the issue wasn’t with one card in particular. Could have been a cable issus, card reader issue, random drive issue, we don’t know.

But at least there’s more of a solution to the problem then there was before.

Let me me know if you have any questions.

Josh

[Jonathan Hensley]

I’m glad you found a possible solution. My only concern is how this will effect relinking the R3D files back to the converted footage in Color. Is it even possible when you split the clip in two?