Welcome to our community

Be a part of something great, join today!

Register Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

When Good Codecs Go Bad...

S

Scott Webster

Well-known member
Joined
Dec 28, 2006
Messages
703
Reaction score
0
Points
0
Location
New Zealand
Website
www.rocketrentals.com
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.
 
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.
 
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.
 
Brook Willard said:
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.
Click to expand...

Why would build 6 be able to handle the same shot? Nothing has changed other than the firmware.
 
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."
 
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.
 
Rocketeer said:
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.
Click to expand...

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
 
Brook Willard said:
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.
Click to expand...

Rocketeer said:
Why would build 6 be able to handle the same shot? Nothing has changed other than the firmware.
Click to expand...

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
 
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...
 
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"
 
digitalfx said:
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"
Click to expand...

good eye.

yes - 8.1.3.6 has the fix, and it is what our feature is shooting on -
 
augenmensch aka therock said:
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...
Click to expand...

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

IBloom
 
Build 8 v1.3.6

Build 8 v1.3.6

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)
 
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
 
You must log in or register to reply here.
Back
Top