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

Epic Frame Artifacts / Corrupt Frames

B

bscibelli

New member
Joined
Nov 12, 2007
Messages
4
Reaction score
0
Points
0
Location
Charlotte, NC USA
Website
www.cinemanix.com
I just completed a shoot and we found that there were corrupted frames in 2 sequences (See Attached). The frames were completely random, and they were on 2 clips that were several minutes apart, but on the same media. There were several frames that had this issue, but is looked similar in all cases.

The camera was rigged into the dashboard of a car that was moving, but I have never seen a frame corruption like this even when the camera has been bumped around.

Other than 2 clips that were affected by this, there were no further problems with other clips shot for the remainder of the shoot.

Any input is appreciated.

Thanks!
Bryan
 

Attachments

  • Frame_Artifacting.jpg
    Frame_Artifacting.jpg
    46.4 KB · Views: 0
We were moving pretty fast, and Shotput Pro was giving proper returns on the file copy, so there was no apparent data corruption. Unfortunately because of the speed that we were moving, the cards checked out and they were wiped and put back into action.

I was on a Macbook Pro playing the files back, and scrubbing through the footage was normal. I have seen corrupt frames in the past halt the playback and crash RedCine, but there was no issue playing the clips back.

I was thinking that it may have been a result of them switching constantly from HDRX mode, because we did have to re-boot the camera a few times because it hung up on switching HDRX on and off, but it shouldn't be problematic in the clips.
 
I was using R3D Data manager and at another time Double Data, both of which gave the all clear for the copy being okay, but we have the same looking corruption happening randomly through a lot of the footage on the drive with the transferred footage. As we still have the original camera data on the SSD cards we got the chance to re-transfer and the issue went away. We were using a Macbook pro too when the corruption happened. The footage was scrubbed through quickly and seemed okay. The corruption was only seen when played in real-time.

The re transferred footage was done on a different computer.

I would try to test the camera using the same Macbook pro for transfers and see if you can reproduce the issue. In my cases it was the transfer process that caused the issues.
 
Get in touch with your Bomb rep. Download a log and send it to RED for analysis. Attach the frame grabs.

I had the same issue last year - EPIC body had to go home for a fix.
 
I'm wondering how MD5 checksums could possibly be reported OK by ShotPut Pro or R3D DataManager/DoubleData if copies were corrupted? Unless the backup drive had a corruption after checksum. But if backing up to two or more drives, there should be at least one good copy even so.

Either that, or the much less safe options of CRC check or Byte Count were selected for speed?
 
ericyoung said:
I'm wondering how MD5 checksums could possibly be reported OK by ShotPut Pro or R3D DataManager/DoubleData if copies were corrupted? Unless the backup drive had a corruption after checksum. But if backing up to two or more drives, there should be at least one good copy even so.

Either that, or the much less safe options of CRC check or Byte Count were selected for speed?
Click to expand...

If the corruption is part of the original recorded data and not a function of the copy, the checksums and every other verification would show exactly the same content.
 
Brian F Kobylarz said:
If the corruption is part of the original recorded data and not a function of the copy, the checksums and every other verification would show exactly the same content.
Click to expand...

Actually Tim was using R3D DataManager and DoubleData, which gave the all clear, but when they found corruption on the transferred files, they were able to retransfer from the original media without corruption, so this wasn't the case based on what he wrote.
 
ericyoung said:
Actually Tim was using R3D DataManager and DoubleData, which gave the all clear, but when they found corruption on the transferred files, they were able to retransfer from the original media without corruption, so this wasn't the case based on what he wrote.
Click to expand...


Yes this is exactly right. Neither R3D data or Double Data at different times picked up that there was a transfer issue. My thinking is that the corrupted transferred frame had the same numbers of bits/ bytes etc as the original only there were a little scrambled, so the checksum software did not see an issue.

I have since retired the Macbook pro that was used and have not had an issue since.
 
I had this issue sporadically with my Epic and it slowly got progressively worse until it finally gave out on a shoot and started corrupting every clip I shot. I sent it into Red and there was a damaged internal board that needed to be replaced. I strongly recommend sending in your camera, especially if its still under warranty.
 
Brian F Kobylarz said:
Get in touch with your Bomb rep. Download a log and send it to RED for analysis. Attach the frame grabs.

I had the same issue last year - EPIC body had to go home for a fix.
Click to expand...
+1
I would say so, at least when the corrupt frames shows in camera too.
I had this for half a year, coming and going from time to time. Finally sent it in, just got it back.
 
Tim Bradley said:
Yes this is exactly right. Neither R3D data or Double Data at different times picked up that there was a transfer issue. My thinking is that the corrupted transferred frame had the same numbers of bits/ bytes etc as the original only there were a little scrambled, so the checksum software did not see an issue.

I have since retired the Macbook pro that was used and have not had an issue since.
Click to expand...

Were you using MD5 or CRC or Byte Count options when this happened? Theoretically, MD5 would have a mathematically miniscule chance of not catching a corrupt transfer due to the number of bits/bytes being the same, at the expense of longer transfer time. CRC would catch single bit errors & some burst errors, and a fairly decent faster alternative to MD5. Byte count is not a reliable check, but better than nothing.

A visual check is still essential, preferably real time if possible.
 
You must log in or register to reply here.
Back
Top