Build 15 Problem

[Bill Paris]

Wanted to share this and couldn't find the thread that focused on build 15 problems...... I had a shoot today with a client in tow. Shooting 4k 16X9, Redcode 28, 23.98, build 15. The first couple of hours the camera worked fine, but when I tried to shoot a waterfall the camera would stop recording and give me a "Codec Error" warning after about 2 seconds. After trying different things (including re-booting back to factory specs) we found that when we shot areas with little movement/detail the camera would record fine, but when the camera was recording palm trees moving in the wind or the waterfall it would jam up. When we switched to 3K it seemed to work fine as well. In the end we took the camera back to the office and loaded Buld 13 at the suggestion of tech support at Red. The up shot is.... beware of using build 15 on jobs with clients in tow!

[CJ Roy]

This was a problem on the earlier builds. Looks like it's reared its ugly head again.

We did some tests to find out exact record times in various modes, comparing two cameras and we found that the record times differed, based upon what the camera was pointing at. Eventually we just covered the lens giving us the longest record time. But some tests had a difference of 5 minutes or more. I guess it's a variable bit rate issue.

Thanks for the heads up.

-CJ

[Evin Grant]

Hence the "Beta" status. This was a pretty common problem on build 8 or 9 I think too.

[Warren Kommers]

Hence the "Beta" status. This was a pretty common problem on build 8 or 9 I think too.

not being able to shoot 16:9 in 4k should be "charlie" status in my opinion.

i thought i may have missed this limitation or mistook it for continued lack of support of QT 16:9. however, i don't even see it on the download page. am i missing where this was published? besides having to stumble upon it in a forum. or the really hard way....on set. i know.....don't depend on beta. luckily it was just a test shoot. still embarrassing.

see my post on the other thread that is about this dependence on 2:1. just getting frustrating.

still love you red team

[NateWeaver]

I had dropped frames with flying water droplets in Build 13 back in January.

[CJ Roy]

I have no idea how this works, but would a constant bit rate solve this problems or be more ideal in anyway? The bit rate experience I have is in encoding DVD's, and a single pass variable bit rate is usually inferior to a multi-pass variable, or constant.

Thanks.

[Jarred Land]

Yes indeed, we heard a few instances of this, Sean is trying to recreate it right now.

[wshultz]

This is interesting. We were hanging out of a helicopter yesterday and got the Codec Error several times using build 15. The camera operator noticed it seemed to happen every time he reversed directions and flipped the camera to shoot behind him. We thought maybe it was the roughness of the ride causing a disconnect with the hard drive. (He was handholding afterall at 55 mph) So maybe the 180 degree reversal flip motion was too much motion. Does this require a reboot? We did but I don't know if it was necessary.

This was a test run to see how the camera would do so we were looking for problems like this. The finished footage would give us a blue screen and "failure to write frame" message in Redcine.

[wshultz]

You can see flipping cam front to back would create some jarring motion. I had accidently configured for 16:9 instead of 2:1 I intended. We didn't notice until we tried using the Flash card. No more errors after that.

[CJ Roy]

That's a Red-Drive dropping frames. It should have popped up on the LCD, indicating how many it dropped. It doesn't take much to induce, and it makes sense on a Tyler mount with combination of high frequency vibration and rotating on 2 of its axis'.

Redcine will not render through the drop frames, it just stops and gives an error. In the QT proxies they'll show up as green frames and when you render out through RedAlert, it'll show as a stutter.

Our first time using the Spacecam AND the Red-Drive had a lot of these problems, as long as we were rotating, doing fast pans, or if there was turbulence. We've since solved that problem and can shoot in any vehicle, drop frame free.

EDIT: I didn't read the post thoroughly enough, the drop frames shouldn't cause the codec error message. Not sure what the hell that is.