Welcome to our community

Be a part of something great, join today!

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

Komoodo Beta 1.5 finally has landed

Great update, thanks!

Especially excited to try the updated wireless capabilities....
 
Thanks Jonathan,

Yeah, I've been testing it out too! Super cool, I was just curious if the Red team had any tips about how it might impact the camera while it recording? Might sound like a crazy idea but I already have a use-case in mind where I could have my post team offloading material via FTP while the crew is shooting! This would likely result in occasional writes to the card while rolling, and sustained background reads out over the FTP connection possibly for hours!

I'm just curious what type of problems I should expect. I don't really think of cfast cards as bullet proof and I'm wary that reading and writing could over tax the card or the camera's card bus, or something that's not current known. I know 1.5.0 is beta but figured I'd ask as for some insights as I starting up my own testing. :)
 
Another crazy idea!!! I'm not technical enough to know if this is possible... Could the camera calculate MD5 or SHA checksums while writing to the card? So... as each clip is saved the camera dumps a hash into the .RDC? Someone on the FTP destination computer could run a MD5/SHA calculation and compare against the original!!

:)
 
erichann said:
Another crazy idea!!! I'm not technical enough to know if this is possible... Could the camera calculate MD5 or SHA checksums while writing to the card? So... as each clip is saved the camera dumps a hash into the .RDC? Someone on the FTP destination computer could run a MD5/SHA calculation and compare against the original!!
Click to expand...

I don't know exactly what data checks occur during the writing of R3Ds or ProRes, but we know it does stuff for sure. For a checksum to work it would have to occur after the file segments would finish writing or after entire clips, which could get hairy on a queued and staggered start/stop recording session.

But!

You can indeed compare a remote file against a local one and produce a checksum to ensure your download completed successfully. I've got a bit on my plate this weekend, but I did mock up a sniffer auto FTP downloader and that worked nicely. I'm actually curious to see how to do this while rolling and if that's going to destroy the world. Don't want to tax the system too hard, but that would be interesting.

Have some stranger ideas pertaining to timelapse setups too. A lot of interesting applications here. One of which would be extracting metadata and generating populated reports on a mag into a populated database which can then be sync'd to a studio, flagging takes in nearly realtime or even after the fact, offloading flagged takes, flagged takes as a priority, etc. Or even when ingesting a physical card cross referencing against the DB with physical media.

Lots of thoughts here.
 
Absolutely Phil! Love that timelapse idea... :)

Speaking of timelapse, where's 1fps for komodo? I knew I left it around here somewhere!

On the checksums front, I just didn't know if you could run a hash function while the bits streamed out of the encoder/buffer/whatever internally, before writing to card. Some desktop apps I use seem to spit out a hash as the file is being copied, not as second pass read/calculate operation. I'm sure that it's highly hash function dependent, i.e. MD5 SHA256, xxHASH, all use different approaches.

I'm just saying, my 5G phone a USB-C cable and the Link Adapter! Add some fancy transfer software tricks and... BAM! Soon I'll be able to automate RAW uploads to Dropbox while shooting!

Just saying non-sense words now.
 
erichann said:
Thanks Jonathan,

Yeah, I've been testing it out too! Super cool, I was just curious if the Red team had any tips about how it might impact the camera while it recording? Might sound like a crazy idea but I already have a use-case in mind where I could have my post team offloading material via FTP while the crew is shooting! This would likely result in occasional writes to the card while rolling, and sustained background reads out over the FTP connection possibly for hours!

I'm just curious what type of problems I should expect. I don't really think of cfast cards as bullet proof and I'm wary that reading and writing could over tax the card or the camera's card bus, or something that's not current known. I know 1.5.0 is beta but figured I'd ask as for some insights as I starting up my own testing. :)
Click to expand...

Let me speak to the team here & get back to you on that.

That's my initial concern as-well, just too many intensive tasks going on at once on the card especially where the footage is a critical asset. CFast cards get hot enough already.

