Anyone else had problems processing Mysterium X rushes on the Red Rocket card?

[Stefan Engelhardt]

I had an issue when I was transcoding some R3Ds that had been shot on our newly upgraded Mysterium X camera to Pro Res. The first two reels went through RedCine X without incident but on the third reel I noticed that the progress slowed significantly. The ETA was about 2 hours for a clip that takes about 10 mins using software only. Some of the files turned out okay but others where just a smattering of different coloured pixels on white. I've attached a frame grab as an example. A test in RocketCine X threw up errors saying frames could not be decoded.

For the sake of expediting the rushes, they were done on other suites using software only. While slower, because of the absence of the Rocket card, this worked fine. Also, when the Rocket card was disabled on the aforementioned suite, it also functioned well. So the problem seemed to be with either the R3Ds or the Rocket card.

I updated the Rocket card firmware, installed the drivers and Red Cine X again. I opened up the tower, took out the card and blew out all the dust, then reseated it. None of this made any difference.

I've done tests with other R3Ds we have and they all work fine.

My guess is that there is some issue with at least one of the clips, possibly metadata related, that is preventing it from being processed properly through the Rocket card. The only way to transcode clips after it hit a corrupt clip would be to reboot the computer. Because once a corrupt clip went though, even non corrupt clips wouldn't work after that.

My specs are as follows:

Mac Pro running Mac OSX 10.6.2
Dual 2.26 GHz Quad-Core Intel Xeon
16GB Memory 1066 MHz DDR3

[Deanan]

Can you send us the corrupt clip?
(please email me at deanan at red)

[Jordan Livingston]

I recently experienced this EXACT same problem transcoding to Avid DNxHD! I was unable to determine any solution after similar troubleshooting measures. I eventually decided the clip itself must have been corrupted somehow. Unfortunately, I was not the DIT on the set, and I can't speak to the data management workflow that was taking place.

Meanwhile, I have been waiting with baited breath for forthcoming updated RedRocket drivers and firmware, hoping that they might magically solve the problem.

Deanan, Stefan: if you guys come to any conclusions or solve this problem, PLEASE post here and let us know!

Thanks + Best,

- Jordan

[sander kamp]

Have had problems as well and although RED is responsive and willing to help still haven't found a solution to all.

Would really appreciate more information and solutions!

[Deanan]

Have had problems as well and although RED is responsive and willing to help still haven't found a solution to all.

Would really appreciate more information and solutions!

If there is corruption in a clip, it can cause problems in both rocket or software modes. The next firmware version tries to recover from problems more robustly.

[Mikael Lubtchansky]

I also ran on an MX clip crashing the rocket. In my case a cold restart of the computer wouln't work and the only way to revive the rocket after it hit that clip was to reinstall firmware otherwise it would keep rendering black frames for any R3D file. It happened only on 1 clip from a 7 week shoot (over 6 Tb recorded on 16gb cards only). The clip would crash the rocket after a few dozen frames both In RedCine-X playback and the new redline. I was able to render an offline of it using the noRocket argument

I will send the file and more detail at the end of the week once we wrap this feature shoot...

[Jordan Livingston]

The problem I faced occurred with just one clip out of a five day shoot, hence my conclusion that the clip itself was to blame. Again, being a broken record here, but would really like to know if there is a solution to "fix" the errant clips in this situation.

- Jordan

[hoylecd]

This is exactly the same problem I've been dealing with as well. Just purchased and installed a Red Rocket card two days ago, and immediately began rendering out to pro res proxy using red cine x. However, it seems to randomly stop rendering, which can be seen clearly in the batch window as the time to completion begins to count up instead of down. The only way to fix the problem is to do an entire restart of my MacPro.

I was concerned it was the Red Rocket card itself, but after seeing these other posts, it seems at least possible RedCine X or the Red Rocket software is having issues. I have backed up all of the footage myself using R3D Data Manager, and viewed every clip in it's entirety, so I know it's not a drop frame issue (which I've dealt with as well). This is clearly something else, and the problem persists with both builds 194 and 221. Today I'm working on another job, again with MX cameras. The DP and I will try RocketCine X today for our one lights, and see if we run into the same issue. Also, I'll try rendering some non MX material and see if I suffer the same problem.

Thanks to everyone who brought this up!

[Mike Prevette]

No problems here, and I've passed 20 hours of MX footage through it.

[Stefan Engelhardt]

Thanks to everybody for their contributions. I've sent one of the clips I was consistently having this problem with to Deanan. Hopefully it will tell them what they need to make the next firmware version for the Rocket card cope a bit better with this sort of error.
In the meantime, if you come across one of these clips, I would suggest disabling your Rocket card and using software only just for that clip. That's what worked for me.

[hoylecd]

Yesterday, after writing my first post, I was going to use Rocketcine X instead. However, it became quickly apparent that Rocketcine X was also suffering from the same issue. Since the current job I'm on requires ProRes 422 HQ transcodes, I thought I'd try running in Leopard (instead of Snow Leopard).

Success! I was pleasantly surprised to see RedCine X 221 push through the transcoding without issue. While this is great news for my current gig, I'm still very concerned about the future when I have to transcode to either 4444 or Pro Res Proxy.

To reiterate my problem, when transcoding to ProRes using my new RedRocket in RedCine X, RedCine X will stop rendering seemingly randomly. There are no drop frames or messed up R3Ds causing this, and doing a software only transcode works fine. This is all happening in Snow Leopard, while Leopard seems to work flawlessly.

Also interestingly, if transcoding 3 clips at a time (instead of lining up the 40 clips in total I had) I had a fair amount of success. RedCine X only froze up three times, each requiring a reboot, and again this was all in Snow Leopard. A troubling thing I noticed however, was a clip that was rendered with some flashes of red-frames. I then went through every clip and found another ProRes with green-frames. These were not in the original R3D files, and a second transcode went through just fine.

I'd much rather be working in Snow Leopard, so if anyone has any suggestions, I'm all for trying some sort of fix.