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 :)

Build 16 Codec Error killer...

Thom said:
Maybe they could dedicate a small platoon to give us a hand with a Canon EF mount? ;)
Click to expand...

We were contacted by another accessory company that has had one in development for awhile... looks like there may be options coming.

Jim
 
Jannard said:
We were contacted by another accessory company that has had one in development for awhile... looks like there may be options coming.

Jim
Click to expand...

I see my EF 200mm f/2L IS on a RED with a working IS system working sooner then later. looks like, and there is nothing better then good competition to make a good product even better.


BTW. if any one needs this lens to try it on RED, SHOUT, offer off course includes the RED team. Not that Jim is unlikely to already have his own in is 500 lens arsenal.:)


ciao
 
REDFEAT said:
Same question, where do we send/upload log files associated with codec errors in this most recent build?
Click to expand...

deanan@red.com

... although I would wait until we post the next build that has further improvements. Leo has given us a lot of feedback. :-)

Jim
 
Mike Prevette said:
On a slightly on topic note. Can I PLEASE have the ability of turning the "CODEC ERROR" warning off on the HDSDI and HDMI outputs? I'd much rather keep any issues in the camera DEPT until I see fit to provide a solution and till the client/producers. My client should never have to see something so ominous.
Click to expand...

I completely agree and second this request.

It does nothing but hurt the reputation of the Red camera to have non-technical clients spread the word that they "Used that new Red camera and we kept getting huge errors all day!" They may simply be 'card full' errors, but to the non-technical money people they are big red X's surrounded by dollar signs!

There is no need for anything so scary looking to flash on the client's monitors!
 
Moscow said:
just looked into upgrading now and can't find Build 15 2.2.8 were is it how do i proceed without it......??
Paul
Click to expand...

Build 15 v2.2.8 has been added to the Build 16 v3.1.8 download as a separate folder within the download. My apologies for that oversight....

BC
 
big lebowski said:
I'm glad that RED is addressing this CODEC error problem with such high priority and great effort. But being a software engineer myself I must say that I'm highly worried by this try-and-error approach. That's simply NOT the way to write reliable software!

I really hope that this is only an intermediate solution to the problem and that they're going back to the drawing board of scientific software design and theoretical proof of the algorithms in use. Yes, it's always possible to prove scientifically that algorithms work.

Keeping my fingers crossed...
Click to expand...

Indeed.

However, where the rubber meets the road is that there often must be compromises within the constraints within the rest of the system. Consider that the RED One:

- Must process even the most pathological of complex test frames in 1/30th of a second or faster in order to be ready for the next frame
-Has a limited power budget
-Has a finite gate/MIPS budget
-Has a thermal envelope target
-etc..

So while it may be possible to mathematically verify that a test frame of entirely random noise in each channel will successfully compress without error, it may require 1/10th of a second to do so. Or it may need 3X the CPU. Or significantly more power.

The end result is that if you design the system, for the worst possible case, you may end up with a camera that's twice as large, runs 3 times as hot, has 1/2 the battery life, and uses only 30% of the CPU capacity 99% of the time, but when maxed out 1% of the time is deterministic in every conceivable worst-case scenario.

Or... you can attempt to tune and make some compromises (perhaps being willing to slide image Q in pathological cases), but those are often "soft" decisions that require some estimation and iteration to get just right.
 
So I'm reporting from set today that build 3.1.5 gave me a codec error on a high contrast white backdrop in a studio setting. Having downloaded build 3.1.8 this morning before the job I told the client we had a new version that should fix the problem. Lo and behold, after the upgrade, no more codec error! Client was VERY impressed and the footage being shot is great.

I hope Leo can get the team over the last hump, but for me 3.1.8 in the studio is 100% as of right now. Awesome work Red Team!

Cheers from the front line!

Paul :)
 
I tried and tried to kick 3.1.8's arse!

I could not break the codec.

I aimed it at trees, shrubs, flowers... I found the highest contrast and most detailed scenes that I could! I even did whip pans until the drive dropped frames because of g-force... but no codec errors!

I shot everything at 23.98, 2k 120 to the drive, 2k 100 to the CF cards, 4k 16:9 and 4k 2:1, 3k overcranked... all the while going back and forth between RedCode 28 and 36. If it was a "legal" setting with 23.98 frame rate, I shot it! (Except anamorphic.)

So, I am happy to report that for me 3.1.8 was rock solid!

-Thor
 
Glad to hear Thor...

I must say it is nice to have an army of you guys out there helping us test this stuff... with your help and the fearless pack of RED engineers, we have improved things even further since this mornings build... stay tuned :)
 
Scaesare, personally I think Joofa, Big L, Pawel, etc are all right - you can build an efficient bug-free codec. I think Red will prove it beautifully when they do their firmware 16 release build.

scaesare said:
So while it may be possible to mathematically verify that a test frame of entirely random noise in each channel will successfully compress without error, it may require 1/10th of a second to do so. Or it may need 3X the CPU. Or significantly more power.
Click to expand...

I disagree that an algorithm that successfully compresses in all cases would put onerous burdens on the CPU. I am defining success as "compresses any image without crashing" not "compresses any image without losing image quality".

I think the reverse is true - it is *substantially* easier to optimize a crash-proof algorithm for speed than optimize a buggy algorithm - eg you never know if it's your new optimization that's screwing things up, or if it's the old crash rearing its head again. That slows you down a lot.

Also, if you have a function that crashes - and don't know why - then it means you don't understand precisely what is going on. It's difficult to optimize something if you don't know what it's doing exactly.

scaesare said:
Or... you can attempt to tune and make some compromises (perhaps being willing to slide image Q in pathological cases), but those are often "soft" decisions that require some estimation and iteration to get just right.
Click to expand...

That's what 99% of lossy compression algorithms do. They slide image quality in all cases. Pathological can look badly-compressed, but never crash out.

Anyway, no need to argue, I guess. I'm confident Red will prove that it is do-able by squashing the codec bugs.

They have made it very clear that they're prioritizing it, so I say thank you again to Red for communicating this and wish them lots of sleep.

Bruce Allen
www.boacinema.com
 
Jarred Land said:
Glad to hear Thor...

I must say it is nice to have an army of you guys out there helping us test this stuff... with your help and the fearless pack of RED engineers, we have improved things even further since this mornings build... stay tuned :)
Click to expand...

I've got a few more challenges to throw at 3.1.8 tomorrow. I'll check for a new build before I shoot, in case one gets released.

Seems like we're close to a clean bill of health! I'm really excited, Jarred. Thanks for the reply.

-Thor
 
WOW that was hard. I just tortured the crap out of 3.1.8, I finally won and it cracked. But one burp out of 80 torture shots aint so bad.

I shot 4k 2:1, 4k 16x9, 3k 16x9, 2k 16x9, Redcode28, Redcode36, Varispeed, etc All on cards.

16mm standard speed at t11. Sun, trees, sand, grass.

It finally cracked on me after pointing it at some sand and beach grass. BUT (very big but) after the camera cut, I hit record again and everything was fine. I'll email logs when I get a sec.
 
As we said... we are 99% there (or in Mike P's case 98.75%)... and we have a better build coming. Thanks to all for torture testing this build. I hope everyone is getting more comfortable that codec errors are soon to be a thing of the past. They have bugged all of us long enough.

Jim
 
Miltos Pilalitos said:
Thanks Jim,

Good to know codec errors will be a thing of the past. Does the fix cover the compression bugs as well?
Click to expand...

I haven't heard of any compression bugs left in Build 16... did I miss something?

Jim
 
You must log in or register to reply here.
Back
Top