Canon EOS R5 so-called overheat timer defeated by a single screw in battery door

[Andrew Reid]

48 minutes ago, phoberus said:

is this the same with the R6?

I don't have one and won't be buying one that's for sure.

Soon the R6 will be announced and I am sure people will put it through the same stringent tests as the R5.

The field tests I've seen of the EOS R6 so far don't bode well, with cut off times as bad as, if not even worse.

It has no fall-back "not limited by cripple hammer" 4K line skipped mode either so it is a 1080p camera basically

[docmoore]

6 hours ago, horshack said:

 

I found the .DAT area on the interrupted-SD image and spliced in the 128KB MP4 header from the .MP4 from the good image. The file plays...and I hear a quick snippet of sound, but no video. So there is work to do there. But at least it demonstrates the basic integrity of the full MP4 is in place.

To get this working on R5 images we'd have to determine how to build the proper 128KB MP4 container header, the same as how the camera builds it when the user ends a video recording. This might be as simple as splicing from a "good" .MP4 image, but probably requires a lot more effort, and then graft that 128KB header data with the the .DAT file to reconstruct the full .MP4

You have made great progress ... I wonder how specific the MP4 header is and whether is has a similar temp file that is converted to the final MP4 header when the file is finalized. I assume it holds the key to interpretation of the file by the NLE 

Fun to see this unfold 

[Andrew Reid]

@horshack

Are you working with the 8K MP4 DAT files, or 4K HQ truncated recordings too? I can send you a few different flavours of file if this helps, might be interesting to compare the different codecs.

I also need to test 4K HQ with the battery pull after starting and stopping recordings prior to one last sacrificial short clip to facilitate the battery pull during recording, and seeing what the camera remembers from the previous 4K HQ clip record times in NVRAM and what it doesn't. Card swap is also key to do.

[mitdelay]

Screw Canon. Waiting for the Sony or Panny

[horshack]

3 hours ago, docmoore said:

You have made great progress ... I wonder how specific the MP4 header is and whether is has a similar temp file that is converted to the final MP4 header when the file is finalized. I assume it holds the key to interpretation of the file by the NLE 

Fun to see this unfold 