I really love the idea of a software application monitoring the media directory & just smashing out a copy & some renders as soon as another clip is initiated.
 
Instead of thinking of timelapse functions, it's better to request undercranking. It's a big problem that we cannot shoot custom framerates. We should be able to choose whatever framerate we want between 1-40 fps in 6K FF, with more on lower resolutions.
It's common for action scenes to shoot 20-22 fps to slightly increase speed or around 12 fps for some VFX application as well as timelapse stuff down at the 1 fps range. We also might want to be able to do trigger frames, like doing one R3D recording with trigger frames for stop motion. I know that it's better to do this with DSLRs, but getting files in R3D format can be nice for faster stop motion post-work. Then, being able to custom choose framerates in overcrank mode between 25-40 fps in order to do stuff like slomo that works with music video timing and easier playback singing in higher speed is extremely important for music video work.

It's a much-needed feature to have 1-40 custom fps options so I hope this gets attention in the next firmware versions.
 
awesome, thank you!!
 
Now that it's out in the wild, how stable has everyone found it to be? I never had issues running DSMC2 betas on jobs, but for some reason I've been reluctant to update the baby dragon.
 
I haven't had a chance to spend a lot of time with it yet since I just moved, but the only issue I've run into so far has been the wonky focal distances on the RF 800mm lens I have. No other problems in those couple of hours. I'll try again this weekend though.
 
D. O'Bryan said:
Now that it's out in the wild, how stable has everyone found it to be? I never had issues running DSMC2 betas on jobs, but for some reason I've been reluctant to update the baby dragon.
Click to expand...

I threw the beta on and then handed the camera to the BTS guys on the last set I was on. They messed around with it for a whole weekend; I don't think there was a single issue. I'll have to do more testing myself, though.
 
Thanks everyone! Good to know. I really haven't even put the Komodo through it's paces besides a 1/2 day interview and some testing around the house. Got weirded out by a clip that was just a black frame when I first got it...

First true shakedown cruise coming this Wednesday!
 
I recently rolled back my Firmware after a few small bugs with the Beta. The most noticeable was the thumbnails of all my clips in playback were very, very blue tinted. Possibly just displaying the wrong white balance and it didn't effect playback. Did spook us for a second though!

I also noticed that Prores clips took longer to finalize, the camera took longer to power down (Image would stay up for a solid 15 seconds after the UI was gone)

I will pop the new firmware back on if I need the features, seems reliable enough but I had a very busy week and didn't need any of the updates and wasn't looking to be a test subject.
 
erichann said:
Thanks Jonathan,

Yeah, I've been testing it out too! Super cool, I was just curious if the Red team had any tips about how it might impact the camera while it recording? Might sound like a crazy idea but I already have a use-case in mind where I could have my post team offloading material via FTP while the crew is shooting! This would likely result in occasional writes to the card while rolling, and sustained background reads out over the FTP connection possibly for hours!

I'm just curious what type of problems I should expect. I don't really think of cfast cards as bullet proof and I'm wary that reading and writing could over tax the card or the camera's card bus, or something that's not current known. I know 1.5.0 is beta but figured I'd ask as for some insights as I starting up my own testing. :)
Click to expand...


Wait...so you trust the stability of a network...ANY network, over that of a Cfast2 card? :out:
 
Totally excited to get anamorphic features in 1.5. The one thing that I noticed is that I'm getting vignetting on 4:3 and 3:2 1.8x 6K settings and it's out of proportion (stretched too wide) in 3:2, 4:3 and 6:5 6K 2x on the Vazen 40mm.

One more setting that would be helpful is 6K 6:5 1.8x. I think that would help clear the vignette completely. I use 6:5 on my Gemini with Atlas lenses and that does the trick. For the official 1.5, please add that mode, thank you much.
 
Brian Roberts said:
Wait...so you trust the stability of a network...ANY network, over that of a Cfast2 card? :out:
Click to expand...

