When Good Codecs Go Bad...

[Scott Webster]

After 3 hits outs with firmware build 8 and no dramas we came to grief on the fourth. Which of course had to be our most interesting from a rigging perspective -Motion Control Crane.

Camera had been stable for 4 hours before we got the 'Codec Error' message.
This coincided with a bent pin in the CF module which we at first thought was the source of the fault. Swapped out the CF for another. Fault remained.

Studio was getting pretty hot by now with no ventilation and the camera had spent a lot of time close to the lights (42C/108F) so we figured that heat may be causing the issue. Broke for lunch and cooled the camera. Fault remained.

Now we were beginning to sweat.

Then I remembered iblooms post on his camera test which had the same Codec Error issue which was resolved by going back to firmware 6. Downloaded firmware 6 from Red support and installed into the camera.

Camera up and stable.

The moral of the story is that sharing the good with the bad is a positive thing. Timezone had screwed us with the Red help desk so this board gave us an answer.

I recommend (as Ian did) anyone running build 8 have a copy of build 6 on hand. Red, we look forward to build 9.

Thanks to the crew and the production co who remained (outwardly) cool calm and collected.

[Scott Webster]

More BTS

Note the 2 MacPros. 1 was processing the r3d files by loading the QT proxies into compressor and outputting 16:9 DV Pal files which were sent via airport to the 2nd MPB. The 2nd MBP then was dropping those into FCP and doing compiles.

[Brook Willard]

What were you shooting when the Codec error hit? Overexposure or high-frequency data, perhaps? I've found that I can consistently replicate the error with either of these.

[Kevin Halverson]

Yep, the cutting edge can easily turn into the bleeding edge!

Thanks for sharing the experience and glad that you managed to resolve the problem and save the shoot.

[Scott Webster]

What were you shooting when the Codec error hit? Overexposure or high-frequency data, perhaps? I've found that I can consistently replicate the error with either of these.

Why would build 6 be able to handle the same shot? Nothing has changed other than the firmware.

[Scott Webster]

Yep, the cutting edge can easily turn into the bleeding edge!

Thanks for sharing the experience and glad that you managed to resolve the problem and save the shoot.

As they say, Lead, Follow or Get Out of the Way!

[Brook Willard]

No idea... I don't know enough about what the firmware updates have control over to say with any certainty. I'm guessing that there has to be some codec code change any time there's a firmware update though... or at least code "close" to the codec [think enabling new formats, for example].

I'm gonna bump this one over to "help."

[Deanan]

The 'codec error' is fixed in the next build coming out. Build 6 does not have the same problem so it's a safer to build to use if you can live without 2k/variable speed.

[Alexander Nikishin]

When will build 9 be released Deanan?

[jimhare]

More BTS

Note the 2 MacPros. 1 was processing the r3d files by loading the QT proxies into compressor and outputting 16:9 DV Pal files which were sent via airport to the 2nd MPB. The 2nd MBP then was dropping those into FCP and doing compiles.

Nice! Is timecode maintained? How easy is it to do an offline this way and then match up to the original .r3d files?

Very interesting stuff.

Jim