I think I've found out why the video playback is blank and the there's no audio. The MP4 header has 'stsz' and 'stco' atoms that are indexes into the actual video and audio data in the mdat atom. Those atoms are used by players/NLEs to correlate time to video/audio frames. Since I copied the entire MP4 header from the "good" video those indexes will be wrong for the "bad" video and have to be rebuilt. I found an open-source tool named uncut that does this (https://github.com/ponchio/untrunc), documentation here. Built and ran it but it wasn't able to find any of the frames in the files. Will be looking into the code to see if it can be tweaked to work on these files

[horshack]

1 hour ago, Andrew Reid said:

@horshack

Are you working with the 8K MP4 DAT files, or 4K HQ truncated recordings too? I can send you a few different flavours of file if this helps, might be interesting to compare the different codecs.

I also need to test 4K HQ with the battery pull after starting and stopping recordings prior to one last sacrificial short clip to facilitate the battery pull during recording, and seeing what the camera remembers from the previous 4K HQ clip record times in NVRAM and what it doesn't. Card swap is also key to do.

I'm working with 4K H.264 files from a 1DX that @docmoore provided me. I can actually use a pair of R5 ALL-I 4K files - perhaps those will be easier to reconstruct. Can you shoot two 4K ALL-I videos for me, each 30 seconds in length, one that is recorded normally and the other where you pull the battery after 30 seconds. The first will be a regular .MP4 and the second will be a .DAT file. Then put them up on a share I can download from? Please have some kind of sound playing while recording - that will help me in the debugging effort find and sync up video/audio frames. Thanks!

 

[Andrew Reid]

Sure will do. I'll send you these via Wetransfer soon - do you want 10bit HEVC or 8bit H.264 - or both?

[horshack]

45 minutes ago, Andrew Reid said:

Sure will do. I'll send you these via Wetransfer soon - do you want 10bit HEVC or 8bit H.264 - or both?

All-I for the pair of videos. thanks. I think 30 seconds might be too big to share - 15 seconds/each should be plenty.

[horshack]

1 hour ago, Jn- said:

Not addressing the file corruption directly, but if the card is formatted in fat32, all of the smaller 4gb video clips recorded and saved except the last one, at battery eject should be fine.

You sir win the internet today. I just tried it on my Canon RP, which like the R5 forgets any changes to the camera's settings (like exposure settings) if you pull the battery in the middle of the recording but will remember the changed settings if you stop a recording normally.

Procedure:

1. Tape down the door sensor and leave the door open so the battery is accessible
2. Put a 32GB card in the camera and
3. Turn the camera on and format the card. It will automatically use FAT32 cards with a capacity <= 32GB
4. Start a video recording, in this case I used 4K 24P, which has an average total video/audio bitrate of 14.43 MB/s.
5. Shoot a video whose length will exceed 4GB. For my 4K 24P that's any video longer than just under 5:00. I shot one for exactly 5:00
6. Pull the battery
7. Check the card and verify there's a single .MP4 file
8. Reinsert the battery and verify the camera "forgot" the previous session's settings

We know the camera saves its settings whenever it has successfully recorded a video. The question is whether @Jn- idea will avoid that save for the FAT32-case of splitting up a video file at 4GB/each (FAT32 limit), provided we still pull the battery at the end of the recording. In other words, will the camera save NVRAM for each intermediate 4GB-split file or only for the final file after properly stopping a recording?

Drumroll...It works! My RP's aperture was f/4 when I turned it on for step #3. I changed it to f/11 for the test. After reinserting the battery my RP's aperture reverted back to f/4!

Andrew, please test this ASAP on your R5 and see if it matches my RP's behavior of forgetting the settings, the most important of which is of course the thermal timer.

 

[horshack]

29 minutes ago, horshack said:

You sir win the internet today. I just tried it on my Canon RP, which like the R5 forgets any changes to the camera's settings (like exposure settings) if you pull the battery in the middle of the recording but will remember the changed settings if you stop a recording normally.

Procedure:

1. Tape down the door sensor and leave the door open so the battery is accessible
2. Put a 32GB card in the camera and
3. Turn the camera on and format the card. It will automatically use FAT32 cards with a capacity <= 32GB
4. Start a video recording, in this case I used 4K 24P, which has an average total video/audio bitrate of 14.43 MB/s.
5. Shoot a video whose length will exceed 4GB. For my 4K 24P that's any video longer than just under 5:00. I shot one for exactly 5:00
6. Pull the battery
7. Check the card and verify there's a single .MP4 file
8. Reinsert the battery and verify the camera "forgot" the previous session's settings

We know the camera saves its settings whenever it has successfully recorded a video. The question is whether @Jn- idea will avoid that save for the FAT32-case of splitting up a video file at 4GB/each (FAT32 limit), provided we still pull the battery at the end of the recording. In other words, will the camera save NVRAM for each intermediate 4GB-split file or only for the final file after properly stopping a recording?

Drumroll...It works! My RP's aperture was f/4 when I turned it on for step #3. I changed it to f/11 for the test. After reinserting the battery my RP's aperture reverted back to f/4!

Andrew, please test this ASAP on your R5 and see if it matches my RP's behavior of forgetting the settings, the most important of which is of course the thermal timer.

 

Just tried it for a longer video, this time 10:00, to test two splits and it still works. Two perfectly-good .MP4 files, each approx 4GB and 4:41 in length, and an RP with amnesia after powering it back on.

The only limitation of this technique is 32GB, since Canon cameras format all cards > 32GB as exFAT, even though FAT32 supports volumes up to 2TB. But there's a workaround for that as well - format the >32GB card on computer instead. Windows 7/10 wont let you format cards > 32GB to FAT32 but there are third-party utilities that will. I just used http://www.ridgecrop.demon.co.uk/index.htm?guiformat.htm on a 64GB card and the camera accepted the card with no complaints. Recording to it right now on my RP to test splits for a very long video. And while Windows wont let you format >32GB cards to FAT32 it will mount them just fine.

[Emanuel]

You're making history, guys! Don't complain ; ) without Cannot you wouldn't be there... : D  (E :- )

 

 

[Emanuel]

[Andrew Reid]

Christmas has come early this year!

Ah I remember Peter, nice guy. He did a video on EOSHD C-LOG as well

 

[horshack]

3 hours ago, horshack said:

Just tried it for a longer video, this time 10:00, to test two splits and it still works. Two perfectly-good .MP4 files, each approx 4GB and 4:41 in length, and an RP with amnesia after powering it back on.

The only limitation of this technique is 32GB, since Canon cameras format all cards > 32GB as exFAT, even though FAT32 supports volumes up to 2TB. But there's a workaround for that as well - format the >32GB card on computer instead. Windows 7/10 wont let you format cards > 32GB to FAT32 but there are third-party utilities that will. I just used http://www.ridgecrop.demon.co.uk/index.htm?guiformat.htm on a 64GB card and the camera accepted the card with no complaints. Recording to it right now on my RP to test splits for a very long video. And while Windows wont let you format >32GB cards to FAT32 it will mount them just fine.