Hey Brian, oddly in this case it doesn't seem too crazy to me. :)

Downloading clips while rolling poses a bigger burden on the camera and card than on the camera's network interface and (very much depending on the existing network infrastructure) the network. My math says, that my CFast cards would max out in the 500MB/s range, and that my test with r3d HQ recording get me roughly 270MB/s writing to the card. A Gigabit connection to the camera could run at 115MB/s and in this case it would be reading from the card at maybe 115MB/s while writing to the card at 270MB/s. Clearly nothing is approaching the cards max, but it's not insignificant load on the card especially because it's having to do two operations (back and forth) at the same time. As far as I'm aware cards in Red cameras, in the past have enjoyed the luxury of dealing with writing clips without having to play them back at the same time, (i.e. couldn't have the camera in playback mode while also rolling). Reading and writing data could possibly have a weird impacts on how the clips bytes get laid out on the CFast storage area.


The camera's network interface would (theoretically) only be sending data (unless someone's using the app/desktop at the same time) and as far as I know the FTPS connection uses TCP packets which have error correction! Dropped packets could be re-sent if failed. And the files don't have to fly off the camera at the same speed at writing them to the card, there's a little less pressure on the network to preform flawlessly as the CFast card. All this to say having some kind of checksum system would still bring a lot of peace of mind.

I could be outta my league, but the potential of offloading while shooting seems promising, assuming all the steps in the middle actually work correctly. Am I too optimistic? :)
 
Seen people have problems with this beta release and their camera not starting up correctly. I don't have a problem myself since I don't update to beta releases because that's what anyone who needs to use their camera or doesn't have any backup cameras should do. But for those with semi-bricked cameras, I noticed that there's only a menu access to a factory reset. How come there's no hard buttons for this? Makes zero sense that we can't do a factory reset through buttons. DSMC2 can factory reset by holding down the power button while it's starting up, but we don't have such an option on Komodo?

And this isn't really solvable by new firmware as the factory reset should go back to a reference point before this. The only way would be to make a solid and 100% stable firmware upgrade that sets a "factory baseline" going forward. So that any factory reset goes back to that firmware and not before. But that would require an extremely rugged and stable firmware update that is the most stable firmware ever. If we don't have a factory reset button option for when a camera is totally not working, we need to have something like that, in some way, installed.
 
Has anyone found noticeably longer clip finalizing times with the new firmware? I can't confirm this phenomenon even for my own case, as it's difficult to compare-- it's not like I ever timed out the "yellow light" period with the previous firmware, and it had been more than a month since I last shot with the exact same settings (6k 17:9 format recorded as 4k prores). But I was surprised how long I had to wait before rolling again after shooting 30-90 second clips.
 
Christoffer Glans said:
Seen people have problems with this beta release and their camera not starting up correctly. I don't have a problem myself since I don't update to beta releases because that's what anyone who needs to use their camera or doesn't have any backup cameras should do. But for those with semi-bricked cameras, I noticed that there's only a menu access to a factory reset. How come there's no hard buttons for this? Makes zero sense that we can't do a factory reset through buttons. DSMC2 can factory reset by holding down the power button while it's starting up, but we don't have such an option on Komodo?


And this isn't really solvable by new firmware as the factory reset should go back to a reference point before this. The only way would be to make a solid and 100% stable firmware upgrade that sets a "factory baseline" going forward. So that any factory reset goes back to that firmware and not before. But that would require an extremely rugged and stable firmware update that is the most stable firmware ever. If we don't have a factory reset button option for when a camera is totally not working, we need to have something like that, in some way, installed.
Click to expand...

A long power press during boot does a factory reset just like it did in DSMC2. It doesn’t go back to known good firmware image - but neither did DSMC2. It will reset all user settings.

There is also a force upgrade method, again like DSMC2, which bypasses the currently installed firmware and upgrades directly from the system bootloader.
 
You must log in or register to reply here.
Back
Top