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 (http://www.reduser.net/forum/showthread.php?t=5540) 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

[Mark L. Pederson]

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
you need to manually enter REEL #s at this time - TC is all good.

[I Bloom]

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.

FOLLOWING IS MY THEORY ONLY:
Once the image gets to the compression engine it is just a matrix of numbers. My guess that at that point they transform the values from the image into a series of wavelet coefficients. Unlike DCT, wavelet is "impulse" based, so it likes thing to be a little random, and doesn't like regular repetition. That's good because most "natural" images are by nature a little random and impulsive. What I would look out for would be highly "periodic" not neccessarily high frequency. Man made things, like the bars on a focus chart, or large areas where every value is exactly the same, such as a region of clipping... these might create an "exceptional case" in the build 8 processing pipeline that trips the codec fault. Once they identify the case, they can write code to handle it, which they've likely already done.
END THEORY

My guess is that they have been working to improve the compression a little since build 6. Hats off to Red for doing this. Bugs are a reality for all software developement. Wavelets compression is more complicated than older forms of compression, but clearly much much better. To look at your footage, you can't find any visible sign that it's been compressed, even after heavy color correction.

Engineers have known about the benefits wavelets for image compression for decades. No other company has had the cojones to go there until these guys. So don't worry about these bumps in the road, but if you do have a problem, share it and share the solution. Rocket being surprised and having to cancel a shoot is much worse fodder for the FUDers than everyone on this forum, knowing in advance about some specific bugs that are being worked out.

IBloom

[Rocco Schult]

Excellent theory Ian, really. I am really an old DCT guy and didn't familiarize mcuh with Wavelet.

But the flowers go also to Cineform, they are on the Wavelet track a long while so when honoring for Wavelet, we shouldn't forget them... I think...

[Greg M]

I just noticed ver 1.3.6 is posted which fixes "codec error" in build 8.

I swear this wasn't there this morning, but its dated Oct 28th.
BTW- they also revised the support page w/ RedCine "Coming Soon"

[Mark L. Pederson]

I just noticed ver 1.3.6 is posted which fixes "codec error" in build 8.

I swear this wasn't there this morning, but its dated Oct 28th.
BTW- they also revised the support page w/ RedCine "Coming Soon"

good eye.

yes - 8.1.3.6 has the fix, and it is what our feature is shooting on -

[I Bloom]

Excellent theory Ian, really. I am really an old DCT guy and didn't familiarize mcuh with Wavelet.

But the flowers go also to Cineform, they are on the Wavelet track a long while so when honoring for Wavelet, we shouldn't forget them... I think...

Alter my post to say camera companies. And cross out my theory, it's fun, but mostly wrong, I think.

IBloom

[Stuart English]

Yes, we have been field testing it for a couple of days, but posted it today. Build 9 should be available this weekend.

(BTW - There is no audio enabled in Build 9. The "next build" mentioned previously means the next build after 9)

[Geoff Reisner]

Yes, we have been field testing it for a couple of days, but posted it today. Build 9 should be available this weekend.
That just made my day! :)

[Noah Kadner]

We got hit once with the Codec Error message in Build 8 during our last shoot. It was right at the first shot of a newly formatted mag. We kept on shooting on that mag without even powering down and all but that first shot were fine.

Noah