Update:

• I recorded 25:00 of video then battery pull with no issue on my RP. All ~4GB MP4 segments were fine, with naturally the last one missing
• Don't let the recording reach the 29:59 legacy limit - if you do the camera will save the NVRAM settings when it automatically ends the recording
• The Ridgecrop formatter tool link I posted for Windows only worked once for me. After that the camera wouldn't accept any cards formatted with it. I then tried the formatter built into OSX using the FAT32 and MBR options (not GPT) - the camera accepts those cards but then displays an error whenever you take a photo or end a video recording. The only reliable and consistent way I've found to format > 32GB cards for FAT32 that my RP would accept and work with is under Linux. You can see instructions how to do so here.
• Here's a screenshot of the ~4GB segements on a 64GB SD card formatted to FAT32 for my 25:00 recording:

[visionrouge]

On 8/25/2020 at 3:02 AM, horshack said:

My RP's aperture was f/4 when I turned it on for step #3. I changed it to f/11 for the test. After reinserting the battery my RP's aperture reverted back to f/4!

 

 

It's always laike this with all Canon camera. If you lose the power, all parameters are not saved.

But here is what you should do.
Put your camera parameters as you like until you are ready to shoot.
Turn off the camera with the power switch (The recording parameters as shutter speed, aperture, iso,...) are saved there
Turn on the camera.
Record and drop the battery when you like.
When you put again the battery, the parameters will be the same as last turn on/off sequence.
 

[horshack]

16 minutes ago, visionrouge said:

It's always laike this with all Canon camera. If you lose the power, all parameters are not saved.

But here is what you should do.
Put your camera parameters as you like until you are ready to shoot.
Turn off the camera with the power switch (The recording parameters as shutter speed, aperture, iso,...) are saved there
Turn on the camera.
Record and drop the battery when you like.
When you put again the battery, the parameters will be the same as last turn on/off sequence.
 

The goal isn't to save the parameters...the goal is to *not* save them 😀 It's the entire basis of the workaround for the timer element of the R5's thermal algorithm.

Btw, you don't have to turn off the camera to save the parameters. Taking a photo or a video or moving the mode dial between stills/movie mode saves them as well.

[John Matthews]

News just in:

Canon is currently finding ways to create loops and bugs in R5's firmware to properly overheat at 20 minutes... code to keep running for two hours after. They've terminated the employment of the engineer responsible for choosing a heat-efficient, modern processor, allowing the R5's limitations to be bypassed.

A spokeswoman for the company released this statement: 

 "We deeply regret that some renegade customers have (illegally?) hacked the R5's abilities to record 8k footage and its limitations of a 20 minute recording every 2 hours. These customers are not in compliance with the user agreement and risk a non-functional device. We have addressed the problem and corrected the R5's firmware to perform as advertised."

Unofficially, the companies spokeswoman, categorically criticized EOSHD.com for their lack of believing the R5's specifications at the time of release, despite Canon's best marketing efforts in the matter.

[ajay]

1 hour ago, John Matthews said:

News just in:

Canon is currently finding ways to create loops and bugs in R5's firmware to properly overheat at 20 minutes... code to keep running for two hours after. They've terminated the employment of the engineer responsible for choosing a heat-efficient, modern processor, allowing the R5's limitations to be bypassed.

In other news, Canon's entire EOS R engineering staff have committed harakiri. Please see Canon's website for new job postings.

[Electroholic Anonymous]

IT WORKS!!!

This is with a Sony 128GB UHS-II card, R5 recording 8K 23.98p IPB in roughly 680Mbps. I will try some other modes next, but I trust this will work in any mode available on SD. Pity that RAW does not work with this neatest of tricks. You guys are geniuses!

 

[ajay]

Congrats! So...This formatting

17 minutes ago, Electroholic Anonymous said:

IT WORKS!!!

This is with a Sony 128GB UHS-II card, R5 recording 8K 23.98p IPB in roughly 680Mbps. I will try some other modes next, but I trust this will work in any mode available on SD. Pity that RAW does not work with this neatest of tricks. You guys are geniuses!

"It" works meaning FAT32 formatting using Linux? Does this only work on SD chips, not CF Express? That's why no 8k raw nor 4k 120p? Please unconfuse me.